Ethereum Et Base Renoncent Au Standard Wallet Unique

On croyait, un temps, que la prochaine génération de portefeuilles programmables allait parler la même langue sur Ethereum et sur Base. Cette hypothèse vient de tomber. Après des mois d’échanges parfois techniques, parfois diplomatiques, les développeurs du réseau principal et les ingénieurs du rollup adossé à Coinbase ont cessé de chercher un format commun de transaction. Chacun part désormais avec sa propre proposition. L’un avance avec l’EIP-8141. L’autre pousse l’EIP-8130. La phrase est courte. Les conséquences, elles, s’étendent à toute la pile logicielle qui fait vivre un compte intelligent.

Pourquoi ce divorce technique change vraiment la donne

La nouvelle n’a rien d’un simple désaccord de calendrier. Elle touche le cœur d’une promesse répétée depuis des années : un utilisateur devrait pouvoir retrouver la même logique de compte, la même signature, parfois la même adresse, d’une chaîne à l’autre. Quand deux formats de transaction coexistent, cette promesse se fissure. Les éditeurs de wallets doivent écrire deux chemins. Les indexeurs doivent lire deux grammaires. Les outils d’audit doivent valider deux modèles de risque. Et l’utilisateur, lui, n’a aucune raison de connaître le numéro d’une EIP. Il veut seulement que son compte fonctionne.

Le sujet paraît aride. Il ne l’est pas. Derrière le jargon se joue la manière dont on paiera le gas demain, dont on enchaînera plusieurs actions sous une seule signature, dont on s’authentifiera avec une passkey, dont on confiera une clé de session à une application. Autrement dit, la manière dont un portefeuille cessera d’être une simple clé privée pour devenir un petit programme.

Ce que recouvre vraiment l’abstraction de compte

Un compte Ethereum classique, l’externally owned account ou EOA, reste d’une simplicité brutale. Il possède une clé. Il signe une transaction. Il paie ses frais en ether. Rien de plus. Cette austérité a permis au réseau de grandir. Elle a aussi figé l’expérience utilisateur dans un rituel que le grand public juge encore hostile : seed phrase, fenêtre de signature opaque, solde ETH obligatoire pour le moindre geste.

L’abstraction de compte inverse le raisonnement. Le compte n’est plus seulement une clé. Il devient un contrat capable d’exprimer des règles. Payer le gas dans un autre jeton. Regrouper plusieurs opérations. Imposer une limite quotidienne. Exiger deux signatures au-delà d’un seuil. Accepter une authentification biométrique via passkey. Déléguer temporairement un pouvoir limité à une application. Toutes ces idées circulent depuis longtemps. Les inscrire nativement dans le protocole, sans béquille externe, est une autre affaire.

Ces fonctions ne sont pas de la science-fiction. Une partie existe déjà grâce à des couches ajoutées après coup. Le problème n’est plus de savoir si c’est possible. Le problème est de savoir à quel étage de la pile on les ancre, et avec quel format de transaction le réseau les reconnaît.

Le long chemin depuis l’ERC-4337 jusqu’à Pectra

En 2023, l’ERC-4337 a ouvert une voie parallèle. Sans modifier le protocole de base, il a introduit des user operations, des bundlers et une infrastructure dédiée. Le résultat a été précieux : des comptes intelligents ont pu vivre sans attendre une hard fork. Le prix à payer s’est vu tout de suite. Un surcoût en gas. Une dépendance à des acteurs supplémentaires. Une complexité d’intégration que beaucoup d’équipes ont sous-estimée.

Puis est arrivée l’EIP-7702, livrée avec la mise à jour Pectra. L’idée était plus chirurgicale. Un compte classique pouvait déléguer son exécution à du code de contrat, le temps d’une transaction ou selon un schéma de délégation. Ce pont entre l’ancien monde des EOA et le nouveau monde des comptes programmables a réduit la rupture. Il n’a pas clos le dossier. La version native, celle que les clients du réseau valident directement, reste l’étape suivante.

Le chantier ne consiste plus à inventer l’abstraction de compte. Il consiste à décider comment le protocole lui-même reconnaît un type de transaction capable de la porter, sans recourir à une infrastructure parallèle.

