Solana 扩容机制分析：牺牲可用性换取高效率的极端尝试

2022-06-09 13:21:54观点

Solana 以系统可用性为代价，将 Layer1 扩容的叙事推向了极端，基本触及无分片公链的 TPS 瓶颈。但多次宕机似乎预示了牺牲可用性换取效率的结局。

作者：eternal1997，CatcherVC

技术顾问：刘洋，《嵌入式系统安全》作者

封面：Solana

摘要

Solana 扩容主要基于：高效利用网络带宽、减少节点间通讯次数、加快节点运算速度 三大方面，这些措施直接缩短了出块和共识通讯的时间，但也降低了系统可用性（安全）。
Solana 提前公开出块者 Leader 名单，揭示了单一可信的数据来源，缩减了共识通讯开销。但又会带来贿赂、针对性攻击等安全隐患。
Solana 将共识通讯（投票信息）作为交易事件来处理，TPS 成分中超过 70% 都是共识讯息，与用户交易相关的 TPS 约为 500—1000；
Solana 的 Gulf Stream 机制取缔了全局性交易池，这提高了交易处理速度，但降低了过滤垃圾交易的效率，Leader 容易宕机。
Solana 的 Leader 节点发布的是交易序列，而非真实的区块。结合 Turbine 传输协议，交易序列可以切碎后分发给不同节点，数据同步速度极快。
POH（Proof Of History）实质为一种计时和计数方式，它给不同的交易事件盖上序号，生成交易序列。Leader 实质上在交易序列中发布了全网一致的计时器（时钟）。在很短的窗口期内，不同节点的账本推进、时间推移都是一致的；
Solana 有 132 个节点占据 67% 的质押份额，其中的 25 个节点占据 33% 的质押份额，基本构成了 “寡头政治” 或 “元老院”。如果这 25 个节点串谋，足以导致网络陷入混乱；
Solana 对节点硬件水准要求很高，它以设备成本为代价，实现了纵向扩容。运行 Solana 节点的个体多为鲸鱼或机构、企业，不利于真正意义的去中心化。
综上，Solana 以高级节点设备、颠覆性的共识机制与数据传输协议，将 Layer1 扩容推向了极端，基本触及无分片公链可维持的 TPS 瓶颈。但多次宕机已经预示了牺牲可用性/安全性来换取效率的结局。

导语

2021 年是区块链和 Crypto 的转折之年。随着 Web3 等概念成为显学，公链界迎来了有史以来最强劲的流量增长。在这样的外部环境下，以太坊凭借充分的去中心化和安全性，成为 Web3 世界的泰山北斗，但效率问题却成了它的 “阿喀琉斯之踵”。相比于 TPS 轻松破千的 VISA，每秒 10 几笔交易的以太坊宛若怀中襁褓，与其 “世界级去中心化应用平台” 的宏大愿景相差甚远。

对此，Solana、Avalanche、Fantom、Near 等以扩容为核心的新公链一度成为 Web3 叙事的主要角色，获得了巨量资本的垂青。仅以 Solana 为例，这个号称 “以太坊杀手” 的头部公链在 2021 年市值飙涨 170 倍，如日中天，甚至一度超越老牌公链 Polkadot 和 Cardano，大有和以太坊争雄的势头。

但在 2021 年 9 月 14 日，Solana 因为性能上的问题，首次迎来宕机事故，时间长达 17 小时，SOL 代币价格随之快速下跌 15%；2022 年 1 月，Solana 再次出现宕机，时长足有 30 小时，引发了极为广泛的讨论；之后的 5 月，Solana 先后宕机 2 次，6 月初又宕机 1 次。根据 Solana 官方的说法，其主网至少经历了 8 次性能下降或是宕机事故。

（链闻联创刘锋对 Solana 的评论）

伴随着诸多问题的出现，以太坊支持者为首的批评者轮番对 Solana 提出质疑，有人甚至给 Solana 冠以 “SQLana” 的称号（SQL 是管理中心化数据库的系统），并先后产生了大量的评论与分析。时至今日，关于 Solana 真实可用性的讨论似乎从未停止，吸引着无数好奇心浓重的观察者。出于对主流公链的兴趣与关注，CatcherVC 将从自身视角出发，在本文对 Solana 扩容机制及其宕机的部分原因展开简单解读。

Solana 系统架构、共识机制、区块传输流程

公链的效率主要指其处理交易的能力，也就是吞吐量 TPS（每秒处理的交易笔数），这个指标受到出块速度和区块容量的影响，同时也影响着交易手续费和用户活跃度。从 2018 年甚嚣尘上的 EOS，到近期发币的 Optimism，所有扩容方案几乎都绕不开 “加速出块” 这个最关键的要素。

