El bug Orchard de Zcash, explicado — qué significa un fallo de solidez en conocimiento cero para las monedas de privacidad

Lo que sucedió, en orden

El pool Orchard de Zcash es su pool blindado más reciente — activado en mayo de 2022 (actualización de red NU5), construido sobre el sistema de pruebas Halo 2 y diseñado específicamente para eliminar el riesgo de configuración confiable que afectaba a los pools anteriores de Zcash. A finales de mayo de 2026, el investigador de seguridad Taylor Hornby — contratado por Shielded Labs precisamente para este tipo de auditoría proactiva — encontró un bug de solidez en el circuito Orchard. Al día siguiente del lanzamiento de Claude Opus 4.8 por Anthropic, lo utilizó dentro de un entorno de auditoría personalizado y produjo una prueba de concepto funcional: en un entorno local de regtest ejecutando las mismas reglas que la red principal, duplicó repetidamente el valor de una nota hasta que una billetera tenía más de 10 millones de ZEC. La prueba se verificó. La red lo habría aceptado.

Desde el descubrimiento hasta la corrección permanente: unos cinco días, sin división de cadena, y un informe público inusualmente sincero. Ten presente esa calidad de respuesta — importa para cómo lees el resto.

El bug en términos simples

Una prueba de conocimiento cero te permite convencer a un verificador de que una afirmación es verdadera — «esta transacción es válida» — sin revelar los secretos detrás de ella (montos, remitente, destinatario). Para que eso sea seguro, el sistema de prueba debe tener solidez: debe ser imposible producir una prueba de aspecto válido para una afirmación falsa.

La falla de Orchard fue un gadget sub-restringido — específicamente en el código de multiplicación escalar de curva elíptica de base variable del que depende el circuito. En lenguaje sencillo: el circuito olvidó fijar completamente una de las relaciones matemáticas que se suponía debía imponer. Esto dejó un hueco por el que un probador podía introducir valores secretos arbitrarios y aún así satisfacer cada verificación que ejecutaba el verificador. La solidez se rompió. El sistema de prueba aceptaba transiciones de estado inválidas — notas fantasma, saldos inflados, dobles gastos dentro del pool — como si fueran legítimas.

Una nota de precisión para la credibilidad: esto no fue un agujero en la especificación del protocolo de alto nivel, sino un bug a nivel de gadget en la biblioteca de pruebas subyacente — una clase común y notoriamente sutil de error de implementación en conocimiento cero. Los gadgets de multiplicación escalar están entre las cosas más difíciles de restringir completamente en un circuito, razón exacta por la cual los mejores criptógrafos y auditorías previas no lo detectaron durante cuatro años.

Por qué «sin inflación» y «grave» son ambos ciertos

La tranquilidad del titular fue precisa: el suministro total de ZEC nunca se infló y no se robó ningún fondo de usuario. Pero el encuadre más cuidadoso — «el bug no creó inflación extraíble, sin embargo la integridad del saldo dentro del pool Orchard se volvió momentáneamente indemostrable» — es la parte que realmente movió al mercado, y vale la pena entenderla.

• Lo que el bug podía hacer: crear transiciones de estado inválidas dentro del pool blindado — notas falsas, saldos internos inflados. Dado que el pool es privado por diseño (montos y participantes ocultos, pruebas de conocimiento cero), no hay forma después del hecho de probar o refutar criptográficamente que alguien lo explotó durante la ventana de cuatro años.
• Lo que el bug no podía hacer: sacar ese valor fantasma fuera de Orchard hacia ZEC transparente o expandir la base monetaria visible. Ese es el trabajo del torniquete (siguiente sección), y funcionó.

Así que para una moneda que se comercializa como dinero sólido privado, el problema residual no es «alguien vació el tesoro». Es que la integridad de la contabilidad interna del pool privado dependía enteramente de un circuito que resultó estar roto — y no puedes auditar un pool privado sumándolo. Esa incognoscibilidad, no un robo confirmado, es lo que los tenedores vendieron. Shielded Labs ha dicho desde entonces que está explorando un nuevo pool blindado con contabilidad de migración forzada para que la integridad del suministro sea verificable públicamente en el futuro, además de la verificación formal del circuito.

El torniquete: el héroe anónimo

El torniquete de Zcash es un invariante contable a nivel de consenso entre sus pools de valor (transparente, los pools blindados heredados Sprout y Sapling, y Orchard). La regla es simple y contundente: cada transacción blindada revela el monto neto que entra o sale de un pool, la cadena rastrea el saldo corriente de cada pool, y cualquier bloque que hiciera negativo el saldo de un pool es rechazado.

Esta es defensa en profundidad superpuesta sobre las pruebas de conocimiento cero, y es precisamente lo que contuvo este bug. Un atacante que acuñara notas falsas podía inflar saldos dentro de Orchard, pero en el momento en que intentara desblindar ese valor hacia afuera, la salida declarada del pool excedería todo lo que alguna vez había entrado legítimamente — y el consenso lo rechazaría. El torniquete actúa como una puerta blindada: una falla de solidez en un pool no puede filtrarse al suministro global. Por eso cada informe creíble pudo decir honestamente «sin inflación de suministro, sin fondos robados», sin poder aún certificar el historial interno del pool.

La lección más profunda: solidez de circuito vs el modelo de Monero

