Solana 交易流水線：TPU 四階段流水線

本技術指南將解釋 Solana 交易流水線的 TPU 四階段流程，以及它如何支援並行處理。

Solana 大約每 400 毫秒產生一個新區塊。大多數區塊鏈一次處理一個交易，等待每個交易完成後再開始下一個。Solana 則不然。

Solana 交易流水線 是 Solana 的交易處理單元將傳入交易移動經過四個順序階段的方法：提取 (Fetch)、簽名驗證 (SigVerify)、銀行處理 (Banking) 和寫入 (Writing)。多個交易批次同時通過這些階段，因此當一個批次正在寫入分佈式賬本時，下一個批次已經在被驗證，而第三個批次已經在被提取。這種並行處理使 Solana (SOL) —— Solana 區塊鏈（記錄所有交易的分佈式賬本）的原生資產 —— 能夠實現遠超大多數第 1 層網絡的吞吐量數據。

Solana 由前 Qualcomm 工程師 Anatoly Yakovenko 創立，他於 2017 年發表了歷史證明白皮書，介紹了使流水線速度成為可能的加密時鐘機制。Solana Labs 是位於舊金山、開發該協議的機構，它將流水線技術作為驗證者客戶端的核心功能予以實施。結果是該網絡已成為去中心化金融 (DeFi) 應用的領先平台，包括去中心化交易所、借貸協議以及需要亞秒級交易最終確定的鏈上衍生品市場。

廣為引用的區塊鏈三元悖論認為，區塊鏈只能在三個屬性中優先考慮兩個：可擴展性、安全性和去中心化。Solana 的交易流水線是其在可擴展性維度上的架構解答。本文涵蓋了什麼是流水線技術、TPU 四個階段如何在機械上運作、歷史證明如何賦能流水線、Gulf Stream 和 Turbine 如何封裝流水線的輸入與輸出、Sealevel 如何將流水線原則延伸到智能合約執行、Solana 在架構上如何與 Ethereum 相比，以及流水線已記錄的權衡與限制所在。

目錄

1. 什麼是 Solana 交易流水線？（以及為什麼它對 SOL 至關重要）
2. Solana TPU 流水線如何運作：四階段解析
3. 歷史證明 (PoH)：使流水線成為可能的加密時鐘
4. Gulf Stream：交易如何在流水線就緒前進入
5. CPU 流水線類比：為什麼 Solana 的架構讓工程師感到熟悉
6. Turbine：流水線輸出如何傳送到網絡
7. Sealevel：將流水線延伸至智能合約執行
8. Solana vs. Ethereum：流水線架構比較
9. 局限性、擁堵與 Solana 流水線架構的權衡
10. 關於 Solana 交易流水線的常見問題
11. Solana 交易流水線與 SOL 投資論點

什麼是 Solana 交易流水線？（以及為什麼它對 SOL 至關重要）

Solana 交易流水線是一種將交易處理分解為不同階段，並在多個交易批次中並行運行這些階段的技術，因此沒有任何驗證者硬體會因為等待另一個階段完成而處於閒置狀態。這可以把它想像成汽車組裝線：不同的車輛同時位於不同的工作站，流水線絕不會為了等待一輛車完全組裝完成，才讓下一輛車進入。

Solana 從電腦處理器中借鑑了這個概念。現代 CPU 通過指令級流水線實現高吞吐量：當一條指令正在執行時，下一條指令正在被解碼，而再下一條指令已經被提取。Solana 將同樣的邏輯應用於驗證者層級的交易。CPU 階段與 Solana TPU 階段的完整映射將在下文的 CPU 類比章節中涵蓋，但核心原則是相同的：讓每個階段始終保持忙碌。

大多數區塊鏈按順序處理交易，這意味著驗證者必須在開始下一個交易（或批次）之前，完成對前一個交易（或批次）的所有處理。這種順序模型創造了一個完全由單個操作鏈運行速度決定的吞吐量上限。流水線技術通過在專用硬體組件上並行運行多個操作來突破這一上限，在不要求每個單獨階段運行更快的情況下，縮短了確認延遲（從提交交易到完成最終確定之間的時間）。

