分布式系统中最困难的问题之一是时间一致性。事实上，一些人认为比特币的工作量证明算法最重要的功能是充当系统的去中心化时钟。在 Solana，我们相信历史证明提供了这个解决方案，并且我们已经基于它构建了一个区块链。
去中心化网络通过可信的集中式计时解决方案解决了这个问题。例如，谷歌的 Spanner 在其数据中心之间使用同步原子钟。谷歌的工程师以非常高的精度同步这些时钟并不断维护它们。
在区块链等对抗性系统中，这个问题更加困难。网络中的节点不能信任外部时间源或消息中出现的任何时间戳。例如，哈希图通过“中值”时间戳解决了这个问题。网络看到的每条消息都由网络的绝大多数人签名和时间戳。消息的时间戳中位数就是 Hashgraph 所说的“公平”排序。每条消息都必须传播到系统中的绝大多数节点，然后在消息收集到足够的签名后，整个集合需要传播到整个网络。正如您可以想象的那样，这确实很慢。
如果您可以简单地信任编码到消息中的时间戳怎么办？大量的分布式系统优化将突然可供您使用。例如。
同步时钟很有趣，因为它们可以用来提高分布式算法的性能。它们使得用本地计算取代通信成为可能。
— Liskov, B. 分布式系统中同步时钟的实际应用
在我们的例子中，这意味着高吞吐量、高性能的区块链
历史证明
如果您可以证明消息是在事件之前和之后的某个时间发生的，而不是信任时间戳，该怎么办？当您拍摄《纽约时报》封面的照片时，您正在创建一个证据，证明您的照片是在该报纸出版后拍摄的，或者您有某种方式影响《纽约时报》的出版内容。通过历史证明，您可以创建历史记录，证明事件在特定时刻发生。
历史证明是一种高频可验证延迟函数。可验证延迟函数需要特定数量的连续步骤来进行评估，但会产生可以有效且公开验证的独特输出。
我们的具体实现使用顺序原像抗散列，该散列连续地运行在自身上，并将先前的输出用作下一个输入。定期记录计数和当前输出。
对于 SHA256 哈希函数，如果不使用 2^2⁸ 核心进行强力攻击，则该过程不可能并行化。
然后我们可以确定每个计数器在生成时已经经过了实时时间，并且每个计数器记录的顺序与实时时的顺序相同。
时间上限
通过将数据的散列附加到先前生成的状态，可以将数据插入到序列中。状态、输入数据和计数均已发布。附加输入会导致所有未来的输出发生不可预测的变化。并行化仍然是不可能的，并且只要散列函数是原像和抗碰撞的，就不可能创建一个在未来生成所需散列的输入，或者创建具有相同散列的替代历史记录。我们可以证明任意两个追加操作之间经过的时间。我们可以证明数据是在附加之前的某个时间创建的。就像我们知道《纽约时报》上刊登的事件发生在报纸撰写之前。
时间下限
历史证明的输入可以引用历史证明本身。反向引用可以作为带有用户签名的签名消息的一部分插入，因此如果没有用户私钥就无法对其进行修改。这就像以《纽约时报》为背景拍照一样。因为此消息包含 0xdeadc0de 哈希值，所以我们知道它是在创建计数 510144806912 之后生成的。
但由于该消息也被插入回历史证明流中，就好像您以《纽约时报》为背景拍了一张照片，第二天《纽约时报》发布了这张照片。我们知道该照片的内容在特定日期之前和之后存在。
确认
虽然记录的序列只能在单个 CPU 内核上生成，但可以并行验证输出。
每个记录的切片都可以在单独的核心上从头到尾进行验证，所需时间仅为生成时间的 1/（核心数）。因此，具有 4000 个核心的现代 GPU 可以在 0.25 毫秒内验证一秒。
ASICS 亚瑟士
是不是每个 CPU 都不同，有些 CPU 比其他 CPU 快得多？您如何真正相信我们的 SHA256 循环生成的“时间”是准确的？
这个主题值得单独写一篇文章，但长话短说，我们不太关心某些 CPU 是否比其他 CPU 更快，以及 ASIC 是否可以比网络可用的 CPU 更快。最重要的是 ASIC 的速度是有限的。
我们正在使用 SHA256，并且感谢比特币，在使这种加密哈希函数变得更快方面进行了大量研究。该功能不可能通过使用更大的芯片区域（例如查找表）或在不影响时钟速度的情况下展开它来加速。 Intel 和 AMD 都发布了可以在 1.75 个周期内完成一轮 SHA256 的消费类芯片。
因此，我们非常确定定制 ASIC 的速度不会快 100 倍，更不用说 1000 倍了，而且很可能会在网络可用速度的 30% 以内。我们可以构建利用这个界限的协议，并且只允许攻击者有非常有限的、容易检测到的、短暂的拒绝服务攻击机会。下一篇文章将详细介绍这一点！