Estamos vivendo a era da IA, disso ninguém tem dúvida. Você pode discutir se os números estão inflados, se as expectativas estão irreais ou até mesmo se estamos construindo algo de bom com estas tecnologias ou não, mas não pode negar que algo grande está acontecendo. Um dos tipos de aplicações com IA mais poderosos da atualidade são os agentes de IA, que eu já comentei e ensinei a programar em outro tutorial aqui do site. Com eles, você pode executar tarefas altamente especializadas através de treinamento prévio, mais ferramentas customizadas e até mesmo dados personalizados (com RAG).
Um caminho que está se desenhando para os Agentes de IA é o de autonomia completa. Ok, você pode dar uma ordem para um agente marcar uma reunião pra você com uma pessoa, para poder entrevistar ela para uma vaga de emprego, por exemplo. Mas um agente autônomo vai além disso: dada uma job description, ele poderia procurar candidatos, filtrar currículos, marcar entrevistas e até mesmo fazê-las e escolher o melhor. Talvez para fazer tudo isso ele precise de ajuda de outros agentes, como um especializado em entrevistas técnicasm outro em filtragem de CV, etc. Ou então encontrar ou criar outro agente para desempenhar a função da vaga.
Outro dia, Vitalik Buterin, criador da Ethereum, disse em um evento que a blockchain é o ecossistema natural para os Agentes de IA interagirem justamente porque ela possui uma economia e relacionamentos programáveis. Afinal, quando agentes interagem entre si, eles precisarão realizar transações e sabemos que cédulas de dinheiro, cartões de crédito ou mesmo contas bancárias não são opções práticas e seguras para agentes usarem, não é mesmo? Você entregaria o número do seu cartão + código de segurança para o OpenClaw ou outro agente cuidar dos seus pagamentos? E mesmo que você confiasse, o uso indiscriminado agente x agente certamente alertaria os sistemas anti-fraude as operadores e o custo por transação seria altíssimo com essa solução.
A solução para este problema vem através das criptomoedas. Uma vez que os protocolos DeFi são programáveis e não exigem KYC (outra barreira aos agentes autônomos), fica muito mais fácil oferecer interfaces financeiras amigáveis para AI Agents transacionarem entre si e todo um ecossistema de possibilidades seguras, auditáveis e práticas para tornar esse futuro agêntico possível.
Mas a grande questão é: como um agente vai saber que é seguro pagar pelo serviço de outro agente? Que ele realmente vai executar o serviço com qualidade? No mundo real, quando contratamos um serviço, nós procuramos por recomendações, sistemas de avaliação e outros tipos de mecanismo fragmentados. A ideia da ERC-8004, é justamente usar a blockchain para criar esta camada de confiança A2A (Agent to Agent). Resumidamente, a ERC-8004, desenvolvida em parceria pela Ethereum, Google, Coinbase e MetaMask, define um padrão EVM para o registro, reputação e validação de agentes de IA trustless, isto é, sem um intermediador ou centralizador outorgando confiança aos agentes, no melhor estilo web3 mesmo.
Neste e nos próximos artigos vamos explorar um pouco da ERC-8004 para entender como ela propõe resolver os problemas acima citados. Para um melhor entendimento desta série, é importante que você já esteja familiarizado com a ERC-721, ERC-20, IPFS e com Agentes de IA, assuntos que ensinei em outros tutoriais.
Se preferir, você pode assistir ao vídeo abaixo ao invés de ler.
A ERC-8004 possui três pilares, a saber:
- Registro de Identidade
- Registro de Reputação
- Registro de Validação
Juntos, os três registros formam uma camada de confiança sem a necessidade de uma figura centralizadora como um banco, auditoria e com vários benefícios de segurança que serão citados mais à frente.
Registro de Identidade
Entenda por “registro”, um smart contract que funciona como uma coleção de 1 ou mais agentes únicos, como se fosse um catálogo. Cada registro deve ser criado na blockchain usando o formato para coleções NFT: ERC-721, enquanto que os agentes em si são os NFTs nessa coleção. Isso garante que os agentes possuam donos, sejam únicos e possam ser transferidos, além de possuírem suporte a todo o ecossistema já existente para NFTs, como carteiras e marketplaces.
Abaixo, vou detalhar os principais pontos, ignorando alguns opcionais. Como este ainda é um EIP (proposta) e não uma ERC final, muita coisa pode mudar e não vale a pena se apegar a detalhes opcionais.
Metadata
Os metadados dos agentes são obrigatórios (seguindo a extensão ERC721URIStorage) e devem apontar para um arquivo externo (IPFS geralmente, quando offchain) ou string base64 (quando onchain), além de uma função setAgentURI (ou equivalente) para alterar essa informação (discutível). O padrão para eles é definido na própria ERC e reproduzidos abaixo, lembrando que como ela está em draft na data que escrevo este artigo, isso pode mudar:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 |
{ "type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1", "name": "myAgentName", "description": "A natural language description of the Agent, which MAY include what it does, how it works, pricing, and interaction methods", "image": "https://example.com/agentimage.png", "services": [ { "name": "web", "endpoint": "https://web.agentxyz.com/" }, { "name": "A2A", "endpoint": "https://agent.example/.well-known/agent-card.json", "version": "0.3.0" }, { "name": "MCP", "endpoint": "https://mcp.agent.eth/", "version": "2025-06-18" }, { "name": "OASF", "endpoint": "ipfs://{cid}", "version": "0.8", // https://github.com/agntcy/oasf/tree/v0.8.0 "skills": [], // OPTIONAL "domains": [] // OPTIONAL }, { "name": "ENS", "endpoint": "vitalik.eth", "version": "v1" }, { "name": "DID", "endpoint": "did:method:foobar", "version": "v1" }, { "name": "email", } ], "x402Support": false, "active": true, "registrations": [ { "agentId": 22, "agentRegistry": "{namespace}:{chainId}:{identityRegistry}" // e.g. eip155:1:0x742... } ], "supportedTrust": [ "reputation", "crypto-economic", "tee-attestation" ] } |
Repare algumas coisas importantes nestes metadados:
- type, name, description e image são propriedades que já existiam na ERC-721, apenas preencha como sempre;
- services: a lista de serviços que esse agente realiza. Note como cada tipo de serviço possui características próprias, que fazem sentido naquele contexto e que não vem ao caso de serem explicadas aqui;
- x402Support: suporte ao protocolo de pagamento HTTP-native criado pela Coinbase, algo complementar ao ERC8004;
- registrations: aqui vai o agenteId (tokenId) e o agentRegistry (formato a seguir);
- supportedTrust: falaremos sobre isso mais à frente;
O formato para o campo agentRegistry é:
|
1 2 3 |
{namespace}:{chainId}:{identityRegistry} |
O namespace é a família do Chain ID, sendo que para blockchains EVM isso definido pela ERC-155. Depois temos o Chain ID da rede e por fim, o endereço da coleção NFT na blockchain. Exemplo: eip155:1:0x742 para um registro EVM, blockchain ETH e endereço da coleção NFT 0x742. Para identificar um agente é usado esse agenteRegistry mais o agenteId, que nada mais é do que o tokenId da NFT.
A carteira do agente é, por padrão, a mesma do owner. Existem propostas para funções de gestão dessa informação.
Mint
Para mintar novos agentes no seu registro, são propostas três variações para uma nova função register, sempre recebendo o agentId mintado como retorno, sendo que a mais importante é a abaixo, que recebe a URI dos metadados:
|
1 2 3 |
function register(string agentURI) external returns (uint256 agentId) |
Dois eventos devem ser emitidos quando esta função é chamada:
- Transfer, normal da ERC-721;
- Registered, novo, como abaixo
|
1 2 3 |
event Registered(uint256 indexed agentId, string agentURI, address indexed owner) |
E com isso temos a especificação mínima completa para o registro de identidade de agentes na blockchain, seguindo o padrão da ERC-8004. Abaixo, um exemplo de implementação, usando como base o ERC721 da OpenZeppelin:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 |
// SPDX-License-Identifier: MIT pragma solidity ^0.8.34; // OpenZeppelin imports import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol"; import "@openzeppelin/contracts/access/Ownable.sol"; import "@openzeppelin/contracts/token/ERC721/IERC721.sol"; contract IdentityRegistry is ERC721URIStorage, Ownable { uint256 private _nextId; mapping(uint256 => bool) private _active; event Registered( uint256 indexed agentId, string agentURI, address indexed owner ); constructor() ERC721("ERC8004 Agent Identity", "AGENT") Ownable(msg.sender) {} function register( string calldata agentURI ) external onlyOwner returns (uint256 agentId) { agentId = _nextId++; _safeMint(msg.sender, agentId); _setTokenURI(agentId, agentURI); _active[agentId] = true; emit Registered(agentId, agentURI, msg.sender); } function resolve( uint256 agentId ) external view returns (address owner, string memory metadataURI, bool active) { require(_ownerOf(agentId) != address(0), "Agent does not exist"); return (ownerOf(agentId), tokenURI(agentId), _active[agentId]); } function deactivate(uint256 agentId) external onlyOwner { _active[agentId] = false; } function exists(uint256 agentId) external view returns (bool) { return _ownerOf(agentId) != address(0); } function approve(address, uint256) public pure override(ERC721, IERC721) { revert("Soulbound: approvals disabled"); } function setApprovalForAll( address, bool ) public pure override(ERC721, IERC721) { revert("Soulbound: approvals disabled"); } function transferFrom( address from, address to, uint256 tokenId ) public override(ERC721, IERC721) { revert("Soulbound: transfers disabled"); } function safeTransferFrom( address from, address to, uint256 tokenId, bytes memory data ) public override(ERC721, IERC721) { revert("Soulbound: transfers disabled"); } } |
Note que incluí um controle se o agente está ativo ou não, algo fora da especificação mas implicado pelo texto. O mesmo vale para a função resolve, que serve para facilitar fluxos de obtenção de dados em dapps. Também assumi que o owner das NFTs mintadas com register é sempre o mesmo da coleção e não implementei o mecanismo para troca de agentWallet, ela sempre será a carteira do owner e assumi aqui que estas NFTs serão soulbound tokens (intransferíveis), por isso os overrides e reverts nas funções finais.
No próximo artigo, vamos explorar o segundo pilar da ERC-8004: Reputation Registry.
Até lá!
Olá, tudo bem?
O que você achou deste conteúdo? Conte nos comentários.