Zcash réduit ses temps de bloc : qu'est-ce que cela change pour les utilisateurs et les mineurs ?

La mise à niveau NU7 de Zcash réduira le temps cible entre les blocs de 75 secondes à 25, donnant aux dépôts une chance d'être confirmés plus tôt tout en laissant les exchanges décider quand les créditer. La mise à niveau modifie également ce que les mineurs gagnent sur les transactions, avec 40 % des frais allant aux mineurs et les 60 % restants mis de côté pour de futures récompenses.

Zcash a programmé sa mise à niveau NU7 pour le bloc 3 543 405, moment où le réseau réduira son temps cible entre les blocs de 75 secondes à 25 et commencera à mettre de côté la plupart des frais de transaction pour de futures récompenses de minage.

Les notes de version Zebra 7.0.0 de la Zcash Foundation identifient le logiciel qui prend en charge le basculement. Pour quelqu'un qui dépose des ZEC sur un exchange exigeant six confirmations, l'intervalle plus court fait passer l'attente cible pour ces blocs de sept minutes et demie à deux minutes et demie, en supposant que l'exchange conserve la même exigence.

Pour les mineurs, le changement réside dans la façon dont ils gagnent leurs récompenses. Zcash émettra une subvention plus faible dans chaque bloc pour maintenir une émission quotidienne programmée stable, tandis que les mineurs percevront 40 % des frais de transaction et les 60 % restants iront dans une réserve pour une réémission ultérieure.

Ce qui change entre l'envoi de ZEC et l'obtention d'un solde utilisable

Un paiement peut passer par plusieurs étapes différentes même lorsque les deux parties utilisent la même monnaie. L'expéditeur crée une transaction et la diffuse au réseau. Un nœud vérifie la transaction par rapport à ses règles, un mineur l'inclut dans un bloc, et le logiciel du destinataire reconnaît le paiement. Le destinataire décide ensuite combien de confirmations attendre avant de considérer les fonds comme disponibles.

NU7 modifie l'espacement attendu entre les blocs de cette séquence. Il n'établit pas de temps garanti pour chacune des autres étapes. Un portefeuille hors ligne ne peut pas afficher le paiement avant de se reconnecter, et un exchange peut maintenir un solde en attente pendant qu'il applique ses propres vérifications. Comme l'a rapporté crypto.news, NU7 fixe un objectif de 25 secondes pour les blocs. L'effet sur un dépôt dépend toujours du service qui le reçoit.

Un transfert direct offre la comparaison la plus simple. Si la transaction de l'expéditeur est acceptée et que les mineurs l'incluent dans le bloc suivant, le destinataire a une chance de voir la première confirmation plus tôt. Si le destinataire est un commerçant qui attend plusieurs confirmations avant de remettre des biens, sa politique détermine quelle part du bénéfice parvient à l'acheteur.

Un exchange ajoute un système de crédit entre la blockchain et le compte du client. Il peut reconnaître la transaction onchain et afficher à l'utilisateur un élément en attente, puis créditer le compte une fois le nombre requis accumulé. Un trader qui souhaite vendre les ZEC ne peut pas utiliser le premier horodatage seul pour comparer les exchanges. La comparaison utile est le temps entre la diffusion du même type de transaction et la réception d'un solde négociable.

Une politique de six confirmations dépend aussi de la façon dont l'exchange définit le décompte. Certaines interfaces comptent le bloc contenant la transaction comme la première confirmation. Le calcul simple de six fois l'espacement cible est une référence pour la production de blocs, tandis que l'attente observée dépend de l'endroit dans l'intervalle où la transaction a été envoyée et si le mineur suivant l'a incluse. Une mesure devrait enregistrer ces détails avant de comparer les résultats.

Un portefeuille recevant un transfert blindé dispose d'une autre source de travail. Il parcourt la chaîne pour trouver des données qu'il peut déchiffrer avec les clés appropriées. Des blocs plus rapides peuvent améliorer l'expérience de paiement tout en créant des mises à jour plus fréquentes à traiter par le logiciel. La mise à niveau a été exécutée sur le testnet de Zcash avant le basculement du mainnet. Ses règles par bloc limitent certains types de travail blindé.

Une comparaison des politiques de confirmation peut être exprimée en minutes sans deviner ce que choisira un échange. À l'ancienne cible, trois blocs représentaient 225 secondes de production attendue. À la nouvelle cible, neuf blocs représentent la même durée cible. Six anciens blocs et 18 nouveaux blocs représentent de même tous deux 450 secondes.

