Como funcionam os registros ERC-8004: identidade e validação

Como funcionam os registros ERC-8004 é um pipeline de três livros-razão: um AgentID ERC-721 aponta para um arquivo de registro off-chain, enquanto registros separados de Reputação e Validação registram sinais de confiança compactos de 0 a 100 com apontadores de evidência.

O design não coloca a "verdade do agente" on-chain, padroniza onde procurar (identidade), quem pode falar (reputação autorizada) e como precificar a garantia (validação) para a identidade do agente 8004.

Principais Conclusões

• ERC-8004 define três registros leves on-chain: Identidade, Reputação e Validação.
• O Registro de Identidade utiliza um AgentID ERC-721 cujo tokenURI aponta para um arquivo de registro de agente off-chain que lista endpoints e identificadores como A2A, MCP, ENS e endereços de carteira.
• O Registro de Reputação registra sinais de feedback portáteis de 0 a 100 com tags opcionais e off-chain.links, e um guia para desenvolvedores descreve um portão feedbackAuth assinado por agente para reduzir spam arbitrário.
• O Registro de Validação registra chamadas de validationRequest e respostas de validadores de 0 a 100, permitindo que aplicativos troquem em staking, provas zkML ou TEE.atestadossem mudar a descoberta.

Registros ERC-8004 e seu propósito

Os registros ERC-8004 sãocontratos inteligentesque armazenam registros padronizados e emitem eventos para que outros aplicativos possam consultar a identidade do agente e sinais de confiança sem negociar esquemas personalizados.

O movimento central do padrão é dividir a “confiança” em três superfícies distintas: um registro de identidade para descoberta, um registro de reputação para feedback do usuário e um registro de validação para verificações de terceiros. Essa separação é a razão pela qual os registros erc 8004 permanecem leves na cadeia enquanto ainda são compostáveis entre aplicativos.

O modelo mental útil é um arquivo de crédito on-chain paraagentes autônomosO Registro de Identidade é o número da conta e as informações de roteamento, não a pontuação de crédito. Reputação e Validação são dois livros-razão diferentes de sinais compactos de 0 a 100, cada um podendo carregar etiquetas e apontadores para evidências off-chain.

Este é o padrão do registro de validação da reputação de identidade: manter a cadeia como o índice canônico e âncora de integridade, e manter os detalhes confusos off-chain.

ERC-8004 é descrito como umEthereumProposta de Melhoria em status de Rascunho e passando por revisão por pares. O guia principal lista a data de criação como 13 de agosto de 2025 e nomeia os co-autores Marco De Rossi (MetaMask), Davide Crapis (Ethereum Foundation), Jordan Ellis (Google) e Erik Reppel (Coinbase).

Essa postura de rascunho é importante porque as interfaces devem ser estáveis o suficiente para experimentação, mas os construtores devem esperar que os detalhes em campo evoluam.

O tema mais amplo é a identidade do agente, e a tese do ERC-8004 é intencionalmente estreita: não afirma provar as capacidades de um agente na blockchain. Ela padroniza onde essas afirmações residem (registro de tokenURI), como o feedback é postado de uma maneira que é mais difícil de ser spam (autorização) e como a garantia independente pode ser adquirida quando os riscos aumentam (validação).

Como funciona o registro de identidade

O ciclo de vida do Registro de Identidade é curto on-chain e longo off-chain. On-chain, o mecanismo é um ERC-721 com armazenamento de URI: cunhar um token AgentID único, definir seu tokenURI e confiar no padrão.NFTindexação e eventos para descoberta. Off-chain, o tokenURI resolve para um arquivo de registro de agente que atua como um documento de configuração vivo sobre como alcançar e interpretar o agente.

Um fluxo concreto se parece com isto:

1. Um operador agente cria um ERC-721 AgentID no registro de identidade e define o tokenURI. 2. Indexadores e aplicativos monitoram eventos do registro e enumeram AgentIDs da mesma forma que enumerariam NFTs. 3. O aplicativo busca o tokenURI e lê o arquivo de registro do agente fora da cadeia para aprender sobre endpoints e identificadores.

