ERC-8326 文档包锚定：一堆链下文件压成一个承诺上链时，能证明什么

NFT 圈最经典的纠纷是”改图”：代币合同没动，托管在服务器上的元数据悄悄换了内容，买家手里两份条款文本各执一词。解决这类争议的原始工具很朴素——把文件哈希写进链，给某个时刻的文件状态盖时间戳。ERC-8326（Canonical Document Bundle Anchor）把这件事工程化了：面向”一揽子文档”定义了确定的打包算法和上链接口，让版本历史变成可回放的链上记录。按以太坊 ercs 仓库的记录，这份提案状态为 Review，创建于 2026 年 7 月 5 日。

从五元组到一个承诺

标准把包内每份文件表示成定长条目：内容哈希、文档角色、媒体类型哈希、文件名哈希、归一化档标识。五个字段全部参与排序——清单按全序排列后在模式版本前缀下哈希，压成一个 bytes32 的包承诺。为什么要这么较真地排序并且把文件名也纳入：只要任何成员、任何命名、任何归一化规则有差异，算出的承诺就不同，接收双方从此不必争论”我们打包方式不一样”。标准还给了参考哈希函数与规范 JSON 归一化的示例，比如带重音字符的文件名要先做 Unicode 归一，否则两个系统对同一个文件名会得出不同哈希——这类细节正是过去链下哈希存证最常翻车的地方。

链上接口：锚定、替换与找回

合约侧用 (subjectId, role) 二元组划出命名空间，anchorBundle 把一个包承诺锚进某个槽位，发 BundleAnchored 事件；条款更新用 supersedeBundle 替换当前锚，发 BundleSuperseded——注意语义是”追加式替换历史”，旧锚不删除，槽位的有效历史完整可查。getAnchor、isAnchored、activeBundle 供任何人对着一串链下文件重算承诺后核查询问。可选的找回接口 IDocumentBundleAnchorRecovery 允许管理员把一个有争议命名空间的归属权重新分配，但标准强调这不动已锚定的记录本身——换的是钥匙，不是历史。

与 NFT 元数据问题的对应关系

把这套机制放回数字资产语境，它补的正是”代币不动、条款变脸”的缺口：项目方可以把许可证、白名单规则、路线图挂成一个文档包锚定，任何时点都能验证”第 N 版条款的哈希是什么、第几块被第几版替换”。对买家，检验方式也标准化了：把手里的条款文件按同样规则重算包哈希，调用 isAnchored 比对，对不上就说明拿到的不是链上承认的那一版。

标准自己划的四条界限

一个纠纷场景里的完整验证链

把机制放进纠纷现场最能看清边界。买家手里有一份项目方 V2 许可证文本，怀疑它不是链上承认的版本：先把文件连同文件名按项目公布的归一化档做规范化，再按标准的全序规则拼清单、套用与项目相同的模式版本前缀算出包哈希，调用 isAnchored——返回否定就证明手里文本与任何已锚定包都不匹配，纠纷当场了结；返回肯定还要补一步，用 getAnchor 核对这个包挂在哪个 (subjectId, role) 槽位、是不是 activeBundle 认定的当前版，因为旧版本并不会从历史里消失，拿 V1 哈希去查询同样会得到”已锚定”的答复，混淆新旧正是这类验证最容易踩的坑。若项目方声称管理员权限被滥用、条款被强行替换，维权依据不在”记录被改”——8326 的追加式替换历史保证了所有曾锚定的包按序可回放——而在 SlotPrincipalAssigned 事件上：谁在什么区块把槽位归属重新指派给了谁，公开可查，找回接口的每次动用都留下指纹。链下那份文件此刻是否仍可下载，则完全取决于托管方；哈希锚定管的是”这串字节的登记历史”，不是”这份数据的永生”，这正是标准在摘要里把可得性排除在承诺之外的原因。

标准文本罕见地在摘要里直接声明它不能做什么，值得逐条转述：它不证明文件真实——锚定的哈希对得上，只说明内容与某次登记一致，内容是谁签的、有没有被篡改前就已造假，锚定机制管不着；它不证明合法效力——链上锚不是公证，更不是法律承认；它不证明链下可得性——锚在链上的哈希对应的 IPFS 节点或服务器可能早已下线，包承诺救不了丢失的文件；它不证明归一化档被正确应用。所以一个健康的用法是把 8326 当作版本审计基础设施，配合签名与托管冗余使用，而不是把它当成”上链即存证有效”。对 Review 阶段的接口，接入前还需以合约实现为准核对。本文为机制说明，不构成任何投资建议。