存在性证明对比 OpenTimestamps：哪种时间戳更适合你的工作？

如果你只需要一份紧凑、可携带、任何人都能对照公链验证的时间戳，那么 OpenTimestamps 是一个出色而专注的选择。如果你需要一份内容更丰富的链上证明记录——它还能承载签名、封存（加密）的负载、面向接收方的投递、内容寻址存储指针以及 Merkle 批处理——那么 Label 309 正是为此而生。两者在核心主张上是重叠的（「这些字节在时间 T 之前已经存在」），但在围绕它的一切上则各走各路。

两者都能在不要求你信任某家公司服务器的前提下证明某物在某时刻之前已存在。差别在于形态：OpenTimestamps 产出一个小巧的外部证明文件；Label 309 则在 Cardano 上发布一条结构化记录。本文将梳理各自的适用场景。

OpenTimestamps 是什么？

OpenTimestamps 是一套用于区块链时间戳的协议与工具集，最常见的做法是锚定到 Bitcoin。思路很简单：你对数据计算哈希，构建一份时间戳证明，这份承诺最终会落入一笔 Bitcoin 交易中。从那一刻起，任何人都能核验该数据在那个区块的时间之前就已存在。

为了控制成本，OpenTimestamps 使用「日历服务器」，把众多用户的哈希聚合进一笔 Bitcoin 交易，这样你就不必为每个文件单独发一笔交易。客户端会生成一份可携带的 .ots 证明文件，随你的数据一同保存。

验证环节最能体现它的信任模型：你拿 .ots 证明对照原始文件和一份 Bitcoin 链视图来验证，整个过程没有可信服务器介入。官方客户端指出，本地验证需要一个 Bitcoin Core 节点——一个裁剪过的节点就够了。

对于追求极简、可独立验证的时间戳而言，这是一套优雅而成熟的设计。

Label 309 是什么？

Label 309 是一套开放、厂商中立的标准，用于 Cardano 上的存在性证明（Proof of Existence）记录。这条记录存放在一笔 Cardano 交易元数据中的元数据 label 309 之下，该交易的区块时间就是见证，证明被承诺的字节不晚于那一刻就已存在。标准本身才是持久的产物；CardanoWall 的 Web 应用、命令行工具与 SDK 都是构建在它之上的参考实现。

该标准已提交至 Cardano 的 CIP 流程，目前作为元数据类别（Metadata）的提案正由 CIP 编辑评审（这个开放的 pull request 当前显示为一个暂定编号）。请注意，链上标识符——元数据 label 309——与它最终获分配的任何 CIP 编号是相互独立的。

要验证一份 Label 309 证明，任何人都可以从公开浏览器获取那笔 Cardano 交易，重新组装出规范记录，验证其结构，检查确认深度，验证任何签名，并重新计算被承诺的内容哈希或 Merkle 包含证明。在最简单的层面上，它回答的是和 OpenTimestamps 相同的问题。但它并不是一个单一的证明文件——它是一种链上记录格式，被设计成可以一次性承载多个证明层。想看更完整的讲解，参见 Label 309 是如何工作的和区块链上实际记录了什么。

两者真正的区别在哪里？

OpenTimestamps 是为时间戳量身打造的。Label 309 则是为一份完整的存在性证明记录而构建的。

当问题是下面这些时，OpenTimestamps 更合适：

这个文件是否在这个由 Bitcoin 见证的时间之前就已存在？
我能否保留一个小巧的证明文件、日后再验证？
我能否在不泄露文件内容的前提下打时间戳？
日历服务器能否把多个请求批量处理，让我不必按文件付费？

当问题是下面这些时，Label 309 更合适：

这个文件、清单或 Merkle 根是否在这个 Cardano 区块时间之前就已存在？
是否有某个特定的身份密钥对这条记录做了签名？
文件本身能否被封存（加密）并在日后恢复？
这条记录能否为特定接收方加密？
一条记录能否一次性对成千上万乃至数百万个叶子做承诺？
公众能否在没有 CardanoWall 账户、也无需访问我们服务器的情况下验证它？

两者都是植根于公开共识的证明系统。它们的形态——以及由此解锁的工作流——各不相同。

OpenTimestamps 最擅长什么？

OpenTimestamps 最擅长的，是围绕一个外部证明对象构建的极简、公开时间戳。你为一个文件打时间戳，把 .ots 证明保存在它旁边，等承诺在 Bitcoin 中得到确认后再升级这份证明。日历模型让众多用户分摊锚定的成本。

它这份克制是健康的。它不试图去当一套机密投递系统、一套媒体来源溯源标准、一套软件签名生态，或一个法律公证机构。它就做时间戳，并且把这一件事做得干净利落。对于想要从一款久经考验的工具中获得 Bitcoin 背书时间戳的人来说，这份专注本身就是一项优点。

Label 309 在时间戳之上又叠加了什么？

Label 309 在时间戳主张之外包裹了一层结构。一条记录可以包含：

每个条目的一个或多个内容哈希；
内容寻址存储指针（Arweave 用 ar://，IPFS 用 ipfs://）；
针对整条记录的可选记录级签名；
用于封存条目的加密信封，其密文存放在链下；
按接收方划分的密钥槽，把内容密钥包装给选定的接收方；
Merkle 承诺，把一个链上根绑定到一份任意大的链下叶子列表；
指向更早记录的取代指针（仅追加——它绝不撤销先前的记录）；
为未来配套规范预留的带命名空间的扩展键。

