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

Rédigé par : imToken

La semaine dernière, lors de la réunion officielle des développeurs principaux d’Ethereum, il a été discuté pour savoir si la proposition EIP-8141 devait être intégrée à la mise à niveau Hegota ; le résultat a été pour le moins surprenant. Cette proposition, soutenue personnellement par Vitalik, n’a pas été classée comme une fonctionnalité “à la une” de Hegota, mais s’est vue attribuer le statut “envisagé pour inclusion” (CFI).

Et cette semaine, l’équipe Google Quantum AI a publié un livre blanc récent, indiquant qu’avec ses hypothèses matérielles données, l’estimation du nombre de qubits quantiques physiques nécessaires pour casser l’ECDLP-256 a chuté de manière spectaculaire, de 20 fois par rapport à auparavant. Bien que cela ne signifie pas que l’attaque quantique est imminente, cela nous rappelle, de façon très concrète, que si, à l’avenir, le système de comptes ne peut pas changer de manière flexible la logique de vérification, alors bon nombre des discussions actuelles sur l’expérience des portefeuilles risquent au final de se transformer en problèmes de sécurité.

Du point de vue pragmatique de l’avancement du protocole, l’EIP-8141 est encore trop lourde aujourd’hui, notamment en ce qui concerne l’implémentation côté client, la sécurité du mempool (pool de transactions) et la complexité de la vérification ; aucun consensus suffisamment solide ne s’est pour l’instant formé.

Mais à ce moment précis, il semblerait qu’il y ait de plus en plus d’éléments qui méritent d’être débattus et examinés sérieusement concernant l’EIP-8141.

1. À quoi l’EIP-8141 veut-elle répondre exactement ?

L’EIP-8141 est portée par Vitalik Buterin et d’autres contributeurs clés comme timbeiko. Son nom officiel est Frame Transactions (transactions par “trames”).

Si on la résume en une phrase plus facile à comprendre, l’objectif n’est en réalité pas d’ajouter une fonction de portefeuille isolée, mais d’essayer, au niveau du protocole, de faire en sorte que n’importe quel compte ne soit plus contraint par un chemin unique de signature ECDSA, et puisse au contraire disposer d’une logique de validation et d’exécution plus flexible.

Cela signifie que les multi-signatures, le parrainage de Gas (Gas sponsorship), la rotation des clés, la récupération sociale, voire à l’avenir l’intégration de schémas de signatures résistants aux attaques quantiques, ne sont plus seulement des capacités “externes” greffées à l’extérieur du portefeuille ; elles ont une chance de devenir des “membres natifs” du système de comptes d’Ethereum.

Si l’on s’en tient à la surface, le débat autour de l’EIP-8141 concerne un ensemble de capacités très concrètes : payer le Gas avec des stablecoins, agréger 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 la place pour des signatures résistantes aux attaques quantiques à l’avenir. On peut dire que, au fil des années, de l’ERC-4337 à l’EIP-7702, beaucoup d’améliorations autour de l’expérience des portefeuilles ont fondamentalement pour but de faire en sorte qu’un compte ne soit plus juste une clé privée, mais un point d’entrée permettant de personnaliser des règles.

Le problème, c’est que ces améliorations font bien en sorte que les portefeuilles ressemblent de plus en plus à des comptes “intelligents”, mais n’ont jamais touché réellement le modèle de compte par défaut le plus basique d’Ethereum.

Comme on le sait, dans le système actuel, les comptes Ethereum se divisent globalement en deux catégories. D’une part, les comptes à possession externe (EOA), ceux que tout le monde connaît le mieux. Ils sont contrôlés par une clé privée, peuvent initier des transactions de manière proactive, mais manquent de capacités programmables. D’autre part, les comptes de contrat, c’est-à-dire le contrat intelligent lui-même : il peut exécuter une logique complexe, mais ne peut pas initier lui-même des transactions de manière proactive.

Cela conduit à ce que la capacité d’initier des transactions reste durablement liée à la signature par une seule clé privée. Tant que cette hypothèse ne change pas, il devient très difficile de faire en sorte que des capacités que beaucoup d’utilisateurs considèrent aujourd’hui comme allant de soi—changer de manière 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 migrer plus facilement vers un nouveau système de mots de passe à l’avenir—puissent réellement devenir des capacités par défaut des comptes.

Si vous avez déjà utilisé imToken ou d’autres portefeuilles Web3, vous avez probablement aussi rencontré ces problèmes : il y a plein de USDC dans le portefeuille, mais sans ETH vous ne pouvez pas envoyer de transaction (car le Gas ne peut être payé qu’en ETH) ; si vous perdez la phrase mnémonique, vous perdez 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 du fait que le produit de portefeuille serait “pas assez bon”, mais du résultat de la conception même du modèle de comptes d’Ethereum.

Sous cet angle, l’évolution des deux dernières années est en réalité déjà très claire : l’ERC-4337, sans modifier le protocole, a fait tourner l’abstraction de compte d’abord au niveau applicatif ; l’EIP-7702 prouve en plus que les EOA ne sont pas totalement impossibles à étendre : du moins, elles peuvent temporairement obtenir une partie des capacités se rapprochant des comptes intelligents.

Autrement dit, Ethereum ne cherche pas à ne pas faire d’abstraction de compte : il l’a toujours poursuivie avec une approche plus douce et plus conservatrice, en s’en approchant progressivement. L’apparition de l’EIP-8141 signifie que ce chemin a atteint un nouveau point. Il ne se contente plus d’empiler une couche de capacité de compte intelligent en périphérie du système existant ; il cherche à intégrer l’abstraction de compte directement dans le modèle de transaction lui-même, de sorte que dès le niveau du protocole, le compte dispose d’une logique de validation et d’exécution programmable.

C’est aussi pourquoi l’EIP-8141 a de nouveau pris de l’ampleur aujourd’hui. D’un côté, l’expérience des portefeuilles côté couche supérieure se rapproche de plus en plus de l’abstraction de compte native, et tôt ou tard la couche protocolaire devra suivre ; de l’autre, la pression à long terme induite par l’informatique quantique fait aussi que la question de savoir si le compte peut changer de manière flexible de méthode de signature, autrefois un sujet technique lointain, devient à l’avance un problème réel qu’il faut sérieusement considérer.

2. Comment fonctionne l’EIP-8141 ?

Au fond, l’EIP-8141 introduit un tout nouveau type de transaction—les Frame Transactions (transactions par trames), avec un identifiant de type de transaction égal à 0x06.

Si la logique de base d’une transaction Ethereum traditionnelle est qu’une transaction correspond à un seul appel, alors ce que l’EIP-8141 veut faire, c’est décomposer une transaction en une série de “trames” pouvant s’exécuter dans un ordre déterminé par des règles, afin de séparer les trois choses—validation, paiement et exécution—qui étaient auparavant liées.

Chaque “trame” a trois modes d’exécution :

VERIFY (trame de validation) : elle est chargée de vérifier si la transaction est valide. Elle exécute la logique de validation personnalisée du compte ; si elle passe, elle appelle le nouveau code d’opération APPROVE pour autoriser l’exécution et spécifier un plafond de Gas.

SENDER (trame d’envoi) : elle exécute l’opération réelle, par exemple un transfert, l’appel d’un 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 du système comme appelant, pour des scénarios tels que le déploiement de contrats, la validation de Paymaster, etc. ;

Le sens de cette mécanique n’est pas que la transaction puisse devenir plus complexe, mais que, pour la première fois, les trois éléments “validation, paiement, exécution” sont séparés des actions du compte, puis délégués à un ordonnancement natif du protocole.

Après tout, dans le passé, qui valide la transaction, qui paie le Gas et qui exécute la véritable opération étaient essentiellement liés à la même action de compte. Dans la conception de l’EIP-8141, ces éléments peuvent être séparés en différentes trames, exécutées par le protocole dans un ordre clair et successif ; c’est précisément pour cela que le compte ne peut plus se limiter à dépendre d’une seule 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 payer le Gas avec USDC pour réaliser un Swap. Dans le cadre de l’EIP-8141, en théorie, cela peut être organisé comme un flux complet de trames : d’abord, le compte valide la signature et les droits d’exécution ; ensuite, le payeur ou Paymaster valide les conditions selon lesquelles il accepte de prendre en charge les frais ; puis le paiement des frais correspondants est effectué ; enfin, l’opération swap réelle 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 annulé (rollback).

Pour les utilisateurs, le changement le plus direct est que beaucoup d’opérations auparavant obligées d’être séparées en deux ou trois étapes et comportant un risque d’échec au milieu peuvent, à l’avenir, ressembler davantage à une seule action complète. C’est pourquoi l’atomicité est aussi l’une des clés par lesquelles l’EIP-8141 cherche à résoudre le problème de fragmentation de l’expérience utilisateur.

Alors, que cela signifie-t-il pour les utilisateurs de portefeuilles ? D’après les résultats, le changement le plus direct comporte au moins quatre couches :

