Pourquoi les agents d’IA ont-ils besoin d’une identité on-chain ? Comprendre ERC-8004, MCP et A2A

L’identité onchain des agents d’IA désigne l’utilisation d’enregistrements interrogeables sur la blockchain afin d’établir des identifiants numériques permettant de reconnaître, relier et gérer les agents d’intelligence artificielle entre différentes applications. À mesure que les agents d’IA évoluent de simples assistants conversationnels vers des systèmes autonomes capables d’appeler des outils, d’accéder à des données, d’exécuter des tâches et de participer à des activités économiques, l’identité des agents devient une infrastructure essentielle pour les réseaux de collaboration ouverts. ERC-8004 est une norme Ethereum proposée pour répondre à ce besoin. Elle vise à établir des interfaces communes pour l’identité, la réputation et les informations de validation des agents au moyen de registres onchain.

Dans les systèmes logiciels traditionnels, les identités de service reposent généralement sur des comptes de plateforme, des clés API et une gestion interne des autorisations d’entreprise. Ces approches peuvent répondre à la plupart des besoins des agents opérant au sein d’une même organisation ou plateforme. Toutefois, lorsque plusieurs agents d’IA proviennent de développeurs différents, s’exécutent sur des infrastructures différentes et doivent se déléguer des tâches, la découverte de services, la confirmation des relations de contrôle, l’évaluation des performances historiques et la validation des résultats d’exécution deviennent de nouveaux défis techniques.

ERC-8004, MCP (Model Context Protocol) et A2A (Agent2Agent) abordent ces enjeux sous différents angles. MCP permet aux agents de se connecter à des outils et à des données, A2A permet la communication et la collaboration entre agents, et ERC-8004 fournit des mécanismes de découverte d’identité et des signaux de confiance entre plateformes. Comprendre leurs périmètres techniques et leur fonctionnement conjoint aide à expliquer comment les réseaux ouverts d’agents d’IA peuvent évoluer de simples appels d’outils vers des systèmes multi-agents composables.

Points clés

• La valeur centrale de l’identité onchain pour les agents d’IA réside dans la découvrabilité, la vérifiabilité et la collaboration interplateforme. Elle aide les agents créés par différents développeurs et plateformes à établir des liens d’identité interrogeables sans dépendre entièrement d’un seul annuaire de services centralisé.

• ERC-8004 fournit une infrastructure d’identité et de confiance au moyen de l’Identity Registry, du Reputation Registry et du Validation Registry, prenant en charge l’enregistrement des agents, les retours de réputation et la validation des tâches.

• MCP traite principalement de la manière dont les agents utilisent les outils, en connectant des bases de données, des services de recherche, des systèmes de fichiers et des API externes via des interfaces standardisées.

• A2A traite principalement de la manière dont les agents collaborent avec d’autres agents, en prenant en charge la découverte de capacités, la délégation de tâches, l’échange de messages et la gestion du statut des tâches.

• ERC-8004, MCP et A2A ne sont pas des solutions concurrentes. Ils peuvent respectivement gérer l’identité et la confiance, l’accès aux outils et la communication entre agents. Toutefois, un enregistrement onchain ne constitue pas à lui seul une vérification d’identité dans le monde réel et ne garantit pas des résultats d’exécution de tâches fiables.

Pourquoi les agents d’IA ont-ils besoin d’une identité onchain ? Quelles sont les limites des comptes de plateforme traditionnels ?

Le défi d’identité des agents d’IA ne consiste pas simplement à attribuer un nom à un programme. Il exige l’établissement de liens d’identité que d’autres systèmes peuvent reconnaître et vérifier.

Sur les plateformes centralisées, les agents sont généralement identifiés au moyen de comptes de plateforme, de clés API ou d’adresses de service fournies par les développeurs. Les plateformes peuvent gérer les autorisations des utilisateurs, maintenir des annuaires de services et restreindre les violations. Ce modèle fonctionne bien pour les opérations au sein d’une même plateforme. Toutefois, lorsque les agents doivent collaborer entre organisations, les informations d’identité peuvent ne pas être partageables, les évaluations historiques peuvent être difficiles à transférer et la fiabilité d’un service peut dépendre d’une plateforme donnée.

Par exemple, un agent d’analyse de marché développé par une entreprise peut avoir accumulé de nombreux historiques de service sur une plateforme. Lorsqu’il rejoint un autre réseau d’agents, la nouvelle plateforme peut ne pas être en mesure de vérifier directement ces historiques, ce qui oblige le développeur à rétablir l’identité et la réputation de l’agent.

L’identité onchain vise à réduire cette fragmentation. En enregistrant des identifiants, des droits de contrôle et certains signaux de confiance sur une blockchain publique, différentes applications peuvent interroger les mêmes informations d’enregistrement et construire par-dessus leurs propres systèmes de découverte de services et d’évaluation des risques.

Toutefois, l’identité onchain n’exige pas que le modèle d’IA lui-même s’exécute sur une blockchain. L’inférence réelle, l’accès aux bases de données et les appels d’outils peuvent toujours avoir lieu offchain. La blockchain gère principalement l’enregistrement partagé, les enregistrements vérifiables et la coordination de la confiance.

Cela signifie également que l’identité onchain ne peut pas remplacer la vérification d’identité traditionnelle. Une adresse peut prouver qu’une clé donnée est autorisée à effectuer certaines opérations, mais elle ne prouve pas nécessairement que le développeur derrière cette adresse possède des qualifications légitimes. Les cas d’utilisation à haut risque, tels que la finance et la santé, nécessitent toujours une vérification supplémentaire de l’identité légale ainsi qu’une autorisation pour les activités commerciales.

Qu’est-ce qu’ERC-8004 ? Comment établit-il une identité portable pour les agents d’IA ?

ERC-8004, officiellement nommé Trustless Agents, est une norme proposée au sein de l’écosystème Ethereum pour les réseaux d’agents ouverts. Son objectif est de fournir une infrastructure de découverte et de confiance interorganisationnelle aux agents sans exiger de relations de confiance préexistantes.

Le mécanisme d’enregistrement d’identité d’ERC-8004 s’appuie sur ERC-721. Après l’enregistrement d’un agent, un développeur peut obtenir un agentId et utiliser les informations d’enregistrement correspondantes pour associer le nom de l’agent, sa description fonctionnelle, ses points de terminaison de service et les protocoles de communication pris en charge.

Cette conception sépare l’identité d’un agent de son adresse de service spécifique. Par exemple, un agent peut changer de serveur ou mettre à jour son interface A2A tout en conservant son identité enregistrée. Les autres applications n’ont qu’à interroger les informations d’enregistrement pertinentes pour obtenir le point de terminaison de service mis à jour.

ERC-8004 permet également aux informations d’enregistrement de relier différents types de points de terminaison, notamment MCP, A2A, ENS, DID et les adresses de wallet, reliant ainsi l’identité onchain à l’infrastructure Web3 et IA existante.

Son noyau se compose de trois registres :

Le Reputation Registry ne détermine pas automatiquement quels avis sont authentiques ou fiables. Il fournit plutôt des enregistrements de retours interrogeables. Les différentes applications peuvent concevoir leurs propres algorithmes de notation, de filtrage et d’évaluation des risques.

Le Validation Registry permet à des validateurs tiers de vérifier des résultats de tâches spécifiques. Les méthodes de validation peuvent inclure la réexécution, les environnements d’exécution sécurisés (TEE) ou l’apprentissage automatique à divulgation nulle de connaissance (zkML).

Il est important de noter qu’ERC-8004 conserve le statut de Draft sur la page EIP d’Ethereum. Cela n’empêche pas les développeurs de le déployer et de l’expérimenter, mais le statut de sa spécification doit être distingué de son adoption réelle.

Qu’est-ce que MCP ? Comment connecte-t-il les agents d’IA aux outils et données externes ?

MCP (Model Context Protocol) est un protocole ouvert permettant de connecter les applications d’IA à des outils externes, des données et des ressources de contexte.

Sans interface unifiée, les développeurs peuvent devoir écrire une logique d’intégration distincte pour chaque base de données, système de fichiers ou API. À mesure que les agents utilisent davantage d’outils, cette approche peut entraîner une duplication des efforts de développement et une hausse des coûts de maintenance.

