ZEC cae más del 30% tras la caída: una vulnerabilidad de "emisión infinita" que no se puede demostrar si ha sido explotada

Título original: La caída de ZEC más del 30% tras una vulnerabilidad de «emisión infinita» que no puede ser probada si ha sido explotada

Autor original:律动BlockBeats

Fuente original:

Reproducción: Mars Finance

TL;DR

El 5 de junio, Zooko Wilcox, fundador de Zcash, publicó un raro análisis de seguridad en profundidad.

El artículo revela que el investigador de seguridad Taylor Hornby descubrió el 29 de mayo que la última generación de la piscina de privacidad Orchard en Zcash tiene una grave vulnerabilidad de falsificación. Los atacantes pueden construir una transacción que no debería pasar la verificación, generando ZEC falsificados de forma ilimitada y no detectable dentro de Orchard.

Esto no es solo un riesgo teórico. Taylor ya ha desarrollado un programa completo de explotación en un entorno de prueba local, generando ZEC falsificados en la práctica. Si dicho programa se desplegara en la red principal, en teoría, los atacantes podrían crear una cantidad ilimitada de activos falsificados en sus propias billeteras principales.

Tras hacerse pública la noticia, ZEC cayó más del 30%. Datos de CoinMarketCap muestran que ZEC bajó a un mínimo de 408,39 dólares en 24 horas, aproximadamente un tercio por debajo del pico de 610,47 dólares en ese mismo período. Lamentablemente, este ha sido uno de los pocos activos en el mercado de criptomonedas con un efecto de riqueza tan positivo recientemente, con una narrativa muy favorable y respaldada por numerosos grandes actores, que ahora ha sido completamente destruida por esta vulnerabilidad.

Si solo se mira el resultado, parece otra vez un incidente de seguridad en criptomonedas familiar: se descubre la vulnerabilidad, los desarrolladores la corrigen urgentemente, y el mercado entra en pánico.

Pero lo que hace que el incidente de Orchard sea realmente complicado es que, aunque la vulnerabilidad ya ha sido corregida, la comunidad de Zcash no puede responder directamente a otra pregunta aún más sensible:

¿Alguien ha explotado esta vulnerabilidad en los últimos cuatro años?

Corrección urgente en cuatro días, Orchard suspendido temporalmente

Orchard es la nueva generación de protocolo de pago privado de Zcash, activada en 2022, y actualmente uno de los principales pools de privacidad utilizados en Zcash. Los usuarios pueden ocultar saldos, montos de transacción y flujo de fondos, además de demostrar mediante pruebas de conocimiento cero que sus transacciones cumplen con las reglas.

Según la línea de tiempo divulgada por Zooko, Shielded Labs y la comunidad de Zcash, Taylor detectó anomalías durante una revisión de seguridad dirigida en el circuito Orchard el 29 de mayo, y de inmediato informó en privado de la vulnerabilidad al Zcash Open Development Lab (ZODL). Shielded Labs, una organización independiente con sede en Suiza que opera con donaciones y apoya el ecosistema Zcash, participa en el desarrollo del protocolo, seguridad y sostenibilidad de la red, sin estar afiliada a la Fundación Zcash ni a ZODL.

Los ingenieros de ZODL confirmaron la existencia del problema en pocas horas tras recibir el informe y comenzaron a buscar soluciones. Debido a que publicar un parche de código directamente podría exponer la vulnerabilidad, el equipo optó inicialmente por cerrar temporalmente Orchard: prohibiendo la creación de nuevas salidas Orchard y también las transacciones que gastaran fondos existentes en Orchard.

Tras coordinar con desarrolladores, mineros, operadores de nodos, exchanges y proveedores de infraestructura, el 2 de junio entró en vigor un soft fork de emergencia. Posteriormente, Zcash actualizó la verificación del circuito Orchard mediante un hard fork y reactivó la funcionalidad de Orchard el 3 de junio. Durante ese período, las direcciones transparentes y la piscina de privacidad Sapling continuaron operando normalmente.

Desde la divulgación de la vulnerabilidad hasta la reparación completa, todo el proceso duró solo unos días. En términos de respuesta de emergencia, fue una gestión bastante exitosa.

Pero el mercado no se calmó solo con la reparación, porque la solución aborda el futuro, no el pasado.

Lo que preocupa no es que el ataque pueda seguir ocurriendo, sino que quizás ya ocurrió

Los incidentes de seguridad comunes suelen tener una magnitud de pérdida relativamente clara. En contratos inteligentes robados, se puede rastrear en la cadena cuánto dinero fue transferido por los atacantes; en vulnerabilidades en puentes cross-chain, se puede analizar el flujo de fondos y las direcciones afectadas.

El incidente de Orchard es diferente.

Según Shielded Labs, esta vulnerabilidad puede ser utilizada para generar ZEC falsificados de forma ilimitada y no detectable dentro de Orchard. Debido a que Orchard tiene propiedades de privacidad, no es posible para el exterior, solo mediante métodos criptográficos, probar con certeza si alguien explotó esta vía antes de que se corrigiera.

