PrivateX402：用于多代理AI系统的隐私保护支付通道 - 应用

作者：Conor McMenamin 和 Artem Grigor，均来自 Nethermind。

摘要

随着AI代理成为自主的经济参与者——调用API、购买计算资源并代表用户进行交易——现有的支付基础设施暴露出一个关键的隐私漏洞。当前的协议会泄露用户向哪些代理付款以及支付金额，从而泄露用户的意图和行为模式。中心化的协调者可以隐藏这些信息，但代价是引入了一个单点信任。PrivateX402是一种支付通道协议，它允许用户在单个通道内向多个代理分配预算，同时向链上观察者隐藏单个分配详情——且不依赖于受信任的中间人。$N$个用户-代理通道（对于任意$N$）的设置和结算，每个用户只需要1笔设置交易和1笔结算交易——总共2笔交易覆盖$N$个通道的生命周期。代理的索赔请求本身在多个通道中进行批量处理，混淆了每个通道的索赔，并相对于每个通道单独收款节省了大量的gas费。PrivateX402中的证明集中在通道生命周期的边界处，而不是每次支付都需要证明。本文描述了该协议、一个可工作的概念验证实现，以及迈向生产部署的路径。

1. 问题：多代理系统中的支付隐私

1.1 代理支付的兴起

具有工具调用能力的大型语言模型正在迅速发展成为代表用户进行交易的自主代理。单个用户会话可能涉及一个LLM协调器，将任务委托给代码执行代理、网络搜索代理和数据分析代理——每个代理都需要为其服务获得报酬。x402是朝这个方向迈出的关键一步，它通过HTTP 402状态码实现机器到机器的支付。

1.2 隐私漏洞

现有的支付通道设计——状态通道、闪电网络以及x402本身——都假定直接的双边支付关系。当用户与多个代理打开单独的支付通道，或进行直接的链上支付时，交易图会暴露：

• 用户与哪些代理交互——暴露了用户的工具选择和工作流程
• 每个代理获得多少报酬——揭示了每项服务的相对重要性
• 支付时间和频率——使得行为指纹识别成为可能

在多代理环境中，这些信息尤其敏感。如果用户将80%的预算分配给医疗研究代理，20%分配给药店查询代理，链上观察者可以推断出健康状况。如果一个竞争情报代理在商业决策前不久收到大额付款，竞争对手可以推断出其策略。

1.3 缺失之处

中心化的支付协调者——一个托管中心、一个托管的API网关——可以轻易地解决隐私问题：它能看到所有支付，但区块链看不到。然而，中心化引入了一个单点信任，它可能审查交易、监控用户行为或挪用资金。在自主AI代理的背景下，支付流可能编码了敏感的用户意图，将这种信任委托给单个运营者是一个糟糕的权衡。

据我们所知，目前没有已部署的协议能同时提供以下功能：

1. 在单个通道内进行多代理预算分配（一次存款覆盖多个代理）
2. 按代理的隐私，其中单个分配对链上观察者隐藏
3. 可验证的结算，确保代理收到正确的付款而无需信任用户
4. 争议解决，用于处理报酬不足或被排除的代理
5. 无受信任的中间人——没有单个实体可以审查、监控或挪用通道资金

PrivateX402解决了这一空白。该协议用可验证的计算层（目前是TEE，设计为可被ZK电路替换）取代了中心化的协调者，该计算层在任何一方都无法拥有通道状态特权访问权的情况下，强制执行结算的正确性。

1.4 相关工作与定位

最近的工作已开始明确针对AI和API使用的隐私保护、高频支付。值得注意的是，以太坊研究文章ZK API Usage Credits: LLMs and Beyond（Davide & Vitalik）提出了一种“一次存款”模型，用户可以使用速率限制空值器（RLN）加上ZK偿付能力证明，以实现许多API调用的不可链接性，确保用户在其资助的信用额度内进行操作，并为可变成本调用提供提供方发行的退款凭证以及用于策略执行的双重质押机制。

PrivateX402是互补的，但它在设计空间中瞄准了一个不同的点：

• 闪电网络 / 状态通道 / x402：这些是强大的支付轨道，但当用户通过按代理结算或按代理通道支付许多独立代理时，它们本身并不能向链上观察者隐藏用户到代理的支付图。PrivateX402特别隐藏了链上每个代理的明细；每个获得报酬的代理仍然会知道自己的收据和分配。
• 托管网关 / API聚合器：一个中心可以向链隐藏每个代理的明细，但它会成为一个受信任的中间人，能够查看（并可能控制）完整的支付图。
• 单提供者私有计量（RLN）：ZK使用信用专注于针对单个提供者（在其术语中是服务器）的不可链接请求，需要每次请求的ZK证明。使用RLN，与$N$个独立提供者交互的用户通常需要$N$次存款/承诺。PrivateX402通过一次存款覆盖$N$个代理，并使支付过程无需证明（仅限每次支付签名），将证明集中在设置/结算/索赔阶段。
• 多方结算和争议：PrivateX402包含明确的结算/争议/索赔生命周期，因此如果用户在结算时撒谎，每个代理都可以强制执行正确的付款；这与RLN惩罚或服务条款质押等策略问责机制正交。

