1. Introducción

Bitcoin es un activo digital descentralizado, seguro y confiable. Sin embargo, enfrenta limitaciones significativas que impiden que se convierta en una red escalable para pagos y otras aplicaciones. El problema de escalabilidad de Bitcoin ha sido una preocupación desde su inicio. El modelo de UTXO (Transacción de Salida no Gastada) de Bitcoin trata cada transacción como un evento independiente, lo que lleva a un sistema sin estado que carece de la capacidad para ejecutar cálculos complejos dependientes del estado. Como resultado, mientras Bitcoin puede realizar scripts simples y transacciones multi-firma, lucha para facilitar las interacciones contractuales complejas y dinámicas comunes en plataformas blockchain con estado. Esta limitación restringe significativamente la gama de aplicaciones descentralizadas (dApps) e instrumentos financieros complejos que se pueden construir en Bitcoin, mientras que los modelos de plataformas con estado ofrecen un entorno más diverso para implementar y ejecutar contratos inteligentes ricos en funciones.

Para la escalabilidad de Bitcoin, las principales tecnologías incluyen canales de estado, cadenas laterales y validación del lado del cliente. Los canales de estado proporcionan una solución de pago segura y diversa pero tienen capacidad limitada para verificar cálculos arbitrariamente complejos. Esta limitación reduce su aplicabilidad en varios escenarios que requieren lógica condicional y interacciones complejas. Las cadenas laterales admiten una amplia gama de aplicaciones y ofrecen diversidad más allá de las capacidades de Bitcoin, pero tienen una seguridad más baja. Esta diferencia de seguridad se deriva del uso por parte de las cadenas laterales de mecanismos de consenso independientes, que son mucho menos robustos que el mecanismo de consenso de Bitcoin. La validación del lado del cliente, utilizando el modelo UTXO de Bitcoin, puede manejar transacciones más complejas, pero carece de verificación bidireccional y restricciones con Bitcoin, lo que conduce a una seguridad más baja. El diseño fuera de la cadena de los protocolos de validación del lado del cliente depende de servidores o infraestructura en la nube, lo que podría conducir a la centralización o a la censura potencial a través de servidores comprometidos. El diseño fuera de la cadena de la validación del lado del cliente también introduce más complejidad en la infraestructura de la cadena de bloques, lo que podría conducir a problemas de escalabilidad.

En diciembre de 2023, Robin Linus, el líder del proyecto ZeroSync, publicó un libro blanco titulado "BitVM: Calcula cualquier cosa en Bitcoin”, lo que generó considerable reflexión sobre cómo mejorar la programabilidad de Bitcoin. El documento propone una solución de contrato Bitcoin completa de Turing que puede ejecutar cualquier cálculo complejo en Bitcoin sin cambiar las reglas de consenso de la red ni alterar los principios fundamentales de Bitcoin. BitVM aprovecha los scripts de Bitcoin y Taproot para implementar Rollups optimistas. Utiliza firmas de Lamport (también conocidas como compromiso de bit) para establecer conexiones entre dos UTXOs de Bitcoin, permitiendo scripts de Bitcoin con estado. Un programa grande se compromete dentro de una dirección Taproot, y los operadores y validadores participan en extensas interacciones fuera de la cadena, dejando una huella mínima en la cadena de bloques. Si ambas partes cooperan, se puede ejecutar cualquier cálculo complejo y con estado fuera de la cadena sin dejar rastro en la cadena de bloques. Sin embargo, si las partes no cooperan, se requiere una ejecución en cadena en caso de disputa. Por lo tanto, BitVM expande significativamente los casos de uso potenciales de Bitcoin, permitiéndole servir no solo como moneda, sino también como una plataforma de verificación para varias aplicaciones descentralizadas y tareas computacionales complejas.

Sin embargo, a pesar de las ventajas de la tecnología BitVM en la escalabilidad de Bitcoin, todavía se encuentra en las primeras etapas y enfrenta algunos problemas de eficiencia y seguridad, como: (1) Los desafíos y respuestas requieren múltiples interacciones, lo que conlleva altas tarifas de transacción y largos períodos de desafío; (2) Las firmas únicas de Lamport tienen longitudes de datos largas, lo que hace necesario reducir el tamaño de los datos; (3) La complejidad de las funciones hash requiere funciones hash amigables con Bitcoin para reducir costos; (4) Los contratos BitVM existentes son grandes y la capacidad del bloque de Bitcoin es limitada, por lo que el uso de scripts sin scripts podría ayudar a lograr BitVM de Scripts Sin Scripts, ahorrando espacio en el bloque de Bitcoin y mejorando la eficiencia de BitVM; (5) BitVM actual opera en un modelo de permisos, con desafíos iniciados solo por miembros del consorcio y limitados a dos partes, lo que debería ampliarse a un modelo de desafío multiparte sin permisos para reducir aún más las suposiciones de confianza. Para abordar estos problemas, el documento sugiere varias ideas de optimización para mejorar la eficiencia y seguridad de BitVM.