Lecture technique du débat entre couche 1 et rollup

C’est précisément à cet étage que le désaccord s’est cristallisé. Pas sur l’objectif. Sur l’architecture du nouveau type de transaction. Sur l’ordre des étapes de validation. Sur ce qui doit être figé dans le protocole et ce qui peut rester flexible. Deux écoles. Deux textes. Deux calendriers.

EIP-8141 contre EIP-8130 : même cible, deux architectures

Les core developers d’Ethereum ont retenu l’EIP-8141 pour une future évolution de la couche 1. Base défend l’EIP-8130 et n’a aucune raison d’attendre une convergence qui n’arrive pas. Le rollup contrôle son séquenceur. Il maîtrise son logiciel de nœud. Il peut déployer selon son propre rythme. Cette autonomie, souvent présentée comme un avantage des couches 2, devient ici un facteur de divergence.

Les deux textes visent l’abstraction de compte native. Ils ne racontent pas la même histoire technique. L’une privilégie un certain enchaînement de vérifications. L’autre en propose un différent. Pour un lecteur non spécialiste, la nuance paraît microscopique. Pour un client de nœud, un bundler, un simulateur de transaction ou un module de signature, elle est décisive. Un octet mal interprété et la transaction est invalide. Un ordre de validation différent et le comportement de sécurité n’est plus le même.

On peut le dire autrement. Ethereum cherche une solution qui devra vivre des années dans un protocole difficile à modifier. Base cherche une solution qu’elle peut embarquer plus vite, dans un environnement qu’elle gouverne davantage. Les deux postures sont cohérentes. Elles ne sont simplement plus compatibles dans l’immédiat.

Les wallets se retrouvent en première ligne

La facture retombe d’abord sur les éditeurs de portefeuilles. MetaMask, Rabby, Safe, Coinbase Wallet et tous les autres devront maintenir deux chemins de code. Deux schémas de signature. Deux batteries de tests. Deux documentations pour un même utilisateur qui, lui, croit encore ouvrir « son » wallet. Cette duplication n’est pas un luxe de laboratoire. C’est de la maintenance permanente, avec le risque classique de toute double implémentation : un correctif appliqué d’un côté et oublié de l’autre.

Les indexeurs et les explorateurs de blocs devront apprendre à lire les deux formats. Les services de simulation, déjà essentiels pour éviter qu’un utilisateur signe une opération ruinieuse, devront reproduire deux mécaniques d’exécution. Les outils d’audit de sécurité devront cartographier deux surfaces d’attaque. Rien de tout cela n’est impossible. Tout cela coûte du temps, de l’attention et de l’argent.

Les indépendants paieront plus cher que les acteurs intégrés. C’est le point le moins charitable de l’histoire. Une entreprise qui édite à la fois le rollup, le wallet, le module de paiement et l’application grand public absorbe la divergence en interne. Une équipe qui ne contrôle qu’un portefeuille open source, elle, doit suivre deux trains qui ne partent plus de la même gare.

Le risque discret des adresses différentes

Un détail moins visible inquiète davantage certains développeurs. L’adresse d’un compte intelligent n’est pas un hasard cosmique. Elle découle des paramètres de son déploiement. Si deux formats de transaction impliquent deux contrats de compte différents, le même utilisateur peut se retrouver avec deux adresses distinctes selon qu’il se trouve sur le réseau principal ou sur Base.

Cette éventualité n’est pas un détail cosmétique. Elle fragilise l’idée d’une identité unique d’une chaîne à l’autre. Elle complique les airdrops, les listes d’éligibilité, les attestations, les historiques de réputation, les passerelles de paiement. Elle oblige les applications à cesser de croire qu’une adresse est un nom propre universel. Dans un écosystème qui rêve encore de comptes portables, c’est une régression douce, presque invisible, et pourtant très concrète.

On objectera qu’il existe déjà des adresses différentes d’un rollup à l’autre pour quantité de contrats. C’est vrai. La différence, ici, concerne le compte de l’utilisateur lui-même, pas seulement un pool ou un routeur. Quand l’identité de base se dédouble, toute la couche sociale de la crypto vacille un peu.

Base n’est pas un rollup que l’on peut ignorer

