Conocimiento cero en Bitcoin: pruebas y transferencias blindadas

Curiosidad

1. ¿Cómo puede un valor cifrado moverse por una cadena pública sin cambiar las reglas de consenso?
2. ¿Qué revela un nullifier sobre una nota gastada y qué oculta?
3. ¿Por qué un protocolo dependería de un indexador en lugar de nodos completos para validar su estado central?

Explorar

Parte IShielded Bitcoin: transferencias privadas sin un soft fork

1. Clara Shikhelman, Mikhail Komarov y Aleksei Moskvin publicaron “Shielded Bitcoin” el 24 de septiembre de 2026. El artículo de 56 páginas propone un diseño que toma prestada la arquitectura de los pools Sapling y Orchard de Zcash para usarla en Bitcoin. El valor se guarda como notas cifradas en lugar de UTXO estándar. Al gastar una nota se revela un nullifier para evitar el doble gasto, pero este identificador no remite a la nota concreta ni a su origen.
2. Cada transferencia consta de una transacción ordinaria de Bitcoin que incluye una salida OP_RETURN. Esta salida contiene un sobre que alberga una prueba de conocimiento cero Groth16, de aproximadamente 192 bytes de tamaño. La prueba demuestra que la transferencia es válida y que los saldos están correctos, sin revelar los datos subyacentes. Un sobre estándar de dos entradas y dos salidas ocupa unos 610 bytes, mientras que la salida OP_RETURN ocupa unos 625 vB. Las reglas de consenso de Bitcoin ignoran por completo estos datos; se tratan como carga útil no gastable.
3. Dado que los nodos completos no validan el contenido del OP_RETURN, los indexadores deben reproducir estos sobres en orden de bloque para reconstruir el árbol de notas, el conjunto de nullifiers y las raíces de Merkle. Si aparece una transferencia inválida en un bloque, los indexadores simplemente la ignoran en lugar de rechazar el bloque. Esto traslada la verificación de los nodos completos al software indexador. Un indexador deshonesto puede servir un estado obsoleto o incompleto, pero no puede apropiarse de los fondos, y cualquiera puede ejecutar el suyo propio.
4. El diseño oculta al análisis de cadena los montos, los remitentes, los receptores y las posiciones en el grafo. Sin embargo, el momento de las transacciones, las comisiones, la estructura del portador de datos y el número de entradas y salidas siguen siendo visibles en la cadena. La retransmisión de estas transacciones depende del mayor límite predeterminado de data carrier de Bitcoin Core v30, un cambio de política y no una actualización de consenso. Si muchos operadores fijan límites más estrictos, sería más difícil retransmitir estas transacciones, aunque los mineros dispuestos a aceptarlas podrían seguir incluyéndolas.
5. El artículo deja explícitamente fuera del alcance de este diseño inicial los mecanismos de peg-in y peg-out. Los autores planean construir estos componentes sobre Bitcoin PIPEs v2, usando cifrado de testigos (witness encryption) para bloquear claves privadas detrás de afirmaciones criptográficas. Este enfoque permite la programabilidad mediante las firmas Schnorr existentes en lugar de nuevos opcodes. Actualmente, el proyecto no tiene implementación, usuarios ni fondos en circulación; sigue siendo una especificación teórica.
6. El diseño tiene limitaciones conocidas. Groth16 requiere una configuración de confianza (trusted setup) única, que es segura si al menos uno de los participantes de la ceremonia fue honesto. Un pool nuevo empieza con un conjunto de anonimato de cero, por lo que es más fácil distinguir a los primeros usuarios. Se estima que una transferencia ocupa unos 700 vB, varias veces lo que ocupa un pago ordinario. Las pruebas se basan en curvas elípticas que una computadora cuántica de gran escala podría romper. Y hasta que los indexadores puedan demostrar su estado de forma económica, las billeteras ligeras deben confiar en el indexador al que consultan, aunque este no pueda apropiarse de sus fondos.

Parte IIPruebas de conocimiento cero en Bitcoin hoy