2. Principio BitVM

BitVM se posiciona como un sistema de contrato fuera de la cadena para Bitcoin, con el objetivo de avanzar en la funcionalidad del contrato de Bitcoin. Actualmente, los scripts de Bitcoin son completamente sin estado, lo que significa que el entorno de ejecución se restablece después de cada script. No hay una forma nativa en el script de Bitcoin para garantizar que los scripts 1 y 2 tengan el mismo valor de x. Sin embargo, es posible hacer que los scripts de Bitcoin sean estado usando opcodes existentes y firmas de Lamport de un solo uso, haciendo cumplir que x en script1 y script2 sean iguales. Si los participantes firman valores conflictivos de x, pueden ser penalizados.

Las computaciones de BitVM ocurren fuera de la cadena, mientras que la verificación de estas computaciones tiene lugar en la cadena. Dada la limitación de 1MB de los bloques de Bitcoin, cuando se necesita la verificación de computaciones complejas, la tecnología OP puede ser utilizada en un modo de desafío-respuesta para soportar una mayor complejidad en la verificación de computaciones.

Similar to Optimistic Rollup and the MATT proposal (Merkelize All The Things), the sistema BitVM se basa en pruebas de fraude y protocolos de desafío-respuesta pero no requiere cambios en las reglas de consenso de Bitcoin. Los primitivos subyacentes de BitVM son simples, principalmente basados en cerraduras hash, cerraduras temporales y árboles de Taproot grandes.

Los probadores se comprometen con el programa byte por byte, pero verificar todas las computaciones en la cadena sería prohibitivamente costoso. Por lo tanto, los verificadores realizan una serie de desafíos cuidadosamente diseñados para refutar sucintamente las afirmaciones falsas del probador. Los probadores y verificadores firman conjuntamente una serie de transacciones de desafío y respuesta para resolver disputas, lo que permite la verificación de computaciones generales en Bitcoin.

Los componentes clave de BitVM incluyen:

• Compromiso de circuito: Los probadores y verificadores compilan el programa en un circuito binario grande. El probador se compromete con este circuito en una dirección Taproot, con cada script de hoja bajo esa dirección correspondiente a cada compuerta lógica en el circuito. El núcleo es lograr un compromiso de compuerta lógica basado en el compromiso de bit.
• Desafío y respuesta: Los probadores y verificadores firman previamente una serie de transacciones para implementar el juego de desafío y respuesta. Idealmente, esta interacción ocurre fuera de la cadena, pero también se puede ejecutar en la cadena si el probador no coopera.
• Penalización ambigua: si el probador hace reclamos incorrectos, el verificador puede tomar el depósito del probador después de desafiar con éxito y frustrar las acciones maliciosas del probador.

3. Optimizaciones BitVM

3.1 Reducir el número de interacciones de OP basado en ZK

Existen dos tipos principales de Rollups: ZK Rollups y Optimistic Rollups (OP Rollups). ZK Rollups se basan en la verificación de validez de Pruebas de Conocimiento Cero (ZK), que son pruebas criptográficas de ejecución correcta. Su seguridad depende de suposiciones de complejidad computacional. Optimistic Rollups se basan en Pruebas de Fraude, asumiendo que todos los estados presentados son correctos y generalmente estableciendo un período de desafío de aproximadamente siete días. Su seguridad presupone que al menos una parte honesta en el sistema puede detectar el estado incorrecto y presentar una prueba de fraude.

Suponiendo que el recuento máximo de pasos para el programa de desafío de BitVM es de 2^{32}, necesitaría aproximadamente 17 GB de memoria (2^{32}×4 bytes). En el peor de los casos, alrededor de 40 rondas de desafíos y respuestas podrían llevar aproximadamente seis meses, con un tamaño total de script de alrededor de 150 KB. Tal escenario proporcionaría incentivos insuficientes, pero rara vez ocurre en la práctica.

Usar Pruebas de Conocimiento Cero para reducir el número de desafíos en BitVM podría mejorar su eficiencia. Según la teoría de Prueba de Conocimiento Cero, si los datos satisfacen un algoritmo F, entonces la prueba satisface el algoritmo de verificación Verificar, dando como resultado Verdadero. Por el contrario, si los datos no satisfacen F, entonces la prueba no satisfará Verificar, dando como resultado Falso. En el sistema BitVM, si el desafiante no acepta los datos del probador, se inicia un desafío.