Le paiement du Gas est abstrait : si vous avez des stablecoins dans votre portefeuille, cela ne signifie plus que vous devez préparer en plus un peu d’ETH pour agir. À l’avenir, faire payer le Gas par un DApp, un Paymaster ou un autre sponsor deviendra plus natif ;

Les opérations en plusieurs étapes sont fusionnées : des flux comme “autorisation + Swap” ou “autorisation + mise en gage”, qui nécessitent souvent plusieurs signatures, ont la possibilité d’être emballés en une opération plus complète ;

Les règles de sécurité du compte s’ouvrent : multi-signatures, 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 en supplément par un produit de portefeuille, mais pourra être établi sur une logique de compte plus native ;

Le schéma de signature n’est plus forcément verrouillé sur un chemin unique ECDSA : cela donne, pour la première fois, une possibilité de sens au niveau du protocole pour une migration future du compte vers différents systèmes de mots de passe, y compris des schémas de signatures post-quantiques ;

3. Pourquoi n’est-ce pas devenu la vedette de Hegotá ?

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

Même si vous utilisez maintenant des portefeuilles Web3 existants comme imToken, vous n’avez pas besoin de migrer, car il assure la compatibilité ascendante. Les adresses EOA existantes peuvent continuer à être utilisées, et il suffit de choisir, au moment opportun, une logique de validation “d’upgrade” du compte.

Mais à l’inverse, c’est précisément parce qu’elle modifie en profondeur qu’elle n’a pas directement été classée comme la fonctionnalité vedette de Hegotá lors des discussions de la dernière ronde. Cependant, selon le processus de “EIP champion 2026”, le sens de CFI (Considered for Inclusion) n’est pas un rejet : cela signifie simplement qu’on entre dans une phase d’examen sérieux, sans être encore au moment du feu vert final pour un déploiement.

Autrement dit, les développeurs principaux ne ne reconnaissent pas la direction de l’EIP-8141 : ils reconnaissent sa valeur, tout en considérant qu’elle est encore trop “lourde” aujourd’hui.

Après tout, l’abstraction native de compte n’est pas comme ERC-4337, qui peut être poussée progressivement d’abord par un petit nombre de portefeuilles, d’infrastructures et d’applications. Une fois qu’elle entre au niveau du protocole, cela signifie que tous les clients d’exécution devront la prendre au sérieux, la tester et coopérer ; cela augmente naturellement les barrières à l’avancement, et rend les développeurs principaux plus enclins à être prudents lorsqu’ils planifient un fork.

Que se passera-t-il ensuite ? On peut voir les choses selon deux lignes :

Puisque l’EIP-8141 est en statut CFI, cela signifie qu’elle fait toujours l’objet d’une évaluation continue. Les auteurs de la proposition continueront à compléter les détails clés autour de la sécurité du mempool, des règles de validation et de l’implémentation côté client. Ensuite, les réunions ACD réexamineront à nouveau si elle remplit les conditions pour avancer davantage ;

Si ces incertitudes peuvent être réduites de façon continue, elle pourrait entrer dans une phase d’intégration plus substantielle lors des mises à niveau ultérieures ; sinon, elle pourrait aussi être totalement reportée à un cycle de mise à niveau plus tardif ;

En toute honnêteté, l’EIP-8141 n’est pas non plus la seule proposition d’abstraction de compte native ; et ce n’est pas non plus, en soi, un certain schéma prêt à l’emploi pour des signatures post-quantiques qui permettrait de résoudre directement le problème du calcul quantique. Son importance réside toutefois dans le fait qu’elle offre, pour la première fois, une sortie ayant un sens au niveau protocolaire pour permettre aux comptes de se libérer du chemin unique ECDSA.

Sous cet angle, la vraie valeur de l’EIP-8141 ne tient pas au fait qu’elle soit la seule réponse correcte, mais au fait qu’elle place pour la première fois, de manière très complète, la question de “à quoi devrait ressembler exactement le point final de l’abstraction native de compte” sur la table de discussion du protocole Ethereum.

Ce n’est pas la seule option, mais c’est assurément l’une des propositions les plus ambitieuses et les plus proches de la limite d’imagination du “compte AA natif complet”.

Quoi qu’il arrive—que l’EIP-8141 parvienne ou non à rattraper Hegotá—cette discussion a déjà montré au moins une chose :

Ethereum ne reste pas immobile en attendant que les problèmes fermentent ; il prépare, pas à pas, grâce à des efforts réguliers, la voie pour le système de comptes de la prochaine génération.