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

ERC8004 is a protocol specification on Ethereum that defines a standard that allows smart agents to establish trust relationships based on the blockchain, integrating the A2A (Agent to Agent) narrative with the Web3 narrative. This article will take a look at the logic behind this grand Web3+AI narrative.

The protocol, located at https://eips.ethereum.org/EIPS/eip-8004 , was created in August of this year and is still under review. This article will analyze the problem this protocol solves, provide a simple explanation of its standards, and finally discuss its significance. The article will take approximately 15 minutes to read; feel free to bookmark it.

Problems to be solved

First, let's look at what problem this protocol is trying to solve:

Simply put, it solves the trust issue in the A2A (Agent-to-Agent) process . For example, I have an AI assistant called A, which is an intelligent agent. I ask it to order reliable takeout for me. However, my intelligent agent is not good at this (after all, connecting with delivery drivers and merchants is a big project, which a small AI assistant cannot support). So what do I do?

At this point, you can seek help from other intelligent agents.

So the question arises: how does my intelligent agent find another reliable intelligent agent to help? Isn't it lacking a trusted institution? Humans are similar; we transact through Taobao, a centralized trusted institution. However, centralized trusted institutions have their limitations, and this problem is even more pronounced in the era of intelligent agents. For intelligent agents to be efficient, they can't rely on people or centralized institutions for everything; otherwise, humans will hinder AI. Even when using centralized institutions for verification, it's still necessary to find trusted institutions that operate based on AI or through decentralized methods to maximize AI's effectiveness.

Therefore, if we could have decentralized, reliable data to help us find trustworthy intelligent agents, our work efficiency would be much higher. This led to the development of the 8004 protocol.

Hmm, doesn't that seem quite reasonable? Now let's take a look at how the ERC8004 is designed based on this logic.

Analysis of the specific scheme of the protocol

This section analyzes the specific technical solution of the protocol. However, we won't delve into the overly detailed contract interfaces and parameters of the specification here, aiming to make it as easy to understand as possible. For more details, please refer to the standard documentation of the protocol. Based on the protocol content, we will explain in layman's terms how this protocol aims to solve the problems we raised above.

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

• Identity Registry. Based on ERC721 (Non-Fungible Token, or NFT), it is used to register smart agents. Each smart agent is essentially an NFT, and its relevant information can be obtained through this NFT.
• Reputation Registry.
• Validation Registry: Verify the registry.

Simply put, you can think of these three types of contracts as three types of institutions operating on the blockchain.

• Organization 1: A smart entity comes over to open an account, just like you open a restaurant.
• Organization Two: I'll be responsible for collecting ratings for these intelligent agents, just like how Dianping and Gaode Maps conduct street sweeps.
• Organization 3: We are a third-party investigation agency responsible for verification. Similar to the quality supervision bureau or the health bureau.

🌐 A specific workflow

Let's take ordering takeout as an example. Suppose you want the AI assistant "Xiao A" to order takeout for you without gutter oil:

1. Finding partners : "Little A" will first check the identity registration form to find "Little B" with good reviews and check its historical reviews.
2. Establishing initial trust : Next, "Little A" will check the reputation registry to see how other collaborators rate "Little B" and decide whether to hire it.
3. Execution and Verification : If this meal is crucial, "A" or you can hire an independent verifier "C" from the verification registry . "C" will verify whether "B's" report is accurate and meets the requirements, and will make the verification results public.
4. Settlement and Feedback : You pay "A" via the x402 protocol (a receipt mechanism connecting on-chain payments and off-chain activities; see our previous article on x402 for more details). "A" then pays "B" and "C". Finally, you leave positive reviews for "A" and "B's" services; all these payments and actions reinforce or influence their respective reputations in the registry.

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

Identity Registry

This contract is essentially an NFT contract, containing the ERC721 protocol itself, including transfer rules, but with a redefined and expanded NFT metadata file:

As you can see, you have already provided the Agent's name, image, description, and corresponding port address.

In addition, the registration method "register" and related events were agreed upon (the ERC721 protocol itself does not specify the mint method, so this method is considered to be the ERC8004 method).

Reputation Registry

When deploying this contract, the NFT contract needs to be passed in through the constructor, meaning it is uniquely associated with an identity registry.

Several methods are defined:

• `giveFeedback` is a rating function that assigns a score to an NFT in the identity registry, ranging from 0 to 100. (The `agentId` corresponds to the NFT's TokenID). Calling this method requires a parameter `feedbackAuth`, which is a signature the agent makes when accepting the task.
• RevokeFeedback.
• `appendResponse` appends a response. You can add additional information (with specific formatting requirements), such as an offline address plus a hash value for verification.
• There are also a series of reading methods that can retrieve relevant rating information.

The format requirements for supplementary information are as follows:

Verify Registry

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

• The validationRequest is used to request validation.
• The validationResponse is used to respond to validation requests.

The specific details will not be elaborated on here. In essence, ERC8004 defines three contract specifications, which enable us to establish a transparent, decentralized evaluation mechanism for smart agents on the blockchain. This helps smart agents find the smart agents they want to cooperate with, providing a Web3 trust solution for A2A.

Our Practice

Based on the design of ERC-8004, we have built a Trustless service capability for Web3 on the Pharos and Jovay networks, which can help users assign a "Trusted Identity Agent DID" in the Web3 world. At the same time, we have also extended the original TEE/ZK verification capability with financial-grade enhancements, which will support higher security verification enhancements in financial scenarios such as machine transactions in the future.

Future Outlook

It looks wonderful, but it's also full of challenges. However, challenges can also be opportunities. Let's see what opportunities might come in the future.

First, while the data resides on the blockchain, and on-chain data is transparent and immutable, ensuring its true authenticity and reliability remains a challenge. Therefore, highly trusted on-chain validators may emerge, essentially representing authoritative institutions behind the scenes. Reliable validators can provide more reliable information through various means, such as historical on-chain data. For example, using a new account to post negative reviews will undoubtedly compromise your credibility.

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

• You could create a service specifically for providing on-chain services to intelligent agents. For example, I could help your intelligent agent deploy a contract that can perform various operations based on this protocol. I could provide such a service through an MCP (Multi-Channel Programming Protocol).
• You could create an on-chain food street where everyone registers their smart agents on your contract. For example, I could open a fried chicken shop (with AI robots frying chicken!), and register on this food street. As long as the food street has high traffic, it can charge registration fees. Just like ens (the Ethereum domain name). Haha, actually, ens can be understood as a registry, just with some extensions.
• You could create an on-chain restaurant Black Pearl (Michelin is fine too) to rate and review other people's food, haha, of course you could make a little money from it.

In short, everything done offline can be moved onto the blockchain, and intelligent agents can work in the blockchain world from now on.

Do you guys think it's reliable? At least I think it's quite interesting.

This article was written by Fisher (X account @yudao1024 ) of ZAN Team (X account @zan_team ).