Si Base n’était qu’une expérimentation marginale, la divergence resterait un sujet de conférence. Ce n’est pas le cas. Le rollup de Coinbase domine souvent les classements de transactions quotidiennes parmi les couches 2. Il concentre plusieurs milliards de dollars de valeur déposée. Des applications grand public s’y installent parce que l’onboarding y est plus simple, parce que la marque Coinbase rassure une partie du public, parce que la liquidité s’y agrège.

Aucune équipe sérieuse ne peut donc décider d’ignorer Base pour simplifier sa base de code. Le calcul serait absurde. On ne coupe pas un marché aussi dense sous prétexte d’élégance architecturale. Le résultat prévisible est le suivant : tout le monde implémentera les deux formats, en pestant, puis en s’habituant.

Coinbase maîtrise une chaîne presque complète

Le déséquilibre économique est évident. Coinbase édite Base. Elle pousse son portefeuille intelligent. Elle construit une brique de paiement. Elle dispose d’une application grand public. Un format divergent lui coûte moins cher qu’à un éditeur indépendant, puisqu’elle livre elle-même le wallet chargé de le comprendre. La boucle se referme à l’intérieur d’un même groupe.

Cela ne signifie pas qu’il y a complot. Cela signifie qu’une entreprise verticalement intégrée n’a pas les mêmes incitations qu’un protocole public dont la gouvernance est lente, débattue et exposée à des milliers d’acteurs. Ethereum doit convaincre des clients multiples, des validateurs, des chercheurs, des auditeurs. Base peut trancher plus vite. La vitesse est un avantage. Elle est aussi une source de fragmentation.

Quand celui qui écrit le rollup écrit aussi le portefeuille, la divergence technique devient un coût interne. Quand on n’écrit que le portefeuille, elle devient une dette permanente.

Observation d’un éditeur indépendant de wallets

La fragmentation des couches 2 n’est plus un slogan

Depuis deux ans, la fragmentation des layers 2 occupe les conversations d’Ethereum. Trop de ponts. Trop de standards de messagerie. Trop de particularités de séquenceur. Trop de différences dans la disponibilité des données. L’Ethereum Foundation finance des travaux d’interopérabilité et des standards d’intentions partagés, avec l’espoir que le passage d’un rollup à l’autre devienne invisible côté utilisateur.

Le format des transactions de compte échappe pour l’instant à cette harmonisation. C’est ironique. On peut rêver d’intentions universelles tout en laissant le véhicule de base, la transaction elle-même, se dédoubler. L’intention dit « fais ceci ». La transaction dit « voici comment le réseau accepte que tu le fasses ». Si le second étage diverge, le premier doit compenser.

Cette compensation existe déjà en partie. Elle s’appelle, dans l’écosystème actuel, une couche d’abstraction supplémentaire. Plus on empile ces couches, plus on retrouve le paradoxe de l’ERC-4337 : pour unifier l’expérience, on ajoute de la machinerie. La machinerie finit par coûter du gas, de la complexité et de la surface d’attaque.

Le garde-fou ERC-5792 et ses limites

Un filet de sécurité existe. L’ERC-5792, parfois présenté comme Wallet Call API, permet à une application d’envoyer un lot d’opérations au portefeuille sans connaître la mécanique d’exécution retenue derrière. Coinbase Wallet et MetaMask le prennent déjà en charge. Dans beaucoup de cas, les développeurs d’applications pourront donc rester agnostiques. Ils formuleront une intention. Le wallet se débrouillera avec l’EIP du réseau visé.

C’est une bonne nouvelle pour les interfaces. Ce n’est pas une disparition du problème. Quelqu’un doit bien absorber l’écart. Si ce n’est pas l’application, c’est le wallet. Si ce n’est pas le wallet, c’est l’indexeur, le simulateur ou l’auditeur. La complexité ne s’évapore pas. Elle se déplace vers ceux qui touchent le métal du protocole.

Il faut aussi rappeler qu’une API d’appels groupés ne résout pas à elle seule la question des adresses, ni celle des différences de validation, ni celle des outils de bas niveau. Elle protège surtout le développeur d’application qui veut rester à distance des détails. C’est déjà beaucoup. Ce n’est pas tout.

