Acercándose a BTC: explicando los conocimientos previos necesarios para BitVM

Autores: Nickqiao & Faust & Shew Wang, Geek web3

Asesor: Equipo de investigación Bitlayer

Resumen:

Recientemente, Delphi Digital publicó un informe de investigación sobre tecnología de capa dos de Bitcoin titulado “El Amanecer de la Programabilidad de Bitcoin: Paving the Way for Rollups”. En el informe se abordan conceptos clave relacionados con Bitcoin Rollup, como el conjunto completo de herramientas BitVM, las cláusulas de restricción OP_CAT y Covenant, la capa DA de la ecología de Bitcoin, los puentes y las cuatro capas secundarias de Bitcoin que utilizan BitVM: Bitlayer, Citrea, Yona y Bob.

Aunque este informe de investigación muestra en general el panorama general de la tecnología de capa 2 de Bitcoin, es bastante vago y carece de detalles específicos, lo que hace que sea difícil de entender. Geeks web3 ha profundizado en el informe Delphi para intentar que más personas comprendan de manera sistemática la tecnología BitVM y otras.

Vamos a colaborar con el equipo de investigación de Bitlayer y la comunidad china de BitVM para llevar a cabo una serie de columnas llamada “Acercándonos a BTC”, que se centrará a largo plazo en temas clave como BitVM, OP_CAT y puentes cross-chain de BTC, con el objetivo de desmitificar las tecnologías relacionadas con la capa dos de Bitcoin y allanar el camino para más entusiastas.

Texto:

Hace unos meses, Robin Linus, el responsable de ZeroSync, publicó un artículo titulado “BitVM: Compute Anything on Bitcoin”, en el que presentó oficialmente el concepto de BitVM, impulsando el avance de la tecnología de capa dos de Bitcoin. Se puede decir que esta es una de las innovaciones más revolucionarias del ecosistema de Bitcoin, que ha desencadenado todo el ecosistema de capa dos de Bitcoin, atrayendo la participación de proyectos destacados como Bitlayer, Citrea, BOB, y ha traído vitalidad a todo el mercado.

Posteriormente, más investigadores se unieron para mejorar BitVM, y lanzaron sucesivamente diferentes versiones iterativas como BitVM1, BitVM2, BitVMX, BitSNARK, etc. La situación general es como se muestra a continuación:

1. El libro blanco de la implementación de BitVM propuesto por Robin Linus el año pasado se basa en el circuito lógico ficticio de puertas para el esquema de implementación de BitVM, conocido como BitVM0;
2. En las siguientes charlas y entrevistas, Robin Linus presentó informalmente el plan BitVM1 basado en una CPU ficticia (llamado BitVM1), similar al sistema de prueba de fraude Cannon de Optimism, que puede simular un CPU universal fuera de la cadena con scripts de Bitcoin.
3. Robin Linus también propuso BitVM2, un protocolo de prueba de fraude de paso único sin interacción permisiva.
4. Los miembros de Rootstock Labs y Fairgate Labs han publicado el White Paper de BitVMX, similar a BitVM1, con la esperanza de simular el efecto de una CPU universal en Bitcoin script (fuera de la cadena).

Actualmente, la construcción del ecosistema de desarrolladores relacionados con BitVM está cada vez más clara, y la iteración y mejora de las herramientas periféricas también son visibles a simple vista. En comparación con el año pasado, el ecosistema de BitVM ahora es “vagamente visible” en lugar de ser un “castillo en el aire”, lo que ha atraído a un número creciente de desarrolladores y VC para ingresar al ecosistema de Bitcoin.

Pero para la mayoría de las personas, entender los términos técnicos relacionados con BitVM y la capa secundaria de Bitcoin no es tarea fácil, ya que primero debe tener un entendimiento sistemático de los conocimientos básicos circundantes, especialmente en Bitcoin scripts y antecedentes como Taproot. Hasta ahora, la información de referencia disponible en línea es o bien demasiado larga y redundante, o bien explica de manera insuficiente, lo que hace que sea difícil de entender. Nos esforzamos por abordar estos problemas, buscando ayudar a más personas a comprender los conocimientos circundantes de la capa secundaria de Bitcoin de la manera más clara posible, estableciendo un entendimiento sistemático del sistema BitVM.

