4.5 KiB
| title |
|---|
| 同步 |
快速、可靠的同步是 Solana 实现超高吞吐量的最大原因。 同步到包含大量交易的传统区块链被称为区块。 通过在区块上同步，某笔交易只能在一个被称为“区块时间”的时间范围内完成。 工作量证明共识的区块时间通常非常大 ~10分钟 才能最大限度地减少多个验证节点同时生成一个新有效区块的概率。 权益证明共识则不存在这样的限制，但它缺乏可靠的时间戳，验证节点无法决定进入区块的顺序。 最常见的做法是通过 挂钟时间戳 来标记每个区块。 由于时钟偏差和网络延迟的波动，时间戳只能保持一两小时的准确性。 要是该系统顺利运行，它们会增长区块时间，以便合理地确定每个区块上的中位时间戳总在不断增加。
Solana 采取了非常独特的做法，称为 历史证明 或 PoH。 带有加密证明“时间戳”的领导节点能够证明自上次确认以来，确实已经过了一段时间。 所有哈希到证明中的数据肯定都是在证明之前发生的。 然后该节点将新区块分享给验证节点，它们能够验证这些证据。 区块可以按照任何顺序甚至延迟好几年才传到验证节点那里。 通过这种可靠的同步保证，Solana 能够将区块分解成更小的批量交易，称为 条目（entries）。 在达成任何共识之前，条目都会实时传输给验证节点。
在技术的角度，Solana 从来都没有发送 区块， 但是会使用这个词语来描述验证节点对条目进行投票，最终取得 确认。 这样，Solana 的确认时间就可以达到媲美两天苹果设备之间传输的速度。 当前的实现区块时间为 800 毫秒。
在这个模式下，条目很快就能传输到验证节点，因为领导节点可以将一组有效的交易归入条目。 验证节点早在投票其有效性之前就处理了这些条目。 以乐观的方式处理交易， 从收到最后一个条目到节点可以投票的期间，实际上不存在延迟。 如果对某个事件 无法 达成共识，节点只需要简单地回滚其状态。 这种优化处理技术早在 1981 年就发明了，被称为 Optimistic Concurrency Control（最优同值控制）。 它也可以应用到区块链结构中，其中一个集群对代表整个账本的哈希进行投票，直到达到某个 区块高度。 Solana 通过使用最后一个条目的 PoH 哈希来轻松实现这一点。
与 VDF 的关系
Solana 在 2017 年 11 月首次介绍了历史证明技术在区块链中的使用。 次年 6 月， 斯坦福阐述了类似的技术，称为 verifiable delay function（可验证延迟函数） 或简称为 VDF。
VDF 的一个优势是验证所需时间非常短。 Solana 验证其延迟函数的方法它与创建所需的时间成正比。 拆分超过 4000 个核心 GPU，它足以满足 Solana 的性能需要，但如果您请教上述论文的作者，他们可能会跟说 Solana 的方法在算法上很慢 [因此](https://github.com/solana-labs/solana/issues/388)，不应该叫作 VDF。 我们的观点是 VDF 一词应当指可证明的延迟方程，而不一定要满足某些性能特征。 在这个问题解决之前，Solana 很可能会继续在其特定的应用程序 VDF 使用 PoH 一词。
PoH 与 VDF 之间的另一个区别是，VDF 仅用于跟踪时间。 另一方面，PoH 的哈希区块链包括应用程序观察到的任何数据的哈希部分。 这些数据是一把双刃剑。 一方面，数据提供了“证明历史”――数据在哈希之后肯定是存在的。 另一方面，这意味着当数据被哈希的_时候_，应用程序可以通过更改它来操纵区块链。 因此，PoH 区块链并不是一个很好的随机数来源，但是没有这种数据的 VDF 却非常合适。 例如，Solana 的 领导人轮换算法，只来源于 VDF 高度 ，而不是该高度的哈希值。
与共识机制的关系
历史证明不是一个共识机制，它用于改进 Solana 权益证明共识的性能。 它还用于改进数据平面协议的性能。