Loading...
Dans le sondage auprès des détenteurs de NU7 qui s'est clôturé le 14 septembre 2026, environ 2 397 669 ZEC ont voté pour ZIP 218 et 141,6 ZEC ont voté contre, soit un résultat de 99,9 %. La plupart des articles l'ont résumé ainsi : « les blocs Zcash deviennent plus rapides ». C'est vrai, mais cela omet l'essentiel de ce que fait la proposition ainsi que l'essentiel de ce qu'elle conserve délibérément à l'identique.
Cette page explique ZIP 218 à partir de son propre texte : ce qui change, ce qui ne change pas et ce que cela coûte.
| Aujourd'hui | Après ZIP 218 | |
|---|---|---|
| Espacement cible des blocs | 75 secondes | 25 secondes |
| Blocs par jour | 1 152 | 3 456 |
| Subvention de bloc (ère de halving actuelle) | 1,5625 ZEC | 0,52083333 ZEC |
| Nouveaux ZEC par jour | inchangé | inchangé |
| Intervalle de halving | 1 680 000 blocs | 5 040 000 blocs |
| Limites d'actions protégées par bloc | aucune (seulement la limite de taille de 2 Mo) | 330 au total, avec des plafonds par pool |
| Débit Orchard (transactions à 2 actions) | environ 2,9 par seconde | environ 6,6 par seconde |
Trois fois plus de blocs, chacun rapportant un tiers autant. Le calendrier d'émission reste inchangé.
L'objectif principal est de réduire le temps d'attente. Aujourd'hui, un paiement attend en moyenne 75 secondes pour sa première confirmation, quelle que soit la charge du réseau. Avec 25 secondes, cette moyenne tombe à 25 secondes. Le ZIP cite les paiements en point de vente, les dépôts sur les plateformes d'échange et les bridges inter-chaînes parmi les usages qui le ressentent le plus.
Deux points du ZIP méritent d'être gardés à l'esprit :
Le ZIP note également qu'un débit supérieur aurait pu être atteint uniquement avec une taille de bloc plus grande. La latence est la raison du choix de blocs plus courts.
Tripler le nombre de blocs triplerait l'émission quotidienne si rien d'autre ne changeait. ZIP 218 l'empêche en divisant la subvention par bloc par un facteur supplémentaire de trois une fois que NU7 est actif.
Dans l'ère de halving actuelle, la subvention de bloc passe ainsi de 1,5625 ZEC à 0,52083333 ZEC (52 083 333 zatoshi). Comme 156 250 000 zatoshi ne se divisent pas exactement par trois, chaque bloc est arrondi à l'inférieur d'un tiers de zatoshi. Sur un intervalle complet de halving de 5 040 000 blocs, cela représente environ 0,0168 ZEC au total.
La subvention est le total des nouveaux ZEC créés par bloc. La part existante destinée au financement du développement continue d'en être prélevée, de sorte que les mineurs reçoivent moins que le montant total, exactement comme aujourd'hui.
Une remarque sur le chiffre de 0,26041666 ZEC. La note explicative du projet de ZIP imprime la subvention post-NU7 comme floor(156250000 / 6) = 0,26041666 ZEC, et certains articles l'ont répétée. Cette note comporte une erreur d'un facteur deux : 156 250 000 zatoshi est déjà la subvention post-Blossom ; la division par six applique donc une seconde fois le facteur deux de Blossom, en plus du facteur trois de NU7. La formule normative donne floor(1,250,000,000 / (2 · 3 · 4)) = 52 083 333 zatoshi à l'indice de halving actuel. Le ticket d'implémentation de Zebra pour cette modification (#11463) indique que la note compte deux fois le facteur Blossom, demande aux implémenteurs d'« implémenter la formule, pas la note », et précise qu'une correction a été déposée concernant le ZIP. Le chiffre correct lors de l'activation est 0,52083333 ZEC.
L'intervalle de halving triple, passant de 1 680 000 blocs à 5 040 000 blocs. Puisque les blocs arrivent trois fois plus souvent, les halvings ont toujours lieu approximativement au même moment qu'ils l'auraient fait sans ce changement. Le plafond total d'approvisionnement n'est pas affecté.
Cela est distinct de l'autre question d'émission du sondage NU7, dans laquelle les détenteurs ont voté pour conserver les halvings plutôt que de les remplacer par une courbe lissée. ZIP 218 fonctionne avec le modèle de halving existant et ne le modifie pas.
ZIP 218 ajoute des plafonds à la quantité d'activité protégée qu'un seul bloc peut contenir :
| Limite | Maximum par bloc |
|---|---|
| Tous les pools protégés combinés | 330 (chaque JoinSplit Sprout compte pour 2) |
| Actions Orchard | 330 |
| Entrées plus sorties Sapling | 300 |
| JoinSplits Sprout | 25 |
Les parties transparentes des transactions ne sont pas affectées, et la limite de taille de bloc de 2 Mo s'applique toujours.
Ces limites existent, car davantage de blocs signifierait autrement davantage de travail pour les wallets et les nœuds. Avec les plafonds en place, le pire cas devient en réalité meilleur qu'aujourd'hui, même avec trois fois plus de blocs :
Les plafonds Sapling et Sprout sont intentionnellement stricts. En mai 2026, Orchard détenait 87,9 % des ZEC protégés, Sapling 11,6 % et Sprout 0,5 % ; les pools plus petits disposent donc de suffisamment d'espace pour leur utilisation réelle tout en offrant moins de possibilités d'abus à un attaquant. Comme les frais de ZIP 317 facturent le même montant par action logique dans chaque pool, un attaquant ne gagne rien à saturer un pool plutôt qu'un autre.
Avec 330 actions Orchard par bloc, une transaction Orchard standard à 2 actions peut tenir ⌊330 / 2⌋ = 165 fois par bloc. Avec un bloc toutes les 25 secondes, cela représente environ 6,6 transactions par seconde, contre environ 2,9 aujourd'hui — le ZIP qualifie cela d'augmentation de 2,3× du débit normal de Orchard. Sapling atteint environ 3,0 par seconde, toujours au-dessus de ce que Orchard gère aujourd'hui.
L'algorithme de difficulté calcule une moyenne sur une fenêtre de blocs récents. ZIP 218 fait passer cette fenêtre de 17 à 102 blocs, de sorte qu'elle couvre toujours environ 2 550 secondes de temps réel, soit la même durée qu'elle couvrait lorsque Zcash a été lancé avec des blocs de 150 secondes. Le ZIP donne deux raisons : éviter de faciliter les attaques de manipulation de la difficulté (il cite l'incident MWEB de Litecoin en avril 2026), et lisser les variations à court terme des temps de bloc.
Juste après l'activation, les temps de bloc mettront un certain temps à se stabiliser sur la nouvelle cible. C'est attendu et cela reflète ce qui s'est produit lors de Blossom, quand Zcash est passé de 150 à 75 secondes.
Il s'agit de recommandations destinées aux implémentations plutôt que de règles de consensus :
Des blocs plus rapides ne sont pas gratuits. Un bloc obsolète est un bloc valide qui perd la course pour être inclus dans la chaîne parce qu'un autre bloc a atteint le réseau en premier. Plus l'écart entre les blocs est court, plus cela se produit souvent, et le ZIP relie le taux de blocs obsolètes à la propagation des blocs, au temps de vérification et au risque de centralisation du minage.
Il existe aussi deux coûts plus modestes. Les wallets légers téléchargent environ 200 Ko supplémentaires par jour d'en-têtes de blocs compacts. Et, comme il y a trois fois plus de blocs, un nœud complet qui a été hors ligne a davantage de blocs à traiter lorsqu'il se remet à jour, même si chaque bloc est moins coûteux à vérifier. Le ZIP accepte les deux.