詳解Solana的區塊傳播流程，與以太坊有何不同？

作者介紹：本文作者 Ryan Chern 曾任 Solana 的工程實習生，也曾是 Quantum Labs 的聯合創始人。現任職於加密貨幣研究中心 Blackhawk Research。

數據可用性對於區塊鏈而言至關重要，它能夠確保節點可以輕鬆訪問所有必要的資訊以進行驗證，從而維護網路的完整性和安全性。然而，在保持高水平性能的同時確保數據可用性是一項重大挑戰，尤其是隨著網路規模的擴大。

Solana 通過獨特的架構設計迎接了這一挑戰，促進了區塊的持續創建和傳播。這是通過多項關鍵創新實現的，例如領導者選擇、Gulf Stream（消除了對內存池的需求）和 Turbine（區塊傳播機制）。

Solana 的連續性需要一個高效的系統來確保所有驗證者及時收到最新的狀態。一種簡單的方法是讓領導者將所有塊直接傳輸給每個其他驗證者。然而，考慮到 Solana 的高吞吐量，這種方法會顯着增加帶寬和其他資源需求，同時破壞去中心化。

帶寬是一種稀缺資源，Turbine 是 Solana 巧妙的解決方案，用於優化從給定區塊的領導者到網路其餘部分的資訊傳播。Turbine 專門設計用於減輕從領導者到網路的出口（發送數據）壓力。

在本文中，我們將深入探討 Turbine 的工作原理以及它在 Solana 更廣泛的交易包容性領域中的關鍵作用。我們還將比較 Turbine 與其他數據可用性解決方案，並討論該領域的開放研究途徑。

什麼是 Turbine？

Turbine 是 Solana 集群使用的多層區塊傳播機制，用於向所有節點廣播賬本條目。Turbine 背後的核心思想多年來一直存在於學術界的討論中，2004 年發表的這篇論文以及最近的工作就證明了這一點。

與傳統的區塊鏈不同，傳統的區塊鏈會按順序或以洪泛的方式發送到所有節點，Turbine 採用更加結構化的方法來最大限度地減少通信開銷，並減少各個節點的負載。在高層，Turbine 將一個塊分解成更小的塊，並通過節點層次結構傳播這些塊。在這裡，單個節點不需要與所有其他節點聯繫，而只需與選定的幾個節點進行通信。

隨著網路規模的擴大，這一點變得越來越重要，因為傳統的傳播方法由於必要的通信量巨大而變得難以維持。因此，Turbine 確保了數據在 Solana 中快速高效的傳播。區塊傳播和驗證的速度對於維持 Solana 的高吞吐量和網路安全至關重要。

此外，Turbine 解決了數據可用性問題，確保所有節點都可以訪問所需的數據，以有效地驗證交易。這是在不需要大量帶寬的情況下完成的，而這是其他區塊鏈網路中的常見瓶頸。

Turbine 通過緩解帶寬瓶頸和確保快速區塊傳播，極大地提高了 Solana 處理高交易量並維持精簡高效網路結構的能力。這一創新協議是 Solana 兌現快速、安全和可擴展網路承諾的基石之一。

現在，讓我們更深入地研究 Turbine 的機制以及它如何在 Solana 網路上傳播區塊。

Turbine 如何傳播區塊？

在傳播區塊之前（即傳輸到網路中的其他驗證器），領導者根據傳入的交易流構建並排序該區塊。區塊構建完成後，就可以通過 Turbine 將其發送到網路的其餘部分。這個過程稱為區塊傳播。『

然後，投票消息在驗證者之間傳遞，這些消息被封裝在塊數據中以滿足承諾狀態「已確認」或「最終確定」。已確認區塊是已獲得絕大多數賬本投票的區塊，而最終區塊是已確認的區塊，並且在目標區塊之上構建了超過 31 個已確認的區塊。此處詳細解釋了承諾狀態的差異。這部分共識將在以後的文章中探討。

當領導者構建並提出整個區塊時，實際數據會作為碎片（部分區塊）發送到網路中的其他驗證者。碎片是驗證器之間發送的原子單元。

在較高級別上，Turbine 獲取碎片並將它們發送到一組預定的驗證器，然後驗證器將這些碎片轉發給一組新的驗證器。下圖概括了碎片傳播的連續過程：

在此示例中，驗證者 1 是指定的槽領導者。在其時隙期間（驗證者被指定為 4 個連續時隙的領導者），驗證者 1 構建並提議一個區塊。驗證器 1 首先通過稱為粉碎的過程，將塊分解為稱為碎片的子塊。

粉碎將塊數據拆分為最大傳輸單元 (MTU) 大小的數據碎片（可以從一個節點發送到下一個節點而不將其分成更小的單元的最大數據量），並通過 Reed-Solomon 擦除生成相應的恢復碎片編碼方案。該方案有助於數據恢復並確保傳輸過程中數據的完整性，這對於維護網路的安全性和可靠性至關重要。

這種分解和傳播過程可確保塊數據在 Solana 中快速高效地分發，從而保持高吞吐量和網路安全。

