Fonctionnement des registres ERC-8004 : identité et…

Comment fonctionnent les registres ERC-8004 est un pipeline à trois livres : un AgentID ERC-721 pointe vers un fichier d'enregistrement hors chaîne, tandis que des registres de Réputation et de Validation distincts enregistrent des signaux de confiance compacts de 0 à 100 avec des pointeurs de preuve.

La conception ne met pas la "vérité de l'agent" sur la chaîne, elle standardise où chercher (identité), qui peut parler (réputation autorisée) et comment évaluer l'assurance (validation) pour l'identité de l'agent 8004.

Points clés

• ERC-8004 définit trois registres légers sur la chaîne : Identité, Réputation et Validation.
• Le Registre d'Identité utilise un AgentID ERC-721 dont le tokenURI pointe vers un fichier d'enregistrement d'agent hors chaîne répertoriant les points de terminaison et les identifiants tels que A2A, MCP, ENS et les adresses de portefeuille.
• Le Registre de Réputation enregistre des signaux de feedback portables de 0 à 100 avec des balises optionnelles et hors chaîne.liens, et un guide pour les développeurs décrit une porte feedbackAuth signée par un agent pour réduire le spam arbitraire.
• Le Registre de Validation enregistre les appels de validationRequest et les réponses de 0 à 100 validateurs, permettant aux applications d'échanger des mises, des preuves zkML ou des TEE.attestationssans changer la découverte.

Les registres ERC-8004 et leur objectif

Les registres ERC-8004 sontdes contrats intelligentsqui stockent des enregistrements standardisés et émettent des événements afin que d'autres applications puissent rechercher l'identité des agents et des signaux de confiance sans négocier de schémas sur mesure.

Le mouvement central de la norme consiste à diviser la "confiance" en trois surfaces distinctes : un registre d'identité pour la découverte, un registre de réputation pour les retours des utilisateurs, et un registre de validation pour les vérifications par des tiers. Cette séparation est la raison pour laquelle les registres erc 8004 restent légers sur la chaîne tout en étant toujours composables entre les applications.

Le modèle mental utile est un dossier de crédit sur la chaîne pourdes agents autonomes.Le Registre d'Identité est le numéro de compte et les informations de routage, pas le score de crédit. La Réputation et la Validation sont deux livres comptables différents de signaux compacts de 0 à 100, chacun pouvant porter des étiquettes et des pointeurs vers des preuves hors chaîne.

C'est le modèle de registre de validation de réputation d'identité : garder la chaîne comme l'index canonique et l'ancre d'intégrité, et garder les détails compliqués hors chaîne.

L'ERC-8004 est décrit comme uneProposition d'Amélioration d'Ethereumen statut de brouillon et en cours de révision par les pairs. Le guide principal indique la date de création comme le 13 août 2025 et nomme les co-auteurs Marco De Rossi (MetaMask), Davide Crapis (Ethereum Foundation), Jordan Ellis (Google) et Erik Reppel (Coinbase).

Cette posture de brouillon est importante car les interfaces sont censées être suffisamment stables pour l'expérimentation, mais les constructeurs doivent s'attendre à ce que les détails au niveau du terrain évoluent.

Le sujet plus large est l'identité de l'agent, et la thèse de l'ERC-8004 est étroite par conception : elle ne prétend pas prouver les capacités d'un agent sur la chaîne. Elle standardise où ces affirmations résident (enregistrement de tokenURI), comment les retours sont publiés d'une manière plus difficile à spammer (autorisation), et comment une assurance indépendante peut être achetée lorsque les enjeux augmentent (validation).

Comment fonctionne le registre d'identité

Le cycle de vie du registre d'identité est court sur la chaîne et long hors chaîne. Sur la chaîne, le mécanisme est un ERC-721 avec stockage de l'URI : frappez un token AgentID unique, définissez son tokenURI, et reposez-vous sur l'indexation standard des NFT et les événements pour la découverte.

Hors chaîne, le tokenURI résout à un fichier d'enregistrement d'agent qui agit comme un document de configuration vivant pour comment atteindre et interpréter l'agent.

Un flux concret ressemble à ceci :

1. Un opérateur d'agent frappe un ERC-721 AgentID dans le registre d'identité et définit le tokenURI. 2. Les indexeurs et les applications surveillent les événements du registre et énumèrent les AgentIDs de la même manière qu'ils énuméreraient les NFTs. 3. L'application récupère le tokenURI et lit le fichier d'enregistrement d'agent hors chaîne pour apprendre les points de terminaison et les identifiants.

