Resumen

Este artículo profundiza en los métodos prácticos para habilitar la verificación ZK en Bitcoin, abordando temas como el modelo UTXO de Bitcoin, las limitaciones de script, Taproot, OP_CAT, BitVM y Chain State Proofs. Presenta un argumento claro de que la integración de ZK en el protocolo Bitcoin es inevitable. Se destacan dos rutas potenciales: una es reintroducir el opcode OP_CAT para apoyar directamente la verificación SNARK en scripts de Bitcoin, un cambio que tiene una alta probabilidad de aprobación eventual. El segundo enfoque gira en torno a BitVM, que incorpora pruebas de fraude. Además, la propuesta del equipo ZeroSync para Chain State Proofs tiene como objetivo reducir el costo de verificar datos históricos para los clientes de nodos.

Texto principal: Para comprender completamente Bitcoin, es útil verlo como un sistema social. En sus primeros días, los creadores de Bitcoin definieron el software que deben ejecutar los nodos, de manera similar a establecer las reglas que gobiernan una sociedad. La estabilidad de Bitcoin depende de un amplio consenso sobre su naturaleza fundamental, lo que lleva a preguntas como "¿Qué es Bitcoin en su núcleo?" y "¿En qué debería evolucionar Bitcoin?" Sin embargo, llegar a un consenso sobre estas preguntas es notoriamente difícil, ya que las opiniones varían ampliamente y evolucionan continuamente.

Esto se remonta al origen histórico de Bitcoin. Cuando Satoshi Nakamoto publicó el libro blanco de Bitcoin, dijo: “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 de Cypherpunks (un grupo de discusión por correo electrónico establecido en 1992, compuesto 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 la criptografía).

Sin embargo, Bitcoin limita el flujo de datos a nivel de diseño del producto. El número de transacciones que puede procesar por unidad de tiempo es limitado. Si el número 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 sola transacción con la tarifa de procesamiento más alta en la red de Bitcoin ocurrió después de que la recompensa por bloque se redujera a la mitad en 2024, y la tarifa de procesamiento para una transacción con prioridad media en la cadena alcanzó los $150. Se puede decir que las costosas tarifas de transacción de la red de Bitcoin se han convertido en un problema.

Para resolver el problema de las tarifas de transacción, las personas han invertido muchos recursos en el desarrollo de la Red Lightning. Pero según un artículo publicado en 2016, la Red Lightning solo puede admitir decenas de millones de usuarios en la práctica y no puede realizar su visión de un sistema de pago global. Además de las tarifas de transacción excesivamente caras, hay otro problema, y es que Bitcoin nunca ha logrado alcanzar el anonimato que imaginó.

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 privacidad y el iniciador de la transacción puede ser completamente anónimo. Sin embargo, aunque el iniciador de la transacción no requiere KYC, los datos de la transacción en la cadena de Bitcoin filtran mucha información, exponiendo la privacidad del usuario en gran medida. Aunque hay algunos clientes de billetera con funciones de privacidad que resuelven los problemas anteriores hasta cierto punto, los desarrolladores de estas billeteras enfrentan amenazas de varios tamaños. Por ejemplo, el desarrollador de la billetera Samourai CoinJoin fue arrestado por el FBI en abril de 2024, y una semana después, el desarrollador de la billetera Wasabi cerró su componente de coordinación de CoinJoin. Obviamente, estas llamadas billeteras de privacidad no son del todo dignas de confianza para los usuarios.

En resumen, muchos de los conceptos de Bitcoin están lejos de ser realizados hasta hoy, y las tecnologías relacionadas aún están en desarrollo continuo. Aun así, muchas personas en la comunidad Bitcoin creen que el diseño del protocolo de Bitcoin debería permanecer sin cambios, pero también hay muchas personas, como yo, que están apasionadas por hacer mejoras a Bitcoin. Entonces, ¿en qué dirección debería mejorar Bitcoin?

