TL; DR

Introducción

Este artículo proporciona una interpretación del documento técnico de BitVM, explicando el enfoque de BitVM: Los datos no necesitan estar en la cadena inicialmente; se publica y almacena fuera de la cadena, con solo un compromiso almacenado en la cadena de bloques.

Título del artículo original reenviado: Una interpretación simplificada de BitVM: Cómo verificar las pruebas de fraude en la cadena de bloques de BTC (ejecución de EVM u otros códigos de operación de VM)

Prefacio: Actualmente, la capa 2 de Bitcoin se ha convertido en una tendencia, con docenas de proyectos que se identifican a sí mismos como "capa 2 de Bitcoin". Muchos de estos, que afirman ser "Rollups", afirman que están utilizando el enfoque propuesto en el documento técnico de BitVM, posicionando a BitVM como una parte destacada del ecosistema de Bitcoin.

Sin embargo, la mayor parte de la literatura existente sobre BitVM no explica sus principios en términos sencillos. Este artículo, basado en nuestra lectura del documento técnico de BitVM de 8 páginas y después de consultar recursos relacionados con Taproot, árboles MAST y Bitcoin Script, ofrece un resumen simplificado. Para ayudar a la comprensión, hemos modificado algunas expresiones de las que se encuentran en el documento técnico de BitVM, asumiendo que el lector tiene algún conocimiento de la Capa 2 y puede comprender la idea básica de "pruebas de fraude".

El concepto preliminar de BitVM se puede resumir en unas pocas frases: elimina la necesidad de datos en cadena, publicando y almacenando inicialmente datos fuera de la cadena, con solo un compromiso almacenado en la cadena de bloques. En casos de impugnación o prueba de fraude, solo se incorporan a la cadena los datos necesarios para demostrar su asociación con el Compromiso en la cadena de bloques. Posteriormente, la red principal de BTC verifica los datos en cadena para detectar cualquier problema y si el productor de datos (el nodo que procesa las transacciones) ha participado en actividades maliciosas. Este enfoque se adhiere al principio de la navaja de Occam: "Las entidades no deben multiplicarse innecesariamente" (si puede estar fuera de la cadena, manténgalo fuera de la cadena).

Texto principal: El llamado esquema de verificación a prueba de fraude de la cadena de bloques de BTC basado en BitVM, en términos sencillos:

1. En primer lugar, una computadora / procesador es un sistema de entrada y salida compuesto por una gran cantidad de circuitos de puerta lógica. Una de las ideas centrales de BitVM es utilizar Bitcoin Script para simular los efectos de entrada-salida de los circuitos de puerta lógica. Siempre que se puedan simular los circuitos de la puerta lógica, en teoría, se puede lograr una máquina de Turing, completando todas las tareas computables. Esto significa que si tiene suficientes recursos y mano de obra, puede reunir un equipo de ingenieros para simular primero los circuitos de puerta lógica utilizando el código rudimentario de Bitcoin Script, y luego usar una gran cantidad de circuitos de puerta lógica para implementar las funcionalidades de EVM o WASM.

(Esta captura de pantalla es de un juego educativo: "Turing Complete", donde el contenido principal es construir un procesador de CPU completo, especialmente usando circuitos de puerta lógica como las puertas NAND).

Algunos han comparado el enfoque de BitVM con la construcción de un procesador M1 en "Minecraft" utilizando circuitos de redstone. O es similar a construir el Empire State Building en Nueva York con bloques de LEGO.

(Se dice que alguien pasó un año construyendo un "procesador" en "Minecraft").

1. Entonces, ¿por qué usar Bitcoin Script para simular EVM o WASM? ¿No es muy engorroso? La razón es que la mayoría de las soluciones de capa 2 de Bitcoin a menudo optan por admitir lenguajes de alto nivel como Solidity o Move, mientras que el único lenguaje que actualmente puede ejecutarse directamente en la cadena de bloques de Bitcoin es Bitcoin Script. Este lenguaje es primitivo, compuesto por un montón de códigos de operación únicos, y no es Turing completo.

(Un ejemplo de código Bitcoin Script)

