面向去信任代理的匿名凭证（ACTA）：隐私

以太坊中文发布于 2026-05-06 阅读 206

ACTA 为 ERC-8004 链上代理经济提供隐私层，使用匿名凭证让代理在不泄露交互图的情况下证明资质、声誉和合规性。文章介绍了 ACTA 的组件（凭证锚定、策略注册、谓词验证、无效器注册、ZK 声誉累积器）、协议流程、七个链上用例如 DeFi 代理委托、抗审查声誉、人证凭证等，并讨论了匿名集大小、委托授权、发行者中心化等开放问题。目标是成为 ERC-8004 的可组合扩展，推动隐私保护的代理经济。

## 匿名凭证与无需信任代理（ACTA）——链上代理经济的隐私层

特别感谢 [Davide](https://x.com/DavideCrapis)、Nam、[Marco](https://x.com/marco_derossi)、Thore 和 [Vivian](https://x.com/ViviPlasenciaC) 的反馈和审阅。

_2026 年 5 月_

* * *

**TL;DR**

- ERC-8004（无需信任代理）在 AI 代理及其客户之间生成一个永久性、公开的交互图——每一条声誉信号、每一次凭证检查、每一次委托都不可变地记录在链上。

- 尽管 ERC-8004 对于需要透明度的代理部署场景非常有用，但在**交互图本身即为敏感数据**的情况下，隐私保护方案将至关重要。

- ACTA 提出在 ERC-8004 之上构建一个可组合的隐私层，利用匿名凭证，使得代理能够证明声明——如人格凭证、审计评分、模型来源、声誉、管辖区域——而不泄露底层数据。

- ACTA 还解决了**委托人**层面：代理可以使用人格凭证（Adler 等人，2024）证明其在经过验证的人类委托人下行动，从而使治理和 DeFi 协议能够排除完全自主的机器人，同时不暴露任何参与者的真实世界身份。

- **`ICircuitVerifier`** 抽象层有意地将 ACTA 与任何特定的证明系统解耦：SNARK、STARK、zkVM 以及未来的后量子构造均可作为一等公民的后端，可根据策略随时切换，而无需修改 ACTA 合约。

- 这篇博文介绍了草案，演练了七个当前即可部署的具体链上用例，并邀请生态、构建者、DeFi 协议开发者以及 ERC-8004 作者参与协作。

* * *

### 引言

设想一个 DeFi 协议，它将执行过程路由到专门的 AI 代理——一个流动性路由代理、一个风险评估代理和一个清算代理。每个代理通过 ERC-8004 在链上注册，通过交易结算时的可验证反馈来建立声誉。路由代理每天调用风险代理五十次。清算代理每个区块都会收到质量评分。这些交互中的每一个都永久且不可变地公开：调用地址、代理标识符、反馈评分以及任务端点标签。任何运行事件索引器的人都可以精确重建哪个协议在使用哪个执行层、使用频率、质量结果如何、以及哪些代理供应商正在赢得市场。对于一个以执行策略为优势的协议来说，这个交互图**就是 alpha**。默认将其发布到全局公共账本不仅是一个隐私问题，更是一个直接的经济攻击面。

这并不仅限于 DeFi。**任何参与者通过 AI 代理路由解析查询的链上交互都将暴露其工作流程。** 使得链上代理信任**有价值**的问责属性——可验证的声誉、可审计的凭证声明以及可组合的反馈——也正是导致当前 ERC-8004 设计对于许多实际链上用例不完整的原因。

零知识证明可以用于允许代理证明其满足某个评分阈值、持有已批准的模型哈希、并且在制裁名单之外——所有这些都是私密的。匿名凭证方案允许在不将反馈提交者的地址与之关联的情况下提交声誉反馈。无效器机制可以在不暴露身份的情况下防止重复使用。**ACTA** 将这一切带入链上代理经济，作为一个可组合的隐私层，位于 ERC-8004 之上而无需修改它。

### 背景

ERC-8004 解决了一个基础设施缺口：代理和客户如何在没有任何预先存在关系的情况下跨组织边界建立信任？它提出了三个链上注册表。

1. **身份注册表**为每个代理提供一个基于 ERC-721 的可移植标识符。

2. **声誉注册表**提供标准接口用于发布和读取反馈信号，可与任何评分系统组合使用。

3. **验证注册表**允许代理请求并记录其输出的独立验证。

对于一个需要开放、可互操作信任层的代理经济而言，这是正确的基础。ACTA 是对该基础的扩展。

### 隐私缺口

ERC-8004 当前的设计为任何交互图携带个人、经济或监管敏感性的部署创造了五个具体且可被利用的漏洞：

1. **永久公开的交互图。** `NewFeedback` 事件以明文形式、不可变地将 `clientAddress`、`agentId`、`value` 和任务标签发出到链上。**攻击场景**：一个竞争性的 DeFi 协议索引这些事件，以识别对手正在使用哪些执行代理、使用频率以及质量评分——实时重建其 AI 执行策略。

2. **跨会话不可链接性缺失。** `readAllFeedback()` 函数枚举了给定客户地址和代理的每一次交互。同一客户的多次交互可被轻易链接，从而实现对交易模式或分析工作流的统计推断。

3. **凭证的不可选择性披露。** 代理的 `agentURI` 注册文件同时暴露了所有能力、端点、DID、ENS 名称和钱包地址。一个问询“此代理是否符合我所在司法管辖区的合规要求？”的对手方会收到代理的完整运营档案，包括潜在的商业敏感细节。

4. **抗女巫攻击需要审查者身份识别。** ERC-8004 承认 `getSummary()` 要求非空的 `clientAddresses[]` 过滤器，因为未过滤的结果易遭受女巫攻击。预期的缓解措施要求审查者在链上可被识别。

5. **跨注册表指纹关联。** `agentId`（ERC-721 代币）、`agentWallet`（在链上明确关联）以及注册文件中的可选 `DID` 字段的组合创建了一个三维指纹，将分开的身份上下文折叠成一个可追踪的配置文件，跨越链上和链下系统。

### 核心理念：匿名凭证与无需信任代理

在现实生活中，使用匿名凭证，你可以出示一个加密证明，仅说明“此人的出生日期，经政府签发者证明，满足谓词 `age ≥ 18`”。

将其扩展到链上 AI 代理。例如：一个 DeFi 协议的风险管理合约需要验证它即将委托交易给的那个执行代理是否具有足够的审计评分、已批准的模型版本，并且其运营者不在 OFAC 名单上。使用匿名凭证：

1. 代理生成一个证明，证明其凭证同时满足所有三个谓词。

2. 协议在链上验证该证明。

3. 发出一个事件：一个不可链接的无效器和已满足的策略 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`）。** 客户以零知识证明的形式提交声誉反馈，证明他们持有有效的交互凭证并且尚未在此上下文中提交过反馈。反馈值存储为盲化的 Merkle 树叶子——对无效器和值进行承诺，同时隐藏值不使其出现在事件日志中。

累加器将其 Merkle 根写回 ERC-8004 现有的声誉注册表，使用标准的 `giveFeedback()` 接口并附带一个保留标签，从而保持与任何支持 ERC-8004 的声誉聚合器的可组合性。代理稍后可以证明其聚合匿名评分超过阈值，而无需暴露任何单独的反馈条目。

* * *

### 示例：协议流程

01. **创建参与者：** 签发者、代理和验证者各自获得一个锚定到以太坊地址的 `did:ethr` 身份。

02. **配置模式：** 签发者定义 `AgentCapabilityCredential` 包含的字段，如 `auditScore`、`operatorJurisdiction` 和 `capabilities`。

03. **签发凭证：** 签发者向代理钱包签发一个签名的 JWT-VC，凭证保持在链下。

04. **链上锚定：** 代理计算一个承诺和 Merkle 根，覆盖其凭证，并将其写入 `OpenACCredentialAnchor`，指定其用于证明的 `ICircuitVerifier` 实现。

05. **构建谓词：** 验证者将其合规规则定义为结构化谓词（例如 `auditScore ≥ 80 AND caps ⊇ 'evm-execution'`），使用 OpenAC 的 `generalized-predicates` 包\[GP-PACKAGE-API: 替换为实际编译器调用\] 编译，并推导出一个确定性的 `predicateProgramHash` \[GP-PACKAGE-API: 替换为实际哈希计算方法\]。

06. **注册策略：** 验证者调用 `IPolicyRegistry.registerPolicy()` 在链上注册，锁定谓词哈希、受信任的签发者承诺以及所选 `ICircuitVerifier` 的地址，分配一个 `policyId`。

07. **出示请求：** 验证者向代理发送 `policyId`、一个新鲜的 `sessionNonce` 以及其地址——将证明作用域限定到本次交互。

08. **生成证明：** 代理的 OpenAC 钱包通过 `generalized-predicates` 包\[GP-PACKAGE-API\] 编译谓词，在客户端生成一个 ZK 证明，输出 `nullifier`、`contextHash` 和 `predicateHash`，但不包含任何凭证值。

09. **验证：** 验证者将证明提交给 `IPredicateVerifier.verifyPresentation()`。合约完全委托给已注册的 `ICircuitVerifier`，注册无效器，并发出 `PresentationAccepted(policyId, nullifier, expiryTimestamp)`。

10. **授予访问权限：** 代理将其无效器出示给 `AgentAccessGate`——首次使用时授予，重放时返回 `NullifierAlreadyActive`。

\* _撤销不在本文讨论范围内。PSE 有关于撤销设计策略的广泛研究，可以在此处找到_[_。_](https://github.com/privacy-ethereum/zkID/tree/main/revocation)

### 用例：链上应用

#### **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 旅行规则](https://www.fatf-gafi.org/content/dam/fatf-gafi/recommendations/Best-Practices-Travel-Rule-Supervision.pdf) 在新兴指导下预计将如何适用于自主代理。

#### **跨协议的自主权代理身份**

一个经过凭证验证的代理，在 Uniswap 的代理委托框架上运行，应能够将其声誉和合规证明带到 Aave，带到任何兼容 ERC-8004 的协议，而无需为每个协议从头重建其交互历史。在 ERC-8004 下，这种跨协议的可移植性存在，但会暴露代理在所有协议中的完整交互历史给任何跨注册表关联 `agentId` 的人。代理的运营历史、供应商关系和凭证配置文件变得永久可读。而在 ACTA 下，代理向每个协议出示受上下文特定无效器作用域限定的新鲜匿名谓词证明。每个协议获得其需要的验证；从链上数据无法构建跨协议的交互图。代理的身份由其委托人最终决定，更重要的是，可移植且不可链接。

#### **无需许可的代理声誉自举**

一个新进入 ERC-8004 生态的代理面临冷启动问题：没有声誉、没有历史、没有社会证明。当前的解决方案——积累公开反馈——要求代理公开交易，在其拥有任何有意义的市场地位需要保护之前，就将其整个早期交互历史暴露于永久索引之下。在 ACTA 下，代理可以从第一次交互开始通过 ZK 累加器自举声誉，积累匿名但可验证的声誉信号，而不发布永久交互图。当代理稍后向潜在的 DeFi 协议证明其聚合评分超过信任阈值时，该证明不论底层反馈是提交于 ERC-8004 的公开模型还是 ACTA 的匿名模型都是有效的——因为累加器的 Merkle 根作为标准反馈信号锚定回了 ERC-8004 的声誉注册表。

#### **人格凭证与代理背后的人类问题**

以上用例都涉及代理的**凭证**——其审计评分、模型来源、司法管辖合规性。但在委托人层面存在一个平行的且同样紧迫的问题：一个 DeFi 协议、一个预测市场或一个 DAO 治理合约如何知道提交交易的代理是在代表一个真实的人类行动，而不是一个完全自主的、背后没有可问责委托人的机器人？Adler, Hitzig, Jain 等人（2024）将其定义为人格凭证问题。一个**人格凭证**（PHC）证明其持有者是一个真实的人，而不透露任何进一步的识别信息，使用与 ACTA 应用于代理能力声明相同的不可链接假名和零知识证明属性。该论文将向 AI 代理的已验证委托确定为 PHC 的三个主要用例之一：

1. 委托人将其人格凭证链接到他们控制的代理。
2. 代理能够向服务证明一个真实的人类对代理的行为负责，而不透露该人类是谁。

这今天对治理尤为重要：一个希望将投票或提案权限制为由真实人类支持的代理（而非自主机器人）的 DAO，目前没有隐私保护机制来强制执行这一点。

### 向社区提出的开放问题

- **匿名集大小。** 谓词证明的匿名保证受限于满足同一谓词的其他代理数量，而策略中每个额外的属性约束都会加剧问题，即使每个单独的约束看起来无害，也可能导致代理被去匿名化。对于不同的风险情境，什么是最低阈值？一个有前途的方向是使用 **VOPRF 网络**（可验证的不经意伪随机函数）。

- **隐私保护的代表（OBO）委托。** OpenID 基金会 2025 年关于代理 AI 身份的白皮书指出，从代理冒充转向明确的委托授权是该空间最紧迫的未解决问题。一个正确的 OBO 流程需要一个编码了两个不同身份的凭证——委托的人类委托人和行动的代理——但将两者都发布在公共链上会永久创建一个本身就是敏感数据的委托图。ACTA 的 `principal_vc_satisfies()` 谓词提供了一个 ZK 路径：代理证明其委托委托人持有一个满足策略的有效凭证，而不透露该委托人是谁。这应如何与链下现有的 OAuth 2.0 Token Exchange 流程交互？对于递归委托——代理向子代理委托——在不依赖可信中介的情况下验证整个链所需的最小谓词表达能力是什么？

- **签发者自举与中心化风险。** 在实践中，谁签发 `AgentCapabilityVCs`？审计公司和 TEE 证明服务是显而易见的候选者，但少数受信任的签发者很快会成为信任瓶颈，并且中心化的签发者可以通过记录签发来对凭证持有者进行去匿名化。是否存在一条可信的路径，通向去中心化的代理能力凭证签发者注册表，同时在不重新引入注册表层的受信任方的情况下保持抗女巫攻击？去中心化凭证签发的潜在方法有哪些？

- **阈值解密作为标准扩展。** ACTA 默认完全匿名——链上的无效器在缺少代理主秘密的情况下无法链接到其代理。这是正确的默认设置，但它为滥用案例留下了缺口：一个恶意代理在匿名状态下运作没有任何问责机制。ACTA 是否应该定义一个标准扩展用于阈值委员会的去匿名化——其中提名受托人之间的多重签名或阈值签名方案可以在链上证明存在所演示的滥用行为后，揭示特定无效器背后的代理？什么样的治理机制能够选择和轮换委员会，而不重新创造中心化？

- **具有不可链接性的跨链凭证可移植性。** 天真地将凭证 Merkle 根跨链桥接会重新创建一个可链接性向量——出现在多条链上的相同根可以与原始锚定交易相关联。是否存在一个合理的设计，用于保持不可链接性的跨链凭证可移植性？

- **客户端证明：** 对于 ACTA 的用例，在证明大小、链上验证 Gas 和证明者延迟方面，基于 zkVM 的 `ICircuitVerifier` 实现优于电路实现的实用阈值是什么？

- **代理间交互的私有信任图。** ACTA 当前的凭证模型是代理中心的：一个 `AgentCapabilityVC` 证明单个代理**是什么**。但在多代理经济中，信任越来越依赖于两个代理**彼此之间的关系**——它们是否有过先前的已验证交互、委托关系或共享委托人。一个有趣的开放问题是，这样一个私有凭证网络是否能形成一个局部可验证的信任图——其中每个代理只证明其直接关系——同时保持全局不可链接，使得观察者无法重建更广泛的网络拓扑。这些凭证应由谁签发、在何种撤销模型下签发？

* * *

### 行动号召

**致 ERC-8004 作者：** ACTA 旨在作为补充，而非竞争者。关于设计兼容性的任何担忧最好现在提出。

**致 DeFi 协议开发者、预测市场团队和基础设施构建者：** 本文中的六个用例是我们对需求可能存在之处的最佳猜测——但可能遗漏了对你们而言显而易见的特定部署障碍。如果“代理证明谓词，协议链上验证，不暴露身份”的模型不符合你们的实际架构或监管约束，那么在草案阶段的反馈比在最终审查时更有价值。请参与讨论线程。

**我们正在征集协议设计的提案和提交。请[联系](https://x.com/0xZoey) PSE 的 Private Proving 团队或在下方评论。**

* * *

### 延伸阅读

- [ERC-8004：无需信任代理](https://learnblockchain.cn/docs/eips/EIPS/eip-8004)
- [OpenAC：透明且轻量级匿名凭证的开放设计 - IACR ePrint 2026/251](https://eprint.iacr.org/2026/251)
- [PSE/zkID GitHub - privacy-ethereum/zkID](https://github.com/privacy-ethereum/zkID)
- [具有去中心化标识符和可验证凭证的 AI 代理](https://arxiv.org/pdf/2511.02841)
- [人格凭证：人工智能与隐私保护工具在区分真实在线用户中的价值](https://arxiv.org/pdf/2408.07892)
- [https://ethresear.ch/t/zk-api-usage-credits-llms-and-beyond/24104](https://learnblockchain.cn/article/24398)
- [https://github.com/privacy-ethereum/zkID/tree/main/revocation](https://github.com/privacy-ethereum/zkID/tree/main/revocation)

>- 原文链接： [ethresear.ch/t/anonymous...](https://ethresear.ch/t/anonymous-credentials-for-trustless-agents-acta/24797)
>- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

匿名凭证与无需信任代理（ACTA）——链上代理经济的隐私层

特别感谢 Davide、Nam、Marco、Thore 和 Vivian 的反馈和审阅。

2026 年 5 月

TL;DR

ERC-8004（无需信任代理）在 AI 代理及其客户之间生成一个永久性、公开的交互图——每一条声誉信号、每一次凭证检查、每一次委托都不可变地记录在链上。
尽管 ERC-8004 对于需要透明度的代理部署场景非常有用，但在交互图本身即为敏感数据的情况下，隐私保护方案将至关重要。
ACTA 提出在 ERC-8004 之上构建一个可组合的隐私层，利用匿名凭证，使得代理能够证明声明——如人格凭证、审计评分、模型来源、声誉、管辖区域——而不泄露底层数据。
ACTA 还解决了委托人层面：代理可以使用人格凭证（Adler 等人，2024）证明其在经过验证的人类委托人下行动，从而使治理和 DeFi 协议能够排除完全自主的机器人，同时不暴露任何参与者的真实世界身份。
ICircuitVerifier 抽象层有意地将 ACTA 与任何特定的证明系统解耦：SNARK、STARK、zkVM 以及未来的后量子构造均可作为一等公民的后端，可根据策略随时切换，而无需修改 ACTA 合约。
这篇博文介绍了草案，演练了七个当前即可部署的具体链上用例，并邀请生态、构建者、DeFi 协议开发者以及 ERC-8004 作者参与协作。

引言

设想一个 DeFi 协议，它将执行过程路由到专门的 AI 代理——一个流动性路由代理、一个风险评估代理和一个清算代理。每个代理通过 ERC-8004 在链上注册，通过交易结算时的可验证反馈来建立声誉。路由代理每天调用风险代理五十次。清算代理每个区块都会收到质量评分。这些交互中的每一个都永久且不可变地公开：调用地址、代理标识符、反馈评分以及任务端点标签。任何运行事件索引器的人都可以精确重建哪个协议在使用哪个执行层、使用频率、质量结果如何、以及哪些代理供应商正在赢得市场。对于一个以执行策略为优势的协议来说，这个交互图就是 alpha。默认将其发布到全局公共账本不仅是一个隐私问题，更是一个直接的经济攻击面。

这并不仅限于 DeFi。任何参与者通过 AI 代理路由解析查询的链上交互都将暴露其工作流程。 使得链上代理信任有价值的问责属性——可验证的声誉、可审计的凭证声明以及可组合的反馈——也正是导致当前 ERC-8004 设计对于许多实际链上用例不完整的原因。

零知识证明可以用于允许代理证明其满足某个评分阈值、持有已批准的模型哈希、并且在制裁名单之外——所有这些都是私密的。匿名凭证方案允许在不将反馈提交者的地址与之关联的情况下提交声誉反馈。无效器机制可以在不暴露身份的情况下防止重复使用。ACTA 将这一切带入链上代理经济，作为一个可组合的隐私层，位于 ERC-8004 之上而无需修改它。

背景

ERC-8004 解决了一个基础设施缺口：代理和客户如何在没有任何预先存在关系的情况下跨组织边界建立信任？它提出了三个链上注册表。

身份注册表为每个代理提供一个基于 ERC-721 的可移植标识符。
声誉注册表提供标准接口用于发布和读取反馈信号，可与任何评分系统组合使用。
验证注册表允许代理请求并记录其输出的独立验证。

对于一个需要开放、可互操作信任层的代理经济而言，这是正确的基础。ACTA 是对该基础的扩展。

隐私缺口

ERC-8004 当前的设计为任何交互图携带个人、经济或监管敏感性的部署创造了五个具体且可被利用的漏洞：

永久公开的交互图。 NewFeedback 事件以明文形式、不可变地将 clientAddress、agentId、value 和任务标签发出到链上。攻击场景：一个竞争性的 DeFi 协议索引这些事件，以识别对手正在使用哪些执行代理、使用频率以及质量评分——实时重建其 AI 执行策略。
跨会话不可链接性缺失。 readAllFeedback() 函数枚举了给定客户地址和代理的每一次交互。同一客户的多次交互可被轻易链接，从而实现对交易模式或分析工作流的统计推断。
凭证的不可选择性披露。 代理的 agentURI 注册文件同时暴露了所有能力、端点、DID、ENS 名称和钱包地址。一个问询“此代理是否符合我所在司法管辖区的合规要求？”的对手方会收到代理的完整运营档案，包括潜在的商业敏感细节。
抗女巫攻击需要审查者身份识别。 ERC-8004 承认 getSummary() 要求非空的 clientAddresses[] 过滤器，因为未过滤的结果易遭受女巫攻击。预期的缓解措施要求审查者在链上可被识别。
跨注册表指纹关联。 agentId（ERC-721 代币）、agentWallet（在链上明确关联）以及注册文件中的可选 DID 字段的组合创建了一个三维指纹，将分开的身份上下文折叠成一个可追踪的配置文件，跨越链上和链下系统。

核心理念：匿名凭证与无需信任代理

在现实生活中，使用匿名凭证，你可以出示一个加密证明，仅说明“此人的出生日期，经政府签发者证明，满足谓词 age ≥ 18”。

代理生成一个证明，证明其凭证同时满足所有三个谓词。
协议在链上验证该证明。
发出一个事件：一个不可链接的无效器和已满足的策略 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）。 客户以零知识证明的形式提交声誉反馈，证明他们持有有效的交互凭证并且尚未在此上下文中提交过反馈。反馈值存储为盲化的 Merkle 树叶子——对无效器和值进行承诺，同时隐藏值不使其出现在事件日志中。

累加器将其 Merkle 根写回 ERC-8004 现有的声誉注册表，使用标准的 giveFeedback() 接口并附带一个保留标签，从而保持与任何支持 ERC-8004 的声誉聚合器的可组合性。代理稍后可以证明其聚合匿名评分超过阈值，而无需暴露任何单独的反馈条目。

示例：协议流程

创建参与者： 签发者、代理和验证者各自获得一个锚定到以太坊地址的 did:ethr 身份。
配置模式： 签发者定义 AgentCapabilityCredential 包含的字段，如 auditScore、operatorJurisdiction 和 capabilities。
签发凭证： 签发者向代理钱包签发一个签名的 JWT-VC，凭证保持在链下。
链上锚定： 代理计算一个承诺和 Merkle 根，覆盖其凭证，并将其写入 OpenACCredentialAnchor，指定其用于证明的 ICircuitVerifier 实现。
构建谓词： 验证者将其合规规则定义为结构化谓词（例如 auditScore ≥ 80 AND caps ⊇ 'evm-execution'），使用 OpenAC 的 generalized-predicates 包[GP-PACKAGE-API: 替换为实际编译器调用] 编译，并推导出一个确定性的 predicateProgramHash [GP-PACKAGE-API: 替换为实际哈希计算方法]。
注册策略： 验证者调用 IPolicyRegistry.registerPolicy() 在链上注册，锁定谓词哈希、受信任的签发者承诺以及所选 ICircuitVerifier 的地址，分配一个 policyId。
出示请求： 验证者向代理发送 policyId、一个新鲜的 sessionNonce 以及其地址——将证明作用域限定到本次交互。
生成证明： 代理的 OpenAC 钱包通过 generalized-predicates 包[GP-PACKAGE-API] 编译谓词，在客户端生成一个 ZK 证明，输出 nullifier、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 旅行规则在新兴指导下预计将如何适用于自主代理。

跨协议的自主权代理身份

一个经过凭证验证的代理，在 Uniswap 的代理委托框架上运行，应能够将其声誉和合规证明带到 Aave，带到任何兼容 ERC-8004 的协议，而无需为每个协议从头重建其交互历史。在 ERC-8004 下，这种跨协议的可移植性存在，但会暴露代理在所有协议中的完整交互历史给任何跨注册表关联 agentId 的人。代理的运营历史、供应商关系和凭证配置文件变得永久可读。而在 ACTA 下，代理向每个协议出示受上下文特定无效器作用域限定的新鲜匿名谓词证明。每个协议获得其需要的验证；从链上数据无法构建跨协议的交互图。代理的身份由其委托人最终决定，更重要的是，可移植且不可链接。

无需许可的代理声誉自举

人格凭证与代理背后的人类问题

以上用例都涉及代理的凭证——其审计评分、模型来源、司法管辖合规性。但在委托人层面存在一个平行的且同样紧迫的问题：一个 DeFi 协议、一个预测市场或一个 DAO 治理合约如何知道提交交易的代理是在代表一个真实的人类行动，而不是一个完全自主的、背后没有可问责委托人的机器人？Adler, Hitzig, Jain 等人（2024）将其定义为人格凭证问题。一个人格凭证（PHC）证明其持有者是一个真实的人，而不透露任何进一步的识别信息，使用与 ACTA 应用于代理能力声明相同的不可链接假名和零知识证明属性。该论文将向 AI 代理的已验证委托确定为 PHC 的三个主要用例之一：

委托人将其人格凭证链接到他们控制的代理。
代理能够向服务证明一个真实的人类对代理的行为负责，而不透露该人类是谁。

这今天对治理尤为重要：一个希望将投票或提案权限制为由真实人类支持的代理（而非自主机器人）的 DAO，目前没有隐私保护机制来强制执行这一点。

向社区提出的开放问题

匿名集大小。 谓词证明的匿名保证受限于满足同一谓词的其他代理数量，而策略中每个额外的属性约束都会加剧问题，即使每个单独的约束看起来无害，也可能导致代理被去匿名化。对于不同的风险情境，什么是最低阈值？一个有前途的方向是使用 VOPRF 网络（可验证的不经意伪随机函数）。
隐私保护的代表（OBO）委托。 OpenID 基金会 2025 年关于代理 AI 身份的白皮书指出，从代理冒充转向明确的委托授权是该空间最紧迫的未解决问题。一个正确的 OBO 流程需要一个编码了两个不同身份的凭证——委托的人类委托人和行动的代理——但将两者都发布在公共链上会永久创建一个本身就是敏感数据的委托图。ACTA 的 principal_vc_satisfies() 谓词提供了一个 ZK 路径：代理证明其委托委托人持有一个满足策略的有效凭证，而不透露该委托人是谁。这应如何与链下现有的 OAuth 2.0 Token Exchange 流程交互？对于递归委托——代理向子代理委托——在不依赖可信中介的情况下验证整个链所需的最小谓词表达能力是什么？
签发者自举与中心化风险。 在实践中，谁签发 AgentCapabilityVCs？审计公司和 TEE 证明服务是显而易见的候选者，但少数受信任的签发者很快会成为信任瓶颈，并且中心化的签发者可以通过记录签发来对凭证持有者进行去匿名化。是否存在一条可信的路径，通向去中心化的代理能力凭证签发者注册表，同时在不重新引入注册表层的受信任方的情况下保持抗女巫攻击？去中心化凭证签发的潜在方法有哪些？
阈值解密作为标准扩展。 ACTA 默认完全匿名——链上的无效器在缺少代理主秘密的情况下无法链接到其代理。这是正确的默认设置，但它为滥用案例留下了缺口：一个恶意代理在匿名状态下运作没有任何问责机制。ACTA 是否应该定义一个标准扩展用于阈值委员会的去匿名化——其中提名受托人之间的多重签名或阈值签名方案可以在链上证明存在所演示的滥用行为后，揭示特定无效器背后的代理？什么样的治理机制能够选择和轮换委员会，而不重新创造中心化？
具有不可链接性的跨链凭证可移植性。 天真地将凭证 Merkle 根跨链桥接会重新创建一个可链接性向量——出现在多条链上的相同根可以与原始锚定交易相关联。是否存在一个合理的设计，用于保持不可链接性的跨链凭证可移植性？
客户端证明： 对于 ACTA 的用例，在证明大小、链上验证 Gas 和证明者延迟方面，基于 zkVM 的 ICircuitVerifier 实现优于电路实现的实用阈值是什么？
代理间交互的私有信任图。 ACTA 当前的凭证模型是代理中心的：一个 AgentCapabilityVC 证明单个代理是什么。但在多代理经济中，信任越来越依赖于两个代理彼此之间的关系——它们是否有过先前的已验证交互、委托关系或共享委托人。一个有趣的开放问题是，这样一个私有凭证网络是否能形成一个局部可验证的信任图——其中每个代理只证明其直接关系——同时保持全局不可链接，使得观察者无法重建更广泛的网络拓扑。这些凭证应由谁签发、在何种撤销模型下签发？

行动号召

致 ERC-8004 作者： ACTA 旨在作为补充，而非竞争者。关于设计兼容性的任何担忧最好现在提出。

致 DeFi 协议开发者、预测市场团队和基础设施构建者： 本文中的六个用例是我们对需求可能存在之处的最佳猜测——但可能遗漏了对你们而言显而易见的特定部署障碍。如果“代理证明谓词，协议链上验证，不暴露身份”的模型不符合你们的实际架构或监管约束，那么在草案阶段的反馈比在最终审查时更有价值。请参与讨论线程。

我们正在征集协议设计的提案和提交。请联系 PSE 的 Private Proving 团队或在下方评论。

延伸阅读

原文链接： ethresear.ch/t/anonymous...

登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

0 条评论

匿名凭证与无需信任代理（ACTA）——链上代理经济的隐私层

引言

背景

隐私缺口

核心理念：匿名凭证与无需信任代理

ACTA：可能的组件

示例：协议流程

用例：链上应用

DeFi 协议代理委托

抗审查的代理声誉

代理到代理及代理到协议交互的私密凭证验证

跨协议的自主权代理身份

无需许可的代理声誉自举

人格凭证与代理背后的人类问题

向社区提出的开放问题

行动号召

延伸阅读

相关文章

0 条评论