ZEC se desploma a la mitad en un día, tras lo cual Claude Opus 4.8 hace su debut y derrota a Zcash

Escribir artículo: Shannon@金色财经

Actualización: ZEC a las 15:05 cayó por debajo de los 300 dólares, con una caída del 50% en 24 horas.

ZEC cayó en 24 horas de casi 700 dólares a 400 dólares, borrando las ganancias del último mes. Ahora se conocen las causas.

Resulta que no solo Arthur Hayes vendió ZEC, sino que también Zcash reveló una vulnerabilidad de seguridad que permite falsificar ZEC de forma ilimitada.

Lo que es aún más notable es que esta vulnerabilidad fue descubierta con la ayuda del modelo de gran escala Claude Opus 4.8 más reciente. Además, esta vulnerabilidad ha existido durante 4 años.

1. Contexto del evento

A principios de junio de 2026, la criptomoneda centrada en la privacidad Zcash (ZEC) enfrentó una de las crisis de seguridad más severas desde su creación.

El 29 de mayo de 2026, el investigador de seguridad independiente Taylor Hornby, durante una auditoría del protocolo encargada por Shielded Labs, utilizó el modelo de gran escala Claude Opus 4.8, lanzado por Anthropic el 28 de mayo, para descubrir una grave vulnerabilidad de falsificación en el pool Orchard de Zcash, que permitía a un atacante crear una cantidad ilimitada de ZEC falsificados sin ser detectado, y esa misma noche realizó una divulgación responsable a Zcash Open Developer Labs (ZODL).

Esta vulnerabilidad había estado latente desde que se lanzó el pool Orchard en mayo de 2022, y permaneció sin ser detectada hasta que los ingenieros la cerraron esta semana, tras aproximadamente cuatro años.

2. Análisis técnico: un defecto fatal en los circuitos de pruebas de conocimiento cero

Para entender este evento, primero hay que comprender la arquitectura técnica central de Zcash.

¿Qué es una prueba de conocimiento cero (ZKP)? La protección de la privacidad en Zcash depende de la tecnología de ZKP, que permite a los usuarios demostrar en la red que "esta transacción es válida" sin revelar detalles de la misma. Orchard es el pool de privacidad más avanzado y reciente de Zcash, que utiliza el sistema de pruebas Halo2.

Causa raíz de la vulnerabilidad: El problema radica en una restricción insuficiente en un componente del circuito Orchard, donde un atacante puede introducir una entrada falsa en una verificación de curva elíptica y aún así hacer que pase.

En términos sencillos, es como si la cerradura de un banco estuviera diseñada para verificar que la llave tenga la forma correcta, pero debido a un fallo en la lógica de verificación, algunas llaves con forma incorrecta también logran pasar.

Significado de la "vulnerabilidad de integridad": En proyectos de pruebas de conocimiento cero como Zcash, "integridad" (soundness) significa que el sistema solo debe aceptar transacciones y cambios de estado válidos. Esta vulnerabilidad hace que el sistema pueda aceptar transacciones que deberían ser rechazadas.

Impacto específico: La vulnerabilidad está en una falla de integridad en la implementación del circuito Orchard en la biblioteca de gadgets halo2. Si se explota, podría permitir pagos dobles en el pool Orchard, pero debido a que Zcash tiene un mecanismo de "puerta giratoria" que protege la cantidad total en circulación, no se puede inflar directamente el total de ZEC.

Importancia del descubrimiento asistido por IA: Shielded Labs reveló que Hornby, con la ayuda del modelo Opus 4.8 de Anthropic y herramientas de IA personalizadas, escribió un programa completo para explotar la vulnerabilidad, que en un entorno de prueba local generó una cantidad ilimitada de ZEC falsificados. Si se ejecutara en la red principal, la misma herramienta podría producir ZEC falsificados en cantidades ilimitadas y sin detección. Es la primera vez que un gran modelo de IA se documenta como utilizado para descubrir y escribir código de explotación de vulnerabilidades graves en protocolos criptográficos, marcando un nuevo avance en la seguridad.

3. Respuesta de emergencia: una gestión de crisis ejemplar

La velocidad y coordinación del equipo de Zcash son dignas de elogio.

Todo el proceso, desde el descubrimiento hasta la reparación, duró solo cinco días.

Primera fase — descubrimiento de la vulnerabilidad (29-30 de mayo): El 29 de mayo de 2026, Taylor Hornby detectó una grave vulnerabilidad de falsificación en el pool Orchard de Zcash. Hornby divulgó la vulnerabilidad a Zcash Open Developer Labs (ZODL).