Le tableau multiplie le nombre par l'espacement cible. Il ne peut pas mesurer la quantité de travail qui sécurise une transaction spécifique ni ce que l'équipe de risque d'un échange considérera comme équivalent. Deux politiques ayant la même durée attendue peuvent avoir des propriétés différentes si les conditions de minage du réseau ou la distribution des temps de bloc changent.

Le test avant-après le plus utile utiliserait le même service, le même portefeuille et le même type de transaction. Un horodatage enregistrerait le moment où l'utilisateur diffuse la transaction. Un deuxième marquerait l'inclusion. Un troisième enregistrerait le moment où l'échange ou le commerçant rend le solde disponible. Si le premier intervalle diminue et que le second reste stable, le changement de réseau a peut-être amélioré une partie du processus tandis que le service a conservé ses vérifications existantes.

Un client effectuant un paiement doit également tenir compte de la disponibilité du logiciel du destinataire. Un commerçant utilisant un backend compatible peut être en mesure d'agir dès que sa politique le permet. Un client envoyant vers un portefeuille qui n'a pas terminé sa synchronisation peut attendre que le portefeuille se rattrape même après que les mineurs ont confirmé le paiement. Les deux expériences peuvent être des descriptions exactes de différentes parties de la même transaction.

Pour les mineurs, les changements dans le rythme des blocs peuvent compliquer les comparaisons effectuées pendant la transition elle-même. Un court échantillon pourrait inclure des blocs plus lents ou plus rapides que la cible, et les opérateurs peuvent mettre à jour leur logiciel à des moments différents. Une lecture d'une heure pourrait capturer le basculement et la variation ordinaire des arrivées de blocs ensemble. Des fenêtres plus longues donnent une meilleure vue de si la production réalisée se stabilise près de la cible.

Un opérateur évaluant les frais a besoin d'une discipline similaire. Comparer le total par bloc peut donner un résultat trompeur car les transactions sont réparties sur davantage de blocs. Une comparaison basée sur les frais par jour peut montrer combien les utilisateurs ont payé au total. L'opérateur peut ensuite calculer quelle part de ce total est disponible immédiatement et quelle part est réservée selon les nouvelles règles.

La capacité à faire ces distinctions importe plus qu'une simple affirmation selon laquelle le réseau est trois fois plus rapide. Pour la plupart des utilisateurs, le bénéfice observable sera un changement spécifique à une route de paiement particulière. Pour les mineurs, le changement observable sera la distribution de la subvention et des frais sur une période suffisamment longue pour tenir compte du plus grand nombre de blocs.

Ce que mesure l'estimation de capacité d'Orchard

L'estimation Orchard de la fondation concerne le taux de transactions selon un modèle spécifié. Les transactions blindées peuvent avoir différentes formes et nécessiter différentes quantités de travail. Deux transactions peuvent compter comme deux transferts pour les personnes qui les utilisent et imposer néanmoins des charges différentes au réseau en raison du nombre d'actions impliquées.

Une limite sur les actions est par conséquent différente d'un quota sur les paiements. Elle fixe une borne sur ce qu'un bloc peut contenir pour le pool concerné. Le réseau peut combiner cette borne plus stricte avec des blocs plus fréquents. Le nombre de transactions qui tiennent réellement dépend de la composition des transactions que les mineurs sélectionnent et de l'interaction entre les limites spécifiques au pool et globales.

Pour un développeur de portefeuille, l'intérêt d'une limite est qu'elle rend certaines charges de travail dans le pire des cas plus faciles à appréhender. Un utilisateur qui synchronise un portefeuille léger dépend de la capacité du logiciel à récupérer et traiter les données nécessaires pour découvrir ses paiements. Si des blocs exceptionnellement coûteux peuvent dominer ce travail, un utilisateur peut connaître une synchronisation plus lente même lorsque les blocs individuels arrivent plus rapidement.

L'estimation de capacité devrait être évaluée parallèlement aux performances sous trafic réel. Des observations utiles incluraient quels pools représentent l'activité, le nombre d'actions par transaction et le temps qu'un portefeuille disposant d'un point de synchronisation plus ancien met à rattraper son retard. Une synchronisation plus rapide sous charge quotidienne et une charge dans le pire des cas plus faible répondent à des problèmes liés mais différents.

Les utilisateurs ne peuvent pas déduire la demande de paiement à partir de la taille des nouvelles limites. La capacité peut augmenter tandis que le nombre de paiements reste stable. Inversement, une application peut générer une rafale d'activité blindée qui rend les limites pertinentes même si la moyenne à plus long terme du réseau reste faible. Cette distinction compte lorsqu'on compare l'utilité de la mise à niveau avec un mouvement de prix autour de la date d'activation.