MCP réduit la complexité de la connexion de différentes applications d’IA à des capacités externes grâce à une communication standardisée entre clients et serveurs.

Dans l’architecture MCP, les serveurs peuvent fournir aux clients trois grands types de capacités :

• Outils : fonctions exécutables, telles que l’interrogation de bases de données, la recherche d’informations ou l’appel d’API métier.

• Ressources : données de contexte lisibles, telles que des documents, des enregistrements de bases de données et le contenu de fichiers.

• Prompts : modèles de prompts réutilisables pour structurer les interactions liées à des tâches spécifiques.

Par exemple, un agent de recherche crypto peut utiliser MCP pour se connecter à une base de données de données de marché, à des interfaces de données onchain et à un référentiel de recherche. Lorsqu’un utilisateur demande une analyse, l’agent peut appeler les outils pertinents, récupérer les données, puis générer les résultats de recherche.

MCP se concentre sur la standardisation de l’accès aux outils, et non sur l’établissement d’une identité onchain publique.

MCP peut également fonctionner avec des mécanismes d’autorisation traditionnels afin de protéger les services restreints. Pour le transport HTTP, les spécifications pertinentes prennent en charge les flux d’autorisation basés sur OAuth. MCP ne doit donc pas être compris comme étant totalement dépourvu de capacités d’identité ou de contrôle d’accès.

La différence avec ERC-8004 est que l’autorisation de MCP prend principalement en charge des connexions à des outils spécifiques et l’accès aux ressources, tandis qu’ERC-8004 se concentre sur des identités d’agents et des enregistrements de confiance partageables entre plateformes.

Qu’est-ce qu’A2A ? Comment prend-il en charge la collaboration entre agents d’IA ?

A2A (Agent2Agent) est un protocole de communication ouvert destiné à différents systèmes d’agents. Google a initialement dirigé son développement, avant qu’il ne rejoigne ensuite l’écosystème de la Linux Foundation.

Contrairement à MCP, qui connecte principalement des outils, A2A vise à permettre à des agents d’IA développés par différents développeurs et avec différents frameworks de découvrir les capacités les uns des autres, d’échanger des messages, de déléguer des tâches et de gérer leur statut d’exécution de manière standardisée.

Un mécanisme important d’A2A est l’Agent Card. Il s’agit d’un document de métadonnées lisible par machine qui décrit le nom d’un agent, ses capacités, ses compétences, son adresse de service et ses exigences d’authentification.

Lorsqu’un agent doit déléguer une tâche, il peut d’abord lire l’Agent Card de l’autre agent, déterminer s’il dispose des capacités requises, puis initier une demande conformément au protocole.

A2A prend également en charge la gestion du cycle de vie des tâches. Par exemple, une tâche de recherche complexe peut nécessiter un temps considérable. L’agent initiateur peut interroger son statut, recevoir des mises à jour de progression et récupérer les résultats une fois l’exécution terminée.

Cela diffère des requêtes API ordinaires. Les API traditionnelles sont souvent conçues pour des opérations individuelles, tandis qu’A2A met davantage l’accent sur les interactions continues entre agents autour des tâches.

Toutefois, A2A inclut lui aussi des mécanismes de découverte des capacités et d’authentification. ERC-8004 ne comble donc pas une absence totale de fonctionnalités d’identité dans A2A. Il ajoute plutôt des informations d’identité onchain, de réputation et de validation pouvant être partagées entre plateformes.

A2A gère la communication et la collaboration autour des tâches, tandis qu’ERC-8004 peut aider les appelants à évaluer les performances historiques d’un fournisseur de services et les signaux de confiance pertinents avant d’établir une relation de travail.

En quoi ERC-8004, MCP et A2A diffèrent-ils ?

ERC-8004, MCP et A2A traitent de problématiques différentes dans les systèmes d’agents. Tous les trois peuvent apparaître dans le même flux de travail, mais tous les agents d’IA n’ont pas besoin de les utiliser tous.

Les trois peuvent être compris comme trois couches d’un réseau d’agents ouvert.

