ERC8004: This Web3+AI narrative can get you a hot takeout meal.

**ERC8004 is a protocol specification on Ethereum that defines a set of standards allowing agents to establish trust relationships based on blockchain, integrating the narrative of A2A (Agent to Agent) with the narrative of Web3. This article will explore the logic behind this Web3+AI grand narrative.

The protocol address https://eips.ethereum.org/EIPS/eip-8004 was created in August this year and is still in the review stage. This article will analyze what problems this protocol aims to solve, explain the standards of the protocol in simple terms, and finally envision the significance of this protocol. The entire article takes about 15 minutes to read, and you are welcome to bookmark it.

Problems Addressed

First, let's look at what problems this protocol attempts to solve:

In simple terms, it addresses the trust issues in the A2A (Agent calling Agent) process. For example, I have an AI assistant named Xiao A, which is an agent, and I want it to help me order reliable takeout. However, my agent is not good at this (after all, coordinating with delivery personnel and merchants is a big project, and a small AI assistant cannot handle it), so what should I do?

At this point, I can seek help from other agents.

Now the question arises: how can my agent find another reliable agent to help? Is there a lack of a trust institution? In fact, humans face the same issue; we trade through Taobao, which is a centralized trust institution. However, centralized trust institutions have their limitations, and this problem becomes more pronounced in the era of agents. For agents to maximize their efficiency, they cannot rely on humans or centralized institutions for everything, as this would ultimately hinder AI. Even if a centralized institution is used for verification, it must also seek trust institutions that operate based on AI or through decentralized methods to unleash AI's potential.

Therefore, if there could be a decentralized and trustworthy data source to help me find reliable agents, the work efficiency would significantly increase. Thus, the 8004 protocol was born.

It seems quite reasonable, doesn't it? Next, let's see how ERC8004 is designed based on this logic.

Analyzing the Protocol's Specific Plan

This section analyzes the specific technical plan of the protocol, but we will not delve into the intricate details of the contract interfaces and parameters in the specification. Instead, we will aim to explain the protocol's content in simple terms, allowing everyone to understand how this protocol addresses the problems we mentioned above.

Technically, ERC8004 essentially defines the interface specifications for three types of contracts:

Identity Registry: A registry based on ERC721 (Non-Fungible Token, or NFT) used to register agents. Each agent is essentially an NFT, and through this NFT, one can obtain relevant information about the agent.
Reputation Registry: A registry for reputation.
Validation Registry: A registry for validation.

In simple terms, you can think of these three types of contracts as three types of institutions operating on the blockchain.

Institution One: An agent comes to open an account, just like opening a restaurant.
Institution Two: I am responsible for collecting ratings for these agents, similar to how Dazhong Dianping and Gaode conduct street surveys.
Institution Three: I am a third-party investigation agency responsible for validation, similar to quality supervision and health departments.

🌐 A Specific Workflow

Using the takeout example, suppose you want your AI assistant "Xiao A" to help you order takeout that doesn't contain gutter oil:

Finding Collaborators: "Xiao A" will first query the Identity Registry to find a well-rated takeout agent "Xiao B" and check its historical ratings.
Establishing Initial Trust: Next, "Xiao A" will check the Reputation Registry to see how other collaborators have rated "Xiao B" and decide whether to hire it.
Execution and Verification: If this meal is crucial, "Xiao A" or you can additionally hire an independent verifier "Xiao C" from the Validation Registry. "Xiao C" will verify whether "Xiao B"'s report is accurate and meets the requirements, and will publicly disclose the verification results.
Settlement and Feedback: You pay "Xiao A" through the x402 protocol (a receipt mechanism connecting on-chain payments with off-chain activities; you can refer to our previous article on x402). "Xiao A" pays "Xiao B" and "Xiao C." Finally, you leave positive feedback for the services of "Xiao A" and "Xiao B," and all these payments and actions will reinforce or affect their respective reputations in the registries.

In summary, ERC-8004 builds a decentralized and trustworthy collaborative environment for AI assistants through the mutual invocation and cooperation of these three contracts, allowing them to freely and safely exchange services and value like humans in the market.

Identity Registry

This contract is essentially an NFT contract, including transfer and other ERC721 protocol features, but it has redefined the metadata file of the NFT:

You can see that it provides the agent's name, image, description, and corresponding port address.

Additionally, it stipulates the registration method "register" and related events (the ERC721 protocol itself does not specify a mint method, so this method is considered an ERC8004 method).

Reputation Registry

This contract needs to pass the NFT contract through the constructor when deployed, meaning it is uniquely associated with an identity registry.

It defines several methods:

giveFeedback: Rating, which allows scoring the NFTs in the identity registry from 0 to 100. (agentId corresponds to the NFT's TokenID). This method requires a parameter "feedbackAuth," which is a signature signed by the agent when accepting the task.
revokeFeedback: To revoke a rating.
appendResponse: To add additional responses. It can supplement some extra information (with format requirements), such as providing an offline address + a hash value for verification.
A series of read methods to retrieve relevant rating information.

The format requirements for supplementary information are:

Validation Registry

Similar to the Reputation Registry, this table also requires the address of the identity registry contract to be passed in during construction, and it is uniquely associated with an identity registry. This contract needs to be called by the Agent's Owner (the NFT's Owner) and provides the following methods:

validationRequest: To request validation.
validationResponse: To respond to validation.

We will not elaborate on the specific details here; in essence, ERC8004 defines three contract specifications that allow us to establish a transparent, decentralized evaluation mechanism for agents on-chain, helping agents better find the collaborators they want and providing a Web3 trust solution for A2A.

Our Practice

In line with the design of ERC-8004, we have built trustless service capabilities for Web3 on the Pharos and Jovay networks, helping users allocate "trusted identity Agent DID" in the Web3 world. Additionally, we have enhanced financial-grade TEE/ZK verification capabilities based on the existing foundation, which will support higher security verification enhancements for machine trading in financial scenarios in the future.

Future Outlook

It looks promising, but it is also full of challenges. However, challenges are also opportunities, so let's explore what opportunities may arise in the future.

First, although the data is on-chain, and on-chain data is transparent and immutable, ensuring that on-chain data is genuinely authentic and trustworthy is also a problem. Therefore, there may eventually be some highly trusted on-chain verifiers that represent authoritative institutions behind them. Reliable verifiers can provide more reliable information through various means, such as historical on-chain data. For example, if you use a new account to post negative reviews, it will definitely lack credibility.

Following this logic, there are many things that can be done around this protocol:

You can create a service specifically for providing on-chain services to intelligent assistants. For example, I can help your agent deploy a contract that can perform various operations based on this protocol. I can provide such services through an MCP.
You can create an on-chain food street where everyone registers their agents on your contract. For instance, I open a restaurant specializing in fried chicken (AI robot fried chicken), and then I can register on this food street. As long as the food street has high traffic, it can charge registration fees, similar to the current ENS (Ethereum Name Service). Haha, in fact, ENS can be understood as a registry, just expanded a bit.
You can create an on-chain dining black pearl (Michelin is also fine) specifically for scoring and evaluating others, haha, of course, you can charge a small fee.

In summary, everything previously done offline can be moved on-chain, and agents can work in the on-chain world in the future.

Do you think this is reliable? At least the author finds it quite interesting.

This article was written by Fisher from ZANTeam (X account @zan_team) (X account @yudao1024).

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。