Puntos clave de la noticia:
- David Schwartz tranquilizó a los holders de Zcash al señalar que las monedas pasivas deberían seguir seguras si la vulnerabilidad de Orchard nunca fue explotada.
- La falla afectó al pool blindado Orchard basado en Halo 2 desde mayo de 2022 hasta el hard fork NU6.2 del 2 de junio.
- Los desarrolladores corrigieron el circuito, pero el diseño de privacidad de Zcash impide probar de forma definitiva que nunca se creó ZEC falsificado, dejando alivio para holders pero incertidumbre sobre el suministro.
David Schwartz, de Ripple, intervino en una de las crisis técnicas más incómodas de Zcash con un mensaje que resulta tranquilizador, pero incompleto. El problema gira en torno a una vulnerabilidad crítica en el pool blindado Orchard, corregida mediante el hard fork de emergencia NU6.2 el 2 de junio. Schwartz dijo que los holders pasivos que no muevan sus monedas deberían seguir seguros si el bug nunca fue explotado. La parte difícil es la condición que acompaña ese alivio, porque el diseño de privacidad de Zcash hace imposible probar si alguna vez se creó ZEC falsificado durante la ventana de exposición.
If there was no exploit, everyone is safe whether they move their coins or not. They'll eventually be a bit lonely in the deprecated pool, but they'll still be safe and accessible.
— David 'JoelKatz' Schwartz (@JoelKatz) June 7, 2026
El bug de Orchard convierte la privacidad en incertidumbre sobre el suministro
La falla estaba dentro de la capa de privacidad Orchard basada en Halo 2, introducida con Network Upgrade 5 en mayo de 2022. Involucraba un elemento subrestringido en el gadget de multiplicación de curva elíptica dentro del crate halo2_gadgets, donde entradas diseñadas de forma maliciosa podían evadir controles de validez. Taylor Hornby descubrió el problema el 29 de mayo de 2026, con ayuda de métodos formales asistidos por IA, y confirmó un exploit funcional en un entorno local de regtest. La vulnerabilidad no era teórica en laboratorio, ya que el mismo camino en mainnet podría haber generado ZEC ilimitado e indetectable.
Los desarrolladores de Zcash se movieron rápido tras la divulgación. Zebra 4.5.3 fue lanzado como soft fork de emergencia para desactivar temporalmente las transacciones Orchard, seguido por NU6.2 mediante Zebra 5.0 en el bloque 3,364,600 el 2 de junio. El parche corrigió el circuito hacia adelante, pero no pudo auditar retroactivamente la ventana de cuatro años desde la activación de Orchard hasta el 1 de junio de 2026. Ahí es donde la privacidad se convierte en un problema de mercado, porque la misma opacidad que protege a los usuarios también impide una prueba criptográfica definitiva de que el suministro permaneció intacto.
El punto de Schwartz se centró en la propiedad, no en la certeza del suministro. Argumentó que las reglas de consenso y la compatibilidad hacia atrás pueden mantener los balances de pools antiguos seguros y accesibles incluso si esos pools eventualmente quedan obsoletos. Eso importa para holders preocupados por que la inactividad por sí sola pueda dejar fondos atrapados. Aun así, el mercado reaccionó al riesgo imposible de verificar, con ZEC cayendo más de 30% en una sola sesión tras la divulgación del 29 de mayo y tocando brevemente su nivel más bajo en más de un mes. El mensaje tranquiliza a los holders, pero no cierra la brecha de confianza más amplia, dejando a Zcash con la tarea de reconstruir credibilidad alrededor de una vulnerabilidad ya parcheada, pero que históricamente todavía no puede descartarse por completo.