根據 Solana 的技術文件，其理論 TPS 約為 65,000 次交易/秒。這代表了理想條件下流水線的最大值。現實世界的非投票 TPS 實質上較低，通常在 2,000 到 4,000 TPS 之間，具體取決於網絡負載和交易組成。Solana 將驗證者投票交易與用戶生成的非投票交易分開計算；包含投票的總 TPS 數據更高，但作為面向用戶的吞吐量指標意義較小。相比之下，Ethereum 在第 1 層（Layer-1）每秒處理約 15 到 30 次交易，而 Bitcoin 每秒處理約 7 次交易。

關鍵數據

Solana 的 TPU 流水線每約 400 毫秒產生一個新區塊，比 Ethereum 約 12 秒的區塊時間快了約 30 倍。 理論 TPS：~65,000。現實世界非投票 TPS：~2,000-4,000（隨網絡負載而異）。

TPS 方法論註記：65,000 的數字是來自 Solana 技術文件的理論最大值。現實世界的非投票吞吐量隨網絡狀況而異。投票交易不包含在 2,000-4,000 的數字中。Ethereum 的數據代表第 1 層吞吐量，且不包含第 2 層解決方案。

實現這一點的機制是 Solana 的 交易處理單元 (TPU)，這是一個在每個領導驗證者內部運行的四階段流水線。下一節將解釋該流水線在機械層面上是如何運作的。

Solana TPU 流水線如何運作：四階段解析

Solana 高速背後的機制是位於 交易處理單元 (TPU) 中的四階段流水線，該單元在每個時隙的領導驗證者內部運行，通過每個階段的專用硬體同時處理多個交易批次。

什麼是交易處理單元 (TPU)？

在 Solana 中，交易處理單元 (TPU) 是每個驗證者節點內部的流水線引擎，負責物理執行交易處理。這是 Solana 的領域特定術語，與 Google 用於機器學習的 Tensor Processing Unit 無關。

TPU 在每個約 400 毫秒的時段（Slot）內僅在**領導驗證者（Leader Validator）**上運行。非領導驗證者則運行交易驗證單元（TVU），負責重放並驗證領導者產生的區塊。Solana 透過確定的領導者排程（Leader Schedule）來決定哪位驗證者擔任領導者，該排程會為每個紀元（Epoch，約 2 到 3 天）提前發佈，並根據每個驗證者的質押權重分配其領導時段。正如稍後 Gulf Stream 章節所述，此排程正是讓 Gulf Stream 的交易預路由（Pre-routing）成為可能的關鍵。

有關 TPU 架構的技術細節，請參閱 Solana 官方 TPU 文件) 以及 Solana 時段時間文件.)

Solana TPU 管線的四個階段

TPU 管線透過四個順序階段處理交易，每個階段由專用硬體處理，在將其輸出傳遞到下一階段的同時，同步接收來自前一階段的新輸入。

1. 擷取 (Fetch)： 網路堆疊透過 QUIC（一種現代傳輸協定，取代了原始的 UDP 連接以改善擁塞控制）接收原始交易數據包。Fetch 階段是管線的入口，它從 Gulf Stream 在時段開始前就已經填滿的預載緩衝區中拉取交易，並將驗證後的數據包傳遞給 SigVerify。

2. 簽章驗證 (SigVerify)： GPU 驗證傳入交易的加密簽章。每筆 Solana 交易都包含一個或多個數位簽章，在發生任何狀態變更之前必須先進行驗證。GPU 加速允許數千個簽章驗證在此單一階段中平行運行。SigVerify 是身分驗證檢查站：通過的交易移至 Banking 階段；失敗的交易則被捨棄。

3. 銀行業務 (Banking)： CPU 將驗證過的交易應用於帳本狀態，執行帳戶扣款與入帳，並處理智能合約的狀態變更。Banking 是管線的會計部門，也是計算量最密集的階段。它也是高負載下的主要瓶頸：當交易量超過 Banking 的處理能力時，管線會開始捨棄交易而非將其排隊。

4. 寫入 (Writing)： NVMe SSD 將確認的帳本條目寫入磁碟，該階段並透過 Turbine 將生成的區塊數據廣播到網路的其他部分。Writing 是派遣與記錄階段：一旦完成，區塊便存在於鏈上並開始傳播。

