Abstraction de compte : EIP-8141 inscrit au fork Ethereum, EIP-8130 renvoyé sans date par Base

Un portefeuille, avant d'être une application, est un format : la façon dont une opération dit qui l'autorise et qui en paie le coût. Tant que plusieurs réseaux lisent le même format, un prestataire l'intègre une fois et sert tous ces réseaux ; c'est ce qui a permis aux réseaux bâtis au-dessus d'Ethereum de reprendre ses portefeuilles, ses dépositaires et ses applications sans rien réécrire. Le format actuel est rudimentaire : une clé, un signataire, des frais payés dans la monnaie du réseau. Tout le reste passe par des intermédiaires ajoutés par-dessus. Le prochain format commun n'est plus acquis. Depuis le 27 août, EIP-8141 est prévu dans Hegotá, une mise à jour future d'Ethereum. Depuis le 8 septembre, le dépôt de code de Base, le réseau de Coinbase, ne rattache plus EIP-8130 à aucune mise à jour datée.

Deux formats, deux calendriers

EIP-8141, baptisé « Frame Transaction », est encore un brouillon. Il a été créé le 29 janvier 2026 et porte dix auteurs, dont Vitalik Buterin et le développeur lightclient. Son inscription au programme de Hegotá figure dans le registre officiel du fork, le document où Ethereum liste ce qu'une mise à jour contiendra. Ce registre ne porte encore aucune date d'activation. Sur Ethereum, les équipes qui écrivent les logiciels des nœuds décident de ces inscriptions et du calendrier.

EIP-8130, baptisé « Keystore Accounts », est lui aussi un brouillon. Il n'a qu'un auteur, Chris Hunter, qui signe d'une adresse coinbase.com, et il ne figure pas au registre de Hegotá. Dans son billet d'ingénierie du 17 juillet, Base l'annonçait pour sa mise à jour Cobalt de septembre. Base prévoyait ensuite de l'étendre, plus tard dans l'année, aux autres chaînes de l'OP Stack, la pile logicielle d'Optimism qu'elle partage avec d'autres réseaux.

Base a changé ce calendrier dans son dépôt de code, où la modification qui déplace l'activation d'EIP-8130 vers Zenith, ouverte le 5 septembre, a depuis été fusionnée. Zenith est une mise à jour ultérieure, et Base ne lui a donné aucune date publique au 15 septembre. La page Cobalt de sa documentation prévoit une activation sur le réseau de test Sepolia le 23 septembre et sur le réseau principal le 30 septembre. Elle liste quatre fonctions, et EIP-8130 n'en fait plus partie. Le format ne tourne aujourd'hui que sur vibenet, un réseau de test de Base. Sur Base, l'équipe du réseau fixe donc elle-même ce calendrier, dans son propre dépôt.

Pour l'OP Stack, l'adoption est annoncée par Base, non intégrée au code au 15 septembre. Deux demandes de modification restent ouvertes depuis le 24 juillet, et une troisième a été fermée sans être fusionnée, avec cette mention : « not yet assigned to a network upgrade ».

Ce que chaque format vérifie, et pourquoi chaque camp le veut

Avec EIP-8141, une transaction devient une suite d'étapes. Certaines vérifient qui autorise l'opération, une approuve le paiement des frais, les autres exécutent. La vérification est du code librement programmable. Le texte place en tête une motivation précise, ouvrir une voie de sortie vers des signatures résistantes au calcul quantique. Ses promoteurs y ajoutent la résistance à la censure. Le 31 janvier, lightclient écrivait que les producteurs de blocs ne pourraient plus écarter ces transactions une fois combinées à FOCIL, attendu comme l'autre tête d'affiche de Hegotá. La Fondation Ethereum, dans sa notation des propositions du 7 septembre, justifie l'abstraction de compte native par la sécurité.

EIP-8130 part de l'autre bout. Chaque compte déclare dans un contrat système, le « keystore », qui peut agir pour lui et avec quelle méthode de signature. La transaction nomme cette méthode, si bien que le nœud sait, avant d'exécuter quoi que ce soit, ce qu'il doit vérifier.

Base motive ce choix par le coût, la latence et la complexité de la méthode actuelle, ERC-4337, qui passe par un réseau d'intermédiaires hors du protocole. Selon la mesure de Base, un transfert d'USDC consomme 46 000 unités de gas avec EIP-8130. Le gas mesure le calcul que le réseau facture. La même opération en demande 125 000 avec ERC-4337, soit 63 % de moins avec le format de Base.

Une séparation racontée par une seule des deux parties

Le 14 septembre, Derek Chiang, co-auteur d'EIP-8141, a écrit sur X que la collaboration entre les deux propositions avait échoué la semaine précédente. Base et Ethereum mettent désormais en œuvre, écrit-il, deux standards différents. Pour lui, les réseaux de seconde couche visent le passage à l'échelle, la personnalisation et la conformité. Ethereum vise, toujours selon lui, la résistance à la censure et à la capture, le logiciel ouvert, la confidentialité et la sécurité. Il estime qu'un dialogue engagé plus tôt aurait donné un meilleur résultat.

