Solana Sealevel：平行處理引擎

Solana Sealevel 平行處理讓運行時能在交易宣告它們將讀寫的帳戶時，同時執行不衝突的交易。因此，Sealevel 是一種執行模型，而不是一個獨立的共識機制，也不是保證每個工作負載都將平行執行的保證。

本文中的效能數據需要背景說明。廣泛引用的 65,000 TPS 數據是理論或受控測試的基準，並非保證的主網吞吐量。大約 400 毫秒的插槽目標與交易最終確定性不同，費用因簽名、計算使用量、優先級設置和網路條件而異。

以太坊在其基礎層上大約每秒處理 15 筆交易。Solana 文件歷史上曾引用理論或受控條件下的最高 65,000 TPS；實際使用者面向的吞吐量有所不同。這個差距並非偶然。其背後的引擎稱為 Sealevel。

Sealevel 是 Solana 的平行智能合約運行時：一種處理數千筆獨立交易的執行引擎，而不是一次處理一筆。它由 Anatoly Yakovenko 構思，他是一位前高通工程師，創立了 Solana Labs（Solana 核心協議開發公司）並於 2017 年撰寫了基礎性的 Solana 白皮書。

想像一下高峰時段的主要高速公路。Solana (一個區塊鏈，或分散式的防篡改數位帳本) 使用 Sealevel 建造數百條車道，並按目的地對進來的交通進行分類。以太坊上的每輛車都必須使用單一車道。汽車排隊等候，一次前進一輛。Sealevel 按目的地對汽車進行分類：開往不同地址的汽車同時行駛，無需等待。只有開往完全相同地址的汽車才必須排隊。這種分類機制是 Solana 速度優勢背後的架構洞察。

本說明文涵蓋 Sealevel 是什麼、其基於帳戶的平行處理如何機械式運作、與以太坊的執行環境相比如何、其不足之處，以及這些功能對評估 Solana 的開發人員和投資者意味著什麼。

Solana Sealevel 平行處理：快速概覽

• Sealevel 是 Solana 的平行智能合約運行時，可同時處理數千筆交易。
• 運作方式： 交易預先宣告帳戶依賴關係；Sealevel 平行執行不衝突的交易。
• 吞吐量： 理論最大值約 65,000 TPS；實際非投票交易通常可達 2,000–4,000 TPS。
• 與以太坊相比： 以太坊的以太坊虛擬機 (EVM) 一次處理一筆交易；Sealevel 同時處理獨立的交易。
• 誠實的限制： Solana 在 2021 年和 2022 年因 Sealevel 上游的擷取失敗而發生網路中斷。

循序執行 vs. 平行執行：Sealevel 解決的核心問題

循序執行與平行執行是處理區塊鏈交易兩種根本不同的方法，而這種區別解釋了 Solana 與以太坊之間大部分的效能差距。

循序執行意味著一筆交易在下一筆開始前必須完全完成。一筆交易進來，區塊鏈鎖定相關狀態，執行計算，寫入結果，解鎖狀態，然後才開始下一筆交易。每一步都會阻塞後面的一步。沒有重疊，沒有並發，沒有獨立工作的同時處理。

這所造成的吞吐量上限是真實存在的。根據以太坊基金會的文件，以太坊的以太坊虛擬機 (EVM) 在其 Layer-1 (L1) 基礎鏈上（不含 Layer-2 (L2) Rollup）大約每秒處理 15-30 筆交易。這個數字多年來大致保持不變，因為瓶頸在於架構。

更廣泛的挑戰體現在廣泛引用的可擴展性三難困境，即區塊鏈在歷史上難以同時最大化去中心化、安全性和高可擴展性的觀察。循序執行是主要的擴展性限制。增加更快的硬體無法解決它，因為執行模型本身將所有工作串行化通過單一管道。

平行處理提供了不同的答案。與其說有一個收銀員對應所有顧客，不如想像一家超市有 500 個結帳通道。購買完全不同商品的顧客（沒有共用的付款終端，沒有共用的會員帳戶）可以同時在所有通道結帳。只有真正需要共用終端的顧客才必須排隊。商店的總吞吐量增加數倍，不是因為任何單一收銀員變得更快，而是因為獨立的交易不再互相阻塞。

