Una IA halló en Zcash un bug oculto durante 4 años

Una inteligencia artificial encontró en dos días un fallo criptográfico que cuatro años de revisión humana no detectaron en el circuito de privacidad de Zcash. El 29 de mayo de 2026, el ingeniero de seguridad Taylor Hornby, contratado por Shielded Labs, descubrió una vulnerabilidad de soundness (solidez: la garantía de que una prueba criptográfica solo se acepta si la afirmación que demuestra es realmente cierta) en el circuito Orchard, el corazón del pool blindado de Zcash. El fallo permitía acuñar ZEC falso de forma ilimitada e indetectable dentro del pool privado, sin dejar rastro en la cadena. Hornby acreditó a Claude Opus 4.8, el modelo de Anthropic publicado el día anterior, como la herramienta que le permitió escribir el exploit funcional. El bug llevaba ahí desde mayo de 2022. Este artículo no es otro parte de hackeo: es la explicación de por qué un circuito de conocimiento cero (zero-knowledge) puede esconder un fallo que no rompe nada visible —no hay caída, no hay transacción sospechosa, no hay forma de saber a posteriori si se explotó— y por qué eso es especialmente devastador para una moneda cuyo único producto es la privacidad. Vamos a reconstruir la cronología exacta, a explicar qué garantiza y qué no garantiza una prueba ZK, y a desgranar la pregunta que ningún parche puede cerrar: ¿está intacto el supply (el circulante total) de ZEC?

¿Qué falló exactamente en el circuito Orchard?

Orchard es el pool blindado de última generación de Zcash, activado en la actualización de red NU5 en mayo de 2022. Cuando alguien mantiene ZEC «en la sombra» —en el pool privado, sin que las direcciones ni los importes sean visibles—, esos fondos viven dentro de Orchard. Para que ese ocultamiento sea seguro, cada transacción privada va acompañada de una prueba de conocimiento cero: una demostración matemática de que la operación es válida (el emisor tiene los fondos, no se crea dinero de la nada, las cuentas cuadran) sin revelar ningún dato concreto. La red no ve los importes; solo verifica la prueba y, si pasa, acepta la transacción.

El problema estaba en cómo se construye esa prueba. Según el aviso técnico de Shielded Labs, el circuito Orchard contenía un elemento sub-restringido (under-constrained): una operación interna de multiplicación sobre una curva elíptica que aceptaba como válidas entradas falsas. Dicho de otro modo, era posible introducir valores arbitrarios y falsos en esa multiplicación y, aun así, lograr que la comprobación los diera por buenos.

La corrección final fue minúscula —una restricción que faltaba en la lógica del circuito—, y esa desproporción es justo lo inquietante: un detalle ínfimo separaba un sistema de privacidad considerado robusto de una máquina de falsificar dinero. El fallo no estaba en el software del nodo, ni en las carteras, ni en la criptografía subyacente de Zcash. Estaba en la implementación del circuito, en la librería de componentes que traduce las reglas contables de Zcash a restricciones matemáticas verificables.

¿Qué significa que un fallo sea de «soundness» y no un hackeo normal?

Conviene distinguir dos propiedades que toda prueba de conocimiento cero debe cumplir, porque la diferencia es el centro de esta historia.

Piensa en el control de acceso de un edificio con torno (el cilindro giratorio que solo deja pasar de uno en uno con una tarjeta válida). La primera propiedad que esperas es que quien tiene tarjeta válida siempre pueda entrar: a eso, en criptografía ZK, se le llama completeness (completitud). La segunda, más importante, es que quien no tiene tarjeta válida nunca pueda entrar, ni siquiera fabricando una falsificación lo bastante buena para engañar al lector: a esa garantía se le llama soundness (solidez).

Un fallo de soundness es precisamente eso: el torno deja pasar a alguien con una tarjeta falsa. La prueba matemática acepta como cierta una afirmación que es mentira. En el caso de Orchard, la afirmación falsa era «tengo este ZEC y no lo estoy creando de la nada». Con el circuito roto, un atacante podía construir una prueba que decía «estos fondos son legítimos» cuando en realidad los acababa de inventar, y la red la aceptaba sin objeción.

La consecuencia práctica es lo que separa este caso de un hackeo convencional. En un exploit normal —un drenaje de un contrato, un puente comprometido— hay un rastro: transacciones que mueven fondos a una dirección, un pico anómalo, un balance que se vacía. Aquí no. Como la falsificación ocurre dentro del pool blindado, donde por diseño no se ven importes ni direcciones, el ZEC falso es indistinguible del legítimo. No hay crash, no hay alerta, no hay transacción marcada como sospechosa. El sistema funciona exactamente igual de bien fabricando dinero falso que moviendo dinero real, porque su trabajo es no contarte nada sobre lo que pasa dentro.

¿Por qué una IA lo encontró y cuatro años de revisión humana no?