Para el algoritmo F, utilizando un enfoque de búsqueda binaria, asumiendo que se necesitan 2^n iteraciones para encontrar el punto de error. Si la complejidad del algoritmo es demasiado alta, n es grande y tarda mucho tiempo en completarse. Sin embargo, la complejidad del algoritmo de verificación de Prueba de Conocimiento Cero Verify es fija. Al revelar públicamente la prueba y el proceso de verificación Verify, es posible ver una salida de Falso. La ventaja de las Pruebas de Conocimiento Cero radica en la menor complejidad computacional requerida para abrir el algoritmo de verificación Verify en comparación con abrir el algoritmo original F utilizando búsqueda binaria. Por lo tanto, con las Pruebas de Conocimiento Cero, BitVM ya no desafía al algoritmo original F, sino más bien al algoritmo de verificación Verify, reduciendo el número de rondas de desafío y acortando el período de desafío.

Aunque la validez de las Pruebas de Conocimiento Cero y las Pruebas de Fraude se basa en diferentes suposiciones de seguridad, se pueden combinar para construir una Prueba de Fraude ZK e implementar una Prueba ZK a Pedido. A diferencia de un ZK Rollup completo, el modelo a Pedido requiere una Prueba ZK solo cuando se hace un desafío, manteniendo un diseño optimista en el que se asume que el estado generado es válido hasta que se cuestione. Si un estado no se cuestiona, no se necesita una Prueba ZK. Sin embargo, si se plantea un desafío, se debe generar una Prueba ZK para la corrección de todas las transacciones dentro del bloque desafiado. En el futuro, podría ser posible generar Pruebas de Fraude ZK para instrucciones individuales en disputa, evitando el costo computacional de generar continuamente Pruebas ZK.

3.2 Firmas únicas amigables con Bitcoin

En la red Bitcoin, las transacciones que siguen las reglas de consenso se consideran válidas, pero más allá de estas reglas, existe un concepto adicional de normalidad. Los nodos de Bitcoin solo propagan y transmiten transacciones estándar, y la única forma de que las transacciones válidas pero no estándar se incluyan en un bloque es a través de la colaboración directa con los mineros.

Según las reglas de consenso, el tamaño máximo para las transacciones heredadas (no Segwit) es de 1MB, lo que podría llenar un bloque entero. Sin embargo, el límite de normalidad para las transacciones heredadas está establecido en 100kB. Para las transacciones Segwit, el tamaño máximo permitido por las reglas de consenso es de 4MB, conocido como el límite de peso, pero su límite de normalidad es de 400kB.

Las firmas de Lamport son un componente fundamental de BitVM, y reducir la longitud de las firmas y claves públicas ayuda a disminuir el tamaño de los datos de transacción, reduciendo así las tarifas de transacción. Las firmas de un solo uso de Lamport requieren una función hash (como una función de permutación unidireccional f). En un esquema de firma de un solo uso de Lamport, la longitud del mensaje es de v bits, y tanto la clave pública como la longitud de las firmas son de 2v bits. Estas largas firmas y claves públicas consumen una cantidad significativa de gas de almacenamiento. Por lo tanto, es necesario explorar esquemas de firma que puedan reducir la longitud de las firmas y claves públicas. En comparación con las firmas de un solo uso de Lamport, las firmas de un solo uso de Winternitz reducen en gran medida las longitudes de las firmas y claves públicas, pero aumentan la complejidad computacional de firma y verificación.

En el esquema de firma de un solo uso de Winternitz, una función especial P mapea un mensaje de v bits a un vector s de longitud n, con cada elemento de s tomando un valor en {0,...,d}. El esquema de firma de un solo uso de Lamport es un caso especial del esquema de Winternitz, donde d=1. En el esquema de Winternitz, la relación entre n, d y v es aproximadamente n≈v/log2(d+1). Cuando d=15, n≈(v/4)+1. Para una firma de Winternitz con n elementos, las longitudes de clave pública y firma son cuatro veces más cortas que las del esquema de firma de un solo uso de Lamport, pero la complejidad de verificación es cuatro veces mayor. Utilizando d=15, v=160, f=ripemd160(x) en BitVM para firmas de un solo uso de Winternitz puede reducir el tamaño de compromiso de bits en un 50%, reduciendo así las comisiones de transacción de BitVM en al menos un 50%. En el futuro, al optimizar la implementación actual de script de Bitcoin de Winternitz, se podría explorar esquemas de firma de un solo uso más compactos expresables en el script de Bitcoin.

