Resumen:

Delphi Digital lanzó recientemente un informe titulado 'El Amanecer de la Programabilidad de Bitcoin: Abriendo el Camino para Rollups', que describe conceptos clave relacionados con Bitcoin Rollups, incluyendo la suite BitVM, las restricciones OP_CAT y Covenant, la capa DA del ecosistema de Bitcoin, puentes y cuatro soluciones principales de Capa 2 que utilizan BitVM: Bitlayer, Citrea, Yona y Bob. Si bien el informe proporciona una visión general de la tecnología de Capa 2 de Bitcoin, sigue siendo bastante general y carece de descripciones detalladas, lo que lo hace algo difícil de entender. Geek Web3 amplió el informe de Delphi para ayudar a más personas a comprender sistemáticamente tecnologías como BitVM.

Trabajaremos con el equipo de investigación de Bitlayer y la comunidad china de BitVM para lanzar una serie llamada 'Aproximándonos a BTC'. Esta serie se centrará en temas clave como BitVM, OP_CAT y los puentes cruzados de Bitcoin, con el objetivo de desmitificar las tecnologías de la Capa 2 de Bitcoin para una audiencia más amplia y allanar el camino para más entusiastas.

Hace unos meses, Robin Linus, el líder de ZeroSync, publicó un artículo titulado "BitVM: Compute Anything on Bitcoin", presentando oficialmente el concepto de BitVM e impulsando la tecnología de capa 2 de Bitcoin. Esta se considera una de las innovaciones más revolucionarias en el ecosistema de Bitcoin, que despierta un interés y una actividad significativos en el espacio de la capa 2 de Bitcoin. Ha atraído proyectos notables como Bitlayer, Citrea y BOB, trayendo nueva energía al mercado. Desde entonces, más investigadores se han unido para mejorar BitVM, lo que ha dado lugar a varias versiones iterativas como BitVM1, BitVM2, BitVMX y BitSNARK. El panorama general es el siguiente:

1. Robin Linus presentó inicialmente el documento técnico de implementación de BitVM el año pasado, que se basa en un circuito conceptual de compuertas lógicas y se conoce como BitVM0.
2. En presentaciones y entrevistas posteriores, Robin Linus presentó informalmente un concepto de BitVM basado en una CPU teórica, denominada BitVM1. Esto es similar al sistema de prueba de fraude Cannon de Optimism, y puede simular el efecto de una CPU de propósito general fuera de la cadena utilizando scripts de Bitcoin.
3. Robin Linus también propuso BitVM2, un protocolo de prueba de fraude no interactivo de un solo paso sin permisos.
4. Los miembros de Rootstock Labs y Fairgate Labs publicaron un documento técnico sobre BitVMX. Similar a BitVM1, su objetivo es simular el efecto de una CPU de propósito general fuera de la cadena utilizando scripts de Bitcoin.

En la actualidad, la construcción del ecosistema de desarrolladores relacionados con BitVM se está volviendo 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 de hoy se ha vuelto "vagamente visible" desde el inicial "castillo en el aire", lo que también ha atraído a más y más personas. Más desarrolladores y VCs se están lanzando al ecosistema de Bitcoin.

Para la mayoría de las personas, entender BitVM y los términos técnicos relacionados con la Capa 2 de Bitcoin no es fácil. Requiere un dominio sistemático del conocimiento fundamental, especialmente scripts de Bitcoin y Taproot. Los recursos en línea existentes a menudo son demasiado extensos y llenos de detalles irrelevantes o demasiado breves para ser claros. Nuestro objetivo es resolver estos problemas utilizando un lenguaje claro y conciso para ayudar a más personas a comprender los conceptos fundamentales de la Capa 2 de Bitcoin y construir una comprensión integral del sistema BitVM.

MATT y Compromisos: El Concepto Principal de BitVM

