Escrito por: Nickqiao, Fausto, Shew Wang, geek web3
Consultor: Equipo de investigación de Bitlayer
Resumen: Delphi Digital publicó recientemente un informe de investigación sobre tecnologías relacionadas con la segunda capa de Bitcoin titulado "El amanecer de la programabilidad de Bitcoin: allanando el camino para los paquetes acumulativos", que clasificó sistemáticamente los conceptos centrales relacionados con los paquetes acumulativos de Bitcoin, como BitVM Family Bucket, OP_CAT. y restricciones de Covenant, capa DA ecológica de Bitcoin, puente y las cuatro segundas capas principales de Bitcoin que utilizan BitVM, incluidas Bitlayer, Citrea, Yona y Bob.
Aunque el informe de investigación generalmente muestra una imagen general de la tecnología de segunda capa de Bitcoin, en general es relativamente general y carece de una descripción detallada, lo que lo hace difícil de entender. Geek web3 realizó extensas excavaciones en profundidad basadas en el informe de investigación de Delphi, tratando de permitir que más personas comprendan sistemáticamente BitVM y otras tecnologías.
Lanzaremos conjuntamente una serie de columnas llamadas "Acercándonos a BTC" con el equipo de investigación de Bitlayer y la comunidad china de BitVM para llevar a cabo una divulgación científica a largo plazo en torno a temas clave como BitVM, OP_CAT y puentes entre cadenas de Bitcoin, y estamos comprometidos a desencantar Bitcoin para más personas. Las tecnologías relacionadas con la capa 2 de monedas ayudan a allanar el camino para más entusiastas.
Hace unos meses, Robin Linus, director de ZeroSync, publicó un artículo llamado "BitVM: Compute Anything on Bitcoin", proponiendo formalmente el concepto de BitVM y promoviendo el progreso de la tecnología de segunda capa de Bitcoin. Se puede decir que esta es una de las innovaciones más revolucionarias en el ecosistema de Bitcoin. Ha detonado todo el ecosistema de Bitcoin de segunda capa, ha atraído la participación de proyectos estrella como Bitlayer, Citrea, BOB, etc., y ha aportado vitalidad. todo el mercado.
Después de eso, más investigadores participaron en la mejora de BitVM y lanzaron sucesivamente diferentes versiones iterativas como BitVM1, BitVM2, BitVMX y BitSNARK. La situación general es la siguiente:
El documento técnico sobre la implementación de BitVM propuesto por primera vez por Robin Linus el año pasado es una implementación de BitVM basada en circuitos de puerta lógica ficticios, llamados BitVM0;
En varios discursos y entrevistas posteriores, Robin Linus presentó informalmente la solución BitVM (llamada BitVM1) basada en una CPU ficticia, que es similar al sistema a prueba de fraude Cannon de Optimism. Puede utilizar scripts de Bitcoin para simular efectos de CPU de propósito general. .
Robin Linus también propuso BitVM2, un protocolo a prueba de fraude no interactivo, de un solo paso y sin permiso.
Los miembros de Rootstock Labs y Fairgate Labs publicaron el documento técnico de BitVMX, que, al igual que BitVM1, espera emular los efectos de una CPU de uso general (fuera de la cadena) a través de scripts de Bitcoin.
En la actualidad, la construcción del ecosistema de desarrolladores relacionado con BitVM es cada vez más clara y la mejora iterativa de las herramientas periféricas también es visible a simple vista. En comparación con el año pasado, el ecosistema de BitVM actual se ha vuelto "vago" desde el "castillo" inicial. in the air", que también ha atraído a más y más personas. Cada vez más desarrolladores y capitalistas de riesgo se están lanzando al ecosistema de Bitcoin.
Pero para la mayoría de las personas, no es fácil entender los términos técnicos relacionados con BitVM y Bitcoin Layer 2, porque es necesario tener una comprensión sistemática de los conocimientos básicos que los rodean, especialmente conocimientos como los scripts de Bitcoin y Taproot. Los materiales de referencia disponibles actualmente en Internet son demasiado largos y están llenos de tonterías, o las explicaciones no son lo suficientemente exhaustivas, lo que hace que la gente parezca entender pero no entender. Estamos comprometidos a resolver los problemas anteriores y nos esforzamos por utilizar el lenguaje más claro posible para ayudar a más personas a comprender el conocimiento circundante de la segunda capa de Bitcoin y establecer una comprensión sistemática del sistema BitVM.
MATT y compromiso: la idea básica de BitVM
En primer lugar, queremos enfatizar que la idea básica de BitVM es MATT, que significa Merkleize All The Things. Se refiere principalmente al uso de una estructura de almacenamiento de datos en forma de árbol, como Merkle Tree, para mostrar el complejo proceso de ejecución del programa. Intente hacer que la verificación de Bitcoin Native sea a prueba de fraude.
Aunque MATT puede expresar un programa complejo y sus rastros de procesamiento de datos, no publicará estos datos directamente en la cadena BTC porque el tamaño total de estos datos es muy grande. La solución que utiliza MATT solo almacena datos en el árbol Merkle fuera de la cadena y solo publica el resumen superior (raíz de Merkle) del árbol Merkle en la cadena. Este árbol Merkle contiene principalmente tres contenidos principales:
Código de script de contrato inteligente
Datos requeridos por el contrato
Rastros dejados durante la ejecución del contrato (registros de cambios en la memoria y en los registros de la CPU cuando los contratos inteligentes se ejecutan en máquinas virtuales como EVM)
(Un diagrama simple del árbol Merkle. La raíz de Merkle se calcula a partir de los 8 fragmentos de datos en la parte inferior de la figura mediante hash multicapa)
Según el esquema MATT, solo la raíz de Merkle extremadamente pequeña se almacena en la cadena, y el conjunto de datos completo contenido en el árbol de Merkle se almacena fuera de la cadena. Esto utiliza una idea llamada "compromiso". A continuación se explica qué es “Compromiso”.
Una promesa es similar a una declaración concisa, que podemos entender como una "huella digital" obtenida al comprimir una gran cantidad de datos. En términos generales, la persona que emite un "compromiso" en la cadena afirmará que ciertos datos almacenados fuera de la cadena son precisos. Estos datos fuera de la cadena deben corresponder a una declaración concisa, y esta declaración es el "compromiso".
En algún momento, el hash de los datos se puede utilizar como un "compromiso" con los datos mismos. Otros esquemas de compromiso incluyen el compromiso KZG o Merkle Tree. En el protocolo habitual a prueba de fraude de Layer2, el editor de datos publica el conjunto de datos completo fuera de la cadena y se compromete a publicar el conjunto de datos dentro de la cadena. Si alguien descubre datos no válidos en el conjunto de datos fuera de la cadena, se cuestionará el compromiso de datos dentro de la cadena.
A través del Compromiso, la segunda capa puede comprimir y procesar grandes cantidades de datos y solo publicar su "compromiso" en la cadena Bitcoin. Por supuesto, también es necesario garantizar que el mundo exterior pueda observar el conjunto completo de datos publicados fuera de la cadena.
En la actualidad, varias soluciones BitVM importantes, como BitVM0, BitVM1, BitVM2 y BitVMX, básicamente adoptan estructuras abstractas similares:
1. Descomposición y compromiso del programa: primero, descomponga el programa complejo en una gran cantidad de códigos de operación básicos (compilación) y luego registre los rastros generados por estos códigos de operación durante la ejecución específica (para decirlo sin rodeos, un programa se ejecuta en la CPU). y Cuando están en la memoria, se registran todos los cambios de estado, lo que se denomina seguimiento). Después de eso, organizamos todos los datos, incluidos los rastros y los códigos de operación, en un conjunto de datos y luego generamos un compromiso para ese conjunto de datos.
Los esquemas de compromiso específicos pueden adoptar muchas formas, como: árboles Merkle, PIOP (varios algoritmos ZK), funciones hash.
2. Promesa de activos y firma previa: los editores y verificadores de datos deben bloquear una cierta cantidad de activos en la cadena mediante la firma previa, y habrá restricciones. Estas condiciones se activarán específicamente para situaciones que puedan ocurrir en el futuro. Si el editor de datos hace algo malo, el verificador puede presentar un certificado para quitarle los activos.
3. Publicación de datos y compromisos: el publicador de datos publica el compromiso en la cadena, el conjunto de datos completo se publica fuera de la cadena y el verificador recupera el conjunto de datos y verifica si hay algún error. Cada parte del conjunto de datos fuera de la cadena tiene una correlación con un compromiso dentro de la cadena.
4. Impugnaciones y sanciones: una vez que el verificador descubre que hay un error en los datos proporcionados por el editor de datos, llevará esta parte de los datos a la cadena para su verificación directa (esta parte de los datos debe cortarse muy finamente primero). ). Esta es la lógica de la prueba de fraude. Si los resultados de la verificación muestran que el editor de datos efectivamente ha proporcionado datos no válidos fuera de la cadena, el validador que lo cuestione le quitará sus activos.
En resumen, Alice, la editora de datos, divulga todos los rastros generados durante la ejecución de la transacción de segunda capa fuera de la cadena y publica los compromisos correspondientes en la cadena. Si desea demostrar que una determinada parte de los datos es incorrecta, primero demuestre al nodo de Bitcoin que esta parte de los datos está relacionada con el compromiso en la cadena, es decir, demuestre que los datos fueron revelados por la propia Alice, y Luego, deje que el nodo Bitcoin confirme que esta parte de los datos es incorrecta.
Ahora entendemos aproximadamente la idea general de BitVM, y todas las variantes de BitVM son básicamente inseparables del paradigma anterior. A continuación, comencemos a aprender y comprender algunas de las tecnologías importantes utilizadas en el proceso anterior, comenzando con los scripts de Bitcoin más básicos y Taproot y la firma previa.
¿Qué es Bitcoin Script?
El conocimiento relacionado con Bitcoin es más difícil de entender que Ethereum. Incluso el comportamiento de transferencia más básico implica una serie de conceptos, que incluyen UTXO (salida de transacción no gastada), script de bloqueo (también conocido como ScriptPubKey) y script de desbloqueo (también conocido como ScriptSig). Primero expliquemos estos conceptos principales.
(Un ejemplo de un código de secuencia de comandos de Bitcoin que consta de códigos de operación de nivel inferior a un lenguaje de alto nivel)
La forma en que se expresan los activos en Ethereum es más parecida a Alipay o WeChat. Cada transferencia simplemente suma y resta los saldos de diferentes cuentas. Este método se centra en la cuenta y el saldo de activos es solo un número debajo del nombre de la cuenta. La expresión se parece más a oro. Cada pieza de oro (UTXO) se marcará con su propietario. La transferencia en realidad destruye el antiguo UTXO y genera un nuevo UTXO (el propietario cambiará).
Bitcoin UTXO contiene dos campos clave:
Cantidad, en "satoshi" (cien millones de satoshi es un BTC);
El script de bloqueo, también conocido como "ScriptPubKey", define las condiciones de desbloqueo de UTXO.
Cabe señalar que la propiedad de Bitcoin UTXO se expresa a través de un script de bloqueo. Si desea transferir su UTXO a Sam, puede iniciar una transacción para destruir uno de sus UTXO y escribir las condiciones de desbloqueo del UTXO recién generado como ". Sólo Sam puede desbloquearlo".
Luego, si Sam quiere usar estos Bitcoins, debe enviar un script de desbloqueo (ScriptSig). En este script de desbloqueo, Sam debe presentar su firma digital para demostrar que es el propio Sam. Si el script de desbloqueo coincide con el script de bloqueo antes mencionado, Sam puede desbloquear y transferir los bitcoins a otras personas.
(El script de desbloqueo debe coincidir con el script de bloqueo)
Desde la perspectiva de la expresión, cada transacción en la cadena de Bitcoin corresponde a múltiples entradas y salidas. Cada entrada debe declarar un determinado UTXO que desea desbloquear y enviar un script de desbloqueo para desbloquear y destruir la información UTXO recién generada. Se mostrará y el contenido del script de bloqueo se divulgará al mundo exterior.
Por ejemplo, al ingresar una transacción, usted demuestra que es Sam, desbloquea múltiples UTXO que otros le dieron, los destruye de manera uniforme, genera múltiples UTXO nuevos y declara que xxx se desbloqueará en el futuro.
Específicamente, en los datos de entrada de la transacción, debe declarar qué UTXO desea desbloquear e indicar la "ubicación de almacenamiento" de estos datos UTXO. Cabe señalar aquí que Bitcoin y Ethereum son completamente diferentes. Ethereum proporciona dos cuentas, cuentas de contrato y cuentas EOA, para almacenar datos. El saldo de activos se registra como un número bajo el nombre de la cuenta de contrato o cuenta EOA, y se coloca. de forma unificada En la base de datos del "Estado Mundial", al transferir dinero, se pueden modificar cuentas específicas directamente desde el "Estado Mundial" para facilitar la localización de la ubicación de almacenamiento de los datos;
Bitcoin no tiene un diseño de estado mundial y los datos de los activos están dispersos y almacenados en bloques anteriores (es decir, los datos UTXO desbloqueados se almacenan por separado en la salida de cada transacción).
Si desea desbloquear un UTXO, debe indicar qué salida de transacción existe la información UTXO en el pasado, mostrar el ID de la transacción (que es su hash) y dejar que el nodo Bitcoin la busque en los registros del historial. Si desea consultar el saldo de Bitcoin de una determinada dirección, debe recorrer todos los bloques desde el principio y encontrar el UTXO desbloqueado asociado con la dirección xx.
Cuando normalmente usa una billetera Bitcoin, puede verificar rápidamente el saldo de Bitcoin que posee una determinada dirección. Esto a menudo se debe a que el propio servicio de billetera indexa todas las direcciones mediante el escaneo de bloques, lo que nos facilita realizar consultas rápidamente.
(Cuando genera una declaración de transacción para entregar su UTXO a otros, debe marcar la posición del UTXO en el historial de Bitcoin según el hash/ID de transacción al que pertenecen estos UTXO)
Curiosamente, los resultados de las transacciones de Bitcoin se calculan fuera de la cadena. Cuando los usuarios generan transacciones en sus dispositivos locales, deben crear directamente tanto la Entrada como la Salida, lo que equivale a calcular los resultados de salida de la transacción. Las transacciones se transmiten a la red Bitcoin y los nodos las verifican antes de colocarlas en la cadena. Este modelo de "cálculo fuera de la cadena y verificación en la cadena" es completamente diferente de Ethereum. En Ethereum, solo necesita proporcionar los parámetros de entrada de la transacción, y el nodo Ethereum calcula y genera los resultados de la transacción.
Además, el script de bloqueo UTXO se puede personalizar. Puede configurar el UTXO para que el propietario de una determinada dirección de Bitcoin pueda "desbloquearlo". El propietario de la dirección debe proporcionar una firma digital y una clave pública (P2PKH). ). En el tipo de transacción Pay-to-Script-Hash (P2SH), puede agregar un Script Hash en el script de bloqueo UTXO. ¿Quién puede enviar la imagen original del script correspondiente a este Hash y cumplir con las condiciones preestablecidas en la imagen original del script? puedes desbloquear UTXO. El script Taproot en el que se basa BitVM utiliza características similares a P2SH.
Cómo activar el script de Bitcoin
Aquí primero usamos P2PKH como ejemplo para presentar el método de activación del script de Bitcoin. Solo comprendiendo su método de activación podemos comprender los más complejos Taproot y BitVM. El nombre completo de P2PKH es "Pagar a hash de clave pública". Según este esquema, se establecerá un hash de clave pública en el script de bloqueo UTXO, y la clave pública correspondiente al hash debe enviarse al desbloquear. Igual que la idea convencional de transferencia de Bitcoin.
En este momento, el nodo Bitcoin debe asegurarse de que la clave pública en el script de desbloqueo coincida con el hash de clave pública especificado en el script de bloqueo. En otras palabras, debe asegurarse de que la "clave" enviada por el desbloqueo y el "bloqueo". "preestablecidos por el UTXO coinciden entre sí.
Además, bajo el esquema P2PKH, después de recibir la transacción, el nodo Bitcoin unirá el script de desbloqueo ScriptSig proporcionado por el usuario con el script de bloqueo ScriptPubkey del UTXO a desbloquear y los ejecutará en el entorno de ejecución del script BTC. La siguiente figura muestra los resultados del empalme antes de la ejecución:
Quizás los lectores no conozcan el entorno de ejecución de scripts de BTC, por lo que aquí lo presentaremos brevemente. Primero, el script BTC contiene dos elementos:
datos y códigos de operación. Estos datos y códigos de operación se insertarán en la pila en orden de izquierda a derecha y se ejecutarán de acuerdo con la lógica especificada para obtener el resultado final (los detalles de qué es una pila no se detallarán aquí, los lectores pueden chatear por sí mismos).
Tomando la imagen de arriba como ejemplo, el lado izquierdo es el script de desbloqueo ScriptSig subido por alguien, incluida su firma digital y clave pública, mientras que el script de bloqueo ScriptPubkey en el lado derecho contiene un código de operación y datos establecidos por el creador de UTXO al generar el UTXO (aquí no necesitamos comprender el significado de cada código de operación, solo una comprensión aproximada).
DUP, HASH160, EQUALVERIFY y otros códigos de operación en el script de bloqueo a la derecha en la figura anterior son responsables de codificar la clave pública contenida en el script de desbloqueo a la izquierda y compararla con el hash de clave pública preestablecido en el script de bloqueo. Si los dos son iguales, significa que la clave pública cargada en el script de desbloqueo coincide con el hash de clave pública preestablecido en el script de bloqueo y se pasa la primera verificación.
Sin embargo, hay un problema. El contenido del script de bloqueo UTXO es en realidad público en la cadena. Cualquiera puede observar el hash de clave pública que contiene. Cualquiera puede cargar la clave pública correspondiente y afirmar falsamente que es él. designado por el emperador". "persona. Por lo tanto, después de verificar la clave pública y el hash de la clave pública, también es necesario verificar si el iniciador de la transacción es realmente el controlador real de la clave pública, lo que requiere verificación de la firma digital. El código de operación CHECKSIG en el script de bloqueo es responsable de verificar la firma digital.
En resumen, bajo el esquema P2PKH, el script de desbloqueo enviado por el iniciador de la transacción contiene la clave pública y la firma digital. La clave pública debe coincidir con el hash de clave pública especificado en el script de bloqueo y la firma digital de la transacción es correcta. cuando se cumplen estas condiciones, se puede desbloquear UTXO sin problemas.
(Esta imagen es dinámica: diagrama esquemático del script de desbloqueo de Bitcoin bajo el esquema P2PKH
Fuente: https://learnmeabitcoin.com/technical/script)
Por supuesto, la red Bitcoin admite múltiples tipos de transacciones, no solo Pago a clave pública/hash de clave pública, sino también P2SH (Pago a hash de script), etc. Todo depende de cómo se configura el script de bloqueo personalizado cuando se crea el UTXO. .
Cabe señalar aquí que bajo el esquema P2SH, se puede preestablecer un Script Hash en el script de bloqueo, y el script de desbloqueo debe enviar el contenido completo del script correspondiente al Script Hash. Los nodos de Bitcoin pueden ejecutar este script. Si la lógica de verificación de firmas múltiples se define en este script, se puede lograr el efecto de una billetera de firmas múltiples en la cadena de Bitcoin.
Por supuesto, bajo el esquema P2SH, el creador de UTXO debe informar a la persona que desbloquee el UTXO en el futuro el contenido del script correspondiente al Script Hash de antemano. Siempre que ambas partes conozcan el contenido de este Script, entonces podemos implementarlo. lógica empresarial más compleja que la firma múltiple.
Cabe señalar aquí que la cadena (bloque) de Bitcoin no registra directamente qué UTXO están asociados con qué direcciones. Solo registra qué hash de clave pública/qué hash de script puede desbloquear el UTXO, pero utilizamos el hash/script de clave pública. para desbloquearlo, Hash puede calcular rápidamente la dirección correspondiente (la sección que se muestra en la interfaz de la billetera parece caracteres confusos).
La razón por la que podemos ver xx cantidad de Bitcoins bajo xx dirección en el explorador de bloques y la interfaz de billetera es porque el explorador de bloques y el proyecto de billetera lo ayudan a analizar los datos, escanear todos los bloques y bloquear el script de acuerdo con el hash de clave pública/hash de script. declarada, calcula la "dirección" correspondiente y luego muestra cuántos Bitcoins hay bajo el nombre de la dirección xx.
Testigo Segregado y Testigo
Una vez que entendemos la idea de P2SH, estamos un paso más cerca de Taproot, del que depende BitVM. Pero antes de eso, debemos entender un concepto importante: Testigo y Testigo Segregado.
Al revisar el script de desbloqueo y el script de bloqueo mencionados anteriormente, así como el proceso de desbloqueo de UTXO, encontrará un problema: la firma digital de la transacción está incluida en el script de desbloqueo y el script de desbloqueo no se puede sobrescribir al generar la firma (el Los parámetros utilizados para generar la firma no pueden incluirse (la firma en sí), por lo que la firma digital solo puede cubrir partes distintas al script de desbloqueo, es decir, solo puede asociarse con la parte principal de los datos de la transacción y no puede cubrir completamente la transacción. datos.
De esta manera, incluso si el intermediario manipula ligeramente el script de desbloqueo de la transacción, no afectará el resultado de la verificación de la firma. Por ejemplo, los nodos de Bitcoin o los grupos de minería pueden insertar otros datos en el script de desbloqueo de la transacción, lo que provoca cambios sutiles en los datos de la transacción sin afectar la verificación de la firma ni los resultados de la transacción. El hash/ID de la transacción calculado final también cambiará. Esto se conoce como problema de maleabilidad de las transacciones.
La desventaja de esto es que si planea iniciar múltiples transacciones seguidas y existen dependencias secuenciales (por ejemplo, la transacción 3 se refiere al resultado de la transacción 2 y la transacción 2 se refiere al resultado de la transacción 1), entonces las siguientes transacciones Es necesario citar el ID (hash) de la transacción anterior. Cualquier intermediario, como un grupo de minería o un nodo de Bitcoin, puede ajustar el contenido del script de desbloqueo para que el hash después de que se cargue la transacción sea inconsistente con lo que se realiza. esperabas Entonces las múltiples transacciones que has creado de antemano tendrán transacciones relacionadas secuencialmente dejarán de ser válidas.
De hecho, en las soluciones DLC bridge y BitVM2, las transacciones con correlación secuencial se construirán en lotes, por lo que el escenario mencionado anteriormente no es infrecuente.
En pocas palabras, el problema de la escalabilidad de la transacción se debe a que el ID/hash de la transacción incluirá los datos del script de desbloqueo al calcularlo, y los intermediarios como los nodos de Bitcoin pueden ajustar el contenido del script de desbloqueo, lo que hace que el ID de la transacción sea diferente de lo que el usuario esperaba. De hecho, este es el bagaje histórico que dejó la mala consideración de Bitcoin en su diseño inicial.
La actualización posterior de Segregated Witness/SegWit en realidad desacopla completamente el ID de la transacción y el script de desbloqueo. No es necesario incluir los datos del script de desbloqueo al calcular el hash de la transacción. El script de bloqueo UTXO que sigue a la actualización de SegWit establecerá un código de operación llamado "OP_0" en primer lugar de forma predeterminada, que sirve como marca y el script de desbloqueo correspondiente ha cambiado de nombre de SigScript a Witness;
Después de seguir las reglas de SegWit, el problema de escalabilidad de las transacciones se resolverá adecuadamente y no tendrá que preocuparse por el ajuste de los datos de la transacción enviados al nodo de Bitcoin. Por supuesto, no necesitamos pensar demasiado complicado. Las funciones de P2WSH no son esencialmente diferentes de las del P2SH mencionado anteriormente. Puede preestablecer un hash de script en el script de bloqueo UTXO y esperar a que el remitente del script de desbloqueo envíe el. contenido del script correspondiente al hash en la cadena y ejecutado.
Pero si el contenido del script que desea implementar es particularmente grande y contiene mucho código, el script completo no se puede enviar a la cadena Bitcoin mediante métodos convencionales (cada bloque tiene un límite de tamaño). ¿Qué hacer? Esto requiere el uso de Taproot para optimizar el contenido del script en la cadena, y BitVM es una solución compleja basada en Taproot.
En el próximo artículo de "Acercándonos a BTC", realizaremos una popularización detallada de Taproot, la prefirma y otras tecnologías más complejas relacionadas con BitVM, ¡así que estad atentos!