核心管線機制在所有四個階段同時運作。當批次 N 處於 Banking 階段時，批次 N-1 已在 Writing 階段，而批次 N+1 則已在 SigVerify 階段。沒有任何階段會等待另一個階段完成目前批次後才開始下一個。這就是管線實現平行吞吐量的方式：在時段內的每一刻，每一件硬體都被佔用。

[需要圖表：DIAGRAM-01] 四階段管線顯示批次 A、B、C、D 同時處於不同階段。批次 A：寫入 (NVMe SSD)。批次 B：銀行業務 (CPU)。批次 C：簽章驗證 (GPU)。批次 D：擷取 (網路)。箭頭顯示每個批次在各階段的進展，以及跨四個階段的同步運作。

誰運行管線？驗證者與領導者排程

Solana 驗證者是實際運行 TPU 管線的節點營運商。每個驗證者都是運行 Solana 軟體的專用伺服器，負責產生區塊（如果它是目前的領導者）或驗證並重放由領導者產生的區塊（使用 TVU）。

領導者排程分配了哪位驗證者負責每個約 400 毫秒時段的 TPU 運行。該排程在每個紀元開始時根據權重質押的驗證者集合確定性地計算出來，因此驗證者可以提前數天知道他們即將到來的領導時段。這種可預測性使 Gulf Stream 能夠在時段開始前將交易預路由給即將到來的領導者，確保 Fetch 階段的緩衝區在時段開始時就已處於已成交（填滿）狀態。

運行 TPU 管線需要企業級硬體：用於 SigVerify 階段的專用 GPU、用於 Banking 階段的高核心數 CPU、用於 Writing 階段的企業級 NVMe SSD，以及用於 Fetch 階段的高頻寬網路。這些要求顯著高於以太坊的驗證者硬體門檻，這在限制章節中提到會產生中心化的權衡。有關目前的驗證者硬體規格，請參閱 Solana 驗證者需求文件.)

歷史證明：讓管線化成為可能的加密時鐘

歷史證明 (Proof of History, PoH) 是一種加密機制，它允許 Solana 的管線以硬體允許的最快速度運行，而不需要驗證者在進入下一階段之前相互通信以就每批交易的時間達成共識。

該機制的運作方式如下：PoH 產生連續的 SHA-256 哈希序列，其中每個哈希都以前一個哈希作為輸入。由於 SHA-256 計算需要可測量且可驗證的時間量，生成的哈希序列便構成了一種加密證明，證明鏈上記錄的任何兩個事件之間已經過了一段特定的時間。每個驗證者都可以獨立驗證此序列，而無需聯繫其他驗證者。

與管線化的連結是直接的。如果沒有 PoH，管線就必須在每個階段暫停，等待網路就當前交易批次的排序達成共識，然後才能開始下一階段。這種節點間通信的往返將成為主要的延遲因素，使得在網路規模下實現 400 毫秒的時段時間變得不可能。PoH 透過提供一個所有驗證者都可以在本地檢查的共享、可驗證時鐘來消除這種等待。管線是根據 PoH 時鐘前進，而不是根據網路訊息的往返。

Anatoly Yakovenko 在 2017 年發佈的 歷史證明白皮書) 中介紹了歷史證明，這源於他在 Qualcomm 任職期間於分散式系統方面的背景。

PoH 不是權益證明（Proof of Stake）。

歷史證明不是 Solana 的共識機制。它是一個對事件進行排序並證明流逝時間的加密時鐘。Solana 使用權益證明（具體為 Tower BFT，其對實用拜占庭容錯的實現）來進行共識，這決定了哪些驗證者在經濟上有資格參與，以及誰領導每個時段。PoH 提供排序與計時。權益證明提供經濟安全性與抗女巫攻擊能力。這些是截然不同的功能。

有關歷史證明運作方式的完整解釋，包括其加密結構及其與 Solana 共識機制的關係，請參閱我們的 [歷史證明專題說明]。

PoH 提供時鐘。Gulf Stream 確保管線的收件箱始終是滿的。

Gulf Stream：交易如何在管線準備好之前進入

