El parche de emergencia cierra la ventana de falsificación de ZEC

Los desarrolladores de Zcash completaron el 2 de junio un parche de emergencia para una falla en el circuito Orchard del protocolo de privacidad que, de no haberse atendido, podría haber permitido la acuñación no detectada de ZEC falsos ilimitados —uno de los riesgos teóricos de oferta más graves jamás documentados para el protocolo. El hallazgo fue anunciado el 29 de mayo por SeedLabs, que informó que el defecto surgió durante una auditoría de seguridad asistida por IA en lugar de una revisión manual convencional.

Esa auditoría combinó el modelo Claude Opus 4.8 de Anthropic con agentes de auditoría creados a medida, y el defecto fue clasificado como una "falla de solidez": las condiciones de verificación dentro de la prueba de conocimiento cero no estaban suficientemente restringidas, lo que significa que un atacante podría construir datos que simulen ser una prueba válida y generar ZEC falsificados sin activar las reglas de validación de la red.

Esta distinción importa para dimensionar el episodio. Las pruebas de conocimiento cero permiten a una red confirmar que las transacciones ocultas siguen sus reglas sin exponer su contenido, por lo que un defecto dentro del circuito de prueba es un error en el propio libro de reglas y no en el código construido sobre él —una capa donde las fallas pueden persistir durante años sin ser detectadas.

La respuesta estuvo a la altura del riesgo demostrado. Los investigadores de SeedLabs no se quedaron en la etapa teórica: escribieron código de ataque funcional en un entorno de prueba local y confirmaron que sí era posible producir ZEC falsificados, convirtiendo el hallazgo de una vulnerabilidad teórica en una ruta de explotación demostrada. El equipo de desarrollo de Zcash trató entonces el asunto como urgente, y el anuncio indica que el trabajo correctivo finalizó el 2 de junio.

Orchard es el pool protegido donde viven las transacciones privadas de Zcash, razón por la cual un defecto de prueba allí golpea el núcleo de la garantía de emisión de la moneda. Para un activo centrado en la privacidad, la integridad de la emisión es la propiedad más crítica, y la falla la afectó directamente.

Lo que el parche no resuelve es la pregunta sobre la explotación. La ruta de generación de falsificaciones se verificó solo en el entorno de prueba local, y nada en el registro público que la falla haya sido abusada en la mainnet. Esa distinción —vulnerabilidad encontrada, explotación demostrada localmente, abuso en la mainnet sin confirmar— es el marco con el que debe leerse cada cifra de esta historia.

Cómo funcionaba la falla de solidez de Orchard

El mecanismo en juego es estrecho pero fundamental. Una falla de solidez en un sistema de prueba de conocimiento cero significa que las verificaciones de una prueba son demasiado laxas: una afirmación que debería ser falsa puede disfrazarse para parecer demostrada. En el circuito Orchard de Zcash, esa laxitud se tradujo en una amenaza directa a la emisión, porque las notas que el pool acepta como válidas alimentan directamente la contabilidad del suministro circulante que cada nodo de la red vuelve a verificar. ZEC falsos ilimitados no serían una falla de mercado; corromperían silenciosamente la garantía de emisión que un protocolo de Capa 1 existe para hacer cumplir.

Vale la pena señalar dos salvaguardas estructurales. El pool Orchard opera bajo un límite de emisión, un techo de acuñación, y la introducción del pool Ironwood fue diseñada para que, incluso si ocurriera un error de prueba de conocimiento cero, los fondos totales capaces de escapar de la zona protegida sean limitados —la verificación del suministro ya estaba reforzada contra exactamente esta clase de falla.

Según la interpretación que ofrece el propio anuncio, la IA no rompió la criptografía: identificó rápidamente un error de lógica que el código público había cargado durante años sin que investigadores humanos lo detectaran, y luego validó que el error era explotable. El caso no es, por tanto, una criptografía rota, sino un error de lógica pasado por alto durante mucho tiempo que fue expuesto y validado rápidamente. Ese es el verdadero significado del episodio —las bases de código públicas y los sistemas de automatización de transacciones son ahora objetivos legítimos para este tipo de análisis automatizado de ataques.

Al cierre de esta edición, el ZEC al contado cae 8.0% en las últimas 24 horas, y nada en el registro on-chain vincula el movimiento con el anuncio.

Qué ha cambiado el parche

El parche del 2 de junio cambió la realidad técnica, mientras el registro de evidencias sigue deliberadamente delgado. No hay hash de transacción de atacante que citar ni monto drenado que verificar on-chain, porque los datos on-chain no muestran explotación confirmada en la mainnet. El propio anuncio de SeedLabs sirve como autopsia, señalando una condición de verificación sin restricciones en el circuito Orchard como causa raíz y el parche de emergencia completado como remediación. Lo que permanece sin abordar es igualmente claro: no se ha publicado ninguna cronología independiente de algún intento de falsificación en la mainnet.

Las preguntas abiertas que quedan son cuestiones de documentación. Si alguna vez emerge una cronología independiente de un intento de falsificación en la mainnet, y cuánto detalle técnico adicional sobre la restricción defectuosa se publica más allá del resumen del anuncio, son los marcadores que completarían el historial.

Frente a ese historial limpio, el interés institucional ha seguido creciendo —la división ZCSH de Grayscale de 3 por 1 y los 320 millones de dólares en ZEC de Garret Jin enmarcan un mercado que trató el incidente como contenido.