糾刪碼

在通過 Turbine 樹傳播碎片之前，首先使用里德-所羅門擦除編碼（Reed-Solomon erasure coding，一種基於多項式的錯誤檢測和糾正方案）對它們進行編碼。糾刪碼作為一種數據保護方法，即使在傳輸過程中某些部分丟失或損壞，也可以恢復原始數據。Reed-Solomon 糾刪碼是一種特定類型的前向糾錯 (FEC) 算法。

由於 Turbine 從根本上依賴於下游驗證器的一系列數據包重傳，因此這些驗證器可能是惡意的（通過選擇重播不正確的數據來對抗拜占庭節點或接收不完整的數據（網路數據包丟失）。由於 Turbine 的重傳樹結構（retransmission tree structure），任何網路範圍內的數據包丟失更加複雜，並且數據包未能到達目的地的機率在每一跳（hop）上都會增加。

在較高級別上，如果領導者將塊的 33% 的數據包作為糾刪碼傳輸，那麼網路可以丟棄任意 33% 的數據包而不會丟失塊。領導者能夠根據網路狀況動態調整此數字（FEC 速率），並考慮最近觀察到的網路範圍內的數據包丟失和樹深度等變量。

為簡單起見，我們來檢查 FEC 率為 4:4 的碎片組。

數據碎片是領導者構建的原始塊的部分塊，而恢復碎片是里德-所羅門生成的糾刪碼塊。

Solana 上的塊通常利用 32:32 的 FEC（64 個數據包中的 32 個數據包可能會丟失，無需重新傳輸）。正如 Solana 文檔所述，以下是保守的網路假設：

· 丟包率 15%

· 50k TPS 每秒生成 6400 個碎片

32:32 的 FEC 速率產生約 99% 的區塊成功率。此外，如果領導者選擇增加區塊成功的機率，他們有權提高 FEC 率。

Turbine 目前使用 UDP 進行區塊傳播，提供巨大的延遲優勢。根據驗證者營運商的說法，使用 UDP 將 6 MB + 糾刪碼數據從 us-east-1 傳輸到 eu-north-1 需要 100 毫秒，而 TCP 需要 900 毫秒。

Turbine 樹

Turbine 樹是 Solana 使用的一種結構化網路拓撲，用於促進驗證器之間碎片（編碼塊數據）的有效傳播。一旦碎片被正確編碼到各自的碎片組中，它們就可以通過渦輪樹傳播，以通知網路中的其他驗證器最新的狀態。

每個碎片組都通過網路數據包發送到一個特殊的根節點，該根節點管理哪些驗證器是第一層的一部分（1 跳之外）。然後執行以下步驟：

1. 列表創建：根節點將所有活躍驗證者聚合到一個列表中，然後根據每個驗證者在網路中的權益進行排序。具有較高權益權重的驗證者將優先獲得更快的碎片，從而使他們能夠更快地用自己的投票消息做出響應以達成共識。

2. 列表改組：然後以確定性方式對該列表進行改組。這將使用從插槽領導者 ID、插槽、碎片索引和碎片類型派生的種子，從每個碎片的驗證器節點集生成一個「Turbine 樹」。在運行時為每個碎片組生成一棵新樹，以減輕與靜態樹結構相關的潛在安全風險。

3. 層形成：然後從列表頂部開始將節點劃分為層。劃分基於 DATA_PLANE_FANOUT 值，該值決定渦輪樹的寬度和深度。該值會影響碎片在網路中傳播的速度。當前 DATA_PLANE_FANOUT 為 6。

眾所周知的 Turbine 樹確保每個驗證者確切地知道他們負責中繼該碎片的位置。假定當前 DATA_PLANE_FANOUT 值為 6，Turbine 樹通常是 4 或 5 跳樹（取決於活動驗證器的數量）。

此外，如果節點沒有獲得足夠的碎片或者丟失率超過 FEC 率，則節點能夠回退到閒話並進行修復。在當前的實現下，缺乏足夠碎片來重建塊的節點會向領導者發送重傳請求。在確定性渦輪機下，任何接收到完整塊的節點都可以發送請求節點所需的修復碎片，從而將數據傳輸進一步向下推送到樹中請求數據的區域。

比較 Solana 和以太坊之間的區塊傳播

Solana 上的區塊傳播與以太坊不同。以下是一些高級別的差異：

1. Solana 的理想帶寬要求（>1 Gbps）明顯高於以太坊（geth 建議>25 Mbps）。這種更高的帶寬要求歸因於 Solana 更大的塊大小和更快的塊時間。Solana 的設計可以有效利用整個帶寬來加快數據傳輸，從而減少延遲。雖然帶寬峰值高達 1 Gbps，但並沒有始終如一地使用 1 Gbps。Solana 的架構專門滿足了帶寬需求的高峰。