智能合約運行時是執行區塊鏈上智能合約代碼的軟體環境。它是接收程式碼並實際運行它的層。在 Solana 上，智能合約稱為「程式」(Solana 文件中的標準術語，但「智能合約」仍然被廣泛理解並在此互換使用)。Sealevel 是 Solana 的運行時：旨在從頭開始同時運行數千個此類程式，而不是循序執行。

理解 Sealevel 如何安全地實現這一點，而不會出現競態條件或狀態損壞，需要理解使其平行處理安全的架構機制。該機制是 Solana 的帳戶模型。

Sealevel 如何運作：帳戶模型與預先宣告狀態

Sealevel 透過兩種協同工作的架構特性安全地實現平行執行：Solana 的帳戶模型以及歷史證明 (PoH) 提供的交易預排序，PoH 是一種密碼學時鐘機制，為 Solana 網路上的每個事件建立可驗證的時間戳。本節將對兩者進行說明。

Solana 帳戶模型：將程式碼與狀態分離

Sealevel 之所以能夠平行執行交易，是因為 Solana 的帳戶模型在執行開始前就提供了它安全執行所需的資訊。

在 Solana 上，程式僅包含可執行代碼，本身不存儲任何數據。這些是無狀態程式：它們承載指令，但本身不持有任何狀態。數據存在於單獨的帳戶對象中，程式可以讀取或寫入這些對象。這種設計在架構層面上分離了程式碼和狀態。它與以太坊模型不同，後者是一個智能合約將其可執行代碼及其狀態存儲在單一合約地址。

每筆 Solana 交易在執行開始前，都必須預先宣告它將從哪些帳戶讀取以及寫入哪些帳戶。Sealevel 讀取這些宣告以安排執行。跳過此步驟的交易將被運行時拒絕。這不是可選的簿記：它是實現安全平行處理的結構性先決條件。

想像廚房裡有六個爐灶的兩位廚師。廚師 A 正在做義大利麵，需要爐灶一和二。廚師 B 正在做炒菜，需要爐灶四和五。他們可以同時工作而無需任何協調，因為他們的工作檯面沒有重疊。他們都不需要等待對方。只有當兩位廚師同時需要爐灶三時，其中一人才必須等待。Sealevel 將這個確切的邏輯應用於交易：使用不同帳戶的交易平行執行；共用寫入帳戶的交易循序執行。

開發人員注意事項：執行階段會拒絕存取未宣告帳戶的交易。帳戶存取必須在交易建構時確定，而不是在執行期間。此限制是實現下方所述平行排程的設計機制。

Sealevel 如何排程平行執行

當交易到達 Sealevel 時，調度流程遵循四個不同的步驟。

1. 交易到達時會攜帶一份清單（Manifest）：完整列出其將讀取和寫入的帳戶。
2. Sealevel 透過同時比較所有待處理交易的清單，建立一個相依性圖表（反映哪些交易共享帳戶的圖譜）。
3. 不共享任何「寫入帳戶」的交易是相互獨立的。Sealevel 會將它們同時分配到不同的處理器核心，並在所有可用的 CPU 和 GPU 核心上平行執行。
4. 宣告對相同帳戶具有「寫入相依性」的交易則存在衝突。Sealevel 會將這些特定交易序列化，依照 PoH 確立的順序逐一執行，而其他所有非衝突交易則繼續保持平行運行。

這種方法屬於決定性平行處理：Sealevel 在執行開始前就會識別衝突，而不是在事後才解決衝突。它不會推測性地執行交易並針對失敗進行回滾。這使其有別於 Aptos Block-STM 等樂觀併發處理方法，後者會先推測性地執行交易，並在發生衝突時重新執行。

Sealevel 也能將簽名驗證任務路由至 GPU 核心，類似於 GPU 在遊戲或 AI 工作負載中同時執行數千個著色器計算的方式。Solana 的交易處理單元 (TPU) 利用流水線技術 (pipelining) 在硬體單元之間同時執行交易驗證階段，並由 Sealevel 負責處理該流水線中的執行階段。

Sealevel 對比以太坊 EVM：架構上的直接比較

