Escrito por Robin Linux Traductor: Grupo de Traducción de la Comunidad Denlink
Resumen
BitVM es un paradigma informático utilizado para expresar contratos de Bitcoin completos de Turing. Esto no requiere ningún cambio en las reglas de consenso de la red Bitcoin. A diferencia de realizar cálculos en Bitcoin, simplemente se verifican, de forma similar a los rollups optimistas. El probador declara que una función determinada se evalúa como ciertas entradas para una salida determinada. Si la afirmación es falsa, entonces el verificador puede hacer una prueba concisa de fraude y penalizar a los probadores. Usando este mecanismo, cualquier función computable puede ser verificada en Bitcoin.
Prometer un programa grande en una dirección Taproot requiere una gran cantidad de computación y comunicación fuera de la cadena, pero su huella en la cadena es pequeña. Siempre que las dos partes trabajen juntas, pueden realizar cálculos fuera de la cadena arbitrariamente complejos y con estado sin dejar ningún rastro en la cadena. La aplicación en cadena solo se requiere en caso de disputa.
1 Introducción
Por diseño, la funcionalidad de los contratos inteligentes de Bitcoin se limita a operaciones básicas como firmas, bloqueos de tiempo y bloqueos de hash. BitVM crea un nuevo espacio de diseño para contratos de Bitcoin más expresivos y computación fuera de la cadena. Las aplicaciones potenciales incluyen juegos como el ajedrez, el Go o el póquer, así como la verificación de la prueba de validez en los contratos de Bitcoin. Además, puede ser posible conectar Bitcoin a cadenas externas, crear mercados de predicción o simular nuevos códigos de operación.
La principal desventaja del modelo presentado aquí es que solo funciona con dos configuraciones, el probador y el verificador. Otra limitación es que para los probadores y verificadores, se requiere una gran cantidad de computación y comunicación fuera de la cadena para ejecutar el programa. Sin embargo, estas cuestiones parecen prometedoras para ser abordadas con más investigación. En este trabajo, nos centramos solo en los componentes clave de una BitVM bipartita.
2 Esquema
Con los optimistas Rollups 1[2] [3] y la propuesta MATT (Merkelize All The Things) 2 Del mismo modo, nuestros sistemas se basan en protocolos a prueba de fraude y desafío-respuesta. Sin embargo, BitVM no requiere ningún cambio en las reglas de consenso de Bitcoin. Las primitivas subyacentes son relativamente simples. Se basa principalmente en bloqueos de hash, bloqueos de tiempo y grandes árboles de raíz principal.
El probador envía el programa poco a poco a la cadena, pero validar todo en la cadena consumiría excesivos recursos informáticos, por lo que el verificador realiza una serie de desafíos elaborados para falsificar sucintamente las afirmaciones falsas del demostrador. Juntos, el probador y el verificador firman previamente una serie de desafíos: responder a las transacciones para resolver cualquier disputa más adelante.
El modelo tiene como objetivo simplemente ilustrar que este enfoque permite la computación universal en Bitcoin. Para aplicaciones prácticas, deberíamos considerar modelos más eficientes.
El protocolo es simple: primero, el probador y el verificador compilan el programa en un circuito binario gigante. El probador envía el circuito a una dirección Taproot con un script de hoja para cada puerta lógica en esa dirección. Además, firman previamente una serie de transacciones para respaldar los juegos de desafío-respuesta entre probadores y verificadores. Ahora que han intercambiado todos los datos requeridos, pueden transferir su depósito en cadena a la dirección Taproot generada.
Esto activa el contrato y pueden comenzar a intercambiar datos fuera de la cadena para desencadenar cambios de estado en el circuito. Si el probador hace alguna afirmación falsa, el verificador puede tomar su depósito. Esto garantiza que los atacantes siempre perderán sus depósitos.
Compromiso de valor de 3 bits
El compromiso de valor de bits es el componente más básico de este sistema. Permite al probador establecer el valor de un bit en particular en "0" o "1". En particular, permite al probador establecer el valor de una variable entre diferentes scripts y UTXO. Esto es fundamental porque escala el tiempo de ejecución al dividir el tiempo de ejecución de la máquina virtual de Bitcoin en múltiples transacciones.
La promesa contiene dos valores hash, hash0 y hash1. En un momento posterior, el probador establece el valor del bit en "0" revelando preimage0 (la preimagen de hash0) o en "1" revelando preimage1 (la preimagen de hash1). Si, en algún momento, revelan tanto preimage0 como preimage1, entonces el validador puede usarlos como prueba de fraude y tomar el depósito del probador. A esto se le llama una declaración contradictoria. Ser capaz de castigar las declaraciones contradictorias es lo que hace que un compromiso sea vinculante: es un "compromiso basado en incentivos".
La combinación de promesas de valor de bits con bloqueos de tiempo permite a los validadores obligar al probador a decidir sobre el valor de un bit en particular dentro de un período de tiempo determinado.
Figura 1: Implementación de un compromiso de valor de bitsFigura 1: Implementación de un compromiso de 1 bit. Para desbloquear este script, el probador debe revelar una de las imágenes previas de hash0 o hash1. En esta ejecución de ejemplo, el probador revela hash1 y establece el valor del bit en "1". Podemos replicar esta promesa para aplicar un valor específico en diferentes scripts.
PARA SIMPLIFICAR, A PARTIR DE AQUÍ, SUPONGAMOS QUE HAY UN CÓDIGO DE OPERACIÓN LLAMADO OP BITCOMMITMENT, QUE ES LA ABREVIATURA DEL SCRIPT ANTERIOR. El código de operación consume dos hashes y una preimagen con hash. En función del hash que coincida con la imagen previa, asigna un valor de bit a la pila.
4 Promesas de puertas lógicas
Cualquier función computable se puede representar como un circuito booleano. La puerta NAND es una puerta lógica universal, por lo que cualquier función booleana puede estar compuesta por ellas. Para mantener nuestro modelo simple, mostramos cómo funciona nuestro enfoque con puertas NAND simples. Además, mostramos cómo combinar puertas arbitrariamente. Todo esto demuestra que BitVM puede representar cualquier circuito.
La realización de la promesa de la puerta NAND es simple. Contiene dos promesas de bits que representan dos entradas y un compromiso de bits que representa salidas. El script calcula el valor NAND de las dos entradas para asegurarse de que coincide con los bits de salida prometidos.
Figura 2: Compromiso de puerta para operaciones NAND Figura 2: Compromiso de puerta para operaciones NAND. La ejecución de este script debe revelar los valores de las promesas de bits A, B y C de modo que A NAND B = C sea verdadero.
(Aquí, para simplificar, supongamos que existe un código de operación llamado OP NAND). DE HECHO, NO EXISTE, PERO SE PUEDE IMPLEMENTAR FÁCILMENTE USANDO OP BOOLAND Y OP NOT. ）
5 Promesas de circuitos binarios
En la sección anterior, definimos el compromiso de puerta NAND. Podemos representar cualquier circuito combinando promesas de puertas. Cada paso de la ejecución se confirma en Tapleaf. Todos se fusionan en la misma dirección Taproot para que el probador pueda ejecutar cualquier puerta en el circuito. La ejecución de la puerta requiere que el probador abra la promesa de puerta correspondiente y establezca valores para sus bits de entrada y salida.
Taptree puede llegar a ser masivo y tener mil millones de scripts de Tapleaf, pero su huella en la cadena es pequeña.
Figura 3: Un circuito de ejemplo aleatorio Figura 3: Un circuito de ejemplo aleatorio con 8 puertas NAND diferentes y 4 entradas A, B, C y D. Usando miles de millones de puertas, se puede definir esencialmente cualquier función.
Figura 4Figura 4: Para cada puerta, la dirección Taproot del probador contiene un script de hoja con la promesa de puerta correspondiente. Esto permite al probador establecer los valores de entrada del circuito en cualquier momento (aquí A, B, C y D).
6 Desafíos y respuestas
No basta con comprometerse con un circuito. Para refutar las afirmaciones erróneas, el verificador debe ser capaz de impugnar la declaración del probador. Esto se puede lograr firmando previamente una serie de transacciones durante la configuración. Estas transacciones responden a → desafíos →→ responden a →... de manera vinculada. Si una de las partes deja de participar, después de un período de tiempo de espera, la otra parte gana el desafío y puede tomar los depósitos de ambas partes. Siempre que ambas partes trabajen juntas, pueden trabajar juntas para resolver cualquier contrato a través de una firma 2 de 2. Los siguientes mecanismos solo son necesarios si hay fraude.
Figura 5: Una serie de transacciones prefirmadasFigura 5: Una serie de transacciones prefirmadas para realizar múltiples rondas de impugnaciones y respuestas. Esta secuencia se genera durante la configuración.
Vicky elige un desafío abriendo un hash lock en su hoja de Tap. Esto desbloqueará un toque específico para Paul y lo obligará a ejecutarlo. El guión obliga a Paul a revelar la promesa de la puerta del desafío de Vicky. Al repetir este proceso durante varias rondas de consultas, puede refutar rápidamente cualquier afirmación incoherente.
Si el probador deja de cooperar fuera de la cadena con el validador, el validador necesita una forma de obligar al probador a actuar en la cadena. El validador logra esto desbloqueando el bloqueo hash: cada NAND Tapleaf en el UTXO del probador solo se puede gastar si el probador conoce la preimagen en poder del certificador. Por lo tanto, el probador puede demostrar que un Tapleaf determinado funciona correctamente revelando sus entradas y salidas, pero solo si el verificador lo "desbloquea" revelando la preimagen del hash que protege ese Tapleaf. Al aplicar una búsqueda binaria, los validadores pueden identificar rápidamente el error del probador después de solo unas pocas rondas de desafíos y respuestas.
Figura 6: Después de cada respuesta, Vicky puede penalizar el comportamiento ambiguo. Si Paul expone dos valores conflictivos a una variable, Vicky gana inmediatamente el desafío y se le permite tomar su depósito. Vicky demuestra la ambigüedad de Paul revelando cualquiera de las dos protoimágenes prometidas por sus bits.
7 Entrada y salida
El probador puede establecer la entrada revelando la promesa de bits correspondiente. Idealmente, revelan compromisos fuera de la cadena para minimizar la ocupación dentro de la cadena. En un caso no cooperativo, los validadores pueden obligar a los probadores a revelar sus entradas en la cadena.
Se pueden procesar grandes cantidades de datos mediante el intercambio de cifrado por adelantado. De esta manera, el probador puede revelar la clave de descifrado en un momento posterior.
También es posible la participación de varias partes. Las puertas pueden tener compromisos de broca de ambos lados.
8 Limitaciones y perspectivas
Es ineficiente representar funciones en circuitos NAND simples. Mediante el uso de códigos de operación más avanzados, los programas se pueden representar de manera más eficiente. Por ejemplo, Bitcoin Script admite la adición de números de 32 bits, por lo que no necesitamos circuitos binarios. También podemos tener promesas de bits más grandes, por ejemplo, 32 bits en un solo hash. Además, el tamaño del script puede alcanzar unos 4 MB. Por lo tanto, podemos implementar mucho más de una instrucción NAND en cada script hoja.
El modelo que aquí se presenta se limita a dos partes. Sin embargo, puede ser posible tener canales bidireccionales y unirlos para formar una red similar a la Lightning Network. La exploración de ambos escenarios puede arrojar interesantes posibilidades de generalización. Por ejemplo, podemos explorar una topología en estrella de 1 a n para una red. Otra pregunta de investigación es si podemos aplicar nuestro modelo a una configuración de n a n y crear fábricas de canales más complejas. Además, podemos combinar nuestros sistemas con diferentes protocolos off-chain como el Lightning Network o los Rollups.
Otras direcciones de investigación incluyen la memoria de aplicaciones cruzadas, cómo hacer declaraciones sobre datos arbitrarios grabados en la cadena o circuitos programables fuera de la cadena, es decir, máquinas virtuales fuera de la cadena. También se pueden aplicar técnicas de muestreo más sofisticadas, similares a los STARK, para examinar los circuitos en un solo turno.
El próximo gran hito es la finalización de un diseño e implementación concretos de BitVM, así como Tree++, un lenguaje de alto nivel para escribir y depurar contratos de Bitcoin.
9 Conclusión
Bitcoin es Turing completo en cierto sentido, ya que la codificación de pruebas de fraude en grandes Taptrees verifica la ejecución de cualquier programa. Una limitación importante de este modelo es que solo funciona en el caso de ambas partes. Se espera que la generalización pueda hacerse en trabajos futuros.
Agradecimientos
Un agradecimiento especial a Super Testnet y Sam Parker, que siempre han creído que Bitcoin no será Turing completo.
Referencias
[1] Investigación de Ethereum. Rollups optimistas. 2022.
[2] Salvatore Ingala. Merkleize todas las cosas. , 2022.
Recursos
[1] Equipo de traducción:
[2] Resúmenes optimistas 1:
[3] MATT 提案(Merkelizar todas las cosas)2:
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
BitVM: Calcula cualquier cosa en Bitcoin
Escrito por Robin Linux Traductor: Grupo de Traducción de la Comunidad Denlink
Resumen
BitVM es un paradigma informático utilizado para expresar contratos de Bitcoin completos de Turing. Esto no requiere ningún cambio en las reglas de consenso de la red Bitcoin. A diferencia de realizar cálculos en Bitcoin, simplemente se verifican, de forma similar a los rollups optimistas. El probador declara que una función determinada se evalúa como ciertas entradas para una salida determinada. Si la afirmación es falsa, entonces el verificador puede hacer una prueba concisa de fraude y penalizar a los probadores. Usando este mecanismo, cualquier función computable puede ser verificada en Bitcoin.
Prometer un programa grande en una dirección Taproot requiere una gran cantidad de computación y comunicación fuera de la cadena, pero su huella en la cadena es pequeña. Siempre que las dos partes trabajen juntas, pueden realizar cálculos fuera de la cadena arbitrariamente complejos y con estado sin dejar ningún rastro en la cadena. La aplicación en cadena solo se requiere en caso de disputa.
1 Introducción
Por diseño, la funcionalidad de los contratos inteligentes de Bitcoin se limita a operaciones básicas como firmas, bloqueos de tiempo y bloqueos de hash. BitVM crea un nuevo espacio de diseño para contratos de Bitcoin más expresivos y computación fuera de la cadena. Las aplicaciones potenciales incluyen juegos como el ajedrez, el Go o el póquer, así como la verificación de la prueba de validez en los contratos de Bitcoin. Además, puede ser posible conectar Bitcoin a cadenas externas, crear mercados de predicción o simular nuevos códigos de operación.
La principal desventaja del modelo presentado aquí es que solo funciona con dos configuraciones, el probador y el verificador. Otra limitación es que para los probadores y verificadores, se requiere una gran cantidad de computación y comunicación fuera de la cadena para ejecutar el programa. Sin embargo, estas cuestiones parecen prometedoras para ser abordadas con más investigación. En este trabajo, nos centramos solo en los componentes clave de una BitVM bipartita.
2 Esquema
Con los optimistas Rollups 1[2] [3] y la propuesta MATT (Merkelize All The Things) 2 Del mismo modo, nuestros sistemas se basan en protocolos a prueba de fraude y desafío-respuesta. Sin embargo, BitVM no requiere ningún cambio en las reglas de consenso de Bitcoin. Las primitivas subyacentes son relativamente simples. Se basa principalmente en bloqueos de hash, bloqueos de tiempo y grandes árboles de raíz principal.
El probador envía el programa poco a poco a la cadena, pero validar todo en la cadena consumiría excesivos recursos informáticos, por lo que el verificador realiza una serie de desafíos elaborados para falsificar sucintamente las afirmaciones falsas del demostrador. Juntos, el probador y el verificador firman previamente una serie de desafíos: responder a las transacciones para resolver cualquier disputa más adelante.
El modelo tiene como objetivo simplemente ilustrar que este enfoque permite la computación universal en Bitcoin. Para aplicaciones prácticas, deberíamos considerar modelos más eficientes.
El protocolo es simple: primero, el probador y el verificador compilan el programa en un circuito binario gigante. El probador envía el circuito a una dirección Taproot con un script de hoja para cada puerta lógica en esa dirección. Además, firman previamente una serie de transacciones para respaldar los juegos de desafío-respuesta entre probadores y verificadores. Ahora que han intercambiado todos los datos requeridos, pueden transferir su depósito en cadena a la dirección Taproot generada.
Esto activa el contrato y pueden comenzar a intercambiar datos fuera de la cadena para desencadenar cambios de estado en el circuito. Si el probador hace alguna afirmación falsa, el verificador puede tomar su depósito. Esto garantiza que los atacantes siempre perderán sus depósitos.
Compromiso de valor de 3 bits
El compromiso de valor de bits es el componente más básico de este sistema. Permite al probador establecer el valor de un bit en particular en "0" o "1". En particular, permite al probador establecer el valor de una variable entre diferentes scripts y UTXO. Esto es fundamental porque escala el tiempo de ejecución al dividir el tiempo de ejecución de la máquina virtual de Bitcoin en múltiples transacciones.
La promesa contiene dos valores hash, hash0 y hash1. En un momento posterior, el probador establece el valor del bit en "0" revelando preimage0 (la preimagen de hash0) o en "1" revelando preimage1 (la preimagen de hash1). Si, en algún momento, revelan tanto preimage0 como preimage1, entonces el validador puede usarlos como prueba de fraude y tomar el depósito del probador. A esto se le llama una declaración contradictoria. Ser capaz de castigar las declaraciones contradictorias es lo que hace que un compromiso sea vinculante: es un "compromiso basado en incentivos".
La combinación de promesas de valor de bits con bloqueos de tiempo permite a los validadores obligar al probador a decidir sobre el valor de un bit en particular dentro de un período de tiempo determinado.
Figura 1: Implementación de un compromiso de valor de bitsFigura 1: Implementación de un compromiso de 1 bit. Para desbloquear este script, el probador debe revelar una de las imágenes previas de hash0 o hash1. En esta ejecución de ejemplo, el probador revela hash1 y establece el valor del bit en "1". Podemos replicar esta promesa para aplicar un valor específico en diferentes scripts.
PARA SIMPLIFICAR, A PARTIR DE AQUÍ, SUPONGAMOS QUE HAY UN CÓDIGO DE OPERACIÓN LLAMADO OP BITCOMMITMENT, QUE ES LA ABREVIATURA DEL SCRIPT ANTERIOR. El código de operación consume dos hashes y una preimagen con hash. En función del hash que coincida con la imagen previa, asigna un valor de bit a la pila.
4 Promesas de puertas lógicas
Cualquier función computable se puede representar como un circuito booleano. La puerta NAND es una puerta lógica universal, por lo que cualquier función booleana puede estar compuesta por ellas. Para mantener nuestro modelo simple, mostramos cómo funciona nuestro enfoque con puertas NAND simples. Además, mostramos cómo combinar puertas arbitrariamente. Todo esto demuestra que BitVM puede representar cualquier circuito.
La realización de la promesa de la puerta NAND es simple. Contiene dos promesas de bits que representan dos entradas y un compromiso de bits que representa salidas. El script calcula el valor NAND de las dos entradas para asegurarse de que coincide con los bits de salida prometidos.
Figura 2: Compromiso de puerta para operaciones NAND Figura 2: Compromiso de puerta para operaciones NAND. La ejecución de este script debe revelar los valores de las promesas de bits A, B y C de modo que A NAND B = C sea verdadero.
(Aquí, para simplificar, supongamos que existe un código de operación llamado OP NAND). DE HECHO, NO EXISTE, PERO SE PUEDE IMPLEMENTAR FÁCILMENTE USANDO OP BOOLAND Y OP NOT. ）
5 Promesas de circuitos binarios
En la sección anterior, definimos el compromiso de puerta NAND. Podemos representar cualquier circuito combinando promesas de puertas. Cada paso de la ejecución se confirma en Tapleaf. Todos se fusionan en la misma dirección Taproot para que el probador pueda ejecutar cualquier puerta en el circuito. La ejecución de la puerta requiere que el probador abra la promesa de puerta correspondiente y establezca valores para sus bits de entrada y salida.
Taptree puede llegar a ser masivo y tener mil millones de scripts de Tapleaf, pero su huella en la cadena es pequeña.
Figura 3: Un circuito de ejemplo aleatorio Figura 3: Un circuito de ejemplo aleatorio con 8 puertas NAND diferentes y 4 entradas A, B, C y D. Usando miles de millones de puertas, se puede definir esencialmente cualquier función.
6 Desafíos y respuestas
No basta con comprometerse con un circuito. Para refutar las afirmaciones erróneas, el verificador debe ser capaz de impugnar la declaración del probador. Esto se puede lograr firmando previamente una serie de transacciones durante la configuración. Estas transacciones responden a → desafíos →→ responden a →... de manera vinculada. Si una de las partes deja de participar, después de un período de tiempo de espera, la otra parte gana el desafío y puede tomar los depósitos de ambas partes. Siempre que ambas partes trabajen juntas, pueden trabajar juntas para resolver cualquier contrato a través de una firma 2 de 2. Los siguientes mecanismos solo son necesarios si hay fraude.
Vicky elige un desafío abriendo un hash lock en su hoja de Tap. Esto desbloqueará un toque específico para Paul y lo obligará a ejecutarlo. El guión obliga a Paul a revelar la promesa de la puerta del desafío de Vicky. Al repetir este proceso durante varias rondas de consultas, puede refutar rápidamente cualquier afirmación incoherente.
Si el probador deja de cooperar fuera de la cadena con el validador, el validador necesita una forma de obligar al probador a actuar en la cadena. El validador logra esto desbloqueando el bloqueo hash: cada NAND Tapleaf en el UTXO del probador solo se puede gastar si el probador conoce la preimagen en poder del certificador. Por lo tanto, el probador puede demostrar que un Tapleaf determinado funciona correctamente revelando sus entradas y salidas, pero solo si el verificador lo "desbloquea" revelando la preimagen del hash que protege ese Tapleaf. Al aplicar una búsqueda binaria, los validadores pueden identificar rápidamente el error del probador después de solo unas pocas rondas de desafíos y respuestas.
7 Entrada y salida
El probador puede establecer la entrada revelando la promesa de bits correspondiente. Idealmente, revelan compromisos fuera de la cadena para minimizar la ocupación dentro de la cadena. En un caso no cooperativo, los validadores pueden obligar a los probadores a revelar sus entradas en la cadena.
Se pueden procesar grandes cantidades de datos mediante el intercambio de cifrado por adelantado. De esta manera, el probador puede revelar la clave de descifrado en un momento posterior.
También es posible la participación de varias partes. Las puertas pueden tener compromisos de broca de ambos lados.
8 Limitaciones y perspectivas
Es ineficiente representar funciones en circuitos NAND simples. Mediante el uso de códigos de operación más avanzados, los programas se pueden representar de manera más eficiente. Por ejemplo, Bitcoin Script admite la adición de números de 32 bits, por lo que no necesitamos circuitos binarios. También podemos tener promesas de bits más grandes, por ejemplo, 32 bits en un solo hash. Además, el tamaño del script puede alcanzar unos 4 MB. Por lo tanto, podemos implementar mucho más de una instrucción NAND en cada script hoja.
El modelo que aquí se presenta se limita a dos partes. Sin embargo, puede ser posible tener canales bidireccionales y unirlos para formar una red similar a la Lightning Network. La exploración de ambos escenarios puede arrojar interesantes posibilidades de generalización. Por ejemplo, podemos explorar una topología en estrella de 1 a n para una red. Otra pregunta de investigación es si podemos aplicar nuestro modelo a una configuración de n a n y crear fábricas de canales más complejas. Además, podemos combinar nuestros sistemas con diferentes protocolos off-chain como el Lightning Network o los Rollups.
Otras direcciones de investigación incluyen la memoria de aplicaciones cruzadas, cómo hacer declaraciones sobre datos arbitrarios grabados en la cadena o circuitos programables fuera de la cadena, es decir, máquinas virtuales fuera de la cadena. También se pueden aplicar técnicas de muestreo más sofisticadas, similares a los STARK, para examinar los circuitos en un solo turno.
El próximo gran hito es la finalización de un diseño e implementación concretos de BitVM, así como Tree++, un lenguaje de alto nivel para escribir y depurar contratos de Bitcoin.
9 Conclusión
Bitcoin es Turing completo en cierto sentido, ya que la codificación de pruebas de fraude en grandes Taptrees verifica la ejecución de cualquier programa. Una limitación importante de este modelo es que solo funciona en el caso de ambas partes. Se espera que la generalización pueda hacerse en trabajos futuros.
Agradecimientos
Un agradecimiento especial a Super Testnet y Sam Parker, que siempre han creído que Bitcoin no será Turing completo.
Referencias
[1] Investigación de Ethereum. Rollups optimistas. 2022.
[2] Salvatore Ingala. Merkleize todas las cosas. , 2022.
Recursos
[1] Equipo de traducción:
[2] Resúmenes optimistas 1:
[3] MATT 提案(Merkelizar todas las cosas)2: