Proof21
简中
菜单

协议设计 · 2026 年 9 月 7 日 · 8 分钟阅读

一份文件,三种不同决定。

即使界面简单,也要区分完整性、评估与接纳。

三道独立关卡分别代表产物完整性、主张评估和使用方接受。通过其中一道,不意味着通过下一道。
三道独立关卡分别代表产物完整性、主张评估和使用方接受。通过其中一道,不意味着通过下一道。

协议设计笔记 · 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 观察和独立验证的状态支持不同的主张。通用封装应保留原始证据类型、来源、限制与尚未解决的问题。

补充原始参考资料

继续阅读

完整简体中文译文,由 AI 辅助准备,尚未完成独立母语技术审阅。存在歧义时以英文规范为准。代码、字段和权限不因翻译而改变。 English
本地搜索 · 不会向 AI 提供商发送提示词或查询

隐私与偏好

必要项

网站传输、安全服务,以及最长保存 180 天的本地隐私选择记录。不包含广告标识符。

在此浏览器保存动态效果偏好。可选,除非你选择启用,否则关闭。

使用静态插图。设备设置优先,无需允许存储。

分析与广告

目前关闭。未来如使用 Cookie、像素或分析工具,将予以披露,并在适用时重新征求选择。此处按钮不授权未来追踪。

隐私政策 · Cookie 政策