ERC-8004

Trustless AI Agent 的身份、声誉与验证协议

整理自官方规范 · 更新于 2025 · 原始 EIP ↗ · GitHub ↗

图1 — ERC-8004 让不同组织的 Agent 无需预先关系，通过链上信号建立信任

ERC-8004 是一套轻量级链上注册表，让 AI Agent 可以在无需预先信任关系的情况下，跨越组织边界互相发现、互相评价、互相验证。

更准确地说，一个 Agent 通过 ERC-8004 可以：

向全网声明身份和服务端点（Identity Registry）
积累其他人对它的评价，形成可被合约直接消费的声誉分（Reputation Registry）
提供可被独立核查的行为证明（Validation Registry）

— EIP-8004 摘要

"A lightweight set of on-chain registries that make agents discoverable and enable trust signals across organizational boundaries."

Note:

ERC-8004 本身不规定"什么程度的信任才够用"——它只提供标准化的信号基础设施。调用方自己决定需要哪些信号组合。

结构总览
Identity Registry
Reputation Registry
Validation Registry
Trust Models
Multi-Chain 部署
示例代码
安全考量
测验

Structure ↑ top

ERC-8004 由三个相互独立但协同工作的智能合约注册表组成。每个 Agent 只需注册一次，即可在所有兼容应用中被发现。

Note:

所有注册表通过 CREATE2 + 盐值挖矿在 40+ 条 EVM 链上部署，地址前缀固定为 0x8004...，跨链地址保持一致。

ERC-8004 三大注册表
注册表	主网地址（前缀）	基础标准	核心作用
IdentityRegistry ↓	`0x8004A169...9432`	ERC-721	为 Agent 颁发 NFT 身份凭证，存储 AgentURI 和元数据
ReputationRegistry ↓	`0x8004BAa1...B63`	—	接收、聚合、撤销链上反馈，提供可被合约消费的声誉摘要
ValidationRegistry ↓	可插拔接口	—	通用验证钩子，支持质押重执行、ZK 证明、TEE 证明、裁判系统

Identity Registry ↑ top

Identity Registry 基于 ERC-721 构建。每个 Agent 注册后获得一个 NFT（tokenId），这个 NFT 就是它在全网的唯一身份凭证——可转让、可查询、可验证。

图2 — register() 铸造 ERC-721 NFT，tokenId 即为 Agent 的链上身份

Agent ID [↑]

Format: namespace:chainId:registryAddress:tokenId
Example: eip155:1:0x8004A169FB4a3325136EB29fA0ceB6D2e539a432:42

Agent 的全球唯一标识符由四部分拼合而成：

部分	示例值	说明
namespace	`eip155`	链标准命名空间，遵循 ERC-155 规范
chainId	`1`	部署链的 Chain ID（Ethereum=1，Base=8453，Arbitrum=42161…）
registryAddress	`0x8004A1...9432`	IdentityRegistry 合约地址，所有链上以 `0x8004...` 开头
tokenId	`42`	注册时自动分配的自增 NFT ID，在单个 Registry 内唯一

Tip:

Agent 在不同链上注册会得到不同 tokenId，但 registryAddress 相同。跨链发现时只需指定目标链的 chainId 即可。

🔧 Agent ID 解析工具输入全局 ID，解析各组成部分

Agent ID

AgentURI [↑]

Type: string
Format: IPFS URI / HTTPS URL / base64 data URI

AgentURI 是指向 Agent 注册文件的链接，支持三种格式：

格式	示例	特性
IPFS	`ipfs://QmXoy...`	内容寻址，内容变化则 URI 变化，最强防篡改保证
HTTPS	`https://agent.example.com/reg.json`	灵活可更新，需配合 endpointHash 做完整性校验
base64	`data:application/json;base64,...`	数据直接内嵌，无需外部存储，适合小型注册文件

Registration File [↑]

Type: JSON
Location: IPFS / HTTPS / base64

字段	示例	必填	说明
name	`"DataAnalysisAgent"`	是	Agent 的人类可读名称
description	`"财务数据分析专家"`	是	功能描述，供发现方快速判断适用性
services.web	`"https://agent.com/api"`	否	HTTP REST API 端点
services.a2a	`"https://agent.com/a2a"`	否	Agent-to-Agent 协议端点（Google A2A 标准）
services.mcp	`"https://agent.com/mcp"`	否	Model Context Protocol 端点（Anthropic MCP）
services.ens	`"dataagent.eth"`	否	ENS 域名，可选身份锚点
services.did	`"did:ethr:0x742..."`	否	W3C DID，可与 DID 生态互操作
trustModels	`["reputation","tee"]`	否	Agent 支持的信任模型列表

Tip — 域名所有权验证:

Agent 可选择在 https://yourdomain.com/.well-known/agent-registration.json 放置相同注册文件，以证明对该域名的控制权。调用方可交叉比对来确认身份真实性。

Functions [↑]

函数	参数	权限	说明
register()	`agentURI, metadata[]`	任何人	注册新 Agent，铸造 NFT，返回 tokenId
setAgentURI()	`agentId, newURI`	Owner	更新 Agent 的注册文件 URI
setAgentWallet()	`agentId, wallet, sig`	Owner	设置运营钱包地址，需 EIP-712 或 ERC-1271 签名
getMetadata()	`agentId, key`	任何人	读取附加元数据键值对
tokenURI()	`tokenId`	任何人	ERC-721 标准接口，返回 AgentURI

Caution:

NFT 转让时，agentWallet 会被自动清除。新 owner 需重新调用 setAgentWallet() 并提供有效签名。这防止旧 owner 继续冒用 Agent 的运营钱包。

Reputation Registry ↑ top

Reputation Registry 是链上标准化的反馈系统。任何地址（客户端）都可以为 Agent 提交数值评分，评分数据聚合后可被智能合约直接消费，形成可组合的信任信号。

图3 — 反馈从客户端流入 Registry，聚合后被智能合约消费用于门控决策

Feedback 数据结构 [↑]

字段	类型	示例	说明
value	int128	`95`	原始评分值，支持负数（差评）
valueDecimals	uint8 (0-18)	`1`	精度位数。value=95, decimals=1 → 实际分数 9.5
tag1	string	`"accuracy"`	主分类标签，按维度细分声誉
tag2	string	`"code-review"`	子分类标签（可选）
endpointURI	string	`"ipfs://Qm..."`	指向详细评价文件的 URI（可选）
endpointHash	bytes32	`0x3f4a...`	URI 内容的 KECCAK-256 哈希，防止链下内容被篡改
revoked	bool	`false`	是否已被提交者撤销。撤销后保留记录但不计入聚合

Note:

固定精度数值设计避免了浮点数在 EVM 中的计算风险。评分"9.5分（满分10）"存储为 value=95, decimals=1。

giveFeedback() [↑]

Signature:

giveFeedback(uint256 agentId, int128 value, uint8 valueDecimals, string tag1, string tag2, string endpointURI, bytes32 endpointHash)

Emits: NewFeedback(agentId, clientAddress, feedbackIndex)

提交一条对 Agent 的评价。clientAddress 由合约自动记录为 msg.sender。

getSummary() [↑]

Signature: getSummary(uint256 agentId, address[] clientAddresses, string tag) returns (int128 totalScore, uint64 feedbackCount)

聚合指定 clientAddresses 列表中各地址对该 Agent 的有效评价，返回总分和有效反馈数量。

Caution — 女巫攻击防护:

clientAddresses 参数是强制的，意味着你只统计你信任的地址的评价。攻击者无法用新地址刷分，因为新地址不在任何人的信任列表中。

revokeFeedback() [↑]

Signature: revokeFeedback(uint256 agentId, uint64 feedbackIndex)
Emits: FeedbackRevoked(agentId, clientAddress, feedbackIndex)

撤销自己之前提交的某条反馈。撤销后 revoked=true，不再计入 getSummary() 聚合结果，但历史记录本身不可删除。

