ERC-8004：Trustless Agents — 以「聲譽＋驗證」建立跨組織的 Agent 發現與信任

摘要

本文翻譯並解析 ERC-8004: Trustless Agents 提案（草案版），該提案在既有的 Agent-to-Agent（A2A Protocol） 之上，新增一層「信任層」，讓參與者能在沒有既有信任的跨組織情境下，去發現、選擇、並與 agents 互動。

它引入三個輕量且 on-chain 的 registry：Identity、Reputation、Validation；而把應用層的細節邏輯留給 off-chain 元件。

原始提案：ERC-8004 on EIPs

動機

現有 A2A Protocol 已涵蓋 agent 驗證、透過 AgentCard 公告技能、direct messaging 與完整的任務生命週期協作。其被大型科技公司採用，顯示市場需求明確。

然而，協定目前多在組織邊界內運作，並假設 Server Agent 與 Client Agent 之間存在信任。

若要促進開放、跨組織的 agent 經濟，我們需要在不可信環境中發現並建立信任的機制。

核心架構：三層 Registry

本 ERC 以三個核心元件回應此需求（可部署於任一 L2 或 Mainnet）：

graph TB subgraph "ERC-8004 Trustless Agents 架構" A[Agent] --> IR[Identity Registry] A --> RR[Reputation Registry] A --> VR[Validation Registry] IR --> |註冊| ID[AgentID + AgentDomain + AgentAddress] ID --> |解析| AC[AgentCard
off-chain] RR --> |授權| FB[Feedback Authorization] FB --> |回饋| OC1[Off-chain Attestations] VR --> |請求| VReq[Validation Request] VReq --> |驗證| Validator{Validator Agent} Validator --> |crypto-economic| CE[重跑任務驗證] Validator --> |crypto-verifiable| CV[TEE/zkTLS 驗證] Validator --> |回應| VResp[Validation Response] VResp --> OC2[Off-chain Evidence] end style IR fill:#e1f5ff style RR fill:#fff4e1 style VR fill:#f0e1ff

1. Identity Registry

最小化 on-chain handle，解析到 agent 的 off-chain AgentCard，提供可攜、抗審查的識別子。

每個 agent 以以下三者唯一識別：

AgentID：鏈上遞增的全域識別子
AgentDomain：依 RFC 8615，其 AgentCard 必須置於 https://{AgentDomain}/.well-known/agent-card.json
AgentAddress：EVM-compatible 地址

寫入端點：

New(AgentDomain, AgentAddress) → AgentID
Update(AgentID, Optional NewAgentDomain, Optional NewAgentAddress) → Boolean

公開查詢：

Get(AgentID)
ResolveByDomain(AgentDomain)
ResolveByAddress(AgentAddress)

2. Reputation Registry

此 registry 提供以 off-chain attestations 交換任務回饋的輕量入口。為降低 on-chain 成本，鏈上只存必要資料。

授權流程：Server Agent 接受任務時，預先授權該 Client Agent 在任務完成後提供回饋。

核心端點：

AcceptFeedback(AgentClientID, AgentServerID) → 觸發 AuthFeedback 事件

Feedback 資料結構：每個提供回饋的 Client Agent，其 Agent Card 必須以 FeedbackDataURI 指向 JSON 清單，項目包含：

FeedbackAuthID（CAIP-10 格式）
可選的 AgentSkillId、TaskId、contextId
Rating、ProofOfPayment、Data 等

3. Validation Registry

提供兩種驗證模式：

Crypto-economic 驗證

DataHash 承諾（commit）重跑工作所需的全部資訊（含輸入與要驗證的輸出）
AgentValidator 可以是單一中心化 agent、門檻式委員會（k-of-n）smart contract、押注保護的服務

Crypto-verification 驗證

DataHash 承諾產出 TEE attestation 或 zkTLS 所需全部資訊
AgentValidator 為 on-chain 驗證 smart contract

核心端點：

ValidationRequest(AgentValidatorID, AgentServerID, DataHash)
ValidationResponse(DataHash, Response)

三種信任模型

開發者可依據任務的風險等級，在三種信任模型中選擇：

graph LR subgraph "信任模型選擇" Task[任務] --> Risk{風險等級} Risk --> |低風險| T1[Reputation-based
基於聲譽] Risk --> |中風險| T2[Stake-secured
押注經濟] Risk --> |高風險| T3[TEE Attestations
可驗證密證] T1 --> U1[點餐
簡單查詢] T2 --> U2[一般業務
數據處理] T3 --> U3[醫療診斷
金融交易] T1 -.-> C1[成本: 低
速度: 快] T2 -.-> C2[成本: 中
保證: 經濟誘因] T3 -.-> C3[成本: 高
保證: 密碼學] end style T1 fill:#d4edda style T2 fill:#fff3cd style T3 fill:#f8d7da

1. Reputation-based（基於聲譽）

適用場景：低風險任務（如點餐、簡單查詢）
機制：依據客戶回饋建立聲譽系統
特點：輕量、快速、成本低

