Zcash Déploie NU7 En Testnet Pour Des Blocs De 25 Secondes

Et si la prochaine confirmation d’une transaction privée n’attendait plus une minute et quart, mais à peine le temps de relire un message ? Le 4 octobre 2026, à 18 h 21 min 45 s UTC, le testnet de Zcash a franchi le bloc 4 465 026 et a basculé sous les règles du NU7. L’activation est arrivée plus tôt que la fenêtre autour du 6 octobre que les équipes avaient encore en tête quelques jours plus tôt. Le compte officiel du protocole a ensuite confirmé que la mise à niveau tournait bel et bien sur le réseau d’essai. Rien n’est encore gravé sur le réseau principal, mais le calendrier se resserre : revue des résultats le 20 octobre, activation mainnet toujours visée autour du 5 novembre.

Ce n’est pas un simple réglage cosmétique. Réduire l’intervalle cible de 75 à 25 secondes change le rythme ressenti par les portefeuilles, la charge de travail des nœuds, la manière dont les frais sont recyclés et, pour une minorité de détenteurs encore logés dans l’ancien pool Sprout, la possibilité même de dépenser leurs pièces après le passage en production. Le testnet sert précisément à observer ces effets avant qu’ils ne deviennent irréversibles.

Ce que le testnet vient réellement de changer

Le NU7 n’a pas été inventé dans la nuit du 4 octobre. Les équipes d’ingénierie s’étaient accordées en septembre sur un paquet de modifications, avec une cible de déploiement principal au 5 novembre une fois la phase d’essai terminée. La publication, le 2 octobre, de la version candidate Zebra 7.0.0-rc.0 avait déjà indiqué la direction : les opérateurs du testnet étaient invités à faire tourner le candidat et à éprouver les règles dans des conditions proches du réel. Les opérateurs du réseau principal, eux, n’avaient rien à modifier tant qu’aucune hauteur d’activation n’était arrêtée.

Le bloc d’activation a donc servi de ligne de départ. Avant lui, l’ancien rythme. Après lui, un objectif de production d’environ trois blocs là où le réseau n’en visait qu’un. La fondation avait résumé l’effet utilisateur de façon simple : l’attente moyenne d’une première confirmation passerait de 75 secondes à 25 secondes. Sur un réseau dont la promesse centrale reste la confidentialité des montants et des contreparties, cette attente n’est pas un détail de confort. Elle pèse sur les paiements, les retraits d’échanges et la sensation qu’une opération « est passée ».

Cette distinction mérite d’être répétée, parce que les fils d’actualité mélangent vite essai et production. Un portefeuille qui affiche un solde sur le réseau public n’est pas soumis, aujourd’hui, aux nouvelles limites ni à la désactivation des transactions de version 4. Le laboratoire est ouvert. L’atelier principal ne l’est pas.

Pourquoi viser 25 secondes plutôt que garder le rythme actuel

Zcash a longtemps vécu avec un intervalle cible de 75 secondes, héritage d’un compromis entre réactivité et coût de validation. Trois quarts de minute, ce n’est pas lent au regard de certaines chaînes historiques, mais c’est long dès que l’usage ressemble à un paiement ou à un arbitrage entre un solde transparent et un solde protégé. Passer à 25 secondes ne promet pas une finalité instantanée. Cela promet une première inclusion plus rapprochée, à condition que les blocs restent trouvables et que les nœuds suivent.

Le soutien des détenteurs a été massif avant même que le calendrier ne soit figé. Un sondage de gouvernance privé a mobilisé près de 2,4 millions de ZEC. Environ 99,9 % des pièces participantes ont appuyé la réduction de l’intervalle cible. La participation représentait à peu près 66 % des soldes Ironwood éligibles enregistrés pour le vote. Ce n’est pas un plébiscite de toute l’offre en circulation, et il ne faut pas le présenter comme tel. C’est en revanche un signal très net parmi les pièces qui ont pris la peine de s’exprimer dans le cadre prévu.

Produire des blocs plus souvent ne doit pas revenir à imprimer trois fois plus de pièces. Le rythme change, le calendrier d’émission est recalibré pour que la journée du mineur ne triple pas.

Principe retenu pour le NU7