Gulf Stream 是 Solana 的交易轉發協定，它確保管線的 Fetch 階段永遠不會因為等待交易到達而閒置。大多數區塊鏈將未確認的交易保存在全域內存池中，等待任何驗證者提取。Solana 沒有全域內存池。Gulf Stream 以確定的預路由取代了這種模型。

該機制分四個步驟運作：

1. Solana 的領導者排程提前發佈哪位驗證者將領導即將到來的每個約 400 毫秒時段。
2. 當用戶或應用程式提交交易時，Gulf Stream 將其直接路由到領導下一個相關時段的驗證者，而不是路由到共享池。
3. 在該驗證者的領導時段開始時，其 Fetch 階段緩衝區已經預載了交易。
4. Fetch 階段從此預載緩衝區中拉取交易，而不是等待交易在時段期間到達。

這種無內存池 (mempool-less) 的設計產生了三個可衡量的優勢：它縮短了確認延遲，因為交易等待的時間減少了；它消除了全局內存池強加給每個驗證者的記憶體開銷；並且大幅降低了每個驗證者的記憶體需求。

權衡之處也非常顯著：由於沒有持久的交易緩衝區，未被快速處理的交易會被丟棄而非排隊。使用者會收到「交易過期」錯誤，並且必須重新提交。在高網路負載下，這種行為是導致擁塞事件的機制之一，正如在限制章節中所討論的。

Gulf Stream 直接連接到獲取 (Fetch) 階段。

Gulf Stream 使用確定性的領導者排程 (Leader Schedule) 將交易預先路由給即將到任的領導者。當驗證者的 TPU 獲取階段啟動時，它會從預先載入的緩衝區中提取，而非全局內存池。這就是為什麼在正常情況下，Solana 的流水線很少在獲取階段等待輸入的原因。

如果說 Gulf Stream 是流水線的輸入機制，那麼 Turbine 就是輸出機制。

CPU 流水線類比：為什麼 Solana 的架構對工程師來說應該感到熟悉

Solana 的交易流水線借鑒了使現代 CPU 變快的相同架構原理：指令級流水線 (instruction-level pipelining)。這不僅是一個隱喻。該設計的架構靈感來自 Patterson 與 Hennessy 的基礎著作《電腦組成與設計》(Computer Organization and Design) 中描述的相同吞吐量技術。

CPU 指令流水線的工作原理如下：CPU 並非等待一條指令完成所有處理階段後才獲取下一條，而是將執行分解為連續的階段（獲取 Fetch、解碼 Decode、執行 Execute、寫回 Write-back），並在不同的指令上同時運行這些階段。當指令 N 正在執行時，指令 N+1 正在被解碼，而指令 N+2 已經被獲取。其結果是，吞吐量的增加與流水線階段的數量成正比，而不需要任何單個階段運行得更快。

Solana 的 TPU 流水線將此相同原理應用於交易。各階段的映射是直接的：

[需要圖表：DIAGRAM-02] 並排對比圖。左側：CPU 指令流水線，包含獲取、解碼、執行、寫回階段，並帶有顯示並行指令處理的波浪箭頭。右側：Solana TPU 流水線，包含獲取、簽名驗證、銀行業務、寫入階段，並帶有顯示並行批次處理的波浪箭頭。類比階段之間有映射線連接。

類比成立之處： 兩種架構都通過讓所有階段同時保持佔用來獲得吞吐量增益。兩者都不會等待一個項目完成後才開始下一個。兩者都以波浪式處理項目，在任何給定時刻都有多個項目處於不同的階段。其核心洞察是相同的：順序處理浪費硬體能力；流水線並行則消除了這種浪費。

類比失效之處： 三個重要的區別將 Solana 的流水線與 CPU 流水線區分開來。

第一，Solana 的流水線運作於通過網路連接的分散式硬體組件之間，而非單個晶片內部。網路狀況對流水線性能的影響，在 CPU 中沒有對應的情況。

