La actualización Zcash Ironwood se activa el 28 de julio para corregir una vulnerabilidad en el pool Orchard

Zcash ha fijado la fecha de activación para su actualización Ironwood, designada formalmente como NU6.3, que se implementará el 28 de julio en la altura de bloque 3.428.143, con una expectativa de alrededor de las 8 a.m. EST, según el desarrollador principal Sean Bowe. La actualización aborda directamente una vulnerabilidad crítica descubierta en el pool shielded de Orchard—la principal capa de transacciones de privacidad de Zcash—que teóricamente permitía la creación ilimitada de ZEC falsificados. Los desarrolladores no hallaron evidencias de que el fallo se hubiera explotado antes de que se desplegaran parches de emergencia y se activara el hard fork NU6.2 el 3 de junio. La actualización Ironwood introduce un checkpoint contable que exige que todos los fondos que salen de Orchard pasen por una verificación, diseñada para detectar cualquier moneda falsificada hipotética creada a través del bug anterior. La divulgación de la vulnerabilidad provocó una caída aproximada del 50% en el precio de ZEC, de $602,68 a $299,25 el 3 de junio, con una recuperación parcial a $492,61 tras la respuesta transparente de la red y el plan de remediación técnica.

La actualización Ironwood de Zcash se activa el 28 de julio en el bloque 3.428.143

Sean Bowe confirmó los parámetros finales de activación en un comunicado público: “Todas las organizaciones principales están comprometidas con la activación de NU6.3 en la altura 3428143, que es aproximadamente el 28 de julio a las 8AM EST”. El anuncio resolvió semanas de incertidumbre sobre el calendario de la actualización.

La fecha del 28 de julio representa un retraso de una semana frente al lanzamiento originalmente planificado para el 21 de julio. Shielded Labs planteó preocupaciones de que los exchanges, los pools de minería y los proveedores de carteras estaban migrando simultáneamente desde el software heredado zcashd al nuevo stack Z3—a bundle que incluye Zebra, Zaino y Zallet. La organización señaló que ejecutar dos transiciones importantes de manera concurrente creó ventanas de preparación ajustadas. A pesar de las conversaciones sobre extender el retraso aún más, la confirmación de Bowe estableció el 28 de julio como la fecha final de activación.

Vulnerabilidad en el pool Orchard descubierta y parcheada antes de la divulgación pública

La actualización Ironwood se concibió como una respuesta directa a lo que los desarrolladores denominaron un “bug de la infinidad” descubierto dentro del pool shielded de Orchard. El fallo, en teoría, permitía a un actor malicioso acuñar ZEC falsificados ilimitados sin ser detectado dentro del entorno shielded.

Shielded Labs divulgó el problema y afirmó que no se encontró evidencia de que la vulnerabilidad hubiera sido explotada. Antes de que el bug se convirtiera en conocimiento público, se desplegaron actualizaciones de software de emergencia. Los desarrolladores deshabilitaron primero por completo las transacciones de Orchard mediante un parche temporal de la red, y luego activaron el hard fork NU6.2 el 3 de junio para corregir el código subyacente y restaurar la funcionalidad del pool.

El calendario de divulgación y remediación dejó una incertidumbre residual: incluso sin pruebas de explotación, la posibilidad teórica de que existieran monedas falsificadas dentro de Orchard exigía un mecanismo de verificación que fuese más allá de la corrección de código por sí sola.

El checkpoint contable filtra los fondos que salen del pool Orchard

El núcleo técnico de la actualización Ironwood es un checkpoint contable integrado en el proceso de migración de fondos. Bajo el nuevo protocolo, cualquier ZEC que salga del pool Orchard debe pasar por ese checkpoint antes de entrar en el nuevo pool privado que Ironwood establece. El checkpoint está diseñado para exponer discrepancias—si se hubiera creado ZEC falsificado, moverla activaría la detección.

El diseño crea un resultado asimétrico para cualquier falsificador hipotético: intentar migrar monedas falsas y arriesgarse a exponerse, o dejarlas permanentemente varadas en un pool que ya no aceptará nuevas actividades. El proceso de migración en sí funciona como una auditoría distribuida, con cada usuario que mueve fondos participando en la verificación.

El precio de ZEC cayó 50% tras la divulgación de la vulnerabilidad y se recuperó a $492,61

La divulgación de la vulnerabilidad desencadenó una fuerte reacción del mercado. Cuando el bug de Orchard se hizo público el 3 de junio—el mismo día que el hard fork NU6.2—ZEC cayó aproximadamente un 50%, deslizándose de $602,68 a $299,25.

Desde entonces, el token se ha recuperado parcialmente, cotizando de nuevo hasta $492,61. La recuperación parcial refleja la respuesta del mercado a la divulgación rápida de la red, la comunicación transparente y el plan de remediación técnica concreto.

El suministro circulante de Zcash supera el 80% de los 21 millones máximos

Zcash superó un umbral de suministro esta semana, ajeno a la actualización de seguridad. Según una publicación de la cuenta de la comunidad ruZCASH el 6 de julio, el suministro circulante alcanzó 16.806.723 ZEC—más del 80% del suministro máximo de 21 millones de la criptomoneda. La cuenta señaló que podrían haber sido los primeros en señalar el hito públicamente.

El momento coincide con la actualización Ironwood, que aborda el incidente de seguridad más significativo de la red hasta la fecha.

Preguntas frecuentes

¿Cuándo está programada la activación de la actualización Ironwood para Zcash?

La actualización Ironwood está programada para activarse el 28 de julio en la altura de bloque 3.428.143, con una expectativa de alrededor de las 8 a.m. EST, según la confirmación del desarrollador principal Sean Bowe.

¿Cuál es el propósito de la actualización Ironwood?

La actualización Ironwood reemplaza el pool shielded de Orchard para abordar una vulnerabilidad que, en teoría, permitió la creación ilimitada de ZEC falsificados. Introduce un checkpoint contable que cualquier fondo que salga de Orchard debe atravesar, diseñado para detectar si se creó algún ZEC falso mediante el bug anterior. Los desarrolladores no encontraron evidencias de que el fallo se hubiera explotado antes de la corrección.