Solana 在基礎層之所以比以太坊快，主要歸因於其平行智慧合約執行環境 Sealevel。雖然以太坊的 EVM 嚴格按順序一次處理一筆交易，但 Sealevel 卻能同時跨越多個處理器核心，處理數千筆獨立交易。

Sealevel 與 EVM 比較

EVM 一次處理一筆交易，是因為其具備狀態的合約架構，使得在架構上難以預先判斷哪些交易可以安全地並行處理。以太坊上的智能合約會存儲各自的狀態。理論上任何兩個合約都可能共享狀態，若無法預先得知哪些交易是獨立的，進行並行處理將面臨損壞狀態的風險。這並非以太坊設計上的缺陷，而是其架構所導致的結果。

Solana 將程式編譯為 Solana 修改後的 eBPF (擴充 Berkeley 封包過濾器) 位元組碼：這是一個改編自成熟的 Linux 原生格式的精簡指令集。Sealevel 以接近原生速度執行此位元組碼。相較之下，EVM 位元組碼則在客製化軟體模擬的虛擬機器上運行。BPF 方法提供了 EVM 客製化格式所沒有的硬體級最佳化路徑，從而促成了 Sealevel 在指令執行層級的吞吐量優勢。

Solana 在架構上有哪些與 Ethereum 不同之處？

• 執行模型： 並行確定性 (Sealevel) vs. 序列式 (EVM)
• 狀態架構： 無狀態程式與獨立的數據帳戶 vs. 有狀態合約
• 擴展方案： L1 並行執行 vs. L2 Rollups 與分片
• 開發語言： Rust vs. Solidity

為了解 Layer-1 區塊鏈架構中帳戶模型的差異，Solana 的預先宣告方法與其他鏈上儲存設計的對比，具有啟發性。

Sealevel 與 Aptos 的 Block-STM 和 Monad：平行執行方法的差異

Sealevel 並非唯一已投入生產的平行執行架構。將其方法與 Aptos Block-STM、Monad，以及 Sui 進行比較，揭示了每個設計所做的獨特取捨。

Aptos 採用 Block-STM (軟體事務記憶體)，一種樂觀並發方法。它投機性地並行執行交易，無需預先聲明帳戶，然後驗證結果，並重新執行任何產生衝突的交易。對開發者而言的優勢：無需在構建時聲明帳戶依賴。權衡：衝突密集的負載會觸發重新執行，這會耗費時間。Sealevel 完全避免重新執行，因為它會在運行前識別出衝突。

Monad 致力於實現具備以太坊 Solidity 相容性的平行 EVM 執行。它將執行階段管線化，並在 EVM 模型之上應用樂觀平行機制。Monad 的觀點是，EVM 相容性所帶來的價值值得其架構上的額外開銷。Sealevel 則做出了相反的選擇：採用全新的帳戶模型以獲得更高的原始平行性，但這要求開發者必須採用新的程式設計範式。

Sui 使用以物件為基礎的所有權作為其並行單位。根據定義，涉及獨立物件的交易會在無需顯式宣告的情況下並行運行。根據目前的技術文件，每種方法（Sealevel 的確定性模型、Block-STM 的樂觀模型、Sui 的物件所有權模型）都代表了對同一個問題的不同答案：如何在大規模情況下實現安全的並行處理。

沒有任何方法是絕對優越的。Sealevel 的預先宣告會產生開發者額外的負擔。Block-STM 的樂觀模型在高衝突負載下會產生重複執行的成本。Monad 以 Solidity 相容性換取原始效能空間。正確的選擇取決於使用案例的需求以及團隊已在其中運行的開發者生態系統。

Sealevel 在 Solana 的八項創新架構中的角色

Sealevel 的平行處理能力之所以安全，是因為歷史證明 (PoH) 在執行開始前已建立了可信的交易順序。理解這種相依關係揭示了 Sealevel 如何融入 Solana 更廣泛的八大創新架構，以及為何不能孤立地評估這些組件。

Solana 的架構建立在八項共同設計的創新之上：PoH、Tower BFT、Turbine、Gulf Stream、Sealevel、Pipelining、Cloudbreak、Archivers。每一項都處理交易生命週期的不同階段。Sealevel 是執行層：運行程式的引擎。

