Full Report
This article describes the process of executing a transaction within the Solana Virtual Machine. Unlike an EVM, where execution means executing opcodes in a VM, the SVM (Solana Virtual Machine) refers to the entire execution pipeline. This article explains the SVM in great detail. They choose to analyze codebases (Agave and Firedancer clients) rather than rely on a specification. The SVM has several main components: Banking Stage: Orchestrates the execution of a transaction at a specific slot. Gets the information from the Transaction Processing Unit (TPU). Handles parallel execution via checking account overlaps in transactions to be executed. BPF Loader: Loads and JIT compiles an sBPF program. sBPF VM: The sandboxed execution environment. uses a variant of BPF. These are also system calls to leave the sandbox. AccountsDB: Persistent state layer where all account data, including the running code, lives. A Solana program is usually written in Rust. It expects a single entrypoint function with the ProgramID of the program itself, an array of account information, and a byte slice of data needed for the transaction. The solana-program serves as the main library for interacting with the runtime, including transferring SOL and executing syscalls. Once compiled with Rust, keeping all its invariants, the code is lowered to LLVM IR. This is then translated into eBPF for actual usage. This allows for a pre-built sandbox to be executed within Solana. Solana originally forked eBPF for its own purposes but has since reverted to the original implementation. The Instruction Set Architecture (ISA) contains 11 registers and uses a RISC-like design for about 100 opcodes. There is the loaded program code, stack, heap, input data passed within the transaction, and other read-only data within defined memory regions of the VM. The execution has a verifier for illegal jumps, unhittable code paths, call depth restrictions and many other things. The runtime has many Syscalls for executing special functions for interacting with the outside world, such as logging and other contract calls. The program binary, that is uploaded by the user, is simply an ELF file. It contains a bytecode section, read-only data, BSS/data, and a symbol/relocation table. To upload the code to Solana, the special BPFLoaderProgram is used. Currently, there are two accounts associated with a program: one for the actual code and another for holding metadata about it. First, all of the bytecode is written via a combination of InitializeBuffer and Write() to an account. Once this is finished, a separate instruction runs various checks, such as bytecode and ELF verification. The pipeline for executing a transaction is now as follows: User signs a transaction and forwards their intent to an RPC provider for propagation and execution. The transaction is sent to the TPU on each Solana validator that received the TX. The transaction is sent to the TPU on each Solana validator that received the TX. This includes signature verification and the fetching of necessary information for execution. The banking stage performs the actual execution. This includes loading, JITing and execution, as described before. Post execution verification is the final step. This will ensure state consistency, account ownership checks, lamport checks, and more. Commit all of the account modifications to storage. Overall, a great post on teaching the nitty-gritty details of the SVM. This explains much of the complexities of execution, which is much appreciated!
Analysis Summary
# Research: What is the Solana Virtual Machine (SVM)?
## Metadata
- **Authors:** 0xIchigo
- **Institution:** Helius Labs
- **Publication:** Helius Blog / Fundamentals
- **Date:** November 4, 2025
## Abstract
This research provides a comprehensive technical deconstruction of the Solana Virtual Machine (SVM). Unlike the Ethereum Virtual Machine (EVM), which centers on a bytecode executor, the SVM is characterized as a holistic transaction execution pipeline. The study traces the lifecycle of a transaction from high-level Rust source code through LLVM intermediate representation to sandboxed sBPF (Solana Berkeley Packet Filter) execution, detailing the architectural components that enable high-parallelism and low-latency throughput.
## Research Objective
The article addresses the ambiguity surrounding the definition of "SVM" and seeks to provide a definitive technical map of Solana’s execution layer. It specifically investigates how the SVM departs from traditional sequential VM designs to achieve parallel execution.
## Methodology
### Approach
The research employs a code-first analysis of the Agave (Anza) and Firedancer validator clients rather than relying on abstract specifications. It utilizes a "bottom-up" approach, tracing data from compilation to execution and final state commitment.
### Dataset/Environment
The study investigates the Solana mainnet architecture and the underlying sBPF Instruction Set Architecture (ISA).
### Tools & Technologies
- **Compilers:** `rustc`, LLVM IR, LLVM eBPF backend.
- **Client Codebases:** Agave (Anza) and Firedancer.
- **Virtualization:** rBPF/sBPF (Solana’s fork of eBPF).
- **Storage:** AccountsDB.
## Key Findings
### Primary Results
1. **Pipeline-Centric Model:** The SVM is not just an interpreter but an integrated pipeline consisting of the Banking Stage (scheduling), BPF Loader (JIT/Loading), and sBPF VM (execution).
2. **Parallel Execution via Account Access Lists:** By requiring transactions to declare account dependencies upfront, the SVM can execute non-conflicting transactions in parallel across multiple CPU cores.
3. **sBPF Standardization:** Solana uses "sBPF," a fork of Linux’s eBPF. Key differences include support for more than five function arguments and specific syscall integrations.
### Supporting Evidence
- **Instruction Set Architecture (ISA):** The SVM utilizes a RISC-like design with 11 registers and ~100 opcodes.
- **Two-Account Deployment:** Historical deployment required an executable account and a data account for metadata, facilitating in-place upgrades.
### Novel Contributions
- **Deterministic Resource Bounding:** Introduction of "Compute Units" (CU) to prevent halting problems and resource exhaustion within the sandbox.
- **Static Verification:** Systematic bytecode verification (checking for illegal jumps and call depth) occurs prior to execution to ensure runtime safety.
## Technical Details
The execution flow follows a specific sequence:
1. **Compilation:** Source code (Rust/C/C++) is lowered to LLVM IR and then to sBPF bytecode stored in ELF files.
2. **TPU Banking Stage:** Receives transactions, verifies signatures, and fetches account state from AccountsDB.
3. **The Sandbox:** The sBPF VM provides isolated memory regions (Stack, Heap, Input Data). External interactions (logging, cross-program invocations) occur via **Syscalls**, which allow controlled exits from the sandbox.
4. **Finalization:** Post-execution checks ensure lamport balances are consistent and account ownership rules are respected before committing to storage.
## Practical Implications
### For Security Practitioners
- **Bytecode Verification:** The SVM's static verifier acts as a primary defense against malformed or malicious code before it ever reaches the processor.
- **Isolated Memory:** Understanding the restricted memory regions (Stack/Heap) is critical for identifying potential buffer overflow or memory exhaustion vectors.
### For Defenders
- **Account Locking:** Defenders can monitor account access patterns; since transactions must declare accounts, "hot" accounts (contended state) can be identified in real-time to mitigate congestion.
- **Signature Verification:** Large-scale signature verification happens at the TPU level, offloading work from the execution core and providing a layer of DoS protection.
### For Researchers
- **Validator Diversity:** The research highlights that the SVM is being reimplemented in Firedancer, opening doors for cross-client differential fuzzing.
## Limitations
- **Client Focus:** The analysis is primarily based on the Agave implementation; specific optimizations within the Firedancer client were noted as outside of the current scope.
- **Spec Documentation:** The lack of a single, formal "SVM Specification" (outside of the ISA) remains a hurdle for third-party implementations.
## Comparison to Prior Work
Unlike the EVM’s stack-based architecture and sequential execution, the SVM is a **register-based** machine that prioritizes **parallelism**. While Ethereum focuses on a "World State" updated one-by-one, the SVM treats state as discrete accounts that can be modified concurrently if they do not overlap.
## Real-world Applications
- **High-Frequency Trading:** Low-latency execution via parallel transaction processing.
- **Internet Capital Markets:** Scalable infrastructure for global financial systems requiring high throughput and low costs.
## Future Work
- **Loader V4:** Transitioning to a single-account model with optional compression for program deployment.
- **Compute Cap Removal:** Proposals to remove block-level compute caps in favor of hardware-driven limits and Alpenglow’s timeout mechanisms.
## References
- Anza’s New SVM API (h-t-t-p-s://www.anza.xyz/blog/anzas-new-svm-api)
- Helius: The Solana Programming Model (h-t-t-p-s://www.helius.dev/blog/the-solana-programming-model)
- Ubermensch: Under the Hood of Solana Program Execution (h-t-t-p-s://ubermensch.blog/under-the-hood-of-solana-program-execution)