MATT y Promise: 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, que se refiere principalmente al uso de la estructura de almacenamiento de datos en forma de árbol de Merkle para mostrar el proceso de ejecución de programas complejos y tratar de hacer pruebas de fraude de verificación nativa de Bitcoin.

Si bien MATT puede expresar un programa complejo y su procesamiento de datos, no publica los datos directamente BTC on-chain porque el tamaño total de los datos es muy grande. El esquema que utiliza MATT solo almacena datos en el árbol de Merkle off-chain y solo publica el resumen superior del árbol de Merkle (raíz de Merkle) en la on-chain. Hay tres pilares principales en este árbol de Merkle:

• Código de script de contrato inteligente
• Datos necesarios para el contrato
• Huella dejada por la ejecución del contrato (registro de los cambios en la memoria, CPU y registros producidos por la ejecución del contrato inteligente en EVM y otras máquinas virtuales)

Bajo la solución MATT, solo la muy pequeña Merkle Root se almacena on-chain, y el conjunto completo de datos contenido en el Árbol Merkle se almacena off-chain, que utiliza una idea llamada “compromiso”. Aquí hay una explicación de lo que es un “compromiso”.

Un compromiso es como una declaración simplificada, que podemos entender como una ‘huella dactilar’ de un gran conjunto de datos comprimidos. Por lo general, quienes publican un ‘compromiso’ en la cadena afirmarán que ciertos datos almacenados fuera de la cadena son precisos y correctos, y estos datos externos deben corresponder a una declaración simplificada, que es el ‘compromiso’.

En ocasiones, el hash de los datos puede ser considerado como un ‘compromiso’ con los propios datos, otros esquemas de compromiso incluyen compromisos KZG o árboles de Merkle. En los protocolos de prueba de fraude comunes en Layer2, el editor de datos publica el conjunto completo de datos fuera de la cadena, y hace un compromiso dentro de la cadena con respecto a los datos publicados. Si alguien encuentra datos inválidos en el conjunto de datos fuera de la cadena, se puede desafiar el compromiso de los datos en la cadena.

A través del compromiso (Commitment), la capa 2 puede comprimir y procesar grandes cantidades de datos y solo publicar su ‘compromiso’ en la cadena de bloques de Bitcoin. Por supuesto, también se debe garantizar que el conjunto completo de datos publicados fuera de la cadena de bloques pueda ser observado por el mundo exterior.

Actualmente, hay varios esquemas principales de BitVM, como BitVM0, BitVM1, BitVM2 y BitVMX, que básicamente utilizan una estructura de abstracción similar:

1. Descomposición y compromiso del programa: en primer lugar, se descompone un programa complejo en una gran cantidad de códigos de operación más básicos (compilación), y luego se registran las huellas que estos códigos de operación generan durante la ejecución concreta (básicamente, el cambio de estado completo registrado cuando un programa se ejecuta en la CPU y la memoria, denominado traza). Después, organizamos todos los datos, incluidas la traza y los códigos de operación, en un conjunto de datos y generamos un compromiso para este conjunto de datos.

Los planes de compromiso específicos pueden tomar diversas formas, como: árbol de Merkle, PIOPs (varios algoritmos ZK), funciones hash

2. Stake y pre-firma de activos: los editores de datos y los validadores necesitan bloquear una cantidad determinada de activos en cadena a través de la pre-firma, y habrá condiciones de restricción. Estas condiciones se activarán específicamente en función de las posibles situaciones futuras. Si el editor de datos actúa maliciosamente, el validador puede presentar pruebas para confiscar los activos del editor de datos.

3. Publicación de datos y compromisos: el editor de datos publica compromisos en la cadena, mientras que los datos completos se publican fuera de la cadena. Los validadores recuperan el conjunto de datos y verifican si hay algún error. Cada parte del conjunto de datos fuera de la cadena está relacionada con los compromisos en la cadena.