Pourquoi les mineurs devraient comparer les revenus sur un jour ou une semaine

Le changement de la subvention signifie qu'un seul bloc est une unité peu appropriée pour comparer le revenu minier total à travers l'activation. Un mineur recevant un tiers de subvention par bloc peut toujours concourir pour environ trois fois plus de blocs sur la même période. Sur un intervalle suffisamment long, la part du mineur dans la puissance de calcul du réseau importe davantage pour sa part attendue de la subvention que le nombre de ZEC attaché à un bloc.

Le changement peut néanmoins modifier la manière dont les paiements sont distribués dans le temps. Un mineur solo vit les blocs comme des événements discrets et peut passer longtemps sans en trouver un. Un pool combine le travail de nombreux mineurs et dispose de sa propre comptabilité pour distribuer les produits. Un flux plus fréquent de récompenses plus petites peut modifier le schéma des recettes même lorsque la subvention globale programmée reste stable.

Un relevé de pool peut combiner subvention, frais et ajustements issus de la formule de paiement du pool. Pour isoler l'effet de NU7, un mineur devrait comparer séparément les composantes de frais et de subvention et utiliser la même unité de temps. Comparer un paiement par bloc avec un paiement quotidien, ou comparer deux périodes avec des puissances de calcul sensiblement différentes, masquerait la part attribuable aux nouvelles règles.

Les coûts d'exploitation introduisent une distinction supplémentaire. Le revenu minier mesuré en ZEC ne décrit pas ce que les mineurs conservent après avoir payé l'électricité et les dépenses matérielles. Un pool pourrait gagner un montant similaire de ZEC sur une période et voir la valeur en dollars de ce revenu changer si le prix du jeton évolue. Une baisse du bénéfice net ne montrerait pas à elle seule que le calendrier de subvention des blocs a changé.

Les frais de transaction peuvent varier bien plus que la subvention programmée. Si l'activité augmente, les frais totaux sur une journée pourraient augmenter même si les mineurs conservent une fraction plus petite. Si l'activité reste la même, la répartition elle-même réduit leur revenu immédiat en frais. Une comparaison nécessite à la fois le nouveau pourcentage et le montant des frais auquel il s'applique.

Il existe un seuil simple pour cette comparaison étroite. Si le montant payé en frais atteint deux fois et demie son niveau antérieur, les mineurs conservant 40 % recevraient le même montant immédiat en frais qu'auparavant, toutes choses égales par ailleurs. Cette arithmétique ne prédit pas le trafic. Elle montre pourquoi l'effet sur les mineurs dépend en partie de l'usage que la mise à niveau permet et en partie du niveau initial des frais.

Les politiques de confirmation décideront de ce que les clients remarquent réellement

L'espacement des blocs indique à un portefeuille à quelle fréquence le réseau s'attend à créer un nouvel emplacement pour les transactions. Un portefeuille doit encore construire et diffuser un paiement, un nœud doit l'accepter, et un mineur doit l'inclure. Si une transaction est en concurrence pour un espace limité, l'intervalle entre blocs seul ne détermine pas son attente.

Une plateforme d'échange a une décision distincte à prendre une fois qu'elle voit la transaction. Elle 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 la plateforme applique sa propre politique de crédit final.

Les nombres de confirmations changent aussi de sens lorsque les blocs arrivent plus fréquemment. Six blocs à la nouvelle cible représentent une durée écoulée plus courte que six à l'ancienne cible. Une plateforme d'échange qui souhaite préserver à peu près la même attente pourrait passer de six à 18 confirmations. Le compromis pour le client dépend de si la plateforme conserve son nombre, le modifie ou suspend temporairement les dépôts pendant la transition.

Les paiements envoyés entre portefeuilles personnels présentent un autre goulot d'étranglement pratique. Le portefeuille du destinataire doit parcourir la chaîne pour trouver les transactions qu'il peut déchiffrer. Un premier bloc plus rapide aide, mais quelqu'un qui ouvre un portefeuille resté hors ligne pendant des jours peut encore passer du temps à se rattraper. Les limites imposées aux actions blindées répondent à cet autre aspect de l'expérience en bornant la quantité de travail que chaque bloc peut imposer au portefeuille.

Cette distinction compte aussi pour les mesures après l'activation. Un échantillon de dépôts effectués peu avant et peu après le fork pourrait contenir des interruptions de service ou des retraits retenus pour examen manuel. Cela constituerait une base fragile pour estimer les délais de confirmation ordinaires. Un échantillon plus comparable suivrait le moment où les utilisateurs ont soumis une transaction, celui où elle est apparue pour la première fois dans un bloc et celui où un fournisseur l'a créditée. Décomposer l'attente en ces intervalles aide à isoler la partie que le consensus modifie réellement.

