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 次性能下降或是宕机事故。

image

(链闻联创刘锋对 Solana 的评论)

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

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

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

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

相比于其他采用 POS 的公链,Solana 最大的创新点在于其独特的共识协议网络节点通信方式,该共识协议基于 POSPBFT(实用拜占庭容错),引入独创的 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 节点就会进行一次变更。

image
(Solana 第 313 个 Epoch 出块节点轮换名单的一部分)

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

Solana 出块流程简述

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

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

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

image

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 的共识协议。

image

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

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

(相关科普:《雪崩 DEX 开发者为你详解 Avalanche 共识机制》)

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

image

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

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

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

image

按照 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(海湾流)机制,提高网络处理交易的速度。

image

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

image

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

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

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

image

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

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

image

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

image

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

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

image
(在以太坊网络,恶意用户发起的重复交易更容易被各个节点直接拦截)

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 群体会自行交换收到的碎片,在本地拼凑完整的交易序列(区块)。

image

为了便于理解,我们可以将每个不同的碎片视作数据量缩减的小区块。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 发出的交易序列,加快账本(区块)的确认速度。

image

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

image

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

image

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

image

在 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] 的 “后代”。

image

·将该序列公开发布后,如果有外人想验证序列的正确性,比如他想判断 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 的 “生日” 之间;

image

•在上面的场景中,实际的 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 序列;

image

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

image

同时,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,把序列不断向前推进。如果有交易事件,就将其作为外部输入,插进序列里;

image

·如果有节点尝试在网络中发布掺水的序列,替换 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 秒。

image

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

image

由于可以判断每个 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 协议的实行创造了完美的土壤;

image

同时,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 网络的运行工作很大程度上成为了鲸鱼和专业机构、企业的专利。

image

对此,以太坊前 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 团队 对本文作者的帮助)

参考文献

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

免责声明:作为区块链信息平台,本站所发布文章仅代表作者及嘉宾个人观点,与 Web3Caff 立场无关。本文内容仅用于信息分享,均不构成任何投资建议及要约,并请您遵守所在国家或地区的相关法律法规。