Ce que l’utilisateur verra, et ce qu’il ne verra pas

L’utilisateur moyen ne lira jamais l’EIP-8141. Il ne comparera pas l’ordre des étapes de validation. Il ouvrira une application, tapera un montant, confirmera. Si les wallets font bien leur travail, la divergence restera souterraine. Si les wallets le font mal, elle remontera sous forme de messages d’erreur, de simulations ratées, de frais inattendus, d’adresses qui ne correspondent pas à ce que l’utilisateur croyait posséder.

Le risque le plus probable n’est pas un crash spectaculaire. C’est une usure. Des cas limites mal gérés. Des fonctionnalités disponibles sur Base et retardées sur Ethereum, ou l’inverse. Des tutoriels qui expliquent un geste valable sur une chaîne et faux sur l’autre. Des équipes support débordées par des captures d’écran incompréhensibles.

Dans l’histoire récente de la crypto, ce type d’usure a déjà fait des dégâts. Les ponts mal compris. Les réseaux mal sélectionnés. Les tokens envoyés à la mauvaise adresse sur la mauvaise chaîne. Chaque fois que l’infrastructure se dédouble, le coût pédagogique augmente. On le paie en fonds perdus, en confiance ébréchée, en utilisateurs qui reviennent aux plateformes centralisées parce que « au moins, là, ça marche ».

Pourquoi les discussions ont pu durer des mois sans aboutir

Un observateur impatient se demandera pourquoi deux camps partageant le même objectif n’ont pas tranché plus tôt. La réponse tient à la nature même d’un changement de type de transaction. On ne parle pas d’un paramètre cosmétique. On parle d’un objet que les clients doivent parser, que les nœuds doivent valider, que les wallets doivent signer, que les explorateurs doivent afficher, que les auditeurs doivent raisonner. Une fois déployé, revenir en arrière est douloureux.

Ethereum, de son côté, refuse souvent d’inscrire trop vite une conception qui pourrait se révéler incomplète. Le protocole de base a une mémoire longue. Une erreur de design s’y paie pendant une décennie. Base, de l’autre, peut itérer. Un rollup n’a pas la même rigidité constitutionnelle. Cette différence de temperament n’est pas un défaut de caractère. C’est une propriété des architectures.

Ajoutez à cela des priorités produit distinctes. Un réseau de couche 1 raisonne en termes de neutralité, de minimalisme, de compatibilité maximale. Un rollup lié à un exchange raisonne aussi en termes d’expérience grand public, de paiement, d’onboarding, de contrôle de la feuille de route. Les deux boussoles ne pointent pas exactement au même nord.

La maintenance, ce coût que l’on sous-estime toujours

Dans les présentations, on parle d’innovation. Dans les dépôts de code, on parle de tests qui cassent, de bibliothèques à forker, de revues de sécurité à recommencer. Maintenir deux chemins, ce n’est pas seulement copier-coller une fonction. C’est accepter que chaque évolution future, chaque durcissement, chaque nouvelle primitive, devra être déclinée deux fois.

Les équipes les plus solides s’en sortiront. Les plus petites improviseront. Certaines retarderont le support d’un réseau. D’autres gèleront des fonctionnalités avancées sur la chaîne la moins prioritaire. Le marché des wallets, déjà concentré autour de quelques marques, peut encore se concentrer si le coût d’entrée technique augmente.

Il y a là un effet de second ordre rarement discuté. Plus le protocole se fragmentera au niveau des transactions de compte, plus les acteurs capables d’absorber cette fragmentation gagneront du pouvoir. L’intégration verticale n’est pas seulement une stratégie commerciale. Elle devient une réponse rationnelle à la complexité.

Sécurité : deux formats, deux grammaires de risque

Un nouveau type de transaction n’est jamais anodin pour la sécurité. Il introduit des champs, des règles de validité, des interactions avec le paiement du gas, des possibilités de délégation, des clés de session. Deux types, c’est deux grammaires. Deux grammaires, c’est deux familles de bugs possibles.

