La feuille de route de Vitalik Buterin pour la confidentialité d’Ethereum

Ethereum dispose depuis longtemps d’outils cryptographiques capables de rendre les transactions privées. Pourtant, dans la pratique, une grande partie des informations des utilisateurs reste exposée : ordre des transactions, requêtes vers les nœuds, ou encore comportement des portefeuilles.

Vitalik Buterin propose donc une feuille de route à court terme pour améliorer concrètement la confidentialité du réseau. L’objectif n’est pas une refonte complète du protocole, mais une série d’améliorations techniques ciblées et déployables rapidement.

Cette stratégie repose sur trois changements clés : renforcer la résistance à la censure lors de l’inclusion des transactions, modifier le système de nonces pour permettre des transactions parallèles, et réduire les fuites de données au niveau des portefeuilles et de l’accès au réseau.

1. Account Abstraction + FOCIL : réduire la censure des transactions

La première étape concerne la façon dont les transactions entrent dans les blocs Ethereum.

Aujourd’hui, les block builders et validateurs ont une influence importante sur les transactions qu’ils incluent dans un bloc. Cela ouvre la porte à des retards ou exclusions — un problème particulièrement sensible pour les transactions privées.

La feuille de route met en avant la combinaison de l’Account Abstraction avec les Fork‑Choice Enforced Inclusion Lists (FOCIL). Ce mécanisme permettrait à des comités de validateurs d’imposer l’inclusion de transactions valides présentes dans le mempool public dans un nombre limité de slots, au lieu de laisser toute la décision à un seul proposeur de bloc.

FOCIL doit devenir l’une des fonctionnalités majeures de la mise à jour réseau Hegota, attendue dans la seconde moitié de 2026. Ce système vise à garantir qu’une transaction respectant les règles du protocole ne puisse pas être facilement ignorée par les builders ou les validateurs.

Pour les systèmes de confidentialité, c’est essentiel : si les acteurs de l’infrastructure peuvent simplement refuser d’inclure certaines transactions, toute protection cryptographique perd une grande partie de son utilité.

2. Les “keyed nonces” (EIP‑8250) pour permettre des transactions parallèles

Ethereum utilise actuellement un nonce unique et linéaire par compte afin d’empêcher les attaques de rejeu et de maintenir l’ordre des transactions.

Ce modèle a toutefois un défaut majeur : si une transaction reste bloquée ou en attente, toutes les suivantes provenant du même compte sont également bloquées.

La proposition EIP‑8250 introduit un système de nonces par clé. Chaque transaction inclurait deux paramètres :

• nonce_key : le domaine de protection contre le rejeu
• nonce_seq : la séquence au sein de ce domaine

Avec ce système, plusieurs flux de transactions peuvent évoluer en parallèle, car chaque clé possède sa propre séquence. Une transaction bloquée n’empêche donc plus les autres d’être exécutées.

Ce changement est particulièrement utile pour les protocoles de confidentialité et les systèmes reposant sur des relayers. Beaucoup d’entre eux regroupent les actions de nombreux utilisateurs dans un même compte, ce qui entre aujourd’hui en conflit avec la file d’attente de nonce unique d’Ethereum.

Les développeurs envisagent également d’intégrer cette amélioration dans la mise à jour Hegota, afin d’aligner l’évolution du modèle de transaction avec d’autres changements structurels du réseau.

3. Confidentialité de la couche d’accès : portefeuilles et lectures privées

La troisième étape s’attaque à un problème souvent sous‑estimé : les fuites de métadonnées provenant des portefeuilles et des fournisseurs RPC.

Même si les transactions deviennent privées, un utilisateur peut révéler beaucoup d’informations simplement en consultant la blockchain — par exemple en vérifiant un solde, en interrogeant un contrat ou en interagissant avec une application. Les opérateurs de nœuds ou les services RPC peuvent observer ces requêtes et en déduire le comportement de l’utilisateur.

La feuille de route insiste donc sur la confidentialité de la couche d’accès, notamment via des infrastructures et des portefeuilles conçus pour limiter ces fuites.

Un exemple est Kohaku, un framework de confidentialité destiné aux portefeuilles Ethereum. L’idée est d’intégrer directement les primitives de confidentialité dans les logiciels de portefeuille, plutôt que de dépendre d’applications spécialisées séparées.

Certaines conceptions utilisent aussi des clients légers intégrés, permettant au portefeuille de vérifier lui‑même les données de la blockchain sans dépendre entièrement de fournisseurs RPC centralisés.

Une stratégie de confidentialité progressive pour Ethereum

Cette feuille de route illustre un changement de stratégie pour Ethereum. Au lieu d’attendre un protocole unique et complet pour la confidentialité, l’écosystème privilégie des améliorations progressives à différents niveaux de la pile technique.

Ces évolutions visent à corriger deux vulnérabilités majeures des blockchains publiques :

• la censure des transactions par certains acteurs de l’infrastructure
• les fuites de métadonnées révélant le comportement des utilisateurs

En améliorant l’inclusion des transactions, en permettant des flux parallèles et en protégeant l’accès aux données au niveau des portefeuilles, Ethereum cherche à transformer la confidentialité en fonctionnalité utilisable par les portefeuilles et les applications grand public.

L’objectif final est un réseau où particuliers et institutions peuvent interagir sans exposer publiquement chaque action — tout en conservant la transparence et la vérifiabilité qui caractérisent les blockchains publiques.

Autrement dit, la confidentialité n’est plus vue comme une fonctionnalité isolée, mais comme une propriété globale du système, couvrant le consensus, le modèle de transaction et l’infrastructure des portefeuilles.