El concepto central de BitVM gira en torno a MATT, que significa Merkleize All The Things. Este enfoque utiliza un Árbol de Merkle, una estructura jerárquica de almacenamiento de datos, para representar la ejecución de programas complejos. Su objetivo es permitir la verificación nativa de pruebas de fraude en la red Bitcoin. MATT puede capturar los detalles de un programa complejo y sus actividades de procesamiento de datos, pero no publica estos extensos datos directamente en la cadena de bloques de Bitcoin debido a su gran tamaño. En cambio, el enfoque MATT almacena estos datos en un árbol de Merkle fuera de la cadena y solo publica la Raíz de Merkle (el resumen superior del árbol de Merkle) en la cadena de bloques. El árbol de Merkle contiene principalmente tres componentes clave:

• Código de script de contrato inteligente
• Datos requeridos para el contrato
• Rastros de ejecución del contrato (registros de cambios en la memoria y registros de la CPU durante la ejecución de contratos inteligentes en máquinas virtuales como EVM)

(Un diagrama esquemático simple del Árbol de Merkle. Su Raíz de Merkle se calcula a partir de los 8 fragmentos de datos en la parte inferior de la imagen a través de un hash de varias capas)

Bajo el esquema MATT, solo se almacena en la cadena la raíz de Merkle extremadamente pequeña, y el conjunto de datos completo contenido en el árbol de Merkle se almacena fuera de la cadena. Esto utiliza una idea llamada 'compromiso'. Aquí tienes una explicación de qué es 'Compromiso'.

Una promesa es como una declaración sucinta, podemos entenderla como la “huella dactilar” obtenida después de comprimir una gran cantidad de datos. En general, 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 propios datos. Otros esquemas de compromiso incluyen el compromiso KZG o el Árbol de Merkle. En el protocolo de prueba de fraude habitual de la Capa2, el editor de datos publicará el conjunto completo de datos fuera de la cadena y un compromiso de publicar el conjunto de datos en la cadena. Si alguien descubre datos inválidos en el conjunto de datos fuera de la cadena, se cuestionará el compromiso de datos en la cadena.

A través del compromiso, la segunda capa puede comprimir una gran cantidad de datos y solo publicar su "compromiso" en la cadena de Bitcoin. Por supuesto, también es necesario asegurar que el conjunto de datos completo publicado fuera de la cadena pueda ser observado por el mundo exterior.

Actualmente, los principales esquemas de BitVM como BitVM0, BitVM1, BitVM2 y BitVMX siguen todos una estructura abstracta similar:

1. Descomposición del programa y compromiso: Inicialmente, un programa complejo se descompone en numerosos opcodes básicos (compilación). Las trazas de ejecución de estos opcodes (básicamente, los cambios de estado cuando un programa se ejecuta en la CPU y la memoria, conocidos como Trace) se registran. Todos los datos, incluidos el Trace y los opcodes, se organizan en un conjunto de datos, y se genera un compromiso para este conjunto de datos. Se pueden utilizar diversos esquemas de compromiso, como árboles Merkle, PIOPs (varios algoritmos ZK) y funciones hash.
2. Staking de activos y pre-firma: El editor de datos y el verificador deben bloquear una cierta cantidad de activos en la cadena de bloques a través de una pre-firma, con condiciones restrictivas específicas. Estas condiciones desencadenan acciones para eventos futuros potenciales. Si el editor de datos actúa maliciosamente, el verificador puede presentar pruebas y tomar los activos del editor de datos.
3. Publicación de Datos y Compromisos: El editor de datos publica el compromiso en la cadena y el conjunto de datos completo fuera de la cadena. El verificador recupera y verifica el conjunto de datos en busca de errores. Cada parte del conjunto de datos fuera de la cadena está vinculada al compromiso en la cadena.
4. Desafío y Penalización: Si el verificador encuentra errores en los datos proporcionados por el editor de datos, traen esta parte de los datos a la cadena para su verificación directa (requiriendo datos detallados con precisión). Este proceso sigue la lógica de las pruebas de fraude. Si se confirma que los datos son inválidos, los activos del editor de datos serán tomados por el verificador desafiante. En resumen, el editor de datos, Alice, revela todas las trazas generadas durante la ejecución de transacciones de Capa 2 fuera de la cadena y publica el compromiso correspondiente en la cadena. Para demostrar que una parte de los datos es incorrecta, primero debes mostrar al nodo Bitcoin que estos datos están relacionados con el compromiso en la cadena, confirmando que fue revelado por Alice, y luego el nodo Bitcoin verifica la precisión de los datos. Habiendo entendido la idea general de BitVM, todas las variantes de BitVM se adhieren a este paradigma básico. A continuación, profundizaremos en algunas tecnologías clave utilizadas en este proceso, comenzando con los fundamentos de los scripts de Bitcoin, Taproot y pre-firmas.

