Zcash detalla siete correcciones de seguridad de Zebra antes de la actualización NU7

La Fundación Zcash ha delineado siete correcciones de seguridad en Zebra 7.0.0 mientras los operadores de nodos se preparan para la actualización de la mainnet NU7, que sigue programada para alrededor del 5 de noviembre.

Resumen

• Zebra 7.0.0 admite la activación de NU7 en el bloque 3,543,405 de la mainnet y aborda siete problemas de seguridad.
• Los operadores deben actualizar antes de la activación para permanecer en la cadena de consenso de la red.
• Una versión alfa separada aborda los retrasos en la minería reportados durante la conferencia Zcon7 en Cancún.
• Zeeder v1.8.0 agrega soporte para NU7, con instrucciones para que los operadores de seeder lo implementen antes de la activación.

La actualización de ingeniería de la Fundación Zcash, publicada el 3 de noviembre y que abarca del 20 de octubre al 2 de noviembre, reúne los preparativos restantes para NU7. Zebra 7.0.0 fue lanzado el 22 de octubre, haciendo que el último anuncio sea un informe de progreso antes de la activación.

La fundación describió seis de los problemas de seguridad como formas en que un par podría detener la sincronización, ocupar recursos de verificación o causar que pares honestos sean prohibidos. El séptimo podría hacer que zebrad, el proceso de software que ejecuta un nodo Zebra, se bloquee.

Las correcciones de Zebra incluyen cinco problemas de alta gravedad

El anuncio de lanzamiento de la fundación clasifica cinco avisos como de alta gravedad y dos como de gravedad media. Los problemas de alta gravedad cubren dos fallos de sincronización de puntos de control, sanciones inadecuadas para scripts transparentes inválidos, cálculos de firma costosos y una verificación de transacción que podría ocupar hilos de verificación.

Un defecto de gravedad media podría detener Zebra cuando desconectara a un par ocupado. El otro podría hacer que un nodo prohibiera a un par honesto por retransmitir una transacción cuya condición de tiempo de bloqueo se volvería válida en el siguiente bloque.

Un aviso de punto de control explica que un par no autenticado podría suministrar un cuerpo de bloque falsificado y dejar a un nodo en sincronización incapaz de avanzar hasta reiniciarse. El nodo trató incorrectamente los bloques faltantes como ya descargados, impidiendo que solicitara copias válidas.

El aviso limita el impacto a la disponibilidad: ningún bloque inválido llegó al disco, no ocurrió bifurcación de cadena y los fondos no se vieron afectados. Los nodos ya sincronizados estaban fuera del grupo afectado.

Una vulnerabilidad relacionada podría dejar al verificador de puntos de control fuera de sincronización con el estado almacenado después de un compromiso fallido. Su aviso dice que reiniciar restauró el progreso, pero un nodo afectado podría quedar estancado nuevamente durante una sincronización posterior.

NU7 requiere que los operadores actualicen antes de la activación

La fundación dice que los operadores de la mainnet deben actualizar antes del bloque 3,543,405. Una vez que NU7 se active, los nodos actualizados desconectarán a los pares que ejecutan versiones anteriores, mientras que los nodos incompatibles pueden seguir una cadena diferente.

Como informó anteriormente crypto.news, la fecha límite de actualización de la mainnet se aplica a los operadores que buscan permanecer en la cadena de consenso.

La instalación conlleva un cambio en la base de datos. Según las notas de lanzamiento de GitHub, Zebra mueve su estado almacenado del formato v28 al v29 en el primer inicio sin requerir una nueva sincronización.

Zebra 6.x no puede leer el nuevo formato. Por lo tanto, los operadores que regresen a una versión anterior necesitarían una resincronización completa, y los desarrolladores aconsejan hacer una copia de seguridad del directorio state/v28 antes de actualizar.

Los sistemas de monitoreo también necesitan atención. Las métricas de pares ya no incluyen etiquetas de dirección individual y agente de usuario, por lo que los paneles y alertas construidos alrededor de esos campos requieren cambios. Zebra 7.0.0 tiene un período de soporte de ocho semanas, en comparación con las 12 semanas habituales.

Zcash apunta a bloques de 25 segundos sin emisión diaria más rápida

Bajo ZIP 218, NU7 reduce el espacio objetivo entre bloques de 75 segundos a 25 segundos. La especificación identifica pagos, depósitos de intercambio y operaciones entre cadenas entre las actividades afectadas por las esperas de confirmación.

La emisión programada de ZEC por día permanece sin cambios porque la recompensa por bloque se ajusta para el horario más rápido. La propuesta no recomienda que los clientes reduzcan los recuentos de confirmación.

La explicación del lanzamiento de la fundación preserva el cronograma de reducción a la mitad de cuatro años y el límite de suministro de 21 millones de ZEC. NU7 introduce una reserva de tarifas, con el 60% de las tarifas de transacción retiradas de circulación para futuras recompensas y el 40% retenido por los mineros.

La retroalimentación de los mineros produce un lanzamiento alfa separado

Tras las quejas en Zcon7 sobre la lenta creación de plantillas, aceptación de bloques y retransmisión, la fundación publicó Zebra Ándale, versión 7.1.0-alpha.0, el 31 de octubre.

La alfa reemplaza los retrasos de sondeo con respuestas a transacciones verificadas y cambios en el mempool. En el benchmark de la fundación, un gran estallido de transacciones que anteriormente tardaba más de ocho minutos en alcanzar una plantilla de minería tomó aproximadamente cuatro segundos. Las cifras son resultados reportados por los desarrolladores de la versión alfa.

La actualización de ingeniería dice que Zeeder v1.8.0 publicita la versión del protocolo NU7 para que los nodos actualizados continúen aceptándola después de la activación. Se instruye a los operadores de seeder a implementar la versión antes. El equipo está revisando la poda opcional de bloques para ahorrar espacio en disco, mientras mantiene el almacenamiento de cadena completa como predeterminado.