3.3 Funciones hash amigables con Bitcoin

Según las reglas de consenso, el tamaño máximo para un script P2TR es de 10kB, y el tamaño máximo para un testigo de script P2TR es el mismo que el tamaño máximo de transacción Segwit, que es de 4MB. Sin embargo, el límite de normalidad para un testigo de script P2TR es de 400kB.

Actualmente, la red Bitcoin no admite OP_CAT, lo que hace imposible concatenar cadenas para la verificación de la ruta de Merkle. Por lo tanto, es necesario implementar una función hash compatible con Bitcoin utilizando el script Bitcoin existente, de la manera más eficiente en tamaño tanto para el tamaño del script como para el tamaño del testigo del script, para admitir la verificación de prueba de inclusión de Merkle.

BLAKE3 es una versión optimizada de la función hash BLAKE2 e introduce un modo de árbol Bao. En comparación con BLAKE2s, el número de rondas de la función de compresión se ha reducido de 10 a 7. La función hash BLAKE3 divide su entrada en trozos de 1024 bytes, siendo el último trozo posiblemente más corto pero no vacío. Cuando hay solo un trozo, sirve como nodo raíz y único nodo del árbol. Estos trozos se disponen como nodos hoja de un árbol binario, y cada trozo se comprime de forma independiente.

Cuando BitVM se utiliza para verificar pruebas de inclusión de Merkle, la entrada para la operación de hash consiste en dos valores de hash de 256 bits concatenados, totalizando 64 bytes. Con la función de hash BLAKE3, estos 64 bytes pueden caber en un solo fragmento, lo que significa que la operación de hash BLAKE3 solo necesita aplicar la función de compresión una vez a este solo fragmento. En la función de compresión de BLAKE3, se requieren siete funciones de ronda y seis funciones de permutación.

BitVM ya ha implementado operaciones básicas como XOR, adición modular y desplazamiento de bits a la derecha basado en valores u32, lo que facilita ensamblar una función hash BLAKE3 usando el script de Bitcoin. La pila utiliza cuatro bytes separados para representar palabras u32, lo que facilita la adición de u32, el XOR bit a bit de u32 y las rotaciones bit a bit de u32 requeridas por BLAKE3. La función hash BLAKE3 en el script de Bitcoin actualmente tiene alrededor de 100 kB, suficiente para construir una versión de juguete de BitVM.

Además, al dividir estos códigos BLAKE3, el Verificador y el Probador pueden reducir significativamente los requisitos de datos en cadena al dividir la ejecución en el juego de desafío-respuesta en lugar de realizarlo en su totalidad. Por último, implementar funciones hash como Keccak-256 y Grøstl en el script de Bitcoin identificará la función hash más amigable con Bitcoin y explorará otras nuevas funciones hash amigables con Bitcoin.

3.4 Scriptless Scripts BitVM

Scriptless Scripts es un método para ejecutar contratos inteligentes fuera de la cadena utilizando firmas de Schnorr. El concepto de Scriptless Scripts se originó en Mimblewimble, donde no se almacenan datos permanentes aparte del núcleo y su firma.

Las ventajas de Scriptless Scripts incluyen funcionalidad, privacidad y eficiencia:

• Funcionalidad: Los scripts sin script pueden ampliar el alcance y la complejidad de los contratos inteligentes. Las capacidades del script de Bitcoin están limitadas por el número de códigos OP habilitados en la red. En contraste, los scripts sin script trasladan la especificación y ejecución de contratos inteligentes fuera de la cadena a discusiones entre las partes del contrato solamente, sin esperar a que la red de Bitcoin bifurque para habilitar nuevos códigos de operación.
• Privacidad: Mover la especificación y ejecución de contratos inteligentes de on-chain a off-chain mejora la privacidad. On-chain, muchos detalles del contrato se comparten con toda la red, incluyendo el número de participantes, direcciones, y la cantidad transferida. Mover los contratos inteligentes off-chain significa que la red solo sabe que los participantes han acordado que se cumplen los términos del contrato y que las transacciones relacionadas son válidas.
• Eficiencia: Los Scripts sin script minimizan la cantidad de datos que deben ser verificados y almacenados en cadena. Al mover los contratos inteligentes fuera de la cadena, los costos administrativos para los nodos completos se reducen, y las tarifas de transacción para los usuarios también se reducen.