En respuesta a los problemas anteriores, hay muchas propuestas en la comunidad de Bitcoin y las que tienen los mejores resultados teóricos deben estar relacionadas con ZK y SNARKs. Con ZK y SNARKs, se pueden lograr las siguientes características:

1. Privacidad mejorada significativamente: utiliza el compromiso Peterson homomórfico para la cantidad de transacción y la Prueba de Rango para mejorar significativamente la privacidad del usuario (como se hace en la cadena lateral Element de Blockstream); utiliza firmas vinculables (como Monero) para ocultar las huellas de transacciones; logra transacciones verdaderamente privadas (como Zcash).

2. Mejorar la capacidad de procesamiento de transacciones

Muchas soluciones técnicas podrían abordar los problemas existentes de Bitcoin, pero ¿por qué no se han integrado estas tecnologías en el protocolo de Bitcoin? La respuesta radica en la dificultad de modificar el protocolo. A diferencia de Ethereum, Bitcoin no tiene una organización centralizada como la Fundación Ethereum. Cualquier cambio en el protocolo requiere un alto nivel de consenso comunitario, que implica una extensa negociación y equilibrio de intereses. Como resultado, mientras que Ethereum actualiza regularmente sus códigos de operación de EVM, el protocolo de Bitcoin ha experimentado muy pocos cambios desde su inicio.

En cierto modo, esta dificultad para modificar el protocolo es beneficiosa. Si los cambios fueran fáciles de implementar, las alteraciones maliciosas o los ataques serían más probables. Esto plantea la pregunta: ¿Cómo se puede mejorar el rendimiento de Bitcoin sin alterar el protocolo?

Para responder a esto, necesitamos volver a visitar algunos conceptos básicos de Bitcoin. Cuando transfieres Bitcoin a otra persona, creas una transacción y la transmites a la red de Bitcoin. Los datos de salida de la transacción especifican la cantidad de BTC que se está transfiriendo. El destinatario puede luego crear una nueva transacción para gastar los BTC recibidos, generando nuevos datos de salida en el proceso.

Es importante tener en cuenta que Bitcoin no tiene un estado global como Ethereum, particularmente carece de un estado de cuenta; solo tiene datos de salida de transacciones. Cada salida de transacción tiene dos estados: o bien ha sido gastada por el destinatario o permanece sin gastar. Las salidas de transacción no gastadas (UTXO) son con las que estamos familiarizados. Además de la cantidad de BTC asociada, cada salida de transacción también tiene un script adjunto escrito en Bitcoin Script. Quien pueda proporcionar la prueba correcta (Testigo) a este script puede gastar el UTXO.

Bitcoin Script es un lenguaje de programación basado en pilas con una serie de opcodes. Los programas adjuntos a los UTXO a menudo constan de múltiples opcodes, realizando cálculos basados en la pila y devolviendo los resultados a ella. Muchos scripts de Bitcoin comunes han existido desde el inicio de Bitcoin. Por ejemplo, el script más común consta de una clave pública y un opcode que verifica la firma digital. Este opcode requiere que, para gastar o desbloquear un UTXO, se proporcione una firma digital correspondiente a la clave pública.

Lectura recomendada: [Aproximándose a BTC: Conocimientos previos para entender BitVM (1)]

Capacidades de Bitcoin Script

Qué puede hacer el script de Bitcoin:

• Reorganice la pila y realice comprobaciones de igualdad (para verificar condiciones específicas y garantizar la seguridad y validez de la transacción).
• Realiza operaciones condicionales similares a las declaraciones if-else.
• Realice operaciones aritméticas limitadas en números de 32 bits, como suma y resta.
• Verificar datos hash y firmas ECDSA y Schnorr.

Lo que Bitcoin Script no puede hacer:

• No hay bucles, saltos o recursión; no es Turing-completo, con capacidades de programación muy limitadas.
• No se pueden realizar operaciones a nivel de bits.
• Falta opcodes para multiplicación y división.
• No se pueden concatenar elementos en la pila.
• Tiene una capacidad muy limitada para leer y verificar los datos de transacciones en la cadena. El script de Bitcoin no puede acceder directamente a la cantidad de cada transacción y no puede pasar estado (los UTXO son de un solo uso y cada transferencia quema los antiguos y genera nuevos).