ERC-8004 fournit des identités et des signaux de confiance interrogeables entre plateformes, MCP connecte les agents aux outils nécessaires à l’exécution des tâches, et A2A aide plusieurs agents à échanger des tâches et des résultats.

Cette répartition signifie également qu’ERC-8004 ne remplace pas les capacités d’appel d’outils de MCP, que MCP ne remplace pas les mécanismes de collaboration sur les tâches d’A2A et qu’A2A n’a pas besoin d’une blockchain pour communiquer.

Leur valeur réside dans la possibilité de les composer selon les besoins métier, plutôt que dans l’exigence d’un ensemble fixe de dépendances techniques.

Comment ERC-8004, MCP et A2A complètent-ils un flux de travail multi-agents ?

Supposons qu’une institution souhaite utiliser des agents d’IA pour générer automatiquement un rapport de recherche sur un cryptoactif. La tâche globale peut impliquer des données de marché, des données onchain, des actualités et une analyse des risques, ce qui nécessite la collaboration de plusieurs agents.

Tout d’abord, l’agent principal de recherche doit trouver un agent spécialisé fournissant des services d’analyse onchain. Il peut interroger les informations d’enregistrement pertinentes via l’Identity Registry d’ERC-8004 afin d’obtenir des descriptions de services et des points de terminaison A2A.

Ensuite, l’agent principal de recherche peut lire les retours historiques dans le Reputation Registry afin d’évaluer si les prestataires de services candidats possèdent une expérience de service pertinente. Pour les tâches d’analyse plus exigeantes, il peut également consulter des enregistrements de validation indépendante.

Après avoir sélectionné les candidats, l’agent principal de recherche initie une tâche avec l’agent retenu via A2A, en demandant une analyse des récents flux de fonds onchain pour un actif donné.

Après réception de la tâche, l’agent délégué utilise MCP pour appeler des outils de données blockchain, des bases de données ou des API externes, récupérer les informations nécessaires et effectuer l’analyse.

Une fois la tâche terminée, l’agent délégué renvoie les résultats de recherche via A2A. L’agent principal de recherche peut ensuite intégrer d’autres informations et générer le rapport final.

Si l’application a intégré le mécanisme de retours d’ERC-8004, elle peut également enregistrer une évaluation de la qualité du service après la fin de la tâche afin que de futurs collaborateurs puissent s’y référer.

Exemple de collaboration entre agents d’IA interprotocoles

L’élément clé de ce scénario n’est pas d’écrire toutes les données sur la blockchain, mais d’attribuer les différentes fonctions à l’infrastructure appropriée.

Les signaux d’identité et de confiance peuvent être partagés via des registres onchain, A2A gère la communication pour les tâches complexes, et MCP gère l’accès aux données et l’exécution des outils.

Cette conception en couches préserve l’efficacité d’exécution des systèmes Internet traditionnels tout en permettant à la collaboration interorganisationnelle d’utiliser une infrastructure de confiance publique.

Comment ERC-8004 traite-t-il la réputation et la validation des agents interplateformes ?

Un défi important dans les réseaux d’agents ouverts consiste à permettre aux agents de réutiliser les enregistrements de performances de service accumulés sur différentes plateformes.

Si la réputation est entièrement gérée par une plateforme centralisée, un agent peut ne plus avoir accès à ses enregistrements d’avis existants après avoir quitté cette plateforme. Une nouvelle plateforme peut également avoir des difficultés à vérifier indépendamment la source des données historiques.

Le Reputation Registry d’ERC-8004 fournit une interface standardisée pour ce problème, permettant de relier les retours des clients à l’identité onchain correspondante.

Toutefois, des enregistrements publics ne rendent pas automatiquement les avis fiables. Des développeurs malveillants peuvent créer un grand nombre de comptes liés afin de fournir de faux retours pour les agents qu’ils contrôlent. Des concurrents peuvent également tenter de manipuler les évaluations.

Les applications doivent donc toujours filtrer et pondérer les signaux de réputation en fonction des sources d’avis, du comportement historique et des schémas anormaux.