Los scripts sin script representan una forma de diseñar protocolos criptográficos en Bitcoin que evita la ejecución de contratos inteligentes explícitos. La idea principal es utilizar algoritmos criptográficos para lograr la funcionalidad deseada en lugar de utilizar scripts. Las firmas de adaptador y las multi-firmas son bloques de construcción fundamentales de los scripts sin script. Con los scripts sin script, las transacciones pueden ser más pequeñas que las transacciones convencionales, reduciendo así las tarifas de transacción.

Los Scripts sin guiones pueden usarse para implementar compromisos de puertas lógicas en el circuito BitVM, ahorrando espacio de script BitVM y mejorando la eficiencia de BitVM, utilizando firmas multi-firma de Schnorr y firmas de adaptador en lugar de proporcionar valores hash y preimágenes como la solución BitVM. Aunque los esquemas actuales de Scripts sin guiones pueden reducir el espacio de script BitVM, requieren una interacción extensa entre el probador y el desafiante para combinar claves públicas. Las futuras mejoras tendrán como objetivo integrar Scripts sin guiones en módulos funcionales específicos de BitVM.

3.5 Desafíos multiparte sin permisos

El desafío actual de BitVM requiere permiso porque un UTXO de Bitcoin solo se puede ejecutar una vez, lo que conduce a una situación en la que un verificador malintencionado podría "malgastar" el contrato desafiando a un probador honesto. BitVM actualmente está restringido a un modelo de desafío de dos partes. Un probador malintencionado podría utilizar un verificador bajo su control para iniciar un desafío y "malgastar" el contrato, asegurando así que su acción maliciosa tenga éxito mientras que otros verificadores no pueden evitar este comportamiento. Por lo tanto, además de Bitcoin, es necesario investigar un protocolo de desafío OP multi-party sin permiso que pueda expandir el modelo de confianza existente de BitVM de 1-de-n a 1-de-N, donde N es mucho más grande que n. Además, es importante abordar problemas de colusión entre desafiantes y probadores o desafíos maliciosos que "malgastan" contratos para lograr un protocolo BitVM más minimizado en confianza.

Un desafío multiparte sin permisos permite a cualquier persona participar sin una lista blanca, lo que significa que los usuarios pueden retirarse de L2 sin la participación de ningún tercero de confianza. Además, cualquier usuario que desee participar en el protocolo de desafío de OP puede cuestionar y eliminar retiros inválidos.

Expandir BitVM en un modelo de desafío multiparte sin permisos implica abordar los siguientes ataques:

• Ataques de Sybil: Incluso si un atacante crea múltiples identidades para participar en el desafío de disputa, un solo participante honesto aún debería poder ganar la disputa. Si el costo para un participante honesto de defender el resultado correcto crece linealmente con el número de atacantes, el costo para el participante honesto de ganar la disputa se vuelve impráctico y vulnerable a los ataques de Sybil cuando involucra a un gran número de atacantes. El documento Torneos de Árbitros sin Permisopropone un algoritmo de resolución de disputas que cambia las reglas del juego, donde el costo para que un único participante honesto gane la disputa crece de forma logarítmica, no linealmente, con el número de oponentes.
• Ataques de retraso: Un individuo o grupo de actores malintencionados siguen una estrategia para prevenir o retrasar la confirmación del resultado correcto (como retirar activos a L1) en L1, obligando al probador honesto a gastar tarifas de transacción de L1. Para mitigar este problema, podría requerirse que los impugnadores hagan una apuesta inicial. Si un impugnador lanza un ataque de retraso, su apuesta sería confiscada. Sin embargo, si los atacantes están dispuestos a sacrificar su apuesta hasta cierto punto para llevar a cabo ataques de retraso, debería haber estrategias para reducir el impacto de estos ataques. El algoritmo propuesto en el documento " BoLD: Bounded Liquidity Delay en un Protocolo de Desafío Rollup"garantiza que el retraso máximo causado por el atacante esté limitado, independientemente de cuánto stake esté dispuesto a perder el atacante."

En el futuro, habrá una exploración de un modelo de desafío multiparte sin permiso de BitVM que sea resistente a estos ataques y adecuado para las características de Bitcoin.

4. Conclusión

La exploración de la tecnología BitVM está apenas comenzando, y en el futuro, se explorarán y practicarán más optimizaciones para lograr la escalabilidad de Bitcoin y enriquecer el ecosistema de Bitcoin.

Descargo de responsabilidad：

1. Este artículo ha sido reimpreso de@Bitlayer/bitvm-and-its-optimization-considerations-007da599d8ac">Bitlayer], Todos los derechos de autor pertenecen al autor original [Lynndell y Mutourend]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y lo resolverán rápidamente.
2. Descargo de responsabilidad: Las opiniones y puntos de vista 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.