EIP-8250 d’Ethereum : des nonces à clé pour désengorger la confidentialité

Le changement technique, en clair

Dans Ethereum, un nonce sert notamment à empêcher le rejeu d’une transaction : une même transaction ne doit pas pouvoir être réutilisée indéfiniment. Le modèle actuel des transactions « frame » repose sur un nonce linéaire par expéditeur. Si une transaction reste bloquée, les transactions suivantes du même expéditeur peuvent se retrouver coincées derrière elle ^[1].

EIP-8250 propose de remplacer cette file unique par deux champs :

• nonce_key : la clé qui choisit le domaine de protection contre le rejeu ;
• nonce_seq : le numéro de séquence à l’intérieur de ce domaine.

Le détail important est la compatibilité. Si

nonce_key == 0

[1]

Autrement dit, EIP-8250 transforme une file d’attente unique en plusieurs files indexées par clé. Les transactions utilisant des clés non nulles différentes sont indépendantes du point de vue du rejeu, mais l’ordre continue d’exister à l’intérieur de chaque clé ^[1]. Ce n’est donc pas une refonte générale de l’exécution Ethereum : c’est une modification précise du mécanisme de nonce pour un type de transaction donné.

Pourquoi les protocoles de confidentialité s’y intéressent

Le problème apparaît surtout lorsque de nombreux utilisateurs sans lien entre eux passent par une même adresse d’envoi. ETH Daily présente EIP-8250 comme particulièrement utile pour les protocoles de confidentialité, justement parce que ces systèmes peuvent router plusieurs utilisateurs indépendants via un expéditeur partagé ^[12].

Avec un seul nonce linéaire, un retard sur une transaction peut créer un blocage en tête de file : tout ce qui vient après attend, même si les opérations concernent des utilisateurs ou des flux sans rapport ^[1][12].

Avec des nonces à clé, un protocole pourrait répartir ces flux sur plusieurs clés non nulles. Un flux retardé ne bloquerait pas nécessairement tous les autres flux passant par le même expéditeur partagé ^[1][12]. La logique reste toutefois une logique de sécurité : il ne s’agit pas de supprimer les contrôles de rejeu, mais de donner à chaque clé sa propre séquence ^[1].

Confidentialité : ce que les nonces à clé ne font pas

Il faut être net : EIP-8250 ne masque pas, à lui seul, les soldes, les destinataires ou les montants. Pour obtenir des transferts privés, il faut d’autres briques.

Un autre texte, EIP-8182, décrit par exemple des transferts privés d’ETH et de jetons ERC-20 à l’aide d’un contrat système, d’un précompilé de vérification de preuves, de notes, de dépôts, de transferts privés et de retraits ^[9]. C’est ce type de mécanique supplémentaire qui permettrait de construire de vraies transactions privées.

EIP-8250 joue donc plutôt sur l’infrastructure : il peut faciliter le passage à l’échelle de systèmes de confidentialité, mais il ne rend pas les transactions confidentielles par simple ajout d’un champ de nonce.

Le sujet de fond : les nullifiers et la taille de l’état

La partie la plus ambitieuse du débat concerne l’état d’Ethereum, c’est-à-dire l’ensemble des données que le réseau doit conserver et vérifier. Plusieurs articles rapportant les commentaires de Vitalik Buterin relient les nonces à clé à une stratégie plus large : créer des formes de stockage spécialisées pour certains usages au lieu de tout mettre dans l’état dynamique général d’Ethereum ^[4][5][10].

L’exemple souvent cité est celui des nullifiers dans les systèmes de confidentialité. Un nullifier est un marqueur qui permet d’empêcher la réutilisation d’un état privé. Une fois entré dans le système, il doit rester vérifiable ; il ne peut donc pas être simplement supprimé ou élagué comme une donnée temporaire ^[4][5].

