Rédigé par : imToken
La semaine dernière, la proposition EIP-8141 a été officiellement discutée lors de la réunion des développeurs principaux d'Ethereum pour déterminer si elle serait incluse dans la mise à jour Hegota. Le résultat a été surprenant : cette proposition, soutenue personnellement par Vitalik, n'a pas été désignée comme la « fonctionnalité phare » de Hegota, mais a plutôt obtenu le statut « Considered for Inclusion » (CFI).
Et cette semaine, l'équipe Google Quantum AI a publié un nouveau livre blanc, indiquant que, selon ses hypothèses matérielles données, l'estimation des qubits physiques nécessaires pour casser ECDLP-256 avait été réduite de manière significative, par un facteur de 20, par rapport aux estimations précédentes. Bien que cela ne signifie pas qu'une attaque quantique soit imminente, cela nous rappelle réellement que si le système de compte ne peut pas changer flexiblement la logique de validation à l'avenir, alors beaucoup de discussions actuelles sur l'expérience du portefeuille pourraient finalement se transformer en problèmes de sécurité.
Bien que, d'un point de vue réaliste de l'avancement du protocole, l'EIP-8141 soit encore trop lourd, en particulier en ce qui concerne la mise en œuvre du client, la sécurité du pool de transactions et la complexité de la validation, pour lesquelles un consensus suffisamment solide n'a pas encore été formé.
Mais à ce stade, les aspects de l'EIP-8141 qui méritent d'être discutés et examinés sérieusement semblent vraiment de plus en plus nombreux.
I. Que cherche à résoudre exactement l'EIP-8141 ?
L'EIP-8141 est porté par Vitalik Buterin, timbeiko et d'autres contributeurs clés, et son nom officiel est Frame Transactions (transactions tramées).
Pour le résumer en une phrase plus compréhensible, son objectif n'est pas d'ajouter une fonctionnalité spécifique de portefeuille, mais plutôt de tenter, au niveau du protocole, de libérer tout compte de l'obligation d'utiliser uniquement le chemin de signature ECDSA, en lui permettant d'avoir une logique de validation et d'exécution plus flexible.
Cela signifie également que la multisignature, le parrainage de Gas, la rotation des clés, la récupération sociale, et même l'intégration future de schémas de signature post-quantiques, ne seront plus seulement des capacités externes greffées au portefeuille, mais auront la possibilité de devenir des « membres natifs » du système de compte d'Ethereum.
Si l'on ne regarde que la surface, l'EIP-8141 discute d'un ensemble de capacités très concrètes : payer le Gas avec des stablecoins, regrouper des opérations multiples en une seule transaction, supporter des méthodes de signature plus flexibles, et même prévoir un espace pour de futurs schémas de signature post-quantiques. On peut dire que, pendant des années, de l'ERC-4337 à l'EIP-7702, de nombreuses améliorations autour de l'expérience du portefeuille ont essentiellement visé à faire en sorte qu'un compte ne soit plus seulement une clé privée, mais une entrée avec des règles personnalisables.
Le problème est que ces améliorations ont certes rendu les portefeuilles de plus en plus proches des comptes intelligents, mais n'ont jamais vraiment touché le modèle de compte par défaut le plus fondamental d'Ethereum.
Comme on le sait, dans le système actuel, les comptes Ethereum sont globalement divisés en deux catégories. La première est le compte détenu à l'extérieur (Externally Owned Account - EOA), celui que tout le monde connaît, contrôlé par une clé privée, pouvant initier des transactions activement, mais manquant de capacités de programmation. L'autre est le compte de contrat, c'est-à-dire le smart contract lui-même, qui peut exécuter une logique complexe, mais ne peut pas initier de transaction de lui-même.
Cela entraîne le fait que la capacité à initier une transaction et la signature par une seule clé privée sont longtemps restées liées. Tant que cette prémisse ne change pas, de nombreuses capacités que les utilisateurs considèrent aujourd'hui comme allant de soi, comme changer flexiblement les règles de signature, faire payer le Gas par quelqu'un d'autre, récupérer le contrôle d'un compte après avoir perdu sa clé privée, ou migrer en douceur vers un nouveau système cryptographique à l'avenir, auront du mal à devenir de véritables capacités par défaut du compte.
Si vous avez utilisé imToken ou d'autres portefeuilles Web3, vous avez probablement aussi rencontré ces points douloureux, par exemple avoir une pile d'USDC dans son portefeuille mais ne pas pouvoir émettre de transaction sans ETH (car le Gas ne peut être payé qu'en ETH) ; perdre sa phrase de récupération signifie perdre définitivement son argent, sans possibilité de récupération ; une opération « autoriser + échanger » nécessite deux signatures, deux confirmations, etc.
Ces problèmes ne sont pas dus au fait que les produits portefeuille ne sont « pas assez bons », mais sont le résultat de la conception même du modèle de compte d'Ethereum.
Sous cet angle, l'évolution des deux dernières années est en réalité très claire : l'ERC-4337 a fait fonctionner l'abstraction de compte au niveau applicatif sans modifier le protocole ; l'EIP-7702 a en outre prouvé que les EOA n'étaient pas totalement incapables de s'étendre, pouvant au moins acquérir temporairement des capacités proches de celles des comptes intelligents.
Autrement dit, Ethereum ne refuse pas de faire de l'abstraction de compte, mais a toujours utilisé des moyens plus doux et plus conservateurs pour s'en approcher progressivement. L'apparition de l'EIP-8141 signifie que cette voie atteint un nouveau stade. Il ne se contente plus d'ajouter une couche de capacités de compte intelligent en périphérie du système existant, mais tente d'intégrer directement l'abstraction de compte dans le modèle de transaction lui-même, permettant aux comptes d'avoir, dès la couche protocole, une logique de validation et d'exécution programmable.
C'est aussi pourquoi l'EIP-8141 regagne en pertinence aujourd'hui. D'une part, l'expérience des portefeuilles de niveau supérieur se rapproche de plus en plus de l'abstraction de compte native, et la couche de protocole devra tôt ou tard suivre ; d'autre part, la pression à long terme exercée par l'informatique quantique transforme également la question « un compte peut-il changer flexiblement sa méthode de signature ? » d'un sujet technique lointain en un problème réel qui doit être sérieusement considéré.
II. Comment fonctionne l'EIP-8141 ?
En fin de compte, l'EIP-8141 introduit un tout nouveau type de transaction – la transaction tramée (Frame Transaction), avec le numéro de type de transaction 0x06.
Si la logique de base d'une transaction Ethereum traditionnelle est qu'une transaction correspond à un appel, alors ce que l'EIP-8141 cherche à faire, c'est de décomposer une transaction en un ensemble de « trames » (frames) qui peuvent être exécutées séquentiellement selon des règles, séparant ainsi la validation, le paiement et l'exécution qui étaient auparavant liés ensemble.
Chaque « trame » a trois modes d'exécution :
- VERIFY (Trame de validation) : Responsable de vérifier si la transaction est légale. Elle exécute la logique de validation personnalisée du compte. Si elle réussit, elle appelle le nouvel opcode APPROVE pour autoriser l'exécution et spécifier la limite de Gas.
- SENDER (Trame 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 (Trame d'entrée) : Utilise l'adresse d'entrée système comme appelant, pour des scénarios comme le déploiement de contrats, la validation du Paymaster, etc. ;
La signification de ce mécanisme n'est pas de rendre les transactions plus complexes, mais de séparer pour la première fois les trois actions « validation, paiement, exécution » des actions du compte et de les confier à la planification native du protocole.
Après tout, par le passé, qui valide la transaction, qui paie le Gas, qui exécute l'opération réelle, étaient essentiellement liés dans la même action de compte. Dans la conception de l'EIP-8141, ces actions peuvent être divisées en différentes trames, exécutées séquentiellement par le protocole dans un ordre clair. C'est précisément pour cette raison que le compte n'est plus obligé de s'appuyer sur une seule clé privée pour « signer globalement », mais commence à acquérir une forme plus proche d'un sujet d'exécution programmable.
Prenons un exemple concret : supposons que vous souhaitiez payer le Gas en USDC pour effectuer un Swap. Dans le cadre de l'EIP-8141, cela pourrait théoriquement être organisé en un flux de trames complet : d'abord, le compte valide la signature et les permissions d'exécution ; ensuite, le payeur ou le Paymaster vérifie qu'il est prêt à assumer les conditions de coût ; puis, le paiement des frais pour l'actif correspondant est effectué ; et enfin, la véritable opération de swap est exécutée.
De cette façon, le paiement du Gas et la transaction principale peuvent être intégrés dans le même flux atomique : soit tout réussit, soit tout est annulé.
Pour l'utilisateur, le changement le plus直观 est que de nombreuses opérations qui devaient auparavant être divisées en deux ou trois étapes, avec un risque d'échec entre elles, pourront à l'avenir ressembler davantage à une action complète. Cette atomicité est donc également l'une des clés permettant à l'EIP-8141 de résoudre le problème de fragmentation de l'expérience utilisateur.
Qu'est-ce que cela signifie pour l'utilisateur de portefeuille ? En termes de résultats, les changements les plus直观 sont au moins au nombre de quatre :
- Le paiement du Gas est abstrait : Avoir des stablecoins dans son portefeuille ne signifie plus que vous devez également préparer un peu d'ETH pour opérer. À l'avenir, le paiement du Gas par un DApp, un Paymaster ou un autre sponsor deviendra plus natif ;
- Les opérations multiples sont fusionnées : Des flux comme « autoriser + Swap » ou « autoriser + staking », qui nécessitent souvent plusieurs signatures aujourd'hui, auront la possibilité d'être regroupés en une opération plus complète ;
- Les règles de sécurité du compte sont ouvertes : La multisignature, la récupération sociale, les limites quotidiennes, les verrous temporels, la rotation des clés, ne seront plus seulement des fonctionnalités avancées supplémentaires fournies par un produit portefeuille, mais commenceront à avoir la possibilité d'être construites sur une logique de compte plus native ;
- Le schéma de signature n'est plus obligatoirement verrouillé sur le chemin unique ECDSA : Cela donne pour la première fois, au niveau du protocole, la possibilité aux comptes de migrer à l'avenir vers différents systèmes cryptographiques, y compris des schémas de signature post-quantiques ;
III. Pourquoi n'est-il pas devenu la star de Hegotá ?
Un point crucial, facile à négliger mais très important pour les utilisateurs de portefeuilles, est le suivant : même si l'EIP-8141 est finalement mis en œuvre, le système de compte existant ne sera pas renversé dans son ensemble.
Même si vous utilisez actuellement imToken ou d'autres portefeuilles Web3 existants, vous n'aurez pas besoin de migrer, car il est rétrocompatible. Les adresses EOA existantes peuvent continuer à être utilisées, il suffira de choisir le moment opportun pour « mettre à niveau » la logique de validation du compte.
Mais, inversement, c'est précisément parce qu'il modifie les choses en profondeur qu'il n'est pas directement devenu la fonctionnalité phare de Hegotá dans le dernier round de discussions. Cependant, selon le processus EIP champion de 2026, CFI (Considered for Inclusion) ne signifie pas rejet, mais entrée dans une phase de considération sérieuse, sans être arrivé au moment de la décision finale de mise en ligne.
En d'autres termes, les développeurs principaux ne rejettent pas la direction de l'EIP-8141, mais tout en reconnaissant sa valeur, ils estiment également qu'il est encore trop « lourd » pour le moment.
Après tout, l'abstraction de compte native, contrairement à l'ERC-4337 qui peut d'abord être promue progressivement par quelques portefeuilles, infrastructures et applications, une fois entrée dans la couche protocole, signifie que tous les clients de la couche d'exécution doivent sérieusement implémenter, tester et coordonner. Cela augmente naturellement le seuil de progression et pousse les développeurs principaux à privilégier la prudence dans la planification des forks.
Que va-t-il se passer ensuite ? On peut le voir selon deux axes :
- L'EIP-8141 étant en statut CFI, cela signifie qu'il est toujours en cours d'évaluation continue. Les auteurs de la proposition continueront à compléter les détails clés concernant la sécurité du pool de transactions, les règles de validation et la mise en œuvre du client. Les réunions ACD ultérieures réexamineront également s'il remplit les conditions pour avancer davantage ;
- Si ces incertitudes peuvent être continuellement réduites, il aura une chance d'entrer dans une phase d'inclusion plus substantielle lors de mises à jour ultérieures ; sinon, il pourrait tout à fait être reporté à un cycle de mise à jour plus tardif ;
Pour être réaliste, l'EIP-8141 n'est pas non plus la seule proposition d'abstraction de compte native, et n'est en soi pas un schéma de signature post-quantique prêt à l'emploi, incapable de résoudre directement les problèmes de calcul quantique. Mais son importance réside dans le fait qu'il offre pour la première fois, au niveau du protocole, une issue permettant aux comptes de se libérer du chemin unique ECDSA.
Sous cet angle, la vraie valeur de l'EIP-8141 ne réside pas dans le fait qu'il soit la seule réponse correcte, mais dans le fait qu'il place pour la première fois, très complètement, sur la table des discussions du protocole Ethereum, la question de savoir à quoi devrait finalement ressembler l'abstraction de compte native.
Ce n'est pas la seule solution, mais c'est actuellement l'une des plus ambitieuses et des plus proches du plafond imaginatif d'une « AA native complète ».
Que l'EIP-8141 parvienne finalement ou non à赶上 Hegotá, cette discussion elle-même montre au moins une chose :
Ethereum n'attend pas passivement que les problèmes fermentent, mais pave progressivement, pas à pas, la voie pour le prochain système de compte.
