Série débutants Web3 : ERC8004 : cette narration Web3+AI pourrait vous faire savourer une livraison chaude

ERC8004 est une norme de protocole sur Ethereum, définissant un ensemble de standards permettant à des agents de bâtir des relations de confiance basées sur la blockchain, fusionnant la narration A2A (Agent to Agent) avec celle du Web3. Cet article vous présente la logique derrière cette grande narration Web3+AI.

L’adresse du protocole a été créée en août et est encore en phase de révision. Nous analyserons ici la problématique que ce protocole cherche à résoudre, en expliquant simplement ses standards, et en évoquant enfin la portée potentielle de ce protocole. La lecture complète dure environ 15 minutes, n’hésitez pas à sauvegarder cette page.

Problématique abordée

Tout d’abord, voyons quel problème ce protocole tente de résoudre :

En résumé, il s’agit de résoudre la problématique de confiance lors du processus A2A (Agent appelant un Agent), par exemple si je possède un assistant IA nommé Xiao A, qui est un agent intelligent. Je lui demande de commander une livraison fiable. Mais mon agent n’est pas spécialisé dans cette tâche (car interface avec livreurs et commerçants est un gros travail, qu’un petit assistant IA ne peut pas gérer). Que faire ?

Dans ce cas, il peut faire appel à d’autres agents intelligents.

Mais alors, comment mon agent peut-il trouver un autre agent fiable pour l’aider ? Faut-il un organisme de confiance ? L’humain aussi utilise des plateformes centralisées comme Taobao pour ses transactions, qui jouent ce rôle de confiance. Mais la centralisation a ses limites, et dans l’ère des agents, ce problème devient encore plus critique. Pour optimiser leur efficacité, les agents ne peuvent pas tout déléguer à des centres de confiance, sinon cela revient à laisser l’humain freiner l’IA. Même en utilisant des organismes de validation centralisés, il faut aussi faire appel à des organismes de confiance décentralisés, spécialisés dans le travail basé sur l’IA, pour exploiter au maximum leur potentiel.

Donc, si l’on pouvait disposer d’une donnée décentralisée et fiable, permettant de trouver des agents fiables, cela augmenterait considérablement l’efficacité. C’est ainsi qu’est né le protocole 8004.

Cela paraît logique, n’est-ce pas ? Passons maintenant à la conception de l’ERC8004 selon cette logique.

Analyse de la solution proposée par le protocole

Il s’agit ici d’une analyse technique détaillée du protocole, sans entrer dans les détails des interfaces de contrats ou des paramètres spécifiques, afin de rendre cela accessible. Pour les détails précis, vous pouvez consulter la documentation officielle. Nous allons expliquer simplement comment ce protocole résout concrètement les problématiques évoquées.

Techniquement, ERC8004 définit essentiellement trois types d’interfaces de contrats :

Identity Registry (Registre d’Identité) : basé sur ERC721 (Jeton non fongible, NFT), il sert à enregistrer des agents. Chaque agent est un NFT, permettant d’accéder à ses informations.

Reputation Registry (Registre de Réputation) : pour gérer la réputation des agents.

Validation Registry (Registre de Validation) : pour la vérification des agents.

En somme, on peut considérer ces trois contrats comme trois institutions opérant sur la blockchain.

Premier organisme : l’agent ouvre un compte, comme ouvrir un commerce de restauration.

Deuxième organisme : chargé de collecter des évaluations, comparable à des plateformes comme Dianping ou GaoDe.

Troisième organisme : une entité indépendante de vérification, comme un organisme de contrôle qualité, une agence sanitaire, etc.

🌐 Un exemple de processus concret

Prenons l’exemple de commander un repas sans huile de rebut : votre assistant Xiao A cherche un fournisseur fiable.

Recherche de partenaires : Xiao A consulte le registre d’identités pour trouver un agent « B » bien noté, puis vérifie ses évaluations passées.

Établissement d’une confiance initiale : Xiao A consulte le registre de réputation pour voir comment d’autres partenaires évaluent B, et décide de l’embaucher.

Exécution et vérification : si la commande est cruciale, Xiao A ou vous pouvez engager un vérificateur indépendant « C » via le registre de validation. C vérifiera la précision des rapports de B et publiera ses résultats.