第二，故障模式不同。CPU 流水線衝突包括數據依賴（一條指令需要尚未完成的前一條指令的輸出）和分支預測錯誤（處理器在錯誤的路徑上獲取了指令）。Solana 的流水線衝突性質不同：交易垃圾郵件作為一種結構性衝突，會使銀行業務階段超載，超出其處理能力；而網路擁塞則作為一種停頓條件，會減慢獲取和寫入階段。這些是外部的、由需求驅動的衝突，而非內部的、由數據依賴引起的衝突。

第三，Solana 的流水線沒有與亂序執行 (out-of-order execution) 對應的機制。歷史證明 (Proof of History) 時鐘在每個批次內強制執行嚴格的交易排序，因此流水線無法像 CPU 重新排序指令以避免數據衝突那樣，為了避免衝突而重新排序交易。

理解這一類比及其局限性，是區分對 Solana 速度的表面認知與真正的架構洞察的關鍵。

Turbine：流水線的輸出如何到達網路

Turbine 是 Solana 的區塊傳播協定，它處理流水線寫入階段完成後的後續工作。如果說 Gulf Stream 確保流水線始終有輸入，那麼 Turbine 則確保流水線的輸出能以最高效率到達網路的其餘部分。

在寫入階段將一批確認的交易提交到帳本後，Turbine 將產生的區塊分解為較小的數據包，稱為 shreds，並通過驗證者的樹狀結構網路進行傳播。Turbine 並非同時向每個驗證者廣播完整區塊（這需要領導者具備巨大的上行頻寬），而是將傳播負載分散到整個網路。樹中的每個驗證者接收一部分 shreds 並將其轉發給樹中更下游的其他驗證者，其原理類似於 BitTorrent 通過多個節點共享分發負載來分發文件。（Turbine 使用結構化樹而非點對點群集，這對於網路可靠性來說是一個重要的區別。）

相容流水線的設計在此至關重要：當領導驗證者已經在通過流水線處理下一個交易批次時，shreds 就已經開始向網路其餘部分傳播。區塊傳播與區塊生產是並行運作的。區塊 N 的網路級傳播不會導致區塊 N+1 的生產暫停。

工程上的優勢在於，Solana 實現了高區塊頻寬，而不需要每個驗證者節點都具備企業級的上行鏈路。只有領導驗證者承擔全部生產負載；傳播則分散在整個網路中。

TPU 流水線的輸入/輸出封裝：

Gulf Stream：流水線輸入（在時段開始前預先將交易路由給即將到任的領導者）。 Turbine：流水線輸出（通過驗證者樹狀網路以 shreds 形式分發已驗證的區塊數據）。 兩者結合，確保 TPU 流水線在任何一端都不會閒置。

Turbine 在區塊層級處理流水線的輸出。Sealevel 則將流水線原理延伸得更深，直達智能合約執行層。

Sealevel：延伸至智能合約執行的流水線技術

交易流水線並非止步於 TPU。Sealevel 將相同的並行處理原理延伸到智能合約執行，這是 Solana 最常被低估的架構優勢之一。

Sealevel 是 Solana 的並行智能合約運行環境。它允許成千上萬的智能合約（在 Solana 架構中稱為程式，這與以太坊術語的區別對開發者而言很重要）同時執行而非順序執行。以太坊的 EVM（以太坊虛擬機）在單執行緒上處理智能合約，這意味著每個區塊一次只能執行一個合約。Sealevel 則利用所有可用的 CPU 核心來並行執行多個程式。

該機制依賴 Solana 的帳戶模型。每個 Solana 交易都必須預先聲明它將讀取和寫入哪些帳戶。Sealevel 使用這些聲明將交易分類到不重疊的群組中：存取不同帳戶的交易可以同時執行，而不會有狀態衝突的風險；而共享帳戶的交易則必須按順序處理，以確保正確性。

這種預先聲明的要求是 Solana 開發人員在設計程式時必須考慮的設計限制。程式必須預先聲明它們將存取的所有帳戶，這與以太坊更寬鬆的狀態存取模型不同，後者在存取合約儲存時無需預先聲明。

與 TPU 管道化的平行處理是直接的。正如 TPU 管道透過同時處理不同階段的不同交易批次來讓所有四個硬體階段保持忙碌一樣，Sealevel 也透過同時執行不衝突的程式來讓所有可用的 CPU 核心保持忙碌。讓所有硬體始終保持忙碌的原則在這裡應用於執行層。