La source principale décrit ce fichier d'enregistrement comme contenant des points de terminaison et des identifiants tels que A2A, MCP, ENS et adresses de portefeuille. C'est la charge utile opérationnelle. Si une application essaie de diriger une tâche vers un agent, le registre d'identité lui donne le pointeur canonique vers le bundle "où me parler" et "quels handles je revendique" de l'agent.

C'est aussi là que la plupart des intégrations sont prises au dépourvu. Le token ERC-721 ne dit pas à une application si le fichier d'enregistrement hors chaîne a discrètement changé, si un point de terminaison est devenu inactif, ou si un nom ENS a été redirigé.

Traiter le contenu du tokenURI comme une configuration de production est la bonne posture : versionnez-le, fixez-le à un stockage adressé par le contenu lorsque cela est possible, et alertez sur les changements. La partie sur la chaîne est intentionnellement ennuyeuse, et c'est le but.

Les objets requis apparaissent ici naturellement : le registre d'identité est le contrat, l'AgentID est le token ERC-721, et la carte d'agent est ce que de nombreux front-ends rendront à partir du tokenURI plus tout résumé de validation et de réputation mis en cache.

Comment les signaux de réputation sont enregistrés

La réputation dans l'erc 8004 est conçue pour être portable mais pas sans autorisation. Le Registre de Réputation fournit une interface standard pour publier et récupérer des signaux de feedback, et la source principale cadre ces signaux comme des scores de 0 à 100 avec des tags optionnels et des liens vers des données de feedback détaillées hors chaîne. La chaîne stocke le signal compact. Le lien hors chaîne porte le récit, les reçus et tout contexte qu'une application souhaite montrer à un humain.

Le mécanisme clé qui empêche le registre de réputation de se transformer en un mur de spam non échangeable est l'autorisation. Un guide orienté développeur décrit la soumission de réputation comme nécessitant une autorisation émise par l'agent via un feedbackAuth signé.

L'idée est simple : l'agent préautorise un contrepartie spécifique à laisser un feedback, de sorte que des adresses aléatoires ne puissent pas pulvériser des avis négatifs à grande échelle sans jamais interagir.

Une séquence typique est :

1. L'agent accepte une tâche et émet une autorisation de feedback au client. 2. Le client soumet un feedback au registre de réputation avec un score (0–100), des tags optionnels, une URI hors chaîne optionnelle et un hash, et le feedbackAuth. 3. Les applications et les agrégateurs lisent les événements de feedback on-chain et calculent leurs propres résumés, tout en récupérant les détails hors chaîne uniquement lorsque nécessaire.

Le guide principal pointe également vers un ticket d'admission plus propre pour les avis de « véritable utilisation » : les preuves de paiement x402. Il fait explicitement référence au code d'état HTTP "402 Paiement requis" dans le cadre du x402, et décrit l'utilisation de preuves de paiement afin que seuls les clients payants puissent laisser des avis.

C'est une composition serrée : des portes de paiement qui peuvent parler, le registre stocke le signal minimal de 0 à 100, et le lien de preuve peut contenir le reçu.

Aucun de cela n'élimine le comportement Sybil. La source principale reconnaît que la préautorisation ne réduit que partiellement le spam et que les attaques Sybil restent possibles, c'est pourquoi de nombreuses implémentations continueront à pondérer les examinateurs, à maintenir la réputation des examinateurs ou à imposer des coûts économiques ailleurs.

Comment fonctionnent les demandes et réponses de validation

La validation est le registre où les applications achètent une réduction de risque. Le Registre de Validation prend en charge la demande et l'enregistrement de vérifications indépendantes des validateurs, et la source principale décrit une fonction validationRequest plus des réponses de validateurs notées de 0 à 100.

Cette plage de 0 à 100 est délibérément flexible : une application peut la traiter comme un succès ou un échec, ou comme un spectre où différents validateurs ont différents seuils.

Le flux est un modèle de demande-réponse :

1. Un agent ou un consommateur appelle validationRequest pour demander à un validateur de vérifier une certaine revendication ou sortie. 2. Un validateur effectue sa vérification en utilisant la technologie d'assurance qu'il supporte. 3. Le validateur renvoie une réponse avec un score de 0 à 100 et peut joindre des preuves hors chaîne via des URI et des hachages.

Le choix de conception important est que le registre ne code pas en dur une seule méthode de vérification. Les sources discutent de plusieurs mécanismes, y compris le staking crypto-économique, les preuves zkML et les attestations TEE.oraclesou attestations.

De nombreux déploiements peuvent vérifier les attestations hors chaîne puis publier le résultat sur la chaîne, gardant la chaîne comme couche de règlement pour "ce qui a été revendiqué" et "qui l'a dit."