A fonte primária descreve que o arquivo de registro contém pontos finais e identificadores como A2A, MCP, ENS e endereços de carteira. Esse é o payload operacional. Se um aplicativo está tentando direcionar uma tarefa para um agente, o registro de identidade fornece o ponteiro canônico para o "onde falar comigo" e o "quais identificadores eu reivindico" do agente.

Este também é o ponto onde a maioria das integrações é pega de surpresa. O token ERC-721 não informa a um aplicativo se o arquivo de registro off-chain mudou silenciosamente, se um endpoint ficou fora do ar ou se um nome ENS foi redirecionado. Tratar o conteúdo do tokenURI como configuração de produção é a postura correta: versioná-lo, fixá-lo em armazenamento endereçado por conteúdo sempre que possível e alertar sobre mudanças. A parte on-chain é intencionalmente chata, e esse é o ponto.

Os objetos necessários aparecem aqui naturalmente: o registro de identidade é o contrato, o AgentID é o token ERC-721, e o cartão do agente é o que muitas interfaces front-end renderizarão a partir do tokenURI, além de qualquer validação em cache e resumos de reputação.

Como os sinais de reputação são registrados

A reputação no erc 8004 é projetada para ser portátil, mas não permissiva. O Registro de Reputação fornece uma interface padrão para postar e recuperar sinais de feedback, e a fonte primária enquadra esses sinais como pontuações de 0 a 100 com tags opcionais e links para dados de feedback detalhados off-chain. A cadeia armazena o sinal compacto. O link off-chain carrega a narrativa, recibos e qualquer contexto que um aplicativo queira mostrar a um humano.

A mecânica chave que impede que o registro de reputação se torne uma parede de spam não negociável é a autorização. Um guia voltado para desenvolvedores descreve a submissão de reputação como exigindo autorização emitida pelo agente via um feedbackAuth assinado.

A ideia é simples: o agente pré-autorizou uma contraparte específica a deixar feedback, de modo que endereços aleatórios não possam despejar avaliações negativas em grande escala sem nunca interagir.

Uma sequência típica é:

1. O agente aceita uma tarefa e emite uma autorização de feedback para o cliente. 2. O cliente submete feedback ao registro de reputação com pontuação (0–100), tags opcionais, URI off-chain opcional e hash, e o feedbackAuth. 3. Aplicativos e agregadores leem eventos de feedback on-chain e computam seus próprios resumos, enquanto buscam detalhes off-chain apenas quando necessário.

O guia principal também aponta para um ingresso de admissão mais limpo para revisões de "uso real": provas de pagamento x402. Ele faz referência explícita ao código de status HTTP "402 Payment Required" como parte da estrutura do x402, e descreve o uso de provas de pagamento para que apenas clientes pagantes possam deixar avaliações.

Essa é uma composição apertada: portões de pagamento que podem falar, o registro armazena o sinal mínimo de 0 a 100, e o link de evidência pode conter o recibo.

Nada disso elimina o comportamento Sybil. A fonte primária reconhece que a pré-autorização apenas mitiga parcialmente o spam e que ataques Sybil continuam sendo possíveis, razão pela qual muitas implementações ainda pesarão revisores, manterão a reputação dos revisores ou imporão custos econômicos em outros lugares.

Como funcionam os pedidos e respostas de validação

A validação é o registro onde os aplicativos reduzem riscos. O Registro de Validação suporta a solicitação e o registro de verificações independentes de validadores, e a fonte primária descreve uma função validationRequest além de respostas de validadores pontuadas de 0 a 100.

Essa faixa de 0 a 100 é deliberadamente flexível: um aplicativo pode tratá-la como aprovação ou reprovação, ou como um espectro onde diferentes validadores têm diferentes limiares.

O fluxo é um padrão de solicitação-resposta:

1. Um agente ou consumidor chama validationRequest para pedir a um validador que verifique alguma reivindicação ou resultado. 2. Um validador realiza sua verificação usando qualquer tecnologia de garantia que suporte. 3. O validador envia uma resposta de volta com uma pontuação de 0 a 100 e pode anexar evidências off-chain via URIs e hashes.

A escolha de design importante é que o registro não codifica um único método de verificação. As fontes discutem múltiplos mecanismos, incluindo staking criptoeconômico, provas zkML e TEEoráculosou atestações. Muitas implementações podem verificar atestações off-chain e depois postar o resultado on-chain, mantendo a cadeia como a camada de liquidação para 'o que foi reivindicado' e 'quem disse isso'.

