Introdução ao padrão ERC-8004 - Parte 3

Inteligência Artificial

Introdução ao padrão ERC-8004 - Parte 3

Luiz Duarte
Escrito por Luiz Duarte em 16/07/2026
Junte-se a mais de 34 mil devs

Entre para minha lista e receba conteúdos exclusivos e com prioridade

Recentemente comecei os estudos da ERC-8004: Trustless Agents e resolvi escrever aqui no site para compartilhar o que aprendi sobre o assunto. Na primeira parte desta série de tutoriais, falamos da problemática A2A que gerou a motivação para a criação da ERC-8004 e entramos a fundo no primeiro dos seus três pilares, que é o Registro de Identidade. Na segunda parte, falamos do Registro de Reputação, que reúne os feedbacks dos clientes que usaram os serviços do agente. Nesta terceira e última etapa, vamos aprofundar no terceiro pilar: Registro de Validação.

Vamos lá!

Registro de Validação

O terceiro e último registro previsto pela ERC-8004 é o que está mais experimental e nebuloso dentre os três: o registro de validação. De certa forma ele cumpre o mesmo papel que o Registro de Reputação, mas de uma maneira mais segura, por assim dizer. A ideia é que o Validation Registry permita que os agentes solicitem validação do seu trabalho para validadores na rede. Para isso, os agentes forneceriam dados suficientes para a reprodução e validação do resultado entregue pelo seu trabalho, algo como uma auditoria externa, interessante especialmente para serviços envolvendo altos valores, alto risco, etc.

De posse desses dados, o validador re-processará a execução da tarefa usando qualquer técnica determinística, auditável e segura e registrará on-chain uma prova de que o agente realizou a tarefa corretamente (ou não), pontuando com uma nota de 0 a 100 e fornecendo opcionalmente a URI de um arquivo com evidências da validação. Desta forma, enquanto no Registro de Reputação temos uma confiança construída com uma filosofia mais “community driven”, entre os clients, no Registro de Validação nós temos algo mais próximo de uma auditoria externa, um feedback mais profissional.

Na prática, temos uma inicialização com o endereço do registro de identidade, para vincular os dois (acoplamento fraco):

E obtenção do endereço se necessário com outra função:

Já o uso do registro de validação se dá em duas etapas: Validation Request (emitida pelo agente) e Validation Response (emitida pelo validador).

Roadmap Web3

Requisição de Validação

O agente (ou seu owner) que deseja ter seu trabalho validado emite um pedido de validação para um validador usando a função abaixo.

Todos os parâmetros são obrigatórios, sendo que a requestURI é um arquivo na rede IPFS (ou equivalente) com as informações necessárias para a validação, como endpoints, payloads, resultado esperado, etc. Enquanto que o requestHash é o identificador único da requisição, gerado a partir do hash do conteúdo da requestURI. Essa request é armazenada internamente e notificada na rede através de um evento.

Uma vez submetida, agora é esperar o validador fazer o trabalho dele.

Resposta de Validação

A outra perna do processo de validação é a resposta. Quando o validador terminar o serviço dele ele deve chamar a função abaixo para registrar sua resposta.

Somente os parâmetros requestHash (identificador da request) e response (nota/score) são obrigatórios. A response é uma nota de 0 a 100 que pode ser entendida como booleano (0 = false, 100 = true) ou qualquer variação dentro desse range. Já responseURI e responseHash podem ser usados para fornecer evidências da validação, como provas. Tag por outro lado, é para ajudar na categorização, servindo por exemplo como status da validação, já que essa função pode ser chamada diversas vezes conforme a validação for acontecendo, mantendo atualizado um campo lastUpdate no registro de cada resposta.

Um ponto importante é que somente o validador designado pode responder a uma request aberta para ele e, quando fizer com sucesso, deve emitir um evento.

Implementação

Outras funções necessárias são as de leitura, conforme especificação abaixo.

A getValidationStatus deve trazer os dados de request e response para um requestHash específico (lembre-se, ele é o identificador único de cada request).

A getSummary deve trazer um resumo/agregado das respostas validadas para um agentId. Se fornecido validatorAddresses e/ou tag, deve usar essas informações como filtro também.

A getAgentValidations deve retornar os request hashes de todas validações realizadas para um agentId.

A getValidatorRequests deve retornar os request hashes de todas validações feitas por um validatorAddress.

Abaixo uma sugestão de implementação que atende ao padrão acima.

Conclusões

E com isso terminamos esses nossos estudos iniciais da ERC-8004. Alguns pontos adicionais a se considerar:

  • este ainda é um draft, muita coisa pode mudar e ainda não há uma implementação “oficial”, dei apenas sugestões;
  • alguns materiais citam a necessidade de se criar um ERC8004Coordinator, ou seja, um quarto contrato que reúne as instâncias dos três registros, para facilitar a sua gestão;
  • alguns materiais citam que a validação poderia ser realizada no registro de reputação pelo validador;

Quer se juntar aos builders da ERC-8004? Eles criaram um grupo no Telegram para compartilhar conhecimentos e experiências, entre aqui (em Inglês).

Dos mesmos criadores, conheça também o Ag0 SDK, que facilita a adesão ao novo padrão aqui.

Outra recomendação de estudos de um assunto ortogonal à ERC-8004 é o protocolo x402, criado pela Coinbase e que facilita o pagamento agêntico por serviços online, saiba mais no site oficial.

Até a próxima!

Curso Web23

TAGS:

Olá, tudo bem?

O que você achou deste conteúdo? Conte nos comentários.

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *