Compte natif abstrait + résistance aux menaces quantiques : pourquoi l'EIP-8141 n'est-il pas encore la vedette d'Ethereum Hegotá ?

La semaine dernière, lors de la réunion officielle des développeurs principaux d’Ethereum, il a été discuté en bonne et due forme de savoir si l’EIP-8141 devait être intégré à la mise à niveau de Hegota. Le résultat a été surprenant : cette proposition, soutenue personnellement par Vitalik, n’a pas été classée comme « fonctionnalité vedette » de Hegota, mais a obtenu le statut « envisagé pour inclusion » (CFI).

Et cette semaine, l’équipe Google Quantum AI a publié son dernier livre blanc, indiquant qu’avec ses hypothèses matérielles données, l’estimation de la quantité de qubits quantiques physiques nécessaires pour résoudre l’ECDLP-256 a fortement diminué, de 20 fois par rapport à auparavant. Même si cela ne signifie pas que l’attaque quantique est imminente, cela nous rappelle bel et bien, si à l’avenir le système de comptes ne peut pas changer de manière flexible la logique de validation, alors une grande partie des discussions d’aujourd’hui sur l’expérience des wallets peut au final se transformer en problèmes de sécurité.

Du point de vue réaliste de l’avancement du protocole, l’EIP-8141 est pour l’instant encore trop lourd, notamment en ce qui concerne l’implémentation côté client, la sécurité du pool de transactions et la complexité de la validation : il n’existe pas encore de consensus suffisamment solide.

Mais au niveau de ce moment précis, les raisons pour lesquelles l’EIP-8141 mérite d’être discuté et examiné sérieusement semblent, en fait, de plus en plus nombreuses.

I. Que cherche exactement à résoudre l’EIP-8141 ?

L’EIP-8141 est porté par Vitalik Buterin et d’autres contributeurs majeurs, dont timbeiko, et son nom officiel est Frame Transactions（transactions de trame）。

Si on le résume en une phrase plus facile à comprendre, l’objectif n’est pas d’ajouter séparément une certaine fonctionnalité au wallet. Il s’agit plutôt d’essayer, au niveau du protocole, d’éviter que n’importe quel compte soit limité par un unique chemin de signature ECDSA, et de permettre des logiques de validation et d’exécution plus flexibles.

Cela signifie aussi que les multi-signatures, le parrainage de Gas, la rotation des clés, la récupération sociale, et même, à l’avenir, l’intégration de solutions de signatures résistantes aux attaques quantiques, ne seront plus seulement des capacités « ajoutées » en périphérie du wallet. Elles auront la possibilité de devenir des « composants natifs » du système de comptes d’Ethereum.

Si l’on ne regarde que la surface, la discussion autour de l’EIP-8141 porte sur un ensemble de capacités assez concrètes : payer le Gas avec des stablecoins, fusionner des opérations en plusieurs étapes en une seule transaction, prendre en charge des méthodes de signature plus flexibles, et même réserver de l’espace pour les signatures post-quantiques à l’avenir. On peut dire que, pendant des années, de l’ERC-4337 à l’EIP-7702, de nombreuses améliorations autour de l’expérience wallet visent essentiellement à faire en sorte qu’un compte ne soit plus seulement une clé privée, mais un point d’entrée où l’on peut définir des règles.

Le problème, c’est que, même si ces améliorations rendent bien le wallet de plus en plus proche d’un compte intelligent, elles n’ont jamais touché vraiment le modèle de compte par défaut, tout au bas de la pile d’Ethereum.

Comme on le sait, dans le système actuel, les comptes Ethereum se répartissent globalement en deux catégories. Une catégorie correspond aux comptes appartenant à l’extérieur, c’est-à-dire les EOA, ceux que tout le monde connaît le mieux : ils sont contrôlés par une clé privée, peuvent initier des transactions activement, mais manquent de capacités programmables. L’autre catégorie est celle des comptes de contrat, c’est-à-dire les contrats intelligents eux-mêmes : ils peuvent exécuter une logique complexe, mais ne peuvent pas initier eux-mêmes des transactions.

Cela conduit à ce que la capacité d’initier des transactions soit liée, durablement, à une signature par une seule clé privée. Tant que ce prérequis reste identique, de nombreuses capacités que beaucoup d’utilisateurs jugent aujourd’hui « évidentes », comme changer de façon flexible les règles de signature, faire payer le Gas par quelqu’un d’autre, récupérer le contrôle du compte après la perte de la clé privée, ou encore migrer en douceur vers un nouveau système de mots de passe à l’avenir, restent difficiles à devenir de véritables capacités par défaut du compte.

Si vous avez déjà utilisé imToken ou un autre wallet Web3, vous avez très probablement rencontré ces douleurs : il y a une pile de USDC dans le wallet, mais sans ETH vous ne pouvez pas émettre de transaction (car le Gas ne peut être payé qu’avec ETH) ; perdre la phrase mnémonique, c’est perdre définitivement l’argent, sans possibilité de récupération ; une opération « autorisation + échange » doit être signée deux fois, confirmée deux fois, etc.