C'est ici que la thèse apparaît sur un écran : l'ERC-8004 ne fait pas de la confiance un badge binaire. Il standardise la manière dont un consommateur découvre l'agent, puis permet au consommateur d'augmenter l'assurance avec le risque. Le routage à faible enjeu peut s'appuyer sur des signaux de réputation. Les actions à risque moyen peuvent nécessiter une validation soutenue par un stake.

Les actions à haut risque peuvent exiger une vérification cryptographique comme des attestations TEE ou des preuves zkML, le registre agissant comme le lieu canonique pour trouver les dernières réponses.

Mettre les registres ensemble en toute sécurité.

Une intégration sécurisée compose les trois registres en une décision de confiance par niveaux plutôt que de tout moyen à un seul "score de confiance." L'identité est la couche de recherche, la réputation est une histoire portable des contreparties parlant des résultats, et la validation est un achat explicite d'assurance pour une revendication spécifique.

Les traiter comme des nombres interchangeables est la manière dont les applications finissent par faire confiance à la mauvaise chose.

Un modèle de filtrage pratique se mappe proprement aux modèles de confiance décrits dans le guide principal :

1. Faible enjeu : utiliser l'identité plus la réputation pour la découverte et le routage. L'application lit tokenURI, vérifie les champs de la carte de l'agent qui l'intéressent, et utilise les signaux de réputation comme filtre. 2. Enjeux moyens : exiger une validation crypto-économique.

L'application ne progresse que lorsqu'une réponse de validateur atteint son seuil, et elle peut préférer les validateurs qui publient des résultats soutenus par un stake. 3. Hauts enjeux : exiger une vérification cryptographique. L'application exige des attestations TEE ou des preuves zkML, le registre de validation stockant la réponse de 0 à 100 et les pointeurs de preuves.

Le bord tranchant est la dérive hors chaîne. Le tokenURI du registre d'identité peut pointer vers un fichier d'enregistrement hors chaîne qui change au fil du temps, et la chaîne ne préviendra pas un consommateur que les points de terminaison, les identifiants ou les options de confiance annoncées ont changé.

La gestion des versions et le verrouillage de ce fichier, ainsi que la surveillance des changements, ne sont pas optionnels si l'agent fait quoi que ce soit qui touche des fonds ou des données sensibles.

L'immuabilité a aussi ses inconvénients. La principale source note que les pointeurs et les hachages on-chain ne peuvent pas être supprimés, ce qui est excellent pour lesaudits et brutal pour les schémas négligents. Concevoir des formats d'enregistrement et de retour d'information en tenant compte de la révocation et de la substitution est important car l'écosystème accumulera des traces permanentes.

C'est aussi le bon endroit pour corriger les idées reçues courantes. L'ERC-8004 ne met pas les capacités des agents on-chain. Il stocke des identifiants, des scores et des pointeurs. Un seul score de réputation n'est pas équivalent à la confiance car la réputation et la validation sont des registres différents destinés à des niveaux de risque différents.

L'autorisation comme feedbackAuth réduit le spam arbitraire, mais cela ne résout pas les attaques Sybil à lui seul. C'est la véritable nature de l'erc 8004, comment cela fonctionne lorsqu'une application essaie de prendre une décision avec du capital en jeu, et c'est pourquoi l'identité de l'agent 8004 est mieux traitée comme un pipeline que vous pouvez ajuster.

Le point

J'ai vu des équipes construire des tableaux de bord de "confiance des agents" qui réduisent tout à un seul chiffre, puis agissent surprises lorsque le chiffre les déçoit. L'erreur coûteuse est de faire la moyenne de la réputation et de la validation comme s'ils étaient le mêmeactif. Ils ne le sont pas. La réputation est un historique de contreparties autorisées qui s'expriment.

La validation est un produit d'assurance tarifé lié à une réclamation spécifique, avec la technologie d'assurance variant de la mise en jeu à zkML en passant par les attestations TEE.

Si une intégration doit échouer, elle échoue généralement à la couture ennuyeuse : tokenURI pointe vers un fichier d'enregistrement hors chaîne, et ce fichier dérive. L'AgentID ERC-721 reste le même, l'interface utilisateur affiche toujours la même carte d'agent, et les points de terminaison ou identifiants changent discrètement en dessous. C'est pourquoi la couche d'identité dans l'ERC-8004 est intentionnellement simple.

Le travail consiste à surveiller ce à quoi cela pointe et à augmenter la validation lorsque le niveau de risque l'exige.

Sources

• Apprendre avec un sac à dos
• Moyen (Siddhant)