# 一份文件，三种不同决定。

**协议设计笔记 · 2026 年 9 月 7 日**

在网站上写“已验证”很容易，精确使用这个词却困难。验证的是签名、计算、交易包含关系、策略条件，还是采取下一步行动的权限？

Proof21 拟议接收方接口有意区分这些问题。用一个绿灯隐藏差别，不适合作为自主金融工作流的基础。

## 1. 验证文件

第一层询问：在认可密钥假设下，文件是否完整并正确绑定？它检查结构、签名、签发方、操作引用及受支持编码规则。

这可以确立签发方签了什么，不能独立证明所有签名声明都为真。PEAC 等现有记录协议明确区分签发方报告证据的边界。[1]

接收系统还需要密钥发现、轮换及吊销策略。对所提供密钥进行离线检查，不是该密钥当前仍获认可的证据。

## 2. 评估具名声明

下一层对明确证据集合应用特定策略。例如比较付款接收方及金额是否符合指令，或根据引用字段和规则复现 DMT 推导。

输出有明确范围：通过、失败或无法判断，并附原因。不能把一个谓词通过，扩展成对智能体安全、投资表现或整个过程轨迹完整性的笼统保证。

证据类型很重要。签名声明、RPC 观察、包含证明及独立验证状态不可互换。共同报告封装应保留差别。

## 3. 应用本地接纳策略

接收方再决定结果是否足够支持下一步。低价值监控任务与高价值金融承诺，对来源、最终性、签发方、新鲜度及人工批准可能有不同要求。

所以 P21 不替代钱包或平台所有防护措施。权力仍归接收方。报告是在既有权限下考虑的证据，不是新的权限授予。

## 对外简单，对内明确

开发体验仍可简洁。一个 SDK 可携带请求、保留原始证据、产生结果并暴露接收方验证器。简单应来自一致接口，而不是消除不确定性。

首个实现里程碑是两个独立进程完成闭环：一个生成报告，另一个复现受支持检查并拒绝篡改证据。当前文档描述的是该目标；已发布 SDK 仍不可用。

## 真实有效的失败报告也是有用证据

假设生成方签署一份报告，说明某次合成付款使用了错误的收款方。独立使用方确认报告未被修改，且签名可在提供的、被接受的密钥下通过验证。此时完整性结果可以是正面的，而付款评估为 `FAIL`。策略随后可以把该报告接受为有用证据，同时拒绝授权与付款有关的下一步操作。这是三个一致的结果，并不矛盾。

反过来，一份完整无损的报告也可能包含生成方没有证据支持的成功主张。评估器不能从签名那里借来确定性。W3C 可验证凭证数据模型是有用的原始参考，帮助区分对凭证机制的验证与依赖方的信任决策；Proof21 并不声称其草案产物格式自动就是一种 W3C 凭证。[2]

这种区分也能改进错误消息。“不支持的证据配置”提示使用方获取兼容的实现或其他证据。“收款方不匹配”描述一个受支持但失败的比较。“本地策略不接受该签发者”涉及权限与信任。如果把三者都压缩为“无效”，可能让补救更困难，并鼓励不安全的重试。

## 签名之前，先确定字节表示

两个 JSON 对象在人看来可以等价，但编码仍然不同。签名需要精确定义的消息，而不是屏幕截图或读者的理解。RFC 8785 定义了 JSON 规范化方案，包括数据限制与确定性的序列化规则。它是相关的设计参考，却不能替代为具体实现选择并测试确切的序列化配置。[3]

对于金融配置，大额货币数量应保留为表示原子单位整数的十进制字符串，而不是随意通过浮点运算转换。被接受的模式必须定义类型并拒绝歧义。它还应把网络、确切资产、操作标识、策略版本、指令摘要和结果摘要绑定到被认证的上下文之内，而不是把重要标签留在外面。

解析器应依据其公开规则拒绝不支持的版本以及重复或冲突的字段。进行昂贵计算之前，应限制输入大小。应使用成熟的密码学库及其测试向量，而不是让大语言模型发明签名验证方法。RFC 8032 提供 EdDSA 的参考与测试向量；选择 Ed25519 本身并不能证明密钥所有权、撤销状态或行动权限。[4]

## 接受决定属于一个明确命名的使用方策略

设想两个使用方收到同一份报告。监控面板允许在回顾性分析中展示一份已明确标记的过时观察。资金控制器则要求当前证据、特定签发者、足够的确认条件以及人工批准。面板展示报告、控制器拒绝与交易有关的行动，是合理的不同决定。

报告不能代替控制器悄悄选择更弱的策略。应记录评估了哪个策略、是否满足其前提，以及实际授权了哪一个后续动作。后来的策略更新不能改写先前决策的历史含义。应保留原版本以供重放，并在需要重新评估时记录一项新决定。

试点中，让生成方与使用方作为独立进程运行，并使用独立配置。测试真实有效的负面报告、被修改的证据、错误的操作标识、未知版本、缺失的观察，以及不被接受的签发者。教育用途的离线演示已经提供有限完整性与策略检查的合成示例，但这不代表动态密钥发现、所有证据适配器或生产级接受服务已经存在。

## 常见问题

### 签名验证能通过，而付款检查失败吗？

能。正确签名的报告可以如实描述一个失败的付款条件。完整性涉及经过认证的产物；评估涉及指定的主张与证据。界面应明确显示两种结果。

### 接受一份报告就授权智能体花钱了吗？

并不是。使用方可以接受一份报告用于存储或审查，而不授予转移资金的权限。行动权限属于应用明确的授权策略与控制措施。

### 所有证据类型都能归结为一个信任分数吗？

这样做会掩盖重要差异。签名断言、RPC 观察和独立验证的状态支持不同的主张。通用封装应保留原始证据类型、来源、限制与尚未解决的问题。

## 补充原始参考资料

- [2：W3C 可验证凭证数据模型 v2.0](https://www.w3.org/TR/vc-data-model-2.0/)
- [3：RFC 8785 — JSON 规范化方案](https://www.rfc-editor.org/rfc/rfc8785.html)
- [4：RFC 8032 — Edwards 曲线数字签名算法](https://www.rfc-editor.org/rfc/rfc8032.html)

## 继续阅读

- [接收方验证模型](https://proof21.xyz/zh-hans/docs/protocol/verification/)
- [安全与信任边界](https://proof21.xyz/zh-hans/docs/protocol/security/)
- [1：PEAC 范围与证据边界](https://www.peacprotocol.org/)