Ces problèmes ne viennent pas d’un wallet « pas assez bon » ; ils sont le résultat du design du modèle de comptes d’Ethereum lui-même.

À partir de ce point de vue, l’évolution des deux dernières années est en réalité très claire : avec l’ERC-4337, sans modifier le protocole, l’abstraction de compte a été lancée d’abord au niveau de l’application ; puis l’EIP-7702 a encore démontré que les EOA ne sont pas complètement impossibles à étendre : au moins temporairement, elles peuvent obtenir une partie des capacités proches d’un compte intelligent.

Autrement dit, Ethereum ne refuse pas l’abstraction de compte : il la poursuit depuis toujours avec une approche plus douce et plus prudente, en s’approchant progressivement de la question. Et l’apparition de l’EIP-8141 signifie que cette voie atteint un nouveau jalon. Elle ne se contente plus d’ajouter une couche de capacité de compte intelligent à l’extérieur du système existant ; elle vise plutôt à intégrer directement l’abstraction de compte dans le modèle de transaction lui-même, pour que le compte, dès le niveau du protocole, dispose de logiques de validation et d’exécution programmables.

C’est aussi pourquoi l’EIP-8141 revient aujourd’hui sous les feux des projecteurs. D’un côté, l’expérience wallet côté couche supérieure ressemble de plus en plus à une abstraction native de compte, et tôt ou tard la couche protocole doit suivre ; de l’autre, la pression de long terme apportée par l’informatique quantique fait aussi que la question de savoir si le compte peut changer de manière flexible la méthode de signature, qui était autrefois un sujet technique lointain, devient en avance un problème concret qu’il faut sérieusement considérer.

II. Comment fonctionne l’EIP-8141 ?

Au final, l’EIP-8141 introduit un tout nouveau type de transaction : la frame transaction (transaction de trame), dont l’identifiant de type de transaction est 0x06.

Si la logique de base des transactions Ethereum traditionnelles consiste à ce qu’une transaction corresponde à un seul appel, alors ce que veut faire l’EIP-8141, c’est décomposer une transaction en un ensemble de « trames » exécutées dans un ordre défini par des règles, afin de séparer de façon distincte ce qui était auparavant « attaché » ensemble : validation, paiement et exécution.

Chaque « trame » a trois modes d’exécution :

• VERIFY（frame de validation） : responsable de vérifier si la transaction est valide. Elle exécute la logique de validation définie par le compte. Si elle réussit, elle appelle le nouvel opcode APPROVE pour autoriser l’exécution et spécifier une limite de Gas.
• SENDER（frame d’envoi） : exécute l’opération réelle, comme un transfert, un appel de contrat, etc. L’adresse de l’appelant est l’expéditeur de la transaction lui-même.
• DEFAULT（frame d’entrée） : utilise l’adresse d’entrée du système comme appelant, utile pour des scénarios comme le déploiement de contrats, la validation de Paymaster, etc. ;

Le sens de ce mécanisme n’est pas que la transaction puisse devenir « plus complexe ». C’est plutôt la première fois que les trois choses « validation, paiement, exécution » sont séparées des actions du compte, puis déléguées à une planification native du protocole.

Après tout, avant, qui valide la transaction, qui paie le Gas et qui exécute la véritable opération étaient globalement tous liés à la même action du compte. Et dans le design de l’EIP-8141, ces éléments peuvent être séparés en différentes trames, que le protocole exécute ensuite dans un ordre clair. C’est précisément pour cela que le compte ne dépend plus seulement d’une unique signature de clé privée pour « signer l’ensemble », et commence à prendre une forme plus proche d’un acteur d’exécution programmable.

Prenons un exemple concret : supposons que vous vouliez utiliser USDC pour payer le Gas afin de réaliser un Swap. Dans le cadre de l’EIP-8141, en théorie, cela peut être organisé comme un processus de trames complet : d’abord, le compte vérifie la signature et les droits d’exécution ; ensuite, le payeur ou le Paymaster vérifie ses propres conditions selon lesquelles il accepte de prendre en charge les frais ; puis, le paiement des frais pour les actifs correspondants est effectué ; enfin, l’opération de swap elle-même est exécutée.

De cette manière, le paiement du Gas et la transaction principale peuvent être inclus dans le même flux atomique : soit tout réussit, soit tout est rollback.

Pour les utilisateurs, le changement le plus direct est que de nombreuses opérations qui auparavant devaient être décomposées en deux ou trois étapes et comportaient un risque d’échec au milieu peuvent désormais ressembler à une seule action complète. Cette atomicité fait donc partie des points clés que l’EIP-8141 vise à résoudre : la fragmentation de l’expérience utilisateur.

Alors qu’est-ce que cela signifie pour les utilisateurs de wallets ? En termes de résultats, le changement le plus direct correspond à au moins quatre couches :