2. Solana 使用 Turbine 進行區塊數據傳播，而以太坊則使用標準的八卦協議。在以太坊上，塊數據傳播以簡單的方式進行：每個節點與網路中的每個其他全節點進行通信。一旦有新的區塊，客戶端將通過將其發送給其對等方並批准該區塊中的交易來驗證它。這種機制適合以太坊，因為與 Solana 相比，它的區塊大小更小，區塊時間更長。當涉及以太坊 L2 匯總數據（不包括 validium）時，傳播也遵循八卦協議，塊數據儲存在以太坊 L1 區塊的「calldata」字段中。

3. 以太坊使用 TCP（通過 DevP2P 協議）進行區塊傳播，而 Solana 使用 UDP（在一些社區支持下過渡到 QUIC）。UDP 和 QUIC 之間需要考慮一些權衡：

· 與 QUIC 相比，UDP 的單向性導致延遲更低，因此需要 QUIC 流。關於將單向流實施到 QUIC 中的討論正在進行中；

· QUIC 的擁護者聲稱，雖然自定義控制流可以通過 UDP 完成，但它需要大量的工程工作，而 QUIC 通過本機支持此類功能來減輕這種工作量。最終目標是相同的，但 QUIC 性能的上限（延遲、吞吐量等）是純 UDP 的當前狀態。

這些區別凸顯了 Solana 和以太坊採用的獨特架構決策，這有助於提高它們各自的性能、可擴展性和網路穩健性。有關 TCP、UDP 和 QUIC 的更深入分析，請查看我們關於 Solana 和 QUIC 的文章。

未來的研究問題

區塊傳播和數據可用性仍然是開放的研究領域，許多團隊都制定了自己獨特的方法。雖然指標可能會不斷發展，但我們希望提供不同方法及其相關權衡的概述：

1. 關於 Turbine 作為「數據可用性」（DA）機制的一些討論已經浮出水面。Turbine 充當數據可用性機制，整個區塊數據由 Solana 上的所有其他驗證器發布和下載。儘管如此，Turbine 缺乏對數據可用性採樣（DAS）的支持，該功能可以幫助輕節點在降低硬體要求的情況下驗證狀態。這是 Celestia 等團隊積極的開發重點。與 Turbine 一樣，DAS 也使用糾刪碼，但這樣做的明確目的是檢測和防止數據隱瞞攻擊。

2. 對於 Solana 虛擬機 (SVM) L2（例如 Eclipse），Tubrine 失去了相關性，因為沒有設置驗證器來在其之間傳遞數據。就 Eclipse 而言，區塊數據被發布到 Celestia 以獲得數據可用性——這使得外部觀察者能夠運行欺詐證明，以確保正確的執行和狀態轉換。Eclipse 將成為 Solana 網路本身之外 SVM 的首批實現之一。Pyth 還為自己的預言機網路「Pythnet」分叉了 SVM，並作為自己的側鏈有效運行。

3. 在 Solana 上，完整節點管理區塊傳播，同時還參與集成區塊鏈堆棧的其他部分，例如交易排序和共識。如果 Turbine 作為模塊化組件在專用硬體上運行，其定量指標是什麼？

4. Turbine 優先考慮權重較高的節點首先接收區塊數據。隨著時間的推移，這會導致 MEV 更加集中化嗎？

5. 就原始吞吐量和信任最小化而言，不同的數據可用性方法（例如 EigenDA（水平可擴展的單個單播中繼器）和 Celestia（數據可用性採樣））與生產中的 Turbine 相比如何？

6. Firedancer 旨在進一步增加數據傳播，並針對強大的 10 Gbps 帶寬連接進行了優化。他們圍繞 Turbine 進行的系統級優化在消費級硬體和專業級硬體的生產中將如何表現？

7. 目前，Solana 上的所有節點都是完整節點（輕客戶端實現仍在開發中）。Sreeram Kannan (EigenLayer) 最近描述了在 Turbine 之上實現 DAS-S。是否會支持適用於 Turbine 的 DAS 版本？是否可以實施具有 DAS 的輕客戶端來保持高數據吞吐量，同時輕客戶端（資源要求低得多）滿足信任最小化？

結論

恭喜！在本文中，我們研究了 Turbine 及其在 Solana 更廣泛的交易包容領域中的工作方式。我們將 Turbine 與其他數據可用性解決方案進行了比較，並討論了對該領域開放的不同研究途徑。Solana 的 Turbine 協議證明了網路致力於通過利用結構化網路拓撲在驗證器之間有效傳播塊數據來實現高吞吐量和低延遲。

尋找增強數據可用性並提高區塊傳播效率的方法可以推動更廣泛的區塊鏈社區內的創新。對 Solana 和以太坊的區塊傳播機制的比較分析揭示了它們各自的優勢和權衡，並激發了人們對新興區塊鏈解決方案（例如 EigenDA、Celestia 和 Firedancer）如何在未來塑造這個生態系統進行更深入的討論。

高效數據傳播和數據可用性的解決方案還遠未完成。然而，Solana 在不影響安全性和信任最小化的情況下，優化網路性能的方法和堅定承諾受到熱烈歡迎。

原文連結