一旦某个工作流需要的不止是「我有一个时间戳证明文件」，这一点就变得重要起来。举例来说，发送方可以封存一个文件，把它发给某个接收方，将加密后的密文发布到一个内容寻址 URI，同时仍让公开记录保持可独立验证——参见哈希、签名、封存、分享。一项高吞吐量的 AI 服务可以发布一个 Merkle 根，用它代表许多生成的产出；一条 CI/CD 流水线则可以对一条覆盖整组清单的发布证据记录做签名——参见一条记录覆盖成千上万个文件。这些工作流需要的记录，远比一份纯 .ots 证明所承载的更丰富。

哪一个更去中心化？

这里不是喊口号的地方，所以要把每种模型要求你信任什么说清楚。

OpenTimestamps 锚定到 Bitcoin，其工作量证明历史为时间戳提供了非常坚实的基础。一旦所需数据到位，证明就能独立验证——一份完整的 .ots 证明可以完全对照本地 Bitcoin 节点验证，而一份不完整的证明仍需日历服务器补上通往区块头的路径。

Label 309 锚定到 Cardano。它的验证只信任公开的 Cardano 链、记录字节以及内容哈希——除此之外别无其他。对于核心证明，它不要求信任 CardanoWall，也不要求信任任何由发布者运营的服务器；验证方只需要交易引用，文件字节可选，再加上一个由它自行选定的公开浏览器。

抽象地说，两者都谈不上「更去中心化」。真正实际的问题是：哪一条链、哪一套工具、哪种证明形态、哪种成本模型和哪个生态，更契合你的工作流。

隐私方面呢——哪一个会泄露文件？

两者都能在不发布私密文件的前提下打时间戳，而且都坦承各自的局限。

OpenTimestamps 的日历服务器收到的是承诺，而不是明文文件。但项目方坦言，打时间戳会泄露元数据：在短时间内接连创建多份时间戳，会让攻击者把它们关联起来；在一条命令里批量处理多个文件，会产生近乎一致的承诺操作，从而暗示它们出自同一作者；而日历的 REST API 目前并不试图提供隐私保护。随机数能让日历无从得知被打时间戳的内容，但周边的元数据并未被隐藏。

对于纯哈希证明，Label 309 把明文留在链下；对于封存证明，它会加密明文，只把密文存放到一个内容寻址 URI。按照设计，链上不暴露任何接收方公钥——接收方只能通过成功试解密某个密钥槽来识别一条消息，因此没有可供读取的接收方字段。它依然无法隐藏的，是时间、付费、网关访问、账户行为以及寻常的操作失误。一份封存记录只让持有密钥者能读取明文；它并不保证匿名，而且接收方在解密之后随时都能泄露明文。

在两套系统中，隐私都是整个工作流的属性，而不只是证明格式本身的属性。

能不能两者一起用？

可以——对于高风险记录，这样做可能很值得。要获得两条相互独立的公开时间路径，用两者一起锚定同一份清单：

创建你的发布、数据集、媒体或证据清单。
对清单计算哈希。
为该哈希或文件创建一份 OpenTimestamps 证明。
为同一份清单，或为包含它的某个 Merkle 根，发布一份 Label 309 证明。
把两份证明引用都与原始证据一并保存。

这样你就有了一条面向 Bitcoin 的路径和一条 Cardano 原生、按 Label 309 结构化的路径。当这份额外的冗余值得为之付出运营开销时，就两者并用；而对大多数工作而言，用一个就绰绰有余。

你什么时候该选 OpenTimestamps？

当任务就是纯粹打时间戳、而一份锚定到 Bitcoin 的证明正是你想要的，就选 OpenTimestamps。它很适合：

简单的文件时间戳
Git 或 PGP 时间戳工作流
已经在运行并信任 Bitcoin 验证的团队
更倾向于随身携带一个外部 .ots 证明文件的工作流
无需更丰富链上记录的极简承诺

它刻意保持专注，而这份专注正是它的要点所在。

你什么时候该选 Label 309？

当证明记录本身需要的不止是一个时间戳，就选 Label 309。它很适合：

Cardano 原生的存在性证明
把作者身份绑定到证明上的已签名记录
在链上承诺的封存（加密）文件
面向特定接收方的机密投递
针对大规模或周期性集合的 Merkle 批处理
内容寻址存储指针
CardanoWall 的 Web、API、CLI、SDK 或自托管网关路径
希望在元数据 label 309 之下共用一种证明格式的应用协议

整套东西都在 github.com/cardanowall 上开源，因此读写一条记录绝不会把你锁死在某一家厂商的工具里。参见 Label 309 是开源的和如何自己验证一条记录。

哪套系统都不能证明什么？

两者本身都不能证明真实性、所有权、作者身份、合法性或质量。OpenTimestamps 证明的是一个被打了时间戳的承诺。Label 309 证明的是一个被打了时间戳的承诺，外加一条记录所承载的任何可选层。无论哪一种，一份证明所表明的，是确切的某些字节在某个公开时间之前就已存在——而不是谁有理、谁拥有什么，或内容是否合法。围绕它的种种主张，仍然需要签名、身份背景、流程证据、法律分析以及人的判断。我们在一份证明不能证明什么中详细展开。

简短版本

OpenTimestamps 是一套强大、专注、锚定到 Bitcoin 的时间戳系统。Label 309 则是一种 Cardano 原生的存在性证明记录格式，留有空间承载签名、封存式留存、面向接收方的投递、内容寻址存储、Merkle 批处理以及未来的扩展。挑选那个证明形态与你真正需要回答的问题相匹配的——或者当冗余值得时，两者并用。

如果你想看更宽泛的对比集，参见存在性证明对比时间戳机构以及作为基础的什么是存在性证明。