Taylor Hornby no es un recién llegado: es un ingeniero de seguridad con trayectoria, contratado por Shielded Labs en abril de 2026 para auditar el protocolo. El 28 de mayo, Anthropic publicó Claude Opus 4.8. Al día siguiente, Hornby lo puso a trabajar sobre el circuito Orchard con un arnés de prompts y herramientas a medida —un conjunto de instrucciones y utilidades encadenadas para dirigir al modelo—, enfocándolo en una revisión focalizada de la lógica del circuito. En menos de 48 horas, el sistema señaló la inconsistencia en la multiplicación sobre curva elíptica. Hornby escribió entonces un exploit completo que, en un entorno de pruebas local, generó ZEC falso ilimitado e indetectable, confirmando que el fallo era real y explotable.

¿Por qué no se vio antes? Un circuito ZK no es código legible como un programa normal. Es un sistema de restricciones algebraicas: miles de ecuaciones que, en conjunto, deben cerrar la puerta a cualquier estado inválido. Verificar que no falta ninguna restricción es radicalmente más difícil que comprobar que las que hay funcionan. El código «hace lo correcto» en todos los casos de prueba; el fallo está en el caso que nadie escribió, en la restricción que nadie añadió. Es un error por omisión, no por comisión, y los errores por omisión son casi invisibles a la lectura humana, a los tests y a las auditorías clásicas, que tienden a comprobar que lo que está escrito funciona, no que está escrito todo lo que debería.

Ahí es donde un modelo de lenguaje con suficiente capacidad de razonamiento sobre matemáticas y código aporta algo que el ojo humano no escala: la paciencia para recorrer exhaustivamente el espacio de lo que debería estar restringido y no lo está. No es magia ni sustituye al ingeniero —fue Hornby quien dirigió la búsqueda y escribió el exploit—, pero marca un precedente: la primera vulnerabilidad criptográfica crítica de esta clase, en producción durante años, atribuida públicamente al uso de una IA de frontera.

¿Cómo fue la respuesta de emergencia de 50 horas?

Lo que siguió a la divulgación privada fue una operación de cirugía en dos tiempos, ejecutada en poco más de dos días, y diseñada con un cuidado poco habitual para no delatar el fallo mientras se arreglaba.

El problema de parchear en abierto un bug de esta gravedad es de transparencia: el código de Zcash es público. Si los desarrolladores hubieran subido directamente la corrección del circuito, cualquiera con acceso al commit habría podido leer el arreglo, deducir la vulnerabilidad que tapaba y explotarla en las redes que aún no se hubieran actualizado. Un parche, para un atacante atento, es un mapa del fallo.

La solución fue desacoplar contención y corrección en dos movimientos:

1. Contención (soft fork). El 2 de junio hacia las 02:00 UTC, en el bloque 3.363.426, se activó un soft fork de emergencia (Zebra 4.5.3) que simplemente rechazaba toda transacción que tocara Orchard. El pool blindado quedó congelado: nadie podía explotar lo que ya no se podía usar, y el parche no revelaba qué se arreglaba porque, técnicamente, no arreglaba nada —solo cerraba la puerta.
2. Corrección (hard fork). Un día después, el 3 de junio hacia las 04:05 UTC, en el bloque 3.364.600, el hard fork NU6.2 (Zebra 5.0.0) reactivó Orchard ya con el circuito corregido.

El hard fork era inevitable por una razón técnica: arreglar un bug en un circuito de conocimiento cero obliga a actualizar la clave de verificación fijada (el parámetro criptográfico contra el que la red valida cada prueba). Ese parámetro está empotrado en las reglas de consenso, y cambiarlo no se puede hacer con un parche de software del nodo —requiere que toda la red salte a un conjunto de reglas nuevo a la vez. De ahí la actualización de red.

¿Qué garantiza una prueba ZK y qué no garantiza nunca?

El incidente expone un malentendido extendido sobre las pruebas de conocimiento cero: que una prueba «matemáticamente verificada» equivale a una verdad absoluta. No es así. Una prueba ZK solo garantiza tanto como las restricciones que el circuito impone. Si el circuito está bien construido, la prueba es tan fiable como las matemáticas que hay debajo. Si le falta una restricción, la prueba certifica con total convicción una mentira, y lo hace con la misma firmeza con la que certificaría una verdad. La criptografía no se rompe; lo que se rompe es el modelo de lo que se está demostrando.

La siguiente tabla separa lo que el sistema seguía garantizando de lo que dejó de garantizar mientras el fallo estuvo vivo.

La columna de la derecha es el verdadero alcance del daño. Y la última fila es la que define la pregunta abierta de todo el caso.

¿Por qué nadie puede saber si el supply de ZEC está intacto?

Zcash dispone de un mecanismo llamado turnstile (torniquete), diseñado precisamente para vigilar la contabilidad entre pools. Cada vez que el valor cruza la frontera entre el supply transparente (visible) y el blindado (oculto), el turnstile comprueba que no salga más de lo que entró en agregado. Es una red de seguridad que detecta una inflación grosera: si alguien intentara sacar del pool privado más ZEC del que matemáticamente debería existir, el turnstile lo cazaría en la frontera.