2. 协议设计

2.1 概述

该协议有七个阶段：设置、注册、支付、结算、争议（可选）、最终确定和索赔。

注意：所有证明均由TEE或ZK证明者生成。

截图 2026-02-18 142532855×731 33.1 KB

2.2 通道设置

用户选择一组代理，并为每个代理分配一个最大预算（MaxSpend）。这些分配被编码为Merkle树的叶子：

$$ Leaf = H(SessionKey, AgentAddress, MaxSpend) $$

每个SessionKey是一个256位的随机秘密，仅在用户和相应的代理之间共享。用户提交Merkle根和一份证明（$P_{alloc}$），证明所有MaxSpend值的总和等于存入的$TotalMaxSpend$。合约只存储根和总资金——单个分配保持私密。

设置时需要$TotalMaxSpend$的50%作为抵押金。如果用户在结算期间作弊，此抵押金将被销毁；如果诚实最终确定，则会退还。

2.3 链下支付

支付完全通过EIP-191签名的累积收据在链下进行。首次接触时，用户发送一个Merkle包含证明，表明代理的叶子存在于已提交的树中。代理根据链上Merkle根验证证明，确认其自己的地址在叶子中，并提取其$MaxSpend$预算。

后续支付是轻量级的：用户签署一个新的累积金额（例如，“我已经与你花费了3 ETH”），代理验证签名并确认新总额未超过$MaxSpend$。无需重新发送Merkle证明——预算是不可变的。

2.4 通过拆分加密进行结算

当用户想要关闭通道并收回未使用的资金时，他们提交一个总计的未使用余额（Remainder），该余额应等于通道中每个代理的未使用分配总和。用户还会为每个代理槽发送加密的结算数据：

$$ EncryptedAmount_i = Amount_i \oplus H(SessionKey_i, 0) $$ $$ EncryptedInfo_i = Address_i \oplus H(SessionKey_i, 1) $$

域分隔符（0用于金额，1用于地址）确保金额和地址独立加密。一份证明（$P_{settle}$）验证使用正确的会话密钥解密所有条目后，产生的金额总和为$TotalMaxSpend - ReturnAmount$。

关键的安全属性：如果用户提供一个伪造的会话密钥以低估代理的付款，解密后的金额将是一个随机的256位值。由于证明强制要求$Amount < 2^{64}$，假密钥失败的概率极高（$\sim 1 - 2^{-192}$）。

2.5 争议机制

结算启动后，将开启一个争议窗口（1天）。任何认为自己被少付或被排除的代理都可以提交一份争议，其中包含其支付收据、Merkle证明和会话密钥。合约将：

1. 在链上验证Merkle证明和EIP-191签名
2. 使用公开的会话密钥解密代理的条目
3. 将解密后的金额与签名的收据进行比较

如果争议有效，通道将被标记为Disputed，用户的抵押品将被销毁（发送到address(0)），争议代理将收到其声称的金额。其他代理随后可以调用disputeClaimMaxSpend，从剩余的通道资金中收回其$MaxSpend$分配。

隐私注意事项：提出争议会暴露代理与用户的关联，因为会话密钥被公开了。这是一个有意的权衡——隐私仅在用户作弊时才被牺牲。

2.6 基于时期的批量索赔

诚实结算在争议窗口期结束后最终确定。在最终确定时，通道的数据被累积到滚动的时间期哈希链中：

$$ entryHash = H(channelId, merkleRoot, encryptedValuesHash) $$ $$ epochHash = H(epochHash_{prev}, entryHash) $$

代理通过提交单个聚合证明（$P_{claim}$），批量索赔在同一时期内结算的所有通道中的资金。该证明通过重建时期哈希、解密每个通道的条目以及验证Merkle包含，来证明对多个通道中资金的所有权——所有这些都无需透露代理参与了哪些具体通道（超出总索赔金额）。

2.7 隐私属性

2.8 成本效益

除了隐私之外，该协议通过在代理和通道之间分摊链上和证明成本，实现了与简单替代方案相比显著的成本降低。