Les ordres de grandeur avancés dans les rapports sont volontairement extrêmes : si les transactions privées on-chain atteignaient 2 000 transactions par seconde pendant huit ans, cela produirait environ 500 milliards de nullifiers ^[2][5][7]. Ce chiffre doit être lu comme un scénario de stress test, pas comme une promesse qu’Ethereum stockera effectivement 500 milliards de tels enregistrements, ni comme une preuve qu’EIP-8250 sera activée telle quelle.

Pourquoi un stockage spécialisé pourrait aider

L’argument est simple : toutes les données n’ont pas besoin du même modèle de stockage. Les nullifiers, par exemple, sont des données à usage étroit. Elles doivent être consultables pour éviter les doubles utilisations, mais elles n’ont pas besoin de toute la flexibilité d’un stockage de contrat arbitraire.

Certains rapports décrivent donc l’idée d’un magasin dédié aux nullifiers, avec des techniques comme le sharding et les filtres de Bloom pour rendre de très grands ensembles de données plus faciles à gérer pour les nœuds ^[2][14]. L’objectif serait de réduire la pression sur l’état général d’Ethereum tout en conservant la décentralisation du protocole ^[5][10].

C’est ce qui donne à EIP-8250 une portée plus large que son mécanisme immédiat. La proposition porte sur des voies de nonce indépendantes pour les transactions « frame », mais elle s’inscrit dans une direction architecturale : confier certains workloads prévisibles et massifs à des structures gérées par le protocole, au lieu de tout traiter comme du stockage généraliste ^[1][4][10].

Ce que EIP-8250 pourrait améliorer

• Le débit des expéditeurs partagés. Les protocoles de confidentialité qui font passer de nombreux utilisateurs par une même adresse pourraient éviter qu’un seul nonce bloqué ralentisse tous les flux ^[1][12].
• L’isolation contre le rejeu. Des clés non nulles différentes correspondraient à des domaines de rejeu indépendants ^[1].
• Le support protocolaire de la confidentialité. Des rapports indiquent que Vitalik Buterin a présenté les nonces à clé comme un meilleur soutien de niveau protocole pour les solutions de confidentialité on-chain ^[4][5].
• Une piste pour le scaling de l’état. Le même débat ouvre la voie à des structures de stockage spécialisées, adaptées à des usages très volumineux mais bien délimités ^[5][10].

Ce qu’il ne faut pas lui attribuer

• EIP-8250 ne remplace pas tous les nonces Ethereum. Le périmètre indiqué concerne les transactions « frame » d’EIP-8141, et la clé 0 conserve le chemin du nonce de compte classique ^[1].
• EIP-8250 ne rend pas les transferts privés par elle-même. Les systèmes de transferts privés ont toujours besoin de mécanismes séparés, comme les notes, la vérification de preuves, les dépôts, les règles de transfert et les retraits décrits dans EIP-8182 ^[9].
• Le chiffre de 500 milliards n’est pas un plan d’activation. Il provient d’exemples fondés sur 2 000 transactions privées par seconde pendant huit ans ^[2][5][7].
• La proposition n’est pas un comportement déjà actif du protocole. La source technique principale disponible ici est une discussion Ethereum Magicians liée à une pull request d’EIP ; les détails peuvent donc encore évoluer ^[1].

En résumé

EIP-8250 est d’abord une proposition de protection contre le rejeu : au lieu d’une file de nonces unique pour certaines transactions, elle introduirait plusieurs voies indexées par clé. Son intérêt pour la confidentialité vient surtout de ce que ces voies peuvent réduire les blocages lorsqu’un protocole fait passer de nombreux utilisateurs par un même expéditeur ^[1][12].

Sa portée potentielle est plus large : si Ethereum parvient à créer des structures spécialisées pour des données massives et difficiles à supprimer, comme les nullifiers, les systèmes de confidentialité pourraient mieux monter en charge sans tout déverser dans l’état général du réseau ^[4][5].