Paiement et feedback : vous payez Xiao A via le protocole x402 (mécanisme de paiement connecté entre la chaîne et le hors-chaîne, voir notre ancien article sur x402). Xiao A paie B et C. Enfin, vous laissez une bonne note pour Xiao A et B, et ces interactions renforcent leur réputation dans le registre.

En résumé, ERC-8004, via l’interaction de ces trois contrats, construit un environnement décentralisé et fiable pour la collaboration entre agents, permettant d’échanger des services et des valeurs en toute sécurité, comme dans le marché traditionnel.

Registre d’identité

Ce contrat est essentiellement un contrat NFT, comprenant les fonctions de transfert de ERC721, avec une extension pour définir des métadonnées :

Il inclut le nom, l’image, la description de l’agent, ainsi que son adresse de contact.

Il définit aussi la méthode d’enregistrement « register » et les événements associés (puisque ERC721 ne prévoit pas de méthode « mint » par défaut, celle-ci est spécifique à ERC8004).

Registre de réputation

Ce contrat doit être déployé en recevant en paramètre l’adresse du contrat NFT, qui lui est associé de manière unique.

Il propose plusieurs fonctions :

giveFeedback : pour donner une note à un NFT (agent), de 0 à 100 (agentId correspond au TokenID du NFT). Elle nécessite un paramètre « feedbackAuth », une signature de l’agent lors de l’acceptation de la tâche.

revokeFeedback : pour retirer une évaluation.

appendResponse : pour ajouter des réponses complémentaires (avec un format précis), par exemple une adresse hors chaîne + un hash de vérification.

Il existe également des méthodes de lecture pour consulter les évaluations.

Format pour les informations complémentaires : (non précisé ici)

Registre de validation

Comme pour le registre de réputation, il doit recevoir en paramètre l’adresse du registre d’identité, qui est la seule association. L’appel doit être effectué par le propriétaire de l’agent (Owner du NFT) et comporte :

validationRequest : pour lancer une demande de validation.

validationResponse : pour répondre à cette demande.

Les détails précis ne seront pas abordés ici, mais l’essentiel est que, grâce à ces trois contrats, ERC8004 établit un mécanisme d’évaluation transparent et décentralisé pour agents, facilitant leur recherche de partenaires fiables, en proposant une solution de confiance Web3 pour les interactions A2A.

Notre mise en pratique

En intégrant la conception ERC-8004, nous avons développé avec Pharos et Jovay un service Web3 sans confiance (Trustless), permettant d’attribuer aux utilisateurs une identité fiable dans le Web3, appelée « Agent DID ». Nous avons également renforcé cette plateforme avec des vérifications TEE/ZK de niveau financier, en vue de futures applications comme la validation sécurisée pour les transactions machine à machine dans des contextes financiers.

Perspectives d’avenir

Tout cela semble prometteur, mais comporte aussi des défis. Ces défis peuvent aussi devenir des opportunités. Voyons ce que l’avenir pourrait réserver.

D’abord, même si les données sont sur la chaîne, leur transparence et leur immutabilité ne garantissent pas leur fiabilité absolue. La confiance pourrait reposer sur des validateurs reconnus, représentant des institutions officielles. Ces validateurs fiables peuvent utiliser l’historique blockchain et d’autres moyens pour fournir des informations plus crédibles. Par exemple, si quelqu’un utilise un nouveau compte pour donner de mauvaises évaluations, sa crédibilité en pâtira.

Selon cette logique, de nombreuses applications peuvent découler de ce protocole :

Vous pouvez créer un service dédié à la gestion d’agents sur la chaîne, par exemple déployer un contrat pour votre agent, permettant diverses opérations selon ce protocole. Je peux aussi offrir ce service via un MCP.

Vous pouvez créer une « rue des délices » sur la chaîne, où tout le monde peut enregistrer ses agents (par exemple, un robot de poulet frit). Si cette plateforme a beaucoup de trafic, elle pourra facturer des frais d’inscription. C’est similaire à l’actuel ENS (Ethereum Name Service), qui n’est qu’un registre étendu.

Vous pouvez aussi créer un « Black Pearl de la restauration » ou un « Michelin » décentralisé, pour évaluer et noter les établissements, moyennant quelques frais.

En résumé, tout ce qui se fait hors chaîne peut être transféré sur la chaîne, permettant aux agents de travailler dans un univers blockchain.

Que pensez-vous de tout cela ? Personnellement, je trouve cela très intéressant.

Cet article a été rédigé par Fisher (@yudao1024) de ZAN Team (compte X @zan_team).