Si la Capa 2 de Bitcoin tiene como objetivo verificar las pruebas de fraude en la Capa 1, como las soluciones de la Capa 2 de Ethereum, como Arbitrum, para heredar en gran medida la seguridad de BTC, necesita verificar directamente "una transacción en disputa" o "un código de operación en disputa" en la cadena de bloques de BTC. Esto significa que los códigos de operación del lenguaje Solidity / EVM utilizados por la Capa 2 deben volver a ejecutarse en la cadena de bloques de Bitcoin. El reto se reduce a:

Usando Bitcoin Script, un lenguaje de programación nativo pero rudimentario de Bitcoin, para lograr los efectos de EVM u otras máquinas virtuales.

Por lo tanto, desde la perspectiva de los principios de compilación, el enfoque de BitVM traduce los códigos de operación EVM / WASM / JavaScript en códigos de operación de Bitcoin Script, con circuitos de puerta lógica que sirven como una representación intermedia (IR) entre los "códigos de operación de EVM > códigos de operación de Bitcoin Script".

(El documento técnico de BitVM analiza el enfoque general para ejecutar ciertas "instrucciones en disputa" en la cadena de bloques de Bitcoin)

De todos modos, el efecto final simulado es procesar instrucciones, que originalmente solo podían manejarse en EVM / WASM, directamente en la cadena de bloques de Bitcoin. Aunque esta solución es factible, la dificultad radica en cómo utilizar un gran número de circuitos de puerta lógica como forma intermedia para expresar todos los códigos de operación EVM / WASM. Además, el uso de combinaciones de circuitos de puerta lógica para representar directamente algunos flujos de procesamiento de transacciones extremadamente complejos puede dar lugar a una carga de trabajo masiva.

1. Analicemos otro concepto central mencionado en el documento técnico de BitVM, que son las "Pruebas de fraude interactivas" muy similares a las utilizadas por Arbitrum.

Las pruebas interactivas de fraude involucran un término conocido como aserción. Normalmente, el proponente de la capa 2 (a menudo actuado por un secuenciador) publica una aserción en la capa 1, declarando que ciertos datos de transacción y resultados de transición de estado son válidos y están libres de errores.

Si alguien cree que la afirmación presentada por el proponente es problemática (los datos asociados son incorrectos), se produce una disputa. En este punto, el proponente y el retador intercambian información en rondas y utilizan un método de búsqueda binaria en los datos en disputa para localizar rápidamente una instrucción de operación muy detallada y su segmento de datos asociado.

Para esta instrucción de operación en disputa (código OP), es necesario ejecutarla directamente en la Capa 1 junto con sus parámetros de entrada y validar el resultado de salida (los nodos de la Capa 1 comparan el resultado de salida que calcularon con el resultado de salida publicado previamente por el proponente). En Arbitrum, esto se conoce como "Pruebas de fraude de un solo paso". (En el protocolo interactivo a prueba de fraude de Arbitrum, la búsqueda binaria se utiliza para localizar rápidamente la instrucción en disputa y su resultado de ejecución, y luego se envía una prueba de fraude de un solo paso a la Capa 1 para su verificación final).

Dando seguimiento a esto:

1. El proceso es interactivo y ambas partes se turnan. Una parte segmenta los datos históricos contenidos en un bloque consolidado y la otra parte señala qué segmento de datos es problemático. Esto es similar a un método binario (en realidad, un proceso de reducción progresiva del rango, N/K).

2. Posteriormente, es posible localizar aún más qué transacción y resultado son problemáticos y, a continuación, limitarse aún más a una instrucción de máquina específica dentro de esa transacción que se disputa.

3. El contrato de ChallengeManager solo verifica si el "segmento de datos" producido por la subdivisión de los datos originales es válido.

4. Una vez que el retador y el impugnado han localizado la instrucción de máquina que se va a impugnar, el retador invoca oneStepProveExecution(), enviando una prueba de fraude de un solo paso para demostrar que hay un problema con el resultado de la ejecución de esta instrucción de máquina.

(En el protocolo interactivo a prueba de fraude de Arbitrum, el proceso implica el uso de la búsqueda binaria para localizar rápidamente la instrucción en disputa y su resultado de ejecución a partir de los datos publicados por el Proponente. Después de identificar el dato o código de operación controvertido, se envía una prueba de fraude de un solo paso a la Capa 1 para su verificación final).

Referencias:

El ex embajador técnico de Arbitrum explica la estructura de componentes de Arbitrum (Parte 1)

