Turbine 充當了 Solana 的數據可用性機制，但 Turbine 不支援 DAS ，無法支援輕節點的驗證。
作者：whiskoy.eth
封面：Photo by GuerrillaBuzz on Unsplash
Turbine 是 Solana 區塊鏈使用的 multi-layer 區塊傳播機制，用於向所有節點廣播帳本。 Turbine 背後的核心思想已經在學術界存在了很多年。 本課題旨在探討 Turbine 是如何工作的，拆解 Solana 上的區塊傳播機制，並與乙太坊的區塊傳播進行比較，探索未來區塊傳播和數據可用性可能的樣子。
一、Solana 概述
公鏈的效率主要指其處理交易的能力，也就是輸送量 TPS ，該指標受限於區塊大小和出塊速度。 大區塊方向的探索飽受詬病，公鏈擴容敘事主要圍繞出快速度。
Solana 擴容主要基於：高效利用網路頻寬、減少節點間通訊次數、加快節點運算速度三大方面，縮短了出塊和共識通訊的時間，但也降低了系統可用性（安全）。
- 共識：
- Leader 名單公示：在每個 Epoch 開始前，網路會提前公開出塊者 Leader 名單，在整個 Epoch（2~4 天）內，出塊者會按照名單指定的次序，每過 4 個 Slot 輪換一次。 基於單一可信的新區塊數據源，縮減了共識通訊開銷，但也可能帶來賄賂、針對性攻擊等安全隱患。
- 共識投票：類似乙太坊確認最終性。 節點無需再通過「流言協定」進行一對一的投票資訊互換，Leader 集中匯總所有 Validator 的投票，再把這些投票打包寫進交易序列里，一次性推送到網路中。 以 ETH 網路為例，若全網節點數量為 N ，則每個節點至少接收 2/3×N 個投票，整個網路產生的通訊次數至少為 2/3×N² 。 而 Solana 的共識將通訊次數降至常數 N 甚至是 logN 的數量級。
- PoH：Solana 中引入 PoH 時鐘是為了解決分散式網路中缺乏單個可信時間源的問題。 Leader 實質上在交易序列中發佈了全網一致的計時器（時鐘），PoH 給不同的交易事件蓋上序號，生成交易序列。 一般而言，Leader 會時刻不停的執行 SHA256 函數，得到新的 X ，把序列不斷向前推進。 如果有交易事件，就將其作為外部輸入，插進序列里; 最終發佈的交易序列形式為：{T1， 序號 3， 緊鄰 X3;}， {T2， 序號 5， 緊鄰 X5;}， {T3， 序號 8， 緊鄰 X8;}， {T4， 序號 10， 緊鄰 X10;}， { POH 序列初始值 X1;}
- 傳輸：
- Gulf Stream：由於提前公開 Leader 名單，Solana 節點無需在本地維護交易池。 用戶端在接收到交易后，直接轉發到 Leader 處打包為交易序列。 但由於該機制設計，節點在收到交易后無法過濾攔截垃圾和重複交易，容易造成 Leader 節點宕機。
- Turbine 傳輸協定：Solana 的 Leader 節點發佈的是交易序列而非真實的區塊。 在 PoH 和 Gulf Stream 的配合下，Solana 實現了類似 BT 種子的傳輸方式。 Leader 會把生成的交易序列切成 X 個不同的碎片，分別發送給質押資產最多的 X 個 Validators ，再由他們傳播給其他 Validators 。 Validator 群體會自行交換收到的碎片，在本地拼湊完整的交易序列，最終構建區塊。
- 投票壟斷：實際上，33% 的質押份額掌控在前 22 個節點中，67% 的份額掌控在前 91 個節點中。 結合前文所說的傳輸機制，這些節點最先收到 Leader 發出的交易序列，也會率先給出投票。 而只要得到這 91 個節點的投票，Leader 發佈的交易序列便可敲定。 從某種角度看，這些節點搶跑在其他節點之前。 另一方面，如果前 22 個節點串謀，便可使網路陷入混亂。
- 交易序列：在 Solana 的設定中，Leader 實質將共識投票作為交易事件來處理，其發佈的交易序列中，節點投票資訊佔比超過 70% 以上。 因此，實際與使用者交易相關的 TPS 遠沒有想像中高。
二、Turbine 傳輸機制
帶寬是一種稀缺資源，Turbine 是一種 multi-layer 的區塊傳播機制，旨在優化「從 leader 到網路其他節點」的交易序列的傳輸。 與其他區塊鏈採用的 flooding 廣播方式不同，Turbine 採用更結構化的方法來最大限度地減少通信成本，減少單個節點的負載。
概括的說，Turbine 將交易序列（區塊）分解成更小的塊，並以「節點層次」的結構進行傳播。 在該結構下，單個節點只需與選定的幾個節點進行通信，而非全網所有節點。 隨著網路規模的擴大，這一點變得越來越重要。
此外，Turbine 在不需要大量頻寬的情況下解決了數據可用性問題，確保所有節點都可以訪問所需的數據以有效地驗證交易。 這是其他區塊鏈網路中的面臨瓶頸。
1、Turbine 原理概述
Leader 生成交易序列後，下一步需要做的就是序列廣播。
Shreds 是交易序列的一部分。 總的來說，Turbine 負責獲取 shreds，並將它們發送到一組預定的 validator ，隨後由驗證器再將這些 shreds 轉發給新的一組 validator 。
- Leader 構建的交易序列在 validator 中是以 shreds 的形式傳播。
- shreds 的大小剛好是 MTU（Maximum Transmission Units），也就是節點之間單次所能傳輸的最大數據量。
- validator 收到 shreds 後，通過 Reed-Solomon 糾刪碼方案生成其他 shreds ，保證傳輸過程中的數據完整性。
2、Reed-Solomon 糾刪碼
Shreds 在傳入 Turbine Tree 進行傳輸之前，需要先經過 Reed-Solomon 糾刪碼進行編碼處理。 糾刪碼作為一種前向糾錯（FEC， Forward Error Correction）數據保護方案，即使在傳輸過程中部分數據丟失或損壞，也可以恢復原始數據。
由於 Turbine 從根本上依賴於下游驗證器的一系列數據包重傳，這些驗證器可能是惡意的（選擇廣播錯誤數據）或接收不完整的數據（網路數據包丟失）。 由於 Turbine 傳播的樹狀結構，網路範圍內的任何數據包丟失都會加劇，丟包概率在每一跳上都會增加。
總的來說，如果 Leader 將交易序列 33% 的數據傳入糾刪碼，那麼網路可以丟棄任意 33% 的數據包而不會影響數據恢復。 Leader 能夠根據網路狀況動態調整此數位（也就是 FEC 速率），綜合考慮樹深度和丟包情況後作出調整。
Solana 的區塊通常利用 32：32 的 FEC（當 64 個數據包中的 32 個數據包可能會丟失，無需重新傳輸）。 如 Solana 文件所述，以下是網路的保守假設：
- 丟包率為 15%
- 50k TPS 情況下，每秒生成 6400 個 shreds
32：32 的 FEC 速率產生約 99% 的區塊成功率。 此外，Leader 可以選擇提高 FEC 率，從而增強區塊傳播的成功概率。
Turbine 目前使用 UDP 進行區塊傳播，具有很小的延遲。 根據節點運營商的數據，使用 UDP 將 6 MB + 糾刪碼數據從 us-east-1 傳輸到 eu-north-1 需要 100 毫秒，而 TCP 需要 900 毫秒。
3、Turbine Tree
Turbine Tree 是 Solana 使用的一種結構化網路拓撲，用於促進驗證器之間 shreds 的有效傳播。 一旦 shreds 被正確（糾刪碼）編碼，它們就可以通過 Turbine Tree 傳播，告知網路中的其他驗證器最新的狀態。
Shreds 通過網路包的方式發送到一個特殊的根節點（root node）。 根節點負責管理驗證器及其所屬的層級（例如 hop1， hop2），並執行以下步驟：
- 創建清單：根節點負責將所有的活躍驗證器聚合到一個清單中，並根據驗證者在網路中的質押量進行排序。 具有質押多的驗證者將優先收到 shreds，可以更快地投票回應以達成共識。
- 清單改組：隨後以確定的方式對清單進行改組，改組使用到的 seed 是由 slot leader id， slot， shred index 和 shred type 決定的。 最終為每個 shred 組生成一棵 Turbine Tree。 “渦輪樹” 是在運行時為每個碎片組新生成的，以減輕與靜態樹結構相關的潛在安全風險。
- 節點分層：隨後根據 Turbine Tree 的結構，從清單頂部開始將節點劃分為層。 分層需要參考 DATA_PLANE_FANOUT 值（目前是 200），該值決定渦輪樹的寬度和深度。 不同數值會影響 shreds 在網路中傳播的速度，目前大多數驗證器僅相距 2-3 跳（leader -> root -> L1 -> L2）。
如果節點沒有獲得足夠的 shreds 來恢復區塊，或丟失率超過 FEC 率，則節點能夠回退到 gossip 模式向其他驗證器所要 shreds 並進行修復。 目前的實現方式是，缺乏 shreds 的節點直接向 Leader 發送重傳請求。
三、對比乙太坊區塊廣播
Solana 的區塊傳播，對比乙太坊有以下區別：
- Solana 對頻寬的要求（>1 Gbps）高於乙太坊的要求（>25Mbps），這是由於 Solana 的區塊更大，對出快速度有更高的要求。
- Solana 採用 Turbine 傳播機制，而乙太坊使用簡單的 gossip 傳輸協定。 乙太坊中，每個節點與網路中的所有其他全節點直接通信; 一旦產生新的區塊，客戶端將驗證區塊內的交易，並廣播到網路中的其他節點。 與 Solana 相比，gossip 機制更適合乙太坊，因為乙太坊區塊更小，出塊時間更長。
- 乙太坊使用 TCP 協定（通過 DevP2P protocol[1]），而 Solana 使用 UDP 協定（一些社區的支援過渡到 QUIC，目前仍在討論 [2]）。
寫在最後
關於「高效的數據傳播」和「數據可用性的解決方案」的探索還遠遠沒有完成。 關於 Turbine 的研究一直在進行，很多專案探索 Turbine 是否可以作為通用的 DA 方案。 從某種意義上來說，Turbine 充當了 Solana 的數據可用性機制，但 Turbine 不支援 DAS ，無法支援輕節點的驗證。 儘管 Turbine 和 DAS 都採用了糾刪碼，但在 DAS 中使用主要是為了避免數據扣留攻擊（data withholding attacks）。
- 對於 SVM Layer2（例如 Eclipse）來說，Turbine 失去了它的作用，因為沒有驗證器集來連接二者實現數據傳遞，區塊數據只能發佈到 Celestia 上。
- 當前所有的 Solana 節點都是全節點，EigenLayer 的 CEO Sreeram Kannan 提出基於 Turbine 實現 DAS-S 方案。
- Firedancer 圍繞 Turbine ，旨在進一步增強 Solana 的數據傳輸，並針對穩健的 10 Gbps 帶寬連接進行了優化。 他們所做的系統級優化在消費級硬體和專業級硬體的生產中表現如何值得期待。
參考
Ryan Chern：https://twitter.com/ryanchern/status/1716941141831270798
Full article：https://www.helius.dev/blog/turbine-block-propagation-on-solana
CatcherVC：https://www.chainfeeds.xyz/feed/detail/20390210-48f7-4aa5-b6e1-ccb8eba39a6f
免責聲明：作為區塊鏈資訊平臺，本站所發佈文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。 文章內的資訊僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
