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

Inteligência Artificial

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

Luiz Duarte
Escrito por Luiz Duarte em 09/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. Nesta segunda etapa, vamos aprofundar no segundo pilar: Registro de Reputação.

Vamos lá!

Registro de Reputação

Uma vez que o smart contract Registro de Identidade garante que o Agente de IA é quem diz ser, entrega os serviços que ele realiza, quem é o seu dono e muito mais, é com o Registro de Reputação que sabemos se esse agente é realmente bom no que ele faz. Pense no registro de reputação como sendo aquela seção de avaliações que temos em qualquer site de ecommerce ou mesmo de prestação de serviços, onde geralmente temos estrelinhas ou notas de 1-5, 1-10, etc, além de depoimentos de clientes satisfeitos (ou não). A ideia aqui é a mesma, mas fazer isso mantendo um registro on-chain (auditável, imutável e descentralizado) e eventualmente, caso necessário, mais alguma informação complementar off-chain.

Assim, toda vez que um Agente, devidamente registrado na blockchain, realiza um serviço para outro agente, ele autoriza o mesmo a deixar uma avaliação no registro de reputação, que nada mais é que outro smart contract fracamento acoplado ao registro de identidade, através de uma função initialize.

Mais tarde, para saber quem é o identityRegistry, deve-se usar outra função.

Roadmap Web3

Feedback

Essa avaliação pode ser qualquer coisa a depender do contexto: notas de 1-10, estrelas de 1-5, etc. O formato sugerido pelo draft da ERC-8004 sugere que os feedback sejam no seguinte formato:

  • valor do score (inteiro);
  • número de casas decimais do score (igual temos em tokens ERC-20);
  • até duas tags opcionais, para ajudar a entender o score;
  • endpoint de contexto (do serviço usado, opcional);
  • arquivo JSON off-chain com detalhes (IPFS, opcional);
  • hash do arquivo anterior (opcional);

Como pode ver, a única coisa realmente importante aqui é o score, um int128 com a nota que o agente dá pelo serviço do outro agente e o número de casas decimais que vamos usar (podendo ser 0). Além de armazenar os scores dos feedbacks individuais, a ERC determina que a agregação dos mesmos, de maneira simplificada, seja feita on-chain, ou seja, esteja presente no contrato, enquanto que agregações e relatórios mais sofisticados possam ser feitos off-chain, se necessário. É nesses recursos off-chain onde os campos opcionais do feedback podem brilhar, já que para uma média simples apenas o score e decimais são o suficiente.

Para dar feeback por um serviço, a função a ser chamada é essa:

Importante ressaltar que o owner de um agent não pode deixar feedback sobre ele, bem como carteiras autorizadas a transferi-lo. Caso esteja fazendo os agents como soulbound tokens, essa última instrução não se aplica, já que a transferência não é possível.

Quando um feedback é realizado, um evento deve ser emitido, como abaixo.

A ERC ainda sugere tags para contextualizar o score (como starred, uptime e outras) e padrão de metadados para o arquivo off-chain da avaliação.

Um ponto que não é citado é sobre autorização para feedback, já que um sistema aberto poderia facilmente seria inundado por spam para denegrir ou elevar a reputação de um agente virtualmente. Isso pode ser resolvido criando um mapping semelhante ao de allowance do ERC-20, para que o owner do agente autorize automaticamente o recebimento do feedback após a prestação do serviço.

Lidando com Feedbacks

A ERC também determina corner cases envolvendo feedbacks, como por exemplo no caso de um client querendo revogar um feedback que deu a um agente. Neste caso, ele precisa chamar a função revokeFeedback:

E ela por sua vez deve emitir um evento FeedbackRevoked:

Também prevê a adição de respostas a feedbacks, por exemplo o agent owner apresentando recibo de refund ou o client apresentando recibo de transação. Para adicionar respostas, deve ser chamada a função appendResponse:

Essa função usa o índice do feedback como associação e permite fornecer a URI do arquivo na rede IPFS. No caso de uso de outras redes, o responseHash é obrigatório para garantir integridade.

Por fim, temos as funções de leitura definidas pelo padrão:

A getSummary deve retornar um resumo agregado dos feedbacks dados para um agentId por um conjunto de clients. Ou seja, é uma subvisão da agregação geral daquele agente.

A readFeedback deve trazer um feedback específico, considerando o client e/ou o índice do feedback. Opcionalmente pode-se usar as tags para filtrar ainda mais o retorno.

A readAllFeedback recebe o agentId obrigatório e alguns filtros opcionais e retorna a coleção de clients, índices de feedback, notas dadas, decimais, tags e a informação se cada um está revogado ou não. Note que não são retornados os feedbacks inteiros em si e caso sejam passados filtros, estes devem ser repeitados no resultado final.

A getResponseCount traz o número de respostas para um feedback e agente específicos, podendo ainda filtras por client e/ou responder.

A getClients traz todos os endereços de clientes que deixaram feedback para este agente.

E por fim, a getLastIndex deve retornar o índice do último feedbakc submetido por um client para um agentId.

Abaixo, um exemplo mínimo de implementação de ReputationRegistry, com acoplamento fraco no IdentityRegistry.

Na próxima e última etapa, vamos falar do terceiro pilar, o Registro de Validação.

Até lá!

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 *