Seul Derek Chiang rapporte cette fin de collaboration. Ni Base, sur son blog d'ingénierie et dans sa documentation, ni la Fondation Ethereum, dans sa notation du 7 septembre, ne l'ont évoquée au 15 septembre.

Le texte d'EIP-8130 donne une grille pour lire cette opposition sans la trancher. Il prévoit un profil L1, pour un réseau principal comme Ethereum, et un profil L2, pour un réseau de seconde couche. Dans le profil L1, le réseau n'entretient aucune liste de méthodes de signature autorisées. Dans le profil L2, la voie de transaction n'accepte que l'ensemble de méthodes inscrit dans la norme. Base n'a pas documenté lequel des deux profils elle retient.

Les motifs que Base a publiés pour son format restent le coût, la latence et la complexité, et la conformité n'en fait pas partie. Le mot appartient à la lecture de Derek Chiang. Les deux lectures peuvent pourtant coexister, parce qu'un réseau qui restreint les méthodes qu'il accepte décide aussi de ce qui est permis.

Le seul format commun, et il date d'avant les deux

Au 15 septembre, le seul format de compte programmable complet commun aux deux réseaux est ERC-4337, précisément celui que les deux propositions visent à dépasser. EIP-8130 le désigne lui-même comme voie de repli. Sur les chaînes qui n'adoptent pas son type de transaction, écrit le texte, les comptes doivent passer par un autre mécanisme, « such as ERC-4337 ».

Pour un intégrateur qui sert Ethereum et Base, le format utilisable sur les deux réseaux n'a donc pas changé.

En mai, CDR relevait que le transfert de stablecoin sans frais ne passait sur Ethereum que par des sponsors applicatifs, sans fonction du protocole, et ce relevé tient toujours. Au 15 septembre, aucune fonction de paiement des frais par un tiers au niveau du protocole n'est en production sur Ethereum ; elle est inscrite au programme d'un fork sans date.

Ce qu'un intégrateur regarde, et chez qui

Un éditeur de portefeuille, un dépositaire ou une application présents sur les deux réseaux n'ont aucun camp à choisir aujourd'hui. Si les deux voies aboutissent, la compatibilité deviendra un coût d'intégration, car il faudra parler deux formats de compte là où un seul suffisait.

Dans l'hypothèse favorable, un format natif réduit la dépendance aux intermédiaires hors protocole qu'utilise ERC-4337, et avec elle un risque de contrepartie opérationnel. L'ensemble de méthodes de signature fixé par EIP-8130 formerait aussi un socle commun aux réseaux de l'OP Stack, à condition qu'ils l'adoptent. Au 15 septembre, cette adoption n'est pas intégrée au code.

Côté prudent, un défaut de tarification d'EIP-8130 reste ouvert. Le 2 septembre, le développeur karlb a signalé sur vibenet que les transactions de ce format échappaient au prix plancher que la norme EIP-7623 applique aux données. Chris Hunter a répondu le 11 septembre qu'il mettrait le texte à jour, mais aucune correction n'y figure au 15 septembre.

EIP-8130 laisse d'ailleurs à chaque chaîne qui l'adopte une part de ses réglages, dont le barème de gas de son profil L2. Pour une diligence, la question utile devient donc de savoir qui fixe les paramètres du compte sur la chaîne où vit l'actif.

Les équipes qui écrivent les logiciels des nœuds d'Ethereum se réunissent les 17, 21 et 24 septembre. Une réunion de travail consacrée à EIP-8141 se tient le 22 septembre. Base doit activer Cobalt sur son réseau principal le 30 septembre, sans EIP-8130.

Le format de compte que les intégrateurs parleront demain se décide dans deux documents publics, le registre du fork Ethereum et le dépôt de code de Base.

Questions fréquentes

EIP-8130 est-il actif sur Base avec la mise à jour Cobalt ?
Non. Base l'a retiré de Cobalt le 8 septembre 2026, dans son dépôt de code, et l'a reporté à Zenith, une mise à jour sans date publique. La page Cobalt de sa documentation, activation sur le réseau principal le 30 septembre, ne le liste pas.

Ethereum a-t-il en production le paiement des frais par un tiers au niveau du protocole ?
Non. Au 15 septembre 2026, aucune fonction de paiement des frais par un tiers au niveau du protocole n'est en production sur Ethereum. Elle est portée par EIP-8141, inscrit au programme du fork Hegotá le 27 août, qui n'a pas de date d'activation.

Base et la Fondation Ethereum ont-elles confirmé la fin de la collaboration sur l'abstraction de compte ?
Non. Seul Derek Chiang, co-auteur d'EIP-8141, l'a écrit, le 14 septembre 2026. Ni Base, sur son blog d'ingénierie et dans sa documentation, ni la Fondation Ethereum, dans sa notation du 7 septembre, ne l'ont évoquée au 15 septembre.

Quel format de compte fonctionne aujourd'hui sur Ethereum et sur Base ?
Au 15 septembre 2026, le seul format de compte programmable complet commun aux deux réseaux est ERC-4337. Les deux nouvelles propositions, EIP-8141 et EIP-8130, visent l'une et l'autre à le dépasser.