Solana擴容機制分析：犧牲可用性換取高效率的極端嘗試 | CatcherVC Research
Solana以系統可用性為代價，將Layer1擴容的敘事推向了極端，基本觸及無分片公鏈的TPS瓶頸。但多次宕機似乎預示了犧牲可用性換取效率的結局。作者：SA，CatcherVC
技術顧問 ：劉洋，《嵌入式系統安全》作者
摘要
- 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第313個Epoch出塊節點輪換名單的一部分）
由於提前公開了未來的出塊節點，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天無人質疑，才能最終確認，這顯然是Solana無法接受的。
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團隊 對本文作者的幫助）
參考文獻
1.Solana白皮書中文版
2.Gulf Stream: Solana's Mempool-less Transaction Forwarding Protocol
13.Tendermint-2-共識算法:Tendermint-BFT詳解
