Solana Turbine：區塊傳播說明
Learn how Solana Turbine propagates blocks across validators using shreds, Reed-Solomon coding, and neighborhood trees for 65,000 TPS throughput.
Solana Turbine 區塊傳播描述了區塊數據如何被分割成碎片 (shreds) 並分發給驗證者。本文中的圖表是歷史的或目標值，除非另有明確日期；實際的時段時間、拓撲結構、數據包丟失和實施行為均可能有所不同。
引言：為何區塊傳播決定了區塊鏈的速度
一次將完整區塊發送給數千個驗證者，需要每個驗證者從單一來源下載整個區塊，這會造成一個隨著網絡擴展而惡化的帶寬瓶頸。Solana (SOL) 是一種高性能的 Layer-1 區塊鏈（一個無需中心化機構即可記錄和驗證交易的分佈式賬本網絡），它通過其專用的區塊傳播協議 Turbine 來解決這個問題。
早期的 Solana 材料引用了接近 65,000 TPS 的理論吞吐量和接近 400 毫秒的目標時段持續時間。這些是設計參考，而非保證的實時測量值，且一個時段並不總能產生一個區塊。Turbine 是 Solana 歷史架構框架中描述的區塊數據傳播機制。
區塊傳播位於共識機制之下：驗證者（擁有賬本副本、驗證交易並對區塊有效性進行投票的服務器）在接收並從碎片重建區塊之前，無法對其有效性進行投票。這種依賴性意味著 Turbine 的速度是 Solana 共識性能的直接推動因素。Solana 上的每一次智能合約交互，從去中心化金融 (DeFi) 交易到 NFT 的鑄造，都取決於該區塊是否足夠快地到達驗證者，以便在下一個時段內確認。
接下來將涵蓋 Turbine 的定義、五步機制、技術參數、性能貢獻、安全權衡，以及與以太坊和 Avalanche 的頭對頭比較。
本文內容
- 什麼是 Solana Turbine 區塊傳播？
- 關鍵術語：Turbine 術語快速參考指南
- Turbine 如何傳播區塊：步驟詳解
- Turbine 的技術參數
- Turbine 與 Solana 的性能：連接區塊傳播與 TPS
- Turbine 安全嗎？安全模型與已知攻擊向量
- Solana Turbine 與以太坊及其他 Layer-1 區塊鏈比較
- Turbine 在 Solana 架構內：所有 8 項創新
- Turbine 的演變：從 2017 年的白皮書至今
- 關於 Solana Turbine 的常見問題
- 結論：Turbine 對 Solana 的未來為何重要
- 進一步閱讀與主要來源
什麼是 Solana Turbine 區塊傳播？
定義
Solana Turbine 是 Solana 的區塊傳播協議，一種將新生成的區塊分割成數千個固定大小的數據包（稱為碎片，shreds）並通過稱為鄰里樹 (neighborhood tree) 的分層樹狀結構分發到驗證者網絡的機制。Reed-Solomon 糾delete碼可恢復傳輸中丟失的任何數據包，確保驗證者即使在不利的網絡條件下也能重建完整的區塊。
Turbine 之所以存在，是因為簡單的廣播無法擴展。如果區塊領導者（為特定時段指定的生產區塊的驗證者）同時將整個區塊直接發送給每個驗證者，那麼每個驗證者都需要獨立下載完整的區塊。在 Solana 網絡擁有 2,000 多個活躍驗證者的情況下，這種方法需要單一來源具有 O(n) 的帶寬，這意味著帶寬成本隨著網絡中驗證者數量的增加而線性增長。
Turbine 通過借用 BitTorrent 協議的核心原則，實現了 O(log n) 的帶寬擴展。BitTorrent 點對點文件分發協議通過將大文件分割成小塊並同時將這些塊分發到許多節點，而不是從單一服務器提供，從而有效地傳輸大文件。Turbine 將相同的理念應用於區塊鏈區塊傳播：區塊領導者不是將整個區塊傳輸給每個驗證者，而是將區塊分割成碎片，並通過驗證者的分層樹路由，每一層將碎片向下傳遞。
這個類比存在需要注意的局限性。BitTorrent 作為一個平坦的點對點網絡運行，所有參與者都被同等對待。Turbine 使用帶有質押權重定位的分層樹，這意味著擁有更多質押 SOL 的驗證者被放置在樹的較高位置，並較早收到碎片。這種區別對於理解 Turbine 的效率及其安全權衡至關重要。
Turbine 由 Solana Labs 的聯合創始人 Anatoly Yakovenko 設計，並在 Anatoly Yakovenko (2017) 的原始 Solana 白皮書.) 中首次提出。該協議自 2020 年 3 月 Solana 的主網 Beta 啟動以來一直持續生產。
關鍵術語：Turbine 術語快速參考指南
在詳細介紹 Turbine 的工作原理之前，以下是您在本文中會遇到的核心術語。
| 術語 | 白話文定義 | 在 Turbine 中的作用 |
|---|---|---|
| Turbine | Solana 的區塊傳播協議，負責將新區塊分發到驗證者網絡。 | 本文的主要主題；包含以下所有組件的系統。 |
| Shred (碎片) | 通過分割區塊以供網絡傳輸而創建的約 1.5 KB 的固定大小數據包。 | Turbine 在網絡上傳輸的基本數據單元。 |
| Data Shred (數據碎片) | 通過分割區塊產生的原始區塊數據片段之一。 | 攜帶區塊中的實際交易數據。 |
| Coding Shred (編碼碎片) | 由 Reed-Solomon 糾delete碼生成的冗餘數據包，不屬於原始區塊數據。 | 允許驗證者在數據碎片傳輸丟失時重建區塊。 |
| Block Leader (區塊領導者) | 通過 Solana 的確定性領導者計劃選定的、為特定時段生產區塊的驗證者節點。 | 通過分割區塊並傳輸給 Layer 1 來啟動 Turbine 進程。 |
| Neighborhood Tree (鄰里樹) (Fanout Tree) | 驗證者按層組織的分層結構，Turbine 通過該結構將碎片向下路由。 | 為 Turbine 提供 O(log n) 帶寬效率的路由拓撲。 |
| Reed-Solomon Erasure Coding (Reed-Solomon 糾delete碼) | 一種數學技術，可生成編碼碎片，允許在數據包丟失時重建區塊。 | Turbine 的容錯機制；處理高達約三分之一的數據包丟失。 |
| Fanout Factor (扇出因子) | 在鄰里樹的每一層中，每個節點傳輸到的驗證者數量（約 200）。 | 決定每一層覆蓋多少驗證者以及多快能觸達整個網絡。 |
| Slot (時段) | Solana 約 400 毫秒的區塊生產窗口，在此期間區塊領導者必須生產並傳播區塊。 | 為共識的進行設定 Turbine 必須滿足的時間限制。 |
| Stake-Weighting (質押加權) | 將高質押權重的驗證者置於鄰里樹較高位置的做法。 | 確保擁有最大質押權重的驗證者最早收到碎片，同時引入輕微的中心化權衡。 |
Turbine 如何傳播區塊：步驟詳解
Turbine 透過五個步驟傳播區塊：區塊領導者將區塊粉碎（shred），里德-所羅門碼（Reed-Solomon coding）產生冗餘封包，產生的碎片（shreds）流經一個權益加權的鄰近樹（neighborhood tree），直到每個驗證者都持有足夠的碎片來重組完整的區塊。下方的每個步驟都完整涵蓋了該過程的一個階段。
第 1 步：區塊領導者產生區塊
每個區塊都從區塊領導者（也稱為區塊生產者）開始，該驗證者節點是針對特定插槽（slot）指定的，並透過 Solana 的確定性領導者排程提前選出。根據 Solana 的領導者排程文件,)，該排程源自歷史證明（PoH）時鐘，即 Solana 的加密計時機制。由於領導者排程是公開且確定性的，任何驗證者都可以在插槽開始前驗證誰將是下一個區塊領導者。
區塊領導者收集由 Gulf Stream（Solana 的交易轉發協定，在當前區塊完成最終確認前將未確認的交易推送到預期的下一個領導者）轉發的交易，並將其組裝成一個完整的區塊。一旦組裝完成，區塊領導者便開始 Turbine 過程。
第 2 步：區塊被粉碎成數據封包
根據 Solana 的技術文件，區塊領導者將完成的區塊拆分為固定大小的數據封包，稱為 shreds，每個大小約為 1.5 KB。這些原始區塊數據碎片稱為數據碎片（data shreds）。一個完整大小的 Solana 區塊根據區塊大小可以產生數千個數據碎片。
將粉碎想像成將一個大文件拆分為數千個小的電子郵件附件，並透過不同的路徑路由每個附件：即使有幾個附件延遲到達，完整的文件也會在目的地重新組裝。關鍵優勢在於並行傳輸。因為樹中的每個驗證者同時接收和轉發不同的碎片，網路在開始分發數據之前不需要等待單個大型的順序傳輸。
Turbine 的粉碎（shredding）不是分片（sharding）。分片將區塊鏈的狀態或交易處理拆分到多個並行的子網路中，由不同的驗證者子集驗證狀態的不同部分。Turbine 粉碎區塊純粹是為了傳輸效率：整個 Solana 驗證者網路驗證的是相同的完整區塊狀態。這種碎片化是一種傳送機制，而非分割策略。
第 3 步：里德-所羅門碼產生冗餘碎片
**里德-所羅門糾刪碼（Reed-Solomon erasure coding）**會產生第二類碎片，稱為編碼碎片（coding shreds），這些是冗餘封包，即使部分原始數據碎片在傳輸中丟失，也能讓任何驗證者重組完整的區塊。這種區別很重要：數據碎片承載實際的區塊內容；編碼碎片承載數學推導的冗餘，可以填補空白。
一個有用的比喻：里德-所羅門糾刪碼的功能就像 QR code。即使 QR code 的一部分被遮擋或損壞，倖存部分中仍編碼有足夠的冗餘資訊來解碼完整的訊息。QR code 的比喻有一個值得注意的限制：QR code 是靜態對象，而 Turbine 的糾刪碼則運作於具有特定數值恢復閾值的串流批次碎片上。
根據 Solana 的實現，只要驗證者收到總碎片（數據加上編碼的總和）的大約三分之二，就可以重組完整區塊。這意味著該協定在重組失敗前可容忍約三分之一的封包丟失。里德-所羅門碼是一項成熟的技術，在 CD、DVD、衛星通訊和其他應用中有數十年的生產使用經驗，這支持了 Turbine 的容錯機制是建立在經過驗證的工程學而非實驗性設計之上的說法。技術參數引用自 Solana 白皮書) 和 Solana 官方 Turbine 文件.)。
第 4 步：碎片透過鄰近樹分發
鄰近樹（也稱為扇出樹 fanout tree）是 Turbine 分發碎片的階層式路由結構，它將 Solana 的驗證者組織成多層，每層從上一層接收碎片並向下游重新傳輸。下方的結構顯示了該樹如何在兩層之間擴展：
第 0 層 (區塊領導者)
|
+-- Layer 1：~200 個驗證者（每個接收碎片的唯一子集）
|
+-- Layer 2：多達 ~40,000 個驗證者（200 x 200，每個 Layer 1 驗證者轉發給另外 ~200 個）考慮到每層約 200 的扇出因子，鄰近樹在兩到三層內涵蓋了 Solana 的完整活躍驗證者集（根據 Solana 基金會網路統計數據，約有 2,000 多個驗證者）。透過兩層，該樹在數學上可以達到 40,000 個驗證者（200 x 200），這遠遠超過了目前的活躍集合。
將此結構想像成郵政分揀網路：中央樞紐將批次發送到區域分揀中心，後者送達地方郵局，再送達個人地址。每一層僅處理總負載的一小部分，沒有任何單個節點承擔全部頻寬成本。然而，與中立的郵政系統不同，Turbine 的鄰近樹是經過權益加權的。在 Solana 基於權益證明（Proof of Stake）的共識機制 (Tower BFT) 下，擁有更多質押 SOL 的驗證者被安置在更靠近樹頂的位置，確保他們最早收到碎片。
樹的拓撲結構在每個插槽也會使用源自 PoH 時鐘的可驗證隨機性進行隨機化，這意味著隨機源是任何驗證者都可以在不信任中央方的情況下獨立驗證的。因為樹在每個插槽都會變動，對抗性驗證者無法預測下一輪誰會是他們的鄰居。這種隨機化是 Turbine 對抗日蝕攻擊（eclipse attacks）的主要防禦手段，在這種攻擊中，攻擊者試圖包圍目標驗證者並扣押碎片。
其結果是 O(log n) 的頻寬擴展，這意味著頻寬需求相對於驗證者數量的增長非常緩慢。隨著 Solana 驗證者數量的增加，這一特性使 Turbine 的設計變得越來越有價值。
第 5 步：驗證者重組區塊並投票
一旦驗證者收到足夠的碎片以達到糾刪碼閾值（該區塊總碎片的大約三分之二），它就會重組完整的區塊並將其投票提交給 Tower BFT（塔式拜占庭容錯），這是 Solana 基於權益證明的共識機制。驗證者在重組完成前無法投票，這就是為什麼 Turbine 的傳播速度直接限制了共識吞吐量。
傳播過程是圍繞 Solana 的目標插槽節奏設計的，但實際的時間安排和驗證者覆蓋範圍會隨網路和實現條件而變化。如果傳播在該視窗內完成，共識就會繼續，下一個插槽就會開始。如果沒有完成，該插槽可能會被跳過，這會暫時降低吞吐量。
當碎片丟失時會發生什麼？
關鍵事實
當碎片在傳輸中丟失時，只要總封包丟失率低於該區塊傳輸的所有碎片的大約三分之一，Solana 的里德-所羅門糾刪碼就允許驗證者從他們收到的編碼碎片中重組完整的區塊。
QR code 的比喻在這裡也適用：只要有足夠的圖案存留，完整訊息就能被解碼。當封包丟失低於恢復閾值時，驗證者會從到達的數據碎片和編碼碎片的任何組合中重組區塊。
當封包遺失超過該閾值時，驗證者會向持有遺失分片（shreds）的鄰近驗證者發出修復請求。此修復機制會增加延遲，但除非修復無法在槽（slot）視窗內完成，否則不會立即導致槽跳過。
在嚴重的網路壅塞情況下，當封包遺失廣泛分佈於整個網路而非僅限於單一路徑時，多個驗證者可能無法在槽視窗內重建其區塊。這種連鎖反應會導致槽跳過，在極端情況下，更會造成 Solana 在 2021 和 2022 年重大壅塞事件期間經歷的網路降級。Solana Labs 此後已針對這些事件改進了 Turbine 的壅塞處理機制。壅塞與槽跳過之間的關聯將在下方的安全性章節中討論。
Turbine 的技術參數
下表總結了 Turbine 的關鍵操作參數，這些參數源自 Solana 的官方文件和 Solana 白皮書。隨著協議的演進，Solana Labs 可能會更新參數；請在 Solana 的官方 Turbine 文件.) 上驗證目前的值。
| 參數 | 值 | 來源 |
|---|---|---|
| 分片大小 | 每片約 1.5 KB | Solana 文件 (docs.solana.com/cluster/turbine-block-propagation) |
| 每層的扇出因子 | 約 200 個驗證者 | Solana 白皮書；Solana 文件 |
| 覆蓋整個網路的典型層數 | 2-3 層 | Solana 文件 |
| 2 層內可觸及的驗證者 | 約 40,000 (200 x 200) | Solana 文件 (根據扇出因子推導) |
| 糾錯碼恢復閾值 | 約 1/3 的封包遺失容忍度 | Solana 白皮書 |
| 目標第一層傳播時間 | 低於 100 毫秒 | Solana 文件操作目標 |
| 目標全網傳播視窗 | 在約 400 毫秒的槽內 | Solana 白皮書；Solana 文件 |
| 與傳統廣播相比的頻寬擴展性 | O(log n) 對比 O(n) | Solana 白皮書 |
Turbine 與 Solana 的效能：連接區塊傳播與 TPS
Solana 白皮書及後續評論引用了接近 65,000 TPS 的理論吞吐量。實際觀測到的吞吐量取決於日期、工作負載、投票包含、過濾和軟體版本，因此不應在未提供測量方法學的情況下展示即時的非投票 TPS 範圍。Turbine 是結果的一個組成部分，而非獨立的 TPS 保證。
因果鏈如下運作。Turbine 以足夠快的速度傳播分片，使得網路中的驗證者能在約 400 毫秒的槽視窗內重建區塊並進行投票。共識得以進行。下一個槽開始。Solana 維持其槽節奏。由於每個槽可包含數千筆交易，維持此節奏是產生高 TPS 的關鍵。傳播延遲會中斷此節奏並導致 TPS 下降；維持節奏則 TPS 保持高位。
理論 TPS 與實際 TPS 之間的區別值得特別關注。Solana 的原始 TPS 數據（可達到更高數字）包含驗證者投票交易，這些是代表使用者提交交易的內部共識訊息。非投票 TPS，這個與其他區塊鏈的吞吐量更具可比性的數據，根據 Solana Labs 的效能文件，在 2024-2025 年的實際負載下通常運行在 2,000 到 4,000 之間。65,000 的數字是假設理想條件下的理論上限；它並非對平均網路行為的描述。
Turbine 的 O(log n) 頻寬設計也防止了隨著驗證者數量增加，傳播層成為瓶頸。採用傳統廣播方法，驗證者數量加倍會使每個發送節點所需的頻寬也加倍。而使用 Turbine 的樹狀結構，驗證者數量加倍僅需增加一層（每個現有節點約增加 200 個驗證者），這意味著頻寬需求緩慢增長而非線性增長。
關鍵要點
Turbine 不執行交易；它負責傳播區塊數據。傳播效能會影響投票和吞吐量，但 Turbine 不保證固定的 TPS 數字、槽節奏或最終確定時間。
Turbine 是否安全？安全模型與已知攻擊向量
Turbine 包含三個核心安全機制：每槽隨機重新洗牌的隨機路由、基於質押權重的樹狀結構定位，以及 Reed-Solomon 糾錯碼冗餘。每個機制都針對特定的攻擊面，儘管每個機制也引入了一個值得誠實檢視的權衡。
鄰近節點樹每槽都使用源自歷史證明（Proof of History）時鐘的可驗證隨機性進行重新洗牌，這意味著惡意驗證者無法預測下一個槽的鄰近節點。這很重要，因為分層分佈樹的主要攻擊向量是「日蝕攻擊」（eclipse attack）：惡意參與者將驗證者圍繞目標驗證者放置並扣留分片，阻止該驗證者重建區塊，進而阻止其投票。
由於樹狀拓撲結構每槽都會改變，攻擊者無法可靠地維持這種圍繞。區塊領導者是預先已知的（通過確定性領導者排程），但傳播路徑不是。這種不對稱性是故意的安全設計：關於誰產生區塊的透明度，結合區塊如何傳播的不透明性。
這種保護有其限制。擁有足夠質押權重的攻擊者有可能在連續洗牌中出現在多個位置，在目標驗證者附近維持一定的統計存在。隨機路由提高了日蝕攻擊的成本和複雜性，但並不能使其對資源充足的對手而言變得不可能。
質押權重將較高質押權重的驗證者置於鄰近節點樹的較頂層，這意味著它們比質押權重較低的驗證者更早接收到分片，為大型質押操作創造了結構性優勢。首先接收分片的驗證者可以在其質押權重較低的同儕之前開始重建和投票，這在共識過程中轉化為輕微的時間優勢。
誠實的批評是：擁有足夠質押權重集中的驗證者理論上可以利用這種早期訪問權來嘗試區塊扣留策略，延遲其投票以獲得資訊優勢。Tower BFT 的共識最終確定規則旨在限制此類策略的可行性，並且質押集中度分佈在約 2,000 多個活躍驗證者之間（根據 Solana 基金會的網路統計），這限制了極端的集中度。Solana 基金會也運行質押委託計畫，旨在將質押更廣泛地分發給較小的驗證者。儘管如此，對大型驗證者的結構性優勢是真實存在的，並且在評估 Solana 的去中心化程度時值得考慮。
Solana 在 2021 年至 2022 年間發生的絕大多數網路中斷是由於交易處理管道壅塞引起的，而非 Turbine 特定故障，儘管極端壅塞可能會對區塊傳播層造成壓力。在那些時期，當交易量壓垮 Solana 的處理管道時，產生的區塊和分片數量也隨之增加，而傳播層面則面臨比網路頻寬能乾淨吸收更多的同時分片批次。
其結果是廣泛的封包丟失，超出了許多驗證者同時的糾刪碼恢復閾值，導致了連續的時段跳過（slot skip cascades），而非孤立的個別故障。Solana Labs 隨後對擁塞處理進行了工程改進，包括更改網路管理交易攝取的方式，以及 Turbine 在高負載下處理傳播的方式。有關當前的工程狀態，請參閱 Solana Labs 工程部落格.)。停機歷史是 Turbine 生產記錄的事實，而非理論風險，對於任何評估 Solana 技術彈性的人來說，這都是相關的背景資訊。
Solana Turbine vs. Ethereum 與其他 Layer-1 區塊鏈
Solana 傳播區塊的速度比 Ethereum 快，主要是因為 Turbine 使用分層鄰近樹（hierarchical neighborhood tree）來並行分發碎片（shreds），而 Ethereum 使用 Gossip 協議，驗證者將區塊廣播給隨機的同行子集，後者再重新廣播給他們的同行，這在規模化時是一種根本上較慢的拓撲結構。下表比較了 Solana、Ethereum 和 Avalanche 在區塊傳播中最重要的維度。
| 屬性 | Solana (Turbine) | Ethereum (Gossip Protocol) | Avalanche (Snowflake/DAG) |
|---|---|---|---|
| 傳播方法 | 分層鄰近樹；碎片逐層分發 | Gossip：隨機同行廣播，重複廣播直至全網覆蓋 | Snowflake/Snowball DAG；基於採樣的協議，帶有重複的隨機輪詢 |
| 數據單位 | 碎片（約 1.5 KB 固定大小封包） | 完整區塊或區塊標頭（大小可變） | 在 DAG 共識後透過 Gossip 轉發區塊 |
| 區塊時間 | 約 400 毫秒時段時間 | 約 12 秒 | 約 1-2 秒（最終性因子網而異） |
| 容錯機制 | Reed-Solomon 糾刪碼（可承受約 1/3 封包丟失） | 冗餘 Gossip 路徑；向同行重新請求區塊 | 重複隨機採樣提供機率性容錯 |
| 頻寬擴展 | O(log n)：隨著驗證者數量增加而緩慢增長 | 每跳 O(n)：Gossip 每輪傳播至隨機比例的同行 | 透過機率性採樣實現次線性增長；擴展性優於純 Gossip |
| 去中心化方法 | 質押加權樹；高質押驗證者更早收到碎片 | 對等選擇；無基於質押的拓撲權重 | 透過子網成員身份選擇驗證者；不同的去中心化模型 |
值得明確指出的一點是：Solana 本身使用 Gossip 協議進行叢集資訊共享和協議元數據交換，但 Turbine 在區塊傳播這一特定任務中取代了 Gossip。正是 Turbine 的分層樹結構在規模化區塊分發方面優於 Gossip 的平面拓撲。
Ethereum 的 Gossip 協議（驗證者將區塊廣播給隨機的同行子集，後者再重新廣播給他們的同行，通過多輪傳播至整個網絡）實現起來較為簡單，且產生的同行選擇更均勻，不會根據質押量偏好任何驗證者。這種設計反映了 Ethereum 對廣泛去中心化和無許可參與的優先考量。權衡之下則是傳播速度：在大型驗證者集合中的多輪 Gossip 導致區塊時間以秒而非毫秒計。
Turbine 與 BitTorrent 協議有兩點不同，這是上表未能完全涵蓋的。BitTorrent 使用平面的點對點群集（swarm），所有參與者地位平等；Turbine 使用具有質押加權中心位置的分層樹。BitTorrent 對文件組裝沒有時間限制；Turbine 必須在 400 毫秒的時段視窗內完成交付，否則將錯過共識。這些差異是針對區塊鏈特定要求的設計回應，而 BitTorrent 模型並未面臨這些要求。
Avalanche 的 Snowflake/Snowball DAG 傳播採取了不同的方法：對小型驗證者子集進行重複隨機輪詢，以達成機率性共識，而無需單一區塊領導者模型。該設計透過採樣而非樹狀結構提供次線性頻寬擴展，並產生比 Ethereum 更快的最終性，但與 Turbine 基於碎片的方案仍有根本不同。每種設計都在速度與去中心化，以及容錯與複雜性之間做出了不同的權衡。表格展示了這些權衡；宣稱某種架構更優越將會誤導對設計空間的理解。
Solana 架構中的 Turbine：全部 8 項創新
Turbine 是 Anatoly Yakovenko 在 2017 年 Solana 白皮書中提出的八項架構創新之一，每項創新旨在解決區塊鏈基礎設施中不同的性能瓶頸。完整清單如下：
- 歷史證明 (PoH): Solana 的加密計時機制，一種可驗證延遲函數，可創建事件順序的歷史記錄，而無需驗證者通過通訊來商定時間。PoH 不是共識機制，它是一個時鐘。它定義了 Turbine 運行的時段結構。
- Tower BFT: Solana 基於權益證明的共識機制，是實用拜占庭容錯 (PBFT) 的變體，利用 PoH 時鐘減少達成最終性時的消息開銷。
- Turbine: 區塊傳播，本文的主題。Turbine 透過碎片和鄰近樹將新產生的區塊分發給所有驗證者。
- Gulf Stream: Solana 的交易轉發協議。Gulf Stream 在當前區塊完成最終確定前，將未確認交易轉發給預期的下一個區塊領導者，縮短了領導者組裝區塊所需的時間。
- Sealevel: Solana 的並行智能合約執行引擎，可同時而非順序處理數千個不重疊的智能合約。
- Pipelining: 交易處理流水線，將交易驗證的不同階段分配給專用硬體，允許在不同的處理階段並行驗證多個區塊。
- Cloudbreak: Solana 的水平擴展帳戶資料庫，針對驗證者存儲硬體的並行讀寫進行了優化。
- Archivers: 分佈式賬本存儲節點，將歷史區塊鏈數據從驗證者卸載到單獨的存儲層，降低驗證者的硬體要求。
Gulf Stream 和 Turbine 在交易生命週期中順序運行。Gulf Stream 在區塊生產開始前將未確認交易轉發給預期的區塊領導者；一旦生產完成，Turbine 隨即將生成的區塊向外分發給所有驗證者。這兩個協議共同處理了從提交到全網分發的完整交易生命週期。
這八項創新是由 Solana Labs 聯合創始人 Anatoly Yakovenko 在 2017 年發表的原版 Solana 白皮書中提出的。
驗證者視角
Turbine 的鄰近樹位置會影響驗證者的硬體要求。位於 Layer 1（較靠近區塊領導者）的驗證者會先收到碎片，且必須將其轉發給大約 200 個 Layer 2 驗證者，這比僅轉發給指定子鄰域的 Layer 2 驗證者需要更高的上傳頻寬。質押水平決定了樹中的位置：高質押驗證者佔據 Layer 1 位置，並應據此配置資源。營運者應諮詢 Solana Labs 當前的硬體建議，因為最低規格自主網啟動以來已有所演進。
Turbine 的演進：從 2017 年白皮書到今天
Turbine 最初是在 Solana Labs 的 Anatoly Yakovenko 於 2017 年撰寫的原版 Solana 白皮書中規定的，這使其成為該協議的創始架構決策之一，而非後來添加的功能。2017 年的規範確立了核心設計：基於碎片的區塊碎分、用於分發的扇出樹（fanout tree）以及用於容錯的 Reed-Solomon 糾刪碼。
Solana 的主網測試版於 2020 年 3 月啟動，首次將 Turbine 投入生產。初始部署確認了設計的核心屬性，但也暴露了理論規範未能完全預見的現實情況，特別是交易擁塞與傳播負載之間的交互作用。
在經歷了 2021 年和 2022 年的網路壓力事件後，Solana Labs 對 Turbine 的擁塞處理進行了工程改進，包括調整在高網路負載下 shred 分片的排隊和傳輸方式。這些改進並未改變協議的基礎架構，但改善了其在極端運行情況下的表現。
Turbine 目前已在一個每日處理數百萬筆交易的網路中連續運行了四年多。這一生產記錄為「Turbine 是經過驗證的方法還是實驗性方法」的問題提供了明確的答案：它是一個經過大規模實戰測試的生產協議，其工程血統可追溯至 2017 年的規範。有關目前的協議參數和最近的工程變更，請參閱 Solana Labs 工程部落格.
關於 Solana Turbine 區塊傳播的常見問題
以下問題針對有關 Solana Turbine 設計與性能最常見的疑問。
什麼是 Solana Turbine？
Turbine 是 Solana 用於在其 400 毫秒時段窗口內將新生成的區塊傳送給網路中每個驗證者的協議。它的工作原理是將區塊粉碎成分片 (shreds)，並通過分層鄰域樹進行路由，由里德-所羅門糾錯碼 (Reed-Solomon erasure coding) 處理傳輸中丟失的任何數據包。其結果是實現了快速、高頻寬效率的區塊分發，且能隨著驗證者數量的增加而擴展。
Solana 中的 shred 是什麼？
shred 是 Turbine 用於區塊傳輸的基礎數據包，大小約為 1.5 KB。共有兩種類型：攜帶原始區塊內容的數據分片 (data shreds)，以及由里德-所羅門糾錯碼生成的冗餘分片 (coding shreds)，後者允許在某些數據分片於傳輸中丟失時重建區塊。
區塊領導者將區塊拆分為數據分片，並通過里德-所羅門編碼生成編碼分片。這些分片通過鄰域樹流動：區塊領導者發送給大約 200 個 Layer 1 驗證者，每個驗證者再轉發給大約 200 個 Layer 2 驗證者，在兩到三層內覆蓋完整的活躍驗證者集，並在約 400 毫秒的時段窗口內完成。
為什麼 Solana 的區塊傳播比以太坊快？
Solana 使用 Turbine 的分層鄰域樹，它能同時在多個驗證者之間並行分發分片，實現 O(log n) 的頻寬擴展。以太坊使用傳言協議 (gossip protocol)，需要多輪隨機節點重播才能達到全網覆蓋，產生的區塊時間約為 12 秒，而 Solana 的時段時間約為 400 毫秒。這兩種設計都反映了刻意的架構優先級。
Turbine 安全嗎？
Turbine 包含隨機路由（鄰域樹在每個時段使用可驗證隨機性重新洗牌）、里德-所羅門冗餘（容許約三分之一的數據包丟失）以及權益加權定位。隨機路由使得日蝕攻擊 (eclipse attacks) 更難執行。權益加權引入了輕微的中心化權衡：高質押驗證者會更早收到分片，形成結構性優勢，而 Tower BFT 的共識規則部分抵消了這一點。
如果分片丟失會發生什麼？
當數據包丟失率保持在總分片的大約三分之一以下時，里德-所羅門糾錯碼允許驗證者從存留的數據分片和編碼分片中重建完整區塊。超過該閾值時，驗證者會向持有缺失分片的相鄰驗證者發送修復請求。如果修復無法在時段窗口內完成，該時段可能會被跳過。
Turbine 會產生中心化風險嗎？
Turbine 的權益加權確實為高質押驗證者創造了結構性優勢，他們能更早收到分片並在鄰域樹中佔據更高位置。這是一個真實的權衡。緩解因素包括 Solana 分佈在 2,000 多個活躍驗證者中、Tower BFT 共識規則限制了早期獲取分片的價值，以及 Solana 基金會旨在擴大權益分佈的權益委派計劃。
誰創造了 Solana Turbine？
Turbine 由 Solana Labs 聯合創始人 Anatoly Yakovenko 設計，並首次在 2017 年發表的 Solana 白皮書中載明。Solana Labs（負責工程的組織，不同於處理生態系統治理的 Solana 基金會）負責維護並持續開發該協議。
Turbine 與 Gulf Stream 有什麼關係？
Gulf Stream 和 Turbine 是 Solana 交易生命週期中的連續協議。Gulf Stream 在區塊生成開始前，將未確認的交易轉發給預期的區塊領導者，以便領導者無需等待交易到達即可開始組裝區塊。區塊生成完成後，Turbine 再將成品區塊向外分發給所有驗證者。
Solana 每秒可以處理多少筆交易 (TPS)？
根據 Solana 白皮書，在理想條件下，Solana 的理論最大值約為 65,000 TPS。在現實情況下，根據 Solana Labs 的性能文件，截至 2024-2025 年，觀察到的非投票 TPS 通常在 2,000 到 4,000 之間。有時引用的較高 TPS 數字包含了驗證者投票交易，這些是內部共識訊息，而非用戶交易。
相關 Solana 指南
在 Bybit 上探索 SOL
讀者可以查看 目前的 SOL 市場資訊 或 SOL/USDT 現貨市場.。這些連結提供市場資訊與進入管道，並不代表對技術主張的背書，也不暗示 SOL 適合每位讀者。
結論：為什麼 Turbine 對 Solana 的未來至關重要
Turbine 是使 Solana 約 400 毫秒時段時間成為可能的工程機制：如果沒有快速、高頻寬效率的區塊傳播，Solana 的驗證者就無法足夠快地接收區塊並對其投票，以維持高吞吐量所需的時段節奏。該設計通過結合基於分片的粉碎、分層樹狀分發和里德-所羅門容錯，解決了真正的擴展性限制，即原始廣播的 O(n) 頻寬問題。
這種設計帶有值得理解的權衡。權益加權的樹狀定位為大型驗證者提供了結構性優勢。隨機路由減輕了日蝕攻擊，但面對資源充足的對手時並不能完全消除攻擊。正如 Solana 2021-2022 年的停機記錄所示，傳播層在極端網路擁塞下可能會承受壓力。這些都不足以否定該設計；它們都是為了換取協議所提供的速度和頻寬效率而做出的架構權衡。
Turbine 自 2020 年起已在生產環境中運行，並根據實際情況進行了改進。隨著 Solana 的驗證節點數量增加，O(log n) 的擴展特性變得越來越重要：驗證節點集合的每一次翻倍僅增加一層樹結構，而非使頻寬成本翻倍。正是這種特性使其設計能夠大規模且持久地運行。Turbine 區塊傳播的速度和可靠性也是 Solana 成為高頻去中心化金融 (DeFi) 應用的可行基礎層的原因，因為傳播延遲直接影響交易確認結果。
關鍵要點
Turbine 是使 Solana 速度聲明可信的工程基礎。理解它如何將區塊分割成片段、透過權重質押的鄰近節點樹進行路由，以及透過 Reed-Solomon 刪除編碼恢復丟失的封包，是評估這些效能聲明是否基於可靠架構的最清晰方式。該設計有真正的優勢和真正的權衡；在對 Solana 的基礎架構進行任何誠實的技術評估時，兩者都應被納入考量。
進一步閱讀與主要來源
以下主要來源為本文主張提供了技術基礎。
- Turbine 區塊傳播 (Solana 文件): 由 Solana Labs 工程師維護的 Turbine 官方技術文件。
- Anatoly Yakovenko (2017) 的原始 Solana 白皮書：Turbine 和所有八項 Solana 架構創新的創始規格。
- Solana Labs 工程部落格：來自 Solana Labs 的最新工程更新、協議改進和事後分析。
- Solana GitHub: turbine 原始碼: 供開發人員直接檢視 Turbine 實作的原始碼。
- Solana 基金會網路統計：目前的驗證節點數量、質押分配數據和網路健康指標。
本文僅供教育目的，不構成財務或投資建議。加密貨幣投資具有重大風險。在做出任何投資決定前，請務必自行研究。