Bitcoin es un activo digital descentralizado, seguro y confiable. Sin embargo, tiene importantes limitaciones que le impiden convertirse en una red escalable para pagos y otras aplicaciones. La cuestión de la escala de Bitcoin ha sido una preocupación desde sus inicios. El modelo Bitcoin UTXO trata cada transacción como un evento independiente, lo que da como resultado un sistema sin estado que carece de la capacidad de realizar cálculos complejos que dependen del estado. Por lo tanto, si bien Bitcoin puede realizar scripts simples y transacciones con múltiples firmas, tiene dificultades para facilitar las interacciones contractuales complejas y dinámicas comunes en las plataformas blockchain con estado. Este problema limita significativamente el alcance de las aplicaciones descentralizadas (dApps) y los instrumentos financieros complejos que se pueden construir en Bitcoin, mientras que las plataformas de modelo estatal proporcionan un entorno más diverso para implementar y ejecutar contratos inteligentes ricos en funciones.
Para la expansión de Bitcoin, existen principalmente tecnologías como canales estatales, cadenas laterales y verificación de clientes. Entre ellos, los canales estatales brindan soluciones de pago seguras y diversas, pero tienen una capacidad limitada para verificar cálculos arbitrariamente complejos. Esta limitación reduce su uso en una variedad de escenarios que requieren interacciones y lógica condicional compleja. Las cadenas laterales, si bien admiten una amplia gama de aplicaciones y brindan una diversidad de funcionalidades más allá de Bitcoin, tienen menor seguridad. Esta diferencia en seguridad se debe al hecho de que las cadenas laterales utilizan mecanismos de consenso independientes, que son mucho menos sólidos que el mecanismo de consenso de Bitcoin. La verificación del lado del cliente, utilizando el modelo UTXO de Bitcoin, puede manejar transacciones más complejas, pero no tiene la capacidad de restricción de suma de verificación bidireccional de Bitcoin, lo que hace que su seguridad sea menor que la de Bitcoin. El diseño fuera de la cadena de los protocolos de verificación del cliente se basa en la infraestructura del servidor o de la nube, lo que puede conducir a la centralización o a una posible censura a través de servidores comprometidos. El diseño fuera de la cadena de validación del lado del cliente también introduce más complejidad en la infraestructura de la cadena de bloques, lo que podría generar problemas de escalabilidad.
En diciembre de 2023, el líder del proyecto ZeroSync, Robin Linus, publicó un documento técnico llamado "BitVM: Compute Anything On Bitcoin", que desencadenó el pensamiento de todos sobre mejorar la programabilidad de Bitcoin. Este artículo propone una solución de contrato de Bitcoin que puede lograr la integridad de Turing sin cambiar el consenso de la red de Bitcoin, de modo que cualquier cálculo complejo pueda verificarse en Bitcoin sin cambiar las reglas básicas de Bitcoin. BitVM hace un uso completo de Bitcoin Script y Taproot para lograr un resumen optimista. Según la firma Lamport (también conocida como compromiso de bits), se establece una conexión entre dos UTXO de Bitcoin para implementar scripts de Bitcoin con estado. Al comprometerse con un programa grande en una dirección Taproot, los operadores y validadores participan en extensas interacciones fuera de la cadena, lo que resulta en una pequeña huella dentro de la cadena. Si ambas partes cooperan, se pueden realizar cálculos arbitrariamente complejos y con estado fuera de la cadena sin dejar ningún rastro en la cadena. Si ambas partes no cooperan, cuando ocurre una disputa, se requiere la ejecución en cadena. Como resultado, BitVM amplía enormemente los posibles casos de uso de Bitcoin, permitiendo que Bitcoin sirva no sólo como moneda sino también como plataforma de verificación para una variedad de aplicaciones descentralizadas y tareas informáticas complejas.
Sin embargo, aunque la tecnología BitVM tiene grandes ventajas en la expansión de Bitcoin, todavía se encuentra en sus primeras etapas y todavía existen algunos problemas en términos de eficiencia y seguridad. Por ejemplo: (1) Los desafíos y las respuestas requieren múltiples interacciones, lo que resulta en costosas tarifas de manejo y largos ciclos de desafío; (2) los datos de la firma única de Lamport son largos y es necesario reducir la longitud de los datos; (3) La función hash es complejo y requiere una función hash compatible con Bitcoin para reducir costos; (4) El contrato de BitVM existente es enorme y la capacidad del bloque de Bitcoin es limitada. Se pueden usar menos s para implementar menos BitVM, ahorrando espacio en el bloque de Bitcoin y mejorando la eficiencia de BitVM; (5 ) El BitVM existente adopta un modelo de permiso. Solo los miembros de la alianza pueden iniciar desafíos y está limitado a solo dos partes. Debería extenderse a un modelo de desafío multipartito sin permiso para reducir aún más la suposición de confianza. Con este fin, este artículo propone algunas ideas de optimización para mejorar aún más la eficiencia y seguridad de BitVM.
2. Principio de BitVM
BitVM se posiciona como un contrato fuera de la cadena de Bitcoin y se compromete a promover las funciones del contrato de Bitcoin. Actualmente, los scripts de Bitcoin no tienen ningún estado, por lo que cuando se ejecuta un script de Bitcoin, su entorno de ejecución se restablece después de cada script. No existe una forma nativa para que el script 1 y el script 2 tengan el mismo valor x, y Bitcoin Script no lo admite de forma nativa. Sin embargo, aún puede usar códigos de operación existentes para hacer que el script de Bitcoin tenga estado a través de la firma única de Lamport. Por ejemplo, puede forzar que x en 1 y 2 tenga el mismo valor. Los participantes pueden ser penalizados si firman valores de x contradictorios. Los cálculos del programa BitVM se realizan fuera de la cadena, mientras que la verificación del resultado del cálculo se produce dentro de la cadena. El bloque de Bitcoin actual tiene un límite de 1 MB. Cuando el cálculo de verificación es demasiado complejo, se puede utilizar la tecnología OP para adoptar el modo de respuesta de desafío para admitir una verificación de cálculo de mayor complejidad.
Al igual que Optimistic Rollup y la propuesta MATT (Merkelize All The Things), el sistema BitVM se basa en protocolos a prueba de fraude y de desafío-respuesta, pero no requiere modificación de las reglas de consenso de Bitcoin. Las primitivas subyacentes de BitVM son simples y se basan principalmente en bloqueos hash, bloqueos de tiempo y grandes árboles Taproot.
El probador confirma byte por byte, pero verificar todos los cálculos en cadena sería demasiado costoso. Entonces, el verificador realiza una serie de desafíos cuidadosamente diseñados para refutar de manera sucinta las afirmaciones falsas del probador. Los probadores y validadores prefirman conjuntamente una serie de transacciones de desafío y respuesta que se utilizan para resolver disputas, lo que permite la verificación computacional universal en Bitcoin.
Los componentes clave de BitVM son:
Compromisos de circuitos: Los probadores y verificadores compilan programas en grandes circuitos binarios. El probador se compromete con el circuito en una dirección Taproot, y cada script hoja bajo esta dirección corresponde a cada puerta lógica en el circuito. El núcleo se basa en el compromiso de bits para implementar el compromiso de puerta lógica y el compromiso de circuito.
Desafío y respuesta: Los probadores y verificadores firman previamente una serie de transacciones para implementar el juego desafío-respuesta. Idealmente, esta interacción se realiza fuera de la cadena, pero también se puede realizar dentro de la cadena cuando el probador no coopera.
Penalización ambigua: Si el probador hace alguna declaración incorrecta, el verificador puede quitarle el depósito al probador después de desafiarlo exitosamente para frustrar el mal comportamiento del probador.
3.Optimización de BitVM
3.1 Reducir la cantidad de interacciones OP basadas en ZK
Actualmente hay dos paquetes acumulativos principales: paquetes acumulativos ZK y paquetes acumulativos OP. Entre ellos, ZK Rollups se basa en la verificación de validez de ZK Proof, es decir, la prueba criptográfica de ejecución correcta, y su seguridad se basa en el supuesto de complejidad computacional; OP Rollups se basa en Fraud Proof, asumiendo que los estados enviados son correctos, estableciendo El período de desafío suele ser de 7 días y su seguridad supone que al menos una parte honesta en el sistema puede detectar el estado incorrecto y presentar una prueba de fraude. Supongamos que el número máximo de pasos del programa de desafío BitVM es 2 ^{ 32 } y la memoria requerida es 2 ^{ 32 }* 4 bytes, que son aproximadamente 17 GB. En el peor de los casos, se necesitan alrededor de 40 rondas de desafío y respuesta, aproximadamente medio año, y el guión total es de aproximadamente 150 KB. Hay una grave falta de incentivos en esta situación, pero casi nunca ocurre en la práctica.
Considere el uso de pruebas de conocimiento cero para reducir la cantidad de desafíos de BitVM, mejorando así la eficiencia de BitVM. De acuerdo con la teoría de la prueba de conocimiento cero, si los datos Datos satisfacen el algoritmo F, se demuestra que la prueba satisface el algoritmo de verificación Verificar, es decir, el algoritmo de verificación genera Verdadero; si los datos Datos no satisfacen el algoritmo F, se demuestra que la prueba no satisface el algoritmo de verificación Verify, es decir, el algoritmo de verificación genera False. En el sistema BitVM, si el retador no reconoce los datos enviados por el probador, se inicia un desafío.
Para el algoritmo F, utilice el método de dicotomía para dividirlo. Suponga que se necesitan 2 ^ n veces para encontrar el punto de error; si la complejidad del algoritmo es demasiado alta, n será grande y llevará mucho tiempo completarlo. Sin embargo, la complejidad del algoritmo de verificación Verify de la prueba de conocimiento cero es fija. Todo el proceso de prueba y el algoritmo de verificación Verify es público y el resultado es Falso. La ventaja de la prueba de conocimiento cero es que la complejidad computacional requerida para abrir el algoritmo de verificación Verify es mucho menor que el método binario para abrir el algoritmo original F. Por lo tanto, con la ayuda de la prueba de conocimiento cero, BitVM ya no desafía el algoritmo original F, sino el algoritmo de verificación Verify, lo que reduce el número de rondas de desafío y acorta el ciclo de desafío.
Finalmente, aunque la eficacia de la prueba de conocimiento cero y de la prueba de fraude depende de diferentes supuestos de seguridad, se pueden combinar para crear ZK Fraud Proof y realizar On-Demand ZK Proof. A diferencia del ZK Rollup completo, que ya no necesita generar pruebas ZK para cada transición de estado, el modelo On-Demand hace que ZK Proof solo sea necesario cuando hay desafíos, mientras que todo el diseño del Rollup sigue siendo optimista. Por lo tanto, el estado resultante sigue siendo válido por defecto hasta que alguien lo cuestione. Si no hay ningún desafío en un estado determinado, no es necesario generar ninguna prueba ZK. Sin embargo, si un participante inicia un desafío, se debe generar ZK Proof para verificar la exactitud de todas las transacciones en el bloque de desafío. En el futuro, podemos explorar la generación de ZK Fraud Proof para una única instrucción controvertida para evitar el costo computacional de generar ZK Proof todo el tiempo.
3.2 Firma única compatible con Bitcoin
En la red Bitcoin, las transacciones que siguen reglas de consenso son transacciones válidas, pero además de las reglas de consenso, también se introducen reglas de estandarización. Los nodos de Bitcoin solo reenvían transacciones estándar de transmisión, la única forma de empaquetar transacciones válidas pero no estándar es trabajando directamente con los mineros.
Según las reglas de consenso, el tamaño máximo de las transacciones heredadas (no Segwit) es de 1 MB, que ocupa todo el bloque. Pero el límite de estandarización para transacciones heredadas es de 100 kB. Según las reglas de consenso, el tamaño máximo de una transacción Segwit es 4 MB, que es el límite de peso. Sin embargo, el límite de estandarización de las transacciones de Segwit es de 400 kB.
La firma Lamport es un componente básico de BitVM. Reduce la longitud de la firma y la clave pública, lo que ayuda a reducir los datos de las transacciones y, por tanto, las tarifas de gestión. La firma única de Lamport requiere el uso de una función hash (como la función de permutación unidireccional f). En el esquema de firma única de Lamport, la longitud del mensaje es v bits, la longitud de la clave pública es 2 v bits y la longitud de la firma también es 2 v bits. La firma y la clave pública son largas y requieren una gran cantidad de gas de almacenamiento. Por lo tanto, existe la necesidad de encontrar esquemas de firma con funciones similares para reducir la longitud de las firmas y las claves públicas. En comparación con la firma única de Lamport, la firma única de Winternitz ha reducido significativamente la longitud de las firmas y de las claves públicas, pero aumenta la complejidad computacional de la firma y la verificación de la firma.
En el esquema de firma única de Winternitz, se utiliza una función especial P para asignar un mensaje de v-bit a un vector s de longitud n. El valor de cada elemento en s es {0,..., d}. El esquema de firma única de Lamport es el esquema de firma única de Winternitz en el caso especial de d= 1. En el esquema de firma única de Winternitz, la relación entre n, d, v satisface: n≈v/log 2(d+ 1). Cuando d= 15, hay n≈(v/4)+ 1. Para una firma Winternitz que contiene n elementos, la longitud de la clave pública y la longitud de la firma son 4 veces más cortas que en el esquema de firma única de Lamport. Sin embargo, la complejidad de la verificación de firmas se multiplica por 4. El uso de d= 15, v= 160, f=ripemd 160(x) en BitVM para implementar la firma única de Winternitz puede reducir el tamaño del compromiso de bits en un 50 %, reduciendo así las tarifas de transacción de BitVM en al menos un 50 %. En el futuro, mientras se optimiza la implementación existente de Winternitz Bitcoin Script, se podrán explorar esquemas de firma única más compactos expresados en Bitcoin Script.
3.3 Funciones hash compatibles con Bitcoin
Según las reglas de consenso, el tamaño máximo de P 2 TR es 10 kB, y el tamaño máximo del testigo P 2 TR es el mismo que el tamaño máximo de transacción de Segwit, que es 4 MB. Sin embargo, el límite superior de estándard del testigo P 2 TR es 400 kB.
Actualmente, la red Bitcoin no admite OP _CAT y las cadenas no se pueden unir para la verificación de ruta de Merkle. Por lo tanto, es necesario utilizar scripts de Bitcoin existentes para implementar una función hash compatible con Bitcoin con un tamaño y un tamaño de testigo óptimos para admitir la función de verificación de prueba de inclusión de merkle.
BLAKE 3 es una versión optimizada de la función hash BLAKE 2 e introduce el modo de árbol Bao. En comparación con el BLAKE 2 s, el número de rondas de su función de compresión se reduce de 10 a 7. La función hash BLAKE 3 dividirá su entrada en fragmentos consecutivos de 1024 bytes de tamaño; el último fragmento puede ser más corto pero no vacío. Cuando solo hay un fragmento, el fragmento es el nodo raíz y el único nodo del árbol. Organice estos fragmentos como nodos hoja de un árbol binario y luego comprima cada fragmento de forma independiente.
Cuando se utiliza BitVM para verificar el escenario de prueba de inclusión de Merkle, la entrada de la operación hash se compone de dos valores hash de 256 bits, es decir, la entrada de la operación hash es de 64 bytes. Cuando se utiliza la función hash BLAKE 3, estos 64 bytes se pueden asignar dentro de un solo fragmento, y toda la operación hash BLAKE 3 solo necesita aplicar la función de compresión una vez a un único fragmento. En la función de compresión de BLAKE 3, es necesario ejecutar la función de ronda 7 veces y la función de permutación 6 veces.
En la actualidad, en BitVM se han completado operaciones básicas como XOR, suma modular y desplazamiento de bits a la derecha según los valores de u 32, y la función hash BLAKE 3 implementada por el script de Bitcoin se puede ensamblar fácilmente. Utilice 4 bytes separados en la pila para representar u 32 palabras para implementar u 32 suma, u 32 XOR bit a bit y u 32 rotaciones bit a bit requeridas por BLAKE 3. El actual script de Bitcoin con función hash de BLAKE 3 tiene un total de aproximadamente 100 kB, lo que es suficiente para construir una versión de juguete de BitVM.
Además, estos códigos BLAKE 3 se pueden dividir, lo que permite a Verifier y Prover reducir significativamente los datos en cadena necesarios al dividir la ejecución en el juego de desafío-respuesta a la mitad en lugar de ejecutarlo por completo. Finalmente, use el script de Bitcoin para implementar funciones hash como Keccak-256 y Grøstl, seleccione la función hash más compatible con Bitcoin y explore otras funciones hash nuevas compatibles con Bitcoin.
3,4 menos BitVM
less s es un método para ejecutar contratos inteligentes fuera de la cadena mediante el uso de firmas Schnorr. El concepto de Scripless nació de Mimblewimble, que no almacena datos permanentes excepto el núcleo y su firma.
Las ventajas de less s son funcionalidad, privacidad y eficiencia.
**Características: **menos anuncios pueden aumentar el alcance y la complejidad de los contratos inteligentes. Las capacidades de secuencias de comandos de Bitcoin están limitadas por la cantidad de OP_CODES habilitados en la red, y menos mueve la especificación y ejecución de contratos inteligentes de la cadena a discusiones solo entre los participantes del contrato de diseño, sin esperar a que se habilite una bifurcación de la red de Bitcoin. Nuevo código de operación.
**Privacidad:**Mover la especificación y ejecución de contratos inteligentes de dentro de la cadena a fuera de la cadena aumenta la privacidad. En la cadena, muchos detalles del contrato se compartirán con toda la red, incluidos el número y las direcciones de los participantes y el monto de la transferencia. Al sacar los contratos inteligentes fuera de la cadena, la red solo sabe que los participantes están de acuerdo en que se han cumplido los términos de sus contratos y que las transacciones subyacentes son válidas.
**Eficiencia: **less s minimiza la cantidad de datos verificados y almacenados en la cadena. Al sacar los contratos inteligentes fuera de la cadena, se reducirán las tarifas de gestión de los nodos completos y también se reducirán las tarifas de transacción para los usuarios.
less s es un enfoque para diseñar protocolos criptográficos en Bitcoin que evita la necesidad de ejecutar contratos inteligentes explícitos. La idea central es utilizar algoritmos criptográficos para lograr la funcionalidad deseada en lugar de utilizar scripts para lograr la funcionalidad. Las firmas de adaptador y las firmas múltiples son los componentes básicos originales de less s. Usando menos correos electrónicos, puede lograr transacciones más pequeñas que las transacciones normales y reducir las tarifas de transacción.
Con la ayuda de less s, se puede utilizar la firma de adaptador y firma múltiple de Schnorr, que ya no proporciona valores hash ni preimágenes hash como la solución BitVM, y también puede realizar el compromiso de puerta lógica en el circuito BitVM, ahorrando así BitVM. espacio de script y mejora de la eficiencia de BitVM. Aunque el esquema less existente puede reducir el espacio del script BitVM, requiere una gran cantidad de interacción entre el probador y el retador para combinar la clave pública. En el futuro, mejoraremos esta solución e intentaremos introducir Scripless en módulos de funciones BitVM específicos.
3.5 Desafío multipartito sin permiso
La razón por la que los desafíos actuales de BitVM requieren permiso de forma predeterminada es que el UTXO de Bitcoin solo se puede ejecutar una vez, lo que permite que un verificador malicioso "desperdicie" el contrato desafiando a un probador honesto. BitVM está actualmente limitado al modo de desafío bipartito. Un probador que intenta hacer el mal puede lanzar simultáneamente un desafío con un verificador que controla, "desperdiciando" así el contrato, haciendo que el acto malvado tenga éxito y otros verificadores no puedan evitar el comportamiento. Por lo tanto, basado en Bitcoin, es necesario estudiar un protocolo de desafío OP multipartito sin permiso, que pueda extender el modelo de confianza 1 de n existente de BitVM a 1 de N. Entre ellos, N es mucho mayor que n. Además, es necesario estudiar y resolver el problema de los retadores que se confabulan con los probadores o cuestionan maliciosamente contratos "desperdiciados". En última instancia, implementar el protocolo BitVM con menos confianza.
Desafíos multipartidistas sin permiso, que permiten que cualquiera participe sin una lista de permisos. Esto significa que los usuarios pueden retirar monedas de L2 sin la participación de ningún tercero de confianza. Además, cualquier usuario que quiera participar en el protocolo de desafío OP puede cuestionar y eliminar retiros no válidos.
Extender BitVM a un modelo de desafío multipartito sin permiso requiere resolver los siguientes ataques:
Ataque Sybil: Incluso si un atacante falsifica múltiples identidades para participar en un desafío de disputa, una sola parte honesta aún puede ganar la disputa. Si el costo para una parte honesta de defender el resultado correcto está relacionado linealmente con el número de atacantes, entonces cuando hay un gran número de atacantes involucrados, el costo de ganar una disputa se vuelve poco realista y vulnerable al ataque de las Brujas. En el artículo Torneos con árbitros sin permiso se propone un algoritmo de resolución de disputas revolucionario: el costo de que un solo participante honesto gane una disputa aumenta logarítmicamente con el número de oponentes, en lugar de linealmente.
Ataque retardado: Una parte malintencionada o un grupo de partes malintencionadas siguen una determinada estrategia para evitar o retrasar la confirmación de resultados correctos (como retirar activos a L1) en L1 y obligar a los probadores honestos a gastar tarifas de L1. Este problema puede aliviarse exigiendo a los rivales que apuesten por adelantado. Si un retador lanza un ataque retrasado, perderá su apuesta. Sin embargo, si un atacante está dispuesto a sacrificar la apuesta dentro de ciertos límites para realizar un ataque retardado, deberían existir contramedidas para reducir el impacto del ataque retardado. El algoritmo propuesto en el artículo BoLD: Bounded Liquidity Delay in a Rollup Challenge Protocol hace que no importa cuánto compromiso esté dispuesto a perder el atacante, el peor ataque solo puede causar un cierto límite superior de retraso.
En el futuro, exploraremos el modelo de desafío multipartito sin permiso de BitVM que es adecuado para las características de Bitcoin y puede resistir los problemas de ataque anteriores.
4. Conclusión
La exploración de la tecnología BitVM acaba de comenzar y en el futuro se explorarán e implementarán más direcciones de optimización para lograr la expansión de Bitcoin y hacer prosperar el ecosistema de Bitcoin.
referencias
BitVM: calcule cualquier cosa en Bitcoin
BitVM: contratos de Bitcoin fuera de cadena
Robin Linus en BitVM
[bitcoin-dev] BitVM: calcule cualquier cosa en Bitcoin
La extraña pareja: ZK y los rollups optimistas en una fecha de escalabilidad
¿Cuáles son las transacciones y los límites de Bitcoin?
BIP-342: Validación de Taproot s
_linus/status/1765337186222686347
Un curso de posgrado en criptografía aplicada
BLAKE 3: una función, rápido en todas partes
[bitcoin-dev] Implementación de Blake 3 en Bitcoin
Introducción a menos s
BitVM usa menos s
Soluciones para retrasar los ataques a los paquetes acumulativos
Presentamos a DAVE. "A prueba de fallos sin permiso de Cartesi".
Ataques retardados en paquetes acumulativos
Soluciones para retrasar los ataques a los paquetes acumulativos - Arbitrum Research
Notas sobre juegos de computación interactivos multijugador
BoLD: Retraso de liquidez limitado en un protocolo de desafío acumulado
Torneos arbitrados sin permiso
Enlace original
Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Consideraciones de optimización y análisis de principios de BitVM
Fuente original: Grupo de Investigación Bitlayer
Autor original: lynndell, mutourend.
1. Introducción
Bitcoin es un activo digital descentralizado, seguro y confiable. Sin embargo, tiene importantes limitaciones que le impiden convertirse en una red escalable para pagos y otras aplicaciones. La cuestión de la escala de Bitcoin ha sido una preocupación desde sus inicios. El modelo Bitcoin UTXO trata cada transacción como un evento independiente, lo que da como resultado un sistema sin estado que carece de la capacidad de realizar cálculos complejos que dependen del estado. Por lo tanto, si bien Bitcoin puede realizar scripts simples y transacciones con múltiples firmas, tiene dificultades para facilitar las interacciones contractuales complejas y dinámicas comunes en las plataformas blockchain con estado. Este problema limita significativamente el alcance de las aplicaciones descentralizadas (dApps) y los instrumentos financieros complejos que se pueden construir en Bitcoin, mientras que las plataformas de modelo estatal proporcionan un entorno más diverso para implementar y ejecutar contratos inteligentes ricos en funciones.
Para la expansión de Bitcoin, existen principalmente tecnologías como canales estatales, cadenas laterales y verificación de clientes. Entre ellos, los canales estatales brindan soluciones de pago seguras y diversas, pero tienen una capacidad limitada para verificar cálculos arbitrariamente complejos. Esta limitación reduce su uso en una variedad de escenarios que requieren interacciones y lógica condicional compleja. Las cadenas laterales, si bien admiten una amplia gama de aplicaciones y brindan una diversidad de funcionalidades más allá de Bitcoin, tienen menor seguridad. Esta diferencia en seguridad se debe al hecho de que las cadenas laterales utilizan mecanismos de consenso independientes, que son mucho menos sólidos que el mecanismo de consenso de Bitcoin. La verificación del lado del cliente, utilizando el modelo UTXO de Bitcoin, puede manejar transacciones más complejas, pero no tiene la capacidad de restricción de suma de verificación bidireccional de Bitcoin, lo que hace que su seguridad sea menor que la de Bitcoin. El diseño fuera de la cadena de los protocolos de verificación del cliente se basa en la infraestructura del servidor o de la nube, lo que puede conducir a la centralización o a una posible censura a través de servidores comprometidos. El diseño fuera de la cadena de validación del lado del cliente también introduce más complejidad en la infraestructura de la cadena de bloques, lo que podría generar problemas de escalabilidad.
En diciembre de 2023, el líder del proyecto ZeroSync, Robin Linus, publicó un documento técnico llamado "BitVM: Compute Anything On Bitcoin", que desencadenó el pensamiento de todos sobre mejorar la programabilidad de Bitcoin. Este artículo propone una solución de contrato de Bitcoin que puede lograr la integridad de Turing sin cambiar el consenso de la red de Bitcoin, de modo que cualquier cálculo complejo pueda verificarse en Bitcoin sin cambiar las reglas básicas de Bitcoin. BitVM hace un uso completo de Bitcoin Script y Taproot para lograr un resumen optimista. Según la firma Lamport (también conocida como compromiso de bits), se establece una conexión entre dos UTXO de Bitcoin para implementar scripts de Bitcoin con estado. Al comprometerse con un programa grande en una dirección Taproot, los operadores y validadores participan en extensas interacciones fuera de la cadena, lo que resulta en una pequeña huella dentro de la cadena. Si ambas partes cooperan, se pueden realizar cálculos arbitrariamente complejos y con estado fuera de la cadena sin dejar ningún rastro en la cadena. Si ambas partes no cooperan, cuando ocurre una disputa, se requiere la ejecución en cadena. Como resultado, BitVM amplía enormemente los posibles casos de uso de Bitcoin, permitiendo que Bitcoin sirva no sólo como moneda sino también como plataforma de verificación para una variedad de aplicaciones descentralizadas y tareas informáticas complejas.
Sin embargo, aunque la tecnología BitVM tiene grandes ventajas en la expansión de Bitcoin, todavía se encuentra en sus primeras etapas y todavía existen algunos problemas en términos de eficiencia y seguridad. Por ejemplo: (1) Los desafíos y las respuestas requieren múltiples interacciones, lo que resulta en costosas tarifas de manejo y largos ciclos de desafío; (2) los datos de la firma única de Lamport son largos y es necesario reducir la longitud de los datos; (3) La función hash es complejo y requiere una función hash compatible con Bitcoin para reducir costos; (4) El contrato de BitVM existente es enorme y la capacidad del bloque de Bitcoin es limitada. Se pueden usar menos s para implementar menos BitVM, ahorrando espacio en el bloque de Bitcoin y mejorando la eficiencia de BitVM; (5 ) El BitVM existente adopta un modelo de permiso. Solo los miembros de la alianza pueden iniciar desafíos y está limitado a solo dos partes. Debería extenderse a un modelo de desafío multipartito sin permiso para reducir aún más la suposición de confianza. Con este fin, este artículo propone algunas ideas de optimización para mejorar aún más la eficiencia y seguridad de BitVM.
2. Principio de BitVM
BitVM se posiciona como un contrato fuera de la cadena de Bitcoin y se compromete a promover las funciones del contrato de Bitcoin. Actualmente, los scripts de Bitcoin no tienen ningún estado, por lo que cuando se ejecuta un script de Bitcoin, su entorno de ejecución se restablece después de cada script. No existe una forma nativa para que el script 1 y el script 2 tengan el mismo valor x, y Bitcoin Script no lo admite de forma nativa. Sin embargo, aún puede usar códigos de operación existentes para hacer que el script de Bitcoin tenga estado a través de la firma única de Lamport. Por ejemplo, puede forzar que x en 1 y 2 tenga el mismo valor. Los participantes pueden ser penalizados si firman valores de x contradictorios. Los cálculos del programa BitVM se realizan fuera de la cadena, mientras que la verificación del resultado del cálculo se produce dentro de la cadena. El bloque de Bitcoin actual tiene un límite de 1 MB. Cuando el cálculo de verificación es demasiado complejo, se puede utilizar la tecnología OP para adoptar el modo de respuesta de desafío para admitir una verificación de cálculo de mayor complejidad.
Al igual que Optimistic Rollup y la propuesta MATT (Merkelize All The Things), el sistema BitVM se basa en protocolos a prueba de fraude y de desafío-respuesta, pero no requiere modificación de las reglas de consenso de Bitcoin. Las primitivas subyacentes de BitVM son simples y se basan principalmente en bloqueos hash, bloqueos de tiempo y grandes árboles Taproot.
El probador confirma byte por byte, pero verificar todos los cálculos en cadena sería demasiado costoso. Entonces, el verificador realiza una serie de desafíos cuidadosamente diseñados para refutar de manera sucinta las afirmaciones falsas del probador. Los probadores y validadores prefirman conjuntamente una serie de transacciones de desafío y respuesta que se utilizan para resolver disputas, lo que permite la verificación computacional universal en Bitcoin.
Los componentes clave de BitVM son:
3.Optimización de BitVM
3.1 Reducir la cantidad de interacciones OP basadas en ZK
Actualmente hay dos paquetes acumulativos principales: paquetes acumulativos ZK y paquetes acumulativos OP. Entre ellos, ZK Rollups se basa en la verificación de validez de ZK Proof, es decir, la prueba criptográfica de ejecución correcta, y su seguridad se basa en el supuesto de complejidad computacional; OP Rollups se basa en Fraud Proof, asumiendo que los estados enviados son correctos, estableciendo El período de desafío suele ser de 7 días y su seguridad supone que al menos una parte honesta en el sistema puede detectar el estado incorrecto y presentar una prueba de fraude. Supongamos que el número máximo de pasos del programa de desafío BitVM es 2 ^{ 32 } y la memoria requerida es 2 ^{ 32 }* 4 bytes, que son aproximadamente 17 GB. En el peor de los casos, se necesitan alrededor de 40 rondas de desafío y respuesta, aproximadamente medio año, y el guión total es de aproximadamente 150 KB. Hay una grave falta de incentivos en esta situación, pero casi nunca ocurre en la práctica.
Considere el uso de pruebas de conocimiento cero para reducir la cantidad de desafíos de BitVM, mejorando así la eficiencia de BitVM. De acuerdo con la teoría de la prueba de conocimiento cero, si los datos Datos satisfacen el algoritmo F, se demuestra que la prueba satisface el algoritmo de verificación Verificar, es decir, el algoritmo de verificación genera Verdadero; si los datos Datos no satisfacen el algoritmo F, se demuestra que la prueba no satisface el algoritmo de verificación Verify, es decir, el algoritmo de verificación genera False. En el sistema BitVM, si el retador no reconoce los datos enviados por el probador, se inicia un desafío.
Para el algoritmo F, utilice el método de dicotomía para dividirlo. Suponga que se necesitan 2 ^ n veces para encontrar el punto de error; si la complejidad del algoritmo es demasiado alta, n será grande y llevará mucho tiempo completarlo. Sin embargo, la complejidad del algoritmo de verificación Verify de la prueba de conocimiento cero es fija. Todo el proceso de prueba y el algoritmo de verificación Verify es público y el resultado es Falso. La ventaja de la prueba de conocimiento cero es que la complejidad computacional requerida para abrir el algoritmo de verificación Verify es mucho menor que el método binario para abrir el algoritmo original F. Por lo tanto, con la ayuda de la prueba de conocimiento cero, BitVM ya no desafía el algoritmo original F, sino el algoritmo de verificación Verify, lo que reduce el número de rondas de desafío y acorta el ciclo de desafío.
Finalmente, aunque la eficacia de la prueba de conocimiento cero y de la prueba de fraude depende de diferentes supuestos de seguridad, se pueden combinar para crear ZK Fraud Proof y realizar On-Demand ZK Proof. A diferencia del ZK Rollup completo, que ya no necesita generar pruebas ZK para cada transición de estado, el modelo On-Demand hace que ZK Proof solo sea necesario cuando hay desafíos, mientras que todo el diseño del Rollup sigue siendo optimista. Por lo tanto, el estado resultante sigue siendo válido por defecto hasta que alguien lo cuestione. Si no hay ningún desafío en un estado determinado, no es necesario generar ninguna prueba ZK. Sin embargo, si un participante inicia un desafío, se debe generar ZK Proof para verificar la exactitud de todas las transacciones en el bloque de desafío. En el futuro, podemos explorar la generación de ZK Fraud Proof para una única instrucción controvertida para evitar el costo computacional de generar ZK Proof todo el tiempo.
3.2 Firma única compatible con Bitcoin
En la red Bitcoin, las transacciones que siguen reglas de consenso son transacciones válidas, pero además de las reglas de consenso, también se introducen reglas de estandarización. Los nodos de Bitcoin solo reenvían transacciones estándar de transmisión, la única forma de empaquetar transacciones válidas pero no estándar es trabajando directamente con los mineros.
Según las reglas de consenso, el tamaño máximo de las transacciones heredadas (no Segwit) es de 1 MB, que ocupa todo el bloque. Pero el límite de estandarización para transacciones heredadas es de 100 kB. Según las reglas de consenso, el tamaño máximo de una transacción Segwit es 4 MB, que es el límite de peso. Sin embargo, el límite de estandarización de las transacciones de Segwit es de 400 kB.
La firma Lamport es un componente básico de BitVM. Reduce la longitud de la firma y la clave pública, lo que ayuda a reducir los datos de las transacciones y, por tanto, las tarifas de gestión. La firma única de Lamport requiere el uso de una función hash (como la función de permutación unidireccional f). En el esquema de firma única de Lamport, la longitud del mensaje es v bits, la longitud de la clave pública es 2 v bits y la longitud de la firma también es 2 v bits. La firma y la clave pública son largas y requieren una gran cantidad de gas de almacenamiento. Por lo tanto, existe la necesidad de encontrar esquemas de firma con funciones similares para reducir la longitud de las firmas y las claves públicas. En comparación con la firma única de Lamport, la firma única de Winternitz ha reducido significativamente la longitud de las firmas y de las claves públicas, pero aumenta la complejidad computacional de la firma y la verificación de la firma.
En el esquema de firma única de Winternitz, se utiliza una función especial P para asignar un mensaje de v-bit a un vector s de longitud n. El valor de cada elemento en s es {0,..., d}. El esquema de firma única de Lamport es el esquema de firma única de Winternitz en el caso especial de d= 1. En el esquema de firma única de Winternitz, la relación entre n, d, v satisface: n≈v/log 2(d+ 1). Cuando d= 15, hay n≈(v/4)+ 1. Para una firma Winternitz que contiene n elementos, la longitud de la clave pública y la longitud de la firma son 4 veces más cortas que en el esquema de firma única de Lamport. Sin embargo, la complejidad de la verificación de firmas se multiplica por 4. El uso de d= 15, v= 160, f=ripemd 160(x) en BitVM para implementar la firma única de Winternitz puede reducir el tamaño del compromiso de bits en un 50 %, reduciendo así las tarifas de transacción de BitVM en al menos un 50 %. En el futuro, mientras se optimiza la implementación existente de Winternitz Bitcoin Script, se podrán explorar esquemas de firma única más compactos expresados en Bitcoin Script.
3.3 Funciones hash compatibles con Bitcoin
Según las reglas de consenso, el tamaño máximo de P 2 TR es 10 kB, y el tamaño máximo del testigo P 2 TR es el mismo que el tamaño máximo de transacción de Segwit, que es 4 MB. Sin embargo, el límite superior de estándard del testigo P 2 TR es 400 kB.
Actualmente, la red Bitcoin no admite OP _CAT y las cadenas no se pueden unir para la verificación de ruta de Merkle. Por lo tanto, es necesario utilizar scripts de Bitcoin existentes para implementar una función hash compatible con Bitcoin con un tamaño y un tamaño de testigo óptimos para admitir la función de verificación de prueba de inclusión de merkle.
BLAKE 3 es una versión optimizada de la función hash BLAKE 2 e introduce el modo de árbol Bao. En comparación con el BLAKE 2 s, el número de rondas de su función de compresión se reduce de 10 a 7. La función hash BLAKE 3 dividirá su entrada en fragmentos consecutivos de 1024 bytes de tamaño; el último fragmento puede ser más corto pero no vacío. Cuando solo hay un fragmento, el fragmento es el nodo raíz y el único nodo del árbol. Organice estos fragmentos como nodos hoja de un árbol binario y luego comprima cada fragmento de forma independiente.
Cuando se utiliza BitVM para verificar el escenario de prueba de inclusión de Merkle, la entrada de la operación hash se compone de dos valores hash de 256 bits, es decir, la entrada de la operación hash es de 64 bytes. Cuando se utiliza la función hash BLAKE 3, estos 64 bytes se pueden asignar dentro de un solo fragmento, y toda la operación hash BLAKE 3 solo necesita aplicar la función de compresión una vez a un único fragmento. En la función de compresión de BLAKE 3, es necesario ejecutar la función de ronda 7 veces y la función de permutación 6 veces.
En la actualidad, en BitVM se han completado operaciones básicas como XOR, suma modular y desplazamiento de bits a la derecha según los valores de u 32, y la función hash BLAKE 3 implementada por el script de Bitcoin se puede ensamblar fácilmente. Utilice 4 bytes separados en la pila para representar u 32 palabras para implementar u 32 suma, u 32 XOR bit a bit y u 32 rotaciones bit a bit requeridas por BLAKE 3. El actual script de Bitcoin con función hash de BLAKE 3 tiene un total de aproximadamente 100 kB, lo que es suficiente para construir una versión de juguete de BitVM.
Además, estos códigos BLAKE 3 se pueden dividir, lo que permite a Verifier y Prover reducir significativamente los datos en cadena necesarios al dividir la ejecución en el juego de desafío-respuesta a la mitad en lugar de ejecutarlo por completo. Finalmente, use el script de Bitcoin para implementar funciones hash como Keccak-256 y Grøstl, seleccione la función hash más compatible con Bitcoin y explore otras funciones hash nuevas compatibles con Bitcoin.
3,4 menos BitVM
less s es un método para ejecutar contratos inteligentes fuera de la cadena mediante el uso de firmas Schnorr. El concepto de Scripless nació de Mimblewimble, que no almacena datos permanentes excepto el núcleo y su firma.
Las ventajas de less s son funcionalidad, privacidad y eficiencia.
less s es un enfoque para diseñar protocolos criptográficos en Bitcoin que evita la necesidad de ejecutar contratos inteligentes explícitos. La idea central es utilizar algoritmos criptográficos para lograr la funcionalidad deseada en lugar de utilizar scripts para lograr la funcionalidad. Las firmas de adaptador y las firmas múltiples son los componentes básicos originales de less s. Usando menos correos electrónicos, puede lograr transacciones más pequeñas que las transacciones normales y reducir las tarifas de transacción.
Con la ayuda de less s, se puede utilizar la firma de adaptador y firma múltiple de Schnorr, que ya no proporciona valores hash ni preimágenes hash como la solución BitVM, y también puede realizar el compromiso de puerta lógica en el circuito BitVM, ahorrando así BitVM. espacio de script y mejora de la eficiencia de BitVM. Aunque el esquema less existente puede reducir el espacio del script BitVM, requiere una gran cantidad de interacción entre el probador y el retador para combinar la clave pública. En el futuro, mejoraremos esta solución e intentaremos introducir Scripless en módulos de funciones BitVM específicos.
3.5 Desafío multipartito sin permiso
La razón por la que los desafíos actuales de BitVM requieren permiso de forma predeterminada es que el UTXO de Bitcoin solo se puede ejecutar una vez, lo que permite que un verificador malicioso "desperdicie" el contrato desafiando a un probador honesto. BitVM está actualmente limitado al modo de desafío bipartito. Un probador que intenta hacer el mal puede lanzar simultáneamente un desafío con un verificador que controla, "desperdiciando" así el contrato, haciendo que el acto malvado tenga éxito y otros verificadores no puedan evitar el comportamiento. Por lo tanto, basado en Bitcoin, es necesario estudiar un protocolo de desafío OP multipartito sin permiso, que pueda extender el modelo de confianza 1 de n existente de BitVM a 1 de N. Entre ellos, N es mucho mayor que n. Además, es necesario estudiar y resolver el problema de los retadores que se confabulan con los probadores o cuestionan maliciosamente contratos "desperdiciados". En última instancia, implementar el protocolo BitVM con menos confianza.
Desafíos multipartidistas sin permiso, que permiten que cualquiera participe sin una lista de permisos. Esto significa que los usuarios pueden retirar monedas de L2 sin la participación de ningún tercero de confianza. Además, cualquier usuario que quiera participar en el protocolo de desafío OP puede cuestionar y eliminar retiros no válidos.
Extender BitVM a un modelo de desafío multipartito sin permiso requiere resolver los siguientes ataques:
En el futuro, exploraremos el modelo de desafío multipartito sin permiso de BitVM que es adecuado para las características de Bitcoin y puede resistir los problemas de ataque anteriores.
4. Conclusión
La exploración de la tecnología BitVM acaba de comenzar y en el futuro se explorarán e implementarán más direcciones de optimización para lograr la expansión de Bitcoin y hacer prosperar el ecosistema de Bitcoin.
referencias
Enlace original