Point de vue : le protocole x402 n'est pas équivalent à l'abstraction de compte Ethereum.

Auteur : Haotian ; Source : X, @tmel0211

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

Le sous-texte est que l'Ethereum a investi beaucoup d'années dans l'abstraction de compte (Account Abstraction), avec des ressources allouées à des initiatives comme l'ERC-4337 et Paymaster, incluant divers subventions et fournisseurs de portefeuilles. Cependant, les résultats sont là et beaucoup de gens critiquent le fait qu'il y a beaucoup de bruit mais peu de résultats.

Bien que je ne pense pas qu'AA ait déjà déclaré faillite, quelle en est la véritable raison ?

1. Le Paymaster transfère la consommation de gaz des utilisateurs au projet, cela semble très beau, mais la capacité du projet à payer pour l'utilisateur est très faible, le ROI n'est pas clair, il est indéniable que cela mène à une impasse dans le modèle commercial, comment peut-on fonctionner sans capacité d'autofinancement et en comptant uniquement sur des transfusions ?

2. L'abstraction du compte AA est limitée à l'écosystème EVM, comme les contrats ERC4337, Paymaster et EntryPoint, qui sont tous spécifiques à Ethereum. Si l'on souhaite inclure des utilisations inter-écosystèmes EVM comme Solana ou BTC, il faut continuer à superposer des services intermédiaires pour réaliser cette fonctionnalité. Mais le problème est que les services intermédiaires ajoutent une nouvelle couche de frais à répartir, ce qui représente un plus grand défi pour le ROI 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 de la tendance pure à la recherche d'Ethereum dans le passé.

En comparaison, qu'est-ce que le protocole x402 joue ? Qu'est-ce qui est différent ? Certaines personnes critiquent le fait de faire ressortir le code d'état HTTP 402, un fossile vieux de 30 ans, et de créer un jeu avec de l'or finement décoré.

Mais n'oubliez pas, le code d'état HTTP 402 - c'est le protocole sous-jacent d'Internet, c'est 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, et même les passerelles de paiement traditionnelles, tout est compatible.

Ce n'est pas une solution d'optimisation pour l'empilement technologique, mais plutôt une “attaque en dimension réduite” pour simplifier le protocole. Plutôt que de s'acharner à adapter diverses méthodes de compatibilité et de confiance au niveau de l'application, il vaut mieux d'abord unifier les normes au 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 effectuer l'autorisation EIP-3009 (ou d'autres normes équivalentes d'autres chaînes), que vous soyez sur Base, Monad, Solana, Avalanche ou BSC, la cross-chain au niveau du protocole est transparente, se manifestant uniquement dans les problèmes de paiement de règlement, ce qui réduit considérablement le coût de la cross-chain.

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 “ouvrir” tout l'écosystème.

Je pense que AA est une ingénierie raffinée issue de la pensée des chercheurs, tandis que le protocole x402 est un pragmatisme imposé par les besoins du marché.

La question est posée, l'ERC-8004 va-t-il suivre le vieux chemin de 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 beaucoup des subventions externes ou du staking, ce sont tous des pièges que l'AA a déjà rencontrés. Si d'autres chaînes doivent être compatibles, il faudra encore ajouter un coût de confiance supplémentaire.

Mais la différence est que, dans le cadre du x402, l'ERC-8004 n'est qu'un outil, et non une norme dominante. Les autres chaînes doivent être compatibles avec le protocole x402, et non pas 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 tourne autour de lui : les portefeuilles doivent être adaptés, les applications doivent être intégrées, les utilisateurs doivent changer leurs habitudes. Cette imposition “de haut en bas”, sans application phare et sans ROI clair, ne peut naturellement pas avancer.

Contrairement à l'ERC-8004. Il n'a pas besoin d'être le protagoniste, car le x402 a déjà résolu le problème le plus crucial : le paiement. L'ERC-8004 n'est qu'une couche de confiance “optionnelle” sur ce réseau de paiement déjà opérationnel.

De plus, l'ERC-8004 profite de l'engouement du x402, ce qui évite d'avoir à construire un écosystème à partir de zéro. Le x402 dispose déjà d'un cercle commercial clair (attraction des fournisseurs, frais pour les facilitateurs), d'une pile technologique complète (protocole HTTP + EIP-3009) et d'un écosystème de projet dynamique, l'ERC-8004 n'a besoin que d'être “prêt à l'emploi”.