En las primeras versiones de Bitcoin, algunas de las funcionalidades mencionadas anteriormente como “no se pueden hacer” eran posibles, pero ciertos opcodes fueron desactivados posteriormente por Satoshi Nakamoto debido a vulnerabilidades de seguridad. Por ejemplo, el opcode OP_CAT, que podía combinar dos elementos de la pila, se utilizaba para atacar de forma remota los nodos de Bitcoin y causar fallos. Satoshi desactivó OP_CAT y otros opcodes por razones de seguridad.

Entonces, ¿puede Bitcoin Script verificar SNARKs? Teóricamente, aunque Bitcoin Script no es Turing-complete, sus operaciones básicas son suficientes para verificar cualquier cálculo. Sin embargo, en la práctica, la verificación de SNARK no es factible porque el tamaño del programa requerido para los pasos de verificación supera el límite máximo de bloque de Bitcoin de 4MB. Si bien podríamos intentar operaciones aritméticas en campos finitos grandes, el costo sería prohibitivamente alto. Por ejemplo, en BitVM, la multiplicación de dos enteros de 254 bits resultó en un tamaño de script de Bitcoin de casi 8KB. Además, sin OP_CAT, el costo de verificar pruebas de Merkle también es alto, ya que esto requiere operaciones similares a bucles.

Entonces, ¿por qué no simplemente modificar el protocolo de Bitcoin para agregar opcodes más poderosos? Como se mencionó anteriormente, lograr un consenso mayoritario sobre nuevas reglas de protocolo es extremadamente difícil. Bitcoin carece de un tomador de decisiones centralizado, y cualquier propuesta para mejorar Bitcoin Script enfrenta una considerable oposición de partes interesadas con diferentes perspectivas. No hay una manera efectiva de medir el consenso de la comunidad en la red de Bitcoin, y forzar una actualización sin ello podría provocar divisiones en la cadena. Por supuesto, Bitcoin no es completamente inmutable. Las actualizaciones más recientes fueron SegWit en 2017 y Taproot en 2021.

La actualización de Taproot, que modificó muchas reglas, tardó tres años y medio en pasar de la versión teórica a la activación real. El factor clave que permitió Taproot fue que no alteró las suposiciones de seguridad existentes y presentó mejoras claras en el protocolo de Bitcoin. Por ejemplo, permite el uso de firmas de Schnorr en lugar de ECDSA. Ambas se basan en la suposición del logaritmo discreto y utilizan la misma curva elíptica, pero la primera es más eficiente y requiere menos cálculos.

Además, las mejoras de Taproot en Bitcoin se pueden categorizar en los siguientes tres aspectos:

Primero, Taproot reduce los costos de verificación de scripts con muchas ramas condicionales, lo que permite que Bitcoin admita programas más complejos.

En segundo lugar, Taproot reduce la cantidad de datos de script que se revelarán en la cadena, y puedes ensamblar múltiples programas de script en un árbol de Merkle, con cada script ubicado en una hoja diferente. Si deseas activar un cierto script, solo necesitas revelar la hoja donde se encuentra y la prueba de Merkle;

En tercer lugar, Taproot también agregó otros diseños de mecanismos.

Teniendo en cuenta el precedente de Bitcoin con Taproot para integrar funciones más avanzadas, uno podría preguntarse por qué no se ha introducido un opcode dedicado para la verificación de SNARK. La diferencia clave radica en la complejidad y el consenso requerido para OP_SNARK. A diferencia de Taproot, que tuvo un diseño claro y directo que obtuvo un amplio apoyo, las propuestas de OP_SNARK varían ampliamente, lo que dificulta unificar a la comunidad en torno a un enfoque único. Si se implementara, cada nodo de Bitcoin debería admitir este método específico de verificación de SNARK, lo que aumentaría significativamente las demandas técnicas. Además, la complejidad inherente de OP_SNARK es un obstáculo importante: Taproot agregó alrededor de 1,600 líneas de código, manejables según los estándares de la comunidad, mientras que OP_SNARK implicaría codificación mucho más intrincada. Además, determinar quién evaluaría la activación de OP_SNARK y lograr consenso cuando pocos comprenden completamente sus complejidades añade capas de dificultad. Dadas estas dificultades, es poco probable que se materialice una actualización de OP_SNARK en un futuro próximo.

