Original | Odaily Planet Daily(@OdailyChina)
Auteur|Azuma(@azuma_eth)
Le 10 mars, l'équipe dAI de la Fondation Ethereum, spécialisée dans la promotion de « l'intégration profonde de l'intelligence artificielle (IA) et de la blockchain », a lancé aujourd'hui, en collaboration avec Virtuals Protocol, une nouvelle norme ERC-8183.
Davide Crapis, responsable de l'IA à la Fondation Ethereum, a déclaré à propos de cette norme : « L'ERC-8183 est l'un des composants manquants dans le système économique d'Agent ouvert que la communauté Ethereum construit. Cette norme peut être utilisée en combinaison avec x402 et ERC-8004 pour jouer un rôle d'infrastructure dans les interactions sécurisées entre Agents. » L'équipe dAI soutiendra l'adoption de l'ERC-8183 et s'efforcera d'en faire une norme neutre.
Que cherche à résoudre l'ERC-8183 ?
Selon l'article de présentation publié par Virtuals Protocol, l'ERC-8183 est conçu pour les transactions commerciales entre Agents IA. Cette norme définit un ensemble de règles on-chain permettant à deux Agents qui ne se font pas confiance de compléter un processus commercial tel que « embauche-livraison-règlement », sans dépendre d'une plateforme centralisée.
Le problème central que l'ERC-8183 tente de résoudre est le suivant : lorsque des Agents s'embauchent et collaborent mutuellement, comment finaliser la transaction sans plateforme, sans cadre légal et sans arbitrage humain ?
Par exemple, supposons qu'un Agent A, orienté marketing, souhaite embaucher un autre Agent B, spécialisé dans la génération d'images, pour créer une série d'affiches promotionnelles. Ici se pose un problème de confiance commerciale — les deux parties ne se connaissent pas et n'ont pas de base de confiance. Quand exactement le paiement doit-il avoir lieu ? Si A paie d'abord, B pourrait faire défaut ou rendre un travail non conforme ; si B travaille d'abord, A pourrait refuser de payer la rémunération...
Dans le monde Internet traditionnel, les utilisateurs et les commerçants sont confrontés à une confiance commerciale similaire, et les plateformes y jouent un rôle clé d'intermédiaire — la plateforme est responsable de la mise en séquestre des fonds de A, de juger si le service de B est terminé ou non, et du déblocage final des fonds. Les plateformes que nous connaissons bien, comme Taobao,京东,美团,滴滴, sont essentiellement ce type d'intermédiaire.
Ce que la Fondation Ethereum et Virtuals Protocol veulent faire, c'est d'abstraire la fonction de la plateforme en un protocole on-chain via l'ERC-8183, en la faisant exécuter par des smart contracts, jouant ainsi un rôle d'intermédiaire décentralisé dans l'économie des Agents.
Décomposition du mécanisme de travail de l'ERC-8183
Le mécanisme de fonctionnement de l'ERC-8183 n'est pas compliqué. Cette norme introduit un nouveau concept appelé Job (vous pouvez le comprendre comme une « tâche »). Chaque Job peut être considéré comme une transaction commerciale complète, comprenant trois rôles distincts :
- Client : Le « client », simplement l'Agent qui publie les différentes tâches ;
- Provider : Le « prestataire de services », l'Agent responsable de terminer la tâche ;
- Evaluator : L'« évaluateur », le rôle le plus particulier, responsable de juger si la tâche est terminée.
Il est nécessaire d'expliquer ici plus en détail l'Evaluator, l'introduction de ce rôle est la conception la plus centrale de l'ERC-8183. Dans cette norme, l'Evaluator est uniquement défini comme une adresse on-chain (address), mais d'un point de vue plus large, cette adresse peut correspondre à différentes formes d'exécution.
- Pour des tâches subjectives comme la rédaction, le design ou l'analyse, l'Evaluator peut être un Agent IA qui lit le résultat soumis, le compare aux exigences initiales de la tâche, puis porte un jugement ;
- Pour des tâches déterministes comme le calcul, la génération de preuves ou la conversion de données, l'Evaluator peut être un smart contract encapsulant un vérificateur zero-knowledge (ZK verifier). Le Provider soumet une preuve, l'Evaluator la vérifie on-chain et appelle automatiquement « complete » ou « reject » pour terminer ou rejeter la tâche ;
- Dans des scénarios de tâches à haute valeur ou à haut risque, l'Evaluator peut également être un compte multi-signature, un DAO, ou un cluster de validation soutenu par un mécanisme de staking.
L'ERC-8183 ne fera pas de distinction entre ces différentes formes. La couche protocolaire ne se soucie que d'une chose — si une adresse appelle « complete » ou « reject », peu importe que cette adresse exécute un Agent IA piloté par un LLM ou un circuit ZK, cela ne relève pas du champ d'application du protocole.
Revenons au Job. Le cycle de vie de chaque Job aura les quatre états suivants, correspondant également aux différents processus du fonctionnement de l'ERC-8183.
- Open : Le Client crée le Job durant cette phase, publie la tâche et précise les exigences ;
- Funded : Le Client transfère la commission vers une adresse de séquestre smart contract, et non directement au Provider ;
- Submitted : Le Provider termine le travail et soumet la preuve ;
- Terminal (Completed / Rejected / Expired) : L'Evaluator est responsable de l'examen de la tâche, juge si la tâche est terminée (Completed ou Rejected) en fonction du résultat de l'audit et transfère les fonds respectivement au Client ou au Provider ; si aucun Provider ne répond ou ne termine la tâche dans le délai requis, les fonds sont remboursés au Client.
Outre ce processus standard, l'ERC-8183 peut également implémenter des fonctionnalités dérivées supplémentaires via des fonctions d'extension modulaires appelées Hooks, pour correspondre aux cas d'usage commerciaux complexes du monde réel. Les Hooks sont des smart contracts optionnels ajoutés lors de la création du Job, ils peuvent exécuter une logique personnalisée avant et après les différents cycles de vie du Job, comme des seuils de réputation, des mécanismes d'enchères, la répartition des frais, ou d'autres exigences spéciales.
Quelle est la différence entre ERC-8183, x402 et ERC-8004 ?
De x402 à ERC-8004, et maintenant à ERC-8183, les lecteurs moins familiers pourraient être perplexes, se demandant pourquoi il faut créer quelque chose de nouveau si souvent. Mais en réalité, ces trois éléments se situent dans trois maillons différents du système économique des Agents IA et visent à résoudre des problèmes distincts.
x402 est un protocole de paiement HTTP, il cherche à résoudre le problème de permettre à un Agent IA de payer directement comme s'il appelait une API ; ERC-8004 est une norme d'identité et de réputation pour les Agents IA, il résout le problème de comment juger si un Agent est fiable ; ERC-8183 s'adresse quant à lui à l'étape de la transaction commerciale, cherchant à résoudre le défi de comment faire en sorte que deux Agents qui ne se font pas confiance puissent conclure une transaction.
Pour résumer en une phrase : x402 s'occupe de « comment payer » ; ERC-8004 s'occupe de savoir « qui est l'autre partie, est-elle fiable » ; ERC-8183 s'occupe de traiter « comment effectuer une transaction en toute confiance ».
Les trois ne sont pas en concurrence, mais complémentaires. Ils visent ensemble le même objectif — construire un système économique d'Agents IA décentralisé, capable de fonctionner de manière autonome.