Le point est décisif pour quiconque lit l’annonce trop vite. Si l’on garde la même récompense par bloc et que l’on multiplie le nombre de blocs par trois, l’émission quotidienne explose. Le NU7 refuse ce raccourci. L’ajustement de l’émission accompagne le raccourcissement de l’intervalle, de sorte que le surcroît de blocs ne se transforme pas en triplement des ZEC versés chaque jour. Le sondage allait dans le même sens sur le calendrier de halving : environ 98,9 % des pièces participantes souhaitaient conserver l’échéancier existant.

Autrement dit, le réseau cherche une latence plus basse sans réécrire l’histoire monétaire déjà promise aux détenteurs. C’est un choix politique autant que technique. Une chaîne privée qui accélérerait l’émission pour « payer » la vitesse se tirerait une balle dans la rareté. Une chaîne qui accélère les blocs sans toucher à la courbe quotidienne garde le contrat d’offre et améliore le ressenti.

Le mécanisme de soutenabilité, ou comment les frais reviennent plus tard

Le deuxième pilier porte un nom volontairement institutionnel : le Network Sustainability Mechanism, souvent réduit à NSM. L’idée est de retirer une partie de chaque frais de transaction de la circulation immédiate et de la placer dans une réserve susceptible d’alimenter de futures récompenses de bloc. La fondation a décrit le dispositif comme un recyclage d’une fraction des frais vers une émission ultérieure.

Le sondage de gouvernance a aussi cadré le moment où une réémission liée à ce mécanisme pourrait démarrer. Environ 96,6 % des pièces participantes ont soutenu février 2031 comme point de départ. Là encore, il s’agit d’une préférence exprimée avant le gel définitif du déploiement, pas d’un arrêté déjà exécuté sur le réseau principal. Le testnet permet de voir si la plomberie tient : collecte, réserve, lisibilité pour les explorateurs, absence d’effets de bord sur le mempool.

Pourquoi un tel mécanisme sur une chaîne dont l’émission est déjà programmée ? Parce que la subvention de bloc diminue avec le temps, comme sur les protocoles cousins de l’arbre Bitcoin. Le jour où cette subvention devient mince, la sécurité repose davantage sur les frais. Recycler une part de ces frais vers des récompenses futures est une tentative de lisser cette transition, plutôt que d’attendre qu’un marché de frais très volatile porte seul les mineurs ou les validateurs. Le NU7 n’éteint pas le débat sur la sécurité à long terme. Il installe un tuyau que les équipes pourront observer avant 2031.

Le détail qui intéressera les places de marché est plus prosaïque : comment un frais « partiellement retiré » apparaît-il dans les reçus, les exports comptables et les estimateurs de portefeuille ? Un mécanisme élégant sur le papier devient un ticket de support s’il est mal étiqueté. Les semaines de testnet servent aussi à cela, pas seulement à compter les blocs orphelins.

Des limites sur les actions protégées pour éviter le spam

Accélérer les blocs sans borner le travail vérifiable serait une fausse bonne idée. Les preuves des pools protégés coûtent cher à contrôler. Un bloc trop chargé peut ralentir les portefeuilles légers, faire ramer la synchronisation et ouvrir une voie de nuisance : inonder le réseau d’actions protégées jusqu’à ce que les clients honnêtes décrochent. Le NU7 introduit donc de nouvelles limites sur ces actions, présentées par la fondation comme un garde-fou contre le spam au moment où la production devient plus fréquente.

Le compromis est classique. Trop de latitude, et un bloc peut devenir un goulot. Trop de rigidité, et une transaction complexe, tout à fait légitime, se fait refuser alors que l’utilisateur n’a rien fait d’anormal. Les équipes vont chercher sur le testnet le point où la protection tient sans casser les usages regroupés, ceux qui combinent plusieurs notes, plusieurs destinataires ou un passage entre pool transparent et pool protégé.

Pour le grand public, la conséquence visible devrait rester discrète si les limites sont bien choisies : des confirmations plus rapprochées, des frais qui se comportent de façon prévisible, et des portefeuilles qui ne se figent pas lorsqu’un acteur tente de saturer la file. Pour les développeurs de clients, la conséquence est plus concrète. Il faut afficher clairement un rejet lié à la limite, proposer un découpage, et ne pas laisser l’utilisateur croire que ses fonds sont bloqués alors que seule la forme de la transaction est en cause.