• Le paiement du Gas est abstrait : avoir des stablecoins dans le wallet ne signifie plus qu’il faille aussi préparer un peu d’ETH supplémentaire. À l’avenir, le paiement du Gas par un DApp, un Paymaster ou un autre sponsor deviendra plus natif ;
• Les opérations en plusieurs étapes sont fusionnées : des processus comme « autorisation + Swap » ou « autorisation + staking », qui nécessitent souvent plusieurs signatures aujourd’hui, ont une chance d’être regroupés en une action plus complète ;
• Les règles de sécurité du compte sont ouvertes : multi-signature, récupération sociale, limites quotidiennes, verrous temporels, rotation des clés : tout cela ne sera plus seulement des fonctionnalités avancées ajoutées par un produit wallet. Cela a une chance de s’appuyer sur une logique de compte plus native ;
• Le schéma de signature n’est plus nécessairement verrouillé sur un chemin unique ECDSA : cela permet, pour l’avenir, aux comptes de migrer vers différents systèmes de mots de passe, y compris vers des schémas de signature post-quantiques ; pour la première fois, il existe une possibilité qui a une signification au niveau du protocole ;

III. Pourquoi cela n’est pas devenu la vitrine de Hegotá ?

Un point facile à négliger, mais crucial pour les utilisateurs de wallets, est le suivant : même si l’EIP-8141 est finalement déployée, le système de comptes actuel ne sera pas pour autant renversé dans son ensemble.

Même si vous utilisez aujourd’hui déjà un wallet Web3 existant comme imToken, vous n’avez pas besoin de migrer. C’est rétrocompatible : les adresses EOA existantes peuvent continuer à être utilisées, et il suffit de choisir, au moment opportun, la logique de validation « mise à niveau » du compte.

Mais justement, c’est aussi parce qu’elle modifie assez profondément les choses qu’elle n’est pas devenue directement une fonctionnalité vedette de Hegotá dans la discussion la plus récente. Or, selon le processus de champion EIP pour 2026, le sens de CFI（Considered for Inclusion, envisagé pour inclusion） n’est pas une négation : cela signifie simplement qu’on entre dans une phase de considération sérieuse. Cela ne veut pas encore dire qu’on a atteint le moment du choix final pour un déploiement.

En d’autres termes, les développeurs principaux ne sont pas en désaccord avec l’orientation de l’EIP-8141. Au contraire : tout en reconnaissant sa valeur, ils considèrent aussi qu’elle est pour l’instant encore trop « lourde ».

Après tout, contrairement à l’ERC-4337, l’abstraction native de compte ne peut pas être poussée progressivement d’abord par quelques wallets, infrastructures et applications. Une fois qu’elle entre dans la couche protocole, cela signifie que tous les clients de la couche d’exécution devront sérieusement reconnaître, tester et coordonner l’ensemble ; cela augmente naturellement le seuil d’avancement. Cela rend aussi les développeurs principaux plus enclins à privilégier la prudence lors de la planification d’un fork.

Que se passera-t-il ensuite ? On peut voir cela en deux lignes :

• Puisque l’EIP-8141 est en statut CFI, cela indique qu’elle fait toujours l’objet d’une évaluation continue. Les auteurs de la proposition continueront à combler les détails clés autour de la sécurité du pool de transactions, des règles de validation et de l’implémentation côté clients. Par la suite, lors de la réunion ACD, on réexaminera si elle remplit les conditions pour un avancement supplémentaire ;
• Si ces incertitudes peuvent être réduites de manière continue, elle aura la possibilité d’entrer dans une phase d’inclusion plus concrète lors des prochaines mises à niveau. Si ce n’est pas le cas, elle pourrait aussi être purement et simplement reportée vers une période de mise à niveau plus tardive ;

Dit franchement, l’EIP-8141 n’est pas la seule proposition d’abstraction de compte native. Et ce n’est pas, en soi, une sorte de proposition préexistante de signature post-quantique permettant de résoudre directement le problème du calcul quantique. Mais son importance tient au fait qu’elle offre pour la première fois, du point de vue du protocole, une sortie qui permet de se libérer du chemin unique ECDSA pour le compte.

À partir de ce point de vue, la vraie valeur de l’EIP-8141 ne réside pas dans le fait qu’elle soit la seule bonne réponse, mais dans le fait qu’elle met pour la première fois, de manière très complète, sur la table des discussions du protocole Ethereum la question de savoir à quoi devrait ressembler, au final, « l’abstraction native de compte ».

Ce n’est pas la seule solution, mais c’est bien l’une des propositions les plus ambitieuses et les plus proches de la limite d’imagination pour un « AA natif complet ».

Qu’elle puisse ou non rattraper Hegotá, cette discussion démontre au moins une chose :

Ethereum n’est pas resté immobile à attendre que les problèmes mûrissent sur place. Il trace plutôt, pas à pas, une voie pour le système de comptes de la prochaine génération.