L'EIP-8141 d'Ethereum semble tracer une nouvelle voie, alors que Vitalik Buterin, cofondateur d'Ethereum, fait avancer cette proposition comme un moyen d'améliorer l'efficacité grâce à des transactions extensibles sur le réseau.

Dans son principe, la proposition sépare les exigences d'approbation d'une transaction des processus réels que celle-ci exécute. Buterin estime que cette approche pourrait permettre à Ethereum de traiter les transactions courantes de manière plus efficace sans compromettre sa flexibilité. Il l'a présentée comme l'une des stratégies destinées à améliorer l'extensibilité d'Ethereum tout en préservant la décentralisation. Cet effort s'inscrit dans une longue lignée de travaux sur le protocole : le parcours de mise à niveau d'Ethereum a traversé des étapes telles que la Fusion de 2022 vers la preuve d'enjeu, puis les hard forks « Dencun » et « Pectra », l'extensibilité et la réduction des coûts de transaction restant des priorités constantes de la feuille de route du réseau.

Dans une publication sur X datée du 5 septembre 2026, Buterin a écrit :

One positive consequence of all the recent detailed thinking about transaction formats – not just 8141, also "future of state" discussions eg. UTXOs, PBT, keyed nonces, and also recursive STARK mempool – is that we have a much more explicit understanding of how transactions have…

— vitalik.eth (@VitalikButerin) September 5, 2026 (https://x.com/VitalikButerin/status/2096378061377900881)

L'EIP-8141 sépare les dépendances des actions dans les transactions

Buterin divise le processus d'exécution d'une transaction en deux composantes principales : les dépendances et les actions.

Les dépendances sont les exigences qui doivent être satisfaites pour qu'une transaction soit considérée comme valide. Elles comprennent la signature des transactions, la preuve via un arbre de Merkle, l'utilisation de ZK-SNARKs ou de STARKs, ainsi que d'autres vérifications.

Les actions sont les opérations effectuées une fois toutes les conditions préalables vérifiées. Elles incluent l'envoi d'ETH, l'appel de contrats intelligents et la modification d'informations sur la blockchain.

Avec la méthode de l'EIP-8141, certaines vérifications de dépendances pourraient être exécutées en parallèle plutôt que d'obliger chaque client à traiter chaque vérification de manière séquentielle. D'autres vérifications de dépendances pourraient même être effectuées pendant que la transaction se trouve dans le mempool, avant son inclusion dans un bloc.

Les dépendances d'état restent plus complexes, car des transactions antérieures peuvent modifier les soldes et d'autres données de la blockchain. Toutefois, les mempools pourraient gérer ces vérifications plus efficacement si les transactions précisaient l'état dont elles dépendent.

Buterin estime que plus de 90 % des transactions sur le réseau Ethereum n'ont pas besoin d'une flexibilité d'exécution complète. Il a précisé que ce chiffre est une estimation personnelle et non une mesure du réseau.

Un design de Frame Transaction

L'EIP-8141 introduit un nouveau type de transaction appelé Frame Transaction. Le design du cadre sépare les appels de contrats consacrés aux autorisations, au paiement des frais et aux opérations utilisateur.

Ce design permettrait au code du compte d'autoriser une transaction et de payer les frais, au lieu de s'appuyer sur le mécanisme de signature traditionnel. Parmi les fonctionnalités potentielles de ce cadre figurent le parrainage des frais, le paiement des frais en jetons, la rotation des clés et les transactions groupées. Ces capacités font écho aux objectifs longtemps associés à l'abstraction de comptes, un thème de conception qu'Ethereum a déjà exploré via des efforts distincts comme l'EIP-4337, qui a introduit un mempool pour les « UserOperations » sans modifier le protocole principal ; l'EIP-8141 agit quant à elle directement au niveau du format transactionnel.

La vérification constituerait la première étape, déterminant si la transaction est authentifiée. Ensuite, d'autres frames pourraient prendre en charge le paiement des frais et l'exécution des actions spécifiées.

Le format proposé est relativement simple, reposant sur des appels de contrats, des indicateurs (flags), l'origine et des informations de nonce. Ce même format pourrait également être adopté par d'autres réseaux construits sur le modèle EVM.

Des questions en suspens subsistent

L'EIP-8141 en est encore au stade de brouillon en tant que proposition Core, ce qui signifie que tout aspect de sa technologie pourrait évoluer au cours du développement. Les propositions d'amélioration d'Ethereum au stade de brouillon doivent être examinées par les développeurs principaux d'Ethereum et être intégrées à une future mise à niveau du réseau avant activation, un processus qui prend historiquement de plusieurs mois à plusieurs années et peut conduire à des révisions voire à l'abandon complet des propositions. L'architecture actuelle couvre l'entrée dans le mempool, l'exécution des frames, les reçus, les signatures, le gaz et la propagation des transactions. Les développeurs travaillent sur les questions de déni de service, le remplacement des transactions, la modification des portefeuilles, la construction des blocs et les RPC.

Une autre question ouverte concerne le nombre maximal de Frame Transactions pouvant être reçues d'un même expéditeur. Des doutes ont été exprimés quant aux conséquences possibles de cette limite pour les utilisateurs qui doivent effectuer plusieurs transactions au sein d'un même bloc.

Ces questions montrent que l'EIP-8141 doit encore surmonter des obstacles techniques avant de pouvoir faire partie du protocole Ethereum.

Du point de vue de Buterin, la proposition relie l'abstraction de comptes aux futurs plans d'extensibilité d'Ethereum. L'EIP-8141 ne remplace pas les comptes Ethereum ; elle rend les modèles de transactions prévisibles. Si le développement se poursuit, la proposition pourrait jouer un rôle central dans la stratégie d'Ethereum en matière d'extensibilité, d'abstraction de comptes et d'amélioration de l'efficacité des transactions.