En octubre pasado, Robin Linus de Zerosync lanzó una pequeña bomba en forma de BitVM. Una de las críticas más antiguas a Bitcoin es que no es posible crear programas arbitrarios para controlar cómo se gasta o bloquea el dinero. Bitcoin sólo tiene una capacidad de programación muy limitada en su lenguaje de programación y las primitivas disponibles son extremadamente limitadas. Puedes verificar una firma, puedes agregar un bloqueo de tiempo a algo, puedes manipular datos de algunas maneras simples, pero eso es todo.
Puede programar un UTXO de Bitcoin para que requiera una verificación de firma, una verificación de bloqueo de tiempo, etc. Pero no puede programarlo para que se desbloquee en función de condiciones arbitrarias. La idea de Robin con BitVM fue que una única primitiva en informática podría aplicado en el script de Bitcoin: una puerta NAND, una de las primitivas básicas de la informática a nivel físico/eléctrico. Cualquier cálculo posible se puede construir a partir de puertas NAND.
De hecho, el script puede verificar una puerta NAND gracias a un ingenioso truco que utiliza OP_BOOLAND y OP_NOT. OP_BOOLAND es una operación AND, lo opuesto a NAND. OP_NOT toma un valor binario 1 o 0 y lo invierte. Esto en conjunto le permite aplicar una única operación NAND directamente en el script. En combinación con hashlocks, se puede crear un script de puerta NAND donde cada campo de entrada y salida tenga dos posibles hashlocks para “desbloquear” para la ruta de consumo, cada uno empujando un 1 o 0 en la pila para realizar la operación NAND. Cada script también tiene una ruta donde si puedes revelar ambos preimágenes a un valor de un solo bit, puede reclamar los fondos inmediatamente. Es decir, una vez que alguien decide qué ingresar en la puerta NAND, no puede cambiar de opinión sin perder dinero.
Se puede comprimir una gran cantidad de scripts de puerta NAND en un árbol con raíces, y una vez que alguien se compromete a ingresar los valores de bits fuera de la cadena en ese cálculo, la otra parte puede desafiarlos en cualquier paso individual del cálculo. para demostrar que se realiza correctamente en la cadena. Cada “desafío” permite a la parte desafiada demostrar que la puerta única se calculó correctamente; de lo contrario, la otra parte puede reclamar el dinero después de un bloqueo de tiempo. Yendo y viniendo así, si se cuestiona un cálculo, se garantiza que la parte que hace trampa eventualmente será atrapada y perderá dinero.
las limitaciones
La principal limitación de BitVM es que solo pueden participar las personas involucradas en la creación de un contrato de BitVM, y los roles son muy limitados. Está el probador, la persona que afirma cómo ocurrió el cálculo fuera de la cadena, y el verificador, la persona que puede cuestionar el cálculo y obligar a que se pruebe en la cadena si el probador no completa el cálculo fuera de la cadena o lo intenta. mentir sobre los resultados.
Una de las razones para diseñar BitVM fue establecer pines bidireccionales para cadenas laterales u otros sistemas. El esquema ofrece una primitiva muy poderosa en el caso de que se le dé a una u otra parte la posibilidad de hacer cumplir los medios basándose en la exactitud de un cálculo arbitrario, es decir, una verificación de validez de si un pegout es válido de acuerdo con las reglas de una cadena lateral. El problema es que sólo las personas que tienen las claves de ese BitVM UTXO pueden decir “¡Oye, estás haciendo trampa!” cuando alguien lo está y participar en el protocolo de desafío. En última instancia, esto significa que todavía se confía en el sistema.
Otra limitación es que el protocolo de respuesta al desafío puede ser muy largo. Si alguien se da cuenta de que el resultado del cálculo le hará perder dinero y deja de responder, el verificador esencialmente tiene que adivinar dónde está la puerta NAND individual en el cálculo en la que el probador debe permanecer y revelar ambos modelos durante un tiempo. daría al verificador los medios. Hasta que se desafíe esa puerta específica en la cadena, el probador aún puede responder correctamente a un desafío y sacarla. Esto puede llevar mucho tiempo y ser ineficaz.
Se han realizado algunas mejoras a este diseño desde la propuesta original para permitir que existan múltiples verificadores en el sistema con el probador, para crear un modelo de confianza 1 de n donde solo se requiere un verificador para desafiar a un probador deshonesto. Sin embargo, esto requiere crear instancias de múltiples instancias de BitVM en paralelo para lograrlo y, por lo tanto, aumenta la ineficiencia del diseño bipartito original.
BitVM 2
Robin propuso recientemente un esquema de diseño para BitVM 2. Este esquema busca hacer algunas concesiones del diseño original a favor de mitigar las dos deficiencias principales. BitVM 2 acorta la duración del protocolo de desafío/respuesta de una serie indefinida de transacciones que podrían ser hasta docenas en el peor de los casos a dos rondas de desafío/respuesta. Además de esto, permite con el uso de salidas de enchufe alguien actuar como verificador. No es necesario que alguien sea miembro involucrado en el establecimiento de BitVM para desafiar a un demostrador deshonesto.
El cambio fundamental aquí es dejar de usar directamente puertas NAND de script para implementar directamente el rastreo de cálculo sin procesar y pasar a usarlas para implementar un verificador general SNARK a prueba de conocimiento cero (una de las primitivas centrales, que Robin pretendía desde el principio). comenzar a implementar usando BitVM). En lugar de colocar la entrada sin procesar en el seguimiento de cálculo sin procesar y ejecutarla puerta por puerta en sus propios scripts tapleaf, la entrada de la instancia de BitVM 2 sería simplemente una entrada sin evidencia combinada con una salida afirmada del cálculo.
Además de abstraer la implementación de cálculo con un ZKP, los scripts tapleaf se expanden masivamente desde una única puerta NAND por hoja a una subfunción completa del verificador ZKP. En lugar de que el protocolo de desafío-respuesta dependa de que el verificador adivine en qué puerta NAND intentó hacer trampa el probador y desafíe selectivamente en una sola puerta, el verificador puede demostrar que la salida de una subfunción completa no es válida según la entrada.
Al igual que BitVM 1, el contrato se negocia previamente mediante transacciones prefirmadas y scripts de bifurcación. Los fondos adjuntos a BitVM se envían a un multisig n de n, que firma dos posibles transacciones de ejecución, una en la que no se produce un desafío y otra en la que se produce un desafío. Para iniciar el proceso de ejecución del contrato, el proveedor de pruebas inicia una transacción inicial. Esta transacción de inicio se compromete con el valor de salida ‘y’ que, según afirman, produce el cálculo e incluye tres salidas: una salida bloqueada en el tiempo que se incluye en la transacción de ejecución sin desafío, una salida de conector A y una salida de conector B, las cuales También se utilizan en la transacción sin desafío.
Aquí es donde el diseño permite que todos participen como verificadores. La salida de conexión A tiene otra transacción prefirmada que puede utilizarla, la transacción de desafío. Esta es una transacción prefirmada que paga al probador un bono en bitcoin, pero la salida del enchufe A no es suficiente para financiarla. Cualquiera puede literalmente agregar sus propias entradas para financiar la transacción y usar la salida A del conector, invalidando la transacción sin cuestionar al probador (una de las entradas, no necesita desafío, existe).
Esto fuerza el camino del desafío. La salida B del conector también se puede utilizar mediante una transacción prefirmada, la transacción de afirmación, para generar la salida de cada subfunción del contrato BitVM 2 completo. Esto requiere una transacción grande con una gran cantidad de datos, pero recuerde, el resultado final ‘y’ que el probador afirma que el cálculo producido ya estaba comprometido en la transacción inicial. Esto crea dos salidas. Una es una salida con bloqueo de tiempo, la otra es una salida de conector C. Ambas salidas, además de los fondos asociados originales, se utilizan en la segunda transacción de pago exitosa para el probador después del bloqueo de tiempo.
La salida del conector C también puede ser utilizada por cualquiera que pueda demostrar que cualquier salida de subfunción en el contrato BitVM 2 produce una salida no válida. Esto requiere una transacción muy grande porque el script necesario para demostrar que una sección completa del cálculo de BitVM es incorrecta es enorme, pero en esta única transacción un verificador puede reclamar las monedas en la salida del enchufe con una prueba válida. Esto invalida la segunda transacción de retiro para el probador y efectivamente quema las monedas. La única manera de restaurarlos en este punto es si el probador y todo de los verificadores en el multisig de financiación original n de n cooperan para recuperarlos. La salida del conector B en la transacción de inicio también se puede usar después de un tiempo de espera mucho más largo que el de la extracción sin desafío para invalidar tanto las transacciones sin desafío como las de afirmación y quemar las monedas fijadas.
Esto reduce lo que podría ser una ridícula cadena de transacciones en la propuesta original de BitVM para hacer cumplir el resultado correcto del contrato a un máximo de cuatro transacciones (aunque ciertamente muy masivas), mientras que en el proceso el conjunto de verificadores para BitVM 2 -la instancia literalmente. cualquier persona con bitcoins que financie la transacción de desafío.
BitVM 2 podría terminar siendo un avance significativo sobre la ola de paquetes acumulativos y otras capas 2 que apuntan a usar BitVM como un pin bidireccional. El operador de un rollup (el prover en BitVM) puede utilizar sus propios fondos para cubrir los pagos de los usuarios que se han conectado al sistema y retirar periódicamente estos fondos de BitVM para compensarse. Alguien El usuario o la parte interesada podría castigarlo quemando su dinero si pudiera demostrar que el operador no procesó todos los pagos correctamente.
Es importante tener en cuenta que la seguridad de una instancia de BitVM 2 es finalmente detenida por el poseedor de claves n de n, aunque las personas que no participan en ella aún pueden desafiar al probador como verificador. Sin embargo, debido a que el probador tiene una salida eficiente en caso de que no haya retadores y cualquiera puede financiar la transacción de desafío para actuar como verificador, el multisig de financiamiento n de n podría seguir una ceremonia de configuración y eliminación de claves similar al lanzamiento de Zcash para mejorar. su seguridad.
BitVM 2 probablemente terminará siendo un avance significativo en términos de mejorar la flexibilidad y el modelo de confianza de los dispositivos bidireccionales que utilizan BitVM. Una vez más, Robin ha demostrado que es un auténtico mago.
Fuente Original Bitcoin Magazine – Bitcoin News, Articles and Expert Insights
