开放式时间戳（OpenTimestamps）：可扩展、信任最小的

每晚八点，我们在社区分享知识，等你。

NervosFans 微信公号：Nervosfans

入群请加乐乐微信：sensus113 美果大冰微信：xj73226

备注入群，谢谢！

---

3.4聚合扩容

使用灵活性提交操作的一个重要原因是其带来的扩展性。 好比，有10000个不同的文件要加时间戳：一般的比特币时间戳方案解决这个问题需要10000笔比特币交易，效率低且成本高。 开放式时间戳方案中，可以为这10000个文件创建个Merkle树，然后在一笔交易中给树的外沿（端点）加上时间戳。那么每个文件的时间戳就是一系列提交操作，里边包含了文件Merkle路径，然后是比特币区块中的Merkle路径，最后到达区块头。 由于验证人视这一些列操作为时间戳操作，所以不会有异议。

通过聚合服务器系统，可做进一步改进：任何人都能提需要加时间戳的摘要至一个公开可访问的“碰头点”。a.pool.opentimestamps.org、b.pool.opentimestamps.org，就属于这种聚合服务器。

提交摘要进行聚合时，摘要先被添加到待处理摘要列表中。列表被定期组合成单个Merkle树，树的外沿用比特币加时间戳。然后，服务器返回每个提交摘要的单个时间戳证明。这个过程可以是多层深度的，意思是Merkle树时间戳套Merkle树时间戳（with merkle trees timestamping tips of merkle trees timestamping tips of merkle trees）。这样的话，每秒可以为无限数量的消息加时间戳，那么系统就可以从一名用户扩展到无限数量的用户，而不会对时间戳的验证方式进行任何变更。

虽然聚合过程越集中效率越高，但也基本上是无信任的：最差的情形就是聚合服务器离线，与其说差不如说是不便。 聚合系统不能生成假的时间戳，原因是由比特币证明时间戳的有效性，而不是聚合系统。

3.5公共日历

虽然聚合服务器本身高效，但并不十分方便，原因是仍然需要等待基础比特币交易得到确认，平均时长至少10分钟，运气不好，则更久。对于有些应用程序来说可能没问题，开放式时间戳客户端支持--wait标志，意思说会一直等着底层比特币交易得到确认。

但是，对于很多应用来说，这个速度远远不够。譬如，发送带时间戳的PGP签名电子邮件或签署带时间戳的Git提交时，肯定是希望一两秒之内就能加上时间戳，但是别忘了任何现有的去中心化共识系统都做不到这点的。

开放式时间戳为解决这一问题做了些折中：公共日历服务器。 所谓日历就是时间戳的集合；可以通过日历服务器远程访问日历。公共日历服务器可参见：alice.btc.calendar.opentimestamps.org、bob.btc.calendar.opentimestamps.org

日历服务器与聚合服务器协同工作，不用非等到比特币为挂起的摘要加上时间戳。 聚合系统做的是将所有提交的时间戳以一秒的间隔聚合到Merkle树中，然后提交树的外沿给公共日历服务器。日历服务器确定两件事：

1. 比特币区块链会在合理的时间内为添加到日历中的提交加上时间戳。

2. 区块链将无限期保留这个完整提交时间戳（complete commitment timestamp），且公众可访问。

日历服务器生成的时间戳叫不完整时间戳。 举个例子：

最后一行中，验证时间戳时，该行告诉验证者向远程日历“Alice”请求剩余的时间戳：

因此，借助公开聚合日历基础设施，能在大约一秒内快速方便地创建时间戳。 任何人都可以使用去中心化无信任的比特币区块链来验证这个时间戳。

当然，这种便利确实有成本：公共日历是个中央故障点。 也正是出于这个原因，才把需要公共日历服务器协助的时间戳叫做不完整时间戳。为降低单点故障的风险，开放式时间戳采取了多种手段：

3.5.1日历使用（可选）

使用—wait选项，创建不依赖日历的时间戳。意思是启用后，客户端会一直等待，直到比特币区块链完全确认时间戳。 生成的时间戳将包含比特币证明时间戳所需的全部数据，允许在本地完成验证。

3.5.2时间戳升级

可以使用‘ots upgrade’命令升级不完整时间戳。从日历中下载完整的比特币证明并保存为时间戳的一部分，升级过的时间戳与--wait选项生成的时间戳一样。

3.5.3冗余

默认下，创建时间戳时同时使用两个公共日历，且只有二者均响应时方能保存时间戳：

前面说过，时间戳就是提交操作树，路径在sha256操作后分叉。 只要有一个日历可用，就可以验证时间戳。

也可以使用自己的日历，替换或辅助公共日历。比如，Example Inc.中可以设置自己（钱包）的日历，但依旧使用公共日历来创建比特币证明，大概是考虑到万一公开日历真瘫了还能靠回自己。 这种时间戳大概长这样：

客户端有个自己可以自动联系的日历白名单，因此非Example Inc.用户可以忽略内些待处理证明然后使用公共日历；具体Example Inc.会不会公开自己的日历完全是人家的决定，但无论如何，都不必依赖公共日历来验证自己的时间戳。

服务器端能执行此操作的软件尚未编写出。 可一旦编写完成，就能与现有客户端兼容，这也是体现提交操作模型优势的一个很好的例子。

3.5.4缓存及镜像

开放式时间戳客户端会维护从日历服务器检索的时间戳数据缓存。 验证同一时间戳两次，就能看到（缓存）：

即便日历无法访问，也可以直接从缓存升级时间戳：

任何人使用本地比特币节点即可验证升级后的时间戳。

一般来说，时间戳证明具有自我验证的属性，意思是无论从何处得来证明，仍然可对时间戳进行验证。 未来的话，希望能利用这个属性让任何人都能轻松制作公共日历的镜像，不管是相关的时间戳子集，还是完整副本。 算下来，这个数据并不算大：一年有3100万秒，平均下来每秒约100字节，那么一个完整的日历镜像每年要消耗掉大约3千兆字节。

这也意味着可以使用Freenet、Tahoe-LAFS和IPFS等技术进行去中心化日历镜像；同样的，一次写入和数据量较小使得抗DDoS托管易于使用。

3.5.5法律风险

预计运营日历基础架构的法律风险很低，原因如下：

1. 日历不具有权威性：最差的情况就是拒绝服务，但不会生成假证明。

2. 撤掉日历无任何意义：数据被广泛镜像很容易。

3. 日历不存储外部提供的数据：所有传入摘要都是随机数过的，且只对这些摘要的提交永久存储。

最大的法律风险，应该是软件专利。

4. 脚注

https://petertodd.org/2016/opentimestamps-announcement