Les attaques ne seront pas nécessairement spectaculaires dès le premier jour. Elles naîtront plutôt aux frontières : une simulation qui ne reflète pas l’exécution réelle, un wallet qui signe le bon payload sur une chaîne et le mauvais sur l’autre, un explorateur qui décode mal un champ et rassure à tort l’utilisateur. La sécurité d’un portefeuille programmable dépend autant de la clarté de ce que l’humain croit signer que de la solidité cryptographique.

Les outils d’audit devront donc se dédoubler eux aussi. Les checklists, les invariants, les tests de fuzzing, les modèles formels s’il y en a, tout cela devra suivre deux spécifications. Dans un secteur où le temps des auditeurs est déjà rare et cher, ce n’est pas un détail budgétaire.

Identité, réputation et multi-chaînes : la promesse ébréchée

Beaucoup de projets bâtissent aujourd’hui des systèmes de réputation, de points, d’attestations, de scores d’activité. Ces systèmes supposent souvent qu’un humain correspond à un ensemble d’adresses reliables. Si le compte intelligent de base n’est plus déployé de la même façon, le graphe d’identité se brouille.

On peut reconstruire des correspondances. On peut tenir des registres. On peut demander à l’utilisateur de lier explicitement ses comptes. Chaque rustine fonctionne. Aucune n’est aussi élégante qu’une adresse déterministe partagée. L’élégance n’est pas un caprice esthétique. C’est ce qui évite à l’utilisateur de devenir son propre service client.

Les applications de paiement, en particulier, détestent l’ambiguïté. Envoyer des fonds à « la bonne personne » suppose de savoir quelle adresse est la bonne sur quelle chaîne. Deux formats de création de compte rendent ce geste plus fragile, surtout si les interfaces simplifient trop le discours pour ne pas effrayer le grand public.

Les développeurs d’applications peuvent encore respirer

Tout n’est pas sombre pour autant. Grâce à des interfaces comme l’ERC-5792, une large part des applications peut continuer à raisonner en lots d’appels plutôt qu’en octets de transaction. C’est le niveau d’abstraction raisonnable pour un front-end. On décrit ce que l’on veut faire. On laisse le wallet choisir comment le faire.

Cette séparation des responsabilités est saine. Elle évite que chaque application réimplémente la physique du réseau. Elle place la charge là où l’expertise existe déjà, chez les éditeurs de wallets et les équipes d’infrastructure. Encore faut-il que ces derniers tiennent le rythme et que leurs SDK restent stables.

Une leçon plus large sur la gouvernance d’Ethereum

Cet épisode dit quelque chose de la gouvernance réelle du paysage Ethereum. La couche 1 n’impose plus, à elle seule, le rythme de toute la galaxie. Les rollups sont devenus des lieux de pouvoir. Ils ont des utilisateurs, des revenus, des feuilles de route, parfois des marques grand public. Ils peuvent innover sans attendre le prochain train de la couche de base.

C’est une victoire pour la scalabilité. C’est une tension pour la standardisation. On ne peut pas célébrer l’autonomie des L2 six jours sur sept et s’étonner, le septième, qu’elles refusent d’attendre. L’alignement ne se décrète pas. Il se négocie, se finance, se spécifie, se teste. Parfois, il échoue.

L’échec n’est pas total. Les deux camps restent dans la même famille intellectuelle. Ils veulent des comptes programmables. Ils veulent moins de friction. Ils veulent une validation native. Ils divergent sur le chemin. Dans l’histoire des protocoles, ce genre de fork conceptuel est fréquent. Ce qui compte ensuite, c’est si un pont d’interopérabilité rattrape le fossé, ou si le fossé s’élargit à d’autres rollups tentés par leur propre variante.

Et si d’autres réseaux copient le geste de Base

Le vrai risque systémique n’est pas seulement qu’Ethereum et Base aient deux formats. C’est qu’un troisième, puis un quatrième rollup décident que leur propre variante est encore mieux adaptée à leur séquenceur, à leur marché, à leur wallet maison. On passerait alors d’une dualité gérable à une mosaïque.

Les standards d’intentions et les API de wallets sont précisément conçus pour empêcher cette mosaïque de remonter jusqu’à l’utilisateur. Ils peuvent réussir. Ils peuvent aussi arriver trop tard, ou trop partiels. L’industrie crypto a déjà connu des périodes où chaque chaîne inventait son pont, son standard de token, son wrapping. On en paie encore les cicatrices.