¿Qué es Bitcoin Script?

Comprender Bitcoin puede ser más desafiante que Ethereum, ya que incluso las transacciones más simples implican varios conceptos clave. Estos incluyen UTXO (Salida de Transacción No Gastada), scripts de bloqueo (también conocidos como ScriptPubKey) y scripts de desbloqueo (también conocidos como ScriptSig). Comencemos desglosando estos conceptos fundamentales primero.

(Una muestra de código de script de Bitcoin consiste en opcodes de nivel inferior en comparación con lenguajes de alto nivel) El método de representación de activos de Ethereum es similar a sistemas como Alipay o WeChat, donde cada transacción simplemente ajusta los saldos de diferentes cuentas. Este enfoque basado en cuentas trata los saldos de activos como simples números asociados con cuentas. En cambio, la representación de activos de Bitcoin es más como tratar con oro, donde cada pieza de oro (UTXO) está etiquetada con un propietario. Una transacción de Bitcoin básicamente destruye el antiguo UTXO y crea uno nuevo, con el cambio de propiedad en el proceso. Un UTXO de Bitcoin incluye dos componentes clave:

• Cantidad: Medido en "satoshis" (un BTC equivale a cien millones de satoshis);
• Script de bloqueo (ScriptPubKey): Esto define las condiciones necesarias para desbloquear el UTXO. La propiedad del UTXO de Bitcoin está determinada por el script de bloqueo. Por ejemplo, si quieres transferir tu UTXO a Sam, iniciarías una transacción que destruye tu UTXO y crea uno nuevo con la condición de 'solo Sam puede desbloquear'. Cuando Sam quiere usar estos bitcoins, debe enviar un script de desbloqueo (ScriptSig). En este script, Sam proporciona su firma digital para demostrar su identidad. Si el script de desbloqueo coincide con el script de bloqueo original, Sam puede desbloquear los bitcoins y transferirlos a otra persona.

(El script de desbloqueo debe coincidir con el script de bloqueo) En las transacciones de Bitcoin, cada transacción consta de múltiples entradas y salidas. Cada entrada especifica un UTXO para desbloquear y proporciona un script de desbloqueo para hacerlo, que luego desbloquea y destruye el UTXO. Las salidas de la transacción muestran los UTXOs recién creados y muestran públicamente los scripts de bloqueo asociados. Por ejemplo, en la Entrada de una transacción, demuestras que eres Sam desbloqueando múltiples UTXOs que otros te han enviado, destruyéndolos en el proceso. Luego, creas varios nuevos UTXOs y especificas que xxx puede desbloquearlos en el futuro.

Específicamente, en los datos de entrada de una transacción, es necesario declarar qué UTXOs se pretende desbloquear y especificar la "ubicación de almacenamiento" de estos datos UTXO. Es importante entender que Bitcoin y Ethereum manejan esto de manera diferente. Ethereum utiliza cuentas de contrato y cuentas poseídas externamente (EOAs) para almacenar datos, con saldos de activos registrados como números en estas cuentas. Toda esta información se almacena en una base de datos llamada el "estado del mundo". Cuando ocurre una transacción, el "estado del mundo" actualiza directamente los saldos de cuentas específicas, facilitando la ubicación de los datos. En contraste, Bitcoin no tiene un "estado del mundo". En su lugar, los datos de activos se distribuyen a través de bloques anteriores como UTXOs no gastados, almacenados individualmente en la salida de cada transacción.