Esto significa que el mercado no enfrenta una cifra de pérdida ya confirmada, sino una incertidumbre difícil de cuantificar:

¿Si alguien descubrió y explotó la vulnerabilidad en el pasado, ya existen ZEC falsificados en Orchard? ¿Y en qué cantidad? ¿Siguen estos activos en la piscina de privacidad? ¿Alguna vez salieron mediante transacciones normales?

Más importante aún, esta ventana de riesgo no empezó solo el 29 de mayo. Shielded Labs indica que la vulnerabilidad ha existido desde que Orchard se activó en mayo de 2022, hasta que se completó la reparación de emergencia en junio de 2026. En otras palabras, el problema ha estado latente casi cuatro años.

Lo que realmente preocupa al mercado no es lo que ocurrió entre el 29 de mayo y el 2 de junio, sino si en estos cuatro años ya se han producido anomalías no observables directamente.

Y esa es la razón principal por la que ZEC cayó más del 30%.

El mercado no solo está vendiendo una vulnerabilidad, sino que está reevaluando la confianza en la oferta.

Un error en una restricción matemática, ¿cómo puede evolucionar en un riesgo de “emisión infinita”?

Al ver la palabra “vulnerabilidad de emisión infinita”, nuestra primera reacción es pensar que un hacker ha obtenido permisos de administrador o acceso a una puerta trasera en el protocolo.

Pero la realidad es aún más fundamental.

La seguridad de Orchard depende de un circuito de pruebas de conocimiento cero (Orchard circuit). Los usuarios pueden ocultar los detalles de sus transacciones, pero deben demostrar a la red que cumplen con las reglas del protocolo. La regla más importante es la conservación de activos: una transacción no puede crear valor de la nada.

En términos simples, los usuarios pueden no revelar cuánto ZEC poseen ni a quién transfieren, pero la red debe poder verificar que:

Los fondos gastados provienen de entradas legítimas.

El problema que encontró Taylor está en una verificación de multiplicación en curva elíptica dentro del circuito Orchard.

Shielded Labs lo describe como un “elemento sub-constrainido”, es decir, un componente del circuito con restricciones incompletas. Debido a que las relaciones matemáticas relacionadas no están completamente restringidas, un atacante puede introducir datos incorrectos en el proceso de multiplicación en curva elíptica, pero la verificación aún puede devolver un resultado positivo.

En otras palabras, el atacante no necesita romper la criptografía ni controlar nodos de la red.

Solo necesita construir un conjunto de datos que no deberían ser válidos, y hacer que el sistema crea erróneamente que la transacción cumple con la conservación de activos.

Cuando esta prueba errónea sea aceptada por la red, los ZEC que en realidad no existían podrán considerarse activos legítimos y permanecer en Orchard.

Por eso Shielded Labs usó un lenguaje extremadamente severo:

ZEC falsificados “ilimitados, indetectables”

El peligro real no solo está en la “ilimitación”, sino en la “imposibilidad de detección”.

Entre ambas expresiones, hay una diferencia importante

La Fundación Zcash en su anuncio tras la actualización afirmó que no hay evidencia de que la vulnerabilidad haya sido explotada, ni se detectó creación de valor no autorizada, y que los fondos y la privacidad de los usuarios no se vieron afectados. Además, destacó que el mecanismo de contabilidad Turnstile de Zcash puede rastrear los flujos de valor entre diferentes pools y proteger el límite total de 21 millones de ZEC.

Al mismo tiempo, Shielded Labs aclaró que no se puede confiar únicamente en pruebas criptográficas para demostrar que en la historia de Orchard nunca hubo ZEC falsificados.

Estas declaraciones parecen contradictorias, pero en realidad abordan diferentes niveles de la problemática.

El sistema de contabilidad Turnstile de Zcash puede entenderse como una “puerta” entre diferentes pools de fondos. El sistema puede contar cuántos activos legítimos hay en Orchard y limitar la cantidad que puede salir.

Supongamos que en Orchard hay originalmente 1 millón de ZEC legítimos. Aunque un atacante haya falsificado más activos en su interior, el sistema no permitirá que salgan más allá de la cantidad legítima. Esto ayuda a evitar que la oferta total de Zcash se supere fácilmente.

Pero este mecanismo no puede probar directamente que en Orchard nunca hayan existido monedas falsificadas.

Si los activos falsificados permanecen en Orchard o se reemplazan gradualmente por activos reales dentro del límite legal, el sistema de estadísticas no puede ofrecer una conclusión definitiva sobre la historia completa.

Para un proyecto de privacidad tan antiguo, solo podemos saber que, hasta ahora, no hay evidencia de emisión adicional, pero la comunidad no puede demostrar directamente que en Orchard nunca existieron activos falsificados.

Este es el tipo de riesgo más difícil de gestionar en el mercado.

No se trata solo de cuánto dinero falso se ha creado, sino de que nadie puede confirmar con certeza que nunca existió.

¿Cómo puede Zcash volver a demostrar que no hay monedas falsificadas en Orchard?