PoH 是一種加密時鐘機制，為 Solana 網路上每一個事件產生可驗證的時間戳。每一個驗證者都會對這個時間戳序列達成共識。等到交易到達 Sealevel 時，排序的問題已經確定。Sealevel 不進行協調，它負責排程。

這就像一條裝配線。PoH 就像是輸送帶，負責以驗證過的順序遞送預先排序的工作項目。Sealevel 則是裝配線上的工作團隊，他們可以同時拾取並處理不會發生衝突的項目。工作人員無需協商下一個處理哪個項目，因為輸送帶已經決定了順序。若沒有輸送帶，工作人員將不斷停下來協調，完全消除平行處理的優勢。

由於 PoH 對交易進行了預排序，且賬戶模型要求預先聲明狀態，Sealevel 在執行開始前就能識別哪些交易存在衝突。衝突是以預見性的方式解決的，而不是在發生後才處理，這與先執行並在衝突時重新運行的樂觀併發模型不同。

其餘的創新各自發揮著輔助作用。Tower BFT（Solana 的共識機制，是實用拜占庭容錯的一種 PoH 優化變體）負責驗證 Sealevel 產生的區塊。Gulf Stream（無內存池交易轉發協議）在區塊確認前將交易推送到驗證者，因此 Sealevel 可以在當前區塊結算的同時開始處理下一批交易。Cloudbreak（賬戶數據庫）與 Sealevel 協同設計，旨在支持跨數千個並行執行線程的併發讀寫。

現實世界的表現：Sealevel 實際交付了什麼（以及不足之處）

相對於順序執行的區塊鏈，Sealevel 確實帶來了吞吐量的增益，但其實際表現遠低於理論最大值，且網絡曾經歷過重大停機。這兩點事實對於誠實的評估都至關重要。

理論與實際吞吐量

Solana 的吞吐量數據需要仔細解讀，因為常被引用的約 65,000 每秒交易量 (TPS) 描述的是理論上的架構上限，而非典型的主網性能。

發布的 TPS 數據通常包含內部驗證者投票交易，這會誇大報告的數值。非投票 TPS 才反映了實際面向用戶的交易吞吐量。

約 65,000 TPS 作為架構設計上限是真實的。它描述了 Sealevel 在理想條件和最佳交易配置下所能處理的能力。現實世界的數據較低，原因有多方面的記錄：交易複雜性、熱門程序中的賬戶競爭以及 Sealevel 本身上游的網絡級限制。即便如此，Solana 主網的吞吐量仍大幅領先於以太坊基礎層（約 15-30 TPS，根據以太坊基金會文檔）。

Sealevel 的並行執行能力是有記錄的架構事實，而非營銷說辭。理論 TPS 數據反映了運行時的設計；現實世界的數據則反映了其周圍的運行環境。

網絡停機與擁堵：誠實的評估

Solana 在 2021 年和 2022 年經歷了多次重大網絡停機，任何對 Sealevel 的誠實論述都必須解釋為什麼儘管運行時具備並行處理能力，這些停機還是發生了。

2021 年 9 月的一次事件持續了約 17 小時。試圖在代幣發行中獲利的殭屍網絡向網絡的交易攝入層發送了大量垃圾郵件，使其癱瘓。2022 年 1 月及 2022 年全年的多個時間點也發生了其他重大的停機。這些都是有案可查的歷史事件，並發布了事後分析報告。

停機並非 Sealevel 並行執行邏輯的失敗，而是 Sealevel 上游交易攝入基礎設施的失敗。Sealevel 約 65,000 TPS 的容量描述的是它可以處理多少有效交易；它並不能使網絡免受交易洪水的影響。一條擁有 100 條車道的高速公路，在十億輛汽車同時嘗試進入入口匝道時仍會陷入癱瘓。處理上限和抗垃圾郵件是不同的工程問題。

非同質化代幣 (NFT) 鑄造活動（數千名用戶嘗試同時鑄造）造成了網絡面臨過的最劇烈的負載高峰，並暴露了同樣的攝入層瓶頸。

Solana 隨後實施了幾項工程應對措施：以 QUIC 協議取代 UDP 進行交易攝入（提供更好的擁堵控制）、局部費用市場允許應用在負載下設置優先費用，以及由 Jump Crypto 開發的 Firedancer 驗證者客戶端，預計將進一步提高吞吐量和彈性。這些應對措施顯示了迭代改進，但沒有任何升級能消除開放式交易提交與有限處理能力之間的根本張力。

Sealevel 的多核並行執行還要求驗證者運行高規格的硬件：快速的多核處理器、大容量內存分配和高帶寬網絡連接。這對驗證者的參與構成了實質性的障礙，代表了 Solana 架構批評者正確指出的去中心化權衡。

Sealevel 是否為 Solana (SOL) 的持久競爭護城河？

Sealevel 賦予了 Solana 在基礎層真實的吞吐量優勢。該優勢是否構成持久的競爭護城河，需要將架構事實與生態系統變量分開來看。

關於持久性的論點始於集成深度。Sealevel 的架構與 Solana 的其他協同組件緊密耦合。PoH 在交易到達 Sealevel 之前對其進行預排序。Cloudbreak 處理 Sealevel 並行線程所需的併發存儲讀取。Gulf Stream 減少了 Sealevel 必須處理的交易積壓。如果脫離這套完整的技術棧，孤立地複製 Sealevel 的性能並不能重現其優勢。這種集成是真正的複製壁壘：雖然不是絕對的，但非同小可。

賬戶模型也為圍繞 Sealevel 範式構建生產應用的開發者創造了真實的切換成本。圍繞預先賬戶聲明、PDA 模式和 Anchor 開發框架設計的程序架構，如果不進行重大的重新架構，就無法移植到 EVM 鏈。日益增長的 Rust 工具庫、Anchor 資源、審計服務和參考實現進一步增加了慣性。

反對永久持久性的論點同樣真實。Aptos 和 Monad 證明了並行執行架構可以建立在不同的技術基礎上。以太坊的 L2 生態系統（Arbitrum、Optimism、Base）通過鏈下執行與鏈上結算實現高吞吐量，這是一條規避了 Sealevel 約束的另一種擴展路徑。對於許多去中心化金融 (DeFi) 使用場景（包括自動做市商 AMM，以及 Orca 和 Raydium 等去中心化交易所 DEX），L2 rollup 的吞吐量已足夠，無需 Sealevel 的範式轉移。

Sealevel 的優勢在結構上最防禦性的地方在於需要高頻、同時的鏈上狀態更新的使用場景：鏈上訂單簿、強制平倉引擎，以及數千個獨立交易必須同時結算的大型 NFT 鑄造活動。即使有了 L2 解決方案，這些使用場景在 EVM 鏈上依然在架構上難以實現，因為 L2 結算仍需與 L1 層協調以獲得最終性。

Sealevel 代表了基礎層真實且有記錄的架構差異化。其競爭護城河是真實的但非永久的。它面臨著新興並行鏈和以太坊不斷擴張的 L2 生態系統的壓力。Solana 地位的持久性既取決於其運行時的原始技術架構，也取決於網絡效應（開發者採用率、DeFi 總鎖定價值、機構基礎設施）。

為了理解各區塊鏈網絡在第一層 (Layer-1) 的競爭定位，以及架構權衡如何在不同的 L1 設計中體現，Sealevel 的設計選擇所提供的類比極具啟發性。

本節內容僅供參考與教育用途，不構成財務、投資或交易建議。加密貨幣投資具有重大風險，包括損失全部本金的風險。在做出投資決定前，請諮詢合格的財務顧問。

相關 Solana 架構資源

Sealevel 依賴於 Solana 帳戶模型，是 Solana 更廣泛的速度架構 的一部分。市場讀者可以參考 SOL 價格頁面.)。SOLUSDT 永續合約) 是一種槓桿衍生品，具有強平風險；它並非衡量 Sealevel 技術效能的指標。

FAQ：Solana Sealevel 並行處理

這些常見問題解決了關於 Sealevel 的並行執行模型、吞吐量數據以及與其他區塊鏈架構關係的最常見困惑。

什麼是 Solana 中的 Sealevel？