4. Desafíos y castigos: Una vez que el validador descubre que los datos proporcionados por el publicador de datos son incorrectos, llevará esos datos directamente a la cadena para su verificación (primero se debe dividir esta parte de los datos de manera muy fina), esta es la lógica de la prueba de fraude. Si los resultados de la verificación muestran que el publicador de datos ha proporcionado datos inválidos fuera de la cadena, sus activos serán tomados por el validador que lo desafió.

En resumen, el editor de datos Alice publica todas las huellas dejadas durante la ejecución de transacciones de segundo nivel fuera de la cadena y publica las promesas correspondientes en la cadena. Si deseas demostrar que ciertos datos son incorrectos, primero debes demostrar a los nodos de Bitcoin que estos datos están relacionados con las promesas en la cadena, es decir, que estos datos fueron publicados por Alice y luego hacer que los nodos de Bitcoin confirmen que estos datos son incorrectos.

Ahora que tenemos una comprensión general de la idea detrás de BitVM, todas las variantes de BitVM se adhieren a este paradigma básico. A continuación, comencemos a aprender y comprender algunas tecnologías importantes utilizadas en este proceso, comenzando con los scripts de Bitcoin y Taproot, así como las pre-firmas.

¿Qué es el script de Bitcoin?

El conocimiento relacionado con Bitcoin es más difícil de entender que el de Ethereum, incluso la acción más básica de transferencia implica una serie de conceptos, incluyendo UTXO (Salida de transacción no gastada), script de bloqueo (también conocido como PubKey) y script de desbloqueo (también conocido como Sig). Comencemos explicando estos conceptos principales.

(Un ejemplo de código de script de Bitcoin compuesto por códigos de operación más bajos que los de lenguajes de programación de nivel superior)

La forma en que los activos se expresan en Ethereum es más similar a Alipay o WeChat, donde cada transferencia solo implica sumar o restar el saldo de diferentes cuentas. Este enfoque se centra en las cuentas, donde el saldo de los activos es solo un número asociado a cada cuenta. Por otro lado, la forma en que se expresan los activos en Bitcoin es más similar al oro, donde cada unidad de oro (UTXO) está asociada a un propietario. Las transferencias en realidad implican destruir una UTXO antigua y generar una nueva UTXO (con un propietario diferente).

El UTXO de Bitcoin contiene dos campos clave:

Cantidad, medida en unidades de “Satoshi” (un BTC equivale a cien millones de Satoshi);

Los scripts de bloqueo, también conocidos como “claves públicas de script (PubKeys”), definen las condiciones de desbloqueo de UTXO.

Es importante tener en cuenta que la propiedad de UTXO de Bitcoin se expresa a través de scripts de bloqueo. Si desea transferir su UTXO a Sam, puede iniciar una transacción para destruir uno de sus UTXO y establecer la condición de desbloqueo del nuevo UTXO como “solo Sam puede desbloquear”.

Después, si Sam quiere usar estos Bitcoin, debe presentar un script de desbloqueo (Sig) en el que Sam debe mostrar su firma digital para demostrar que es él mismo. Si el script de desbloqueo coincide con el script de bloqueo mencionado anteriormente, Sam puede desbloquear y transferir estos Bitcoin a otra persona.

(El script de desbloqueo debe coincidir con el script de bloqueo)

Desde el punto de vista de la forma en que se presenta, cada transacción en la cadena de Bitcoin tiene múltiples entradas y salidas. En cada entrada, se debe declarar el UTXO que se desea desbloquear y se debe enviar un script de desbloqueo para desbloquear y destruir ese UTXO. En la salida, se muestra la información del nuevo UTXO generado y se revela el contenido del script de bloqueo al público.

Por ejemplo, en una entrada de transacción, demuestras que eres Sam, desbloqueas varias UTXO que te han dado, las destruyes todas juntas, luego generas varias UTXO nuevas y declaras que xxx puede desbloquearlas en el futuro.