Si desea desbloquear cierto UTXO, debe indicar en qué Salida de transacción existe la información UTXO en el pasado y mostrar el ID de la transacción (que es su hash). Deje que el nodo Bitcoin lo busque en la historia. Si desea consultar el saldo de Bitcoin de cierta dirección, debe recorrer todos los bloques desde el principio para encontrar el UTXO desbloqueado asociado con la dirección xx.

Cuando suele usar una billetera Bitcoin, puede verificar rápidamente el saldo de Bitcoin propiedad de cierta dirección. Esto se debe a menudo a que el propio servicio de billetera indexa todas las direcciones escaneando bloques, lo que nos facilita realizar consultas rápidamente.

(Cuando creas una transacción para transferir tu UTXO a otra persona, debes especificar la ubicación de ese UTXO en el historial de transacciones de Bitcoin haciendo referencia al hash/ID de transacción al que pertenece.) 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 todas las entradas y salidas de antemano, calculando efectivamente las salidas de la transacción. La transacción se transmite luego a la red de Bitcoin, es verificada por nodos y se agrega a la cadena de bloques. Este modelo de "cálculo fuera de la cadena - verificación en la cadena" es completamente diferente al de Ethereum. En Ethereum, solo necesitas proporcionar los parámetros de entrada de la transacción, y los resultados de la transacción son calculados y generados por los nodos de Ethereum. Además, el script de bloqueo de un UTXO puede ser personalizado. Puedes establecer un UTXO para que sea "desbloqueable por el propietario de una dirección de Bitcoin específica", lo que requiere que el propietario proporcione una firma digital y una clave pública (P2PKH). En las transacciones de Pago a Script Hash (P2SH), puedes agregar un Hash de Script al script de bloqueo del UTXO. Cualquiera que pueda enviar el script correspondiente a este hash y cumplir con las condiciones especificadas en el script puede desbloquear el UTXO. El script Taproot, en el que BitVM confía, utiliza características similares a las de P2SH.

Cómo activar el script de Bitcoin

Para comprender el mecanismo desencadenante de los scripts de Bitcoin, comenzaremos con el ejemplo P2PKH, que significa "Pagar a la Clave Pública Hash". En esta configuración, el script de bloqueo de un UTXO contiene un hash de clave pública, y para desbloquearlo, se debe proporcionar la clave pública correspondiente. Este mecanismo se alinea con el proceso estándar de transacciones de Bitcoin. En este contexto, un nodo de Bitcoin debe verificar que la clave pública en el script de desbloqueo coincida con el hash de clave pública especificado en el script de bloqueo. Básicamente, comprueba que la "clave" proporcionada por el usuario encaje en el "bloqueo" establecido por el UTXO. Con más detalle, bajo el esquema P2PKH, cuando un nodo de Bitcoin recibe una transacción, combina el script de desbloqueo del usuario (ScriptSig) con el script de bloqueo (ScriptPubKey) del UTXO a desbloquear y luego ejecuta este script combinado en el entorno de ejecución de scripts de Bitcoin. La imagen a continuación ilustra el resultado concatenado antes de la ejecución:

Es posible que los lectores no estén familiarizados con el entorno de ejecución de scripts BTC, así que vamos a presentarlo brevemente. Los scripts de Bitcoin constan de dos elementos: datos y códigos de operación. Estos elementos se insertan en una pila secuencialmente de izquierda a derecha y se ejecutan de acuerdo con la lógica especificada para producir el resultado final (para una explicación de lo que es una pila, los lectores pueden consultar ChatGPT). En el ejemplo anterior, el lado izquierdo muestra el script de desbloqueo (ScriptSig) proporcionado por alguien, que incluye su firma digital y clave pública. En la parte derecha se muestra el script de bloqueo (ScriptPubKey), que contiene una serie de códigos de operación y datos establecidos por el creador de UTXO al generar ese UTXO (basta con entender la idea general; no es necesario profundizar en el significado de cada código de operación). Los códigos de operación de la secuencia de comandos de bloqueo del lado derecho, como DUP, HASH160 y EQUALVERIFY, aplican un hash a la clave pública de la secuencia de comandos de desbloqueo del lado izquierdo y la comparan con el hash de clave pública preestablecido en la secuencia de comandos de bloqueo. Si coinciden, confirma que la clave pública en el script de desbloqueo coincide con el hash de clave pública en el script de bloqueo, pasando la primera verificación. Sin embargo, hay un problema: el contenido del script de bloqueo es visible públicamente en la cadena de bloques, lo que significa que cualquiera puede ver el hash de la clave pública. Por lo tanto, cualquiera podría enviar la clave pública correspondiente y afirmar falsamente que es la persona autorizada. Para solucionar esto, después de verificar la clave pública y el hash de clave pública, el sistema también debe verificar si el iniciador de la transacción controla realmente la clave pública, lo que implica verificar la firma digital. El código de operación CHECKSIG en el script de bloqueo maneja esta verificación. En resumen, bajo el esquema P2PKH, el script de desbloqueo del iniciador de la transacción debe incluir 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 debe ser correcta. Estas condiciones deben cumplirse para desbloquear correctamente el UTXO.

