Contenu source (brut)
<p>Many thanks to <a href="https://x.com/__lostin__" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">Lostin</span></a>, <a href="https://x.com/alessandrod" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">Alessandro</span></a>, <a href="https://x.com/0xbrw" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">Brian</span></a>, <a href="https://x.com/bradyowen_" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">Brady</span></a>, and <a href="https://x.com/danielkcumming" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">Daniel Cumming</span></a> for reviewing earlier versions of this work. </p><h2>Actionable Insights</h2><ul class="list-bullet"><li value=1>The SVM encompasses the entire transaction execution stack, unlike the EVM, which refers unambiguously to a bytecode executor.</li><li value=2>Requiring transactions to declare which accounts they’ll access before execution unlocks parallel execution across CPU cores and localized fee markets.</li><li value=3>Rust source compiles through rustc to LLVM IR, then LLVM’s eBPF backend, specifically Solana’s fork sBPF, lowers it to sBPF bytecode. This means that any language with an LLVM frontend (e.g., C, C++, Zig) can be used to write Solana programs.</li><li value=4>sBPF is Solana’s fork of Linux’s eBPF, which, for all intents and purposes, is effectively the same, with some historical additions that have been introduced. However, these additions are set to be rolled back. The only meaningful difference is that upstream eBPF functions have a maximum of 5 arguments, while Solana’s fork can have more.</li><li value=5>Compiled sBPF bytecode is stored in ELF files containing sections for instructions and constants, as well as relocation tables. The linker resolves syscall references to deterministic 32-bit Murmur3 hashes and rewrites internal functions as relative jumps for portability. </li><li value=6>The BPF Loader Upgradeable uses a two-account model for in-place upgrades and deployments, while the upcoming Loader V4 streamlines this to a single account with optional compression. All bytecode is statically verified before being marked as executable.</li><li value=7>Transactions contain an array of account addresses with read and write permissions, instructions, and signatures. This structured format allows for conflict detection and scheduling non-conflicting transactions in parallel.</li><li value=8>The TPU’s Banking Stage is responsible for scheduling non-conflicting transactions in parallel. The Bank loads account state from AccountsDB. BPF Loaders provision isolated sBPF VMs with bounded memory regions and compute budgets. Successful state changes commit atomically, while failures revert completely.</li><li value=9>The SVM ISA is the only formal specification—besides Alpenglow’s whitepaper, and the series of articles initially written by Toly, there is no single “SVM spec.” The runtime emerges from the interaction of the Bank, scheduler, BPF Loaders, and the sBPF VM itself.</li></ul><h2>Introduction</h2><p>The Solana Virtual Machine (SVM) is one of the most misunderstood systems in blockchains today. Unlike the Ethereum Virtual Machine (EVM), which refers unambiguously to an opcode executor, the term SVM encompasses an entire transaction execution pipeline, from the Banking Stage scheduler to the sBPF bytecode interpreter itself. This ambiguity reflects Solana’s architectural difference: there is no traditional specification that defines “the SVM” in isolation. The only specification that comes close pertains to the Solana Virtual Machine Instruction Set Architecture (SVM ISA), which describes how sBPF bytecode must execute, but says nothing about the broader runtime.</p><p>This article aims to serve as a comprehensive reference for what the SVM is, how it works, and why it’s fundamentally different from the perspective of Anza’s Agave validator implementation. Exploration into how Firedancer’s client operates, as well as their custom virtual machine implementation that adheres to the SVM ISA, is outside the scope of this work.</p><p>We are interested in examining the actual codebase, rather than some abstract specification. We trace the complete execution pipeline—how Rust source code compiles through LLVM to sBPF bytecode, how programs are deployed and verified, how the runtime provisions isolated execution environments for parallel execution, and how transactions interact with deployed bytecode.</p><p>The first few sections contextualize the SVM’s ambiguity and give a high-level overview of how it works. The remainder of the article is intended for a more technical audience seeking a rigorous understanding of Solana’s execution layer.</p><h2>A Contentious Definition</h2><p>The term “Solana Virtual Machine” (SVM) has sparked contentious debate within the community, especially since the emergence of network extensions and other layer blockchains being built on top of Solana. Contention stems from the term’s scope: Is the SVM strictly the low-level sBPF interpreter, or does it encompass the full transaction execution stack? </p><p>The narrow view treats the SVM as analogous to a traditional virtual machine (VM), such as the EVM’s opcode executor. More specifically, the eBPF-derived virtual machine (rBPF, now sBPF) that interprets and JIT-compiles bytecode. This perspective emphasizes the SVM as a sandboxed, register-based executor that handles instructions, such as ALU operations or Solana-specific system calls. Essentially, the SVM is inspired by Linux eBPF’s safety model, but is customized for blockchain infrastructure. This aligns with phrases like the SVM ISA (Instruction Set Architecture) in validator code, where the SVM is the VM layer <em>alone</em>.</p><p>The broad view defines the SVM as the <em>entire </em>transaction execution layer of a Solana validator. This includes more than just running bytecode; it also encompasses upstream components, such as the Banking Stage’s scheduler, compute unit budgeting, and state updates via the accounts database, colloquially known as AccountsDB. It’s the “runtime” that turns raw transactions into validated state changes.</p><p>The ambiguity arises because official Solana communications use the term “runtime” interchangeably with “SVM,” without a singular pinned definition. <a href="https://www.anza.xyz/blog/anzas-new-svm-api"><span style="text-decoration: underline">Anza has added much-needed clarity to the debate</span></a>, explicitly validating it while promoting a pragmatic, action-oriented perspective grounded in engineering. Their framing of the SVM as the Bank-driven runtime that provisions the eBPF VM offers a much broader, pipeline-inclusive view that can be used to form a proper definition of the SVM.</p><p>This is formalized in <a href="https://github.com/anza-xyz/agave/blob/master/svm/doc/spec.md"><span style="text-decoration: underline">Anza’s official SVM specification</span></a>, which defines the SVM as “the components responsible for transaction execution,” packaged as a stand-alone library for validators, fraud proofs, sidecars, and more.</p><p>For our purposes, we can define the Solana Virtual Machine as:</p><blockquote><em>The decoupled runtime interface and transaction processing pipeline within Solana validators, driven by the Bank component, that orchestrates parallel instruction and on-chain program execution, provisioning a customized eBPF-based virtual machine for secure bytecode interpretation, JIT compilation, and resource metering. </em></blockquote><h2>The SVM at a Glance</h2><p>The Solana Virtual Machine (SVM) serves as the execution environment for processing transactions that interact with on-chain programs across the network. It’s the runtime layer where code meets state—the execution environment that transforms cryptographically signed transactions into
