每个主要云服务商都试图向你推销托管账本服务。AWS 有过 QLDB（现已停服）。微软有 Azure Confidential Ledger。推销话术总是一样的：我们来处理密码学，你获得防篡改记录。听起来像是一个已解决的问题。但架构中埋藏着一个陷阱——而它只有在你试图在创建证明的云之外使用这些证明时才会显现。
承诺与细则
托管云账本确实提供了真正的加密完整性。它们对你的数据进行哈希，将区块链接在一起，并发放收据。数学是真实的。但验证路径通过云服务商的 API 运行。你的证明只和厂商的服务端点一样可访问。
当审计师要求证据时，你不能交给他们一张收据说“自己验证吧。”你必须说：“登录我们的 Azure 门户，导航到这个端点，用这些凭证认证，然后调用这个 API。”这不是独立验证——这是厂商中介的验证。
锁定破坏完整性的三种方式
锁定问题以三种具体方式表现，侵蚀了托管账本的价值主张：
- 验证依赖：第三方审计师、监管机构和合作伙伴需要云凭证才能验证你的数据。这造成了摩擦、安全隐患和单点故障。
- 服务停服风险：AWS 在6年后关闭了 QLDB。每个托管账本都承载着这种风险。当服务消亡时，你的证明变得不可访问——可能恰好在你最需要它们的时候。
- 多云不可能：如果你同时在 AWS 和 Azure 上运营（许多企业如此），没有任何单一云账本能覆盖两者。你最终得到碎片化的完整性——有些记录在一个云上可证明，另一些在另一个云上，没有一个是通用可验证的。
不透明验证的真实成本
锁定问题不仅仅是架构性的——它有直接的商业成本。当验证需要平台访问时，每次完整性检查都变成一条依赖链：认证、网络连接、API 可用性和订阅状态。
在事件响应、争议解决或监管检查中，这条依赖链在最不该引入延迟和风险的时刻引入了延迟和风险。问题从“我们能否证明这条数据没被篡改”变成了“我们能否让所有人在正确的平台上完成认证来检查。”
厂商中立验证的样子
替代方案是将证明存放在没有任何单一公司控制的基础设施上。公共区块链提供了这一点：一旦 Merkle 根被锚定在链上，任何拥有浏览器和区块浏览器的人都可以验证。
结合像 IPFS 这样的内容寻址存储来存放清单和元数据，这就创建了一条不依赖于任何厂商的 API、订阅或持续存在的验证路径。证明就是证明——而非指向厂商服务的指针。
锁定最为致命的场景
云账本锁定在以下场景中尤为危险：
- 监管检查 — 当监管机构要求数据完整性证据时，证明需要可独立验证——而不是依赖于你的云订阅处于活跃状态以及你的 API 密钥有效。
- 多方争议 — 当两方就记录内容产生分歧时，证明必须是中立的。如果它存在于一方的云账户内，另一方没有理由信任它。
- 长期存档 — 监管留存要求跨越 7-10 年以上。没有任何云服务在这个时间线上有保证可用性的记录。QLDB 只存续了6年。
选择完整性而非便利
托管云账本很方便。它们与现有云基础设施无缝集成。但对于完整性而言，便利是错误的优化目标。防篡改记录的核心意义在于，证明必须能够在对抗性条件下存活——包括服务提供商退出市场的情况。如果你的完整性证明需要第三方的持续配合，那它就不是真正的证明。它只是一个承诺。
如果你的数据完整性证明需要厂商的 API 在运行，那它就不是证明——是承诺。承诺会过期。数学不会。