La reparación de la vulnerabilidad es solo el primer paso.

Shielded Labs ya anunció que está trabajando con otros desarrolladores de Zcash en una propuesta de actualización de red que incluye desplegar una nueva piscina de privacidad y aplicar la contabilidad Turnstile a todos los activos migrados desde Orchard.

Esto sería como poner una nueva puerta de migración en Orchard.

Los activos en la antigua Orchard, si quieren ingresar a la nueva piscina de privacidad, deberán migrar siguiendo reglas verificables. El sistema podrá volver a contar los activos legítimos que salieron y detectar si hay ZEC adicionales que no pudieron migrar normalmente.

Si la actualización se realiza con éxito, cualquiera podrá verificar la integridad de la oferta de Zcash y demostrar que no hay activos falsificados en Orchard.

El objetivo de esta propuesta no es solo arreglar el código, sino reconstruir la confianza en Orchard.

Porque en un sistema de privacidad, la confianza no proviene de “creer que no ha ocurrido un ataque”, sino de “que cualquiera pueda verificar que no ha ocurrido”.

Shielded Labs también admite que la probabilidad de que la vulnerabilidad haya sido explotada maliciosamente en el pasado es baja. La vulnerabilidad ha estado oculta durante años, y su descubrimiento fue muy difícil; Taylor la encontró en un proyecto de investigación de seguridad dedicado. Tras la divulgación, la comunidad cerró rápidamente la ventana de ataque en unos días.

Pero también enfatizan que los usuarios no deben confiar solo en la evaluación subjetiva del equipo de desarrollo.

Lo que se necesita es una prueba.

¿Por qué se descubrió una vulnerabilidad que estuvo oculta durante casi cuatro años justo ahora?

El incidente de Orchard tiene un detalle que el mercado puede pasar por alto fácilmente.

El 28 de mayo, Anthropic lanzó Claude Opus 4.8.

Un día después, Taylor descubrió la vulnerabilidad en Orchard.

Según la revisión de Zooko y Shielded Labs, poco después del lanzamiento de Opus 4.8, Taylor la utilizó para una auditoría altamente dirigida del circuito Orchard y encontró el problema el 29 de mayo. Luego, con la ayuda de Opus 4.8, desarrolló un programa completo de explotación que en un entorno local generó ZEC falsificados ilimitados y no detectables.

Este detalle es importante, no porque la IA pueda realizar auditorías criptográficas de forma independiente.

La información pública no respalda esa conclusión exagerada.

Taylor es un investigador de seguridad con experiencia. Shielded Labs también menciona que utilizó métodos tradicionales, marcos de IA personalizados y prompts diseñados específicamente. Opus 4.8 fue una herramienta importante en la auditoría, pero no la única.

Lo realmente relevante es que Taylor no usó el modelo de IA especializado en seguridad de Anthropic, sino el modelo general Opus 4.8, que acaba de ser lanzado públicamente.

Anthropic describe a Mythos Preview como un modelo avanzado con capacidad para detectar y explotar vulnerabilidades. Debido a los riesgos de abuso, no lo han abierto al público, sino que lo proporcionan a socios seleccionados a través de Project Glasswing.

En cambio, Opus 4.8 es un modelo general accesible a cualquier desarrollador. En su anuncio, Anthropic destaca mejoras en análisis de código, ejecución de tareas complejas y detección de errores.

Esto envía una señal importante:

La capacidad de detectar vulnerabilidades de alto valor se está extendiendo desde modelos especializados a modelos generales.

Un modelo general publicado solo un día antes, guiado por un investigador experto, ya puede participar en auditorías de circuitos complejos de pruebas de conocimiento cero y ayudar a descubrir una vulnerabilidad oculta casi cuatro años.

Esto no significa que los criptógrafos ya no sean importantes.

Al contrario, la experiencia de Taylor, la selección de objetivos y la verificación de los resultados del modelo siguen siendo clave en todo el proceso.

Pero la combinación de expertos y IA está reduciendo significativamente los costos de descubrir vulnerabilidades complejas.

El agujero ya se cerró, pero el mercado sigue esperando respuestas

Para Zcash, la ventana de ataque más urgente ya se cerró.

Las funciones de Orchard se han restaurado, los circuitos de verificación se han actualizado y no hay evidencia de que la vulnerabilidad haya sido explotada maliciosamente.

Pero la caída del 30% en ZEC indica que lo que preocupa al mercado no es solo si el código fue reparado.

El mercado sigue esperando una respuesta más definitiva:

¿En los últimos casi cuatro años, hubo alguna vez ZEC falsificado en Orchard?

Si la nueva piscina de privacidad y la actualización de Turnstile se implementan con éxito, la comunidad tendrá la oportunidad de verificar la integridad de la oferta y restablecer la confianza del mercado.

Pero antes de esa prueba, todavía hay un suspenso difícil de ignorar en el incidente de Orchard:

¿Es cierto que los ZEC falsificados, que en teoría podrían generarse ilimitadamente, nunca existieron realmente, o alguna vez estuvieron ocultos en lugares que nadie pudo ver directamente?