Sin embargo, existen otras formas de verificar SNARKs en Bitcoin Script. Podemos hacer que los scripts de Bitcoin sean más funcionales agregando opcodes más simples, lo que permite a las personas implementar programas validadores de SNARK en scripts. Pero de hecho, es muy difícil escribir un programa de verificación de SNARK en el lenguaje de script de Bitcoin. Por lo tanto, el equipo de investigación de Blockstream está desarrollando Simplicity, un lenguaje de programación diseñado para reemplazar Bitcoin Script. Simplicity está específicamente diseñado para sistemas de consenso blockchain y no es intencionalmente Turing-completo, lo que facilita el análisis estático y la verificación formal.

Centremos nuestra atención en una propuesta aparentemente simple pero de gran impacto que podría mejorar significativamente las capacidades de scripting de Bitcoin: la reactivación del opcode OP_CAT. OP_CAT fue incluido originalmente en el código temprano de Bitcoin pero luego fue desactivado por Satoshi Nakamoto debido a su potencial para permitir ataques DoS bajo condiciones específicas. Sin embargo, ahora hay un creciente interés dentro de la comunidad de Bitcoin para traerlo de vuelta.

La función de OP_CAT es directa: toma los dos elementos principales de la pila, los concatena y luego empuja el resultado de nuevo a la pila. Si bien esto puede parecer básico, tiene el potencial de desbloquear mejoras sustanciales en el lenguaje de secuencias de comandos de Bitcoin. Por ejemplo, los scripts actuales de Bitcoin no pueden acceder a ciertos datos de transacciones en cadena, como los montos involucrados, pero con OP_CAT, esta capacidad podría ser introducida. Además, OP_CAT podría ser fundamental para verificar las pruebas de Merkle.

En esencia, OP_CAT es una actualización de opcode de bajo nivel que podría llevar a una amplia gama de nuevas funcionalidades. Muchos han señalado que OP_CAT podría ser crucial para lograr diversos objetivos. Una pregunta clave es si OP_CAT podría ayudar en la verificación de SNARK dentro de los scripts. La respuesta es sí. Dado que la verificación de prueba de Merkle es un paso hacia la validación de SNARKs basados ​​en FRI, OP_CAT sería una adición valiosa. En el pasado, es posible que los scripts diseñados para la verificación de SNARK hayan sido demasiado grandes para ajustarse a los límites de tamaño de bloque de Bitcoin, pero OP_CAT podría ayudar a agilizar estos scripts, haciéndolos más compactos.

OP_CAT ha sido discutido durante años, con una creciente conciencia de su papel potencial en la introspección de transacciones. Una de sus principales ventajas sobre otras propuestas es que alguna vez fue una parte integral del Bitcoin Script, lo que podría facilitar la consecución de un consenso comunitario. Sin embargo, la desventaja es que habilitar OP_CAT podría impactar negativamente en las ganancias de MEV (Valor Exponible por los Mineros) para algunos, lo que ha llevado a un debate continuo dentro de la comunidad sobre su reactivación.

En resumen, Bitcoin podría dar un paso hacia la verificación de SNARK en scripts reintroduciendo opcodes sencillos como OP_CAT. Además, vale la pena mencionar una propuesta reciente llamada la "Gran Restauración de Script," que reintroduce un opcode de multiplicación y permite que todas las operaciones aritméticas se realicen con precisión arbitraria.