Tip:

即使 Agent NFT 被转让，声誉记录不会随之清除——声誉属于 tokenId，而非 NFT 持有者地址。

appendResponse() [↑]

Signature: appendResponse(uint256 agentId, address clientAddress, uint64 feedbackIndex, string responseURI, bytes32 responseHash)
Emits: ResponseAppended(agentId, clientAddress, feedbackIndex)

Agent 或第三方可针对某条具体评价添加回应，形成链上可查的对话记录，让 Agent 有机会公开申诉。

🔧 声誉评分计算器模拟 getSummary() 的聚合逻辑

反馈 1 dec:

反馈 2 dec:

反馈 3 dec:

Validation Registry ↑ top

Validation Registry 是一套通用的验证器接口。与声誉（主观评价）不同，验证提供的是对 Agent 行为的客观证明，可达到密码学级别的可信度。

设计理念:

验证器完全可插拔——ERC-8004 只定义接口，不规定验证逻辑。任何人都可以部署自己的验证器合约，只要实现标准接口即可。

四种验证器类型 [↑]

类型	type值	验证机制	适用场景
质押重执行	`0`	验证者质押代币并独立重跑任务，结果不符则没收质押	确定性计算：代码执行、数学运算、数据处理
ZK-ML 证明	`1`	将 ML 推理过程编译为零知识电路，链上验证器核验证明	需证明"用特定模型处理了特定输入"但不想暴露模型
TEE 预言机	`2`	Agent 在 Intel SGX / AMD SEV 内运行，预言机提交硬件远程证明	高安全性隔离：金融交易、敏感数据处理
可信裁判系统	`3`	指定一组裁判多签或 DAO 投票，对 Agent 输出质量进行评定	主观任务：创意写作、战略建议、开放性问题

Functions [↑]

函数	参数	说明
publishValidation()	`agentId, taskHash, passed, type, proof`	验证器发布对某任务的验证结果，附带类型相关证明数据
getValidationRecord()	`agentId, taskHash`	查询某个任务的验证历史记录
getPassRate()	`agentId, validatorType`	获取 Agent 在指定验证器类型下的历史通过率

Trust Models ↑ top

三大注册表可单独使用，也可按需组合。调用方根据业务风险等级选择组合方式。

场景	推荐组合	理由
低风险 — 信息查询、文本摘要	声誉	快速低成本，参考他人使用经验即可
中等风险 — 财务分析、代码生成	声誉 + 质押验证	声誉提供历史信任，质押验证提供当次任务经济担保
高风险 — 智能合约操作、资金转移	声誉 + 质押 + TEE	需要硬件级执行隔离，防止 Agent 被恶意篡改
主观任务 — 创意、战略建议	声誉 + 裁判	客观验证无法评估主观质量，需引入人工或 DAO 裁决

Tip:

Agent 在注册文件的 trustModels 字段声明它支持哪些信任模型。调用方可据此过滤——如需 TEE 证明，只查找 trustModels 包含 "tee" 的 Agent。

Multi-Chain 部署 ↑ top

ERC-8004 使用 CREATE2 + 盐值挖矿，在所有支持的 EVM 链上以相同地址部署合约。地址前缀固定为 0x8004...。

链	Chain ID	Identity Registry	Reputation Registry
Ethereum Mainnet	1	`0x8004A169...9432`	`0x8004BAa1...B63`
Base	8453	`0x8004A169...9432`	`0x8004BAa1...B63`
Arbitrum One	42161	`0x8004A169...9432`	`0x8004BAa1...B63`
Optimism	10	`0x8004A169...9432`	`0x8004BAa1...B63`
Polygon	137	`0x8004A169...9432`	`0x8004BAa1...B63`
Ethereum Sepolia（Testnet）	11155111	`0x8004A818...D9e`	`0x8004B663...713`
Avalanche, BSC, Gnosis 等 35+ 链	各异	主网地址相同，共 40+ 条 EVM 链

UUPS 可升级模式 [↑]

