每个区块链网络，都有网络层、共识层、应用层的区分。每个区块链网络的特性不同，也有事因为在不同的分层里的设计思路不一样。本文中，我们将整理Solana网络的运行逻辑，可以通过这些资料了解到为什么Solana会在以太坊2.0还没上线的时候，会比以太坊好用。

以太坊的总帐本在1.0链上，是由矿工维护的，在2.0里，矿工变成验证者，验证者用计算设备建立验证器代替了原来的矿机。Solana也是通过验证者保护总帐本的，不过验证者的在形成共识的算法不太一样。通过下面的顺序，可以了解到共识形成的过程。

Solana集群

Solana集群是一组验证人，共同保持账本的完整性，存在多个集群。

创建集群

在启动任何验证节点之前，首先需要创建一个创世配置。创世配置会配置一个具备引导验证能力的节点，第二个验证节点可联系引导验证节点来注册为一个验证节点。然后，其他验证节点将在集群的任何已注册成员中继续注册。

验证节点会收到领导者的所有条目，并提交投票以确认这些条目的有效性。投票后，验证节点需要存储这些条目。不过一旦验证节点发现存在足够多的副本，它将删除自身的副本。

加入集群

验证节点通过发送到控制台（control plane）的注册消息进入集群。控制台使用八卦（gossip）协议实现，这意味着节点可以向任何现有节点注册，并期望其注册传播到集群中的所有节点。一个节点可以确保它最终拥有与每个其他节点相同的信息，但任何一个节点都无法审查该信息。所有节点同步所需的时间与参与群集节点数的平方成正比。

将交易发送到集群

客户端将交易发送到任何验证节点的交易处理单元(TPU)端口。如果该节点处于验证节点角色，则它将交易转发给指定的领导者。如果处于领导者角色，则该节点将传入的事务捆绑在一起，对其打上时间戳，来创建一个条目（entry），然后将其推送到集群的数据中心（dataplane）。进入数据中心后，交易将由验证节点进行验证，从而将交易有效地添加到账本中。

确认交易

Solana集群能够在亚秒级的时间内确认（confirmation）最多150个节点，并要计划扩展到成千上万个节点。一旦完全实施，确认时间预计只会随着验证节点数量的对数而增加，而对数的基数又很高。网络增长到一定规模后，就会变得太慢而无法实现亚秒级确认。将消息发送到所有节点所花费的时间与节点数的平方成正比。如果区块链想要获得低确认率并尝试使用网络来做到这一点，它将被迫集中到少数几个节点上。

所以可以使用以下技术组合来实现可扩展的确认：

使用VDF样本对交易打上时间戳并签名。将交易分为几批，将每笔交易发送到单独的节点，同时每个节点都与对等节点共享其批次。递归地重复上一步，直到所有节点都具有所有批次。

Solana以固定的时间间隔（称为插槽）轮换领导者。每个领导者只能在其分配的时段内产生条目。领导者因此对交易加上时间戳记，以便验证节点可以查找指定领导者的公钥。然后，领导者对时间戳进行签名，以便验证节点验证签名，证明签名者是指定领导者公钥的所有者。

接下来，将交易分成批处理，以便节点可以将交易发送给多方，而无需进行多份复制。例如，如果领导者需要将60笔交易发送到6个节点，则它将把60笔交易的集合分成10笔交易的批次，并向每个节点发送一个交易。这能够让领导者将60笔交易放在网络上，而不是每个节点60笔交易。接着，每个节点都与对等节点共享其批次。一旦节点收集了全部6个批次，它将重建60个交易的原始集合。

这种技术可以被称为（涡轮区块传播）Turbine Block Propogation。

同步

快速、可靠的同步是Solana实现超高吞吐量的最大原因。Solana采取了历史证明PoH算法。通过带有加密证明“时间戳”的领导节点证明自上次确认以来，确实已经过了一段时间。以证明所有哈希到证明中的数据肯定都是在证明之前发生的。然后该节点将新区块分享给验证节点，它们能够验证这些证据。

区块可以按照任何顺序甚至延迟好几年才传到验证节点那里。通过这种可靠的同步保证，Solana能够将区块分解成更小的批量交易，称为条目（entries）。在达成任何共识之前，条目都会实时传输给验证节点。

在技术的角度，Solana从来都没有发送区块，但是会使用这个词语来描述验证节点对条目进行投票，最终取得确认。这样，Solana的确认时间就可以达到800毫秒。在这个模式下，如果对某个事件无法达成共识，节点只需要简单地回滚其状态。

领导者轮换

每个验证节点使用同一种算法来选择预期的领导者。当验证节点收到一个新的签名账本条目时，可以肯定某条目是来自预期的领导者。分配给每位领导者的插槽顺序称为leader schedule（领导者安排表）。

一个验证节点会拒绝未经过插槽领导者签名的区块。所有插槽领导者的身份列表称为领导者安排表。领导者安排表是通过本地定期重新计算产生的。它指派插槽领导者持续一段称为epoch（纪元）的时间。安排表必须早于它分配的时间段，这样它保证了计算计划的账本状态最后能够确定。该持续时间称为领导者安排表偏移时间。Solana将偏移时间设置为直到下一个epoch的插槽持续时间。也就是说，一个epoch的领导者计划通过上一个epoch开始时的账本状态来计算得到。一个纪元的偏移量是比较随意的，并且假定时间足够长，使所有验证节点都将在生成下一个计划之前确定其账本状态。集群可以选择缩短偏移时间，来缩短质押变化与领导者计划更新之间的时间。

在没有分区的情况下运行时间比一个epoch长的时候，只有在根分叉的epoch边界才能生成安排表。由于安排表用于下一个纪元，因此在下一个纪元之前，任何质押给根分叉的新质押都不会被激活。用于生成领导者计划的区块是跨过纪元边界的第一个区块。

如果分区比一个epoch时间短，集群将按以下方式运作：

验证节点在投票时不断更新自己的根分叉。

每次在纪元边缘的插槽高度的时候，验证节点将更新其领导者安排表。

写在最后

正是因为对共识的改动，Solana出世的时候就以一个高性能公链的角色面对市场，其使用的类权益证明修改版PoH是在权益证明性能之上再次修订的，目标就是性能更高，这样做的目的也是即使以太坊2.0出现之后，网络仍旧有竞争力。

不过这种共识体现的竞争力是在应用上，而不是在本身技术攻坚上。在某些信仰纯粹的技术人员眼中，Solana可能有些过于中心化，只是在庞大的市场里，区块链网络面对不同受众，会体现出不同的优劣，也能得到不同的发展。