Pour les tâches plus importantes, la réputation seule peut ne pas suffire à établir la confiance. Par exemple, lorsqu’un agent fournit une analyse des risques de smart contracts, les clients peuvent vouloir non seulement connaître ses avis passés, mais aussi confirmer que ses méthodes de détection et ses résultats d’analyse ont été vérifiés de manière indépendante.

Le Validation Registry permet aux systèmes concernés d’enregistrer les demandes et résultats de validation, puis de les relier à des identités d’agents spécifiques.

Toutefois, la qualité de la validation dépend des méthodes utilisées et des validateurs eux-mêmes. Un TEE prouve les propriétés d’un environnement d’exécution spécifique, tandis que zkML prouve qu’un processus de calcul donné satisfait à des conditions définies. Ni l’un ni l’autre ne signifie que la décision métier finale est nécessairement correcte.

La force d’ERC-8004 réside donc dans la prise en charge de combinaisons de mécanismes de confiance, plutôt que dans la fourniture d’un score unique déterminant automatiquement la sécurité de chaque agent.

Pourquoi ERC-8004 utilise-t-il la blockchain au lieu d’un annuaire d’agents centralisé ?

Les annuaires d’agents centralisés ont une réelle utilité. Pour les systèmes internes d’entreprise, une plateforme de gestion unifiée facilite généralement le contrôle d’accès, l’évaluation des services et la maintenance de la sécurité.

Toutefois, entre organisations, différentes plateformes peuvent utiliser des normes d’enregistrement et des systèmes d’évaluation différents. Les informations d’identité et les données de réputation détenues par une plateforme peuvent ne pas être directement interrogeables ou réutilisables par une autre.

La blockchain fournit une approche de tenue de registres partagée, qui permet à différentes applications de construire des services autour des mêmes informations d’enregistrement publiques.

ERC-8004 utilise ERC-721 comme fondement de l’enregistrement d’identité, en reliant les identités des agents aux relations de propriété et de contrôle onchain. Les informations d’enregistrement peuvent également renvoyer vers des métadonnées offchain, évitant ainsi de devoir stocker directement sur la blockchain toutes les descriptions et données de service.

Cette approche offre un certain degré de composabilité. Par exemple, des développeurs tiers peuvent créer des moteurs de recherche d’agents, des plateformes d’analyse de réputation ou des services de validation des tâches sans dépendre entièrement de la plateforme d’enregistrement d’origine.

Toutefois, la blockchain introduit également de nouveaux coûts et une complexité supplémentaire, notamment les frais de transaction, la coordination des identités entre réseaux et les questions de confidentialité liées aux enregistrements publics.

En outre, même si les identités onchain peuvent être interrogées, les points de terminaison de services associés peuvent toujours échouer, et les métadonnées peuvent contenir des erreurs ou du contenu trompeur. Un registre public ne peut pas remplacer une surveillance continue des services.

La blockchain est donc mieux adaptée au partage interorganisationnel et à la coordination de la confiance, mais pas nécessairement à la gestion de chaque aspect de l’exploitation et de l’administration des agents.

En quoi ERC-8004 diffère-t-il d’ENS et de DID ?

ENS (Ethereum Name Service) et DID (Decentralized Identifier) concernent également l’identité numérique, ce qui peut les rendre faciles à confondre avec ERC-8004.

ENS fournit principalement des noms lisibles par l’humain et la résolution des enregistrements associés. Par exemple, une adresse Ethereum peut être liée à un nom ENS facilement reconnaissable, ce qui réduit la difficulté d’utilisation des adresses complexes.

DID désigne une catégorie de spécifications d’identifiants décentralisés pouvant être combinées à différentes méthodes DID et mécanismes de vérification afin d’établir des systèmes d’identité numérique.

ERC-8004 se concentre plus précisément sur les besoins applicatifs des agents d’IA. Au-delà des identifiants, il doit relier les capacités de service, les points de terminaison de communication, les retours historiques et les informations de validation des tâches.

Ces mécanismes ne s’excluent pas mutuellement.

Un agent peut disposer simultanément d’une identité ERC-8004, d’un nom ENS et d’un identifiant DID, les données pertinentes étant liées dans ses informations d’enregistrement.

