← Volver a la Bitácora

El exploit de Orchard y la migración a Ironwood

El exploit de Orchard y la migración a Ironwood

En mayo de 2026 Zcash estuvo a horas de una catástrofe silenciosa: un error de solidez en el circuito de su pool de privacidad Orchard permitía, en teoría, falsificar ZEC de la nada sin dejar rastro. Nunca fue explotado — o al menos, es criptográficamente imposible saberlo. Lo que siguió fue una de las respuestas más metódicas de la historia de la criptografía aplicada: parche de emergencia, torniquete de contención, y un pool nuevo verificado teorema por teorema con Lean.

Esta guía recorre el incidente completo y la migración a Ironwood, con la verificación de cada dato contra las fuentes primarias del ecosistema (Zcash Open Development Lab, ZIPs oficiales y el repositorio de verificación formal).

El evento: una auditoría que se adelantó a los atacantes

Slide: el descubrimiento del error de solidez por Taylor Hornby

El 29 de mayo de 2026, el investigador Taylor Hornby detectó un error de solidez durante una auditoría focalizada del circuito Orchard, asistida por IA y financiada por Shielded Labs. El hallazgo se reportó en privado a Zcash Open Development Lab (ZODL) — sin divulgación previa — y el ecosistema aplicó un parche de emergencia: primero un soft fork que desactivó Orchard temporalmente, y luego el upgrade NU6.2 (ZIP 257) que reactivó el pool con el circuito corregido.

Anatomía de una falla criptográfica

Slide: anatomía de la falla en la multiplicación de curva elíptica

El defecto (CVE-2026-54496, GHSA-ww9q-8r59-xv46) era una restricción faltante — una missing copy constraint — en la multiplicación escalar de base variable del gadget halo2_gadgets. Consecuencia: un probador podía crear transacciones inválidas que acuñaran ZEC de la nada dentro del pool, rompiendo la vinculación matemática sin activar alarmas. Un error diminuto; una puerta trasera teóricamente infinita.

La paradoja de la privacidad perfecta

Slide: la paradoja de auditar un pool 100% zero-knowledge

Orchard es un pool 100% Zero-Knowledge: cantidades y participantes están matemáticamente cifrados. Eso significa que es criptográficamente imposible auditar su historial interno para saber si el fallo fue explotado antes del parche. Zcash asumió la peor posibilidad teórica y diseñó una contención absoluta.

El torniquete: contener sin romper la privacidad

Slide: el mecanismo del torniquete sobre el pool Orchard

La primera línea de defensa fue la regla del turnstile (torniquete), que el protocolo de Zcash sostiene desde su diseño: un pool de privacidad jamás puede retirar hacia el exterior más ZEC del que originalmente ingresó — matemáticamente, (in) ≥ (out). En consenso, ZIP 209 la refuerza prohibiendo balances de pool fuera de rango. Al activarse el torniquete, el pool quedó encapsulado como entorno de solo retiro: aunque hubiera monedas falsas adentro, ninguna podía escapar.

El suministro total está intacto

Slide: verificación del suministro y el límite de 21 millones de ZEC

Con Orchard en modo solo retiro, ninguna inflación neta puede filtrarse al suministro visible, que se verifica y cuenta on-chain. El límite histórico absoluto de 21 millones de ZEC se mantiene.

Migración a Ironwood (NU6.3)

Slide: el retiro de Orchard y el nacimiento de Ironwood el 28 de julio

El 28 de julio de 2026, el upgrade NU6.3 (ZIP 258) activó Ironwood en el bloque 3.428.143: el pool Orchard quedó sellado permanentemente con ~3,66 millones de ZEC (~USD 1.700 millones), y nació un nuevo pool blindado, independiente y matemáticamente verificado.

¿Qué es la verificación formal en Lean?

Slide: qué es Lean y por qué no es una IA probabilística

Lean no “lee código buscando errores”: es un asistente de pruebas matemáticas que revisa mecánicamente la lógica pura. En lugar de humanos diciendo “no encontramos errores”, Lean demuestra que un sistema cumple propiedades específicas — eliminando el error de razonamiento humano del núcleo.