Además, al evaluar el impacto de OP_CAT en la red de Bitcoin, es importante considerar sus efectos en los operadores de nodos de Bitcoin. Para asegurar que Bitcoin siga siendo resistente a la censura y descentralizado, la comunidad se esfuerza por tener a tantas personas como sea posible ejecutando nodos para validar transacciones. Si Bitcoin implementara la verificación SNARK, no aumentaría significativamente el costo de operar un nodo, lo que no afectaría en gran medida la seguridad o la resistencia a la censura de Bitcoin.

Actualmente, un bloque de Bitcoin puede contener hasta 4MB de datos, con nuevos bloques siendo minados aproximadamente cada 10 minutos. La mayoría de los bloques están llenos de scripts de Bitcoin y datos de Testigo (similar a firmas digitales). En promedio, cada bloque puede acomodar entre 7,000 y 10,000 verificaciones de firma, con un máximo de alrededor de 80,000 verificaciones por bloque. Para poner en contexto, mi CPU Intel del 2020 tarda cerca de 3.2 segundos en verificar un bloque de Bitcoin. Naturalmente, la velocidad de verificación del bloque está influenciada por factores más allá del tiempo de verificación de la firma.

Además, si las transacciones de Bitcoin eventualmente admiten pruebas de conocimiento cero (ZK), cualquier aumento en el tiempo de generación de transacciones podría no ser una preocupación importante. Las carteras de hardware, que se utilizan para el almacenamiento de activos a largo plazo, suelen tener pantallas y diseños compactos centrados en el almacenamiento de claves y la creación de firmas. Estas carteras suelen contar con CPUs de baja potencia, como un procesador de doble núcleo de 240 MHz, pero manejan las transacciones de Bitcoin de manera eficiente.

Realicé una pequeña encuesta preguntando a los usuarios sobre la demora máxima que aceptarían para que un dispositivo de firma genere una prueba, y muchas personas estaban bien con una espera más larga, especialmente si hubiera ganancias significativas por hacer. Entonces, si introducimos ZK en las transacciones de Bitcoin, no parece haber mucho problema. Hemos pasado mucho tiempo discutiendo cambios potenciales en el diseño subyacente de Bitcoin, pero hay muchas aplicaciones que se pueden desarrollar sin alterar Bitcoin en sí. Una de estas aplicaciones que vale la pena mencionar es Chain State Proofs, que está relacionada con BitVM. Este enfoque utiliza pruebas de conocimiento cero para validar la corrección de los hash de bloque.

¿Qué impacto tiene esta tecnología en Bitcoin? En primer lugar, las Pruebas de Estado de la Cadena pueden reducir considerablemente la carga de trabajo involucrada en la sincronización y verificación de los datos históricos de Bitcoin, lo que a su vez reduce los costos de ejecutar un nodo. Actualmente, la sincronización y verificación de datos desde el bloque génesis hasta el último bloque lleva aproximadamente 5 horas y 30 minutos en un dispositivo de gama alta, y varios días en un dispositivo de nivel Raspberry Pi. Las Pruebas de Estado de la Cadena podrían acortar significativamente este proceso.

En segundo lugar, las Pruebas de Estado de la Cadena juegan un papel crucial en el avance de BitVM. El equipo de ZeroSync ha investigado a fondo las Pruebas de Estado de la Cadena y ha desarrollado una versión simplificada llamada 'Pruebas de Cadenas de Encabezado'. Este enfoque utiliza pruebas de conocimiento cero para validar los encabezados de bloque de Bitcoin, creando una 'cadena de encabezados' que abarca los 850,000 encabezados de bloque en la historia de Bitcoin. Cada encabezado de bloque se hashea para producir una prueba de 80 bytes. Este método requiere cálculos de doble SHA-256 para cada encabezado para verificar la prueba de trabajo asociada. ZeroSync utiliza STARKs para generar estas pruebas de cadena de encabezado, lo que cuesta alrededor de $4,000 producir, mientras que la verificación solo lleva alrededor de 3 segundos en mi navegador.