要提升出块速度，往往要在出块流程上 “做手脚”，Solana 也不出其右。其扩容方式主要立足于 高效利用网络带宽、减少节点间通讯的次数、提高节点处理事务的速度 三大方面，这些措施直接缩短了出块和共识通讯的时间。Solana 的创始人 Anatoly Yakovenko 及其队友对每一个细节都进行了精心雕琢，以系统的可用性（安全）为代价，尽可能在效率上作出提升，基本达到了无分片公链的实际 TPS 极限，最终作出了 “有代价” 的创新。

相比于其他采用 POS 的公链，Solana 最大的创新点在于其独特的共识协议和网络节点通信方式，该共识协议基于 POS 和 PBFT（实用拜占庭容错），引入独创的 POH（Proof of History）作为推进区块链账本的机制，独树一帜的创建了自己的共识体系。

单从表现形式的角度看，Solana 的共识协议与 Cardano 最早的 Ouroboros（衔尾蛇）算法类似，都包含 Epoch（纪元）和 Slot（间隔）两大时间单位。每个 Slot 约为 0.4~0.8 秒，相当于一个区块的时间间隔。而每个 Epoch 周期包含 43.2 万个 Slot（区块），长达 2~4 天。

在 Solana 的系统架构中，最重要的角色分为两类：Leader（出块者）和 Validator（验证者）。两者实际上都是质押了 SOL 代币的全节点，只是在不同的 Slot（出块周期）内，Leader 会由不同的全节点来充当，而没有当选 Leader 的全节点会成为 Validator。

在每个新的 Epoch 周期开始时，Solana 网络会按照各节点的质押权重进行抽选，组成一个出块者 Leader 轮换名单，“钦定” 了未来不同时刻的出块者。在整个 Epoch（2~4 天）内，出块者会按照名单指定的次序进行轮换，每过 4 个 Slot（出块周期），Leader 节点就会进行一次变更。

由于提前公开了未来的出块节点，Solana 网络实质获得了确定而可信的新区块数据源，为共识过程提供了巨大便利。

Solana 出块流程简述

为了更清晰的理解 Solana 的扩容机制，我们不妨从出块逻辑开始，对 Solana 的大致结构进行解析：

1. 用户发起交易后，会被客户端直接转发给 Leader 节点，或者先被普通节点接收，再立刻转发给 Leader；

2. 出块者 Leader 接收网络内全部的待处理交易，一边执行，一边给交易指令排序，制成交易序列（类似区块）。每隔一段时间，Leader 会把排好的交易序列发送给 Validator 验证节点；

3.Validator 按照交易序列（区块）给定的顺序执行交易，产生相应的状态信息 State（执行交易会改变节点的状态，比如改变某些账户的余额）；

4. 每发送 N 个交易序列，Leader 会定期公开本地的状态 State，Validator 会将其与自己的 State 作对比，给出肯定/否定的投票。这一步就类似于以太坊 2.0 或其他 POS 公链里的 “检查点”。

5. 如果在规定时间内，Leader 收集到占全网 2/3 质押权重 的节点们给出的肯定票，则此前发布的交易序列和状态 State 就被敲定，“检查点” 通过，相当于区块完成最终确认 Finality；

6. 一般而言，给出肯定票的 Validator 节点与出块者 Leader 所执行的交易、执行后的状态都是相同的，数据会同步。

7. 每过 4 个 Slot 周期，Leader 会进行一次切换，这意味着 Leader 每次大概有 1.6 秒~3.2 秒时间掌握网络的 “最高话语权”。

Solana 扩容机制细解

表面看来，Solana 的出块逻辑与其他采用 POS 机制的公链大体一致，都有一个发布区块、对区块投票的过程。但如果我们对每一个步骤都展开观察，不难发现 Solana 与其他公链之间有着天壤之别，而这正是其高 TPS、低可用性的根源所在：

1. 最重要的一点：Solana 提前公开每个周期 Slot 的出块者 Leader，大幅减少了共识过程的工作量。在其他 POS 公链中，由于缺乏单一的、可信的出块节点，网络的共识通讯效率极低，产生的时间复杂度往往比 Solana 高出几个数量级，这成为了多数公链在 TPS 上的瓶颈。

以主流的 POS 共识协议或 PBFT 算法为例，这些算法大多采用了和 Solana 相同的时间单位与角色划分，也有类似于 Epoch 纪元、Slot 区块周期、Leader 出块者、Validator 验证者、Vote 投票 的设定，只是参数设置和叫法不同而已。最大的不同在于，此类算法大多以安全性（可用性）为前提，不会提前公开 Leader 名单。

（比如 Cardano 也会事先生成一个 Leader 轮换列表，但列表不公开。每个选中的 Leader 只知道自己该在何时出块，不知道其他时刻的出块者是谁。这使得出块节点不可被外界预测。）