Le point le plus sensible : Sprout et la fin des transactions de version 4

C’est le passage que les détenteurs anciens doivent lire deux fois. Une fois le NU7 appliqué au réseau principal, les transactions de version 4 seraient désactivées. Or dépenser depuis le pool protégé historique Sprout repose précisément sur ce format. Les fonds qui y resteraient deviendraient impossibles à dépenser après l’activation, sauf à les avoir déplacés avant. Aucun basculement de ce type n’a eu lieu sur le mainnet. L’avertissement concerne la suite, pas la soirée du 4 octobre.

Sprout appartient à la première génération de confidentialité du protocole. Les pools suivants, Sapling puis Orchard, puis le pool séparé introduit avec Ironwood, ont remplacé des preuves plus lourdes par des constructions plus efficaces. Laisser indéfiniment un format ancien, c’est conserver une surface d’attaque, un coût de maintenance et une complexité que plus personne ne veut porter dans chaque client. Le couper sans préavis serait en revanche une mauvaise manière faite aux soldes oubliés.

Tant que le mainnet n’a pas activé le NU7, un solde Sprout reste dépensable selon les règles actuelles. Le risque naît du calendrier, pas du bloc de testnet.

Lecture prudente de l’annonce

La fenêtre pratique dépendra de la hauteur finalement choisie le 20 octobre. Si la cible du 5 novembre est tenue, les détenteurs concernés disposent de quelques semaines, pas de quelques trimestres. Un exchange qui custodie encore des entrées Sprout, un portefeuille matériel ancien, une phrase de récupération jamais migrée : chacun de ces cas mérite un inventaire avant la date, pas un fil de discussion après. Le testnet, lui, permet aux éditeurs de logiciels de vérifier que le rejet des transactions de version 4 est propre, explicite, et qu’il ne se confond pas avec une erreur de frais ou de synchronisation.

Il faut aussi distinguer immobilisation et perte au sens comptable. Une pièce qui ne peut plus être dépensée selon les nouvelles règles de consensus ne retourne pas magiquement dans une réserve protocolaire. Elle reste associée à son engagement historique, mais sans chemin de dépense. C’est précisément pour cela que le déplacement préalable est le seul geste utile. Attendre une « restauration » ultérieure serait spéculer sur une décision qui n’est pas annoncée.

Ironwood, l’ombre portée de l’été

Le NU7 arrive quelques mois seulement après une autre bascule majeure. Le 28 juillet, au bloc 3 428 143, la mise à niveau Ironwood a activé un pool protégé suivi séparément. Le motif n’était pas la vitesse. C’était une faille dans le pool Orchard, susceptible en théorie de permettre la création de ZEC contrefaits et indétectables. Les chercheurs n’avaient pas trouvé de preuve d’exploitation. Le modèle de confidentialité empêchait toutefois de démontrer de façon concluante qu’aucune pièce non autorisée n’avait jamais été créée dans le pool concerné.

Ironwood a répondu à cette incertitude d’offre en séparant le nouveau pool d’Orchard et en posant des garde-fous comptables sur ce qui pouvait sortir de l’ancien. Orchard restait ouvert aux retraits, tandis que les fonds nouvellement protégés partaient vers Ironwood. La version 6.0.0 de Zebra a implémenté ce pool avec la structure d’action d’Orchard et le système de preuve Halo2, tout en tenant des registres distincts pour l’arbre d’engagement des notes, l’ensemble des nullificateurs, le pool de valeur de chaîne et l’historique.

Le NU7 s’inscrit donc dans une séquence, pas dans un vide. Juin avait déjà vu des mesures d’urgence : transactions affectées temporairement désactivées, logiciels corrigés, puis trajectoire vers Ironwood comme réponse de plus long terme. Automne 2026 ajoute le rythme, les frais recyclés, les limites d’actions et le retrait programmé d’un format ancien. Lire le testnet du 4 octobre sans l’été précédent, c’est manquer la raison pour laquelle les équipes avancent par paliers vérifiables plutôt que par grand soir.

Les nœuds, Zebra, et le détour par Zakura