7. El Script de Bitcoin se diseñó buscando sencillez y seguridad, lo que limita su capacidad para ejecutar código arbitrario. Una prueba de conocimiento cero estándar, como un SNARK Groth16, requiere aritmética de curvas elípticas basada en emparejamientos (pairings) que el conjunto actual de opcodes de Bitcoin no puede realizar a un costo razonable. Esta brecha computacional implica que la propia red no puede verificar estas pruebas de forma nativa sin un soft fork o un gasto de recursos considerable por transacción.
8. Los protocolos al estilo BitVM lo resuelven mediante verificación optimista. En lugar de comprobar cada prueba de inmediato, asumen que es correcta y solo activan la costosa verificación si surge una disputa. Si nadie impugna la transición de estado dentro de un plazo determinado, se acepta como válida. La seguridad se basa en incentivos: los operadores depositan garantías que pierden si hacen trampa, y cualquiera que esté vigilando puede impugnar.
9. El puente Clementine de Citrea llegó a mainnet en enero de 2026 con esta arquitectura BitVM2. Su vía de disputa verifica una prueba Groth16 con un verificador en Script de aproximadamente 1 GB (frente a estimaciones iniciales cercanas a 3 GB), dividido en fragmentos que solo se ejecutan cuando se presenta una impugnación. Este diseño permite que transiciones de estado complejas queden aseguradas por Bitcoin bajo el supuesto de una sola parte honesta, sin que cada nodo completo tenga que ejecutar las pesadas verificaciones criptográficas en las transacciones rutinarias.
10. El proyecto Glock de Alpen demostró un enfoque alternativo basado en garbled circuits (circuitos ofuscados), que llegó a una testnet signet en julio de 2026. Glock usa garbled circuits para que verificar una prueba durante una disputa sea mucho más barato on-chain. Sigue basándose en disputas, pero con una huella on-chain mucho menor, y ambos enfoques reconocen que la verificación nativa en Script de criptografía avanzada sigue siendo prohibitivamente costosa para un uso general.
11. La validación del lado del cliente ofrece otra vía, en la que las pruebas las verifican los usuarios o los indexadores en lugar de la capa base. Protocolos como RGB y Taproot Assets dependen de que los participantes verifiquen localmente las pruebas de propiedad. Del mismo modo, los diseños de Shielded Bitcoin implican que los indexadores reproduzcan los sobres de las transacciones para reconstruir los árboles de notas; el consenso ignora las transferencias inválidas, pero estas pueden detectarse con software de monitoreo que ejecuta toda la lógica de verificación fuera del nodo.
12. Estos sistemas implican concesiones específicas. Groth16 requiere una configuración de confianza (trusted setup), en la que una ceremonia debe garantizar que nadie conserve secretos tóxicos que puedan invalidar las pruebas. Las transacciones de disputa en los sistemas optimistas son grandes y complejas, lo que dificulta su retransmisión. Además, las curvas aptas para emparejamientos en las que se basa Groth16, al igual que la propia secp256k1 de Bitcoin, son vulnerables a una computadora cuántica de gran escala, de modo que una computadora cuántica podría falsificar pruebas y romper el cifrado de notas basado en ECDH, aunque las pruebas Groth16 en sí no revelan ningún secreto.

Datos clave

Ejercicio nueve, seis, tres, uno

Verificación de hechos

Fechas, cifras y afirmaciones verificadas con las fuentes publicadas que se enumeran a continuación.

• Shikhelman, Komarov & Moskvin, 'Shielded Bitcoin' ([alloc] init, September 24, 2026)
• D. Hopwood et al., Zcash Protocol Specification (Sapling and Orchard)
• Bitcoin Core v30 release notes
• news.bitcoin.com coverage of Shielded Bitcoin (2026)
• R. Linus et al., 'BitVM2: Bridging Bitcoin to Second Layers' (2024)
• Citrea documentation and mainnet announcement (2026)
• Alpen, 'Glock is here' (July 2026)