由于没有公开的出块者，节点间会 “互不信任”并 “各自为政”。此时，若某个节点自称为合法出块者，大家并不敢信任他，必须要其出示相关的 Proof 证明才行。但此类 Proof 证明的生成、传播、验证会浪费带宽资源，并产生额外的工作量（甚至会和 ZK 零知识证明扯上关系）。Solana 公开每个时段的 Leader，可以避免此类麻烦。

更为重要的是，在绝大多数 POS 共识协议或 PBFT 类算法中，针对新区块的投票 Vote（一个区块要得到网络内 2/3 节点的肯定票才能敲定），往往由各个节点通过 “流言协议”，以类似 1 对 1 交流的方式发送或收集，有点类似于病毒式随机扩散，实质等价于每两个节点间都要通讯一次，其复杂度和耗时远高于 Solana 的共识协议。

在 Tendermint 等 PBFT 算法中，单个 Validator 节点至少要收集网络内 2/3 的节点发出的单张投票。如果全网节点数量为 N，则每个节点至少接收 2/3×N 个投票，整个网络产生的通讯次数至少为 2/3×N²，显然这个数量级太大了（和 N 的平方成正比）。如果节点数量很多，其共识过程的耗时往往会陡增。

*（普通公链里单个节点投票的传播方式，类似过程每个节点都会做 1 次，每次出块要进行 N 次类似的传播）*

（相关科普：《雪崩 DEX 开发者为你详解 Avalanche 共识机制》）

对此，Solana 和 Avalanche 以不同的方式改良了节点收集投票的通讯过程，降低了时间复杂度。通俗的讲，Leader 集中汇总所有 Validator 发出的投票，再把这些投票打包在一起（写进交易序列里），一次性推送到网络中。

这样一来，节点们无需再通过 “流言协议” 频繁的、1 个 1 个的互换投票信息，通讯次数降低到了常数 N 甚至是 logN 的数量级，这在很大程度上缩短了出块时间，大幅提高了 TPS。

目前 Solana 出块周期基本和单个 Slot 的时长一致，为 0.4~0.8 秒，甚至比 Avalanche 还快出 3 倍。（Solana 浏览器显示的区块，实质是每个 Slot 内 Leader 发布的交易序列）。

但这也带来了另一个问题：由 Leader 在交易序列（区块）内发布节点们的投票信息，会占用区块空间。在 Solana 的设定中，Leader 实质将共识投票作为一种交易事件来处理，其发布的交易序列包含节点投票 Vote，而这些投票正是 Solana TPS 的主要成分（一般占 70% 以上）。

按照 Solana 浏览器里的数据统计，其实际 TPS 维持在 2000~3000 左右，其中 70% 以上是与普通用户无关的共识投票讯息，与用户交易相关的实际 TPS 维持在 500~1000，虽然比 BSC 和 Polygon、EOS 等高性能公链还高出 1 个量级，但仍无法达到官方所鼓吹的上万级别。

同时，如果 Solana 未来不断的提升去中心化程度，允许更多的节点参与共识投票（目前有近 2000 个 Validator），则 Leader 发布的交易序列中必将包含更多的投票讯息，会持续压缩与用户交易相关的 TPS 空间。这标志着 Solana 在不分片的前提下，基本难以取得更高的 TPS。

某种程度来看，Solana 每秒 500~1000 笔的交易处理能力已达到无分片公链的巅峰，在节点数量较多、不分片且支持智能合约的前提下，新公链基本难以超越 Solana 的 TPS 量级，除非它们采用 “委员会” 模式，只允许少量节点参与共识，或者退化为中心化服务器。只要参与共识的节点数量很多，就难以取得比 Solana 更高的 “可证实的 TPS”。

格外值得注意的是，由于每个 Epoch 内 （2~4 天）的出块者名单是提前公开的，Solana 的共识协议与原始的 Tendermint 算法并无本质区别，实际都没有赋予出块者以不可预测性，所有人都能预知未来某个时间点由谁来出块，这就会在 可用性/安全性上产生诸多隐患。
（Leader 易遭遇有预谋的 DDOS 攻击，提高了故障率，若连续几个 Leader 出现故障，则网络容易宕机；且用户可提前贿赂 Leader 等）

2.Gulf Stream 与网络宕机：Solana 公开出块者 Leader 名单还有一个更重要的目的：配合其独创的 Gulf Stream（海湾流）机制，提高网络处理交易的速度。

用户发起交易后，往往被客户端程序直接转发给指定的 Leader，或者先被某个普通节点接收，再被该节点快速发送给 Leader。这种方式可以让 Leader 尽快接收交易请求，提高响应速度。（称为 Gulf Stream 机制，是 Solana 宕机的主因之一）

