Solana扩容机制分析（2）：牺牲可用性换取高效率的极端尝试 | CatcherVC Research

 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世界不需要单纯的营销和高效率，只有真正具备可用性的事物，能够在历史洪流的冲刷中屹立不倒，永世长存。

『声明：本内容仅供区块链爱好者科普学习和交流，不构成投资意见或建议，请理性看待，树立正确的理念，提高风险意识』

参考文献

1.Solana白皮书中文版

2.Gulf Stream: Solana’s Mempool-less Transaction Forwarding Protocol

3.Turbine Block Propagation

4.Solana调研报告

5.Solana之旅

6.与币安钱包合作的高性能公链Solana是如何提速的？

7.Overclock blockchain to 710,000 transactions per second: a review of the Proof of History algorithm

8.Solana 的逆袭之路 - SQLANA

9.PoS和Tendermint共识讲解

10.以太坊源码分析：交易缓冲池txpool

11.以太坊交易池架构设计

12.PBFT基础流程

13.Tendermint-2-共识算法:Tendermint-BFT详解

14.Cardano（ADA）的共识算法Ouroboros

15.深度调查：新公链们为何频现宕机事故？

16.深度解读Optimism：基本架构、Gas机制与挑战 | CatcherVC Research

17.剖析新版Metis：Gas最低Layer2的去中心化进行时 |CatcherVC Research