$O(1)$的设置gas。单笔链上交易为覆盖$N$个代理的通道提供资金。替代方案——开启$N$个双边支付通道——需要$N$次单独的存款，每次都会产生基础交易gas费加上合约存储写入。

零成本链下支付。 每笔支付都是一个EIP-191签名，由用户在本地计算并由代理在本地验证。没有链上交易，没有ZK证明，除了用户-代理链接之外没有网络通信。这与每次支付都使用ZK的方法形成鲜明对比，后者每次API调用都需要生成证明（数秒的延迟，大量的计算）。

结算：$O(1)$交易，$O(N)$数据可用性。 单笔链上交易为所有$N$个代理结算通道（而不是$N$笔关闭/提款交易），但发布每个代理槽的EncryptedAmount[i] / EncryptedInfo[i]在calldata中是$O(N)$，除非将其移动到带有承诺的blob/DA层。

$O(1)$批量索赔。在一个时期内服务$M$个通道的代理提交一个聚合证明，并接收单笔转账，而不是$M$笔单独的提款交易。Gas节省量与通道数量呈线性关系。

证明集中在生命周期边界。 该协议仅在三个点需要证明：设置（$P{alloc}$）、结算（$P{settle}$）和索赔（$P_{claim}$）。对于一个有100个代理且每个代理进行1,000次支付的通道，这意味着总共只有3个证明——而不是100,000个。绝大多数协议活动（链下支付）是无需证明的。

3. 概念验证总结

一个可工作的概念验证存在于Solidity和Rust中：一个智能合约管理通道生命周期；一个用户库创建通道并发布累积收据；一个代理服务器验证注册证明和收据；一个可插拔的证明后端目前使用一个模拟TEE（ZK电路已起草但尚未集成）。有关完整的协议描述，请参阅协议规范。有关实现细节和已知问题，请参阅后续步骤和已知问题。

4. 关键设计决策

累积收据而非增量收据。 每张支付收据都包含累计总支出，而不是增量。代理只保留金额最高的最新收据。这简化了收据管理和争议逻辑——一张收据即可证明总义务。

无通道调整。 修改活动通道的Merkle树会泄露旧资金和新资金之间的差异，可能暴露新添加代理的预算。通道一旦开启即不可变；用户需要为更改的分配创建新通道。

抵押品作为威慑。 50%的抵押品要求为欺诈性结算带来了直接的经济成本。结合争议机制，理性的用户没有作弊的动机：如果任何一个代理提出争议，他们肯定会损失50%的存款，而最多只能获得少付的金额。

可插拔验证。 所有密码学验证都通过部署时的接口注入。这使得同一合约今天可以与TEE签名配合使用，明天可以与ZK证明配合使用，而无需重新部署或迁移。

时期批处理以实现索赔隐私。 如果没有时期，每个代理的索赔都会将一个代理链接到一个通道。时期批处理将多个通道聚合成一个索赔，减少了关于每个通道参与情况泄露的信息。

5. 现状与后续步骤

该协议已作为可工作的PoC（概念验证）实现，但仍有关键的生产工作尚待完成。去中心化至上主义者可能更喜欢将ZK集成而非TEE；此仓库同时保留了这两种路径（当前是TEE，后期是ZK）。尽管如此，TEE可以降低成本并提供更大的灵活性。一些有趣的附加功能可能包括为通道充值、将通道扩展到更多代理，或者在创建时不安置通道中的代理。最初看来，这些功能要么会增加复杂性，要么会增加gas成本——创建新通道可能最有意义。将PrivateX402与混币器集成，使用户能够购买隐私币，进行混币，然后使用这些隐私币创建我们所描述的多代理通道，这也是一个可行的扩展。

6. 结论

PrivateX402证明了多代理AI系统的隐私保护支付通道是实用、经济高效的——并且可以在没有受信任中间人的情况下构建。该协议通过设定的承诺和加密隐藏了按代理的预算分配，同时通过争议机制和可验证证明的结合，保留了链上结算保证。通过用可验证的计算层（今天为TEE，明天为ZK）取代中心化协调者，该协议消除了原本可以访问完整支付图的单点信任。

该设计还实现了显著的成本效益：一次链上存款即可覆盖任意数量的代理，链下支付是无证明的签名交换，代理在一个时期内通过一笔交易批量索赔多个通道的资金。链上成本与用户数量成比例，而非代理或支付数量。

该概念验证在Solidity智能合约和Rust工作区中实现了完整的协议生命周期，其中TEE信任后端在模拟模式下运行，ZK电路已编写但尚待集成。该架构设计旨在实现TEE和ZK之间的后端互换性。

• 原文链接： ethresear.ch/t/privatex4...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～