Solana 的这种设定，是与其他公链截然不同的交易提交方式。Gulf Stream 取缔了比特币和以太坊的 “全局交易池” 设定，普通节点不运行大容量的交易池。一个节点收到用户的待处理交易后，只需交给 Leader，不必再发给其他节点，这种做法大幅提高了效率，但由于取缔了交易池，普通节点无法高效拦截垃圾交易，容易导致 Leader 节点宕机。

为了深刻理解这一点，我们可以对比 ETH：
·以太坊的每个全节点都有名为交易池（内存池）的存储区域，用于存放未上链、待处理的交易指令。

·当节点接收到新的交易请求后，会先进行过滤，判断交易指令是否合规（是否为重复/垃圾交易），之后将其存入交易池，再转发给其他节点（病毒式扩散）。

·最终，一笔合法的待处理交易会传遍网络，放入所有节点的交易池里，这就让不同节点都获取到相同的数据，表现出 “一致性”。

以太坊和比特币采取这种机制，理由很明确：不知道未来的出块者是谁，所有人都有概率打包新区块。所以，必须让不同节点接收到相同的待处理交易，为打包区块做准备。

如果有矿池节点发布新区块，接收区块的节点会解析其中的交易序列，按次序执行，再把这部分交易指令从交易池中清掉。至此，一批待处理的交易就可以上链。

Solana 取缔了以太坊的那种交易池，待处理的交易无需在网络内随机扩散，而被快速提交给指定的 Leader，再打包成交易序列一次性分发出去（类似于前文的分发投票的方式）。最终，一笔交易只需要夹在交易序列里，在网络内传播 1 圈（以太坊实际是 2 圈）。在交易数量很大的情况下，这个细微差别可以大幅提高传播效率。

但根据交易池 TxPool 的相关技术说明，交易池/内存池实质发挥了数据缓冲区和过滤器的作用，能提升公链可用性。所有节点都运行交易池，收录网络内全部待处理交易，不同节点就可以独立过滤垃圾请求，第一时间拦截重复交易，分担流量压力。虽然采用交易池会放慢出块速度，但如果有用户发起重复交易（交易池里有记录的请求），或其他类型的垃圾请求，接收到交易的节点可在本地将其过滤，不会再转发出去，这就让过滤工作被全网节点分担开。

Solana 采取了背道而驰的做法。在 Gulf Stream 机制下，普通节点们不运营全网一致的交易池，无法高效拦截重复/垃圾交易。普通节点真正能做的，只是检查交易数据包是否符合正确格式，无力辨别恶意重复请求。同时，由于普通节点 “一股脑” 的把交易指令推给 Leader，相当于把过滤交易的 “重担” 甩给了 Leader 自己，在流量极大、重复交易数量极多的情况下，Leader 节点会因压力过大而无法顺利出块，共识投票将无法顺利传播，网络容易崩溃。

对此，Solana 创始人 Anatoly Yakovenko 于今年 1 月 27 日表示，某些热门项目的公售时段，每秒最多有近 200 万笔交易请求到达同一个 Leader 节点，其中 90% 以上是完全相同的重复交易，最终导致 Solana 宕机。
（参考资料：《深度调查：新公链们为何频现宕机事故？》）

综上所述，以太坊实质是牺牲效率换安全，Solana 则是牺牲安全换效率，它所面临的问题可归纳为：
由于 Leader 轮换顺序是给定的，必须按照这个轮换链条不断的走下去。但由于流量分担机制不完善，Leader 节点故障几率较高，如果某段时间内用户流量过大（如某些火热 NFT 开启公售），可能使多个 Leader 先后出现故障（比如未来 40 个 Slot 的 Leader 都不能顺利出块），这样一来，共识过程受阻，网络会分叉、Leader 轮换链条会彻底断裂，最终会彻底崩溃。

3. 类似 BT 种子的 Turbine 传输协议：在上文的 Gulf Stream 机制配合下，Leader 迅速接收一段时间内的全部交易请求，检查其合法性，之后会执行交易。同时，Leader 采用称为 POH（Proof of History）的机制，为每笔交易都盖上一个序列号，为交易事件排序。（细节将于后文阐述）

Leader 把交易事件排好序后，会把交易序列切成 X 个不同的碎片，分别发送给质押资产最多的 X 个 Validator，再由他们传播给其他 Validator。Validator 群体会自行交换收到的碎片，在本地拼凑完整的交易序列（区块）。

为了便于理解，我们可以将每个不同的碎片视作数据量缩减的小区块。Leader 一次对外分发 X 个碎片，相当于发出 X 个不同的小区块，让不同的节点接收并进一步扩散。

