Imaginez que vous envoyez des ZEC vers un exchange pour vendre rapidement avant une fluctuation. Jusqu’à présent, le réseau Zcash produisait un bloc toutes les 75 secondes en moyenne. Avec l’upgrade NU7, ce rythme passe à 25 secondes. Cette accélération change-t-elle réellement l’expérience utilisateur, ou les plateformes continueront-elles d’imposer leurs propres délais ? Pour les mineurs, la question est encore plus tranchée : le volume de blocs triple, mais la subvention par bloc chute d’environ deux tiers. Le calcul quotidien reste-t-il identique ?
L’Upgrade NU7 : Un Changement De Rythme Pour Zcash
L’activation de NU7 est prévue au bloc 3 543 405. À partir de ce moment, le réseau adopte un intervalle cible de 25 secondes entre chaque bloc, contre 75 secondes auparavant. Cette décision technique vise à rendre les confirmations plus fréquentes sans modifier le plafond d’émission total de 21 millions de ZEC. Le logiciel Zebra 7.0.0 prépare les nœuds à cette bascule. Pourtant, le moment exact dépend de la cadence réelle des mineurs, qui peuvent accélérer ou ralentir le calendrier en fonction de la puissance de calcul engagée.
Pour un utilisateur qui dépose des fonds sur une plateforme exigeant six confirmations, le calcul théorique passe de sept minutes et demie à deux minutes et demie. Cette estimation reste purement indicative. Les exchanges conservent la liberté de conserver le même nombre de confirmations, de l’augmenter, ou même de suspendre temporairement les dépôts pendant la transition. Le réseau produit les blocs plus vite ; c’est aux services de décider quand rendre les fonds utilisables.
Ce Qui Change Entre L’Envoi Et La Disponibilité Des Fonds
Un transfert de ZEC traverse plusieurs étapes indépendantes. L’expéditeur construit la transaction et la diffuse. Les nœuds la valident. Un mineur l’inclut dans un bloc. Le destinataire la détecte. Enfin, la plateforme ou le wallet décide du nombre de confirmations nécessaires avant de considérer les fonds disponibles. NU7 n’agit que sur l’intervalle entre les blocs. Elle ne garantit pas que la transaction soit immédiatement incluse, ni que le wallet du destinataire soit synchronisé, ni que l’exchange applique une politique identique.
Dans le cas d’un transfert direct entre deux wallets personnels, le premier bloc peut apparaître plus rapidement. Si le destinataire attend plusieurs confirmations avant de livrer un bien ou de libérer un service, sa politique interne détermine l’ampleur du gain. Un wallet offline ne affichera le paiement qu’une fois reconnecté, même si le réseau a déjà confirmé la transaction plusieurs fois. Ces délais logiciels restent inchangés.
Les exchanges introduisent une couche supplémentaire. Ils peuvent afficher un dépôt en attente dès la première confirmation, puis créditer le compte uniquement après avoir atteint leur seuil. Un trader qui compare les délais entre plateformes doit mesurer le temps écoulé entre la diffusion de la transaction et le moment où le solde devient tradable. Le simple compteur de blocs ne suffit plus. Certains interfaces comptent le bloc d’inclusion comme première confirmation, d’autres non. Une mesure précise doit enregistrer ces détails pour éviter les comparaisons trompeuses.
Les transactions shielded ajoutent une autre dimension. Le wallet doit scanner la chaîne pour déchiffrer les données avec les clés appropriées. Des blocs plus fréquents peuvent améliorer la réactivité perçue, mais ils génèrent aussi davantage de mises à jour à traiter. L’upgrade a d’abord été testée sur le testnet public, où des limites par bloc restreignent certains types de travail shielded. Ces limites visent à éviter qu’un seul bloc n’impose une charge excessive aux wallets légers.
Comparer Les Politiques De Confirmation Avant Et Après
Une comparaison utile se fait en durée cible plutôt qu’en nombre brut de blocs. Avant NU7, trois blocs représentaient 225 secondes de production attendue. Après, neuf blocs produisent la même durée. Six anciens blocs équivalent à 18 nouveaux blocs, soit 450 secondes. Ces équivalences permettent aux plateformes de conserver un niveau de sécurité temporelle similaire tout en s’adaptant au nouveau rythme.
Un tableau illustratif aide à visualiser ces équivalences :
| Politique | Cible par bloc | Durée cible |
|---|---|---|
| 3 confirmations avant NU7 | 75 secondes | 3 min 45 s |
| 3 confirmations après NU7 | 25 secondes | 1 min 15 s |
| 9 confirmations après NU7 | 25 secondes | 3 min 45 s |
| 18 confirmations après NU7 | 25 secondes | 7 min 30 s |
Ce tableau multiplie simplement le nombre de confirmations par l’intervalle cible. Il ne mesure pas la sécurité réelle d’une transaction précise, ni la décision finale d’une équipe de risque. Deux politiques de même durée attendue peuvent présenter des propriétés différentes si la variance des temps de bloc évolue ou si les conditions de minage changent. Le test le plus fiable consiste à utiliser le même service, le même wallet et le même type de transaction avant et après l’activation, en enregistrant trois horodatages : diffusion, inclusion dans un bloc, et crédit effectif.
Impact Sur Les Wallets Et La Synchronisation
Les wallets légers dépendent de leur capacité à récupérer et traiter les données nécessaires pour découvrir les paiements. Si des blocs exceptionnellement lourds dominent le travail de synchronisation, un utilisateur peut ressentir un ralentissement même lorsque les blocs arrivent plus souvent. Les limites sur les actions Orchard réduisent ce risque en bornant la charge maximale par bloc. Cependant, la capacité réelle dépend de la composition des transactions choisies par les mineurs et de l’interaction entre les limites spécifiques au pool et les limites globales.
Un développeur de wallet trouve de la valeur dans ces bornes parce qu’elles rendent certains cas extrêmes plus prévisibles. Un utilisateur qui ouvre un wallet après plusieurs jours d’inactivité devra toujours attendre la mise à jour, mais les blocs plus légers en termes d’actions shielded peuvent raccourcir cette attente dans la pratique. Les observations utiles après activation incluront le nombre d’actions par transaction, la répartition entre les pools, et le temps nécessaire à un wallet avec un point de synchronisation ancien pour rattraper le réseau.
La capacité peut augmenter alors que le nombre de paiements reste stable. Inversement, une application peut générer un pic d’activité shielded qui rend les limites pertinentes, même si la moyenne de long terme reste faible.
Cette distinction compte lorsque l’on compare l’utilité de l’upgrade à un mouvement de prix autour de la date d’activation. Une hausse de capacité ne prouve pas une hausse de demande. Les utilisateurs ne peuvent pas déduire le volume de paiements à partir de la taille des nouvelles limites. Seules les mesures de trafic réel après le lancement fourniront une image claire.
Pourquoi Les Mineurs Doivent Comparer Sur Une Journée Ou Une Semaine
La réduction de la subvention par bloc rend une comparaison bloc par bloc trompeuse. Un mineur qui reçoit environ un tiers de la subvention précédente peut néanmoins participer à environ trois fois plus de blocs sur la même période. Sur un intervalle suffisamment long, la part de puissance de calcul du réseau détermine la part attendue de la subvention bien davantage que le montant attaché à un seul bloc. L’émission quotidienne programmée reste stable grâce à cette compensation.
La distribution temporelle des paiements change néanmoins. Un mineur solo vit les blocs comme des événements discrets et peut passer de longues périodes sans en trouver un. Un pool agrège le travail de nombreux mineurs et applique sa propre comptabilité. Un flux plus fréquent de récompenses plus petites modifie le rythme des recettes, même lorsque l’agrégat programmé reste constant. Un relevé de pool peut mélanger subvention, fees et ajustements liés à sa formule de distribution. Pour isoler l’effet de NU7, il faut séparer ces composants et utiliser la même unité de temps.
Les coûts opérationnels introduisent une distinction supplémentaire. Le revenu en ZEC ne décrit pas le profit après électricité et amortissement du matériel. Un pool peut générer un montant similaire de ZEC sur une période et voir la valeur en dollars évoluer si le prix du token bouge. Une baisse de profit net ne prouverait pas à elle seule que le calendrier de subvention a changé. Les fees de transaction varient bien davantage que la subvention programmée. Si l’activité augmente, le total des fees sur une journée peut progresser même si les mineurs n’en conservent qu’une fraction plus faible. Si l’activité stagne, la nouvelle répartition réduit immédiatement leur revenu en fees.
Une journée contient approximativement 1 152 blocs à 75 secondes et 3 456 blocs à 25 secondes. Avec un tiers de la subvention par bloc, l’émission agrégée quotidienne reste identique. Le nombre réel de blocs peut varier, de sorte qu’une journée isolée peut se situer au-dessus ou en dessous de ces repères. Un opérateur de pool doit donc comparer les retours sur des fenêtres de même durée. Un graphique affichant le paiement par bloc chutera mécaniquement à la transition. Un graphique de la subvention agrégée sur une semaine pose une question différente. Les frais de pool, les coûts matériels, l’électricité et la part de puissance de calcul déterminent ce que chaque mineur conserve réellement.
La Réserve De Fees Et Le Mécanisme De Soutien Du Réseau
Sous le mécanisme de durabilité du réseau, le protocole conserve un enregistrement de la valeur mise de côté pour une réémission ultérieure. Cette réserve offre au réseau une source de récompenses futures qui provient des fees ou de montants éligibles non réclamés. Le solde de la réserve et les règles de prélèvement déterminent combien peut être rendu disponible au fil du temps. Deux périodes peuvent donc entretenir des relations différentes entre l’usage et les dépenses de sécurité. Pendant que les fees s’accumulent, les mineurs actuels ne conservent que la part versée immédiatement. Une fois la réémission programmée, les mineurs futurs peuvent recevoir des récompenses issues d’une activité bien antérieure. Les participants qui ont collecté la part initiale et ceux qui reçoivent plus tard les fonds de la réserve peuvent être différents.
La conception préserve une incitation à inclure des transactions payantes grâce à la portion conservée par les mineurs. Elle soulève aussi la question de savoir quel volume de demande de blocs est nécessaire avant que la réserve ne devienne économiquement significative. Si les fees restent modestes par rapport à la subvention, un pourcentage élevé de fees peut encore représenter une part faible des fonds qui soutiennent le minage. Une proposition séparée visant à diriger une portion supplémentaire des récompenses vers la réserve illustre cette distinction. La contribution déjà spécifiée dans NU7 et une proposition de financement futur constituent des choix de politique distincts. Une description des règles de lancement doit s’en tenir aux paramètres de la spécification de l’upgrade et garder les propositions ultérieures à part.
La réserve crée également une question comptable pour qui suit l’émission. La valeur mise de côté à partir des fees peut être comptée lorsqu’elle entre dans la réserve et à nouveau lorsqu’elle est réémise. Ce sont deux événements distincts dans la vie de la même valeur. Une vision comptable qui traiterait chaque étape comme une nouvelle offre peut obscurcir ce qui est réellement disponible aux utilisateurs à une hauteur donnée. Les dates d’événements sont exprimées en numéros de blocs, ce qui permet à un observateur de savoir quelle règle s’applique sans extrapoler à partir d’une prévision d’horloge.
La Transition Logicielle Et Les Services
Zebra 7.0.0 constitue la version stable qui supporte l’activation sur le mainnet. Un service qui utilise un nœud plus ancien peut continuer à faire tourner son logiciel même lorsque sa vue de la chaîne ne suit plus le réseau upgradé. Un exchange, un backend de wallet ou un pool doit donc considérer ce que son infrastructure voit à la hauteur d’activation. La distinction devient visible lorsque différents services rapportent des hauteurs de blocs différentes. Une interface peut rester accessible même si le nœud derrière elle cesse de suivre la chaîne que les utilisateurs attendent. Pour une entreprise qui crédite des soldes, la question pertinente est de savoir si son système interne suit les mêmes règles de consensus que le réseau sur lequel les clients envoient des fonds.
Les préparatifs de la version ont inclus des correctifs affectant la synchronisation et la vérification. Ces correctifs traitent le comportement opérationnel en plus de l’upgrade de consensus. Pour un opérateur, le passage implique davantage que de vérifier l’intervalle de blocs annoncé. Il comprend le déploiement d’une version compatible et la vérification que les dépendances du service continuent de lire et de traiter correctement la chaîne. Le testnet a offert un terrain d’exercice avant le changement sur le mainnet. Il fournit la preuve que le code peut traiter des blocs sous les nouveaux paramètres dans un environnement de test. L’adoption sur le mainnet dépend des opérateurs qui soutiennent les wallets, les dépôts et le minage réels. Leur comportement devient observable à travers la chaîne et à travers les éventuels avis de service publiés autour de l’activation.
Un exchange qui se prépare à la transition doit réconcilier deux enregistrements. Son nœud suit les blocs et les transactions qu’ils contiennent, tandis que son grand livre client enregistre ce que les utilisateurs peuvent trader ou retirer. Une upgrade de chaîne peut se dérouler tandis que l’exchange maintient ces livres séparés pendant une période, notamment s’il souhaite confirmer que les dépôts observés avant l’upgrade restent visibles pour son infrastructure upgradée. Le temps d’attente d’un client est alors gouverné par le moment où le service réconcilie les livres et reprend le crédit des comptes.
Le Sort Irréversible Du Pool Sprout
Le pool shielded original constitue un héritage de l’histoire de Zcash. Les pools ultérieurs ont offert au réseau d’autres manières de représenter les transactions shielded, mais un solde laissé dans Sprout dépend encore des formats capables de dépenser depuis ce pool. NU7 modifie les versions de transactions valides, ce qui rend la question de format matérielle pour le détenteur d’un solde legacy. Un solde affiché comme ZEC donne au propriétaire le montant en devise. Il peut falloir davantage d’informations pour identifier le pool et le chemin de dépense disponible. L’action pertinente pour un détenteur legacy consiste à déplacer les fonds par une route compatible avant le changement de consensus. Mettre à jour le logiciel seul ne peut pas créer une transaction valide une fois que l’ancien format cesse d’être accepté.
Un chiffre public pour le solde d’un pool ne renseigne pas un observateur sur le nombre de détenteurs qui l’utilisent activement ni sur la portion récupérable avec des clés encore disponibles. Un petit nombre de gros soldes et de nombreux petits soldes inactifs peuvent produire le même total. La règle s’applique aux fonds restant dans le pool à l’activation, quelle que soit leur origine. Cette conséquence est distincte du plafond monétaire et des fees réservés pour des récompenses futures. Le traitement d’une ancienne version de transaction supprime un chemin de dépense. La règle de réserve comptabilise des fees qui pourront être réémis selon leur propre calendrier. La spécification de l’upgrade traite ces changements comme distincts, les transactions de version 4 devenant invalides à partir de la hauteur d’activation sur le mainnet.
L’échéance Sprout constitue l’exception à une histoire autrement mesurée en intervalles et en moyennes. Les wallets et les exchanges peuvent réviser leurs règles de confirmation, et les revenus de minage varieront avec l’activité. La règle affectant le pool legacy est fixée à la hauteur d’activation. Une fois appliquée, elle est irréversible.
Ce Qu’il Faut Surveiller Après L’Activation
Plusieurs indicateurs permettront d’évaluer concrètement les effets de NU7. Le premier est l’atteinte du bloc 3 543 405 et la production de blocs suivants sous les nouvelles règles. Le second concerne les politiques de dépôt : les exchanges publient-ils de nouveaux seuils de confirmation ou rouvrent-ils des dépôts suspendus ? Le troisième porte sur l’activité Orchard : nombre d’actions observées par bloc et temps écoulé pendant les périodes chargées. Le quatrième concerne les revenus de minage : recettes de fees et revenus de subvention quotidiens comparés sur des fenêtres équivalentes. Enfin, les avis de wallets concernant les soldes legacy Sprout qui étaient encore éligibles au déplacement avant l’activation fourniront une indication sur la prise en compte réelle de cette contrainte.
Les politiques de confirmation décideront ce que les clients remarquent réellement. L’espacement des blocs indique à un wallet à quelle fréquence le réseau s’attend à créer un nouvel emplacement pour les transactions. Le wallet doit encore construire et diffuser un paiement, un nœud doit l’accepter, et un mineur doit l’inclure. Si une transaction concurrence pour un espace limité, l’intervalle de blocs seul ne détermine pas son attente. Un exchange prend une décision séparée une fois qu’il voit la transaction. Il peut afficher un dépôt en attente avant de rendre le solde disponible pour le trading ou le retrait. Un client pourrait donc voir le dépôt apparaître plus tôt après NU7 tout en attendant plus longtemps que l’exchange applique sa propre politique finale de crédit.
Le nombre de confirmations change également de signification lorsque les blocs arrivent plus fréquemment. Six blocs au nouveau rythme représentent un intervalle de temps plus court que six blocs à l’ancien rythme. Un exchange qui souhaite préserver approximativement la même attente pourrait passer de six à dix-huit confirmations. Le compromis pour le client dépend de si l’exchange conserve son compte, le modifie, ou suspend temporairement les dépôts pendant la transition. Les paiements envoyés entre wallets personnels présentent un goulot d’étranglement pratique différent. Le wallet du destinataire doit scanner la chaîne pour les transactions qu’il peut déchiffrer. Un premier bloc plus rapide aide, mais quelqu’un qui ouvre un wallet resté offline pendant des jours peut encore passer du temps à rattraper. Les limites sur les actions shielded traitent cette autre partie de l’expérience en bornant la quantité de travail que chaque bloc peut imposer au wallet.
Cette distinction compte aussi pour les mesures après activation. Un échantillon de dépôts effectués juste avant et après le fork pourrait contenir des temps d’arrêt de service ou des retraits retenus pour examen manuel. Il constituerait une base faible pour estimer les temps de confirmation ordinaires. Un échantillon plus comparable suivrait le moment où les utilisateurs ont soumis une transaction, le moment où elle est apparue pour la première fois dans un bloc, et le moment où un prestataire l’a créditée. Découper l’attente en ces intervalles aide à isoler la partie que le consensus modifie réellement.
Trois Fois Plus De Blocs : Comment Les Résultats De Minage Se Présentent
Les mineurs peuvent comparer les récompenses quotidiennes avant et après l’upgrade en séparant la subvention de la composante fees. La subvention est le montant alloué par les règles du protocole. Les fees de transaction varient avec les transactions que les utilisateurs envoient et les fees incluses dans les blocs. En utilisant uniquement les cibles de blocs, une journée contient environ 1 152 blocs à 75 secondes et 3 456 à 25 secondes. Avec un tiers de la subvention par bloc, cela produit la même subvention agrégée programmée sur la journée. Le nombre de blocs réalisé peut varier, de sorte qu’une journée individuelle peut encore se situer au-dessus ou en dessous de l’un ou l’autre repère.
Un opérateur de pool de minage devra donc comparer les retours sur la même période. Un graphique montrant le paiement par bloc chutera à la transition par conception. Un graphique montrant la subvention agrégée sur une semaine pose une question différente. Les frais de pool, les coûts matériels, l’électricité et la part de puissance de calcul du réseau qu’un mineur contrôle déterminent combien ce mineur conserve. La répartition des fees peut être évaluée avec un calcul séparé. Si la subvention représente 99 % des récompenses pré-upgrade d’un mineur et les fees 1 %, réduire la part de fees de 60 % réduirait les récompenses totales de 0,6 %, en supposant tous les autres facteurs constants. Si les fees représentent 10 %, le même changement réduirait les récompenses totales de 6 %. Ces exemples restent hypothétiques et isolent la règle de fees des changements d’usage et de concurrence.
La première comparaison pour les pools de minage est également sensible à la fenêtre sélectionnée. Prendre une heure de chaque côté de l’activation peut donner des résultats inhabituels si un pool a trouvé plusieurs blocs ou si quelques transactions exceptionnellement importantes sont arrivées proches les unes des autres. Mesurer les fees totales et la subvention émise sur le même nombre d’heures donne un résultat plus interprétable. Les règles de crédit d’un pool peuvent encore séparer le moment où le revenu est enregistré on-chain du moment où les mineurs individuels voient le solde sur leur compte. À titre d’illustration, un pool qui représente une part constante de blocs réussis s’attendrait à enregistrer davantage de découvertes de blocs dans une journée sous le nouveau calendrier. La récompense plus petite attachée à chaque découverte change les unités dans lesquelles son revenu arrive. Si le pool rapporte les récompenses par bloc sans montrer également combien il en a trouvés et combien il a payé par unité de travail, un utilisateur regardant le tableau de bord peut confondre un changement de distribution avec un changement de revenu. C’est pourquoi une comparaison quotidienne a besoin à la fois des composants de subvention et de fees, ainsi que d’une mesure comparable de participation.
Questions Fréquentes Sur L’Upgrade NU7
Quand NU7 s’active-t-il exactement ? Les règles basculent au bloc 3 543 405. Les estimations d’heure d’horloge évoluent au fur et à mesure que les mineurs produisent des blocs. Le déclencheur de consensus reste ce numéro de bloc.
De combien le temps de bloc cible est-il réduit ? La cible passe de 75 secondes à 25 secondes. Cette cible est une moyenne à travers les blocs, de sorte que l’intervalle entre deux blocs particuliers peut être plus long ou plus court.
Les dépôts sur exchanges arriveront-ils toujours trois fois plus vite ? Chaque plateforme fixe sa propre politique de confirmation et de crédit. Les prestataires peuvent modifier leurs seuils de confirmation ou maintenir les dépôts en pause pendant la bascule. Leurs décisions de crédit déterminent quand les fonds apparaissent sur un compte client.
NU7 modifie-t-il la subvention quotidienne programmée ? La subvention par bloc tombe à un tiers tandis que le nombre cible de blocs triple. Comparez les revenus sur des périodes égales pour voir l’effet combiné.
Quelle part des fees les mineurs conservent-ils ? Ils retiennent 40 % des fees de transaction. Le reste va à la réserve du réseau sous les nouvelles règles de fees. Les recettes d’un mineur dépendent toujours du total des fees payées.
Que devient le reste des fees ? Le protocole en met 60 % de côté pour une réémission future selon les règles de sa réserve. Cette réémission est programmée à une hauteur ultérieure et reste distincte de la portion que les mineurs peuvent collecter au moment de l’inclusion de la transaction.
Peut-on encore dépenser les fonds laissés dans Sprout après l’activation ? NU7 invalide les transactions de version 4, que les transferts Sprout requièrent. La restriction s’applique aux soldes Sprout legacy. Les utilisateurs des autres pools font face à des considérations de wallet et de confirmation différentes.
L’upgrade change-t-elle le plafond d’offre de ZEC ? Le plafond reste de 21 millions de ZEC. La réserve modifie le timing et le traitement de montants éligibles à l’intérieur des règles monétaires existantes.
En définitive, l’upgrade NU7 accélère le rythme de production des blocs et redistribue la manière dont les fees soutiennent le réseau à long terme. Pour la majorité des utilisateurs, le bénéfice observable sera un changement spécifique sur une route de paiement particulière. Pour les mineurs, le changement observable sera la distribution de la subvention et des fees sur une période assez longue pour tenir compte du nombre accru de blocs. Les plateformes et les wallets restent les arbitres finaux de l’expérience perçue, tandis que les détenteurs de soldes Sprout doivent agir avant la hauteur d’activation s’ils souhaitent conserver un chemin de dépense. L’observation attentive des politiques de confirmation, des volumes réels et des revenus de minage sur des fenêtres comparables fournira les réponses les plus solides une fois le réseau basculé.