La différence est qu’ENS et DID ne fournissent pas spécifiquement les registres de réputation des agents et de validation des tâches définis par ERC-8004.

Quels défis de sécurité et de confidentialité l’identité onchain pose-t-elle aux agents d’IA ?

L’identité onchain peut faciliter l’interrogation des enregistrements, mais elle ne résout pas intrinsèquement les problèmes de sécurité des réseaux ouverts.

Le premier risque est l’abus d’identité. La création d’une identité onchain ne nécessite pas forcément des contrôles rigoureux de l’identité dans le monde réel. Des participants malveillants peuvent donc enregistrer un grand nombre d’agents afin de fabriquer des réseaux de services ou des enregistrements de réputation.

Le deuxième risque concerne le contrôle de l’identité. Si la clé de contrôle d’un agent est volée, un attaquant peut modifier ses informations d’enregistrement ou effectuer des opérations non autorisées. Les développeurs d’agents à forte valeur doivent appliquer une gestion des clés plus stricte et une séparation des autorisations.

Le troisième risque est lié à la sécurité des métadonnées. Les informations d’enregistrement ERC-8004 peuvent renvoyer vers des points de terminaison de services externes, mais ces points de terminaison peuvent être attaqués, remplacés ou arrêtés. Les clients ne doivent pas faire confiance au contenu renvoyé uniquement parce qu’une adresse apparaît dans un registre.

Le quatrième enjeu est la confidentialité. Les enregistrements de retours et de validation onchain peuvent rester publics sur le long terme. Si les développeurs écrivent directement onchain les identités de clients, les détails sensibles des tâches ou des données commerciales, ils risquent de créer une exposition irréversible d’informations.

Une conception plus appropriée consiste donc à enregistrer onchain les identifiants, empreintes et signaux de confiance nécessaires, tout en conservant les données métier sensibles dans des systèmes offchain dotés de contrôles d’accès appropriés.

Enfin, le modèle de confiance lui-même présente des limites. Un agent performant pour de simples requêtes de données peut ne pas être en mesure d’exécuter de manière sûre des opérations financières complexes. Les applications doivent choisir différents niveaux de validation en fonction de la valeur de la tâche, des conséquences des erreurs et de la sensibilité des données.

Les agents impliqués dans des transferts d’actifs ou l’exécution de transactions doivent également disposer d’autorisations de wallet distinctes, de limites de fonds et de conditions d’approbation humaine. L’identité onchain ne doit pas être considérée comme une autorisation de déplacer des fonds.

Comment ERC-8004, MCP et A2A affecteront-ils Web3 et l’économie des agents d’IA ?

Le développement d’ERC-8004, MCP et A2A reflète l’expansion progressive de l’infrastructure des agents d’IA, passant des appels d’outils au sein d’applications individuelles à des réseaux de collaboration couvrant les plateformes et les organisations.

MCP réduit la complexité de la connexion des agents aux données et outils externes, A2A fournit une approche commune des interactions de tâches entre agents, et ERC-8004 vise à réduire la dépendance totale à une plateforme unique pour les informations d’identité et de confiance.

Pour l’écosystème Web3, cette architecture peut permettre de nouvelles applications, notamment des annuaires d’agents décentralisés, l’analyse de réputation onchain, la validation des tâches d’agents et des systèmes de paiement et de règlement pour les services automatisés.

Combinés à des protocoles de paiement tels que x402, les agents peuvent également payer des données, des ressources de calcul et d’autres services numériques après avoir reçu une autorisation, créant ainsi un flux de travail plus complet allant de la découverte de services à l’exécution des tâches, au paiement et aux retours.

Toutefois, l’adoption de ces normes ne signifie pas que chaque agent d’IA doit émettre un token ou que chaque activité d’agent doit s’exécuter sur une blockchain.

Les applications apportant une véritable valeur doivent toujours démontrer des avantages par rapport aux solutions existantes en matière de coût, d’efficacité, de sécurité et d’interopérabilité interplateforme.

À long terme, le développement de réseaux d’agents ouverts peut étendre le rôle de la blockchain au-delà de la tenue de registres d’actifs et de l’infrastructure de règlement, vers l’identité des machines et la coordination de la confiance.

