L'abstraction des comptes Ethereum a-t-elle échoué ?

Rédaction : Haotian

La dernière fois, j'ai parlé du fait que le protocole x402 prolonge le réseau Lightning. Récemment, lors d'un repas avec un groupe d'amis programmeurs, on m'a de nouveau « challengé » : x402, ce n'est pas simplement la précédente abstraction de compte (AA) ?

Entre les lignes, cela signifie qu'Ethereum a passé de nombreuses années à travailler sur l'abstraction de compte (Account Abstraction), investissant massivement dans ERC-4337, Paymaster et autres ressources, y compris diverses subventions et fournisseurs de services de portefeuille, mais comme chacun peut le constater, beaucoup critiquent le fait qu'il y ait eu beaucoup de bruit pour rien.

Même si je ne pense pas que l'AA soit un échec avéré, où se situe exactement le problème ?

1. Le Paymaster transfère la consommation de Gas des utilisateurs aux projets. Cela semble idéal en théorie, mais en pratique, la motivation des projets à payer à leur place est faible, car le ROI n'est pas clair. Cela conduit inévitablement à une impasse commerciale : comment survivre sans capacité d'autofinancement, uniquement par perfusion extérieure ?

2. L'abstraction de compte AA est limitée à l'écosystème EVM : ERC4337, Paymaster, contrat EntryPoint, tous spécifiques à Ethereum. Pour étendre son usage à des écosystèmes non-EVM comme Solana ou BTC, il faut ajouter des couches intermédiaires, or celles-ci ajoutent une couche supplémentaire de frais, aggravant encore davantage le défi du ROI commercial !

Il existe bien d'autres problèmes techniques complexes que je n'approfondirai pas ici, mais disons-le clairement : l'AA est essentiellement un produit « technologie pour la technologie », hérité de l'approche purement académique d'Ethereum.

Alors, quel est le jeu de x402 ? En quoi est-il différent ? Certains reprochent de ressortir une espèce préhistorique comme le code d'état HTTP 402 datant de 30 ans, comme graver des motifs sur de l'or déjà précieux.

Mais n'oublions pas que le code d'état HTTP 402 est un protocole fondamental d'Internet, un langage commun à Web2 et Web3.

L'AA nécessite des contrats intelligents, des états en chaîne et une machine virtuelle EVM pour s'exécuter, tandis que x402 ne requiert qu'un en-tête HTTP : tout système supportant HTTP peut l'utiliser — API Web2, RPC Web3, voire passerelles de paiement traditionnelles, tout est compatible.

Il ne s'agit pas d'une optimisation par accumulation technique, mais d'une « frappe dimensionnelle » au niveau protocolaire qui simplifie radicalement la complexité. Plutôt que de jongler avec des adaptations applicatives et des mécanismes de confiance variés, mieux vaut d'abord unifier la norme au niveau protocolaire le plus haut.

Le point clé est que x402 constitue naturellement une excellente norme d'interopérabilité multi-chaînes. Dès lors qu'un Agent peut envoyer une requête HTTP, traiter une réponse 402 et accomplir une autorisation EIP-3009 (ou une norme équivalente sur une autre chaîne), peu importe que ce soit Base, Monad, Solana, Avalanche ou BSC : l'interfonctionnement entre chaînes est transparent au niveau protocole, se réduisant à un simple point de règlement, rendant ainsi le coût de la multi-chaîne bien moindre.

Un Facilitator peut servir plusieurs chaînes simultanément, les historiques de paiement des utilisateurs peuvent être indexés de façon unifiée, et les développeurs, après une seule intégration, peuvent « connecter » l'ensemble de l'écosystème.

Mon sentiment général est que l'AA est une ingénierie raffinée issue d'une logique académique, tandis que le protocole x402 est un pragmatisme imposé par la demande du marché.

La question se pose alors : ERC-8004 suivra-t-il la même voie que l'AA ?

Théoriquement, ERC-8004 ressemble fortement à une version AA 2.0 : toujours spécifique à l'EVM, nécessitant le déploiement de trois registres (Identité/Réputation/Validation), et dépendant initialement de subventions externes ou de mise en gage, autant de pièges que l'AA a déjà connus. Pour assurer la compatibilité avec d'autres chaînes, un coût supplémentaire de confiance reste requis.

Mais la différence tient à ceci : dans le cadre de x402, ERC-8004 n'est qu'un outil, pas une norme dominante. Ce sont les autres chaînes qui doivent être compatibles avec le protocole x402, et non avec ERC-8004.

Cette différence de positionnement est cruciale. Quel était le problème de l'AA à l'époque ? Il voulait devenir « la norme unique de l'expérience de paiement sur Ethereum », exigeant que tout l'écosystème s'adapte : les portefeuilles devaient intégrer, les applications s'adapter, les utilisateurs changer leurs habitudes. Une imposition « top-down » qui, sans application phare ni ROI clair, ne pouvait tout simplement pas progresser.

ERC-8004 est différent. Il n'a pas besoin d'être le protagoniste, car x402 a déjà résolu le problème central : le paiement. ERC-8004 n'offre qu'une couche de confiance « optionnelle » sur ce réseau de paiement déjà opérationnel.

De plus, ERC-8004 profite de l'élan de x402, sans avoir à construire un écosystème depuis zéro. x402 dispose déjà d'une boucle commerciale claire (récupération de trafic par les Providers, frais perçus par les Facilitators), d'une pile technique complète (protocole HTTP + EIP-3009) et d'un écosystème de projets actifs. ERC-8004 n'a qu'à s'intégrer directement, « plug and play ».