Sealevel 是 Solana 的並行智能合約運行環境：它是處理成千上萬個獨立交易的執行引擎，能夠同時進行而非逐一處理。透過 Solana 的帳戶模型識別哪些交易不共享數據依賴關係，Sealevel 會將這些交易同時分發到不同的處理器核心，實現順序執行無法企及的吞吐量。

Sealevel 如何實現並行交易處理？

Sealevel 要求每筆交易預先聲明其將讀取和寫入的帳戶。它利用這些聲明構建一個依賴圖，識別出哪些交易沒有重疊的帳戶。這些獨立的交易會同時在多個處理器核心上運行。共享寫入帳戶的交易會被串行化並按順序執行，而所有其他非衝突交易則繼續並行處理。

Solana 的 Sealevel 與以太坊 EVM 有何不同？

以太坊虛擬機 (EVM) 順序處理交易，一次一個，因為以太坊的狀態合約架構在架構上很難預先確定哪些交易可以安全地並行化。Sealevel 則能同時處理非衝突交易，因為 Solana 的帳戶模型要求交易預先聲明其狀態依賴關係，為 Sealevel 提供在執行開始前安全地並行化所需的信息。

Solana 使用 Sealevel 每秒可以處理多少筆交易？

根據 Solana Labs 的文件，在理想條件下，Solana 的理論處理能力可達 ~65,000 TPS。在實踐中，主網上非投票交易的真實吞吐量通常在 2,000–4,000 TPS 之間，具體取決於交易複雜性、帳戶競爭和網絡條件。這仍顯著高於以太坊底層約 15–30 TPS 的吞吐量。

在 Sealevel 上構建使用什麼編程語言？

Solana 程序主要使用 Rust 編程語言編寫，但也支持 C 和 C++。所有程序在部署到鏈上之前都會編譯成 Solana 修改過的 eBPF (extended Berkeley Packet Filter) 字節碼格式。Anchor 框架是一個廣泛使用的基於 Rust 的開發工具，它抽象了帳戶管理並減少了 Solana 程序開發的樣板代碼。

如果 Sealevel 速度如此之快，為什麼 Solana 還會出現網絡停機？

Solana 在 2021 年和 2022 年的網絡停機並非由 Sealevel 的並行執行邏輯故障引起。這些故障是由於大量的垃圾信息和格式錯誤的交易淹沒了網絡的交易攝取層（Sealevel 上游的一個獨立系統）造成的。Sealevel 的 TPS 上限描述了它可以處理多少有效交易；它並不能使網絡在攝取層面免受交易洪水攻擊。

Proof of History 與 Sealevel 之間的關係是什麼？

Proof of History (PoH) 透過在執行開始前建立可信的交易順序來支援 Sealevel。PoH 是一種加密時鐘機制，產生成為每個驗證者都同意的可驗證時間戳序列。由於交易排序在 Sealevel 接收交易之前就已確定，因此 Sealevel 無需暫停與驗證者協調，即可立即將非衝突交易調度到並行處理線程中。

結論：Sealevel 對 Solana 未來的意義

Sealevel 是 Solana 對每個區塊鏈面臨的問題最明確的回答：如何在不犧牲安全性或去中心化的情況下處理更多交易？

Sealevel 的並行執行是一種架構上的真實且有文檔記錄的能力，它將 Solana 的執行模型與 Layer-1 上的所有順序執行區塊鏈區分開來。其實際吞吐量意義重大，遠高於以太坊的基礎層，但仍低於理論最大值，並且仍受制於曾導致網絡停機的攝取層限制。它作為競爭優勢的持久性，既取決於生態系統的發展和競爭性並行執行架構的步伐，也取決於運行環境自身的設計。

Firedancer 驗證者客戶端的推出以及 Monad 等競爭性並行鏈的成熟，將在未來幾年使競爭態勢更加明朗。相關的問題已不再是底層並行執行是否可行，而是哪種架構方法能在規模化應用中最好地服務於各類用例。

延伸閱讀

• 以太坊智能合約執行：5 步交易框架
• 帳戶模型在不同區塊鏈架構中如何運作
• Layer-1 區塊鏈架構比較：Near Protocol vs. FetchAI

來源