Solana 的这种消息分发方式很特别，灵感来自于 BT 种子。（原理不易用文字表述，主旨在于同时利用多个节点的闲置带宽，并行式的传输数据）。一般而言，交易序列被切分的碎片数越多，节点群体扩散碎片、拼凑交易序列的速度越快，数据同步效率也会显著提升。

而在其他公链中，出块者会向 X 个邻居节点发送相同的区块，相当于把一个区块复制 X 份发出去，而非分发 X 个不同的碎片（小区块），这种做法产生的数据冗余和带宽浪费很严重。究其根源，传统的区块 Block 式结构不可切分，根本无法灵活传输，而 Solana 干脆以交易序列 Sequence 替代区块式结构，结合类似 BT 种子的 Turbine 协议，可以实现高速的数据分发，极大提升了吞吐量 TPS。

Solana 官方曾表示，在 Turbine 传输协议下，网络有 4 万个节点时，可以在 0.5 秒内把一个交易序列同步给所有节点。

同时，在 Turbine 协议下，节点按照其质押资产的权重，被划分为不同的层级（优先级），质押资产多的 Validator 率先收到 Leader 发出的数据，之后由这些节点传递给下一层。在这种机制下，占全网质押资产 2/3 权重的节点群体，会最先收录 Leader 发出的交易序列，加快账本（区块）的确认速度。

根据 Solana 浏览器披露的数据，目前 2/3 的质押权重被 132 个节点瓜分，再结合前文所说的传播机制，这些节点最先收到 Leader 发出的交易序列，也会率先给出投票。而只要得到这 132 个节点的投票，Leader 发布的交易序列便可敲定。从某种角度看，这些节点抢跑在其他节点之前，如果他们串谋，便可产生某些作恶场景。

更值得注意的是，目前 Solana 有 25 个节点占据了 1/3 的质押权重，按照拜占庭容错理论，只要这 25 个节点集体串谋（比如故意不向某个 Leader 发出投票），足以让 Solana 网络陷入混乱。某种程度来讲，Solana 面临的 “寡头政治” 问题是所有采用 POS 投票制的公链都应该去重视的。

4.POH（Proof Of History）：前文提到，Turbine 协议允许 Leader 将交易序列切碎，把不同的碎片发布出去。这种做法要有一个保障：交易序列被切碎后，要容易被拼凑复原。为了解决这个问题，Solana 特意在数据包中掺杂纠删码（可防止数据丢失），并且引入独创的 POH（Proof Of History）机制为交易事件排序。

在 Solana 白皮书中，Yakovenko 以哈希函数 SHA256 为案例，展示了 POH 的原理。为了便于理解，本文将以下面的例子解释 POH 机制：

（由于 POH 及对应的时间演进逻辑较难用语言描述，建议先阅读 Solana 中文白皮书对 POH 的解读，再将本文以下桥段作为辅助阅读）

·SHA256 函数的输入值和输出值是唯一映射的（1 对 1），输入参数 X 后，仅有唯一的输出结果 SHA256（X）=？；不同的 X 会得到不同的？=SHA256（X）；

·如果循环、递归的计算 SHA256，比如：
定义 X2 = SHA256 ( X1 )，再用 X2 计算 X3 = SHA256 (X2)，再算 X4 = SHA256 (X3)，如此重复迭代下去，Xn = SHA256 ( X[n-1] )；

·反复执行这个过程，最终我们会得到一个 X1，X2，X3......Xn 的序列，该序列有个特点：Xn = SHA256 ( X[n-1] )，排在后面的 Xn 是前面 X[n-1] 的 “后代”。

·将该序列公开发布后，如果有外人想验证序列的正确性，比如他想判断 Xn 是否真的是 X[n-1] 的 “合法后代”，可以直接将 X[n-1] 代入 SHA256 函数去算，看结果和 Xn 是否相同。

·在这种模式下，没有 X1 就得不到 X2，没有 X2 得不到 X3...... 没有 Xn 得不到后面的 X[n+1]。这样一来，序列就具有了连续性和唯一性。

·最关键的一点：交易事件可以被插进序列里。比如：
在 x3 出生后、x4 未出现时，交易事件 T1 可作为外部输入，和 X3 迭加在一起，得到 x4 = SHA256（X3+T1）。其中，X3 的出现略早于 T1，X4 则为（T1+X3）孕育的后代，T1 实质被夹在 X3 和 X4 的 “生日” 之间。

以此类推，T2 可以在 X8 产生后，作为外界的输入参数，计算 X9=SHA256（T2+X8），这样 T2 的出现时间就被夹在 x8 和 x9 的 “生日” 之间；

•在上面的场景中，实际的 POH 序列为以下形式：