Trois fois plus de blocs change l'apparence des résultats du minage

Les mineurs peuvent comparer les récompenses quotidiennes avant et après la mise à niveau en séparant la subvention de la composante des frais. La subvention est le montant alloué par les règles du protocole. Les frais de transaction varient selon les transactions envoyées par les utilisateurs et les frais inclus 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 globale 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 de ces repères.

Un opérateur de pool de minage devra donc comparer les rendements sur la même période. Un graphique montrant le paiement par bloc baissera à la transition, par conception. Un graphique montrant la subvention globale sur une semaine pose une question différente. Les frais du pool, les coûts du matériel, l'électricité et la part de la puissance de calcul du réseau contrôlée par un mineur déterminent ce que ce mineur conserve.

La répartition des frais peut être évaluée par un calcul séparé. Si la subvention représente 99 % des récompenses d'un mineur avant la mise à niveau et les frais 1 %, réduire la part des frais de 60 % diminuerait les récompenses totales de 0,6 %, en supposant que tous les autres facteurs restent constants. Si les frais représentent 10 %, la même modification réduirait les récompenses totales de 6 %. Les deux exemples sont hypothétiques et isolent la règle des frais des changements d'usage et de concurrence.

La première comparaison pour les pools de minage est tout aussi sensible à la fenêtre choisie. Prendre une heure de part et d'autre de l'activation peut donner des résultats inhabituels si un pool a trouvé par hasard plusieurs blocs ou si quelques transactions exceptionnellement importantes sont arrivées à proximité. Mesurer les frais totaux 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 en outre séparer le moment où les revenus sont enregistrés onchain de celui où les mineurs individuels voient le solde sur leur compte.

À titre d'illustration, un pool qui représente une part constante des blocs réussis s'attendrait à enregistrer davantage de découvertes de blocs dans une journée selon le nouveau calendrier. La récompense plus faible attachée à chaque découverte change les unités dans lesquelles ses revenus arrivent. Si le pool déclare des récompenses par bloc sans indiquer également combien il en a trouvé et combien il a payé par unité de travail, un utilisateur consultant le tableau de bord peut confondre un changement de distribution avec un changement de revenu. C'est pourquoi une comparaison quotidienne nécessite à la fois les composantes de subvention et de frais, ainsi qu'une mesure comparable de la participation.

La réserve change lorsque les frais soutiennent les mineurs

Dans le cadre du Mécanisme de durabilité du réseau, le protocole conserve une trace de la valeur mise de côté pour une réémission ultérieure. Ce pool donne au réseau une source de récompenses futures provenant de frais ou de montants non réclamés éligibles. Le solde de la réserve et les règles pour y puiser déterminent combien peut être rendu disponible au fil du temps.

Deux périodes peuvent donc présenter des relations différentes entre l'usage et les dépenses de sécurité. Pendant que les frais s'accumulent, les mineurs actuels ne conservent que la part payée immédiatement. Une fois la réémission programmée pour commencer, les futurs mineurs peuvent recevoir des récompenses provenant d'une activité survenue bien plus tôt. Les participants qui ont perçu la part initiale des frais et ceux qui reçoivent plus tard les récompenses financées par la réserve peuvent être différents.

La conception préserve une raison pour les mineurs d'inclure des transactions payantes grâce à la portion qu'ils conservent. Elle soulève aussi une question sur la demande de blocs nécessaire avant que la réserve ne devienne économiquement significative. Si les frais sont modestes par rapport à la subvention, un grand pourcentage de frais peut encore représenter une petite part des fonds soutenant le minage.

Une proposition distincte 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 sont des choix politiques distincts. Une description des règles de lancement devrait utiliser les paramètres de la spécification de mise à niveau et garder les propositions de financement ultérieures distinctes.

La réserve crée une question différente pour quelqu'un qui suit l'émission. La valeur mise de côté à partir des frais peut être comptée lorsqu'elle entre dans la réserve et de nouveau lorsque les règles la réémettent éventuellement. Ce sont des événements distincts dans la vie de la même valeur. Une vision comptable qui traite chacun comme une nouvelle offre peut obscurcir la quantité disponible pour les utilisateurs à une hauteur particulière. Le ZIP 259 donne les dates des événements en blocs, ce qui permet à un observateur de savoir quelle règle est en vigueur sans extrapoler à partir d'une prévision en temps réel.

La transition logicielle affecte les services ainsi que les opérateurs de nœuds