(Diagrama de flujo interactivo a prueba de fraude de Arbitrum, la explicación es relativamente aproximada)

En este punto, el concepto de pruebas de fraude de un solo paso se vuelve bastante sencillo: la gran mayoría de las instrucciones de transacción que ocurren en la Capa 2 no necesitan volver a verificarse en la cadena de bloques de BTC. Sin embargo, si se impugna un segmento/código de operación de datos en disputa en particular, debe reproducirse en la Capa 1.

Si el resultado de la verificación indica que los datos publicados previamente por el proponente son problemáticos, los activos apostados del proponente se recortan. Si se determina que el Retador tiene la culpa, entonces los activos apostados del Retador se recortan. Los probadores que no respondan a los desafíos de manera oportuna también pueden ser recortados.

Arbitrum implementa los efectos antes mencionados a través de contratos en Ethereum, mientras que BitVM tiene como objetivo lograr una funcionalidad similar utilizando Bitcoin Script para implementar bloqueos de tiempo, multifirma y otras características.

4. Después de discutir "Pruebas de fraude interactivas" y "Pruebas de fraude de un solo paso", hablaremos sobre los árboles MAST y las pruebas de Merkle. Anteriormente, mencionamos que en la solución BitVM, la gran cantidad de datos de transacciones y circuitos de puerta lógica procesados fuera de la cadena en la capa 2 no se colocan directamente en la cadena. Solo una cantidad mínima de circuitos de puerta de datos/lógica se colocan en cadena cuando es necesario. Sin embargo, necesitamos una forma de demostrar que estos datos, que originalmente estaban fuera de la cadena y ahora deben colocarse en la cadena, no son inventados. Aquí es donde entra en juego el concepto de Compromiso en criptografía, y Merkle Proof es una forma de dicho Compromiso.

Primero, hablemos de los árboles MAST. El nombre completo de MAST es Merkelized Abstract Syntax Trees, que es una transformación de AST (Abstract Syntax Trees) del ámbito de los principios del compilador en Merkle Trees. Entonces, ¿qué es un AST? En términos simples, es una estructura de datos en forma de árbol que descompone un comando complejo en un montón de unidades de operación básicas a través del análisis léxico.

(Un ejemplo de un árbol AST sería desglosar cálculos simples como "x = 2, y = x * 3" en códigos de operación y datos subyacentes. )

El árbol MAST, entonces, es el resultado de aplicar Merkleization a un árbol AST, compatible con Merkle Proofs. Una ventaja de los árboles de Merkle es su capacidad para "comprimir" datos de manera eficiente. Por ejemplo, si desea publicar un segmento de datos del árbol de Merkle en la cadena de bloques de BTC cuando sea necesario, y al mismo tiempo hacer creíble que este segmento de datos realmente existe en el árbol de Merkle y no se elige arbitrariamente, ¿qué hace?

Simplemente registre la raíz del árbol de Merkle en la cadena de bloques de antemano. En el futuro, bastará con presentar una prueba de Merkle que demuestre que existe un dato en el árbol de Merkle correspondiente a la raíz.

(La relación entre Merkle Proof/Branch y Root)

Por lo tanto, no es necesario almacenar el árbol MAST completo en la cadena de bloques de BTC; basta con revelar su Raíz de antemano como un Compromiso. Cuando sea necesario, es adecuado presentar el segmento de datos + Merkle Proof/Branch. Esto reduce en gran medida la cantidad de datos en la cadena al tiempo que garantiza que los datos en la cadena existan realmente en el árbol MAST. Además, revelar solo una pequeña parte de los segmentos de datos + Merkle Proof en la cadena de bloques de BTC, en lugar de todos los datos, puede mejorar significativamente la protección de la privacidad.

Referencias:Retención de datos y protección contra fraudes: por qué Plasma no admite contratos inteligentes

(Ejemplo de árbol MAST)

En la solución de BitVM, todos los circuitos de puertas lógicas se expresan mediante scripts de Bitcoin, organizados en un enorme árbol MAST. Las hojas inferiores de este árbol, indicadas como Contenido en el diagrama, corresponden a los circuitos de puerta lógica implementados en el script de Bitcoin. El proponente de la capa 2 publica con frecuencia la raíz del árbol MAST en la cadena de bloques BTC, con cada árbol MAST asociado a una transacción que involucra todos sus parámetros de entrada/códigos de operación/circuitos de puerta lógica. Esto es algo similar a la publicación de Rollup Blocks por parte del Proponente de Arbitrum en la cadena de bloques de Ethereum.