Más de 2.700 teoremas probados mecánicamente

Slide: los 2.700+ teoremas y la propiedad de knowledge soundness

El repositorio zcash/ironwood contiene la prueba asistida por máquina de la solidez del SNARK y del circuito del nuevo pool: más de 2.700 teoremas en Lean 4 que cubren el verificador Halo 2 desplegado y las capas de seguridad del protocolo (balance, key binding, juegos de seguridad del modelo de ledger). La propiedad central garantizada es la knowledge soundness: bajo las asunciones criptográficas base, es matemáticamente imposible que existan bugs de falsificación oculta en Ironwood.

Auditoría por IA vs. verificación formal

Slide: matriz de seguridad — detección empírica vs. garantía matemática

La lección del incidente cabe en una matriz: la auditoría por IA (como la que encontró el bug en Orchard) es una búsqueda proactiva de fallos — empírica, poderosa, pero con falsos negativos posibles. La verificación formal no encuentra errores: demuestra que no pueden existir. Zcash usó ambas: la primera para encontrar el exploit; la segunda para asegurar el circuito del futuro.

ZIP 318: la migración privada

Slide: el problema de migrar un saldo sin dejar rastro

Los fondos de Orchard no se mueven solos: cada titular debe migrarlos al nuevo pool. Pero una transacción masiva dejaría un rastro evidente en la cadena. ZIP 318 define una migración automática diseñada para preservar la privacidad: divide y camufla los fondos al cruzar hacia Ironwood.

Slide: denominaciones estandarizadas de 1, 2 y 5 ZEC

Para evitar patrones reconocibles, el saldo no se mueve como un total exacto: el software lo descompone en fracciones estandarizadas (expansión decimal en múltiplos de 1, 2 y 5 ZEC por posición), haciendo las transacciones indistinguibles de las de miles de otros usuarios.

Slide: dispersión temporal aleatoria entre transacciones

Luego, dispersión temporal: las billeteras no envían todas las fracciones a la vez, sino que introducen pausas aleatorias entre envíos (según ZIP 318, retardos muestreados de una distribución exponencial), para impedir que un observador agrupe los movimientos bajo una sola entidad.

Slide: privacidad a nivel de red con Tor o Nym

La cadena de Zcash es privada, pero la dirección IP no lo es. ZIP 318 exige que las billeteras ofrezcan rutear la migración por redes de anonimato como Tor o Nym — una capa opt-in que, al activarse, aísla los metadatos de red. (Matiz verificado: el ruteo por Tor/Nym es una opción que la wallet debe ofrecer y el usuario puede habilitar; no es un mandato incondicional del protocolo.)

El triunfo de la ingeniería metódica

Slide: detección, contención, garantía y transición

Cuatro fases definieron la respuesta: detección (la IA de los auditores se adelantó a los atacantes), contención (el torniquete preservó el límite de 21M de ZEC), garantía (la verificación formal convirtió a Ironwood en una fortaleza demostrable) y transición (ZIP 318 garantiza un cruce privado y seguro). La crisis probó los cimientos del ecosistema — y este no solo se recuperó: evolucionó.

Fuentes verificadas

  • Zcash Open Development Lab — Zebra 4.5.3 y 5.0.0: emergencia y activación de NU6.2 (zfnd.org)
  • Shielded Labs — The Orchard Counterfeiting Vulnerability (shieldedlabs.net)
  • GitHub Advisory GHSA-ww9q-8r59-xv46 (CVE-2026-54496)
  • ZIP 257 — despliegue de la mitigación temporal y NU6.2 · ZIP 258 — NU6.3 · ZIP 318 — migración Orchard → Ironwood · ZIP 209 — balances de pool fuera de rango (zips.z.cash)
  • Ironwood Verification Complete — blog de Tachyon (tachyon.z.cash) y documentación de verificación formal (zcash.github.io/ironwood)
  • CoinDesk — Zcash seals USD 1.7B shielded pool as Ironwood activates (28-jul-2026)