Un changement de consensus ne vit pas seulement dans un document de spécification. Il vit dans les implémentations que les opérateurs acceptent de lancer. Les versions 6.4 de Zebra, en septembre, contenaient déjà du travail lié à la préparation du NU7. Le candidat du 2 octobre a ajouté le support de la mise à niveau sur le testnet public. C’est ce fil logiciel qui a rendu l’activation du 4 octobre observable, plutôt qu’une simple annonce de calendrier.

Juste avant ces préparatifs, le réseau a traité un incident distinct. Une vulnérabilité de haute sévérité touchant Zebra 6.4.0 et 6.4.1 pouvait permettre à un pair de faire planter un nœud à distance. La fondation a publié Zebra 6.4.2 le 25 septembre et a indiqué que le problème visait la disponibilité du nœud, pas le consensus ni les fonds. La nuance compte. Un plantage distant est grave pour la résilience. Ce n’est pas une faille d’émission. Les deux sujets se sont succédé dans le temps ; ils ne se confondent pas.

Pendant ce temps, Gemini a déplacé son infrastructure Zcash vers Zakura en vue du NU7. L’échange a indiqué que ses déploiements Zakura avaient rejoint la pointe de chaîne en un peu plus de six heures, contre près d’une journée pour Zebra, tandis que les dépôts et retraits clients continuaient de fonctionner normalement. Ce n’est pas un classement définitif des clients. C’est un signal opérationnel : à l’approche d’une activation, la vitesse de rattrapage et la stabilité des retraits deviennent des critères aussi visibles que la pureté de la spécification.

Pour un opérateur individuel, la leçon est plus modeste. Le testnet demande le candidat qui comprend les nouvelles règles. Le mainnet, tant que la hauteur n’est pas fixée, n’exige pas encore ce basculement. Confondre les deux consignes est le moyen le plus sûr de mettre à jour trop tôt, ou trop tard. La communication de la fondation sur ce point était nette dès la sortie du 2 octobre : pas de changement obligatoire côté production avant une hauteur établie.

Ce que le 20 octobre doit trancher

La date du 20 octobre n’est pas une activation. C’est une revue. Les développeurs doivent regarder comment le testnet s’est comporté depuis le bloc 4 465 026, puis décider s’il faut poursuivre vers le réseau principal et, le cas échéant, à quelle hauteur. La cible du 5 novembre reste un cap, pas un engagement déjà exécuté. Un écart de quelques jours sur le testnet, l’activation étant arrivée plus tôt que l’estimation, rappelle que les hauteurs se calculent, puis se constatent.

Plusieurs questions pratiques se poseront dans cette revue, même si le communiqué du jour ne les liste pas toutes. Les blocs de 25 secondes produisent-ils une chaîne stable, ou une hausse gênante d’orphelins ? Les limites d’actions protégées rejettent-elles le spam sans bloquer des paiements ordinaires ? Les estimateurs de frais des portefeuilles comprennent-ils le NSM ? Les clients refusent-ils proprement une transaction de version 4 sur le réseau d’essai, avec un message qu’un humain peut comprendre ? Une seule de ces réponses négative peut justifier de décaler la hauteur, sans remettre en cause le paquet lui-même.

Il existe aussi un scénario plus ferme : les métriques tiennent, la hauteur est posée, et le 5 novembre devient une vraie fenêtre de production. Dans ce cas, le travail change de nature. Il ne s’agit plus d’observer un laboratoire. Il s’agit de prévenir les soldes Sprout, de vérifier que les exchanges ont le bon binaire, et de s’assurer que les explorateurs n’affichent pas l’ancienne cadence comme si de rien n’était.

Ce que cela change pour un détenteur, sans dramatiser

La majorité des utilisateurs récents, ceux dont les fonds protégés vivent dans les pools postérieurs à Sprout, ne sont pas concernés par l’impasse de la version 4. Ils sont concernés par le rythme, par la façon dont les frais seront présentés, et par la nécessité de mettre à jour le logiciel avant une activation principale. Un client trop vieux qui ne connaît pas les nouvelles règles peut refuser de suivre la chaîne, ou pire, construire une transaction que le réseau n’acceptera plus.

