# 实现互操作，不抹去证据。 **协议设计笔记 · 2026 年 9 月 7 日 · 兼容目标不等于已经实现的集成。** 一个工作流可能产生发票、签名服务报价、收据、交易观察和策略评估。给它们套上相同封装，可以让软件更容易编写。但如果封装悄悄把每一项都当作等价的成功证明，证据反而会更难理解。 Proof21 的互操作目标应恰恰相反：提供一致接口，同时保留原始产物的含义、来源与限制。适合时复用现有格式，只增加工作流确实需要的绑定和评估结果。给收据起一个新名字，不是替代一个运作良好生态的理由。 ## 先明确主张，再选择封装 x402 的签名报价与收据扩展涉及商业交互产物。PEAC 描述可验证的交互记录，并明确签发方报告证据的边界。它们可以是有用输入或兼容目标，但不能把任何一个标签扩大为：所有请求的下游操作均已正确执行的独立证明。[1][2] 拟议适配器应说明它处理的确切主张。例如：这个签发者签署了这些商业条款；这项服务报告了这次交互；这个来源返回了这份交易观察；这个评估器按这个配置比较了这些字段。使用方可以组合这些陈述，而不假装它们具有相同信任假设。 从一个明确版本和一种受支持产物结构开始。“兼容一切”的主张，不如一个配有正面、负面和不支持案例测试向量的有限配置有用。应说明适配器是在解析产物、验证其机制、评估主张，还是仅保留它供后续检查。 ## 规范化之前保留原件 假设适配器读取一份签名 JSON 产物，并生成方便的规范化视图。这个视图可以帮助开发者，但适配器不能丢弃原始的、经过认证的表示。如果它重写类型、删除字段、改变 Unicode 处理或序列化方式，所得字节可能已不是签发者签署的消息。 保留原始产物，或经授权且绑定完整性的获取引用。记录转换版本，以及每个规范化字段来自哪些输入。如果源格式区分字段缺失与明确为空，就应保留区别。影响来源验证或主张语义的不支持字段，不能悄悄消失。 规范化可以解决一个明确的序列化问题，而不是所有转换问题。RFC 8785 是某种 JSON 规范化方案的有用参考。配置必须说明何时适用该方案，以及原始格式何时采用不同规则。不要把任意签名对象规范化后，就假定签名理应对新字节有效。[3] ## 跨系统保持标识精确 网络和资产名称常导致意外的等同处理。两个网络可能显示相同资产符号。测试网络和生产网络可能具有看起来相近的地址。本地账号标识离开分配它的系统后，可能毫无意义。规范化报告必须保留命名空间和绑定规则。 CAIP-2 和 CAIP-19 提供链与资产标识的原始规范。它们帮助命名讨论对象，却不能证明外部链已达成共识，或某次转移确实发生。使用方仍需相关执行证据和接受策略。[4][5] 在合成互操作测试中，可以保持显示符号不变，同时改变确切资产标识。再保持收款方可见文字相似，同时更改网络。适配器应暴露这些变化，而不是合并记录。有帮助的界面可以解释不匹配，但不能为让工作流通过而重写底层标识。 ## 分开传输成功与语义成功 HTTP 成功响应意味着请求按服务器接口得到处理，并不自动代表业务主张评估为正面。真实有效的产物可以包含负面发现。即使 JSON 能成功解析，不支持的配置仍应保持不支持。这些区分应同时体现在模式与使用方展示中。 拟议 P21 使用方应分别报告产物完整性、每项受支持评估的结果和本地接受。如果合作格式只包含签发者断言，应保留该证据类别。不能仅因它进入 P21 报告，就改称独立验证的状态。 同样，保留外部签名并不证明使用方今天接受该签发者。密钥发现、轮换、撤销及组织授权各有策略。对提供密钥进行离线测试，只能说明其声明的范围。跨格式适配器不能暗示曾查询身份或信任注册表，而实际并未查询。 ## 构建可以诚实失败的兼容契约 第一项集成应记录输入版本、受支持主张、必需字段、认证机制、输出配置、保留的原件与未解决条件。发布覆盖完整产物、篡改、错误操作标识、未知版本、真实有效的负面结果和证据缺失的样例。让生成方与使用方独立运行。 往返测试可以验证适配器保留了承诺保留的内容。差分测试可以揭示与上游实现的分歧。任何一种测试本身都不能建立合作关系或生产就绪状态。记录上游修订与测试日期，避免后来的变化悄悄使旧兼容声明失效。 有用的试点结果是：独立使用方无需让生成方重新讲述过程，就能解释结果并找到原始证据。当前 Proof21 文档明确列出互操作目标与边界，不声称已发布 PEAC、x402、MCP 或 A2A 适配器；离线演示也不是这些协议的一致性测试套件。 ## 常见问题 ### Proof21 应替代所有现有收据格式吗？ 不应。在格式适合所需主张时，应默认复用。拟议适配器应保留原始证据，并增加明确的工作流绑定或评估，而不是仅为品牌再造一层封装。 ### 把 RPC 响应放进签名报告，会让它成为独立验证的状态吗？ 不会。签名可以认证报告签发者签署的内容。除非确实执行并记录了额外验证，否则 RPC 响应仍是具有自身来源与限制的观察。 ### 能解析合作方格式，就足以宣称完全兼容吗？ 不够。兼容声明必须指明版本与范围、覆盖必需语义，并有测试支持。解析、签名验证、主张评估和本地接受是不同能力。 ## 跨链访问与生态支付 原生 NAT 和 Base USDC 仍为初次商业发布的必备方式。NAT 在以太坊、Solana 和 BNB Smart Chain 也有可识别的表示。接受前分别批准准确合约或 mint 及桥接映射；跨链可用性不会消除数据源自身的信任假设。 Binance B402 集成范围包括 BNB Smart Chain 上的 USDT、USDC、USD1 和 U，使用每种资产支持的方法。PayAI 和 Coinbase 通道使用经测试的网络／资产组合；Virtuals ACP 保留 USDC 任务支付生命周期。MCP 与 A2A 不指定付款币种。付款选择和可选资金兑换与比特币／DMT 证据验证相互独立。这些是规范中的集成目标，不是已启用的支付服务。 [Binance assets and methods](https://developers.binance.com/en/docs/products/onchainpay-x402/basics/9.supported-payment-methods) · [Binance integration](https://developers.binance.com/en/docs/products/onchainpay-x402/introduction) · [Coinbase facilitator](https://docs.cdp.coinbase.com/x402/seller/facilitator) · [PayAI assets](https://docs.payai.network/x402/reference) · [Virtuals ACP](https://os.virtuals.io/acp/concepts) · [NAT Ethereum listing](https://www.bitmart.com/en-US/support/articles/7923014477723/360001026214/49446319153179) · [NAT Solana record](https://solscan.io/token/FbKRaqBzupLry3V7QujpNghwrHgxutB4MY11M8aeyVa1) · [NAT BNB Chain contract](https://bscscan.com/token/0x600e3b55d5368c32a94f9372563318adb6a3f882) ## 更新 · 互操作性也需要授权边界 可移植证据若配合明确的执行权限边界会更有价值。P21 现在区分证据验证与可选 action-bound 执行授权；同一授权原则可以适配 TAP 阈值签名、smart account、MPC/HSM 或 API capability proxy，而不声称这些系统共享同一共识。 接收方决策也是可移植签名材料。拒绝不会覆盖独立 settlement 或 evaluation；冲突签名可以形成 equivocation 证据，而不是被压缩成可随意修改的信誉分数。 ## 原始参考资料与延伸阅读 - [1：x402 — 签名报价与收据](https://docs.x402.org/extensions/offer-receipt) - [2：PEAC — 交互记录与证据边界](https://www.peacprotocol.org/) - [3：RFC 8785 — JSON 规范化方案](https://www.rfc-editor.org/rfc/rfc8785.html) - [4：CAIP-2 — 区块链标识规范](https://standards.chainagnostic.org/CAIPs/caip-2) - [5：CAIP-19 — 资产类型与资产标识规范](https://standards.chainagnostic.org/CAIPs/caip-19) - [Proof21 支付集成范围](https://proof21.xyz/zh-hans/docs/integrations/payments/)