Segunda fase — soft fork de emergencia (1 de junio): Se activó un soft fork temporal en el bloque 3,363,426, aproximadamente a las 02:00 UTC, desactivando las operaciones Orchard en toda la red, para dar tiempo a los desarrolladores de corregir el código.

Tercera fase — hard fork NU6.2 (2 de junio): El hard fork NU6.2 se activó en el bloque 3,364,600, aproximadamente a la 00:05 hora del este de EE. UU., y con el circuito corregido se reactivó Orchard. Desde la divulgación privada hasta la activación final, todo el proceso duró cinco días.

¿Por qué fue necesario un hard fork? Porque la reparación del circuito de prueba de conocimiento cero requiere una "clave de verificación fija" (verifying key) nueva, y un soft fork no puede realizar este cambio.

Justificación de la coordinación confidencial: Durante la reparación, el equipo deliberadamente mantuvo en secreto los detalles de la vulnerabilidad y coordinó en privado con mineros y exchanges para evitar que actores maliciosos explotaran la vulnerabilidad antes de que se aplicara el parche. Este modo de "divulgación responsable" (Responsible Disclosure) es la práctica estándar en la industria, y en esta ocasión se ejecutó de manera completa y normativa.

4. Incertidumbre en el mercado: el costo de la privacidad

El problema más profundo de este incidente radica en la característica más valorada de Zcash: la privacidad.

Por el diseño de privacidad de Orchard, desde la perspectiva criptográfica, no es posible saber si la vulnerabilidad fue explotada antes de ser reparada.

En otras palabras, "no hay señales evidentes de explotación" no equivale a "se puede confirmar que no fue explotada".

Esta contradicción fundamental hace que la declaración de la Fundación Zcash no pueda ser completamente tranquilizadora.

Por ello, Shielded Labs propuso una actualización en la red Zcash que permita a cualquier persona verificar que la oferta de monedas privadas no ha sido inflada secretamente. Este paso va más allá de la reparación de emergencia activada el 3 de junio.

La propuesta refleja también un dilema eterno en las blockchains de privacidad: cuanto más fuerte sea la privacidad, más difícil será demostrar inocencia.

5. Precedentes históricos y lecciones para la industria

No es la primera vez que Zcash enfrenta un defecto criptográfico importante.

En 2019, el equipo reveló una vulnerabilidad de falsificación en el pool de privacidad Sprout, que había pasado desapercibida durante años. Esa vulnerabilidad tampoco tiene registros conocidos de explotación, y la reacción del mercado fue de confianza, no de pánico.

Las reflexiones más amplias derivadas de este evento:

1. La IA transformará el panorama de auditorías de seguridad. La ayuda de IA para detectar vulnerabilidades significa que tanto atacantes como defensores tendrán herramientas más poderosas. Auditorías periódicas y frecuentes asistidas por IA serán un estándar para la seguridad de protocolos de alto valor.

2. La contradicción entre "privacidad" y "auditoría" se profundizará. La tensión entre reguladores, usuarios y desarrolladores de protocolos se verá amplificada en eventos similares. Encontrar un equilibrio entre protección de la privacidad y transparencia en crisis será un reto a largo plazo en el sector de las monedas privadas.

3. La capacidad de respuesta ante emergencias será la ventaja competitiva de los protocolos. Completar en cinco días todo el ciclo desde descubrimiento, coordinación privada, soft fork y hard fork demuestra la madurez y colaboración del ecosistema. En contraste con casos donde la falta de coordinación retrasó la reparación, la gestión de Zcash puede considerarse un ejemplo a seguir.

4. La reconstrucción de la confianza del mercado requiere tiempo. La volatilidad a corto plazo refleja asimetría de información y reacciones emocionales, no un juicio sobre el valor fundamental del protocolo. Antes del incidente, ZEC ya había subido más de 16 veces desde su mínimo en julio de 2024, y la validez de esa tendencia aún está por verse.

Conclusión

El incidente de la vulnerabilidad en Orchard de Zcash es una intersección de fallos técnicos, capacidades de IA, gestión de crisis y psicología del mercado.

Ilustra claramente los desafíos que enfrentan las blockchains de privacidad en el mundo real: cuando la protección criptográfica se resquebraja, la tensión entre transparencia y privacidad se revela de la forma más directa.

La reparación ya se ha realizado.

Pero la verdadera prueba será si este ecosistema puede, antes de la próxima vulnerabilidad, construir defensas más sólidas y mecanismos de verificación más confiables.