D’où l’importance de documenter clairement, dès maintenant, ce qui est commun et ce qui ne l’est plus. Plus le discours public restera flou, plus les implémentations divergeront dans le silence des dépôts Git.

Ce que les équipes devraient faire dès cette semaine

Les discours généraux ne suffisent pas aux gens qui shippent du code. Concrètement, une équipe wallet devrait isoler dès maintenant la couche d’encodage des transactions. Une équipe d’application devrait vérifier son support de l’ERC-5792 plutôt que de bricoler des payloads spécifiques. Une équipe d’indexation devrait prévoir deux parseurs, même si l’un des deux restera inactif quelques semaines.

Les produits grand public devraient aussi revoir leurs textes d’aide. Dire « votre compte intelligent » comme s’il s’agissait d’un objet unique et portable peut devenir trompeur. Mieux vaut expliquer, avec calme, qu’un compte peut avoir des comportements différents selon le réseau, sans transformer chaque écran en cours de protocol engineering.

• Cartographier dès maintenant les points du code qui supposent un format unique.
• Séparer clairement la logique métier et la logique d’encodage réseau.
• Tester les cas où une adresse dérivée sur une chaîne ne correspond pas à l’autre.
• Préparer le support et la documentation à des erreurs de simulation spécifiques.

Le récit marketing devra se calmer

Depuis trois ans, le marketing des comptes intelligents promet parfois un monde sans friction, sans seed, sans gas visible, sans différence entre chaînes. Une partie de cette promesse reste juste. Une autre partie vient de prendre un coup. Continuer à vendre l’unicité parfaite serait malhonnête. Dire que tout s’effondre serait hystérique. La vérité se tient au milieu : l’expérience peut rester fluide si les wallets tiennent, et elle se dégradera si l’on fait semblant que rien n’a changé.

Les utilisateurs avancés, eux, comprendront vite. Ils ont déjà l’habitude des RPC différents, des explorateurs différents, des ponts capricieux. Ce sont les nouveaux venus qu’il faut protéger. Eux n’ont pas de carte mentale de la pile. Ils ont un bouton. Si le bouton ment, ils partent.

Une lecture économique de la divergence

On peut aussi lire l’événement comme un arbitrage économique. Standardiser coûte du temps de coordination. Divergier coûte du temps d’implémentation. Base a estimé, implicitement, que le second coût lui était plus favorable que le premier. Ethereum a estimé que la qualité du design de couche 1 valait mieux qu’un compromis rapide. Chaque camp optimise sa fonction de coût.

Le marché tranchera ensuite. Si l’EIP retenue par Ethereum devient le centre de gravité des autres rollups, Base devra un jour converger, ou vivre avec une exception durable. Si le modèle de Base séduit par sa vitesse de déploiement et son intégration produit, d’autres L2 pourront s’en inspirer. Les standards gagnent rarement uniquement parce qu’ils sont plus beaux. Ils gagnent parce qu’ils sont partout.

C’est pourquoi les wallets comptent autant que les EIP. Un format que personne n’implémente dans les applications que les gens ouvrent chaque matin n’est qu’un fichier sur un dépôt. Un format médiocre mais universellement supporté gagne souvent la partie. Cette leçon, l’histoire d’Internet l’a déjà écrite vingt fois.

Ce que cette affaire dit de l’avenir des portefeuilles

Le portefeuille n’est plus un coffre. Il devient un système d’exploitation personnel pour la chaîne. Plus cette métaphore se réalise, plus le wallet concentre de logique : politiques de dépenses, sessions, récupération, paiement de gas, multi-chaînes, identité. Une divergence de format de transaction renforce encore ce rôle. C’est le wallet qui traduit le monde fragmenté en geste unique.

On peut s’en réjouir. Un bon système d’exploitation cache la complexité. On peut aussi s’inquiéter. Plus le wallet cache, plus l’utilisateur dépend d’un intermédiaire logiciel, même si les clés restent théoriquement siennes. L’abstraction de compte, paradoxalement, peut rapprocher l’expérience d’une banque tout en conservant une base cryptographique. Le curseur entre souveraineté et confort continuera de bouger.