其中，交易事件 T1 和 T2 是外界插入序列里的数据，在 POH 序列的时间记录上，他晚于 X3 早于 X4。
只要给出 T1 在 POH 序列里的次序号，可得知它之前发生了多少次 SHA256 计算（T1 前面有 X1、X2、X3，发生了 3 次 SHA256 计算）。
同样的道理，T2 前面有 X1~X8 八个 X，发生了 8 次计算。

以上过程的白话解释如下：有个人拿着秒表在那里数秒，每当他收到一封信，他就按照秒表的读数，在信封上记下时间。收到十封信后，这十封信上记录的秒数肯定不同，有先后区分，这就给不同的信件排了序，根据信件上的记录还可以知道两封信之间隔多久。

·Leader 在对外发布交易序列时，只要在 T1 的数据包里给出 X3 的数值，并告知 X3 的序号（第 3 个），接收数据包的 Validator 便可解析出 T1 之前的完整 POH 序列；
只要在 T2 的数据包里，提供 X8 的数值，及其序号 8，Validator 便可解析出 T2 之前的完整 POH 序列；

·按照 POH 的设定，只要标记出每笔交易在 POH 序列里的序号（Counter），并给出紧挨着它的 X 值（Last Valid Hash），就可以披露出每笔交易的次序。由于 SHA256 函数本身的特性，这种通过哈希计算来敲定的次序，难以被篡改。

同时，Validator 知道 Leader 得出 POH 序列的方式，他们可以执行相同的操作，还原出完整的 POH 序列，验证 Leader 发布的数据的正确性。

For example，如果 Leader 发布的交易序列数据包为：
T1，序号 3，紧邻 X3；
T2，序号 5，紧邻 X5；
T3，序号 8，紧邻 X8；
T4，序号 10，紧邻 X10；
POH 序列初始值 X1；

Validator 接收到以上数据包后，便可把 X1 作为初始参数，循环代入 SHA256 函数自行计算，解析出完整的 POH 序列为：

这样一来，只要知道序列里总共包含多少个 X，就可得知计算者做了几次 SHA256 计算。事先估计好每次哈希计算的耗时，就可以知道不同交易的时间间隔（比如 T1 和 T2 之间隔了 2 个 x，就隔着 2 次 SHA256 计算，约为？？毫秒）。得知了不同交易之间相隔的秒数后，可以更方便的确定每笔交易发生的时间点，省去了很多麻烦的工作。

·一般而言，Leader 会时刻不停的执行 SHA256 函数，得到新的 X，把序列不断向前推进。如果有交易事件，就将其作为外部输入，插进序列里；

·如果有节点尝试在网络中发布掺水的序列，替换 Leader 发布的版本，比如把上文中的 X2 替换为 X2’ ，序列变为 X1，X2’，X3......Xn，显然其他人只要对比 X3 和 SHA256（X2’）, 就可以发现两者对不上号，序列造假了。
所以，造假者必须把 X2’ 之后的 X 全部替换才行，但这样做成本很高，尤其在 X 的个数很庞大的情况下，造假将非常浪费时间。此情此景，最好的办法就是不去造假，收到了 Leader 发出的序列后原方不动的转发给别的节点。
再考虑到 Leader 会在发布的每个数据包里加上自己的数字签名，在网络内传播的序列其实是 “唯一的”“难以被篡改的”；

5. 全网一致的时间推进：Solana 的创始人 Yakovenko 曾强调，POH 最大的作用是提供了一个 “全局一致的单一时钟”（其实应该转译为：全网一致的时间推进）
。这句话其实可以这样理解：
Leader 节点在网络内发布了一个唯一的、难以篡改的交易序列。根据该交易序列的数据包，节点可以解析出完整的 POH 序列，而 POH 序列是 Solana 独创的计时方式，可以作为时间参照物。

如前文所述，由于 Leader 会时刻不停的执行 SHA256 哈希计算，把 POH 序列不断向前推进，这个序列记录了 N 次哈希计算的结果，对应着 N 次计算过程，包含了时间推移。而 Solana 把计算的次数当做独特的计时方式。

在原始的参数设定中，默认 200 万次哈希计算对应现实中 1 秒，每个 Slot 出块周期为 400 ms，也就是说每个 Slot 产生的 POH 序列包含 80 万次哈希计算。Solana 还创造了一个名为 Tick（滴答）的名词，类比钟表指针前进时的滴答声。按照设定，每个 Tick 应该包含 1.25 万次哈希计算，1 个 Slot 周期包含 64 次 Tick，每 160 次 Tick 对应现实中 1 秒。

以上只是理想状态下的设定，在实际的运行过程中，每秒可产生的哈希计算次数往往不固定，所以实际的参数应该是动态调整的。但以上说明可以解释 POH 机制的大致逻辑，这种设计让 Solana 节点在收到 POH 序列后，根据其中包含的哈希计算次数，判断 1 个 Slot 是否结束，以及是否到了下一个 Leader 该出现的时候（4 个 Slot 一轮换）。

