阅读约 7 分钟
无需信任厂商,审计师也能自行核对的合规日志
把合规证据的 Merkle 根锚定到 Cardano 上,审计师日后即可确认某份报告或某条日志在某个公开时间之前已被承诺——而无需信任产出它的系统。

合规证据一旦锚定在产出它的系统之外,说服力就强得多。做法很简单:定期对你的报告、审计日志和控制快照计算哈希,把这些哈希批量汇入一个 Merkle 根,再把这个根作为一条 Label 309 存在性证明(Proof of Existence)发布到 Cardano 上。日后,审计师只需要拿到叶子和交易引用,就能确认某个特定条目确实属于这批被承诺的内容,并且这批内容在某个公开的区块时间之前就已存在——而无需信任你的数据库、你的仪表盘,也无需听信你的一面之词。
这并不能证明每一条记录下来的事件都属实。它只是让悄悄改写变得难以掩盖。
为什么「它在我们系统里」对审计师来说是个站不住脚的回答?
大多数合规证据都存放在厂商系统内部,这固然方便,却带来了信任问题。如果证据只存在于产出报告的那个平台里,日后的审查者就会提出一些这套系统无法自证的问题:
- 这条日志会不会是事后被改过的?
- 报告是在期限之前还是之后生成的?
- 这份控制快照在当时是否真的存在?
- 证据是不是在事件发生后补录进去的?
- 导出的那份 PDF 和当初被审阅的是同一份吗?
- 厂商或某位管理员有没有可能改写过这条记录?
内部系统可以管控得很好,但它终归还是内部系统。时间戳、变更历史以及「截至某时」的状态,全都来自那个行为正受审查的同一方。存在性证明为这条时间线引入了一个外部见证者:一份独立的记录,证明某个摘要在某个公开时间之前就已存在。
你应该锚定哪些证据?
把日后可能要紧的证据锚定下来——也就是监管机构、客户、董事会或法院有朝一日可能要求你按某个特定日期的原貌复现的任何东西。常见的对象包括:
- 合规与透明度报告;
- 风险评估;
- 控制快照;
- 审计日志;
- 访问权限审查;
- 政策审批;
- AI 治理与模型评估记录;
- 内容审核报告;
- 事件时间线;
- 漏洞响应日志;
- 面向客户的安全交付物;
- 提交给监管机构的材料;
- 数据处理记录。
证据本身可以保持私密。公开记录只承诺一个哈希,或承诺一个覆盖众多哈希的 Merkle 根——绝不承诺底层内容。
为什么要把证据批量汇入一个 Merkle 根,而不是逐个文件去锚定?
合规证据通常是一条数据流,而不是单个文件。一天就可能产生成百上千条记录;一个审计周期可能横跨多套系统;一个平台可能同时从内容审核、客户支持、安全、模型评估和事件响应等环节生成日志。把每个条目都放进各自的交易去锚定,既慢又贵。
Merkle 树解决了这个问题。你把每个条目计算成一个叶子,把这些叶子折叠成一个 32 字节的根,再发布这一个根。有序的叶子列表则留在链下。日后,任何持有叶子的人都能用一份小巧的包含证明,证明某份特定的报告或某条日志已被纳入其中——而这份证明的大小只随批次规模呈对数增长,无需把任何私密记录放上链。
根是公开的,底层证据则始终处于你自己的控制之下。如果你正在权衡它与逐文件方案的取舍,用一条记录覆盖成千上万个文件 一文详细梳理了其中的取舍。
审计师实际上验证的是什么?
审计师验证的是从单份证据一路延伸到区块链的整条链。对单个条目而言,步骤如下:
- 文件、报告或日志条目本身;
- 它的哈希;
- 把该哈希连到根的 Merkle 包含证明;
- 写入 Label 309 记录中的根;
- Cardano 交易时间;
- 记录上的任何签名;
- 你那份描述日志记录节奏的政策。
构建这棵树并核对一份包含证明,全是纯计算——不需要服务器、不需要账户、不需要网络。任何持有叶子和链上根的人,都能独立地重新推导出任意一份证明,这正是它的关键所在:验证并不依赖于你的配合。
这回答了一个范围有限但很有用的问题:这份证据在当时是否属于某个被承诺的批次?这并不构成一份完整的审计意见,但它为证据的时间线提供了一个任何内部系统都给不了的外部锚点。
这与日益加重的监管压力有何关系?
许多监管制度都在朝着更多文档、更多报告以及机器可读的透明度方向演进。欧盟的《数字服务法》(Digital Services Act)就是一个明显的例子。它要求中介服务发布透明度报告,要求托管服务为其审核决定出具理由说明,并对超大型在线平台和搜索引擎施加更重的义务:更频繁的报告、向经审核的研究人员开放数据访问、设立匿名举报人渠道,以及每年的风险评估和独立审计报告。欧盟委员会还把透明度报告标准化为一种可比较、机器可读的格式。
锚定证据哈希本身并不能满足某项法规的要求,本文也不构成法律意见——什么才是恰当的证据,取决于法律、司法管辖区、公司以及具体的工作流程。但底层的需求是一致的:各团队越来越需要拿出可重复、经得起审视的证据。一份带时间戳的承诺,有助于表明证据在审查、期限、事件或争议之前就已存在,而不是为了应对它们才临时拼凑出来的。
这里所说的「无需信任厂商」究竟意味着什么?
信任厂商,就是把某个平台的数据库当成整个证据故事的全部依据。三个常见的情形可以看出这种依赖会在哪里失效:
- 如果你的合规仪表盘显示某项控制上个月是绿色的,你能证明它确实是 上个月 这样显示的——而不是昨天才被改成这样的吗?
- 如果你的 AI 治理工具显示某份审核报告在一起公开事件之前就已存在,你能证明这份报告不是事后重新生成的吗?
- 如果你的 GRC 平台导出了一份 PDF,你能证明被审阅的就是 那份一模一样的 PDF 吗?
一条 Label 309 记录并不会把厂商从你的工作流中剔除。厂商仍然可以生成报告、存储证据。改变的是:这份证明建立了一个外部承诺,厂商日后无法在不破坏哈希链的情况下悄悄改写它。(这里的「GRC」指治理、风险与合规,即包含 Vanta、Drata 等类似平台在内的那一类工具。)
清单里应该包含什么?
一份清单能让日后做验证的人看懂这份证明。一份合规清单可能记录:
- 证据所属的时间段;
- 系统名称;
- 控制和报告的标识符;
- 文件名和文件哈希;
- 记录类型;
- 责任人;
- 导出时间戳;
- 政策版本;
- 签名状态;
- 存储位置;
- 一个指向包含证明的引用。
这份清单可以保持私密、公开发布,或封存给特定的接收方。要紧的是它足够稳定、足够有文档支撑,以便日后据此验证。一份文档化不充分的清单,可能留下一个密码学上有效、但操作上令人困惑的证明——字节都对得上,却没人说得清当初承诺的到底是什么。
你应该多久锚定一次?
让节奏与风险相匹配。有些团队每天锚定;也有团队按小时、按事件、按发布、按审计周期或按监管报告来锚定。
对于持续监控类的义务,固定节奏正是关键所在。一份在审计前一天才生成的报告,远不如一连串定期承诺有说服力——后者表明证据是随时间持续采集下来的。这个节奏本身可以成为控制措施的一部分:如果你的政策规定每天发布一个根,那么缺了哪一天,所有人都看得见。同样的逻辑也让存在性证明天然适用于 法律证据与电子取证——在那里,某件事 何时 被记录下来,恰恰是争议的焦点。
合规记录应该封存吗?
通常是的。合规证据可能包含敏感的运营数据、个人数据、安全细节或机密的商业记录。把明文发布出去会是个错误。Label 309 支持三种模式,而且你可以混合使用:
- 仅哈希——只发布承诺,证据留在内部。
- Merkle 根——发布一个覆盖众多私密证据条目的根。
- 封存——把加密后的证据或清单存放在一个内容寻址位置(URI),并把解密密钥包装给特定的接收方,这样证明和密文就能一同传递,而只有获授权的密钥持有者才能读到内容。
当你想同时拥有可验证的时间戳 和 机密性时,封存就很有用——比如那些日后可能要交给监管机构或审计师、但今天还不能公开的证据。但要记住它的边界:一条封存记录证明的是时间和完整性,而不是永久的保密。接收方一旦解密了内容,事后仍然可以把明文泄露出去。
这不能证明什么?
一份存在性证明表明的是某段确切的字节在某个公开时间之前就已存在。它在这一点上很精确,对其他一切则保持沉默:
- 它不能证明底层事件属实。 如果生成并承诺了一份不实的报告,证明只能表明这份不实报告曾经存在——它无法让其内容变得准确。
- 它不能证明合规计划是有效的。
- 它无法取代 访问控制、变更管理、日志完整性、职责分离、法律审查或审计流程。
- 它不能证明证据是完整的,除非你的流程和控制措施能独立地支撑这一主张。
存在性证明是一层证据完整性保障,而不是一套合规计划。关于完整的边界,参见 一份证明无法证明什么。
一个好的初次落地方案是什么样的?
从你已经在生成的报告入手,并且先从一条证据流做起,而不是一次性铺开所有系统:
- 选定一份合规报告或一份控制快照。
- 以稳定、可复现的格式将其导出。
- 对文件计算哈希。
- 把这个哈希加入每日或每周的清单。
- 为这个周期构建一个 Merkle 根。
- 发布一条 Label 309 记录,可选择对其签名。
- 保存清单、叶子列表、包含证明和交易引用。
- 把整个流程文档化,让审计师明白这份证明意味着什么。
然后再扩展到下一条证据流。同样的结构也能干净利落地接入自动化——构建与发布这几步,正好可以嵌进 CI/CD 流水线,在每次运行结束时锚定一个根。
这件事为什么对 CEO 而非仅仅对合规团队重要?
它把对话从「信任我们的仪表盘」转向「验证我们的证据时间线」——而这个区别,对客户、审计师、董事会、投资者、监管机构乃至内部事件复盘而言,同样要紧。
它还降低了对任何单一厂商的依赖。即便厂商的系统发生变动、导出功能消失,或某个账户被关闭,你手里仍然握着对所保存证据的带时间戳的承诺。这些证明可以对照一条公开的区块链和一个公开的浏览器来验证,整个过程不需要任何签发方服务器参与。这样看来,这其实算不上一项加密货币功能,而是一种证据韧性。
一句话总结
合规证据应当难以被悄悄改写。对要紧的报告和日志计算哈希,把它们批量汇入 Merkle 根,按清晰的节奏发布 Label 309 记录,并保存好清单和包含证明。当内容不能公开时,就把敏感证据封存起来。
这份证明不会告诉你公司是否合规。但它有助于证明哪些证据曾经存在、它们何时存在,以及日后的某份文件是否仍与被承诺的记录相符——并且它让审计师无需盲信你的系统,就能确认上述这一切。
延伸阅读
- 用一条记录覆盖成千上万个文件——Merkle 批处理和包含证明是如何运作的。
- 一份证明无法证明什么——存在性证明的边界。
- 开放标准及其参考实现托管在 label309.org 和 github.com/cardanowall。Label 309 已提交至 Cardano CIP 流程,目前作为 Metadata 类别的提案正由 CIP 编辑审查中(公开的 PR)。
- 欧盟委员会对 DSA 透明度义务 的概述,描述了受监管平台越来越需要产出的那类可重复、机器可读的证据。