
ERC-8004 : l'identité agent qui rend la confiance mobile
L'identité de l'agent ERC-8004 est un enregistrement d'identité sur la chaîne pour les agents IA autonomes qui utilise un jeton ERC-721 comme identifiant durable et pointe vers une carte d'agent lisible par machine décrivant les points de terminaison et les préférences de confiance.
La norme ancre également des retours portables et une vérification tierce optionnelle dans deux registres distincts afin que la confiance puisse être auditée et réutilisée à travers les applications et les chaînes.
Points clés
- L'ERC-8004 spécifie trois registres de contrats intelligents singleton par chaîne : Identité, Réputation et Validation.
- Le Registre d'Identité crée un ERC-721 par agent et l'URI du jeton pointe vers un fichier de carte d'agent hors chaîne, généralement hébergé à /.well-known/agent-card.json.
- La réputation est un canal de retour d'information contrôlé : les soumissions nécessitent une pré-autorisation cryptographique de l'agent et stockent un score limité de 0 à 100 ainsi qu'une URI et un hachage KECCAK-256.
- La validation est apportez votre propre preuve : le Registre de Validation enregistre les demandes et les résultats avec des URIs de preuve, tandis que le niveau d'assurance dépend du backend choisi.
L'identité de l'agent ERC-8004 en un coup d'œil
La manière la plus rapide de comprendre ce qu'est l'identité de l'agent erc-8004 est de cesser de penser "NFTpour les agents" et de commencer à penser "fichier d'intégration sur la chaîne." L'ERC-721 est le numéro de compte. La charge utile utile est la carte d'agent et les deux grands livres qui se trouvent à côté : un registre de réputation pour des retours contrôlés et un registre de validation pour des pistes de vérification tierces.
ERC-8004 n'est explicitement pas un rail de paiement et n'est pas un standard de jeton portant de la valeur. C'est une couche de coordination destinée à se composer avec des systèmes de règlement plutôt qu'à les remplacer.
Ce choix de portée est important car il maintient l'identité, le retour d'information et la vérification comme des primitives neutres que n'importe quel portefeuille, marché ou couche d'exécution peut lire sans hériter d'un modèle de facturation spécifique.
Le problème qu'il vise est la confiance entre contreparties pour les logiciels autonomes. Les agents peuvent déjà communiquer entre eux via des protocoles de communication tels que le protocole Agent-à-Agent (A2A) de Google et le Protocole de Contexte de Modèle (MCP) d'Anthropic.
La messagerie ne répond pas aux questions qu'une contrepartie doit se poser avant de laisser un agent faire quoi que ce soit de coûteux : qui le contrôle, où il peut être joint, ce qu'il a fait auparavant et si quelqu'un d'indépendant peut attester de son travail.
C'est le coin de l'« identité crypto d'agent » : l'ERC-8004 standardise l'emplacement des signaux d'identité et de confiance afin qu'ils soient portables. Un portefeuille ou un service peut mettre en œuvre un ensemble de vérifications contre les données ERC-8004 et les appliquer de manière cohérente à de nombreux agents, au lieu d'incorporer la confiance dans un annuaire propriétaire.
Comment le registre d'identité représente les agents
Trois choses se produisent entre l'enregistrement d'un agent par un opérateur et la possibilité pour une contrepartie de le référencer.
1. Le Registre d'Identité crée un jeton d'identité ERC-721 pour l'agent. La propriété et le transfert suivent les modèles normaux ERC-721, ce qui rend les changements de garde et d'opérateur lisibles sur la chaîne. 2. L'URI du jeton résout vers un fichier d'enregistrement ou de métadonnées hors chaîne, généralement servi à /.well-known/agent-card.json. Cette carte d'agent est le paquet lisible par machine que d'autres systèmes analysent. 3.
L'ID du jeton résout vers une référence indépendante de la chaîne : un CAIP-10.adresseplus une chaîne de domaine, conçue pour que le même agent puisse être référencé de manière cohérente à travers les réseaux.
La carte d'agent est l'endroit où l'« identité d'agent onchain » devient utilisable pour les logiciels. Les sources la décrivent comme un fichier semblable à une carte de visite qui peut déclarer le nom et la description de l'agent, les points de terminaison pris en charge (A2A, MCP ou HTTPS propriétaire), les modèles de confiance qu'il accepte et les agrégateurs de réputation qu'il considère comme autorisés.
Ce dernier champ est facile à manquer, mais c'est le pont entre les données brutes.attestationsà la politique. Un portefeuille peut décider quels agrégateurs il reconnaît, puis évaluer le même ensemble de données sous-jacent différemment.
C'est aussi là que le terme « sans confiance » est mal interprété.agent IAne rend pas un agent sûr par magie. Il rend le pointeur d'identité, les points de terminaison et les préférences de confiance lisibles à un endroit standard afin qu'une contrepartie puisse appliquer des règles avant de diriger du travail ou de régler quoi que ce soit.
Signaux de réputation et de validation pour la confiance
Le Registre de réputation est conçu comme un canal de rétroaction contrôlé, pas comme un site d'avis ouvert. Un client ne peut pas simplement se présenter et inonder un agent d'évaluations. Les soumissions de réputation sont soumises à une pré-autorisation cryptographique de l'agent serveur, utilisant EIP-191 pour les EOAs et ERC-1271 pour les clients de contrats intelligents.
L'autorisation comprend un horodatage d'expiration et un plafond d'index, qui sont destinés à réduire les rejouements et le spam.
Une fois autorisé, le client soumet un tuple de rétroaction limité : un score de 0 à 100, des balises optionnelles, une URI pointant vers une documentation hors chaîne, et un hachage KECCAK-256 qui lie l'enregistrement sur chaîne à cette documentation. Le score limité est le primitif qui peut être interrogé à moindre coût. L'URI et le hachage sont leauditcrochet pour quiconque souhaite inspecter les preuves.
Allium a signalé 401 soumissions de rétroaction au cours des deux premières semaines après le lancement, ce qui est un signal précoce que le primitif « limité mais portable » est utilisé. C'est aussi un rappel que le volume de réputation se concentrera probablement sur des surfaces d'exécution moins chères au fil du temps, car les retours fréquents surEthereum le mainnet est contraint par les coûts.
La validation est le deuxième registre, et elle est intentionnellement optionnelle et hétérogène. Le registre de validation enregistre les demandes de vérification et les résultats, y compris les URI de preuve, mais il ne mandate pas une technique unique.
Les sources décrivent des backends pluggables tels que la réexécution basée sur le staking, les environnements d'exécution de confiance (TEE), et les preuves à divulgation nulle de connaissance.Le registre standardise la piste d'audit afin qu'une contrepartie puisse voir ce qui a été demandé, qui a validé et quelles preuves ont été publiées, puis décider si ce modèle d'assurance est acceptable.
Où l'identité de l'agent s'inscrit dans les piles
L'ERC-8004 se situe en dessous de l'exécution, et ce placement est ce qui transforme l'« identité de l'agent » en plomberie exécutoire. L'ERC-8196, une norme de portefeuille authentifié pour agents AI, cadre une pile de confiance modulaire où l'ERC-8004 est la couche 1 (Registre), l'ERC-8126 est la couche 2 (Vérifier), et l'ERC-8196 est la couche 3 (Exécuter).
L'ERC-8196 exige également que les portefeuilles vérifient l'enregistrement de l'ERC-8004 avant de s'enregistrer ou d'utiliser une politique, ce qui est l'exemple le plus clair de la façon dont l'« identité de l'agent » devient une barrière stricte plutôt qu'une page de profil.
C'est aussi là que le modèle mental du courtier principal s'inscrit. L'enregistrement est l'ouverture de compte. La vérification et le scoring peuvent être superposés. Les systèmes d'exécution refusent ensuite d'agir à moins que l'agent ne passe les vérifications d'enregistrement et de vérification.
L'ERC-8041 montre un autre chemin d'intégration : des collections de l'identité des agents ERC-8004, fixées et curées. L'ERC-8041 traite l'ERC-8004 comme un registre de frappe illimitée et propose des contrats de collection qui enregistrent des agents dans l'ERC-8004 tout en suivant les numéros de frappe et les métadonnées de collection.
Le détail clé est opérationnel : l'ERC-8041 avertit que les clients ne doivent pas se fier uniquement aux métadonnées écrites sur l'agent, et doivent interroger directement le contrat de collection pour vérifier l'appartenance.
La cross-chain est l'autre réalité d'intégration. Eco décrit l'ERC-8004 comme agnostique de la chaîne dans la façon dont il référence les identités via CAIP-10 et domaine, avec des registres singleton par chaîne et la possibilité d'enregistrement multi-chaînes. Allium cadre l'ERC-8004 comme conçu pour des chaînes compatibles EVM, avec des systèmes non-EVM consommant des données via des ponts ou des adaptateurs.
Quoi qu'il en soit, une intégration doit toujours choisir quels registres de chaîne elle considère comme canoniques pour la politique.
Limitations et idées reçues courantes
« ERC-8004 est un jeton de rail de paiement ou d'agent » est le premier malentendu coûteux. ERC-8004 n'est pas un système de règlement et ne remplace pasERC-20transferts, micropaiements de style x402, ou tout autre rail de paiement. C'est une couche de confiance qui est destinée à se composer avec tout ce qui déplace de la valeur.
« La réputation n'est que des évaluations par étoiles sur la chaîne » ne tient pas compte du design anti-spam. La réputation ERC-8004 est limitée (0–100), liée par un hash à des preuves hors chaîne via KECCAK-256, et soumise à une pré-autorisation (EIP-191 ou ERC-1271) avec expiration et un plafond d'index. Cette restriction est la différence entre un signal utilisable et une section de commentaires sur la chaîne.
« La validation signifie que l'agent est prouvé correct » regroupe plusieurs modèles d'assurance en un seul mot. Le Registre de Validation enregistre les demandes et les résultats avec des URIs de preuve, mais la force dépend du backend choisi.
Un réseau de réexécution basé sur le staking, une attestation TEE et une preuve à connaissance nulle ne fournissent pas les mêmes garanties ni les mêmes modes de défaillance, même s'ils se terminent tous par un drapeau de « succès » dans un registre.
La dernière limitation est la portabilité par rapport au canon. ERC-8004 peut référencer des agents de manière cohérente à travers les réseaux en utilisant CAIP-10 plus domaine, mais la portabilité dépend toujours de l'endroit où l'agent s'enregistre et des indexeurs ou agrégateurs auxquels un portefeuille fait confiance. C'est pourquoi l'identité de l'agent par rapport à l'identité humaine sur la chaîne n'est pas une distinction cosmétique.
Les humains peuvent s'appuyer sur le contexte social et l'identité légale. Les agents ont besoin de points de terminaison lisibles par machine, de modèles de confiance explicites et de pistes auditées car la contrepartie est souvent un autre programme.
L'analyse
J'ai vu des équipes livrer "l'identité de l'agent" sous forme de page de mint d'un NFT et considérer cela comme terminé, puis être surprises lorsque les intégrateurs posent les questions ennuyeuses : quels points de terminaison cela prend-il réellement en charge, quel modèle de confiance accepte-t-il et où se trouve la trace d'audit lorsque quelque chose ne va pas. L'ERC-8004 de l'ERC-721 est la poignée, pas la substance.
La substance est de savoir si la carte de l'agent est analysable et si les entrées du registre de réputation et du registre de validation sont utilisables selon la politique d'un portefeuille.
La posture claire est de traiter la réputation comme un routage et la validation comme une confiance. La note de 401 soumissions de feedback d'Allium au cours des deux premières semaines est un bon signe que le primitif de feedback est vivant, mais cela ne remplace pas une piste de validation lorsque les enjeux augmentent.
L'erreur qui coûte de l'argent est le prix.risque de contrepartie sur la base d'un score seul lorsque la norme donne déjà un endroit pour ancrer des preuves et une vérification par des tiers.
Sources
Frequently Asked Questions
Le ERC-8004 est-il une norme de jeton comme le ERC-20 ou le ERC-721 ?
Le ERC-8004 n'est pas une norme de jeton portant de la valeur. Il utilise un ERC-721 à l'intérieur du Registre d'Identité pour représenter les identités des agents, mais le but de la norme est la coordination de l'identité, de la réputation et de la validation plutôt que le transfert de valeur économique.
Qu'est-ce qu'une carte d'agent ERC-8004 et que contient-elle ?
Une carte d'agent est un fichier de métadonnées lisible par machine hors chaîne auquel le jeton d'identité ERC-8004 pointe, généralement à /.well-known/agent-card.json. Les sources la décrivent comme énumérant les points de terminaison de l'agent (A2A, MCP ou HTTPS), les modèles de confiance acceptés et les agrégateurs de réputation qu'il reconnaît.
Comment le ERC-8004 empêche-t-il les faux avis de réputation ou le spam ?
Les soumissions de réputation sont contrôlées par une pré-autorisation cryptographique de l'agent serveur. L'autorisation utilise l'EIP-191 pour les EOAs ou l'ERC-1271 pour les clients de contrats intelligents et inclut un horodatage d'expiration et un plafond d'index pour réduire les rejouements et le spam.
La validation ERC-8004 prouve-t-elle que la sortie d'un agent est correcte ?
Aucun niveau de sécurité unique n'est impliqué par "validé". Le Registre de Validation enregistre les demandes et les résultats avec des URI de preuve, tandis que l'assurance dépend du backend choisi, tel que la réexécution basée sur le staking, les TEE ou les preuves à divulgation nulle de connaissance.
Comment le ERC-8004 est-il lié aux portefeuilles d'agents ERC-8196 ?
Le ERC-8196 positionne le ERC-8004 comme Couche 1 (Registre) dans une pile de confiance modulaire et exige que les portefeuilles vérifient l'enregistrement ERC-8004 avant d'utiliser des politiques. Le ERC-8196 utilise ensuite la vérification et l'exécution liée aux politiques comme couches ultérieures pour contrôler ce qu'un agent peut faire.