Pour un détenteur Sprout, la hiérarchie des gestes est plus sèche. Identifier le pool. Déplacer les fonds tant que le format reste accepté. Ne pas confondre un solde affiché avec un solde dépensable après la hauteur choisie. Les interfaces qui mélangent encore les générations de pools sans étiquette claire auront une responsabilité éditoriale dans les semaines qui viennent. Un libellé du type « protégé » ne suffit plus lorsqu’un seul des pools protégés est menacé d’impasse.

• Utilisateur récent : surveiller la mise à jour du portefeuille et la date finalement votée le 20 octobre.
• Détenteur Sprout : traiter la migration comme une échéance, pas comme une option cosmétique.
• Opérateur de nœud : testnet sur le candidat adapté, mainnet inchangé tant que la hauteur n’existe pas.
• Place de marché : vérifier le client, les retraits et l’étiquetage des dépôts anciens.

Aucune de ces lignes ne remplace la documentation officielle du protocole au moment où la hauteur sera publiée. Elles cadrent seulement l’attention. Le bruit autour d’une activation a tendance à produire deux erreurs symétriques : tout migrer dans la panique le jour du testnet, ou ne rien lire jusqu’au lendemain du mainnet. Les deux sont mauvaises. Le calendrier publié laisse une revue intermédiaire précisément pour éviter ce genre de réflexe.

Vitesse, confidentialité et charge : le triangle qui ne se négocie pas

Une chaîne transparente peut raccourcir ses blocs en surveillant surtout la propagation et les orphelins. Une chaîne à preuves de connaissance succincte ajoute une dimension : chaque action protégée embarque une vérification que le portefeuille et le nœud doivent pouvoir absorber. Le NU7 tente de tenir les trois bords du triangle. Des blocs plus fréquents pour l’usage. Des limites pour que la fréquence ne devienne pas une arme. Une émission recalibrée pour que la fréquence ne devienne pas une dilution.

Ce triangle explique aussi pourquoi le test « sous conditions réelles » demandé aux opérateurs n’est pas une formule creuse. Un banc d’essai interne voit des transactions propres. Un testnet public voit des clients hétérogènes, des pairs mal configurés, des transactions limites, des relances. C’est dans cet écart que se nichent les bugs d’affichage, les frais mal estimés et les synchronisations qui semblaient acceptables à 75 secondes et qui deviennent pénibles lorsque le rythme triple.

Les semaines entre le 4 et le 20 octobre sont donc plus utiles qu’un simple décompte de blocs. Elles diront si le ressenti des 25 secondes survit au-delà du communiqué. Une première confirmation plus rapide ne vaut rien si le portefeuille met trois minutes à construire la transaction, ou si le nœud passe son temps à reconstituer des branches courtes. La promesse utilisateur se juge à l’ensemble du chemin, pas au seul paramètre d’intervalle.

Gouvernance : un signal fort, pas un blanc-seing

Le chiffre de 99,9 % frappe. Il doit être lu avec son dénominateur. Près de 2,4 millions de ZEC ont participé, soit environ deux tiers des soldes Ironwood éligibles enregistrés pour ce vote. C’est considérable pour un sondage privé. Ce n’est pas l’unanimité de chaque adresse ayant jamais reçu un ZEC. Les pièces transparentes anciennes, les soldes en conservation, les détenteurs qui n’ouvrent pas leurs outils de vote : ils n’apparaissent pas dans ce pourcentage.

Le trio de résultats reste néanmoins cohérent. Intervalle à 25 secondes très largement soutenu. Calendrier de réduction de récompense conservé. Départ de réémission sous NSM plutôt situé en février 2031. On y lit une préférence pour la réactivité et pour la continuité monétaire, plus qu’une envie de réécrire l’offre. Les équipes qui ont ensuite visé le 5 novembre pouvaient s’appuyer sur ce mandat, à condition de ne pas sauter l’étape d’observation. C’est exactement l’ordre retenu : accord de septembre, candidat logiciel début octobre, testnet, revue, puis seulement hauteur principale.

Cette séquence mérite d’être soulignée dans un secteur où les activations sont parfois annoncées comme déjà faites. Ici, le compte du protocole a confirmé le testnet. Il n’a pas annoncé un mainnet accompli. La nuance tient en une phrase, et elle évite une partie des malentendus qui accompagnent chaque jalon de Zcash depuis que le nom du protocole attire de nouveau l’attention des marchés.

