無信任代理人的匿名憑證 (ACTA)：鏈上代理人經濟的隱私層
本文提出了 ACTA，這是一個建立在 ERC-8004 之上的可組合隱私層，利用匿名憑證與零知識證明技術，在維持問責制的同時，保護 AI 代理人的互動圖譜不被公開洩露。
特別感謝 Davide、Nam、Marco、Thore 以及 Vivian 的反饋與審閱。
2026 年 5 月
內容摘要
ERC-8004（去中心化代理人）在 AI 代理人及其客戶之間產生了一個永久且公開的交互圖譜——每一次聲譽信號、每一次憑證檢查、每一次授權都不可篡改地記錄在鏈上。
雖然 ERC-8004 對於需要透明度的代理人部署非常有用，但對於「交互圖譜本身即是敏感數據」的情況，具備隱私保護的解決方案將至關重要。
ACTA 提議在 ERC-8004 之上建立一個使用匿名憑證（Anonymous Credentials）的可組合隱私層，使代理人能夠證明各項主張——如人格證明、審計評分、模型來源、聲譽、管轄權——而無需洩露底層數據。
ACTA 還解決了「委託人（Principal）」層面的問題：代理人可以證明其是在經過驗證的人類委託人授權下行動（使用人格憑證，Adler et al., 2024），使治理和 DeFi 協議能夠排除完全自主的機器人，同時不暴露任何參與者的現實世界身份。
ICircuitVerifier 抽象層刻意將 ACTA 與任何特定的證明系統解耦：SNARKs、STARKs、zkVMs 以及未來的後量子構造都是一等後端，可以在不更改 ACTA 合約的情況下根據策略進行更換。
本文介紹了草案內容，梳理了七個現今即可部署的具體鏈上案例，並邀請生態系統、開發者、DeFi 協議開發者以及 ERC-8004 的作者共同協作。
簡介
想像一個透過專業 AI 代理人（流動性路由代理、風險評估代理和清算代理）進行執行的 DeFi 協議。每個代理人都透過 ERC-8004 在鏈上註冊，並隨著交易結算透過可驗證的反饋建立聲譽。路由代理每天調用風險代理五十次；清算代理每個區塊都會收到質量評分。這些交互中的每一項都是永久且不可篡改地公開的：調用地址、代理人標識符、反饋分數和任務終端標籤。任何運行事件索引器的人都可以精確地重構出哪個協議正在使用哪個執行層、頻率如何、質量結果為何，以及哪些代理商正在贏得市場。對於一個以執行策略為核心競爭力的協議來說，這種交互圖譜就是其「超額收益（Alpha）」。默認將其發佈到全球公共賬本上不僅是隱私問題，更是一個直接的經濟攻擊面。
這並不侷限於 DeFi。任何參與者透過 AI 代理人路由解析查詢的鏈上交互都會暴露其工作流程。使鏈上代理人信任具備價值的問責屬性——可驗證聲譽、可審計憑證主張和可組合反饋——同時也是導致當前 ERC-8004 設計在許多實際鏈上案例中不夠完善的原因。
零知識證明可以用於允許代理人私密地證明其滿足評分閾值、持有核准的模型哈希，並在制裁名單之外運行。匿名憑證方案允許提交聲譽反饋，而無需將其與提交者的地址關聯。無效化器（Nullifier）機制可在不披露身份的情況下防止重複使用。ACTA 將這一切作為一個可組合的隱私層引入鏈上代理人經濟，該層位於 ERC-8004 之上且無需對其進行修改。
背景
ERC-8004 填補了基礎設施的空白：代理人和客戶如何在沒有預先關係的情況下跨組織邊界建立信任？它提出了三個鏈上註冊表：
身份註冊表 (Identity Registry)：為每個代理人提供一個基於 ERC-721 的便攜式標識符。
聲譽註冊表 (Reputation Registry)：提供發布和讀取反饋信號的標準接口，可與任何評分系統組合。
驗證註冊表 (Validation Registry)：允許代理人請求並記錄其輸出的獨立驗證。
對於需要開放、互操作信任層的代理人經濟來說，這是正確的基礎。ACTA 則是該基礎的延伸。
隱私缺口
ERC-8004 當前的設計為任何對交互圖譜具有個人、經濟或監管敏感性的部署創造了五個特定的、可利用的漏洞：
永久公開的交互圖譜：NewFeedback 事件以明文形式在鏈上不可篡改地發出 clientAddress、agentId、value 和任務標籤。攻擊場景：競爭對手索引這些事件，以識別對手正在使用哪些執行代理、頻率以及質量評級，從而實時重構其 AI 執行策略。
會話間缺乏不可關聯性：readAllFeedback() 函數列舉了任何給定客戶地址和代理人的每一次交互。同一客戶的多個交互可以輕易關聯，從而實現對交易模式或分析工作流的統計推斷。
憑證無法選擇性披露：代理人的 agentURI 註冊文件同時暴露了所有功能、終端、DID、ENS 名稱和錢包地址。詢問「該代理人是否符合我的管轄權要求？」的交易對手會收到代理人的完整運營概況，包括可能具有商業敏感性的細節。
女巫攻擊防禦需要識別評論者：ERC-8004 承認 getSummary() 需要一個非空的 clientAddresses[] 過濾器，因為未經過濾的結果容易受到女巫垃圾郵件的攻擊。預期的緩解措施要求評論者在鏈上是可識別的。
跨註冊表指紋識別：agentId（ERC-721 代幣）、agentWallet（在鏈上明確鏈接）以及註冊文件中可選的 DID 字段相結合，創造了一個獨特的三維指紋，將分離的身份上下文坍縮為單一的可追蹤配置文件，橫跨鏈上和鏈外系統。
核心理念：去中心化代理人的匿名憑證
在現實生活中使用匿名憑證，你可以出示一個加密證明，僅說明「此人的出生日期（由政府簽發者認證）滿足年齡 ≥ 18 的斷言」。
將此擴展到鏈上 AI 代理人。例如：一個 DeFi 協議的風險管理合約需要驗證它即將授權交易的執行代理人是否具有足夠的審計分數、核准的模型版本，且操作員不在 OFAC 名單上。使用匿名憑證：
代理人生成一個證明，證明其憑證同時滿足這三個斷言。
協議在鏈上驗證該證明。
發出一個事件：一個不可關聯的無效化器（nullifier）和被滿足的策略 ID。
代理人的實際審計分數、模型哈希和管轄權永遠不會在任何地方發布。
ACTA：可能的組件
憑證錨定 (IOpenACCredentialAnchor)：在代理人可以進行匿名出示證明之前，它會在鏈上註冊其憑證的加密承諾。這是代理人主密鑰與其憑證屬性結合後的盲化哈希——它證明了憑證的存在且由合法簽發，而不洩露任何屬性值。錨定合約驗證正確承諾形成的零知識證明（使用操作員選擇的任何 ICircuitVerifier），然後僅存儲承諾哈希、簽發者密鑰承諾、憑證架構標識符和過期時間戳。鏈上不會出現憑證細節。這是所有下游證明流程依賴的前提。
策略註冊表 (IPolicyRegistry)：驗證者（DeFi 協議、DAO、鏈上合規預言機）將策略註冊為布爾斷言程序：audit_score >= 80 AND operator_jurisdiction_not_in(OFAC_LIST)。策略以哈希形式存在於鏈上。PolicyDescriptor 包括斷言程序哈希、憑證架構、簽發者承諾、有效期窗口，以及關鍵的——用於證明驗證的 ICircuitVerifier 實現地址。策略一旦註冊即不可更改。
斷言驗證 (IPredicateVerifier)：當代理人出示證明其憑證滿足已註冊策略時，此合約處理每次調用的驗證。它從 IPolicyRegistry 讀取信息，將驗證委託給註冊的 ICircuitVerifier，註冊生成的無效化器，並發出一個 PresentationAccepted 事件，其中僅包含策略 ID、無效化器和過期時間戳。不會洩露代理人身份、屬性值或錢包地址。
無效化器註冊表 (INullifierRegistry)：無效化器具有上下文範圍：每個無效化器都由代理人的主密鑰結合包含驗證者地址和會話隨機數（nonce）的上下文哈希導出。同一個代理人針對驗證者 A 的無效化器與針對驗證者 B 的無效化器在計算上是不相關的。在單個會話上下文中，重複使用會被檢測並拒絕，從而在不披露全局身份的情況下提供每會話的女巫攻擊防禦。
ZK 聲譽累加器 (IZKReputationAccumulator)：客戶以零知識證明的形式提交聲譽反饋，證明他們持有有效的交互憑證，且尚未在此上下文中提交過反饋。反饋值存儲為盲化默克爾樹葉節點——承諾無效化器和數值，同時在事件日誌中隱藏該值。
累加器使用保留標籤通過標準 giveFeedback() 接口將其默克爾根寫回 ERC-8004 現有的聲譽註冊表，從而保持與任何兼容 ERC-8004 的聲譽聚合器的組合性。代理人稍後可以證明其匿名總分超過某個閾值，而無需洩露任何單條反饋記錄。
範例：協議流程
角色創建：簽發者、代理人和驗證者各自獲得一個錨定在以太坊地址上的 did:ethr 身份。
架構配置：簽發者定義 AgentCapabilityCredential 包含的字段，如 auditScore、operatorJurisdiction 和 capabilities。
憑證簽發：簽發者向代理人錢包簽發一個 JWT-VC，憑證保留在鏈下。
鏈上錨定：代理人對其憑證計算承諾和默克爾根，並將其寫入 OpenACCredentialAnchor，指定其將用於證明的 ICircuitVerifier 實現。
斷言構建：驗證者將其合規規則定義為結構化斷言（例如 auditScore ≥ 80 AND caps ⊇ 'evm-execution'），使用 OpenAC 通用斷言包進行編譯，並導出確定性的 predicateProgramHash。
策略註冊：驗證者在鏈上調用 IPolicyRegistry.registerPolicy()，在一個 policyId 下鎖定斷言哈希、信任的簽發者承諾以及所選 ICircuitVerifier 的地址。
出示請求：驗證者向代理人發送 policyId、一個新的 sessionNonce 及其地址——將證明範圍限定於本次交互。
證明生成：代理人的 OpenAC 錢包編譯斷言，在客戶端生成 ZK 證明，公開輸出為無效化器、contextHash 和 predicateHash，但不包含憑證數值。
驗證：驗證者將證明提交給 IPredicateVerifier.verifyPresentation()。合約完全委託給註冊的 ICircuitVerifier，註冊無效化器，並發出 PresentationAccepted(policyId, nullifier, expiryTimestamp)。
授予訪問權限：代理人向 AgentAccessGate 出示其無效化器——首次使用時授予權限，重複使用時則因 NullifierAlreadyActive 而回退。
撤銷機制被認為超出了本文的討論範圍。PSE 對撤銷設計策略有深入研究，可以在這裡找到。
案例研究：鏈上應用
DeFi 協議代理人授權
隨著 DeFi 協議越來越多地透過專業 AI 代理人進行執行，協議的智能合約如何信任這些代理人成為一個迫切的問題。在 ERC-8004 下，協議發布的每一次授權檢查和每一次質量評級都是永久公開的。在 ACTA 下，協議在 IPolicyRegistry 中註冊功能策略，代理人透過 IPredicateVerifier 對其出示匿名斷言證明。協議在註冊策略時選擇其 ZK 後端。調用 verifyPresentation 的協議合約對選擇了哪個後端並不關心；無論哪種方式，它都讀取相同的 policyId 並接收相同的 PresentationAccepted 事件。
抗審查的代理人聲譽
預測市場、借貸協議以及任何依賴代理人質量信號的系統都面臨同樣的問題：在 ERC-8004 下，有意義的聲譽只能由已識別的評論者提交。因為 getSummary() 需要非空的 clientAddresses[] 過濾器來防止女巫攻擊，匿名來源無法做出貢獻。任何能夠識別並向評論者施壓的角色（如主導協議或資源豐富的競爭對手）都可以完全壓制其反饋。最能識別不當行為的參與者被迫保持沈默，因為發聲在經濟上是自我毀滅的：預測市場參與者舉報偏袒的結算代理人會永久關聯其地址，進而關聯其未平倉頭寸。ACTA 的 ZK 聲譽累加器直接解決了這個問題。任何憑證持有者都可以在不讓其地址出現在鏈上的情況下提交反饋；無效化器機制防止重複投票；累加器根作為可組合信號錨定回 ERC-8004 的聲譽註冊表。
代理人對代理人及代理人對協議交互的私密憑證驗證
當 AI 代理人代表人類委託人開始執行鏈上交易（兌換、貸款、轉賬、合約調用）時，受監管的協議面臨新的合規挑戰：如何驗證交易中的「代理人」其操作員已通過憑證檢查、在許可的管轄區內運營且不在制裁名單上——而無需代理人在每筆交易中向全鏈廣播其操作員的身份？在 ERC-8004 下，沒有這種機制；代理人的公開註冊直接將其 agentId 與其操作員的錢包鏈接。透過 ACTA，代理人錨定由合規身份提供商簽發的憑證，註冊要求 operator_jurisdiction_not_in(sanctionsList) AND credential_tier >= required_tier 的功能策略，並向受監管協議出示匿名斷言證明以進行可驗證的合規。這直接對應了 FATF 的轉帳規則 (Travel Rule) 預計如何應用於新興指導方針下的自主代理人。
跨協議的自主代理人身份
在 Uniswap 代理人授權框架上運行的經過憑證驗證的代理人，應該能夠將其聲譽和合規證明帶到 Aave 或任何兼容 ERC-8004 的協議，而無需為每個協議從頭重構其交互歷史。在 ERC-8004 下，這種跨協議的可移植性雖然存在，但會向任何關聯跨註冊表 agentId 的人暴露代理人在所有協議中的完整交互歷史。代理人的運營歷史、供應商關係和憑證概況變得永久可讀。在 ACTA 下，代理人向每個協議出示新的匿名斷言證明，並由特定上下文的無效化器限定範圍。每個協議都獲得了所需的驗證；從鏈上數據無法構建跨協議的交互圖譜。代理人的身份是由其委託人最終決定的，更重要的是，它是可移植且不可關聯的。
無許可的代理人聲譽冷啟動
進入 ERC-8004 生態系統的新代理人面臨冷啟動問題：沒有聲譽、沒有歷史、沒有社交證明。目前的解決方案——累積公開反饋——要求代理人公開進行交易，在擁有任何有意義的市場地位以保護自己之前，將其整個早期交互歷史暴露於永久索引中。在 ACTA 下，代理人可以從第一次交互開始透過 ZK 累加器啟動聲譽，在不發布永久交互圖譜的情況下累積匿名但可驗證的聲譽信號。當代理人稍後向潛在的 DeFi 協議證明其總分超過信任閾值時，無論底層反饋是在 ERC-8004 的公開模型還是 ACTA 的匿名模型下提交的，該證明都是有效的——因為累加器的默克爾根作為標準反饋信號錨定回了 ERC-8004 的聲譽註冊表。
人格憑證與「代理人背後的人類」問題
上述案例都涉及「代理人」的憑證——其審計分數、模型來源、管轄權合規。但在委託人層面存在一個並行且同樣緊迫的問題：DeFi 協議、預測市場或 DAO 治理合約如何知道提交交易的代理人是代表真實的人類行動，而不是一個背後沒有負責委託人的完全自主機器人？Adler, Hitzig, Jain et al. (2024) 將此定義為人格憑證問題。一個「人格憑證 (PHC)」證明其持有者是真實的人，而不透露任何進一步的身份信息，使用與 ACTA 應用於代理人功能主張相同的不可關聯匿名性和零知識證明屬性。該論文將向 AI 代理人的驗證授權確定為 PHC 的三個主要用例之一：
委託人將其人格憑證鏈接到他們控制的代理人。
代理人能夠向服務證明真實的人類對代理人的行為負責，而不披露該人類是誰。
這對當前的治理至關重要：一個想要將投票或提案權限制在由真實人類支持的代理人（而非自主機器人）手中的 DAO，目前沒有保護隱私的機制來執行此操作。
社群開放問題
匿名集大小：斷言證明的匿名保證受限於憑證滿足相同斷言的其他代理人數量，策略中每增加一個屬性約束都會加劇這個問題，即使每個單獨的約束看起來都是良性的，也可能使代理人去匿名化。對於不同的風險背景，合適的最低閾值是多少？一個有前景的方向是使用 VOPRF 網絡（可驗證不經意偽隨機函數）。
隱私保護的「代表 (OBO)」授權：OpenID 基金會關於代理 AI 身份的 2025 年白皮書指出，從代理人冒充轉向明確的授權委託是該領域最緊迫的未解決問題。一個適當的 OBO 流程需要編碼兩個不同身份的憑證——授權的人類委託人和行動的代理人——但在公共鏈上永久發布兩者會創建一個本身就是敏感數據的授權圖譜。ACTA 的 principal_vc_satisfies() 斷言提供了一條 ZK 路徑：代理人證明其授權委託人持有滿足策略的有效憑證，而不透露該委託人是誰。這應該如何與鏈下現有的 OAuth 2.0 Token Exchange 流程交互？對於遞歸授權（代理人授權給子代理人），在沒有信任中介的情況下驗證整個鏈條所需的最小斷言表達能力是多少？
簽發者啟動與中心化風險：在實踐中，誰來簽發 AgentCapabilityVC？審計公司和 TEE 認證服務是顯而易見的候選者，但少數信任的簽發者很快就會成為信任瓶頸，且中心化簽發者可以透過記錄簽發行為使憑證持有者去匿名化。對於代理人功能憑證，是否存在一條可信的路徑來建立去中心化的簽發者註冊表，使其在不重新引入註冊表層信任方的情況下保持抗女巫攻擊能力？去中心化憑證簽發的潛在方法有哪些？
門限解密作為標準擴展：ACTA 默認是完全匿名的——鏈上的無效化器在沒有代理人主密鑰的情況下無法鏈接到其代理人。這是正確的默認設置，但它為濫用案例留下了缺口：匿名運行的惡意代理人沒有問責機制。ACTA 是否應該為門限委員會去匿名化定義一個標準擴展——即在被提名受託人之間的私鑰分片或門限簽名方案，在鏈上證明存在濫用行為時，可以揭露特定無效化器背後的代理人？什麼樣的治理機制可以在不重建中心化的情況下選擇和輪換委員會？
具備不可關聯性的跨鏈憑證可移植性：天真地跨鏈橋接憑證默克爾根會重新創造一個關聯向量——出現在多條鏈上的相同根可以與原始錨定交易相關聯。是否存在一種既能保持不可關聯性，又能實現跨鏈憑證可移植性的完善設計？
客戶端證明：在證明大小、鏈上驗證 Gas 和證明者延遲方面，在什麼樣的實際閾值下，基於 zkVM 的 ICircuitVerifier 實現會比基於電路的實現更適合 ACTA 用例？
代理人對代理人交互的私密信任圖譜：ACTA 當前的憑證模型是以代理人為中心的：AgentCapabilityVC 證明單個代理人「是什麼」。但在多代理人經濟中，信任越來越依賴於兩個代理人「彼此是什麼」——他們是否有過往的驗證交互、授權關係或共同的委託人。有趣的開放問題是，這類私密憑證網絡是否能形成一個局部可驗證的信任圖譜（每個代理人僅證明其直接關係），同時保持全局不可關聯，使觀察者無法重構更廣泛的網絡拓撲。這些憑證應如何簽發、由誰簽發，以及在何種撤銷模型下運行？
行動呼籲
致 ERC-8004 作者：ACTA 旨在作為補充而非競爭對手。聲譽註冊表的 giveFeedback() 接口和身份註冊表的操作員/所有者模型被直接利用。我們正在尋求在草案定稿前，就兩個特定的集成點達成早期共識：giveFeedback() 中的 zkReputationRoot 標籤慣例，以及 anchorCredential() 中的操作員權限檢查。任何關於設計兼容性的疑慮最好現在提出。
致 DeFi 協議開發者、預測市場團隊和基礎設施建設者：本文中的六個用例是我們對需求所在的最優猜測——但我們可能遺漏了對您而言顯而易見的特定部署障礙。如果「代理人證明斷言，協議在鏈上驗證，不披露身份」的模型不符合您的實際架構或監管約束，那麼在草案階段的反饋比最終審查時更有價值。請參與討論串。
致 EIP 編輯：我們打算在近期將 ACTA 作為正式的標準軌道（Standards Track）草案提交。鑑於 ERC-8004 本身仍處於草案（Draft）狀態，存在一個順序問題：ACTA 應該等待 ERC-8004 進入審閱（Review）階段後再正式提交，還是考慮到 ACTA 依賴於 ERC-8004 但不修改它，兩個草案應該並行推進。我們歡迎關於首選流程的指導。
我們正在徵求協議設計的提案和投稿。請聯繫我們或在下方留言。
延伸閱讀
OpenAC: Open Design for Transparent and Lightweight Anonymous Credentials - IACR ePrint 2026/251
PSE/zkID GitHub - privacy-ethereum/zkID
AI Agents with Decentralized Identifiers and Verifiable Credentials
https://ethresear.ch/t/zk-api-usage-credits-llms-and-beyond/24104
https://github.com/privacy-ethereum/zkID/tree/main/revocation
1 則貼文 - 1 位參與者
[閱讀完整主題](https://ethresear.ch/t/anonymous-credentials-for-trustless-agents-acta/24797)
相關文章