Sin embargo, dado que las pruebas de la cadena de encabezado no verifican las transacciones dentro de los bloques, solo pueden suponer que la cadena de bloques con la mayor cantidad de prueba de trabajo (PoW) es válida y confiar en los clientes de Bitcoin para sincronizar los últimos bloques de esta cadena. En esta configuración, un atacante podría teóricamente crear bloques con transacciones inválidas, agregar más bloques después de ellos y generar una prueba de cadena de encabezado para engañar a los clientes que sincronizan datos históricos. Sin embargo, el costo de dicho ataque sería prohibitivamente alto y probablemente sería detectado por los clientes existentes de nodos completos de Bitcoin.

Sin embargo, aunque las posibilidades de que dicho ataque tenga éxito son bajas, si permitiera a los atacantes robar una cantidad significativa de BTC, las pruebas de cadena de encabezado no se considerarían una solución completamente segura. Para verificar el estado completo de la cadena, debemos asegurarnos de que todos los contenidos de bloques de Bitcoin sean válidos, incluidas las verificaciones de firma ECDSA y Schnorr basadas en la curva elíptica secp256k1. Los bloques históricos de Bitcoin contienen aproximadamente 30 millones de firmas cada mes, lo que suma alrededor de 2.5 mil millones de firmas históricamente, junto con numerosos cálculos SHA-256. Como resultado, la red de Bitcoin genera aproximadamente 7GB de datos de bloque mensualmente, con datos históricos que superan los 650GB, y en la práctica, esta cifra podría ser de 2 a 3 veces más alta.

Ahora, veamos BitVM. BitVM permite que Bitcoin verifique cualquier tarea computacional, proporcionando una forma óptima de realizar la verificación de SNARK sin modificar el protocolo. BitVM supera las limitaciones de tamaño de script de Bitcoin utilizando dos métodos. Primero, aprovecha la estructura del script del Taproot MerkleTree. En segundo lugar, utiliza un esquema de almacenamiento KV que puede ser accedido a través de scripts individuales, facilitando conexiones a un gran número de programas de script. Sin embargo, el protocolo de Bitcoin no hace cumplir la integridad de este esquema de almacenamiento KV. BitVM aborda esto empleando pruebas de fraude para detectar Provers maliciosos. Si un Prover hace reclamos inválidos o utiliza un almacenamiento KV defectuoso, otros pueden iniciar una transacción en la cadena de bloques de Bitcoin para informar sobre la mala conducta del Prover y confiscar los activos apostados del Prover.

En resumen, Bitcoin está lidiando con desafíos significativos, y aunque se han propuesto diversas soluciones para abordarlos, es poco probable que obtengan una aceptación rápida por parte de la comunidad de Bitcoin. Los cambios en el protocolo no son alcanzables a corto plazo, lo que refleja tanto las fortalezas como las limitaciones de la descentralización y la seguridad de Bitcoin. El potencial de SNARKs y STARKs está generando una considerable emoción dentro de la comunidad. BitVM parece ser el método más prometedor para integrar la verificación de SNARK a medio y largo plazo, aunque requiere más investigación y desarrollo para ser completamente práctico. La reactivación del opcode OP_CAT es otra opción a explorar, pero debe demostrar que los beneficios de su reactivación superan los riesgos, e identificar qué opcodes simples podrían facilitar la verificación de SNARK u otras funciones similares en los scripts de Bitcoin. En última instancia, la comunidad de Bitcoin tiene como objetivo mejorar la practicidad de la tecnología y respaldar casos de uso más efectivos.

Lea el contenido original aquí: https://www.youtube.com/watch?v=GrSCZmFuy7U

Descargo de responsabilidad:

1. Este artículo es reimpreso de [Geek Web3], Todos los derechos de autor pertenecen al autor original [Geek Web3]. Si hay objeciones a esta reimpresión, por favor contacte a la Gate Learnequipo, y ellos lo resolverán rápidamente.
2. Renuncia de responsabilidad: las opiniones y puntos de vista expresados en este artículo son exclusivamente 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.