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