Específicamente, en los datos de entrada de la transacción, debes declarar qué UTXO quieres desbloquear y especificar la “ubicación de almacenamiento” de estos datos UTXO. Aquí es importante tener en cuenta que Bitcoin y Ethereum son completamente diferentes. Ethereum proporciona dos tipos de cuentas, la cuenta de contrato y la cuenta EOA, para almacenar datos. El saldo de activos se registra como números en la cuenta de contrato o la cuenta EOA, y se coloca de manera unificada en una base de datos llamada “estado mundial”. Al realizar transferencias, se modifica directamente la cuenta específica desde el “estado mundial”, lo que facilita la ubicación de la ubicación de almacenamiento de los datos.

Bitcoin no tiene un diseño de estado global, los datos de activos se almacenan de forma descentralizada en bloques anteriores (es decir, datos UTXO no gastados, se almacenan individualmente en la salida de cada transacción).

Si desea desbloquear una UTXO específica, debe indicar que la información de la UTXO se encuentra en la salida de una transacción pasada, mostrando su ID (es decir, su hash) y permitiendo que los nodos de Bitcoin busquen en el historial. Si desea consultar el saldo de Bitcoin de una dirección específica, debe recorrer todos los bloques desde el principio y encontrar las UTXO no bloqueadas asociadas con la dirección xx.

Al usar la billetera Bitcoin habitualmente, puede verificar rápidamente el saldo de Bitcoin que posee cierta dirección. A menudo, esto se debe a que el servicio de la billetera escanea los bloques y crea un índice de todas las direcciones para que podamos consultarlas rápidamente.

(Cuando generas una declaración de transacción para enviar tus propias UTXO a otra persona, debes marcar la posición de esta UTXO en el historial de Bitcoin según el hash/ID de transacción al que pertenecen estas UTXO)

Interesantemente, el resultado de las transacciones de Bitcoin se calcula fuera de la cadena, cuando los usuarios generan transacciones en dispositivos locales, deben crear directamente tanto las entradas como las salidas, lo que equivale a completar el cálculo de los resultados de la transacción. La transacción se transmite a la red de Bitcoin, se verifica por los nodos y luego se incluye en la cadena. Este modelo de “cálculo fuera de la cadena - verificación en la cadena” es completamente diferente al de Ethereum, donde solo necesitas proporcionar parámetros de entrada de transacción, y los nodos de Ethereum calculan y generan la salida de la transacción.

Además, el script de bloqueo (Locking) de UTXO es personalizable, puedes establecer UTXO como “desbloqueable por el propietario de una dirección de Bitcoin”, y el propietario de esa dirección debe proporcionar una firma digital y una llave pública (P2PKH). En el tipo de transacción Pay-to-Hash (P2SH), puedes agregar un Hash en el script de bloqueo de UTXO, y quien pueda proporcionar el script de imagen original correspondiente a ese Hash y cumpla con las condiciones preestablecidas en ese script de imagen original, puede desbloquear UTXO. El script Taproot en el que BitVM se basa utiliza características similares a P2SH.

¿Cómo se desencadena el script de Bitcoin?

Aquí vamos a usar P2PKH como ejemplo para explicar cómo se activa el script de Bitcoin. Sólo cuando se entiende cómo se activa este script se puede entender el más complejo Taproot y BitVM. P2PKH significa “Pay to Public Key Hash”. En este caso, el script de bloqueo de UTXO establecerá un hash de clave pública, y al desbloquear se debe proporcionar la clave pública correspondiente a ese hash, lo cual es básicamente similar al enfoque convencional de transferencia de Bitcoin.

En este punto, los nodos de Bitcoin deben asegurarse de que la clave pública en el script de desbloqueo coincida con el hash de la clave pública especificado en el script de bloqueo, es decir, asegurarse de que la “llave” presentada por la persona que desbloquea coincida con la “cerradura” predefinida en la UTXO.

Además, en el esquema P2PKH, después de recibir la transacción, el nodo de Bitcoin concatenará la firma de script de desbloqueo proporcionada por el usuario con el script de bloqueo pubKey del UTXO que se debe desbloquear, y lo ejecutará en el entorno de ejecución de scripts de BTC. La siguiente imagen muestra el resultado de concatenación antes de la ejecución:

Es posible que los lectores no estén familiarizados con el entorno de ejecución de scripts de BTC, así que aquí hacemos una introducción básica. En primer lugar, el script de BTC consta de dos elementos:

Datos y códigos de operación. Estos datos y códigos de operación se empujan en la pila en orden de izquierda a derecha y se ejecutan según la lógica especificada, obteniendo el resultado final (sobre qué es una pila, no se explica aquí. Los lectores pueden investigar por su cuenta).

En el ejemplo anterior, el lado izquierdo es el script de desbloqueo Sig subido por alguien, que incluye su firma digital y su clave pública, mientras que en el script de bloqueo Pubkey del lado derecho, incluye un segmento de códigos de operación y datos establecidos por el creador de UTXO al crear ese UTXO (aquí no necesitamos entender el significado de cada código de operación, solo comprenderlo aproximadamente).

Los códigos de operación DUP, HASH160, EQUALVERIFY, etc. en el script de bloqueo en el lado derecho de la figura son responsables de tomar la clave pública llevada en el script de desbloqueo en el lado izquierdo y hacer un hash, luego compararlo con el hash de la clave pública predefinida en el script de bloqueo. Si son iguales, significa que la clave pública enviada en el script de desbloqueo coincide con el hash de clave pública predefinido en el script de bloqueo, lo que pasa la primera validación.

Sin embargo, existe el problema de que el contenido del script de bloqueo de UTXO es en realidad on-chain público, y cualquiera puede observar el Llave pública hash contenido en él, y cualquiera puede cargar el Llave pública correspondiente y mentir que es el que está “designado”. Por lo tanto, después de verificar la clave pública y el hash de clave pública, es necesario verificar si el iniciador de la transacción es realmente el controlador real de la clave pública, lo que requiere la 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, en el esquema P2PKH, el script de desbloqueo presentado por el remitente de la transacción debe contener la firma digital y la clave pública, esta clave pública debe coincidir con el hash de la clave pública especificada en el script de bloqueo, y la firma digital de la transacción debe ser correcta para que se desbloquee el UTXO con éxito.

（Esta imagen es dinámica: diagrama esquemático del script de desbloqueo de Bitcoin en el esquema P2PKH

Fuente: ** )

Por supuesto, la red de Bitcoin admite varios tipos de transacciones, no solo Pay to public key/public key hash, sino también P2SH (Pay to hash), todo depende de cómo se configure el script de bloqueo personalizado al crear UTXO.

Aquí hay que tener en cuenta que, en el caso del esquema P2SH, se puede predefinir un Hash en el script de bloqueo, mientras que el script de desbloqueo debe presentar completamente el contenido del script correspondiente al Hash. Un nodo de Bitcoin puede ejecutar este script, y si este script define la lógica de verificación de múltiples firmas, se puede lograr el efecto de una billetera multifirma en la cadena de bloques de Bitcoin.

Por supuesto, bajo el esquema P2SH, el creador de UTXO debe hacer que la persona que desbloqueará UTXO en el futuro sepa de antemano el contenido del script correspondiente al hash. Si ambas partes conocen este contenido, podemos implementar lógica empresarial más compleja que la de la firma múltiple.

Aquí hay que aclarar que Bitcoin on-chain (Bloquear) no registra directamente qué UTXO y qué direcciones están asociadas. Solo registra qué UTXO puede desbloquear qué hash de clave pública / hash de script, pero podemos calcular rápidamente la dirección correspondiente según el hash de la clave pública / hash del script (la parte que se muestra como caracteres aleatorios en la interfaz de la billetera).

La razón por la que podemos ver la cantidad de Bitcoin en la interfaz del explorador de bloques y la billetera bajo la dirección xx es porque el proyecto del explorador de bloques y la billetera te ayudan a analizar estos datos, escaneando todos los bloques y calculando la ‘dirección’ correspondiente según el hash del script de bloqueo/cripto hash declarado en la clave pública, luego muestran cuántos Bitcoin hay bajo la dirección xx.