Ce que les marchés peuvent surinterpréter

Une activation de testnet n’est pas un catalyseur de flux en soi. Elle peut le devenir si les opérateurs la lisent comme le prélude certain d’un mainnet au 5 novembre, puis si un report du 20 octobre déçoit cette lecture. Le texte disponible ne permet pas ce raccourci. La cible existe. La décision n’est pas prise. Traiter le cours comme s’il devait « intégrer » des blocs de 25 secondes dès le 4 octobre, c’est confondre un laboratoire et une chambre de compensation.

Il existe en revanche un sujet de flux plus concret, et il est étroit : la migration éventuelle de soldes Sprout avant une désactivation de format. Si une fraction non négligeable de ces pièces se déplace vers un pool plus récent, ou vers une adresse transparente, dans une fenêtre courte, les explorateurs verront du volume qui n’est pas un changement d’avis économique. C’est un changement de contenant. Les commentateurs qui liront ce volume comme un signal directionnel se tromperont de variable.

Le NSM, de son côté, n’a pas d’effet immédiat sur l’offre circulante du jour de l’activation, au-delà de la part de frais mise en réserve. Ce n’est pas un choc d’émission. Les gros chiffres d’offre restent gouvernés par le calendrier de subvention, que le sondage a précisément demandé de conserver. Quiconque annoncerait une « impression accélérée » à cause des blocs plus courts aurait manqué l’ajustement explicitement prévu.

Une comparaison utile avec d’autres rythmes de bloc

Vingt-cinq secondes placent Zcash dans une zone intermédiaire. Ce n’est pas le rythme de quelques secondes de certaines chaînes à preuve d’enjeu, ni l’intervalle historique d’une dizaine de minutes associé à Bitcoin. L’intérêt de la comparaison s’arrête vite, parce que le contenu d’un bloc n’a pas le même coût. Valider une transaction transparente et vérifier une action protégée ne pèsent pas le même poids. Le NU7 ne cherche pas à gagner une course de latence contre des réseaux dont le modèle de confidentialité est différent. Il cherche à réduire une attente que ses propres utilisateurs jugeaient trop longue, sans casser les preuves.

C’est aussi pourquoi le discours « trois fois plus rapide » doit être manié avec des pincettes. Trois fois plus de blocs visés, oui. Trois fois moins d’attente moyenne pour une première inclusion, en théorie, oui. Trois fois plus de débit utile si chaque bloc est borné par de nouvelles limites, pas nécessairement. Le débit perçu dépendra du nombre d’actions autorisées par bloc autant que de la cadence. Les limites anti-spam sont donc l’autre moitié de la promesse de vitesse. Les isoler du communiqué, c’est raconter une accélération incomplète.

Ce que les portefeuilles devront rendre visible

Le protocole peut être correct et l’expérience, mauvaise. Après une activation principale, un bon client devrait montrer au moins quatre choses sans jargon inutile. Le pool dans lequel se trouve chaque note. Le fait qu’un format ancien ne sera plus accepté après une hauteur donnée. Une estimation de frais compréhensible une fois le NSM en place. Un motif de rejet explicite lorsque une action protégée dépasse la limite du bloc.

Rien de tout cela n’est un détail d’interface. L’histoire récente du protocole, avec un pool séparé pour répondre à une incertitude d’offre, a déjà demandé aux utilisateurs de comprendre qu’il existe plusieurs shielded pools, pas un seul coffre. Ajouter une échéance Sprout sans l’afficher reviendrait à compter sur la presse spécialisée pour faire le travail des logiciels. Une partie du public ne lit pas les notes de version. Elle lit l’écran qui dit si l’envoi a réussi.

Les échanges ont un écran de plus : la page de dépôt. Si un ancien chemin Sprout reste affiché après l’annonce d’une hauteur, des fonds peuvent arriver dans un contenant que la plateforme ne saura plus faire sortir selon les nouvelles règles. Le précédent Gemini, avec un basculement d’infrastructure vers Zakura et des retraits maintenus, montre que les places anticipent. Il ne dit pas que toutes l’ont fait. La revue du 20 octobre sera aussi le moment où ces acteurs sauront s’ils doivent accélérer leurs tests internes.

