Zcash lanza nodo Zakura antes de la actualización Ironwood
El nuevo cliente se sincroniza rápidamente a partir de instantáneas de 11 GB y soporta el NU6.3 'torniquete' destinado a contener el riesgo potencial de ZEC falsificado.
Los desarrolladores del ecosistema Zcash lanzaron Zakura v1.0.0, un nuevo nodo completo diseñado para reducir el tiempo de sincronización y facilitar las migraciones, ya que el cliente legado zcashd llegó al final de su vida útil el 18 de julio.
El lanzamiento se produce días antes de la actualización Ironwood (NU6.3) del 28 de julio, que añade un 'torniquete' a nivel de protocolo para limitar los retiros de la piscina protegida Orchard después de descubrirse un error de solidez.
Puntos Clave
- Zakura v1.0.0 está en funcionamiento como un nuevo nodo completo de Zcash mantenido de forma independiente de la Fundación Zcash por Sean Bowe y Dev Ojha, financiado por donaciones privadas de ZEC.
- El software es un fork podado y de sincronización rápida de Zebra y envía un modo de compatibilidad con zcashd ya que zcashd llegó al final de su vida útil el 18 de julio.
- Los operadores pueden iniciar desde instantáneas de cadena podadas de aproximadamente 11 GB, con el equipo afirmando que un nodo nuevo puede estar funcionando en menos de dos minutos, '680 veces más rápido'.
- Ironwood (NU6.3) está programado para el 28 de julio en el bloque 3,428,143 (~8 a.m. ET) e introduce un 'torniquete' Orchard para contener posibles ZEC falsificados vinculados a un error de solidez de Orchard.
Zakura v1.0.0 llega mientras zcashd alcanza el final de su vida útil
La pila de infraestructura de Zcash se está viendo forzada a través de una ventana de transición de cliente. Zakura v1.0.0 se lanzó como una nueva implementación de nodo completo al mismo tiempo que zcashd, el cliente original de Zcash, llegó al final de su vida útil el 18 de julio.
Operativamente, ese momento importa más que el marketing de rendimiento. Los nodos completos hacen cumplir las reglas de consenso, y los intercambios, billeteras y creadores de mercado necesitan un comportamiento de nodo predecible alrededor de las ventanas de actualización.
Zakura está posicionada como un camino de integración para equipos que históricamente se integraron con zcashd, con un modo de compatibilidad diseñado para reproducir la interfaz de zcashd para que las integraciones existentes puedan seguir funcionando sin reescrituras.
Zakura es mantenido de forma independiente de la Fundación Zcash por Sean Bowe y Dev Ojha, y está financiado por donaciones privadas de ZEC en lugar de por una empresa o fundación. Esa independencia tiene sus pros y sus contras para los operadores: puede acelerar la iteración, pero también transfiere la debida diligencia a los integradores que necesitan estar cómodos ejecutando un nuevo cliente de producción.
Sincronización Rápida por Instantánea: Lo que Zakura Cambia para las Operaciones de Nodo
Zakura es un fork de Zebra, lo que significa que comenzó a partir de la base de código del nodo de la Fundación y fue reconstruido a partir de ahí. El cambio operativo clave es su modelo de sincronización rápida impulsado por instantáneas, habilitado por el pruning.
El pruning elimina datos antiguos de la blockchain que un nodo ya no necesita para validar la cadena actual. Con los datos antiguos eliminados, el equipo distribuye instantáneas de la cadena podada listas de aproximadamente 11 GB.
Un nuevo nodo puede descargar la instantánea en lugar de sincronizar la cadena completa bloque por bloque desde el génesis, y el equipo afirma que eso lleva a un nodo de cero a funcionando en menos de dos minutos, "680 veces más rápido."
Si ese flujo de trabajo se mantiene bajo condiciones del mundo real, reduce el costo de establecer nodos redundantes y rotar infraestructura. Eso es más importante cuando el tiempo de actividad es innegociable, como en ventanas de hard fork donde los intercambios y billeteras quieren caminos de recuperación rápidos si un nodo falla o un despliegue necesita ser revertido.
Zakura también incluye un sistema experimental de propagación rápida de bloques destinado a entregar cada bloque a cada nodo en menos de medio segundo. Está desactivado por defecto.
Ironwood el 28 de julio: El Parche de Integridad del Suministro de Torniquete
El catalizador a corto plazo no es la escalabilidad teórica. Es Ironwood (NU6.3), programado para activarse el 28 de julio en el bloque 3,428,143 (aproximadamente a las 8 a.m. hora del Este). La actualización introduce un mecanismo de 'torniquete' para limitar los retiros del grupo protegido de Orchard.
Ironwood existe debido a un error de solidez del circuito de prueba de Orchard descubierto el 29 de mayo por el investigador de Shielded Labs, Taylor Hornby. El defecto había estado activo desde que Orchard se activó en mayo de 2022 y podría haber permitido a un atacante acuñar ZEC falsificado sin rastro en la cadena.
Los desarrolladores desactivaron Orchard a través de una respuesta de emergencia completada el 2 de junio, y luego lo restauraron con un circuito corregido a través del hard fork NU6.2 en el bloque 3,364,600 el 3 de junio.
El problema es la brecha entre "arreglado hacia adelante" y "demostrablemente seguro históricamente."Pruebas de conocimiento cerorevela solo que se verificó una prueba, no qué valor se movió dentro de Orchard, por lo que la cadena no puede probar que ZEC falsificado nunca fue creado durante la ventana de varios años.
El torniquete de Ironwood está diseñado para contener esa incertidumbre controlando lo que puede cruzar el límite de Orchard, utilizando el hecho de que las cantidades que entran y salen de los grupos protegidos son públicas, incluso si las transferencias internas son privadas.
Lista de verificación de Catalyst hasta el 28 de julio: Migraciones de clientes y preparación para la actualización
Los eventos umbral son claros y están muy cerca uno del otro. Primero está la realidad posterior al 18 de julio: si los principales proveedores de infraestructura migran públicamente a Zakura (u otros clientes) y si el modo de compatibilidad con zcashd funciona correctamente en producción sin fallos en casos extremos.
El segundo es el propio 28 de julio. Al mercado le importará menos el titular de activación y más las confirmaciones de los principales intercambios y billeteras de que han actualizado y reanudado las políticas normales de depósitos y retiros.
También existe el riesgo de parámetros. Cualquier actualización de los equipos centrales sobre la configuración del torniquete de Orchard y la orientación operativa para mover fondos a través del límite de Orchard después de la activación dará forma a la rapidez con la que los usuarios pueden migrar saldos con el tiempo.
Finalmente, las afirmaciones de rendimiento de Zakura necesitan validación independiente. La evaluación comparativa de terceros del flujo de instantáneas de 11 GB y la afirmación de inicio en menos de dos minutos convertiría una buena demostración en algo que los operadores pueden respaldar.
Por qué la narrativa a corto plazo de ZEC es riesgo de infraestructura, no sueños de TPS
Estoy tratando esto como una historia de infraestructura e integridad del suministro con una fecha límite, no como un avance en escalabilidad. La activación de Ironwood del 28 de julio es un catalizador concreto porque está explícitamente diseñada para contener el riesgo potencial de ZEC falsificado que no puede ser auditado en la cadena debido a cómo funcionan las pruebas de conocimiento cero.
El umbral que importa es si la migración del cliente y el despliegue del torniquete se realizan correctamente en los intercambios y billeteras. Si esa plomería se mantiene, la configuración comienza a parecer estructural en lugar de impulsada por la narrativa, porque reduce la fragilidad de la ventana de actualización y estrecha la sobrecarga de integridad del suministro en un mecanismo definido sobre el que los comerciantes pueden razonar.