2. Stake-secured Inference Validation（押注經濟學）

適用場景：中風險任務
機制：Validator 押注並重跑任務驗證結果
特點：經濟誘因保證驗證品質

3. TEE Attestations（可驗證密證）

適用場景：高風險任務（如醫療診斷、金融交易）
機制：使用 TEE（Trusted Execution Environment）或 zkTLS
特點：密碼學保證的可驗證性

參與者角色

所有參與者必須先於 Identity Registry 註冊。Agent 可具三種角色：

Server Agent（A2A Server）：提供服務並執行任務
Client Agent（A2A Client）：指派任務並提供回饋
Validator Agent（可選）：以押注或密證方式進行驗證

Agents 可同時扮演多個角色，不受限制。

sequenceDiagram participant C as Client Agent participant IR as Identity Registry participant S as Server Agent participant RR as Reputation Registry participant V as Validator Agent participant VR as Validation Registry Note over C,VR: 完整的 Agent 互動流程 C->>IR: 1. 註冊 (AgentDomain, AgentAddress) IR-->>C: AgentID S->>IR: 2. 註冊 (AgentDomain, AgentAddress) IR-->>S: AgentID C->>IR: 3. 查詢可用的 Server Agents IR-->>C: Server Agent 列表 C->>S: 4. 指派任務 S->>RR: 5. 預先授權回饋 (ClientID, ServerID) RR-->>S: FeedbackAuthID S->>S: 6. 執行任務 S-->>C: 7. 回傳結果 alt 需要驗證 C->>VR: 8. 請求驗證 (ValidatorID, ServerID, DataHash) VR-->>V: ValidationRequest 事件 V->>V: 9. 執行驗證 (重跑或 TEE) V->>VR: 10. 提交驗證結果 (DataHash, Response) VR-->>C: ValidationResponse 事件 end C->>RR: 11. 提供回饋 (使用 FeedbackAuthID) RR-->>S: AuthFeedback 事件 Note over C,VR: 回饋與驗證記錄存於 off-chain

Agent Card 結構

沿用 A2A Protocol 的 Extension 概念，Agent Card 應包含：

必要欄位

{
  "registrations": [
    {
      "agentAddress": "eip155:1:0x...",  // CAIP-10 格式
      "agentId": "12345",
      "agentDomain": "example.com"
    }
  ],
  "trustModels": [
    "feedback",
    "inference-validation",
    "tee-attestation"
  ]
}

可選欄位

FeedbackDataURI：指向回饋資料的 URI
ValidationRequestsURI：驗證請求資料
ValidationResponsesURI：驗證回應資料

設計理念

Off-chain 基礎設施

將複雜操作下放到 off-chain，以便：

使用進階的聲譽演算法與聚合服務
採用具彈性的驗證協定與自訂誘因機制
擴展資料儲存與檢索

互通性

CAIP-10 確保鏈無關的地址格式
RFC 8615 使 web-based 服務發現具標準化
模組化設計可無痛整合既有支付與驗證系統

安全考量

回饋需事前授權（pre-authorization）
鏈上指標（pointers）不可刪除，確保稽核軌跡完整性
Validator 的誘因與懲罰由各驗證協定管理
驗證 Identity Registry 中的 AgentDomain 是否真對應到 Agent Card 由協定使用者自行處理

可能的未來方向

跨鏈識別子
以 NFT 表徵 agent 的鑄造/所有權/轉移
ENS 支援
與 A2A 支付擴充的整合
對回饋/驗證的可用性提供誘因
在 Identity Registry 驗證 AgentDomain

小結

ERC-8004 為 AI Agent 生態系統提供了一個輕量、模組化、可擴展的信任框架。透過三層 Registry（Identity、Reputation、Validation）的設計，它實現了：

可發現性：標準化的 Agent 註冊與查詢機制
可信任性：多層次的信任模型適用不同風險場景
可擴展性：Off-chain 設計降低成本並保持彈性
互通性：採用業界標準（CAIP-10、RFC 8615）

這個提案代表了 Web3 與 AI Agent 融合的重要一步，為未來的跨組織 Agent 經濟奠定了基礎。

參考資料

版權

原提案採 CC0（權利拋棄）授權。

摘要#

動機#

核心架構：三層 Registry#

1. Identity Registry#

2. Reputation Registry#

3. Validation Registry#

Crypto-economic 驗證#

Crypto-verification 驗證#

三種信任模型#

1. Reputation-based（基於聲譽）#

2. Stake-secured Inference Validation（押注經濟學）#

3. TEE Attestations（可驗證密證）#

參與者角色#

Agent Card 結構#

必要欄位#

可選欄位#

設計理念#

Off-chain 基礎設施#

互通性#

安全考量#

可能的未來方向#

小結#

參考資料#

版權#

跳出資訊焦慮，進入策略思維

⚡ 跳出資訊焦慮，進入策略思維

摘要

動機