Sécurité des nœuds et sécurité de l’offre, deux dossiers distincts

Le plantage distant corrigé dans Zebra 6.4.2 et la faille Orchard traitée par Ironwood n’appartiennent pas à la même famille. Le premier menaçait la disponibilité : un pair pouvait faire tomber un processus. Le second touchait à la question la plus sensible d’une chaîne à supply opaque : peut-on prouver qu’aucune pièce indue n’a été créée là où les montants sont cachés ? La fondation a été claire sur le correctif de septembre. Disponibilité atteinte, consensus et fonds non atteints. Sur Orchard, la réponse a été différente, précisément parce que l’absence de preuve d’exploitation ne vaut pas preuve d’absence.

Le NU7 n’est pas présenté comme un correctif de cette faille. Cette page a été tournée avec Ironwood. Le lier quand même est utile pour une seule raison : la confiance dans une activation dépend de la mémoire des précédentes. Un réseau qui a dû séparer un pool au cœur de l’été, puis corriger un plantage de nœud en septembre, aborde octobre avec des opérateurs plus attentifs. C’est plutôt sain. La vigilance excessive vaut mieux que l’habitude, dès lors qu’elle ne mélange pas les bulletins de sécurité.

Scénarios entre le testnet et la première semaine de novembre

Le scénario central, celui que les textes publics décrivent, est linéaire. Le testnet continue sous NU7. Le 20 octobre, les équipes jugent l’essai suffisant, fixent une hauteur, et visent le 5 novembre. Les clients publient des versions stables. Les détenteurs Sprout qui ont lu l’avertissement déplacent leurs fonds. Le jour dit, l’intervalle cible, le NSM, les limites et le refus des transactions de version 4 deviennent des règles du réseau qui porte la valeur.

Un scénario de décalage reste ouvert, et il ne serait pas un échec automatique. Si les orphelins, la charge des preuves ou le comportement des frais sortent de la bande acceptable, reporter la hauteur protège les soldes réels. Le coût est narratif : une cible manquée. Le coût d’une activation précipitée serait plus dur à raconter, surtout après un été déjà consacré à une incertitude d’offre. Rien dans l’annonce du 4 octobre ne suggère une volonté de brûler les étapes une fois le testnet lancé. L’existence même d’une revue datée dit le contraire.

Un troisième scénario, plus étroit, concerne uniquement Sprout. L’activation principale a lieu comme prévu, mais une part des fonds anciens n’a pas bougé. Ces pièces deviennent non dépensables. Le protocole fonctionne. Des utilisateurs découvrent trop tard la conséquence du format. Ce scénario ne se joue pas dans le code du 20 octobre. Il se joue dans la clarté des messages d’ici là. C’est le seul volet où la communication compte autant que la spécification.

Ce qu’il faut retenir sans attendre le prochain fil

Le 4 octobre, Zcash a fait ce qu’il avait annoncé vouloir faire avant le mainnet : allumer le NU7 là où une erreur coûte du temps, pas des soldes. Le bloc 4 465 026 est une borne vérifiable, pas un slogan. L’intervalle visé passe de 75 à 25 secondes. L’émission est ajustée pour ne pas suivre cette accélération au triple. Une part des frais peut être mise de côté pour de futures récompenses. Les actions protégées sont bornées. Les transactions de version 4, elles, ne disparaîtraient qu’avec l’activation principale, et avec elles le chemin de dépense Sprout.

Le 20 octobre dira si cette mécanique, observée depuis le testnet, mérite une hauteur sur le réseau qui compte. Le 5 novembre reste l’horizon cité, pas une date gravée. D’ici là, le geste utile n’est pas de commenter la vitesse en abstrait. C’est de savoir dans quel pool se trouvent ses pièces, quel client on fait tourner, et si l’on dépend encore d’un format que le protocole s’apprête à retirer.

Zcash a passé l’été à séparer un pool pour circonscrire un doute, puis septembre à colmater une disponibilité de nœud. Octobre ouvre un autre chantier : faire tourner le réseau plus souvent, sans diluer la journée, sans ouvrir la porte au spam, et sans laisser un ancien coffre se refermer en silence. Le testnet vient de commencer à répondre. La réponse qui vaudra pour les fonds réels n’a pas encore été signée.