Cuando surge una disputa, un retador declara en la cadena de bloques de BTC qué Root desea desafiar, luego le pide al Proponente que revele un segmento de datos específico correspondiente a la Raíz. Posteriormente, el Proponente presenta una prueba de Merkle, revelando continuamente pequeños segmentos de los datos del árbol MAST en la cadena hasta que el circuito de la puerta lógica en disputa se localiza conjuntamente con el retador. Después de eso, se puede ejecutar una barra diagonal.

(Fuente:https://medium.com/crypto-garage/deep-dive-into-bitvm-computing-paradigm-to-express-turing-complete-bitcoin-contracts-1c6cb05edfca)

1. Hasta este punto, los aspectos más cruciales de la solución BitVM se han cubierto en gran medida. Aunque algunos detalles aún pueden ser algo oscuros, se cree que los lectores pueden captar la esencia y los puntos principales de BitVM. Con respecto al "compromiso de valor de bits" mencionado en su documento técnico, está diseñado para evitar que un proponente asigne 0 y 1 a los valores de entrada de una puerta lógica cuando se le desafía y se le obliga a verificar el circuito de la puerta lógica en la cadena, creando así ambigüedad y confusión.

En resumen, el esquema BitVM comienza utilizando el script de Bitcoin para expresar circuitos de puertas lógicas, luego usa estos circuitos para expresar los códigos de operación de la EVM/otras VM, que a su vez expresan el flujo de procesamiento de cualquier instrucción de transacción dada, y finalmente los organiza en un árbol de Merkle/árbol MAST. Si el flujo de procesamiento de transacciones representado por un árbol de este tipo es muy complejo, puede superar fácilmente los 100 millones de hojas, por lo que es crucial minimizar el espacio de bloque ocupado por los compromisos y el alcance afectado por las pruebas de fraude.

Aunque una prueba de fraude de un solo paso solo requiere una cantidad muy pequeña de datos y un script de puerta lógica en la cadena, el árbol de Merkle completo debe almacenarse fuera de la cadena durante mucho tiempo, de modo que se pueda acceder a él en la cadena en cualquier momento si alguien lo desafía. Cada transacción en una capa 2 genera un gran árbol de Merkle, y uno puede imaginar la presión computacional y de almacenamiento en los nodos. Es posible que la mayoría de las personas no quieran ejecutar nodos (sin embargo, dichos datos históricos se pueden eliminar gradualmente, y la red B^2 introduce específicamente pruebas de almacenamiento zk similares a Filecoin para incentivar a los nodos de almacenamiento a preservar los datos históricos a largo plazo).

Sin embargo, los Rollups optimistas basados en pruebas de fraude no necesitan demasiados nodos porque su modelo de confianza es 1/N, lo que significa que siempre que uno de los N nodos sea honesto y pueda iniciar una prueba de fraude en un momento crítico, la red de capa 2 es segura.

Sin embargo, existen muchos desafíos en el diseño de soluciones de Capa 2 basadas en BitVM, tales como:

1) Teóricamente, para comprimir aún más los datos, no es necesario verificar los códigos de operación directamente en la Capa 1. El flujo de procesamiento de los códigos de operación se puede comprimir aún más en una prueba de zk, lo que permite a los impugnadores desafiar los pasos de verificación de la prueba de zk. Esto podría reducir significativamente la cantidad de datos en la cadena. Sin embargo, los detalles específicos del desarrollo pueden ser muy complejos.

2) Los proponentes y los retadores necesitan generar interacciones fuera de la cadena repetidamente. La forma en que se debe diseñar el protocolo y la forma en que se debe optimizar aún más el proceso de compromiso y desafío en el flujo de procesamiento, requerirá un gran esfuerzo intelectual.

Renuncia:

1. Este artículo es una reimpresión de [Geek Web3], reenvía el título original "Una interpretación minimalista de BitVM: Cómo verificar la prueba de fraude en la cadena BTC (ejecutar el código de operación de EVM u otra VM)", los derechos de autor pertenecen al autor original [Faust & Misty Moon]
   . Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.