É aqui que a tese aparece na tela: ERC-8004 não torna a confiança um distintivo binário. Ele padroniza como um consumidor descobre o agente, e então permite que o consumidor aumente a garantia com risco. Roteamento de baixo risco pode se apoiar em sinais de reputação. Ações de risco médio podem exigir validação respaldada por stake.

Ações de alto risco podem exigir verificação criptográfica como atestações TEE ou provas zkML, com o registro atuando como o lugar canônico para encontrar as últimas respostas.

Colocando os registros juntos de forma segura

Uma integração segura compõe os três registros em uma decisão de confiança em camadas, em vez de média tudo em uma única 'pontuação de confiança'. A identidade é a camada de consulta, a reputação é uma história portátil de contrapartes falando sobre resultados, e a validação é uma compra explícita de garantia para uma reivindicação específica. Tratar esses números como intercambiáveis é como os aplicativos acabam confiando na coisa errada.

Um modelo de gating prático se mapeia claramente para os modelos de confiança descritos no guia principal:

1. Baixo risco: use identidade mais reputação para descoberta e roteamento. O aplicativo lê tokenURI, verifica os campos do cartão do agente que lhe interessam e usa sinais de reputação como filtro. 2. Risco médio: requer validação criptoeconômica. O aplicativo só prossegue quando uma resposta do validador atende ao seu limite, e pode preferir validadores que postam resultados respaldados por stake. 3.

Alto risco: requer verificação criptográfica. O aplicativo exige atestações TEE ou provas zkML, com o registro de validação armazenando a resposta de 0 a 100 e ponteiros de evidência.

A borda afiada é a deriva off-chain. O tokenURI do registro de identidade pode apontar para um arquivo de registro off-chain que muda ao longo do tempo, e a cadeia não avisará um consumidor que os endpoints, identificadores ou opções de confiança anunciadas mudaram. Versionar e fixar esse arquivo, além de monitorar mudanças, não é opcional se o agente estiver fazendo qualquer coisa que toque em fundos ou dados sensíveis.

A imutabilidade também tem suas desvantagens. A fonte primária observa que os ponteiros e hashes on-chain não podem ser deletados, o que é ótimo paraauditoriatrilhas e brutal para esquemas descuidados. Projetar formatos de registro e feedback com revogação e substituição em mente é importante porque o ecossistema acumulará migalhas permanentes.

Este também é o lugar certo para corrigir as concepções errôneas comuns. O ERC-8004 não coloca capacidades de agente na blockchain. Ele armazena IDs, pontuações e ponteiros. Uma única pontuação de reputação não é igual a confiança porque Reputação e Validação são livros-razão diferentes destinados a diferentes níveis de risco. A autorização como feedbackAuth reduz spam arbitrário, mas não resolve ataques Sybil por si só.

Essa é a verdadeira forma do ERC 8004 e como ele funciona quando um aplicativo tenta tomar uma decisão com capital em jogo, e é por isso que a identidade do agente 8004 é melhor tratada como um pipeline que você pode ajustar.

A Análise

Eu vi equipes construírem painéis de "confiança do agente" que colapsam tudo em um único número e, em seguida, ficam surpresas quando o número as decepciona. O erro caro é fazer a média de Reputação e Validação como se fossem a mesma coisa.ativoEles não são. A reputação é um histórico de contrapartes autorizadas falando.

A validação é um produto de garantia precificado vinculado a uma reivindicação específica, com a tecnologia de garantia variando de staking a zkML e atestações TEE.

Se uma integração vai falhar, geralmente falha na costura entediante: tokenURI aponta para um arquivo de registro off-chain, e esse arquivo se desvia. O AgentID ERC-721 permanece o mesmo, a interface ainda mostra o mesmo cartão de agente, e os endpoints ou identificadores mudam silenciosamente por baixo. É por isso que a camada de identidade no ERC-8004 é intencionalmente simples. O trabalho consiste em monitorar para onde aponta e aumentar a validação quando o nível de risco exige.

Fontes

• Aprender com a Mochila
• Médio (Siddhant)