有關帳戶聲明和 Solana 帳戶模型實際如何運作的更深入探討，請參閱我們的 [Solana 帳戶模型說明] 文章。

Solana 與以太坊：管道架構比較

Solana 與以太坊之間的效能差異可追溯到一個根本性的架構選擇：平行管道處理與依序交易執行。

以太坊的 EVM 以單一線程佇列處理交易。一筆交易必須先完成，下一筆才能開始。這種設計是有意為之的：依序執行簡化了狀態管理，使智能合約行為更容易理解，並允許驗證者使用消費級硬體參與，從而產生廣泛且相對去中心化的驗證者集合。以太坊目前約有 900,000 或更多活躍驗證者。

相比之下，Solana 的平行 TPU 管道透過四個專用硬體階段同時處理多個交易批次。GPU 加速簽名驗證。CPU 透過 Sealevel 同時對非衝突程式應用狀態變更。NVMe SSD 處理寫入，而 Turbine 同時執行傳播。這種設計產生了顯著更高的 Layer-1 吞吐量，但它需要更多的硬體，並造就了約 2,000 名活躍驗證者的更集中的驗證者集合。

效能數據是具體的。以太坊的區塊時間約為 12 秒；Solana 的槽時間約為 400 毫秒。以太坊的 Layer-1 TPS 約為 15 至 30；Solana 的真實世界非投票 TPS 約為 2,000 至 4,000，取決於網路狀況。（作為參考，比特幣每秒處理約 7 筆交易。）以太坊的 Layer-2 解決方案，包括 Arbitrum 和 Optimism，將以太坊的實際吞吐量從其 Layer-1 基線大幅提升，在比較原始 Layer-1 數據時，這是重要的背景。

