Autor original: Janos Nick, Blockstream
Texto original compilado por: Bai Ding, Faust, Geek Web3
Resumen: Este artículo señala de manera concisa pero precisa cómo hacer que Bitcoin admita la función de verificación ZK. Los temas específicos cubiertos incluyen los defectos funcionales de Bitcoin UTXO y scripts, conceptos como Taproot y OP_CAT, y BitVM y Chain State Proof. contenido general. El artículo presenta un punto de vista relativamente claro:
La introducción de ZK en el protocolo Bitcoin es una tendencia inevitable. Hay dos rutas para esto: una es permitir que los scripts de Bitcoin admitan directamente la verificación SNARK, que requiere la ayuda del código de operación OP_CAT, y la probabilidad de que OP_CAT eventualmente pase. es muy alto; la segunda ruta se basa en BitVM, es necesario introducir un método a prueba de fraude, y el equipo de ZeroSync también propuso Chain State Proofs para reducir el costo de la verificación de datos históricos del cliente de nodo.
Texto: Para comprender Bitcoin más profundamente, es mejor tratarlo como un sistema social. Cuando se lanzó Bitcoin en sus inicios, los desarrolladores determinaron los programas de software que los nodos de Bitcoin necesitaban ejecutar, del mismo modo que determinaban un conjunto de reglas que debía seguir un sistema social. La razón por la que el sistema social de Bitcoin puede funcionar de manera estable es porque todos tienen un cierto consenso sobre cuestiones clave como "cuál es la esencia de Bitcoin" y "cuál debería ser". Por supuesto, no es fácil llegar a un consenso. desacuerdo generalizado y en evolución sobre las cuestiones mencionadas.
Esto se remonta al origen histórico de Bitcoin. Cuando Satoshi Nakamoto publicó el documento técnico de Bitcoin, dijo una vez: Estoy trabajando en un nuevo sistema de pago electrónico. Este sistema es completamente P2P y no necesita depender de ningún tercero. Este pasaje fue publicado en la lista de correo Cypherpunks (un grupo de discusión por correo electrónico establecido en 1992 por un grupo de criptógrafos y entusiastas de la tecnología preocupados por la protección de la privacidad y la tecnología de criptografía).
Sin embargo, Bitcoin limita el rendimiento de datos en el nivel de diseño del producto. La cantidad de transacciones que puede procesar por unidad de tiempo es limitada. Si la cantidad de transacciones a procesar aumenta rápidamente, los usuarios iniciarán una guerra de precios para completar con éxito la transacción rápidamente, aumentando rápidamente las tarifas de procesamiento pagadas. La única transacción con la tarifa de gestión más alta en la red Bitcoin se produjo después de que la recompensa del bloque se redujera a la mitad en 2024, y la tarifa de gestión para una transacción con una prioridad media en la cadena alcanzó los 150 dólares. Se puede decir que las costosas tarifas de transacción de la red Bitcoin se han convertido en un problema.
Para resolver el problema de las tarifas de transacción, la gente ha invertido muchos recursos en el desarrollo de Lightning Network. Pero según un artículo publicado en 2016, en la práctica Lightning Network solo podía soportar a decenas de millones de usuarios como máximo, sin lograr hacer realidad su visión de un sistema de pagos global.
Además del hecho de que las tarifas de transacción son demasiado caras, también existe el problema de que Bitcoin nunca ha podido alcanzar el anonimato que imaginaba. Satoshi Nakamoto señaló en un grupo de discusión por correo electrónico cypherpunk que Bitcoin tiene una función de protección de la privacidad y que el iniciador de la transacción puede ser completamente anónimo. Sin embargo, aunque los iniciadores de transacciones no requieren KYC, los datos de las transacciones en la cadena Bitcoin filtran mucha información, exponiendo en gran medida la privacidad del usuario.
Aunque hay algunos clientes de billetera con funciones de privacidad que resuelven los problemas anteriores hasta cierto punto, los desarrolladores de estos clientes de billetera enfrentan amenazas de diversos tamaños. Por ejemplo, los desarrolladores de la billetera Samourai CoinJoin fueron arrestados por el FBI en abril de 2024, y una semana después, los desarrolladores de la billetera Wasabi cerraron su componente de coordinación CoinJoin. Obviamente, estos llamados monederos de privacidad no son del todo dignos de confianza de los usuarios.
En resumen, muchos de los conceptos de Bitcoin están lejos de realizarse hasta el día de hoy, y las tecnologías relacionadas todavía están en continuo desarrollo. Aun así, muchas personas en la comunidad de Bitcoin creen que el diseño del protocolo de Bitcoin debería permanecer sin cambios, pero también hay muchas personas, como yo, a las que les apasiona realizar mejoras en Bitcoin. Entonces, ¿en qué dirección debería mejorar Bitcoin?
En respuesta a los problemas anteriores, hay muchas propuestas en la comunidad Bitcoin, y las que tienen el mejor efecto teórico deberían estar relacionadas con ZK y SNARK. Con ZK y SNARK, se pueden lograr las siguientes características:
1. Mejorar significativamente la privacidad: utilice Peterson homomórfico para comprometerse con el monto de la transacción y la Prueba de rango para mejorar significativamente la privacidad del usuario (como se hace en la cadena lateral Element de Blockstream; ocultar los rastros de las transacciones mediante firmas vinculables (como Monero); Zcash).
2. Mejorar el rendimiento de las transacciones
De hecho, existen muchos medios técnicos que pueden solucionar los problemas existentes en Bitcoin, pero ¿por qué estas tecnologías no se han agregado al protocolo Bitcoin hasta hoy? Esto se debe a que el protocolo Bitcoin es difícil de modificar. No existe una organización similar a la Fundación Ethereum en el ecosistema de Bitcoin. Cualquier modificación del protocolo requiere un alto grado de consenso de la comunidad. Esto implica muchos juegos y controles y equilibrios de poder, por lo que, a diferencia de Ethereum, habrá códigos de operación EVM cada vez. año Ha habido muy pocas actualizaciones del protocolo Bitcoin desde su inicio.
De hecho, es bueno que el protocolo sea difícil de modificar hasta cierto punto. Si modificar el protocolo Bitcoin es fácil, también será fácil realizar cambios y ataques maliciosos. Esto plantea la pregunta: ¿Existe algún medio para mejorar el rendimiento de Bitcoin sin cambiar el diseño del protocolo Bitcoin?
Para responder a esta pregunta, primero debemos revisar lo que sabemos sobre Bitcoin. Si queremos transferir Bitcoin a otra persona, debemos crear una transacción y transmitirla a la red Bitcoin. Los datos de salida de la transacción indicarán la cantidad de BTC transferida y el destinatario de BTC puede crear una nueva transacción para gastar el BTC recibido. Posteriormente, esta nueva transacción generará nuevos datos de salida y enviará BTC a otros.
Lo que cabe señalar aquí es que Bitcoin no tiene un estado global como Ethereum, especialmente un estado sin cuentas, solo datos de salida de transacciones. El resultado de cada transacción tiene dos estados: gastado por el destinatario o no gastado. El resultado de la transacción no gastada es el conocido UTXO.
Por supuesto, además de la cantidad de BTC asociada, cada resultado de transacción tiene un programa adicional escrito en un lenguaje llamado Bitcoin Script. Quien pueda proporcionar el testigo de prueba correcto para este programa puede gastar el resultado de la transacción (UTXO). Bitcoin Script en sí es un lenguaje de programación basado en pila que contiene una serie de códigos de operación. Los apéndices UTXO antes mencionados a menudo se componen de múltiples códigos de operación. Completan cálculos basados en la pila y devuelven los resultados a la pila.
Hay muchos tipos de scripts de Bitcoin comunes que han existido desde el comienzo de Bitcoin. Por ejemplo, el script más común en Bitcoin consta de una clave pública + un código de operación que verifica una firma digital. Este opcode estipula que para gastar/desbloquear un UTXO se debe presentar la firma digital de la clave pública correspondiente.
Aquí resumimos la funcionalidad de Bitcoin Script. Primero, ¿qué puede hacer Bitcoin Script?
· La pila se puede reorganizar, verificar la igualdad (use la verificación de igualdad para verificar si se cumplen condiciones específicas, garantizando así la seguridad y validez de las transacciones) y se pueden realizar operaciones de sucursal similares a if-else.
· Puede realizar operaciones aritméticas limitadas en números de 32 bits, concretamente sumas y restas.
· Se pueden aplicar hash a los datos y se pueden verificar las firmas ECDSA y Schnorr.
¿Qué no puede hacer Bitcoin Script?
· No hay bucles, saltos ni recursiones, es decir, no es Turing completo y sus capacidades de programación son muy limitadas.
· Las operaciones bit a bit no son posibles. Falta de códigos de operación para multiplicación y división.
· No se pueden concatenar elementos en la pila.
· Poca capacidad para leer e inspeccionar datos de transacciones en cadena.
· Los scripts de Bitcoin no pueden acceder directamente al monto de cada transacción y no hay forma de pasar el estado (los UTXO son de un solo uso, los antiguos se destruyen y se generan otros nuevos con cada transferencia).
En las primeras versiones de Bitcoin, algunas de las cosas que "no se pueden hacer" en los scripts anteriores en realidad se pueden hacer, pero Satoshi Nakamoto deshabilitó algunas funciones más tarde porque Satoshi Nakamoto descubrió que había lagunas en estos códigos de operación. Por ejemplo, puede utilizar el código de operación OP_CAT, que combina dos elementos en la pila, para atacar de forma remota un nodo de Bitcoin y provocar que colapse. Satoshi Nakamoto deshabilitó OP_CAT por precaución, y también se deshabilitaron algunos otros códigos de operación.
Entonces, ¿Bitcoin Script puede verificar los SNARK? Aunque en teoría el script de Bitcoin no es completo según Turing, sus operaciones básicas son suficientes para verificar cualquier cálculo. Sin embargo, en la práctica, la verificación SNARK no se puede implementar porque el tamaño del programa requerido para el paso de verificación excede el límite máximo de bloque de Bitcoin de 4 MB.
Tal vez podamos intentar realizar operaciones aritméticas en campos finitos grandes, pero el costo es muy alto. Por ejemplo, la multiplicación de dos enteros de 254 bits implementada por BitVM, el tamaño del script de Bitcoin relacionado alcanza casi 8 KB.
Además, verificar las pruebas de Merkle sin OP_CAT es costoso ya que requiere operaciones similares a un bucle for.
Volviendo a la pregunta anterior: ¿por qué no podemos simplemente cambiar el protocolo de Bitcoin y agregar códigos de operación más potentes?
Como se mencionó anteriormente, es muy difícil llegar a un consenso mayoritario sobre las nuevas reglas del protocolo porque no existe un tomador de decisiones centralizado en el ecosistema de Bitcoin. Cualquier propuesta para mejorar el script de Bitcoin tiene muchas objeciones. En la red Bitcoin, no existe una buena manera de medir si la comunidad ha alcanzado un consenso mayoritario, y forzar una actualización en este caso conducirá a una bifurcación de la cadena.
Por supuesto, Bitcoin no es completamente estático, siendo las actualizaciones más recientes SegWit en 2017 y Taproot en 2021.
La actualización de Taproot cambió muchas reglas y pasaron tres años y medio desde su lanzamiento teórico hasta su activación real. El factor clave para habilitar Taproot es que no cambia los supuestos de seguridad existentes y supone una mejora clara en el protocolo Bitcoin. Por ejemplo, permite usar firmas Schnorr en lugar de ECDSA, ambas se basan en el supuesto de logaritmo discreto y usan las mismas curvas elípticas, pero la primera es más eficiente y menos intensiva computacionalmente que la segunda.
Además, las mejoras de Taproot a Bitcoin se dividen principalmente en las siguientes tres partes:
Primero, Taproot reduce el costo de verificación de scripts con una gran cantidad de ramas selectivas, lo que permite que Bitcoin admita programas más complejos;
En segundo lugar, Taproot reduce los datos del script que deben revelarse en la cadena. Puede ensamblar varios scripts en un árbol Merkle, con cada script ubicado en una hoja diferente. Si desea activar un determinado script, solo necesita revelarlo. La hoja donde se ubica y la prueba de Merkle;
En tercer lugar, Taproot también añadió otros diseños mecánicos.
Dicho esto, dado que Bitcoin tiene un precedente de agregar funciones más potentes como Tarpoot, ¿por qué no agregar un código de operación dedicado para verificar SNARK? Esto se debe a que agregar el llamado código de operación OP_SNARK es muy diferente a una actualización de Taproot.
En primer lugar, hay muchas ideas de diseño para OP_SNARK y es difícil para la mayoría de las personas admitir una solución única. En segundo lugar, si se aprueba dicha propuesta, todos los nodos de Bitcoin deben admitir esta solución OP_SNARK específica, lo que agregará enormes desafíos técnicos; . carga.
Además, la complejidad del propio OP_SNARK también es un gran desafío. Taproot solo agrega alrededor de 1600 líneas de código, lo cual es aceptable si no se incluyen pruebas, mientras que OP_SNARK contiene código mucho más complejo.
Además, ¿quién revisará si se debe activar el código de operación OP_SNARK? ¿Cómo lograr consenso dentro del ecosistema Bitcoin sin que unas pocas personas entiendan sus detalles? Todas estas son preguntas. Por lo tanto, en general, la actualización de OP_SNARK no se realizará en poco tiempo.
Sin embargo, existen otras formas de verificar SNARK en Bitcoin Script. Podemos hacer que los scripts de Bitcoin sean más funcionales agregando códigos de operación más simples que permitan a las personas implementar programas de validación SNARK en sus scripts. Pero, de hecho, es muy difícil escribir un programa de verificación SNARK en el lenguaje de programación Bitcoin.
Como resultado, el equipo de investigación de Blockstream está desarrollando Simplicity, un lenguaje de programación diseñado para reemplazar Bitcoin Script. Simplicity está diseñado específicamente para sistemas de consenso blockchain e intencionalmente no es completo en Turing, lo que facilita el análisis estático y la verificación formal.
A continuación vamos a hablar de una propuesta muy simple pero pesada que podría hacer que Bitcoin Script sea más poderoso: el código de operación OP_CAT. Como mencionamos anteriormente, OP_CAT existía en la versión inicial de Bitcoin, pero este código de operación puede permitir que los nodos de Bitcoin sean atacados por DOS bajo ciertas condiciones, por lo que Satoshi Nakamoto lo deshabilitó. Ahora algunas personas en la comunidad de Bitcoin quieren volver a habilitarlo. . él.
Lo que hace OP_CAT es colocar los dos elementos en la parte superior de la pila, concatenarlos y luego volver a colocarlos en la pila. Esto suena muy simple, pero puede aportar enormes mejoras funcionales a los scripts de Bitcoin.
Por ejemplo, los scripts de Bitcoin originalmente no pueden acceder a información de estado, como la cantidad de transacciones en la cadena, pero con OP_CAT esto también será posible utilizar OP_CAT para verificar pruebas de Merkle. En resumen, OP_CAT es una actualización en el nivel del código de operación subyacente, que derivará en muchas funciones nuevas. Muchas personas han propuesto los efectos que se pueden lograr usando OP_CAT.
¿Y OP_CAT ayuda a verificar los SNARK en los scripts? La respuesta es que ayuda, porque la compatibilidad con la verificación de pruebas de Merkle ayuda a verificar los SNARK basados en FRI, y OP_CAT puede admitir esto. En el pasado, los scripts involucrados en la verificación SNARK podían haber sido demasiado grandes para caber en un bloque de Bitcoin; con OP_CAT se puede reducir el tamaño del programa.
OP_CAT se ha debatido durante muchos años y cada vez se reconoce más su papel en la inspección de transacciones (introspección). La ventaja de OP_CAT en comparación con otras propuestas es que ya existía antes en Bitcoin Script, lo que facilita llegar a un consenso en la comunidad. Sin embargo, la activación de OP_CAT también puede dañar los ingresos MEV de algunas personas, por lo que la comunidad Bitcoin aún no ha llegado a un consenso al respecto.
En resumen, puede haber una ruta potencial para que Bitcoin habilite la verificación de SNARK en scripts de Bitcoin al habilitar códigos de operación simples como OP_CAT. También vale la pena mencionar que existe una propuesta reciente llamada "Great Script Restoration" que permite la multiplicación de códigos de operación, permitiendo que todos los códigos de operación aritméticos funcionen con precisión arbitraria.
Además, cuando consideramos el impacto de OP_CAT en la red Bitcoin, podemos examinar el impacto en los operadores de nodos Bitcoin después de su aprobación. Para que Bitcoin sea resistente a la censura y descentralizado, la comunidad Bitcoin quiere que la mayor cantidad de personas posible ejecuten nodos para verificar los datos. Si Bitcoin admite las operaciones de verificación SNARK, el costo de ejecutar un nodo de Bitcoin aún no aumentará significativamente, lo que no dañará mucho la seguridad y la resistencia a la censura de Bitcoin.
Actualmente, un bloque de Bitcoin puede contener hasta 4 MB de datos y, como se espera que un bloque se extraiga cada 10 minutos, casi todos los bloques se pueden llenar con scripts de Bitcoin y testigos (similares a las firmas digitales). Convertido, cada bloque puede contener actualmente hasta 80 000 verificaciones de firmas y, en promedio, cada bloque admite entre 7 000 y 10 000 verificaciones de firmas. Mi CPU Intel 2020 tarda un promedio de 3,2 segundos en verificar un bloque de Bitcoin. Por supuesto, no es sólo la lenta verificación de firmas lo que afecta la velocidad de la verificación de bloques.
Además, si las transacciones de Bitcoin admiten la ZKización en el futuro, no parece perjudicial ampliar el tiempo de generación de las transacciones. Las billeteras de hardware utilizadas para el almacenamiento de activos a largo plazo tienden a tener pantallas y no son grandes. Su función es almacenar claves y generar firmas. Las carteras de hardware generalmente tienen una CPU débil, como una CPU de doble núcleo de 240 MHz con una cierta cantidad de memoria, que responde muy rápidamente al firmar transacciones de Bitcoin.
Hice una pequeña encuesta preguntando a los usuarios sobre el retraso máximo que aceptarían para que un dispositivo de firma generara una prueba, y muchas personas estaban de acuerdo con una espera más larga, especialmente si se podían lograr ganancias significativas. Entonces, si introducimos ZK en las transacciones de Bitcoin, no parece que haya muchos problemas.
Hemos dedicado mucho espacio a discutir cómo cambiar el diseño subyacente de Bitcoin arriba, pero de hecho hay muchos escenarios de aplicación que se pueden implementar sin cambiar Bitcoin. Aquí me gustaría destacar una aplicación relacionada con BitVM: Chain State Proofs, que combinada con ZK puede probar la validez del hash del bloque.
¿Qué cambios ha traído esta tecnología a Bitcoin? En primer lugar, con Chain State Proofs, la carga de trabajo de sincronización y verificación de los datos del calendario de Bitcoin se puede comprimir, lo que reduce significativamente el costo de ejecutar nodos. Actualmente, se necesitan 5 horas y 30 minutos para sincronizar y verificar el último bloque de Bitcoin desde el bloque génesis en un dispositivo con buen hardware, mientras que en un dispositivo de nivel Raspberry Pi se necesitarán varios días si se introduce la prueba estatal, esta vez. -El proceso de consumo se puede reducir considerablemente. En segundo lugar, la prueba del estado de la cadena es una parte importante que se puede utilizar con BitVM y promoverá la implementación de BitVM.
El equipo de ZeroSync realizó una investigación en profundidad sobre las pruebas de estado de la cadena y creó una "prueba de cadena de encabezado" más liviana. Esta solución, combinada con ZK, solo prueba la validez del encabezado del bloque de Bitcoin, formando así una "cadena de encabezado" que contiene los 850,000. encabezados de bloque en el historial de Bitcoin y genera un hash de 80 bytes para cada encabezado de bloque.
Este esquema requiere un doble cálculo SHA-256 de cada encabezado de bloque de Bitcoin para verificar la prueba PoW correspondiente. ZeroSync usa STARK para generar la prueba de la cadena de encabezado de Bitcoin. El costo para generar la prueba es de aproximadamente $4,000 y solo toma 3 segundos verificar la prueba usando mi navegador.
Sin embargo, dado que no incluye el proceso de verificación del contenido de la transacción en el bloque, la prueba de la cadena de encabezado solo puede asumir que la cadena de bloques con la mayor cantidad de pruebas de POW es válida y, de forma predeterminada, permite que el cliente Bitcoin sincronice el último bloque en esta cadena. . En este escenario, aunque el atacante puede crear un bloque que contenga transacciones no válidas, agregar más bloques después de este bloque y generar una prueba de cadena de encabezado para engañar al cliente Bitcoin que sincroniza datos históricos, al hacerlo, el ataque sería extremadamente costoso y ser desacreditado directamente por los clientes de nodo completo de Bitcoin existentes.
Sin embargo, a pesar de la baja tasa de éxito de este escenario de ataque, la prueba de cadena de encabezado no puede considerarse una solución infalible si permite a un atacante robar una gran cantidad de BTC. Si queremos probar el estado completo de la cadena, debemos demostrar directamente que todo lo que hay en el bloque de Bitcoin es válido, incluida la verificación de firmas ECDSA y Schnorr basada en curvas elípticas secp256k1.
Los bloques históricos mensuales de Bitcoin pueden contener 30 millones de firmas, y el historial contiene un total de 2.500 millones de operaciones de firmas, así como una gran cantidad de operaciones SHA-256. De esta manera, la red Bitcoin genera alrededor de 7 GB de datos de bloques cada mes, y todos los datos históricos suman más de 650 GB. En realidad, este número puede ser de 2 a 3 veces mayor.
Ahora veamos BitVM. BitVM permite a Bitcoin verificar cualquier tarea informática y es el mejor camino para lograr la verificación SNARK sin cambiar el protocolo. BitVM utiliza dos técnicas para sortear el límite de tamaño de bloque de Bitcoin en los scripts. Primero, utiliza la estructura de secuencias de comandos de Taproot MerkleTree;
En segundo lugar, habilita un esquema de almacenamiento KV al que se puede acceder a través de un único script, lo que permite conexiones a una gran cantidad de scripts. Sin embargo, el protocolo Bitcoin no exige la integridad del esquema de almacenamiento KV anterior. BitVM necesita verificar el Prover malicioso mediante prueba de fraude. Si el Prover emite una declaración no válida o un almacenamiento KV problemático, otros pueden iniciar una transacción en la cadena Bitcoin. , indicando que Prover actuó de manera inapropiada y le quitó sus bienes pignorados previamente.
En resumen, Bitcoin se enfrenta a grandes desafíos y se han propuesto varias soluciones para resolver estos problemas. Sin embargo, estas propuestas no serán adoptadas rápidamente por la comunidad de Bitcoin y los cambios en el protocolo no se pueden completar en el corto plazo. Tanto algo bueno como malo, también significa que Bitcoin está descentralizado y es más seguro.
Muchos en la comunidad Bitcoin están entusiasmados con el potencial de SNARK/STARK. El método más factible para lograr la verificación SNARK a mediano y largo plazo es probablemente BitVM, pero requiere más inversión en I+D para que sea eficaz en la práctica;
Volver a habilitar el código de operación OP_CAT también es una idea, pero es necesario demostrar que los beneficios de reiniciar el código de operación superan con creces los riesgos, e investigar qué códigos de operación simples pueden permitir la verificación SNARK en scripts de Bitcoin, o explorar qué escenarios similares a las funciones OP_CAT puede lograr. Independientemente de la solución que se elija, el objetivo final de la comunidad Bitcoin debe ser hacer que el producto sea práctico y admita escenarios más implementables.
Enlace original