标准: EIP-1822（UUPS — Universal Upgradeable Proxy Standard）

合约通过代理模式部署，逻辑合约可以升级，代理地址永久不变。升级分两阶段：

通过 CREATE2 将 MinimalUUPS 占位合约部署到确定性地址（挖矿出 0x8004... 前缀）
通过预签名交易，将代理升级为真实实现合约

Note:

实现合约构造函数调用 _disableInitializers()，防止攻击者直接初始化逻辑合约并绕过代理。

Examples ↑ top

1. 注册 Agent（JavaScript）

// 1. 上传注册文件到 IPFS
const reg = { name: "MyAgent", services: { a2a: "https://agent.com/a2a" } };
const uri = await uploadToIPFS(reg);  // → "ipfs://QmXoy..."

// 2. 调用合约注册
const registry = new ethers.Contract(
  "0x8004A169FB4a3325136EB29fA0ceB6D2e539a432",
  IDENTITY_ABI, signer
);
const tx  = await registry.register(uri, []);
const rec = await tx.wait();
const agentId = rec.logs[0].args.agentId;
// 全球 ID: eip155:1:0x8004A1...9432:{agentId}

2. 合约中用声誉做门控（Solidity）

interface IReputationRegistry {
    function getSummary(
        uint256 agentId,
        address[] calldata clientAddresses,
        string  calldata tag
    ) external view returns (int128 totalScore, uint64 count);
}

contract AgentMarketplace {
    IReputationRegistry constant REP =
        IReputationRegistry(0x8004BAa17C55a88189AE136b182e5fdA19dE9b63);

    // 只允许声誉 ≥ 7.0 分的 Agent 参与
    modifier onlyTrustedAgent(uint256 agentId) {
        address[] memory trusted = new address[](1);
        trusted[0] = msg.sender;
        (int128 score,) = REP.getSummary(agentId, trusted, "");
        require(score >= 70, "Agent reputation too low");
        _;
    }
}

Security ↑ top

威胁	防护机制	相关接口
女巫攻击（刷评价）	getSummary() 强制过滤 clientAddresses，只统计信任地址的评价	`getSummary()`
旧 owner 冒用 AgentWallet	NFT 转让时自动清除 agentWallet，需重新签名设置	`setAgentWallet()`
抹除差评	撤销仅标记 revoked=true，记录永久保留链上	`revokeFeedback()`
链下内容篡改	endpointHash 存储 KECCAK-256，调用方可验证链下文件完整性	`endpointHash`
域名冒充	对比 /.well-known/agent-registration.json 与链上数据	域名验证（可选）
代理合约直接初始化	实现合约构造函数调用 _disableInitializers()	UUPS

Quiz ↑ top

5 道题检验你对 ERC-8004 的理解。

1. Identity Registry 基于哪个 ERC 标准，Agent 身份因此具有什么特性？

2. getSummary() 为什么强制要求传入 clientAddresses 参数？

3. 一条反馈被 revokeFeedback() 撤销后，链上会发生什么？

4. 哪种验证器最适合"证明 AI 使用了特定模型处理了特定输入，但不想暴露模型权重"？

5. ERC-8004 在 40+ 条链上实现相同地址（0x8004...）依赖的是什么技术？

Summary ↑ top

注册表	核心函数	关键设计
Identity Registry	`register()` · `setAgentURI()` · `setAgentWallet()`	ERC-721 NFT 身份；转让自动清除 wallet；域名验证可选
Reputation Registry	`giveFeedback()` · `getSummary()` · `revokeFeedback()`	固定精度评分；clientAddresses 防女巫；撤销保留记录
Validation Registry	`publishValidation()` · `getPassRate()`	可插拔验证器；ZK / TEE / 质押 / 裁判四种类型

Note:

ERC-8004 当前为 Draft 状态（创建于 2025-08-13）。依赖标准：ERC-155 · ERC-712 · ERC-721 · ERC-1271 · EIP-1822(UUPS)。规范以官方 EIP-8004 为准。