La Fondation Zcash a publié Zebra 7.0.0 avec le support du réseau principal NU7, demandant aux opérateurs de nœuds de mettre à niveau avant le bloc 3 543 405, prévu vers le 5 novembre.
Résumé
- Les opérateurs du réseau principal doivent mettre à niveau avant l'activation pour rester sur la chaîne de consensus.
- Les versions Zebra 6.4.x devraient cesser de fonctionner quelques jours avant la mise à niveau.
- NU7 introduit des blocs de 25 secondes tout en préservant l'émission quotidienne programmée de ZEC.
- La fondation indique que Zebra 7.0.0 inclut des correctifs pour cinq avis de sécurité.
La Fondation Zcash a déclaré dans son annonce du 22 octobre que les opérateurs du réseau principal doivent installer la mise à niveau pour rester sur la chaîne de consensus, tandis que les anciennes versions 6.4.x s'arrêteront d'elles-mêmes quelques jours avant l'activation.
« Tous les opérateurs du réseau principal DOIVENT mettre à niveau avant la hauteur 3 543 405 (~5 nov.) pour rester sur la chaîne de consensus. »
La fondation a cité parmi les fonctionnalités de cette version des blocs de 25 secondes, un mécanisme de durabilité du réseau et des correctifs pour cinq avis de sécurité.
Les opérateurs de Zebra confrontés à un arrêt plus précoce
La mise à jour technique de la fondation du 6 octobre situait l'arrêt attendu de Zebra 6.4.x autour du 2 novembre. Les développeurs ont raccourci la période de fonctionnement du logiciel de 15 semaines à 12 semaines afin d'anticiper cet arrêt avant la mise à niveau du réseau prévue.
Dans la même mise à jour, l'équipe d'ingénierie a indiqué que les calculs d'expiration et les estimations de synchronisation avaient été ajustés pour suivre le temps de bloc en vigueur à chaque hauteur. Sans cet ajustement, une production de blocs plus rapide pourrait faire arrêter le logiciel plus tôt que prévu.
NU7 a atteint le réseau de test public au bloc 4 465 026 le 4 octobre, a confirmé la fondation. L'activation sur le réseau de test a introduit les changements de consensus pour observation avant le déploiement sur le réseau principal.
Comme crypto.news l'avait précédemment rapporté le 21 octobre, les développeurs avaient sélectionné la hauteur d'activation sur le réseau principal après une réunion des éditeurs ZIP le 20 octobre. À la date limite de ce reportage, le changement attendait encore son intégration dans la spécification de déploiement.
Le texte actuel du ZIP 259 liste désormais le bloc 3 543 405 du réseau principal. Ses règles de compatibilité indiquent que les nœuds mis à niveau déconnecteront les pairs annonçant une version antérieure du protocole réseau après l'activation.
La spécification avertit que les logiciels non pris en charge peuvent rester en ligne et suivre une branche de consensus antérieure à NU7. Elle n'établit pas combien d'opérateurs utilisent encore un logiciel incompatible.
Zcash vise des confirmations plus rapides sans émission plus rapide
Le ZIP 218 fixe le nouvel objectif de bloc à 25 secondes, contre 75 secondes auparavant. Ses auteurs identifient les paiements, les dépôts sur les plateformes d'échange et les opérations inter-chaînes comme des usages affectés par l'attente des confirmations.
La proposition ne conseille pas aux clients de réduire leur nombre de confirmations. Sa discussion du risque de rollback distingue entre les modèles de sécurité, notamment les modèles fondés sur la part de puissance de minage d'un attaquant et ceux fondés sur le coût économique de l'inversion d'un paiement.
L'explication de la version candidate de la fondation du 2 octobre indique que l'émission quotidienne programmée reste inchangée car le logiciel divise les récompenses de bloc programmées par trois et ajuste les intervalles de halving restants.
Sa description conserve le calendrier de halving de quatre ans et le plafond d'approvisionnement de 21 millions de ZEC. Une production de blocs plus rapide ne signifie donc pas que la subvention minière quotidienne programmée triple.
Le sondage des détenteurs de pièces de septembre a enregistré environ 99,9 % de soutien pour un espacement plus court des blocs et 98,9 % de soutien pour la préservation des halvings. Près de 2,4 millions de ZEC ont participé, représentant environ 66 % des soldes éligibles d'Ironwood au moment de l'instantané, selon les résultats publiés couverts le 16 septembre.
Le vote s'est clos le 14 septembre après l'enregistrement des soldes au bloc 3 459 350 du réseau principal le 24 août. L'éligibilité dépendait des fonds blindés dépensables détenus dans Ironwood à cet instantané.
NU7 redirige les frais vers de futures récompenses de minage
L’explication de la version candidate de la fondation décrit une répartition dans laquelle 60 % des frais de transaction quittent la circulation pour une réserve, tandis que les mineurs conservent les 40 % restants.
Dans le cadre du Network Sustainability Mechanism, les fonds réservés peuvent revenir progressivement via de futures récompenses de bloc. La couverture de l’activation du 21 octobre a identifié le bloc 8 939 664 du réseau principal comme point de départ de la réémission, attendue vers février 2031.
Les détenteurs de coins avaient favorisé ce calendrier avec environ 96,6 % de soutien lors du sondage de septembre. La spécification de déploiement liste la hauteur de réémission séparément de la hauteur d’activation de NU7.
L’explication technique du 2 octobre donne aux pools de minage une instruction associée. Étant donné qu’une transaction coinbase dépend des frais de transaction sélectionnés et de la réserve du bloc parent, les mineurs devraient demander un nouveau modèle de bloc au lieu de modifier eux-mêmes son ensemble de transactions ou son bloc précédent.
La fondation a décrit des limites d’activité shielded couvrant les pools individuels et un budget partagé entre les pools. Sa mise à jour d’ingénierie indique que ces restrictions sont conçues pour protéger les light wallets contre le spam tandis que le réseau produit des blocs plus fréquemment.
ZIP 218 fixe le budget shielded partagé à 330 actions par bloc, aux côtés de limites distinctes par pool. Ses auteurs estiment que les changements réduisent la bande passante de synchronisation quotidienne des light wallets dans le pire des cas de 271 mégaoctets à 169 mégaoctets, soit une réduction d’environ 37 %.
La proposition note un compromis distinct en matière de confidentialité. Des blocs plus fréquents donnent aux observateurs des informations temporelles plus fines, qui peuvent être combinées avec des observations provenant de réseaux ou d’applications. Ses auteurs affirment que les nouvelles limites n’empêchent pas l’analyse de trafic ni n’éliminent le risque de déni de service.
Les fonds Sprout font face à une échéance de dépense distincte
La couverture du testnet du 5 octobre a décrit un autre changement de NU7 affectant les fonds dans Sprout, le pool shielded original de Zcash. La désactivation des transactions de version 4 empêche de dépenser ces fonds après l’activation, sauf si les détenteurs les déplacent au préalable.
ZIP 259 spécifie que l’interdiction s’applique à chaque transaction de version 4, y compris les transactions transparent-only et Sapling. Les transactions enregistrées signées hors ligne nécessitent les mêmes vérifications d’activation.
La spécification indique que les versions 5 et 6 conservent leurs structures existantes, mais que leurs signatures s’engagent sur un identifiant de branche de consensus. Un format de transaction inchangé ne garantit pas qu’une transaction reste valide à travers l’activation.
