Puntos Clave de la Noticia:
- La versión Zebra 7.0.0 incorpora parches para siete vulnerabilidades: cinco clasificadas como de alta severidad y dos de severidad media.
- La actualización de red NU7 está programada para activarse en el bloque de mainnet 3.543.405, previsto alrededor del 5 de noviembre de 2026.
- La especificación técnica ZIP 218 reduce el tiempo objetivo por bloque de 75 a 25 segundos sin alterar la emisión diaria total de ZEC ni el tope de 21 millones de monedas.
La Zcash Foundation publicó un informe de ingeniería este 3 de noviembre en el que detalló siete correcciones de seguridad en Zebra mediante el lanzamiento de su versión 7.0.0, preparando el terreno técnico para la activación de la actualización de red NU7 en la mainnet.
Según los datos de la organización, los operadores de nodos completos deben actualizar su software antes del bloque 3.543.405 para permanecer alineados con la cadena de consenso de la red.
El reporte técnico explica que seis de los fallos identificados permitían que un nodo par malicioso detuviera la sincronización, monopolizara recursos de verificación o provocara el baneo erróneo de pares honestos. El séptimo vector de riesgo podía forzar el cierre inesperado de zebrad, el proceso principal que ejecuta el cliente en los servidores.
En la categorización interna presentada por los desarrolladores, cinco advertencias recibieron la calificación de alta severidad y dos quedaron registradas como de severidad media. Entre las fallas graves figuran dos errores de sincronización en puntos de control (checkpoints), sanciones insuficientes para scripts transparentes inválidos, cálculos de firmas computacionalmente costosos y una verificación de transacciones capaz de saturar hilos del procesador.
Respecto a los problemas de severidad media, el informe señala que uno de ellos causaba la detención de Zebra al desconectar a un par ocupado, mientras que el segundo provocaba la expulsión de nodos legítimos al retransmitir transacciones cuya condición de tiempo de bloqueo (lock-time) sería válida en el bloque inmediatamente posterior.
Una de las advertencias técnicas vinculadas a los puntos de control puntualizó que un par no autenticado podía suministrar el cuerpo de un bloque falso. Dicha acción dejaba al nodo en proceso de sincronización imposibilitado de continuar hasta que se reiniciara el sistema, debido a que el software marcaba de forma errónea los bloques faltantes como ya descargados.
La Zcash Foundation remarcó en su reporte que el impacto de esta vulnerabilidad se limitó estrictamente a la disponibilidad operativa: ningún bloque inválido llegó a escribirse en el disco, no se generó una bifurcación de la cadena y los fondos de los usuarios se mantuvieron intactos. Los nodos que ya se encontraban completamente sincronizados quedaron fuera del grupo afectado.
Modificaciones de base de datos y parámetros técnicos de NU7
La implementación de Zebra 7.0.0 acarrea además cambios estructurales en el almacenamiento local. Los desarrolladores indicaron en las notas de la versión en GitHub que el estado del nodo migra del formato v28 al v29 durante el primer arranque, sin exigir una descarga completa desde el bloque génesis.
Dado que la versión Zebra 6.x no cuenta con compatibilidad para leer el formato v29, el equipo de ingeniería recomendó realizar un respaldo del directorio state/v28 antes de proceder con la actualización, advirtiendo que volver a una versión previa demandaría una resincronización total.
Asimismo, las métricas de red sufrieron modificaciones funcionales. Los paneles de monitoreo basados en etiquetas individuales de dirección IP y agentes de usuario dejaron de recibir esos identificadores, lo que exige ajustes de configuración en los sistemas de telemetría de los operadores. A su vez, la fundación estableció que esta versión 7.0.0 dispondrá de un período de soporte de ocho semanas, a diferencia del ciclo habitual de doce.
En el plano del protocolo, la propuesta de mejora ZIP 218 contempla reducir el intervalo promedio entre bloques de 75 a 25 segundos. De acuerdo con las especificaciones del diseño, esta aceleración busca agilizar la confirmación de pagos cotidianos, depósitos en exchanges y operaciones entre cadenas.
Para evitar presiones inflacionarias sobre el suministro, la recompensa emitida por cada bloque minado se reduce de forma proporcional. La documentación subraya que la emisión diaria calculada de ZEC se mantiene invariable, conservando el esquema de halving de cuatro años y el límite máximo de emisión fijado en 21 millones de unidades.
NU7 también integra una reserva de tarifas: el 60% de las comisiones de transacción queda apartado fuera de circulación para recompensas de minería posteriores, mientras que el 40% restante es percibido directamente por los mineros.
En respuesta a observaciones planteadas por mineros durante la conferencia Zcon7 en Cancún relativas a demoras en la construcción y propagación de bloques, la fundación liberó de manera paralela la versión Zebra Ándale (7.1.0-alpha.0) el pasado 31 de octubre. Según pruebas reportadas por los desarrolladores en ese entorno alpha, la creación de plantillas tras ráfagas intensas de transacciones se redujo de más de ocho minutos a cerca de cuatro segundos.
Los operadores de seeders recibieron la instrucción de desplegar la versión complementaria Zeeder v1.8.0 antes de la llegada del bloque de activación 3,543,405 en la mainnet, fijado en el calendario para este 5 de noviembre.