Aquí está el matiz que casi toda la cobertura simplificó. El turnstile vigila el tránsito entre pools, no lo que ocurre dentro de uno. Mientras el ZEC falsificado permaneciera en el interior de Orchard, sin cruzar al exterior, sería invisible al torniquete. Y si un atacante lo hubiera ido sacando poco a poco, mezclado con fondos legítimos y por debajo de cualquier umbral llamativo, no hay forma criptográfica de distinguir esa salida de una retirada normal.

Por eso conviven dos afirmaciones que parecen contradictorias y no lo son. Por un lado, el turnstile confirma que no se ha detectado creación de valor no autorizada a nivel agregado, y no hay evidencia de explotación en mainnet. Por otro, Shielded Labs reconoce de forma explícita que, debido a las propiedades de privacidad de Orchard, no existe ninguna manera definitiva —usando solo criptografía— de determinar si la explotación ocurrió. Ambas cosas son ciertas a la vez: no hay prueba de que se explotara, y tampoco puede haber prueba de que no se explotara. La privacidad que protege al usuario es la misma que impide auditar la falsificación.

Para una moneda de privacidad esto es existencial de una forma que no lo sería para Bitcoin o Ethereum, donde cualquiera puede sumar el supply mirando la cadena. El producto entero de Zcash es la confianza en que lo que no se ve, cuadra. Cuando esa confianza ya no se puede verificar criptográficamente, queda como un acto de fe.

¿Cómo reaccionó el mercado y qué propone Shielded Labs ahora?

La reacción del mercado fue inmediata. Tras la divulgación pública del 5 de junio, ZEC se desplomó: CoinDesk reportó una caída en torno al 38 % en 24 horas, con un mínimo cercano a los 442 $. Medido sobre la ventana de 48 horas, otras fuentes situaron la corrección próxima al 50 %. El rango exacto depende del marco temporal y del exchange, pero el orden de magnitud —una pérdida de entre un tercio y la mitad del valor en dos días— es consistente en toda la cobertura.

La verdadera incógnita no es el precio, sino el plan de fondo. Como no se puede demostrar criptográficamente que el supply esté limpio, Shielded Labs ha propuesto una actualización de red más ambiciosa que el simple parche: crear un pool blindado nuevo y forzar una contabilidad de turnstile sobre todos los fondos que migren desde el viejo Orchard. En la práctica, equivaldría a obligar a que cada ZEC blindado «pase por la aduana» al moverse al pool nuevo, donde su existencia pueda contrastarse contra el supply auditable. Es la única vía para reconstruir, de forma verificable, una verdad contable que el fallo dejó en suspenso. Es también una operación delicada que reabre debates de gobernanza sobre quién decide y cómo se ejecuta un cambio de esta magnitud en una red descentralizada.

El patrón recuerda a otros incidentes recientes donde el problema no fue la criptografía en sí, sino el hueco entre lo que el código debería garantizar y lo que realmente garantizaba en producción. Lo analizamos en el caso del parche fantasma de Gnosis Pay, donde un arreglo existía en el repositorio pero nunca llegó al contrato desplegado. La lección compartida es incómoda: «auditado» y «verificado» no significan «correcto».

¿Qué lecciones deja para la privacidad ZK y para el papel de la IA en seguridad?

La primera lección es sobria: las pruebas de conocimiento cero son tan fuertes como la corrección de sus circuitos, y verificar esa corrección es uno de los problemas abiertos más difíciles de la criptografía aplicada. Cada protocolo que apila privacidad o escalabilidad sobre circuitos ZK —y son cada vez más, desde stablecoins privadas hasta rollups— hereda esta superficie de riesgo. La privacidad on-chain no es un interruptor que se enciende; es una propiedad que depende de que miles de restricciones algebraicas estén todas presentes y bien puestas.

La segunda lección apunta al futuro inmediato. Que una IA de frontera detectara en 48 horas lo que años de revisión no vieron corta en dos direcciones. Por un lado, es una herramienta defensiva poderosísima: los equipos que integren modelos capaces de razonar sobre circuitos en sus auditorías encontrarán fallos antes. Por otro, el mismo poder está disponible para el atacante, y no todos los que encuentren un bug de soundness lo divulgarán de forma responsable como hizo Hornby. La ventana entre «un modelo nuevo puede encontrar esto» y «alguien lo encuentra con malas intenciones» se acorta con cada generación.

Para el ecosistema de privacidad —desde monedas como Zcash hasta las nuevas stablecoins de privacidad sobre redes ZK y las hojas de ruta de privacidad institucional en Ethereum (2025-2029)—, el episodio fija un estándar: auditar circuitos ZK con asistencia de IA dejará de ser opcional. El caso se cerró sin pérdidas verificadas y con una respuesta técnica ejemplar en velocidad, pero deja una pregunta que ningún hard fork resuelve: en un sistema diseñado para no contar nada, ¿cómo se demuestra que nada se ha roto?

Fuentes y enlaces: Zcash Community Forum — The Orchard Counterfeiting Vulnerability · Zcash Foundation — Zebra 4.5.3 y 5.0.0 · CoinDesk · Decrypt · BitMEX Blog