Résumé

Les agents d’IA ont principalement besoin d’une identité onchain parce que les réseaux d’agents ouverts sont confrontés à des défis liés à la découverte d’identité interplateforme, à la portabilité de la réputation et à la validation des tâches.

Les comptes de plateforme traditionnels et les clés API peuvent répondre aux besoins d’identité et d’autorisation au sein de systèmes spécifiques, mais les informations associées sont souvent difficiles à partager entre organisations. Grâce aux registres d’identité, de réputation et de validation onchain, ERC-8004 établit une infrastructure de confiance composable pour différentes plateformes.

MCP et A2A traitent respectivement de la connectivité des agents aux outils et de la collaboration intersystème. MCP permet aux agents d’accéder aux données et d’exécuter des opérations d’outils, tandis qu’A2A permet à différents agents de découvrir des capacités, de déléguer des tâches et d’échanger des résultats.

Les trois ne se substituent pas les uns aux autres. Ils peuvent être combinés selon les besoins pratiques.

À mesure que les agents d’IA participent de plus en plus à l’acquisition de données, à la recherche financière, aux opérations d’entreprise et aux services automatisés, l’identité, la confiance, la communication et les paiements peuvent former un système technique plus complet. Toutefois, l’identité onchain n’établit pas la fiabilité dans le monde réel, et une réputation publique ne garantit pas la qualité du service. Les applications pratiques nécessitent toujours une validation robuste de la sécurité, une gestion des autorisations et des contrôles des risques.

ERC-8004 traite de la coordination de l’identité et de la confiance dans les réseaux ouverts, MCP connecte les outils et les données, et A2A connecte différents agents. Ensemble, ils fournissent une base pour la collaboration interplateforme entre agents d’IA.

FAQ

Pourquoi les agents d’IA ont-ils besoin d’une identité onchain ?

L’identité onchain fournit aux agents des identifiants interrogeables entre plateformes et pouvant être liés à des informations de service, des retours historiques et des enregistrements de validation, réduisant ainsi la dépendance à un annuaire centralisé unique.

Qu’est-ce qu’ERC-8004 ?

ERC-8004 est une proposition de norme Ethereum pour les agents d’IA qui prend en charge la découverte des agents et l’évaluation de la confiance au moyen de registres d’identité, de réputation et de validation.

Quelle est la principale différence entre ERC-8004 et MCP ?

ERC-8004 traite principalement des informations d’identité et de confiance interplateformes, tandis que MCP traite principalement de la manière dont les applications d’IA se connectent à des outils externes, des données et des ressources de contexte.

Quelle est la différence entre MCP et A2A ?

MCP se concentre sur les interactions entre les agents et les outils, tandis qu’A2A se concentre sur la communication, la délégation de tâches et la collaboration entre différents agents.

Pourquoi ERC-8004 est-il nécessaire si A2A prend déjà en charge l’Agent Card ?

L’Agent Card peut décrire les capacités des agents et les points de terminaison de service, tandis qu’ERC-8004 fournit en outre des interfaces permettant le partage interplateforme de l’identité onchain, des retours de réputation et de la validation des tâches.

ERC-8004 exige-t-il que les agents d’IA s’exécutent sur une blockchain ?

Non. L’inférence des modèles d’IA et l’exécution des outils peuvent continuer à avoir lieu offchain. La blockchain est principalement utilisée pour l’enregistrement d’identité et les enregistrements de confiance associés.

Le fait de disposer d’une identité ERC-8004 signifie-t-il qu’un agent d’IA est sûr et fiable ?

Non. Un enregistrement onchain prouve uniquement le lien entre une identité donnée et ses enregistrements d’inscription. L’évaluation des risques exige toujours une validation du service, une analyse de la réputation et des contrôles de sécurité.

ERC-8004, MCP et A2A peuvent-ils être utilisés avec x402 ?

Oui. ERC-8004 fournit des signaux d’identité et de confiance, MCP et A2A gèrent l’accès aux outils et la collaboration autour des tâches, et x402 peut fournir des capacités de paiement pour les services payants.