L'abstraction de compte Ethereum a-t-elle échoué ?

Rédaction : Haotian

La dernière fois, j'ai mentionné que le protocole x402 prolongeait le réseau Lightning, et récemment, lors d'un repas avec un groupe d'amis programmeurs, j'ai de nouveau été “défié” : n'est-ce pas juste l'abstraction de compte AA d'avant ?

Le sous-texte est qu'Ethereum a investi beaucoup d'années dans l'abstraction de compte (Account Abstraction), avec des ressources considérables consacrées à l'ERC-4337, au Paymaster, ainsi qu'à divers types de subventions et de prestataires de services de portefeuille. Cependant, comme le constate tout le monde, cela a été critiqué par beaucoup comme étant bruyant mais peu efficace.

Bien que je ne pense pas que AA ait déjà déclaré faillite, quel est le véritable problème ?

1. Le Paymaster transfère la consommation de Gas des utilisateurs au projet, ce qui semble très attrayant, mais la capacité des projets à payer pour cela est très faible, le ROI n'est pas clair, et cela mène sans aucun doute à une impasse dans le modèle commercial. Comment peut-on fonctionner sans capacité d'auto-financement et en dépendant uniquement des transfusions?

2. L'abstraction de compte AA est limitée à l'écosystème EVM, par exemple les contrats ERC4337, Paymaster et EntryPoint, qui sont tous exclusivement Ethereum. Si l'on souhaite inclure l'utilisation de l'écosystème inter-EVM tel que Solana, BTC, etc., il faudra continuer à superposer des services intermédiaires pour réaliser cette fonctionnalité. Cependant, le problème est que ces services intermédiaires entraînent une nouvelle division des frais, ce qui représente un défi encore plus grand pour le retour sur investissement du modèle commercial !

Il y a encore beaucoup de problèmes techniques complexes, je ne vais pas les développer, mais je vais dire quelque chose que tout le monde peut comprendre. AA est essentiellement un produit de « technologie pour la technologie », issu d'une tendance de recherche pure sur Ethereum dans le passé.

En comparaison, qu'est-ce que le protocole x402 joue ? Quelles sont les différences ? Certains critiquent le fait de ramener un spécimen ancien comme le code d'état HTTP 402, qui existe depuis 30 ans, et de créer un jeu avec des dorures.

Mais n'oubliez pas, le code d'état HTTP 402 - c'est le protocole de base d'Internet, la langue commune de Web2 et Web3.

AA nécessite des contrats intelligents, nécessite un état on-chain, nécessite l'exécution de la machine virtuelle EVM, x402 n'a besoin que d'un en-tête de requête HTTP, tout système prenant en charge HTTP peut l'utiliser - API Web2, RPC Web3, voire des passerelles de paiement traditionnelles, tout est compatible.

Ce n'est pas une solution d'optimisation de l'empilement technologique, mais plutôt une “attaque dimensionnelle” simplifiant la complexité au niveau du protocole. Au lieu de s'acharner sur diverses compatibilités et méthodes de confiance au niveau des applications, il vaut mieux d'abord unifier les normes du niveau du protocole en amont.

La clé est que x402 est naturellement un très bon standard d'interopérabilité inter-chaînes. Tant que l'Agent peut envoyer des requêtes HTTP, traiter les réponses 402 et compléter l'autorisation EIP-3009 (ou un standard équivalent d'une autre chaîne), que vous soyez sur Base, Monad, Solana, Avalanche ou BSC, le niveau de protocole ne ressent pas l'interopérabilité inter-chaînes, cela ne se manifeste que dans le problème de point unique de règlement des paiements, ce qui réduit considérablement le coût de l'interopérabilité inter-chaînes.

Le Facilitateur peut servir plusieurs chaînes simultanément, les données historiques de paiement des utilisateurs peuvent être indexées de manière uniforme, et les développeurs peuvent se connecter une fois pour “connecter” tout l'écosystème.

Dans l'ensemble, je sens que l'AA est une ingénierie raffinée issue de la pensée des chercheurs, tandis que le protocole x402 est un pragmatisme dicté par les besoins du marché.

La question se pose, l'ERC-8004 suivra-t-il le même chemin que l'AA ?

D'un point de vue théorique, l'ERC-8004 ressemble beaucoup à l'AA 2.0, il reste exclusif à l'EVM et nécessite le déploiement de trois registres (Identité/Réputation/Validation). Les incitations initiales dépendent également des subventions externes ou du staking, ce qui sont des pièges que l'AA a déjà rencontrés. Pour que d'autres chaînes soient compatibles, il faudra encore ajouter un coût de confiance supplémentaire.

Mais la différence est que, dans le cadre de x402, l'ERC-8004 n'est qu'un outil, et non une norme suprême. Les autres chaînes doivent être compatibles avec le protocole x402, et non avec l'ERC8004.

Cette différence de positionnement est très importante. Quel était le problème d'AA à l'époque ? Il voulait devenir « la seule norme pour l'expérience de paiement Ethereum », exigeant que tout l'écosystème gravite autour de lui : les portefeuilles doivent être compatibles, les applications doivent être intégrées, et les utilisateurs doivent changer leurs habitudes. Ce type d'imposition « de haut en bas », sans application phare ni retour sur investissement clair, ne peut naturellement pas avancer.

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

De plus, l'ERC-8004 profite de l'essor de x402 et n'a pas besoin de construire un écosystème à partir de zéro. x402 dispose déjà d'un cycle commercial clair (génération de trafic par le Fournisseur, facturation par le Facilitateur), d'une pile technologique complète (protocole HTTP + EIP-3009) et d'un écosystème de projet actif. L'ERC-8004 n'a besoin que d'un “plug-and-play”.