什麼是 Solana virtual machine（SVM）？運作原理是什麼？
作者 Usman Asim
Solana 已成為加密貨幣領域中最活躍使用的區塊鏈之一，在每日活躍地址數與交易量方面持續位居前五名。單是在 2025 年 10 月，Solana 網路就處理了約7 千萬筆每日交易，並促成了 1,430 億美元的 DEX 交易量，尖峰時段的吞吐量足以讓大多數其他鏈陷入停滯。
讓這一切成為可能的，不只是快速的共識機制或強大的硬體需求，而是 Solana 效能核心所在的一套根本上不同的執行引擎：Solana Virtual Machine（SVM）。
Solana Virtual Machine 是一種以暫存器為基礎、建構於 eBPF 位元碼之上的執行環境，透過要求預先宣告所有狀態依賴關係來平行執行交易。與Ethereum Virtual Machine的循序交易模型不同，SVM 從一開始就是圍繞平行執行來設計的，能在多個 CPU 核心上同時處理數千筆交易，而非逐筆處理。
這項架構選擇影響了系統的方方面面：程式如何儲存狀態、交易如何構造、費用如何計算，以及開發者如何思考在鏈上建構應用程式。
本指南從基本原理拆解 SVM。我們會先介紹核心元件，逐一說明它們個別的運作方式，接著說明它們如何組合起來實現 Solana 的效能。讀完之後，你不僅會理解 SVM「做了什麼」，還會理解「為什麼」它要這樣建構。
什麼是虛擬機？
在深入探討 SVM 之前，先確立虛擬機究竟是什麼，以及區塊鏈為何需要它。
虛擬機（VM）是一種在另一台電腦內部運作的軟體型電腦。它提供一個受控環境，讓程式碼可以執行，而不必直接存取主機系統的資源。VM 隨處可見：Java Virtual Machine 執行 Java 位元碼、你的瀏覽器在 VM 中執行 JavaScript、雲端伺服器也常常在 VM 內執行。
區塊鏈需要 VM 有個具體原因：對不受信任的程式碼進行確定性執行。當你部署一份智慧合約時，全球數千個驗證者需要執行同一份程式碼並得出完全相同的結果。VM 提供了：
- 沙盒隔離：不受信任的程式碼無法存取主機系統或其他程式的記憶體
- 確定性：相同輸入永遠產生相同輸出，不受硬體影響
- 計量：可以測量並限制執行量（gas／compute units）以防止濫用
- 可攜性：程式碼在不同機器與作業系統上執行結果一致
**Ethereum Virtual Machine（EVM）**是第一個被廣泛採用的區塊鏈 VM。它採用堆疊式架構，循序執行交易，並將程式碼與狀態一起儲存在合約中。它是可行的，但其設計選擇造成了根本性的吞吐量限制。
**Solana Virtual Machine（SVM）**採取不同的做法。它使用暫存器式架構（更接近實體 CPU），將程式碼與狀態分離，最重要的是，它平行執行交易。
什麼是 Solana virtual machine（SVM）？
SVM 的核心是 Solana 的執行引擎，負責執行程式邏輯、處理交易並更新狀態。如果你熟悉 Ethereum，可以把它視為 Solana 對 EVM 的回應，但在架構上有著重要的不同之處。
要理解 SVM，你首先需要理解它所操作的對象：
- Accounts（帳戶）： Solana 的通用資料結構。所有東西都是 account：使用者錢包、代幣餘額、程式狀態，甚至程式本身。Account 持有資料並有一個 owner（被允許修改它的程式）。與將程式碼和儲存捆綁在一起的 EVM 合約不同，Solana 將兩者完全分離，所有狀態都存在於 account 中。
- Programs（程式）： 這是 Solana 對智慧合約的稱呼。Program 是無狀態的：它們僅包含可執行程式碼，被編譯成稱為 sBPF 的位元碼格式。大多數 Solana program 是用 Rust 撰寫（雖然也支援 C 與 C++）。當一個 program 執行時，它會讀寫傳入的 account，但內部不儲存任何東西。
- Transactions（交易）： 一個或多個 instruction 的組合，每個 instruction 都指向某個 program，並指定它需要讀取或寫入的 account。這種預先宣告狀態依賴關係的做法，正是一切的關鍵所在。它使平行執行成為可能。
有了這樣的基礎，理解 SVM 最簡單的方式是：它是一個沙盒式的執行環境，接收已編譯的 program 位元碼，對一組 account 執行，並判定所產生的狀態變化。Solana 上的每一筆交易都會經過 SVM。
SVM 與 EVM 的不同之處不只是實作細節，而是根本性的設計。SVM 從一開始就是圍繞平行執行來建構的。交易預先宣告其狀態依賴關係，讓執行環境能夠識別不衝突的工作，並在多個 CPU 核心上同時處理。EVM 循序處理交易；SVM 則同時處理數千筆。
關於術語的說明：「SVM」一詞在不同語境下有不同含義。狹義定義專指執行 program 程式碼的位元碼解釋器與 JIT 編譯器（稍後會介紹 sBPF 這種位元碼格式）。廣義定義則是像 Anza（Solana 核心驗證者團隊）等團隊正式採用的說法，涵蓋整個交易執行流程：排程、compute budget 計算、program 載入、執行以及狀態更新。當開發者說「the SVM」時，通常指的是這個較廣義的系統。本指南會同時涵蓋兩者，並在過程中清楚說明所指為何。
理解 SVM 架構
現在我們知道 SVM「是什麼」，以及它與其他區塊鏈 VM 有何不同，接下來讓我們理解它「實際上如何運作」。本節將完整走過整個架構，從交易抵達的那一刻到最終的狀態變化。
我們會涵蓋四個相互關聯的部分：
- 交易如何在系統中流動（pipeline）
- 執行你程式碼的執行引擎（eBPF、編譯、VM 本身）
- program 所操作的資料模型（accounts、PDA、rent、CPI）
- 平行執行，以及 Sealevel 如何使其成為可能
每個部分都建立在前一個之上。讀完之後，你不僅會理解各個元件，還會理解它們如何組合起來實現 Solana 的效能特性。
第一部分：交易如何在 SVM 中流動
理解 SVM 的第一步，是追蹤一筆交易的歷程，從你按下「送出」的那一刻，到區塊確認為止。這個 pipeline 解釋了為什麼 Solana program 是這樣建構的、為什麼你必須預先宣告 account，以及平行執行實際發生在哪裡。
當你向 Solana 提交一筆交易時，它並不會單純進入佇列排隊等候。它會流經一系列專門的子系統，每個子系統解決一個特定的問題：
Transaction submitted
↓
Banking Stage
(conflict detection, parallel scheduling)
↓
The Bank
(state snapshot for this slot)
↓
BPF Loader
(provisions sBPF VM instance)
↓
Program executes
(reads/writes accounts within budget)
↓
State updates committed讓我們逐一走過每個階段：
Banking stage：平行處理發生的地方
這是交通控制中心。當已驗證的交易抵達時，Banking Stage 會分析每一筆交易：它需要讀取哪些 account？需要寫入哪些 account？
有了這些資訊，它會判斷哪些交易可以安全地同時執行：
- 觸及完全不同 account 的交易 → 平行執行
- 同時讀取同一個 account 的交易 → 平行執行（讀取不會衝突）
- 同時寫入同一個 account 的交易 → 必須循序執行
排程器使用 account 層級的鎖定來強制執行這些規則。工作執行緒會同時處理一批批不衝突的交易。這正是 Solana 平行執行模型（稱為 Sealevel）的核心（我們會在第四部分深入探討 Sealevel）。
Bank：某個時間點的狀態
Banking Stage 負責處理排程，而 Bank 則負責狀態。可以把它想成是 Solana 整體狀態在某個特定 slot（Solana 的時間單位，大約 400 毫秒）下的快照。
Bank 管理 account 資料、協調執行，並追蹤哪個版本的狀態是正確的（canonical）。每個 Bank 都會經歷三個生命週期階段：
當 Banking Stage 執行交易時，它是針對某個特定的 Bank 進行操作——也就是世界的某個特定版本。這就是 Solana 在同時平行處理數千筆交易時，仍能維持一致性的方式。
BPF loader：啟動程式執行
當一筆交易呼叫某個 program 時，必須有東西實際「執行」該 program 的程式碼。這就是 BPF Loader 的工作。
BPF Loader 負責整個 program 的生命週期：
- 部署：將新的 program 位元碼上傳到網路
- JIT 編譯：將位元碼轉換為原生機器碼以加快執行速度
- 升級：推送現有 program 的新版本
- 執行：在 program 被呼叫時佈建隔離的 VM 實例
每次 program 呼叫都會取得屬於自己的沙盒式 sBPF VM 實例，具備：
- 專用的記憶體區域
- 一份 compute budget（類似 gas limit）
- 與其他 program 嚴格隔離
如果 program 超出其 compute budget？執行就會中止。試圖存取不該存取的記憶體？執行也會中止。這種隔離是刻意設計得如此嚴格的。這就是 Solana 能安全執行來自數千位開發者、不受信任程式碼的方式。
典型的交易流程
以下是一筆典型交易的完整流程：
- 你提交一筆交易，指定要呼叫的 program 以及它需要的 account
- Banking Stage 接收該交易，檢查是否與其他待處理交易有衝突，並適當地進行排程
- Bank 為此 slot 提供目前的狀態快照
- BPF Loader 為目標 program 佈建一個 sBPF VM 實例
- Program 執行，讀寫指定的 account
- 狀態變化提交到 Bank
- 最終，Bank 凍結並根植（root），使變更永久生效
每個元件都解決一個特定問題：Banking Stage 實現平行處理，Bank 提供一致的狀態，而 BPF Loader 則確保安全執行。它們共同構成了廣義上的「SVM」。
想更深入了解交易？請參考以下資源：
- Transaction lifecycle：交易如何構造與處理
- Fees on Solana：compute unit、priority fee 與費用估算
- Clusters & endpoints：理解 Solana 的網路架構
第二部分：執行引擎
BPF Loader 會佈建 VM 實例來執行 program 程式碼。但在該 VM 實例內部，究竟發生了什麼事？
大多數區塊鏈 VM 都是從零開始設計的。Solana 走了不同的路：它採用了eBPF（extended Berkeley Packet Filter），一項原本為 Linux kernel 打造的技術。
BPF 起源於 1992 年勞倫斯柏克萊國家實驗室，用於高效的網路封包過濾。隨著時間演進，它發展成 eBPF，一種在 Linux kernel 內安全執行的通用沙盒式 VM。如果你曾使用過 bpftrace 之類的可觀測性工具，或使用過以 eBPF 為基礎的網路技術，那你已經接觸過這項技術了。它是經過實戰考驗、支撐著大規模關鍵系統的基礎設施。
Solana 創辦人 Anatoly Yakovenko 在作業系統領域的背景（在 Qualcomm 任職超過 13 年）讓他得出一個關鍵洞見：既然已經有現成的 VM 解決了那些困難的問題，為什麼還要從零開始打造新的 VM？
eBPF 恰好提供了 Solana 所需要的一切：
- 無額外開銷的安全性： eBPF program 在受限環境中執行，無法讓主機當機或破壞記憶體。位元碼在載入前會經過靜態驗證——不允許無效的記憶體存取、超出範圍的跳躍、或未經授權的操作。這種安全性不需要執行期開銷，不像那些需要垃圾回收的受管理執行環境。
- 接近原生的效能： 暫存器式架構（不同於 EVM 的堆疊式設計）使得可以 JIT 編譯成原生機器碼。程式能以接近原生的速度執行。
- 成熟的工具鏈： LLVM 已內建 eBPF 後端。Rust、C、C++ 以及其他 LLVM 支援的語言可以直接編譯成 eBPF 位元碼。你用自己熟悉的語言寫程式，工具鏈負責處理其餘的部分。
sBPF：Solana 客製化的變體
Solana 並未使用標準的 eBPF。它也無法這麼做，因為標準 eBPF 是為了具有嚴格限制的 kernel 空間操作而設計的，這些限制並不適用於區塊鏈執行環境。因此 Solana 分岔（fork）了它。
結果就是 sBPF（Solana Bytecode Format），一種為鏈上 program 執行量身打造的修改版本：
那些使 eBPF 在 kernel 空間中安全的限制——極小的堆疊、不允許迴圈——若套用在 Solana 上會使智慧合約開發窒礙難行。sBPF 放寬了這些限制，同時透過 compute unit budget 維持安全性：你可以使用迴圈，但終究會耗盡 compute。
自訂 syscall 同樣重要。Program 需要記錄訊息、呼叫其他 program（Cross-Program Invocation），以及執行加密運算。標準 eBPF 完全沒有這些概念，而 sBPF 將它們新增為一等公民的原語。
如果你在編譯 Solana program，會在工具鏈中看到目標三元組（target triple）sbf-solana-solana。這就是這個 Solana 專屬變體的識別碼。
從 Rust 到位元碼：編譯 pipeline
當你執行 cargo build-sbf 時，你的 Rust 程式碼會經過多階段的編譯 pipeline：
1. Rust 前端： 編譯器解析你的程式碼、展開巨集、執行型別檢查，並執行 borrow checker 來驗證記憶體安全性。等到程式碼離開這個階段時，Rust 已經消除了整整一類的錯誤（use-after-free、資料競爭、null 指標），這些問題在其他系統程式語言中屢見不鮮。這是 Solana 一項未被充分重視的優勢：在程式碼觸及鏈之前，記憶體安全性就已在編譯期強制執行。
2. LLVM 最佳化： 程式碼轉換成 LLVM IR，一種平台無關的表示形式，各種重要的最佳化就在此發生：常數摺疊、函式內聯、無用程式碼消除、迴圈展開。這些最佳化很重要，因為 compute unit 是要花錢的。位元碼越小、越精簡，交易成本就越低。
3. sBPF 後端： Solana 客製化的 LLVM BPF 後端分支，將經過最佳化的 IR 轉換成 sBPF 位元碼，並封裝成 ELF 檔案（.so）。這就是你要部署到網路上的東西——也是當你的 program 被呼叫時，BPF Loader 會佈建進 VM 實例中的東西。
Rust source (.rs)
↓
Rust compiler (type checking, borrow checker)
↓
LLVM IR (optimizations)
↓
sBPF bytecode (.so)
↓
Deployed to SolanasBPF VM 內部
現在我們來到最底層：實際執行你位元碼的虛擬機器本身。
sBPF instruction set 使用 64 位元的 instruction（每個 8 個位元組），採用類 RISC 設計，約有 100 個 opcode。Program 可存取 11 個 64 位元暫存器：
記憶體布局
VM 將記憶體組織成固定的區域，每個區域都從特定位址開始：
這種嚴格的布局讓 VM 能夠強制執行明確的邊界，使你的 program 不會（意外或惡意地）存取不該存取的記憶體。
JIT 編譯與安全性
sBPF VM 支援兩種執行模式：
- 解釋器： 逐一走過每個 instruction。啟動快，執行慢。適合本地測試與除錯。
- JIT 編譯： 在執行前先將 sBPF 位元碼轉換成原生 x86_64 機器碼。啟動慢，但執行速度大幅提升。這是驗證者在正式環境中使用的方式。
Agave 驗證者會將 JIT 編譯過的 program 快取在 ProgramCacheForTxBatch 中以供重複使用。像 Token Program 這類常用的 program，不會在每筆交易時重新編譯。它們已經在快取中。
安全性強制執行發生在兩個層級：
- 靜態驗證（執行前）：
- 拒絕格式不正確或無效的 instruction
- 驗證所有記憶體存取模式
- 確保跳躍目標落在有效的 instruction 邊界上
- 抓出無法到達的程式碼路徑
如果你的 program 沒有通過驗證，就無法部署，沒有例外。
- 執行期計量（執行期間）：
- 每個 instruction 都會消耗 compute unit
- VM 在每一步之後都會檢查 budget
- 超出 budget 會立即中止執行
這種雙層機制可防止無窮迴圈、資源耗盡攻擊，以及失控的 program。即使惡意位元碼設法通過了靜態驗證，它也無法永遠執行下去，一旦達到 compute 上限就會停止。
如果你想更深入了解執行引擎，請參考以下資源：
- Programs overview：Solana program 如何運作
- Developing programs in Rust：官方 Rust 開發指南
第三部分：資料模型
我們已經追蹤了交易如何流經 SVM，以及位元碼如何在 sBPF VM 內執行，現在來看看 program 所操作的對象是什麼。
在大多數程式開發環境中，你會有變數、資料庫、檔案系統，各種儲存與擷取資料的方式。區塊鏈需要類似的東西：一種在交易之間持久保存狀態的方法。EVM 的解決方式是給每個合約自己的儲存空間，一個內建在合約本身的鍵值儲存區。
Solana 採取了截然不同的做法，而理解這個差異至關重要，因為它決定了你在這個平台上建構應用的方方面面。
Solana 上的一切都是 account
可以把 Solana 想成一個巨大的鍵值資料庫：
- Key：一個 32 位元組的位址（通常是公鑰或衍生位址）
- Value：一個 account（一種持有位元組資料、餘額及中繼資料的資料結構）
這種一致性一開始可能看起來很奇怪，但正是它使 Solana 的效能特性成為可能。每一份狀態都有明確的位址、明確的 owner，以及明確的修改規則。執行環境不需要追蹤嵌套的合約呼叫來搞清楚哪些狀態可能改變，它從交易的 account 清單中就已預先得知。
讓我們看看 account 內部實際包含什麼，每一個都包含相同的五個欄位：
owner 欄位至關重要。只有擁有該 account 的 program 才能修改其 data 欄位或扣除其 lamports。任何人都可以讀取任何 account（Solana 上所有狀態都是公開的），任何人也都可以將 lamports 存入任何 account。但寫入是由 ownership 來把關的。
正是這種 ownership 模型使平行執行成為可能。執行環境確切知道哪個 program 可以修改哪些 account，因此可以安全地同時執行不衝突的交易。
Program：設計上就是無狀態的
Solana program 是一個包含已編譯 sBPF 位元碼的可執行 account。但關鍵的洞見在於：program 無法在內部儲存狀態。它們是純函式，處理 instruction 並修改傳入給它們的 account。
每個 Solana program 都共用相同的進入點簽章：
pub fn process_instruction(
program_id: &Pubkey, // This program's address
accounts: &[AccountInfo], // All accounts passed to this instruction
instruction_data: &[u8], // Arbitrary data (parameters, method selectors, etc.)
) -> ProgramResult當你的 program 執行時，它會接收到：
- 自己的位址（因此它可以驗證自己衍生出的 PDA）
- 一組它被允許讀寫的 account
- 包含呼叫者傳入之任何參數的 instruction 資料
Program 執行其邏輯，修改它被允許修改的 account，然後回傳成功或錯誤。它在呼叫之間不儲存任何內部狀態。
為什麼要無狀態？因為這樣能實現乾淨的 ownership 邊界。如果 program 儲存自己的狀態，你就需要複雜的規則來決定哪些 program 可以存取哪些儲存空間。透過強制所有狀態進入具有明確 owner 的 account 中，這個模型保持簡單，平行化也才得以維持可能。
設計說明：與預設不可變的 EVM 合約不同，Solana program 預設是可升級的。升級權限（upgrade authority）可以隨時推送新的位元碼。開發者可以撤銷升級權限使 program 變成不可變，但這是一個明確的選擇。這反映了 Solana 務實的態度——大多數 program 都需要修 bug 與功能更新。
Program Derived Addresses（PDA）
如果 program 是無狀態的，且所有資料都存在於 account 中，那 program 該如何建立並管理自己的 account？它們不能持有私鑰。這就是 Program Derived Addresses（PDA）發揮作用的地方。
PDA 是一種特殊的位址，它落在 Ed25519 橢圓曲線之外，意味著沒有有效的私鑰與之對應。這種密碼學特性讓 program 能夠為這些位址「簽署」，而不需要持有私鑰——執行環境會在內部驗證其衍生過程。
PDA 的衍生方式是將 seed、program ID 加上一個「bump seed」進行雜湊：
// Find a PDA for storing a user's balance
let (user_balance_pda, bump) = Pubkey::find_program_address(
&[
b"balance", // Static seed
user.key().as_ref() // User's public key as seed
],
program_id
);該演算法會從 255 開始向下嘗試 bump 值，直到找到一個能產生曲線外位址的值為止。第一個有效的 bump 就是「canonical bump」。
為什麼 PDA 很重要
- 確定性定址：給定相同的 seed，你總是能得到相同的位址。不需要另外儲存位址。
- 由 program 控制的 account：Program 可以在自己衍生出的 PDA 上建立 account，且只有它們自己能為這些 PDA 簽署。
- 鍵值模式：Seed 可以編碼各種關係（使用者 + 代幣類型 → 餘額 account），實現類似映射的資料結構。
// Common PDA patterns
// User-specific data
let (user*profile, *) = Pubkey::find_program_address(
&[b"profile", user.key().as_ref()],
program_id
);
// Token account for a specific mint
let (token*vault, *) = Pubkey::find_program_address(
&[b"vault", mint.key().as_ref()],
program_id
);
// Unique item with incrementing ID
let (item, _) = Pubkey::find_program_address(
&[b"item", &item_id.to_le_bytes()],
program_id
);Rent：為狀態付費
區塊鏈狀態並非免費。每一個 account 都會佔用驗證者磁碟上的空間，而空間是要付出實際成本的。不同鏈以不同方式處理這個問題。Ethereum 對儲存操作收取 gas 費用，但一旦寫入，狀態就會永久存在，導致狀態不斷膨脹。
Solana 採取了不同的做法。有一種稱為「rent」的機制，網路每年對每個位元組收取約 3,480 lamports 以維持資料上鏈。實務上，所有主網 account 都必須「免除 rent」（rent-exempt），即預先持有至少兩年份的 rent：
rent_exempt_minimum = (account_size + 128 bytes overhead) × 3,480 × 2以典型的 token account（165 個位元組）為例，這大約相當於 0.002 SOL。
但這裡有個與其他鏈的關鍵差異：關閉一個 account 會返還全部的 rent 押金。這創造了清理無用狀態的經濟誘因，這在儲存永久存在的模型中是不存在的。
// Closing an account returns lamports to a recipient
ctx.accounts.account_to_close.close(ctx.accounts.recipient.to_account_info())?;Cross-Program Invocation（CPI）
Program 並非孤立存在。一個 DeFi 協定可能會呼叫 Token Program 來轉移代幣，而後者可能會呼叫 Associated Token Account Program。這些 Cross-Program Invocation 正是 Solana 生態系統組合（compose）的方式。
有兩個函式可以實現 CPI：
// Standard CPI - passes existing signers through
invoke(
&instruction,
&[account1, account2, ...]
)?;
// CPI with PDA signing - program "signs" for a PDA it controls
invoke_signed(
&instruction,
&[account1, account2, ...],
&[&[b"seed", &[bump]]] // Seeds that derive the PDA
)?;當你以 PDA seed 呼叫 invoke\_signed 時，執行環境會驗證其衍生過程符合預期位址，並為該次呼叫授予簽署權限。這就是 program 能夠在不持有私鑰的情況下控制資產的方式。
重要限制：
- 最大呼叫深度為 5（從初始交易起算最多 4 層嵌套 CPI）
- Signer 權限會沿著呼叫鏈層層傳遞
- Compute budget 由一筆交易中的所有 CPI 共享
想更深入了解 account，請參考以下資源：
- Accounts Overview：Solana account 完整指南
- PDAs：Program Derived Addresses 詳解
- CPIs：Cross-Program Invocation 指南
第四部分：平行執行（Sealevel）
我們現在已經涵蓋了所有基礎元件：交易如何流經 pipeline、sBPF VM 如何執行位元碼，以及 account 模型如何以明確的 ownership 儲存狀態。
現在我們終於可以回答一路建構至今所要解答的問題：Solana 究竟是如何實現平行執行的？
我們在過程中已經多次提示過：Banking Stage 排程不衝突的交易、account 預先宣告 owner、交易指定它們將觸及哪些 account。這些並非各自獨立的功能，它們都是一個名為 Sealevel 的單一系統中的組成部分。
Sealevel 是 Solana 的平行智慧合約執行環境，也是使 SVM 吞吐量成為可能的核心創新。我們前面所涵蓋的一切——account 模型、ownership 規則、預先宣告的 account——都是為了使 Sealevel 成為可能而存在的。
其根本的洞見看似簡單：
如果交易在執行開始前就宣告了它們要讀取與寫入哪些 account，執行環境就能識別出彼此不重疊的交易，並同時平行執行它們。
就是這樣。這就是整個訣竅所在。但要在實務上讓它運作，就必須圍繞這項限制來設計系統的其他每一個部分。
平行執行的規則
Sealevel 的排程遵循簡單明瞭的規則：
就是這樣。讀取不會與讀取衝突，寫入則會與一切衝突。
TX1: [Account A (write), Account B (read)]
TX2: [Account C (write), Account D (read)] ──► PARALLEL
TX3: [Account B (read), Account E (write)]
TX4: [Account A (write), Account F (read)] ──► SEQUENTIAL with TX1
(conflicts with TX1 on Account A write)這就是為什麼你必須在 Solana 交易中預先宣告所有 account。這並非官僚形式，而是執行環境用來平行處理你交易所需要的資訊。
排程演算法
Banking Stage 透過 account 層級的鎖定機制來實作 Sealevel：
- 交易抵達，指定帶有讀寫旗標的 account
- 對每個可寫入的 account：取得獨佔鎖
- 對每個可讀取的 account：取得共享鎖（允許多個讀取者）
- 若所有鎖都取得成功：排入執行
- 若有任何鎖被阻擋：重新排入佇列，稍後再試
目前的實作使用 6 個執行緒：4 個用於非投票交易，2 個用於投票交易。每個執行緒維護一個依 priority fee（每 compute unit 的費用）與到達時間排序的佇列。
較新的 Central Scheduler 架構使用單一排程執行緒，搭配 Prio-Graph 演算法——一種延遲填入的依賴圖，透過前瞻視窗（look-ahead window）識別衝突。這改善了高競爭工作負載下的排程效率。
實際效能表現
實際的吞吐量高度取決於交易組合。觸及不重複 account 的簡單轉帳可以完美平行化。而全都命中同一個流動性池的複雜 DeFi 交易，則會產生競爭並被序列化。
這其實是一項優點：競爭是局部化的。某個去中心化交易所交易量的暴增，並不會拖慢某個新型銀行（neobank）的代幣轉帳，因為它們觸及的是不同的 account。這與所有交易都在爭奪同一個全域吞吐量的鏈有著根本性的不同。
為什麼循序式 VM 無法簡單地採用這種做法
你可能會想：為什麼 EVM 不能直接加入平行執行？
根本的問題在於，EVM 的 account 存取是在執行時才決定的，而非事前。當你呼叫一份 Solidity 合約時，在你實際執行它之前，沒有辦法知道它會讀寫哪些儲存槽（storage slot）。該合約可能會呼叫另一個合約，後者又呼叫另一個，每一次都存取無法預測的狀態。
這種「對讀寫毫無所知」的模型使得在不使用推測執行的情況下無法安全地平行化。一些較新的鏈實作了「樂觀平行執行」：先假設沒有衝突而推測性地執行，然後在發生衝突時偵測並循序重新執行。這種方式可行，但增加了複雜度與開銷。
Solana 的做法不同：衝突是被避免的，而非事後解決的。透過要求預先宣告，執行環境在執行開始前就確切知道每筆交易需要什麼。這項限制正是使最佳化成為可能的原因。
EIP-2930 為 Ethereum 引入了可選的「access list」以獲得 gas 折扣，但它並非強制性的。Solana 使宣告成為強制且普遍的做法，這正是關鍵差異所在。
SVM 生態系統：不只 Solana Mainnet
SVM 已不再只屬於 Solana。2024 年 6 月，Anza 推出了 SVM API，將執行引擎與 Solana 的驗證者用戶端解耦。這項模組化開啟了全新的使用情境。
Eclipse：Ethereum 上的 SVM
Eclipse 於 2024 年 11 月上線，是 Ethereum 上第一個正式運作的 SVM rollup：
上線時已有超過 60 個應用程式部署，包括 Orca。Eclipse 為打造這座橋樑募得了 6,500 萬美元，證明 SVM 具有獨立於 Solana 共識層之外的價值。
SOON network
SOON（Solana Optimistic Network）在 2025 年初達成 alpha 主網階段，是第一個「解耦式 SVM」rollup。與簡單的分岔不同，SOON 乾淨地將執行與共識分離，實作了 Merkle Patricia Trie 來管理狀態（不同於 Solana 的 AccountsDB）。目標是搭配 Firedancer 整合達到 5K–600K TPS。
Sonic SVM
Sonic 於 2025 年 1 月上線，是 Solana 上第一個用於遊戲的原子式 SVM Layer-2。由 Mirror World Labs 打造，包含用於為每款遊戲快速建立自訂 SVM 鏈的 HyperGrid Framework。測試網已處理超過 6 億筆交易，來自超過 200 萬個月活躍錢包。
MagicBlock：短暫式 rollup
MagicBlock 推出了「短暫式 rollup」（ephemeral rollup）——一種臨時、依需求啟動的 SVM 執行環境。你可以照常在 Solana 上部署合約，然後在需要低於 50 毫秒延遲時，將特定 account 委派給 MagicBlock。寫入會在短暫的 session 中進行，然後再提交回 Solana。
這非常適合遊戲與即時應用場景，在這些場景中，400 毫秒的區塊時間仍然太慢。
Firedancer：效能上的突破
Jump Crypto 的 Firedancer 用戶端，可能是 SVM 開發中最重要的一項進展。它完全以 C 語言撰寫，與 Agave 沒有任何共享元件，採用基於 tile 的架構，讓每個功能都在專用的 CPU 核心上執行，並搭配核心旁路（kernel-bypass）網路。
這些是合成基準測試結果，但它們顯示出遠超目前主網效能的巨大成長空間。
時間軸：
- 2024 年 9 月：Frankendancer（混合式）上線主網
- Breakpoint 2024：完整版 Firedancer 以非投票模式運作
- 2025 年：預計推出完整正式版本
在 SVM 上建構
我們已經涵蓋了架構層面，現在來談談實務。如果你想開始在 Solana 上建構應用，實際上需要什麼？
工具鏈一覽
對大多數開發者來說，路徑是：Solana CLI + Anchor + Bankrun。這個組合涵蓋了 90% 的使用情境。
快速上手：5 分鐘設定
# Install Solana CLI
sh -c "$(curl -sSfL <https://release.anza.xyz/stable/install>)"
# Install anchor
cargo install --git <https://github.com/coral-xyz/anchor> anchor-cli
# Create a new project
anchor init my_project && cd my_project
# Build and test
anchor build
anchor test就是這樣。你現在已經擁有一個可運作的 Solana 開發環境、一個起始 program、測試套件，以及可用的本地驗證者整合環境。
從這裡開始，Anchor Book 會帶你建構第一個真正的 program，而 Solana Cookbook 則提供了常見模式的實作範例。
想更深入了解，可以參考：
- Solana Developer Docs：官方文件
- Anchor Book：完整的框架指南
- Solana Cookbook：實用的範例與模式
- Alchemy Solana APIs：RPC 基礎設施與開發者工具
結論：架構上的賭注
SVM 代表了一套一致的架構願景：接受一些預先設定的限制（明確的 account 宣告、無狀態的 program、複雜的交易構造），以換取平行處理能力、吞吐量以及局部化的費用市場。這些限制並非附帶產物——它們正是使這種效能得以實現的機制。
如果你想探索有哪些可能性，Alchemy 的 Solana APIs 讓你能從單一平台存取 Solana mainnet、devnet 以及更廣泛的 SVM 生態系統。開始建構，親自體驗看看。
常見問題
什麼是 Solana Virtual Machine（SVM）？
SVM 是 Solana 的執行引擎，一種以暫存器為基礎、建構於 eBPF 位元碼之上的執行環境，透過要求預先宣告所有狀態依賴關係來平行執行交易，讓數千筆交易能在多個 CPU 核心上同時處理。
SVM 與 Ethereum Virtual Machine（EVM）有何不同？
與 EVM 堆疊式、循序執行的架構不同，SVM 採用暫存器式設計並支援平行執行，透過 account 將程式碼與狀態分離，並要求預先宣告 account 以實現並行處理。
什麼是 Sealevel，為什麼它很重要？
Sealevel 是 Solana 的平行智慧合約執行環境，會排程不衝突的交易在多個 CPU 核心上同時執行，透過並行處理觸及不同 account 的交易，實現數千 TPS 的吞吐量。
我可以用哪些程式語言在 SVM 上開發？
Program 主要以 Rust 撰寫，並透過 LLVM 編譯成 sBPF 位元碼，不過也支援其他與 LLVM 相容的語言，例如 C、C++ 與 Zig。
什麼是 Program Derived Addresses（PDA）？
PDA 是一種落在 Ed25519 曲線之外、沒有有效私鑰的特殊位址，讓 program 能夠確定性地產生這些位址並為其「簽署」，而不需要持有私鑰，使 program 能夠管理自己的 account。
SVM 的 account 模型如何運作？
Solana 上的一切都是 account，一種包含 lamports（餘額）、任意資料位元組、owner program ID 以及中繼資料的資料結構。Program 是無狀態的，只能修改自己擁有的 account，這為平行執行提供了明確的 ownership 邊界。
什麼是 sBPF，它與 eBPF 有何關係？
sBPF（Solana Bytecode Format）是 Solana 客製化的 eBPF 變體，為區塊鏈用途進行了修改，具備更大的堆疊空間（4KB 對比 512 位元組）、支援受 compute unit 限制的迴圈，以及用於記錄、CPI 和加密運算的自訂 syscall。
什麼是 Cross-Program Invocation（CPI）？
CPI 讓 Solana program 能在執行期間呼叫其他 program，最大呼叫深度為 5，在維持共享 compute budget 與 signer 權限層層傳遞的同時，實現整個生態系統的可組合性。
SVM 可以用在 Solana mainnet 以外的地方嗎？
可以，模組化的 SVM API 使其應用不限於 Solana：Eclipse 將 SVM 作為 Ethereum rollup 執行、SOON Network 以解耦式 SVM rollup 的形式運作，而 Sonic 與 MagicBlock 等專案則打造了專屬的 SVM 執行環境。
我該如何開始在 SVM 上建構應用？
安裝 Solana CLI 與 Anchor framework，接著使用 anchor init 建立一個包含起始 program、測試套件與本地驗證者整合的專案，Anchor Book 與 Solana Cookbook 提供了完整的開發指南。
相關總覽
Solana2026年7月27日
Solana 節點：驗證者、RPC 節點與自架
說明 Solana 節點是什麼、驗證者、RPC 節點與次級資料系統的差異，以及何時該自架、何時該使用服務供應商。
Solana2026年7月22日
Solana 歸檔資料：如何查詢完整區塊與交易歷史
說明 Solana 歸檔資料：節點為何會修剪歷史資料、哪些 RPC 方法需要歸檔存取權限，以及如何大規模查詢完整區塊與交易歷史。
Solana2026年5月28日
Solana Agent Kit vs GOAT vs ElizaOS：該選哪個框架？
比較 Solana Agent Kit、GOAT 與 ElizaOS：Solana 原生深度、多鏈廣度，或完整的 agent runtime。附程式碼範例與選擇依據。
打造區塊鏈魔法
Alchemy 結合最強大的 Web3 開發者產品與工具，並提供資源、社群與卓越的支援。