Dans ce contexte, la qualité du logiciel de portefeuille devient un sujet politique autant que technique. Qui écrit les règles par défaut. Qui propose la récupération. Qui décide comment une session est présentée. Deux EIP ne changent pas ces questions. Elles les rendent plus urgentes, parce que le traducteur, le wallet, gagne encore en importance.

Replacer l’épisode dans la saison plus longue d’Ethereum

Ethereum n’en est pas à sa première tension entre ambition d’unicité et réalité multi-réseaux. Le passage à la preuve d’enjeu, la montée des rollups, les débats sur la disponibilité des données, les discussions sur les intentions : à chaque étape, le centre a dû accepter de ne plus tout contrôler. Cette acceptation est la condition de l’échelle. Elle produit aussi des zones grises.

Les comptes programmables natifs devaient, dans certains récits, refermer une de ces zones grises en inscrivant enfin dans le protocole ce que l’ERC-4337 avait improvisé sur le côté. Le résultat immédiat est plus ambigu. La nativeité arrive, mais pas sous une bannière unique. On gagne en ancrage protocolaire. On perd en uniformité inter-chaînes.

Peut-être n’était-il pas possible d’obtenir les deux en même temps. Peut-être fallera-t-il une troisième génération de standard, plus tard, quand les deux implémentations auront vécu, cassé, enseigné. Les protocoles mûrissent souvent ainsi : d’abord la diversité féconde, ensuite la consolidation, parfois douloureuse.

Ce qu’il faut retenir sans se noyer dans les numéros d’EIP

Si l’on écarte le bruit, il reste quelques faits stables. Ethereum et Base ne feront pas converger, pour l’instant, le format des transactions de leurs futurs portefeuilles programmables. Le réseau principal avance avec l’EIP-8141. Base déploiera l’EIP-8130 selon son calendrier. Les wallets, indexeurs et outils d’audit devront vivre avec deux chemins. Les adresses de comptes intelligents pourraient diverger. L’ERC-5792 offre aux applications un moyen de rester au-dessus de la mêlée.

Ces faits suffisent à orienter une feuille de route. Ils suffisent aussi à tempérer les récits trop lisses sur l’unification imminente de l’expérience multi-chaînes. L’unification avance. Elle avance par couches, par compromis, par reculs locaux. Ce recul-là est local. Il n’est pas mineur.

La fin d’un standard commun n’empêche pas les comptes programmables d’arriver. Elle impose seulement d’admettre que l’arrivée se fera en formation dispersée, et que quelqu’un devra traduire.

Synthèse du basculement en cours

Une clôture lucide plutôt qu’un verdict définitif

Il serait tentant de conclure par un camp du bien et un camp de l’erreur. Ce serait paresseux. Ethereum protège la lenteur d’un protocole commun. Base protège la vitesse d’un produit qu’elle peut livrer de bout en bout. Les utilisateurs, eux, jugeront à l’usage. Ils jugeront si leur portefeuille masque la couture. Ils jugeront si une adresse se comporte comme ils le croient. Ils jugeront si payer, signer, récupérer un compte reste simple quand on change de réseau.

En attendant ce verdict empirique, le travail commence. Il est ingrat. Il consiste à lire deux spécifications, à écrire deux adaptateurs, à tester deux mondes qui se ressemblent assez pour tromper, et assez peu pour casser. C’est moins glamour qu’une annonce d’unification. C’est davantage fidèle à la manière dont les infrastructures évoluent vraiment.

Les portefeuilles programmables arriveront. Ils seront plus puissants qu’un EOA. Ils paieront le gas autrement. Ils signeront autrement. Ils ouvriront des sessions. Ils se rapprocheront, parfois, de l’expérience d’une application mobile ordinaire. Seulement voilà : sur Ethereum et sur Base, ils ne parleront plus exactement la même langue technique. À chacun, désormais, de décider s’il apprend les deux dialectes, ou s’il s’en remet à un traducteur. Dans cette industrie, le traducteur a un nom. On l’appelle encore wallet. Il vient d’hériter d’un second dictionnaire, et il n’aura pas le droit de se tromper de page.