(Esta es una ilustración dinámica: Un diagrama de scripts de desbloqueo de Bitcoin bajo el esquema P2PKH
Fuente:https://learnmeabitcoin.com/technical/script)

Es importante tener en cuenta que la red Bitcoin admite varios tipos de transacciones más allá de Pagar a Clave Pública/Hash de Clave Pública, como P2SH (Pagar a Hash de Script). El tipo específico de transacción depende de cómo se configure el script de bloqueo cuando se crea el UTXO.

Es importante entender que bajo el esquema P2SH, el script de bloqueo puede preestablecer un Script Hash, y el script de desbloqueo debe proporcionar el contenido completo del script que corresponde a este Script Hash. El nodo Bitcoin puede entonces ejecutar este script, y si incluye lógica de verificación de multi-firma, efectivamente habilita billeteras de multi-firma en la cadena de bloques de Bitcoin. En el esquema P2SH, el creador de UTXO necesita informar a la persona que desbloqueará la UTXO en el futuro sobre el contenido del script correspondiente al Script Hash. Si ambas partes son conscientes del contenido del script, podemos implementar una lógica empresarial aún más compleja que solo la multi-firma. También es importante señalar que la cadena de bloques de Bitcoin no registra directamente qué UTXOs están vinculados a qué direcciones. En cambio, registra qué UTXOs pueden ser desbloqueados por qué hash de clave pública o hash de script. Sin embargo, podemos derivar rápidamente la dirección correspondiente (la cadena de caracteres que parece un galimatías mostrado en las interfaces de la billetera) a partir del hash de clave pública o hash de script.

La razón por la que puedes ver la cantidad de Bitcoin asociada a una dirección específica en exploradores de bloques e interfaces de monedero es que estos servicios analizan e interpretan los datos de la cadena de bloques por ti. Escanean todos los bloques y, basándose en el hash de clave pública o el hash de script declarado en los scripts de bloqueo, calculan la correspondiente “dirección”. Esto les permite mostrar cuánto Bitcoin está asociado con esa dirección.

Testigo Segregado y Testigo

Comprender P2SH nos acerca a Taproot, un componente crucial para BitVM. Sin embargo, antes de adentrarnos en Taproot, es esencial comprender el concepto de Testigo y Testigo Segregado (SegWit). Revisar los scripts de desbloqueo y bloqueo, así como el proceso de desbloqueo de UTXO, destaca un problema: la firma digital de una transacción se incluye en el script de desbloqueo. Al generar esta firma, el propio script de desbloqueo no puede formar parte de los datos firmados (ya que los parámetros utilizados para generar la firma no pueden incluir la firma en sí misma).

En consecuencia, la firma digital solo puede cubrir partes de los datos de transacción fuera del script de desbloqueo, lo que significa que no puede proteger completamente todos los datos de transacción. Esto conduce a una vulnerabilidad donde un intermediario puede modificar ligeramente el script de desbloqueo sin afectar la verificación de la firma. Por ejemplo, los nodos de Bitcoin o las piscinas mineras podrían insertar datos adicionales en el script de desbloqueo. Aunque esta alteración no afecta la verificación y el resultado de la transacción, cambia ligeramente los datos de la transacción, lo que a su vez altera el hash de transacción / ID de transacción calculado. Este problema se conoce como maleabilidad de la transacción.

El problema con esto es que si planeas iniciar múltiples transacciones secuenciales que dependen entre sí (por ejemplo, la transacción 3 hace referencia a la salida de la transacción 2, y la transacción 2 hace referencia a la salida de la transacción 1), las transacciones subsiguientes deben hacer referencia a los hashes de las transacciones precedentes. Cualquier intermediario, como un grupo minero o un nodo de Bitcoin, puede hacer ligeras modificaciones al script de desbloqueo, lo que provoca que el hash de la transacción difiera de tu expectativa una vez que esté en la cadena de bloques.

Esta discrepancia puede invalidar su secuencia preplanificada de transacciones interdependientes. Este problema es particularmente relevante en el contexto de los puentes de DLC y BitVM2, donde se construyen lotes de transacciones secuencialmente relacionadas, lo que hace que tales escenarios sean bastante comunes.

En términos simples, el problema de maleabilidad de la transacción se produce porque el cálculo del ID de transacción/hash incluye datos del script de desbloqueo. Los intermediarios, como los nodos de Bitcoin, pueden realizar ligeras modificaciones en el script de desbloqueo, lo que da como resultado un ID de transacción que no coincide con las expectativas del usuario. Este problema se debe a las primeras limitaciones de diseño de Bitcoin. La actualización de testigo segregado (SegWit) soluciona este problema desacoplando el identificador de transacción del script de desbloqueo. Con SegWit, el cálculo del hash de la transacción excluye los datos del script de desbloqueo. Los scripts de bloqueo UTXO en SegWit comienzan con un código de operación "OP_0" como marcador, y el script de desbloqueo correspondiente cambia de nombre de SigScript a Witness.

Al adherirse a las reglas de Testigo Separado (SegWit), el problema de maleabilidad de transacciones se resuelve de manera efectiva, eliminando preocupaciones sobre la manipulación de datos de transacciones por nodos de Bitcoin. La funcionalidad de P2WSH (Pagar a Script de Testigo Hash) es esencialmente la misma que la de P2SH (Pagar a Script Hash). Puede preestablecer un hash de script en el script de bloqueo de UTXO, y la persona que envía el script de desbloqueo proporcionará el contenido de script correspondiente a la cadena para su ejecución. Sin embargo, si el contenido del script que necesita es muy grande y contiene mucho código, los métodos convencionales pueden no permitirle enviar el script completo a la cadena de bloques de Bitcoin (debido a los límites de tamaño de bloque). En tales casos, entra en juego Taproot. Taproot permite la compresión del contenido de script en cadena, lo que hace posible manejar scripts más grandes. BitVM aprovecha Taproot para construir soluciones más complejas. En el próximo artículo de nuestra serie “Aproximándonos a BTC”, proporcionaremos explicaciones detalladas sobre Taproot, pre-firma y otras tecnologías avanzadas relacionadas con BitVM. ¡Estén atentos!

Descargo de responsabilidad:

1. Este artículo está reimpreso de [Geek Web3] , con derechos de autor pertenecientes a los autores originales [Nickqiao & Faust & Shew Wang]. Si hay alguna objeción a la reimpresión, por favor contacta al Gate Learnequipo, y el equipo lo procesará rápidamente según los procedimientos relevantes.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las de los autores y no constituyen ningún consejo de inversión.
3. Otras versiones del artículo han sido traducidas por el equipo de Gate Learn. Sin mencionarGate.io, los artículos traducidos no deben ser copiados, difundidos o plagiados.