SegWit y Witness

Cuando comprendamos el concepto de P2SH, estaremos un paso más cerca de Taproot, en el que BitVM se basa. Pero antes de eso, debemos entender un concepto importante: Witness y Segregated Witness.

Al revisar los scripts de desbloqueo y bloqueo, así como el proceso de desbloqueo de UTXO mencionado anteriormente, se puede encontrar un problema: la firma digital de la transacción se incluye en el script de desbloqueo, y al generar la firma digital no se puede sobrescribir el script de desbloqueo (los parámetros utilizados para generar la firma digital no pueden incluir la firma en sí misma), por lo tanto, la firma digital solo puede cubrir la parte fuera del script de desbloqueo, es decir, solo puede establecer una relación con la parte principal de los datos de la transacción, no puede cubrir completamente los datos de la transacción.

De esta manera, incluso si el script de desbloqueo de la transacción es manipulado ligeramente por un intermediario, no afectará el resultado de la verificación. Por ejemplo, un nodo de Bitcoin o un pool de minería puede insertar otros datos en el script de desbloqueo de la transacción, lo que hace que los datos de la transacción cambien ligeramente sin afectar la verificación y el resultado de la transacción, y el hash/ID de la transacción calculado al final también cambiará. Esto se conoce como el problema de la maleabilidad de la transacción.

El inconveniente de esto es que si planeas realizar varias transacciones consecutivas y hay una dependencia de orden (por ejemplo, la transacción 3 hace referencia a la salida de la transacción 2, la transacción 2 hace referencia a la salida de la transacción 1), entonces las transacciones posteriores deben hacer referencia al ID (hash) de la transacción anterior. El pool de minería o cualquier intermediario puede ajustar el contenido del script de desbloqueo, lo que hace que el hash de la transacción después de ser enviada a la cadena no coincida con lo que esperabas, por lo que tus múltiples transacciones relacionadas en orden previamente creadas fallarán.

De hecho, en el caso de los puentes DLC y BitVM2, se construirán lotes de transacciones con secuencias relacionadas, por lo que los escenarios mencionados anteriormente no son poco comunes.

En resumen, el problema de la escalabilidad de las transacciones se debe a que la identificación/hash de la transacción incluye los datos del script de desbloqueo durante el cálculo, y los intermediarios como los nodos de Bitcoin pueden ajustar ligeramente el contenido del script de desbloqueo, lo que hace que la identificación de la transacción no coincida con las expectativas del usuario. En realidad, esto es una carga histórica dejada por el diseño inicial de Bitcoin que no fue considerado adecuadamente.

La actualización posterior, SegWit, en realidad separa por completo la identificación de la transacción (ID) y el script de desbloqueo, por lo que no es necesario incluir los datos del script de desbloqueo al calcular el hash de la transacción. El script de bloqueo UTXO que cumple con la actualización SegWit establecerá automáticamente un código de operación llamado “OP_0” en la primera posición como una marca; mientras que el script de desbloqueo correspondiente, se renombró de Sig a Witness (testigo).

Siguiendo las reglas de SegWit, los problemas de escalabilidad de las transacciones se resolverán adecuadamente, por lo que no es necesario preocuparse por que los datos de las transacciones enviados a los nodos de Bitcoin sean ajustados. Por supuesto, no necesitamos complicar demasiado las cosas, ya que la funcionalidad de P2WSH no difiere en esencia de la de P2SH discutida anteriormente. Puede predefinir un hash de script en el script de bloqueo del UTXO y esperar a que el remitente del script de desbloqueo envíe y ejecute el contenido del script correspondiente al hash en la cadena.

Pero si el script que deseas implementar es especialmente grande, con una gran cantidad de código, no podrás enviar el script completo a la cadena de bloques de Bitcoin de forma convencional (hay un límite de tamaño en cada bloque). ¿Entonces qué hacer? Esto requiere el uso de Taproot, que simplifica el contenido del script para la cadena, y BitVM es precisamente un esquema complejo construido sobre Taproot.