Durante la semana pasada (2026/06/01 - 2026/06/07), se observaron múltiples incidentes de ataque en ecosistemas blockchain. El informe de esta semana se centra en la divulgación pública de una vulnerabilidad crítica de solidez en el pool blindado Orchard de Zcash, que podría haber permitido la falsificación indetectable de ZEC. No se ha confirmado ninguna explotación en cadena, pero la divulgación desencadenó una actualización de red de emergencia y ZEC perdió más del 40% de su valor.
| Fecha | Incidente | Tipo | Pérdida estimada |
|---|---|---|---|
| 2026/06/04 | Zcash Orchard | Bug de Solidez ZK | Sin explotación confirmada |
El Mejor Auditor de Seguridad para Web3
Valida el diseño, el código y la lógica de negocio antes del lanzamiento
Destacado de la Semana: Bug de Solidez en Zcash Orchard
Este incidente se selecciona como el destacado de esta semana porque es una de las vulnerabilidades ZK más graves encontradas en producción. Una restricción de circuito faltante pasó desapercibida durante más de cuatro años a pesar de múltiples auditorías y fue finalmente encontrada mediante una revisión de seguridad asistida por IA. La clase de vulnerabilidad (relaciones insuficientemente restringidas en circuitos ZK) podría existir en cualquier protocolo construido sobre circuitos ZK.
El 4 de junio de 2026, Zcash divulgó públicamente un bug crítico de solidez en su circuito del pool blindado Orchard [1]. Una restricción faltante en el circuito de prueba de conocimiento cero rompió el vínculo criptográfico que previene el doble gasto, permitiendo potencialmente que la misma nota blindada se gaste múltiples veces sin detección. La vulnerabilidad existía desde la activación de Orchard en mayo de 2022 y fue descubierta el 29 de mayo de 2026 por el investigador de seguridad Taylor Hornby mediante una auditoría asistida por IA. Una actualización de red de emergencia (NU6.2) parcheó el circuito el 3 de junio de 2026. No se ha encontrado evidencia de explotación.
Contexto
Zcash es una blockchain de Capa-1 centrada en la privacidad cuyo token nativo es ZEC. A diferencia de Bitcoin, donde todos los detalles de las transacciones son públicamente visibles, Zcash admite transacciones blindadas a través de pruebas de conocimiento cero, ocultando las direcciones del remitente, las direcciones del destinatario y los montos de las transacciones. Zcash tiene múltiples pools blindados, cada uno correspondiente a una generación diferente de su protocolo de privacidad. Orchard es la última generación, activada en mayo de 2022 con la actualización de red NU5, y utiliza el sistema de prueba de conocimiento cero halo2 [2] para verificar transacciones. Cuando un usuario realiza una transacción blindada, actúa como el probador: construye una prueba de conocimiento cero utilizando el circuito Orchard que demuestra que la transacción es válida — posee la nota, el anulador se deriva correctamente y los montos están equilibrados — sin revelar ningún detalle privado. Los nodos de red actúan como verificadores, comprobando la prueba sin ver los datos subyacentes. El circuito Orchard define las restricciones que debe satisfacer cada prueba válida. La vulnerabilidad está en esta implementación del circuito e involucra cuatro conceptos fundamentales en Zcash: claves, direcciones, notas y anuladores.
Claves. La jerarquía de claves de Zcash es más compleja que la de la mayoría de las blockchains. Una única clave de gasto (el secreto de la billetera) deriva varias sub-claves: ask (clave secreta de autorización de gasto), nk (clave de derivación de anulador) y rivk (un aleatorizado). A partir de estas, el sistema calcula ak (clave pública de autorización) e ivk (clave de visualización entrante, mediante ivk = Commit(ak, nk, rivk)). La clave ivk se utiliza para identificar y recibir fondos entrantes.
Direcciones. Para crear una dirección Orchard, el usuario elige un diversificador d (un valor de 11 bytes), que determina un punto base diversificado g_d = DiversifyHash(d). La dirección es el par (d, pk_d), donde la clave de transmisión diversificada pk_d se calcula como una multiplicación escalar de curva elíptica: pk_d = [ivk] g_d. Esto significa que la dirección está criptográficamente vinculada a la clave de visualización del usuario.
Notas. Una Nota es un registro de activos que representa los fondos recibidos. Por privacidad, lo que se almacena en cadena no es la Nota en sí misma, sino un compromiso de Nota cm (un compromiso criptográfico con el contenido de la Nota, incluidos pk_d, el valor y otros datos). La Nota está bloqueada a la dirección del destinatario.
Anuladores. Al gastar una Nota, el gastador revela un anulador nf, calculado a partir de los datos de la Nota y la clave de anulador nk: nf = Extract_P([(F_nk(ρ) + ψ) mod p]G + cm). La propiedad de seguridad crítica es que cada Nota debe producir exactamente un anulador. Una vez que un anulador aparece en cadena, la Nota correspondiente se considera permanentemente gastada. Si la misma Nota pudiera producir diferentes anuladores, podría gastarse múltiples veces sin que nadie lo notara.
La cadena de vinculación. Estos conceptos están conectados por una cadena de vinculación criptográfica:
Los nodos resaltados en rojo (pk_d, nk) son los puntos donde la vulnerabilidad rompe la cadena de vinculación: el circuito debe aplicar pk_d = [ivk] g_d, lo que vincula al gastador con el ivk correcto y, por tanto, con el nk correcto para esa Nota. Si se rompe este vínculo, el gastador puede falsificar un ivk falso y, por tanto, usar un nk diferente para cada gasto. Diferentes valores de nk producen diferentes anuladores para la misma nota, lo que permite el doble gasto.
Cómo el circuito aplica este vínculo. La relación pk_d = [ivk] g_d es una multiplicación escalar de curva elíptica (Q = [k]P), implementada usando el algoritmo doble-y-suma. En un circuito de conocimiento cero, el verificador no ejecuta el algoritmo directamente; en cambio, el circuito restringe cada paso intermedio. Un circuito de multiplicación escalar correcto debe aplicar, entre otras cosas, que el punto base del bucle interno sea igual al punto base de entrada previsto (P_loop = P_input). Sin esta restricción, el circuito puede demostrar que se realizó una multiplicación escalar válida, pero con el punto base incorrecto, haciendo que toda la cadena de vinculación carezca de significado.
Análisis de la Vulnerabilidad
El gadget ECC vulnerable se usó en la relación de multiplicación escalar que aplica pk_d = [ivk] g_d, donde Q = pk_d, k = ivk y P = g_d. El código vulnerable se encuentra en la implementación de multiplicación escalar de base variable del repositorio halo2 (incomplete.rs L309-L310):
// incomplete.rs (fuente completa vinculada arriba)
298 for (row, k) in bits.iter().enumerate() {
299 // z_{i} = 2 * z_{i+1} + k_i
...
305 z = region.assign_advice(|| "z", self.z, row + offset, || z_val)?;
306 zs.push(Z(z.clone()));
307
308 // Asignar `x_p`, `y_p`
309 region.assign_advice(|| "x_p", self.double_and_add.x_p, row + offset, || x_p)?; // BUG
310 region.assign_advice(|| "y_p", self.y_p, row + offset, || y_p)?; // BUG
311
312 // Si el bit está activado, usar `y`; si no está activado, usar `-y`
313 let y_p = y_p
314 .zip(k.as_ref())
315 .map(|(y_p, k)| if !k { -y_p } else { y_p });
316
317 // Calcular y asignar lambda1
318 let lambda1 = y_a.zip(y_p).zip(x_a.value()).zip(x_p)
.map(|(((y_a, y_p), x_a), x_p)| (y_a - y_p) * (x_a - x_p).invert());
...
}En un circuito de conocimiento cero, el probador rellena cada valor de celda; el circuito en sí no puede copiar ni transferir valores entre celdas — solo puede definir restricciones que el verificador comprueba. Las dos líneas marcadas como BUG usan assign_advice() para escribir las coordenadas del punto base x_p e y_p (las entradas privadas del circuito conocidas como valores testigo) en las columnas de consejo del circuito (la región de entrada privada del probador). Esta función rellena un valor sin crear una restricción que lo vincule al punto base externo. Una restricción separada sí garantiza que los valores base sean iguales en todas las iteraciones del bucle — el probador no puede usar un punto base diferente en cada iteración. Sin embargo, el probador puede sustituir un único punto base arbitrario en todas las iteraciones, y nada en el circuito lo rechazará, porque ninguna restricción ancla los valores base del bucle al g_d real pasado desde el exterior.
La función correcta es copy_advice(), que rellena el valor y añade una restricción de igualdad (una restricción de copia) que impone que coincida con el punto base real g_d. Dado que g_d varía por dirección (derivado del diversificador de cada dirección), el circuito no puede codificarlo de forma fija — debe restringir el punto base del bucle para que coincida con el g_d calculado en la parte superior.
Como resultado, el circuito en realidad no aplicaba pk_d = [ivk] g_d. Un probador malicioso podría suministrar un punto base arbitrario dentro del bucle (en lugar del g_d correcto), y el circuito seguiría aceptando la prueba: el cálculo interno seguía siendo algebraicamente autoconsistente, pero ya no estaba anclado al punto base diversificado especificado por el protocolo. Este grado de libertad adicional permite al probador elegir un nk diferente cada vez, calcular el ivk = Commit(ak, nk, rivk) correspondiente y usar la multiplicación escalar sin restricciones para hacer que el ivk falsificado pase la verificación. Dado que el anulador depende de nk, cada gasto produce un anulador distinto:
misma nota N + nk_1 → nf_1
misma nota N + nk_2 → nf_2
donde: nf_1 ≠ nf_2El consenso solo verifica si un anulador ya ha aparecido en cadena. Dado que cada gasto produce un anulador único de apariencia válida, el doble gasto es invisible para la red.
La corrección [3] añade una llamada a copy_advice() en la primera iteración del bucle (row == 0), creando una restricción de copia que ancla el punto base del bucle al base real pasado desde el exterior. Las iteraciones restantes continúan usando assign_advice(), pero la restricción de consistencia entre iteraciones existente propaga el ancla a todas ellas.
Impacto y Respuesta
Escenario de explotación. Un probador malicioso podría explotar la vulnerabilidad para gastar la misma nota Orchard múltiples veces, generando cada vez un anulador diferente. Dado que la prueba de conocimiento cero oculta las entradas privadas del circuito, los anuladores fraudulentos son indistinguibles de los legítimos. El ataque no deja evidencia criptográfica definitiva en cadena, lo que hace imposible determinar de manera concluyente si alguna vez fue explotado.
La vulnerabilidad existía desde la activación de Orchard en mayo de 2022 (actualización NU5), dando una ventana de exposición total de más de cuatro años. La contabilidad de torniquete de Zcash limita la cantidad de valor falsificado que puede salir del pool Orchard hacia pools transparentes o Sapling, acotando el impacto real sobre el suministro más amplio. Sin embargo, las notas falsificadas podrían existir sin ser detectadas dentro del pool blindado, y sus propiedades de privacidad hacen imposible demostrar criptográficamente si la vulnerabilidad fue alguna vez explotada.
Nota: el torniquete solo se activa cuando los flujos de salida totales superan los flujos de entrada totales de un pool. Un atacante podría retirar valor falsificado en pequeñas cantidades a lo largo del tiempo sin alcanzar este límite. La discrepancia solo se haría evidente si los usuarios legítimos colectivamente intentaran retirar más de lo que el pool realmente contiene.
Descubrimiento y respuesta. La vulnerabilidad fue descubierta el 29 de mayo de 2026 por el investigador de seguridad Taylor Hornby (contratado por Shielded Labs), utilizando un framework de auditoría asistida por IA con el modelo Opus 4.8 de Anthropic lanzado el día anterior. Auditorías previas del mismo circuito con modelos más antiguos no habían encontrado el bug. Hornby reportó el problema a ZODL el mismo día. Una bifurcación suave de emergencia el 2 de junio (UTC) deshabilitó temporalmente las transacciones Orchard, y la actualización de red NU6.2 el 3 de junio (UTC, bloque 3.364.600) introdujo un circuito corregido, restaurando la funcionalidad de Orchard [1]. Tras la divulgación pública el 4 de junio, ZEC perdió más del 40% de su valor, con liquidaciones superiores a 100 millones de dólares [4].
Conclusión
La vulnerabilidad de Zcash Orchard fue causada por una restricción de igualdad faltante en el circuito de multiplicación escalar, lo que permitía al probador eludir el vínculo del punto base y falsificar anuladores para realizar doble gasto. A diferencia de los bugs tradicionales de contratos inteligentes que a menudo pueden detectarse mediante revisión de código o pruebas, un bug de solidez en un circuito ZK requiere comprender la brecha entre lo que el circuito realmente prueba y lo que debería probar — una sutileza que eludió más de cuatro años de auditorías profesionales por criptógrafos expertos.
La biblioteca halo2 se usa en todo el ecosistema ZKP, y relaciones similares insuficientemente restringidas podrían existir en otros proyectos construidos sobre estos bloques de construcción criptográficos. Los protocolos que usan pruebas de conocimiento cero deberían implementar verificaciones de integridad de saldo (como la contabilidad de torniquete) para acotar el impacto potencial de bugs de solidez no descubiertos: sin el mecanismo de torniquete de Zcash, el valor falsificado creado dentro del pool blindado podría haber fluido libremente hacia el suministro más amplio. Shielded Labs ha anunciado planes para verificar formalmente el circuito Orchard de manera matemática.
El descubrimiento es un ejemplo típico de un flujo de trabajo humano en el bucle: un investigador de seguridad experimentado construyó el framework de auditoría y dirigió la investigación, mientras que la IA manejó la amplitud de la verificación de restricciones individuales del circuito. Ninguno de los componentes por sí solo fue suficiente: ejecuciones previas solo con IA con modelos más antiguos no encontraron el bug, y años de revisión humana experta tampoco lo encontraron. Hornby es él mismo un experto en seguridad de Zcash — se necesitaba experiencia en el dominio para diseñar el alcance de auditoría adecuado para que la IA operara dentro de él. Como también ha mostrado la investigación reciente publicada por BlockSec [5], los modelos de IA están progresando rápidamente en el análisis de seguridad, pero aún se necesita orientación experta para dirigir la IA hacia los objetivos correctos y validar lo que encuentra. La colaboración interactiva entre expertos e IA — en lugar de depender únicamente de la IA — es el modelo de trabajo más efectivo.
Referencias
- La vulnerabilidad de falsificación de Orchard y los próximos pasos, Foro de la Comunidad Zcash, 4 de junio de 2026. Enlace
- halo2: Un sistema de prueba de conocimiento cero, GitHub. Enlace
- Corrección: anclar el punto base de multiplicación escalar mediante restricción de copia, halo2 GitHub. Enlace
- Por qué ZEC cayó un 40% incluso después de que Zcash parcheara un bug del pool blindado, CoinTelegraph, 5 de junio de 2026. Enlace
- Re-Evaluando EVMBench: ¿Están los Agentes de IA Listos para la Seguridad de Contratos Inteligentes?, arXiv, 2026. Enlace
Acerca de BlockSec
BlockSec es un proveedor integral de seguridad blockchain y cumplimiento cripto. Construimos productos y servicios que ayudan a los clientes a realizar auditorías de código (incluyendo contratos inteligentes, blockchain y billeteras), interceptar ataques en tiempo real, analizar incidentes, rastrear fondos ilícitos y cumplir con las obligaciones AML/CFT, a lo largo de todo el ciclo de vida de los protocolos y plataformas.
BlockSec ha publicado múltiples artículos de seguridad blockchain en conferencias de prestigio, ha reportado varios ataques de día cero en aplicaciones DeFi, ha bloqueado múltiples hackeos para rescatar más de 20 millones de dólares y ha asegurado miles de millones en criptomonedas.
-
Sitio web oficial: https://blocksec.com/
-
Cuenta oficial de Twitter: https://twitter.com/BlockSecTeam
