En octubre pasado, Robin Linus de Zerosync lanzó una especie de 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 el campo de la informática podría aplicarse en el script de Bitcoin: a puerta NAND, uno de los primitivos básicos de la informática a nivel físico/eléctrico. Todos los cálculos posibles se pueden 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” esa ruta de gasto, cada uno empujando un 1 o 0 a 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. Esto es para que una vez que alguien decide qué ingresar en la puerta NAND, no pueda cambiar de opinión sin perder dinero.
Se puede compactar una gran cantidad de scripts de puerta NAND en un árbol de raíz principal, y una vez que alguien se compromete con los valores de bits fuera de la cadena para ingresar a ese cálculo, la otra parte puede desafiarlos en cualquier paso individual del cálculo para demostrar que es así. ejecutándose correctamente en la cadena. Cada “impugnación” permite a la parte impugnada demostrar que la puerta individual se calculó correctamente; de lo contrario, la otra parte puede reclamar los fondos después de un bloqueo de tiempo. Yendo y viniendo así, si se impugna un cálculo, se garantiza que la parte que hace trampa eventualmente será atrapada y perderá fondos.
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 intenta hacerlo. mentir sobre los resultados.
Una de las razones para diseñar BitVM fue establecer conexiones bidireccionales a cadenas laterales u otros sistemas. El esquema ofrece una primitiva muy poderosa en ese caso de uso, la capacidad de hacer cumplir que los fondos se entreguen a una parte o a la otra en función de la exactitud de un cálculo arbitrario, es decir, una verificación de validez para determinar si un pegout es válido de acuerdo con las reglas de las cadenas laterales. . El problema es que solo 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 hace que el sistema siga siendo confiable.
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 básicamente tiene que adivinar dónde está la puerta NAND individual en el cálculo en la que el probador tendría que ubicarse y revelar ambas preimágenes a un bit que le daría los fondos al verificador. Hasta que esa puerta específica sea desafiada en la cadena, el probador aún puede responder correctamente a un desafío y alargarlo. Esto puede llevar mucho tiempo y ser ineficiente.
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 la creación de instancias de múltiples instancias de BitVM en paralelo para lograrlo y, por lo tanto, aumenta las ineficiencias con el diseño original de dos partes.
BitVM 2
Robin propuso recientemente un esquema de diseño para BitVM 2. Este esquema busca hacer algunas compensaciones en comparación con el diseño original para mitigar sus dos principales deficiencias. BitVM 2 acorta la duración del protocolo de desafío/respuesta de una serie indeterminada de transacciones que podrían ser más de docenas en el peor de los casos, a dos rondas en el desafío/respuesta. Además de esto, con el uso de salidas de conector permite 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 rastro computacional sin procesar y pasar a usarlas para implementar un verificador de prueba de conocimiento cero SNARK general (una de las primitivas centrales que Robin pretendía implementar desde el principio usando BitVM). ). En lugar de colocar la entrada sin procesar en el rastro computacional 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 a prueba de conocimiento cero en combinación con una salida afirmada del cálculo.
Además de abstraer la implementación de cálculo con un ZKP, los scripts de hoja tapleaf se están expandiendo masivamente desde una única puerta NAND por hoja a una subfunción completa del verificador ZKP. En lugar de que el protocolo de respuesta al desafío se base en que el verificador adivine en qué puerta NAND intentó hacer trampa el probador, desafiando selectivamente en una sola puerta, el verificador puede demostrar que la salida completa de una subfunción no es válida según la entrada.
Al igual que BitVM 1, el contrato se negocia previamente mediante transacciones prefirmadas y scripts de ramificación. Los fondos vinculados al BitVM se envían a un multifirma n de n que firma dos posibles transacciones de ejecución, una en la que no se produce ningún desafío y otra en la que se produce un desafío. Para iniciar el proceso de ejecución del contrato, el probador 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 gastan en la transacción sin desafío.
Aquí es donde el diseño permite que cualquiera pueda participar como verificador. La salida del conector A tiene una segunda transacción prefirmada que puede gastarla, la transacción de desafío. Esta es una transacción prefirmada que paga al probador un bono en bitcoin, pero la salida del conector A no es suficiente para financiarla. Literalmente, cualquiera puede agregar sus propias entradas para financiar la transacción y gastar la salida A del conector, lo que invalida la transacción de retiro sin desafío para el probador (una de las entradas que no necesita desafío existe).
Esto fuerza el camino del desafío. La salida B del conector también se puede gastar mediante una transacción prefirmada, la transacción de afirmación, en la salida de cada subfunción en todo el contrato BitVM 2. 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 vinculados originales, se gastan en la segunda transacción de retiro exitosa para el probador después del bloqueo de tiempo.
La salida del conector C también puede gastarla 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 conector 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 recuperarlos 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 gastar después de un tiempo de espera mucho más largo que el retiro sin desafío para invalidar tanto la transacción sin desafío como la de afirmación, quemando las monedas vinculadas.
Esto reduce lo que podría ser una cadena ridícula 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 son muy masivas), mientras que en el proceso se crea literalmente el conjunto de verificadores para la instancia de BitVM 2. cualquier persona con bitcoins que financie la transacción de desafío.
BitVM 2 podría terminar siendo un avance significativo con respecto a la ola de acumulaciones y otras capas 2 que apuntan a utilizar BitVM como una vinculación bidireccional. El operador de un rollup (el prover en BitVM) puede usar sus propios fondos para cubrir los retiros de los usuarios que se han vinculado al sistema y retirar periódicamente esos fondos de BitVM para compensarse. Cualquier El usuario o la parte interesada podría entonces penalizarlo quemando sus fondos si pudiera presentar pruebas de que el operador no estaba procesando todos los retiros correctamente.
Es importante tener en cuenta que, en última instancia, la seguridad de una instancia de BitVM 2 está respaldada por el poseedor de claves n de n, aunque las personas que no participan en ella aún pueden desafiar al probador como verificador. Pero debido a que el probador tiene una salida eficiente en el 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 las clavijas bidireccionales que utilizan BitVM. Una vez más, Robin ha demostrado ser un auténtico mago.
