Root Proof 与 ResourcePackage：如何证明一个资源版本可信

资源版本需要可验证

在智能体资源生态中，版本更新非常常见。一个 Skill 会迭代提示词和工具声明，一个 MCP Server 会增加工具，一个 Agent Service 会调整 endpoint 或认证策略，一个 API 会升级 schema。问题在于：调用者如何确认自己看到的是某个资源的可信版本，而不是被篡改、伪造或过期的描述？

OAN 用 ResourcePackage 和 Root Proof 来处理这个问题。资源 DID 标识稳定主体，ResourcePackage 则绑定某一次发布的 DID 文档、元数据、包版本、哈希和验证材料。Root Proof 是 Root 对该资源包验证结果的签名证明。二者结合后，可以让 Discovery、SDK 和调用方确认“这个资源版本确实经过 Root 验证并发布”。

ResourcePackage 把分散材料变成一个验证单元

ResourcePackage 的价值在于把分散的信息组合成一个可验证单元。一个资源不仅有 DID 文档，还可能有元数据、外部 manifest、包哈希、版本号和注册证据。如果这些信息各自散落在不同地方，客户端很难判断它们是否属于同一次发布。ResourcePackage 将这些材料按协议形态组织起来，再通过哈希建立绑定关系。

在 OAN 的共享协议实现中，ResourcePackage 会包含 packageVersion、resourceDid、resourceType、didDocument、didDocumentHash、metadataHash、packageHash、hashAlgorithm、metadata、rootProof 和 createdAt 等字段。RootProof 中又包含 rootDid、bulletinEventHash、signature、packageClaims、proof、cryptoSuite 和 hashAlgorithm。这些字段不是展示用装饰，而是后续验证的输入。

Root Proof 签的是可核验事实

ResourcePackageClaims 是 Root Proof 的关键载荷。它绑定资源 DID、资源类型、版本、DID 文档哈希、元数据哈希、包哈希、哈希算法、生命周期状态、授权域和 bulletin 引用。这样，Root 签的不是一句笼统的“该资源可信”，而是一组可以被程序逐项核验的事实。只要 DID 文档、元数据或包内容发生变化，相关哈希就会变化，旧证明不能被误用到新版本上。

Root Proof 的价值在于给这个包一个可验证的权威出处。Root 在接收 Registrar 提交时，需要检查 DID 文档完整性、资源类型一致性、主体控制证明、包哈希、元数据哈希和上游签名等条件。验证通过后，Root 才会归档资源包、生成证明，并协调后续 CDN 发布和 Discovery 可见性。Discovery 不是凭本地偏好直接收录资源，而是同步 Root 认可的资源包。

校验逻辑可以被第三方实现复用

代码层面的校验也能说明 OAN 关注的不是“页面记录”，而是包级一致性。资源包验证会分别检查 DID 文档哈希、元数据哈希、包哈希、资源类型一致性、元数据一致性和 Root claims 绑定关系。对应到实现，就是 verify_did_document_hash、verify_metadata_hash、verify_package_hash、verify_resource_type_consistency、verify_metadata_consistency、verify_root_claim_binding 这一类可组合检查。第三方节点未来也应围绕这些可验证规则实现自己的同步和准入测试。

这套机制尤其适合资源版本更新。资源标识不变，版本可以变化。调用方查询 Discovery 时，默认可以获得最新 active 版本，也可以在需要时追溯历史版本。每个版本都应有自己的包哈希和验证材料。这样，资源提供者可以持续迭代，而用户不必在每次更新后重新信任一个完全陌生的对象。

分发层不是信任权威

CDN 在这里承担分发职责，但不是信任权威。即使 CDN 被替换、缓存或迁移，客户端仍然可以通过包哈希、Root Proof 和 bulletin 事件检查资源是否可信。这个设计避免了把“能下载到文件”误认为“文件一定可信”。对智能体自动化调用来说，这一点非常重要。

与传统应用商店或插件市场相比，OAN 的 ResourcePackage 更偏协议对象，而不是平台页面。它服务于自动化验证：Discovery 可以验证后再索引，SDK 可以在调用前检查，第三方节点也可以按同一规则实现自己的同步和查询逻辑。只要协议对象稳定，生态中不同实现就能围绕同一套信任材料互操作。

链上治理和链下资源包各司其职

Root Proof 也不是为了把所有数据都放到链上。OAN 的架构是“链上治理基础设施身份，链下执行资源注册、包验证和发现”。资源包本身可能较大、更新频繁、查询复杂，更适合由 Root、CDN 和 Discovery 以服务侧方式处理。Root Proof 让链下流程仍然具备可验证性。

因此，当我们说 OAN 支持可信资源发现时，核心不是 Discovery 页面上多了几个字段，而是背后有资源包、哈希绑定、Root 验证和证明链条。对未来的智能体互联网而言，资源版本是否可信，将决定自动化调用能否从“能用”走向“敢用”。

证据链条的分工

因此，当我们说 OAN 支持可信资源发现时，核心不是 Discovery 页面上多了几个字段，而是背后有资源包、哈希绑定、Root 验证和证明链条。对未来的智能体互联网而言，资源版本是否可信，将决定自动化调用能否从“能用”走向“敢用”。

验证链条

Root、CDN 和 Discovery 放在同一条链上，意思不是它们承担同样的职责，而是它们分别完成验证、分发和查询。Root 负责把事实钉住，CDN 负责把工件送出去，Discovery 负责把可信结果暴露给用户。

为什么要把证据包起来

把证据分散在多个文件里，用户和第三方很难判断“到底哪一版才可信”。ResourcePackage 的价值，就是把 DID、metadata、包内容和 Root Proof 绑成一个可重复验证的单元。