由于可以判断每个 Slot 的起始点，Validator 会把起始点中间夹着的交易序列划分为一个区块。一旦得到敲定，就相当于把账本向前推进了一个区块，系统则向前推移了一个 Slot。

这就可以用一句话概括：
“时钟的指针不会回头，但我们可以用自己的手把它向前推”。—碇源渡《新世纪福音战士 EVA》

换言之，只要节点都收到相同的交易序列，那么他们解析出的 POH 序列，及对应的时间推进都是一致的。这就创造了一个 “全局一致的单一时钟”（全网一致的时间推进）。

（在原始的 Tendermint 算法中，每个节点在本地的账本上添加的是相同的区块，区块高度一致，几乎从不分叉，所以按照 Solana 对 “时间推移” 的解释，在 Tendermint 中，不同节点的时间推移应该也是一致的）

此外，由于交易事件在 POH 序列中的序号是给定的，节点仅凭自己计算就可获知，不同的交易之间隔了多少次哈希计算（隔着几个 X），也就能大致估算出不同交易之间的时间差△T。

有了大致的△T 和某个初始的时间戳 TimeStamp 0 后，就可以像多米诺骨牌一样，粗略估算每起事件的发生时刻（时间戳）。
For example：
T1 发生于 01:27:01，T2 与 T1 之间隔着 1 万次哈希计算（1 万个 X），如果 1 万次哈希计算耗时约为 1 秒，则 T2 大概发生在 T1 的 1 秒后，也就是 01:27:02。以此类推，所有交易事件发生的时间（时间戳）都可以粗略推算出来，这带来了巨大便利，允许节点独立确认某些数据的送达时间。

同时，POH 机制也方便统计各节点给出投票的时间点。Solana 白皮书中提出，Validator 应该在 Leader 每次发布 State 状态信息后的 0.5 秒内提供投票。

如果 0.5 秒对应着 100 万次哈希计算（前文的 100 万个 X），而 Leader 发布 State 后，后面的序列里连续 100 万次哈希计算都没有收录进某节点的投票，大家就可以得知这个节点在偷懒，没有在规定时间内履行投票的义务，届时系统可以执行相应的惩罚措施 （Tower BFT）。

6. 与 Optimism 的相似性：以上即为 Solana 独创的 POH（Proof Of History），类似于 Optimism 和 Arbitrum 的交易排序形式，都通过与哈希函数有关的计算，来确立一个 “不可篡改、唯一确定” 的交易事件序列，之后由 Leader/Sequencer 将这个序列发布给验证节点 Validator/Verifier。

在 Optimism 中也有类似 Leader 的角色，叫 Sequencer（排序器），它在数据传输中也取缔了区块式结构，定期在以太坊某合约地址中发布交易序列，叫 Validator 自己去读取并执行。不同的 Validator 收到的交易序列都是相同的，那么他们执行下来后得到的状态 State 也必定相同。这个时候再去对比 Sequencer 的状态 State，各个 Validator 自己就能验证其正确性，几乎不需要和其他节点沟通。

在 Optimism 的共识机制中，并没有要求不同 Validator 之间进行互动，也没有收集投票的步骤，“共识” 其实是隐式的。如果有 Validator 执行完交易序列后，发现 Sequencer/Leader 提供的状态信息 State 不对，就可以发起 “挑战”，质疑 Sequencer/Leader。但在这种模式下，Optimism 为交易事件提供了 7 天的敲定窗口期，Sequencer 发布交易序列后，需要 7 天无人质疑，才能最终确认，这显然是 Soalna 无法接受的。

Solana 要求 Validator 尽快给出投票，目的在于让网络快速达成共识，快速敲定交易序列，这样可以比 Optimism 具备更高的效率。

此外，Solana 分发和验证交易序列的方式更灵活，允许将一个序列切碎，以碎片的形式分发，这为 Turbine 协议的实行创造了完美的土壤；

同时，Solana 允许节点同时运行多个计算部件，并行式的验证不同碎片的正确性，把验证工作分担开，大幅节约时间。在 OP 和 Arbitrum 中则不允许这种做法，Optimism 直接以 1 笔交易对应 1 个执行后状态 State 的方式，通过 Transcation—State 映射的形式给出交易序列，只能由一个 CPU 核心从头到尾一步一步的去计算一遍，才能验证整个序列的正确性，相对而言笨重低效很多。Solana 的 POH 序列可以从任意一个位置开始验证，多个计算单元可以同时验证不同的 POH 片段，这就为多线程并行式的验证模式提供了基础。