Zebra 7.0.0 est la version stable qui prend en charge l'activation du réseau principal. Un service utilisant un nœud plus ancien peut continuer à exécuter le logiciel même lorsque sa vision de la chaîne ne suit plus le réseau mis à niveau. Un échange, un backend de portefeuille ou un pool doit donc considérer ce que sa propre infrastructure voit à la hauteur d'activation.

La distinction devient visible lorsque différents services rapportent différentes hauteurs de bloc. 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 incluaient des correctifs affectant la synchronisation et la vérification. Ces correctifs traitent du comportement opérationnel parallèlement à la mise à niveau du consensus. Pour un opérateur, le basculement implique donc plus que la vérification de l'intervalle de bloc annoncé. Il comprend l'exécution d'une version compatible et la garantie que les dépendances du service continuent de lire et de traiter correctement la chaîne.

Le réseau de test a fourni un endroit aux développeurs pour exercer les règles avant le changement du réseau principal. Il fournit la preuve que le code peut traiter des blocs selon les nouveaux paramètres dans un environnement de test. L'adoption sur le réseau principal dépend des opérateurs qui prennent en charge les portefeuilles réels, les dépôts et le minage. Leur comportement devient observable à travers la chaîne et à travers les avis de service émis autour de l'activation.

Un échange se préparant à la transition doit concilier deux registres. Son nœud suit les blocs et les transactions qu'ils contiennent, tandis que son grand livre client enregistre ce que les utilisateurs peuvent échanger ou retirer. Une mise à niveau de la chaîne peut se poursuivre pendant que l'échange garde ces registres séparés pendant une période, en particulier si le service souhaite confirmer que les dépôts observés avant la mise à niveau restent visibles pour son infrastructure mise à niveau. Le temps d'attente d'un client est alors déterminé par le moment où le service concilie les registres et reprend le crédit des comptes.

Sprout donne à la mise à niveau une conséquence irréversible pour certains fonds

Le pool blindé d'origine est une partie héritée de l'histoire de Zcash. Les pools ultérieurs ont donné au réseau différentes façons de représenter les transactions blindées, mais un solde laissé dans Sprout dépend toujours des formats qui peuvent dépenser depuis ce pool. NU7 modifie les versions de transaction valides, ce qui rend la question du format matérielle pour le propriétaire d'un solde hérité.

Un solde de portefeuille affiché en ZEC donne au propriétaire le montant en devise. Il peut falloir plus d'informations pour identifier le pool et le chemin de dépense disponible. L'action pertinente pour un détenteur hérité est de déplacer les fonds par une voie compatible avant le changement de consensus. La mise à jour du logiciel seule ne peut pas créer une transaction valide après que l'ancien format cesse d'être accepté.

Un chiffre public pour le solde d'un pool ne peut pas indiquer à un observateur combien de détenteurs l'utilisent activement ou quelle portion est récupérable avec des clés encore disponibles. Un petit nombre de gros soldes et de nombreux petits soldes inactifs pourraient produire le même total. La règle s'applique aux fonds restant dans le pool à l'activation, quelle que soit la manière dont ils y sont arrivés.

Cette conséquence est distincte du plafond d'offre monétaire et des frais réservés pour les récompenses futures. Le traitement par le protocole d'une ancienne version de transaction supprime un chemin de dépense. La règle de réserve tient compte des frais qui peuvent être réémis ultérieurement selon son propre calendrier. La spécification de mise à niveau traite ces changements comme distincts, les transactions de version 4 étant invalides à partir de la hauteur d'activation du réseau principal.

La date limite de Sprout est l’exception à une histoire autrement mesurée en intervalles et en moyennes. Les portefeuilles et les plateformes d’échange peuvent réviser les règles de confirmation, et les revenus miniers varieront selon l’activité. La règle affectant le pool historique est fixée à la hauteur d’activation. Une fois que la chaîne mise à niveau applique la restriction, la disponibilité d’un portefeuille plus récent ne rétablit pas à elle seule la capacité de dépenser un solde qui y reste.

Ce qu’il faut surveiller

• Activation. Le réseau atteignant le bloc 3 543 405 et produisant les blocs suivants selon les nouvelles règles.
• Politiques de dépôt. Les plateformes d’échange publiant de nouveaux seuils de confirmation ou rouvrant les dépôts suspendus.
• Activité d’Orchard. Actions observées par bloc et temps écoulé pendant les périodes de forte activité.
• Revenus miniers. Recettes quotidiennes de frais et revenus de subvention comparés sur des fenêtres équivalentes.
• Sprout. Notices de portefeuille précisant quels soldes historiques étaient éligibles à être déplacés avant l’activation.

FAQ