Es tentador leer esto como «conocimiento cero malo, Monero bueno». Esa no es la conclusión honesta. La conclusión honesta es sobre dónde concentra cada diseño su riesgo.

Orchard fue en sí mismo una respuesta a una crítica anterior válida de Zcash: sus primeros pools usaban un sistema de prueba que requería una configuración confiable, donde una ceremonia de configuración comprometida podía permitir la falsificación indetectable para siempre. Halo 2 eliminó esa configuración confiable. Pero este incidente muestra el costo de esa compensación: sin configuración confiable, la implementación del circuito debe ser perfectamente sólida — cada gadget, cada restricción, cada operación de curva elíptica. Una sola relación sub-restringida en cualquier lugar rompe toda la garantía, y esos gadgets son extraordinariamente difíciles de hacer exactamente bien.

Monero hace un trato diferente. No tiene un único circuito que deba codificar toda la relación de validez. Su privacidad proviene de maquinaria algebraica más directa: los compromisos Pedersen más pruebas de rango ocultan los montos (RingCT), las firmas de anillo proporcionan ambigüedad del firmante frente a salidas señuelo, las direcciones ocultas hacen de cada salida una clave de un solo uso, y las imágenes de clave previenen los dobles gastos. Menos capas de abstracción se sitúan entre «la transacción es válida» y «las matemáticas cuadran», lo que significa una superficie más pequeña para esta clase específica de bug de «forjar valor mediante un circuito roto».

• Zcash blindado (Orchard): fuerte privacidad teórica — montos, remitente, destinatario y memo completamente ocultos, un conjunto de anonimato dentro del pool en crecimiento — a costa de tener que mantener un sistema de restricciones muy complejo 100% correcto y re-auditado en cada cambio. La privacidad también es opcional, con un respaldo transparente.
• Monero: privacidad obligatoria, activada por defecto con fuerte desvinculabilidad práctica, a costa de transacciones más grandes y un perfil de riesgo diferente centrado en la calidad de los señuelos, heurísticas de selección de salida y el endurecimiento continuo de primitivas (por ejemplo, la actualización FCMP++ en curso).

Ambos dependen en última instancia de una implementación correcta y revisión continua. ZK compra «privacidad matemática» exigiendo perfección en el circuito; RingCT obtiene privacidad obligatoria usable con verificaciones más explícitas pero sus propias compensaciones de ingeniería. Ninguno es magia.

Lo que Zcash hizo bien — y lo que hay que mantener honesto

Una guía neutral debe decir esto claramente: el manejo de Zcash fue un modelo de divulgación responsable. El equipo contrató a un investigador específicamente para buscar estos bugs antes de que los atacantes pudieran; coordinaron en privado con mineros y exchanges; enviaron una corrección en dos fases en días; y divulgaron completamente, negándose explícitamente a afirmar que la explotación era imposible. Dijeron, en efecto, «no podemos descartar criptográficamente que esto se usó — no confíes en 'probablemente está bien'». Esa franqueza es rara y correcta.

Y los contrapuntos que mantienen honestos a los defensores de Monero:

• «Más simple es siempre más seguro» es demasiado fuerte. Monero ha tenido su propio escrutinio histórico y su cuota de bugs de billetera y nodo a lo largo de los años, y su modelo obligatorio significa que todo el valor depende de sus elecciones de diseño sin opción de salida.
• Los bugs de gadget y restricción son un desafío recurrente en toda la industria ZK, no un fallo específico de Zcash.
• El torniquete y la respuesta rápida son ingeniería genuinamente impresionante. El mercado castigó la incognoscibilidad, amplificada por el apalancamiento y al menos un gran tenedor público (Arthur Hayes) saliendo con la línea de que las narrativas de privacidad exigen «perfección, no 'probablemente está bien'». Monero solo experimentó ventas leves por simpatía.
• Ciertas afirmaciones marginales de «puerta trasera intencional» circularon. Tienen baja credibilidad; un lector neutral debería descartarlas.

Qué significa esto para ti

Si tienes o usas cualquiera de las dos monedas, la lectura práctica:

• Este es un caso de estudio en defensa en profundidad, no un aviso de defunción para ZK. El torniquete hizo su trabajo; las pruebas no, y un respaldo lo atrapó. Los sistemas que asumen que sus propios componentes pueden fallar envejecen mejor que los que no.
• La «solidez» es existencial para cualquier dinero privado — ya sea la solidez de un circuito o la solidez algebraica de RingCT. Trata la cadencia de auditoría y la verificación formal como características, no como sobrecarga.
• La privacidad obligatoria vs opcional es un eje real. El modelo sin opción de salida de Monero es una apuesta diferente de la realidad multi-pool y mayormente transparente de Zcash — elige según si quieres que la privacidad sea el valor predeterminado o una elección.
• La era de la auditoría por IA corta en ambos sentidos. Un defensor con el entorno adecuado encontró en un día lo que cuatro años de revisión experta pasaron por alto. También podría hacerlo un atacante. La auditoría proactiva asistida por IA es ahora un requisito básico para los protocolos de privacidad.

¿Nuevo en la privacidad sin KYC y tratando de decidir por dónde empezar? Consulta Cómo comprar Monero sin KYC y la lista de billeteras verificada. El objetivo de esta guía no es coronar a un ganador — es asegurarse de que entiendas en qué estás confiando realmente en cada diseño.