7. 针对节点本身的纵向扩容：以上是 Solana 在出块流程、共识机制和数据传输协议上的改良，除此之外，Solana 还创建了名为 Sealevel 和 Pipeline、 Cloudbreak 的机制，支持多线程、并行、并发的执行模式，并支持以 GPU 来作为执行计算的部件，大幅提高了节点处理指令的速度，优化了硬件资源的利用效率，属于纵向扩容的范畴。由于相关技术细节较为复杂，且与本文的侧重点并无关联，在此不展开赘述。

虽然 Solana 的纵向扩容大幅提升了节点设备处理交易指令的速度，但也抬高了对硬件配置的要求。目前 Solana 的节点配置要求很高，被许多人评为 “企业级硬件水平”，并被斥责为 “节点设备最昂贵的公链”。

以下为 Solana 的 Validator 节点硬件要求：
Cpu 12 或 24 核，内存至少 128 GB，硬盘 2T SSD，网络带宽至少达到 300 MB/s，一般为 1GB/s。
再对比当前以太坊节点的硬件要求（转型 POS 前）：
CPU 4 核以上，内存至少 16 GB，硬盘 0.5 T SSD，网络带宽至少 25 MB/s。

考虑到以太坊转型 POS 后节点硬件配置要求会调低，Solana 对节点硬件的要求远远高于前者。根据部分说法，一个 Solana 节点的硬件成本，相当于几百个转型 POS 后的以太坊节点。由于节点运行成本过高，Solana 网络的运行工作很大程度上成为了鲸鱼和专业机构、企业的专利。

对此，以太坊前 CTO、Polkadot 创始人 Gavin Wood 曾在去年 Solana 首次宕机后评论称：真正的去中心化和安全性比高效率更有价值。如果用户不能自己运行网络的全节点，那么这样的项目将和传统银行毫无区别。

全文总结

Solana 扩容主要基于：高效利用网络带宽、减少节点间通讯次数、加快节点处理事务的速度三大方面，这些措施直接缩短了出块和共识通讯的时间，但也降低了系统可用性（安全）。
Solana 提前公开每个出块周期 Slot 内的出块者 Leader 名单，实质揭示了单一可信的数据来源，借此大幅精简了共识通讯的流程。但公开 Leader 信息会带来贿赂、针对性攻击等潜在安全隐患。
Solana 将共识通讯（投票信息）作为一种交易事件来处理，TPS 成分中往往超过 70% 都是共识讯息，真实与用户交易相关的 TPS 约为 500—1000；
Solana 的 Gulf Stream 机制实质取缔了全局性交易池，虽然这提高了交易处理速度，但普通节点无法高效拦截垃圾交易，Leader 会面临巨大压力，容易致使其宕机。若 Leader 宕机，则共识讯息无法正常发布，网络容易分叉甚至崩溃；
Solana 的 Leader 节点发布的是交易序列，而非真实的区块。结合 Turbine 传输协议，交易序列可以被切碎后分发给不同节点，最终的数据同步速度极快。
POH（Proof Of History）实质为一种计时和计数方式，它可以给不同的交易事件盖上不可篡改的序号，生成交易序列。同时，由于同一时间只有单一的 Leader 发布交易序列，其中蕴含 POH 计时序列，Leader 实质上发布了全网一致的计时器（时钟）。在一个很短的窗口期内，不同节点的账本推进、时间推移都是一致的；
Solana 有 132 个节点占据 67% 的质押份额，其中的 25 个节点占据 33% 的质押份额，基本构成了 “寡头政治” 或 “元老院”。如果这 25 个节点串谋，足以导致网络陷入混乱；
Solana 对节点硬件水准要求较高，它在抬高设备成本的基础上，实现了纵向扩容。但这也致使运行 Solana 节点的个体多为鲸鱼或机构、企业，不利于真正意义的去中心化。

从某种角度来看，Solana 实际成为了公链中最特立独行的存在，它以高级的节点硬件水准、颠覆性的共识机制与网络传输协议，将 Layer1 扩容的叙事推向了极端，基本触及了无分片公链可长期维持的 TPS 瓶颈，但 Solana 的多次宕机，似乎已经说明了牺牲可用性/安全性来换取效率的最终结局。

从长远看，去中心化和安全性始终是公链领域的核心叙事，虽然 Solana 靠着一时的 TPS 数值与 SBF 等金融大鳄的推波助澜，一度成为资本簇拥下的瑰宝，但 EOS 的结局已经昭示，Web3 世界不需要单纯的营销和高效率，只有真正具备可用性的事物，能够在历史洪流的冲刷中屹立不倒，永世长存。

（在此特别感谢《嵌入式系统安全》的作者刘洋先生、Rebase 社区及 W3.Hitchhiker 团队对本文作者的帮助）