有關這些架構在投資和開發維度上如何比較的詳細分析，請參閱我們的 [完整的 Solana 與以太坊架構比較] (https://www.bybit.com/en/wiki/article/solana-vs-ethereum-which-to-buy-now/).)

兩種架構都沒有絕對的優勢。兩者都代表了廣受引用的區塊鏈三元悖論中的深思熟慮的權衡。以太坊為了去中心化和豐富的 Layer-2 生態系統而犧牲了吞吐量。Solana 為了 Layer-1 吞吐量而犧牲了去中心化。哪種權衡更適合特定應用程式或投資論點，取決於具體需求。

Solana 管道架構的限制、壅塞與誠實的權衡

Solana 的管道架構提供了有記錄的效能優勢，同時也伴隨著有記錄的權衡。理解兩者對於任何嚴肅的網路評估（無論是開發還是投資）都是必要的。

管道不堪重負時：壅塞如何發生

當交易量超過銀行階段的處理能力時，就會發生管道壅塞。事件順序是特定的。銀行階段落後於進來的交易量。由於 Solana 的無內存池（mempool-less）Gulf Stream 設計不維護持久的交易緩衝區，因此無法快速處理的交易會被丟棄而不是排隊。用戶會收到「交易過期」錯誤，必須重新提交。在極端的壅塞水平下，驗證者可能會脫離共識，因為相對於總交易量，管道無法足夠快地處理投票交易，導致網路停滯。

Solana 在 2021 年 9 月、2022 年 1 月和 2022 年 5 月以及其他時期經歷了重大的網路中斷。原因並非完全相同。在某些情況下，過多的交易量使銀行階段的容量不堪重負。在其他情況下，原因是協調的交易垃圾訊息活動、軟體錯誤或與管道吞吐量限制無關的共識故障。將所有 Solana 中斷歸因於管道化是不準確的。當在特定條件下超過管道容量限制時，會促成某些中斷事件，而其他中斷則有獨立的根本原因。

有關 Solana 網路事件及其原因的記錄歷史，請參閱我們的 [Solana 網路中斷：歷史與對投資者的意義] 文章。

Solana 自 2022 年以來已進行了幾項架構變更，以解決管道壅塞問題：

• 採用 QUIC 協議： Solana 用 QUIC（一種提供 UDP 所缺乏的擁塞控制和連接管理的現代傳輸協議）取代了 Fetch 階段的原始 UDP 連接。QUIC 允許 Fetch 階段在高負載下更智能地管理交易攝入，從而降低低成本交易垃圾訊息的有效性。
• 基於質押的服務品質 (SWQoS)： Solana 引入了基於質押的服務品質 (SWQoS)，該服務會優先處理從質押權重較高的驗證者轉發的交易。這降低了低質押參與者用消耗銀行階段容量的垃圾訊息交易淹沒管道的能力，從而損害了合法用戶交易。
• 優先費用： 用戶可以將優先費用附加到交易中，表明願意在高需求時期為透過管道的更快處理付費。
• Firedancer： Firedancer 是 Jump Crypto 開發的一個獨立驗證者客戶端實現，目前正在開發中，旨在透過提供替代客戶端來減少單一實現風險，從而顯著提高管道吞吐量並增強網路彈性。

Solana 對驗證者硬件的高要求產生了可衡量的去中心化權衡。運行 TPU 流水線需要企業級 GPU 用於 SigVerify 階段、高核心數 CPU 用於 Banking 階段、企業級 NVMe SSD 用於 Writing 階段，以及高頻寬網絡用於 Fetch 和 Turbine。這些規範為家庭驗證者設置了顯著的成本障礙。

結果是驗證者集合比 Ethereum 更集中。Solana 擁有約 2,000 名活躍驗證者；Ethereum 擁有約 900,000 名或更多（這兩個數字都會波動，應根據當前網絡數據進行驗證）。Solana Labs 和 Solana 基金會明確承認了這一權衡：硬件要求是吞吐量優先設計選擇的刻意後果，代表了 Solana 在區塊鏈三元悖論的可擴展性-去中心化軸上的立場。這種權衡是否可以接受，取決於評估者的優先考量。

常見問題：Solana 交易流水線

什麼是 Solana 的交易處理單元 (TPU)？

Solana 的交易處理單元 (TPU) 是驗證者節點內實際處理交易的流水線引擎。這是 Solana 的專用術語，與 Google 用於機器學習的 Tensor Processing Unit 完全無關。TPU 僅在每個約 400 毫秒時隙的領導驗證者（leader validator）上運行，並通過四個階段運作：Fetch、SigVerify、Banking 和 Writing。非領導驗證者則運行 TVU（交易驗證單元）來驗證和回放區塊。

什麼是歷史證明，它與流水線有什麼關係？

歷史證明 (PoH) 是一個加密時鐘，可產生可驗證的、按時間排序的 SHA-256 哈希序列。PoH 通過消除驗證者在推進每個流水線階段之前進行溝通並就交易排序達成一致的需求，從而實現流水線化。如果沒有 PoH，節點間的通信延遲將成為主要瓶頸；有了 PoH，流水線基於共享的、本地可驗證的時鐘推進，無需網絡往返。

什麼是 Solana 中的 Gulf Stream？

Sealevel 是 Solana 的平行智能合約運行環境。它通過要求每筆交易預先聲明將讀取和寫入哪些帳戶，允許數千個智能合約（在 Solana 架構中稱為程序）同時執行。Sealevel 識別非重疊的交易，並在所有可用的 CPU 核心上平行運行它們，將同樣的平行處理原則從 TPU 流水線擴展到智能合約執行層。

流水線擁塞導致了一些 Solana 停機事件，但並非全部。當交易量超過 Banking 階段的容量時，無內存池設計會導致交易被丟棄而非排隊，在極端擁塞時，驗證者可能會脫離共識。Solana 還經歷過由軟件漏洞、共識失敗以及與流水線吞吐量限制無關的協調交易垃圾郵件引起的停機。自 2022 年以來，QUIC 的採用和 SWQoS 已減少了由擁塞引起的故障。

Solana 的理論 TPS 約為 65,000，代表了根據 Solana 技術文檔在理想條件下流水線的最大值。實際環境中的非投票 TPS 通常在 2,000 到 4,000 之間，具體取決於網絡負載、交易類型構成和驗證者表現。Solana 將驗證者投票交易與用戶生成的交易分開計算；包含投票的總數較高，但作為面向用戶的性能指標意義較小。

Solana 如何比 Ethereum 更快？

Solana 的四階段平行 TPU 流水線同時處理多個交易批次，而 Ethereum 的 EVM 則是在單線程上按順序處理交易。結果是：Solana 的時隙時間（slot time）約為 400 毫秒，而 Ethereum 的區塊時間約為 12 秒；Solana 的 Layer-1 TPS 約為 2,000 至 4,000，而 Ethereum 則約為 15 至 30。這兩種架構都代表了在區塊鏈三元悖論中具有不同權衡的刻意設計選擇。

當 Solana 流水線發生擁塞時會發生什麼事？

當交易量超過 Banking 階段的處理能力時，Solana 會丟棄交易而不是將其排隊，因為無內存池的 Gulf Stream 設計不會維持持久緩衝區。受影響的交易會返回「交易已過期」錯誤，並且必須重新提交。在嚴重擁塞時，投票交易的處理可能會滯後，導致驗證者脫離共識。QUIC 和 SWQoS 減輕了垃圾訊息驅動的擁塞影響，儘管底層的容量限制仍然是已知的架構權衡。

在 Bybit 探索 SOL

使用 Solana 價格頁面 查看目前的 SOL 市場數據，或者如果現貨交易符合您的目標，請訪問 SOL/USDT 現貨市場。Bybit 交易活動與提交 Solana 鏈上交易不同；在 Solana 網絡上充值或提現 SOL 時，仍可能產生網絡費用。

經驗豐富的衍生品交易者也可以查看 SOLUSDT 永續市場.。衍生品涉及額外風險，且不提供現貨 SOL 的所有權。

Solana 交易流水線與 SOL 投資論點

Solana 的交易流水線是真正的架構創新，而非行銷口號。四階段 TPU 流水線代表了 Layer-1 吞吐量的一種連貫工程方法。歷史證明（Proof of History）提供了加密時鐘，讓流水線在沒有網絡共識延遲的情況下推進。Gulf Stream 預先加載流水線的輸入。Turbine 分發流水線的輸出。Sealevel 將同樣的平行化原則延伸到智能合約執行。

對於持有或評估 Solana (SOL) 的投資者來說，理解流水線意味著理解 Solana 性能差異化的技術基礎。該架構的速度優勢是結構性的，而非偶然的。它源於在交易生命週期的每一層應用平行處理原則的具體工程選擇。

這些工程選擇帶來了真正的權衡。2021 年和 2022 年的擁塞事件證明，無內存池設計和 Banking 階段的吞吐量上限在對抗性或極端負載條件下是真實的約束。高驗證者硬件要求產生的驗證者集合比 Ethereum 更集中，這代表了在區塊鏈三元悖論的可擴展性-去中心化軸上的刻意定位。Solana 持續的架構演進，包括 QUIC 的採用、SWQoS 的部署，以及由 Jump Crypto 開發中的 Firedancer 客戶端，反映了一個正積極努力提高這些限制的協議。這些代表了發展軌跡，而非已解決的問題。

Solana 的流水線吞吐量使其成為需要亞秒級交易最終性（finality）之 DeFi 應用程式的有意義平台。Ethereum 仍然是一個具有不同優先級的有效架構選擇：更廣泛的去中心化、成熟的 Layer-2 生態系統以及更大的開發者群體。這兩個網絡在生產級區塊鏈中各具特色。

免責聲明： 本文僅供教育目的，不構成投資建議、財務建議、交易建議或任何其他形式的建議。Solana (SOL) 是一種加密貨幣。加密貨幣是高度波動的資產，具有重大的損失風險。在做出投資決定前，務必進行自己的研究並諮詢合格的財務顧問。

從此主題集群相關閱讀：

• [歷史證明說明]：我們的專門歷史證明解說
• [什麼是 Solana (SOL)？完整指南]：Solana (SOL) 的完整指南
• [Solana 質押：如何賺取 SOL 獎勵]：Solana 質押指南
• Solana 與 Ethereum：完整架構比較: Solana 與 Ethereum 的完整架構比較
• [Solana 中的 Gulf Stream 是什麼？]：Gulf Stream 說明
• [Solana 網路中斷：歷史及其對投資者的意義]：Solana 網路中斷歷史