# SVM Series

Deep dive into Solana Virtual Machine (SVM). Some knowledge of Solana architecture like `Ledger`,`Bank`,`AccountsDB` and transactions is required to go through this series. An overview of the SVM API used in this series of articles can be found at [Anza’s SVM API blog](https://www.anza.xyz/blog/anzas-new-svm-api).

## Articles in this series

1. Introduction to SVM, a summary of SVM API blog (this article)
    
2. [SVM Series 02: SVM Feature Activation & Management](https://448.africa/svm-series-02-svm-feature-activation-and-management)
    
3. [SVM Series 03: Compute Budget & Syscalls](https://448.africa/svm-series-03-compute-budget-and-syscalls)
    
4. [SVM Series 04: TransactionBatchProcessor](https://448.africa/svm-series-04-transactionbatchprocessor)
    

## Introduction to SVM, a summary of SVM API blog

The Solana Virtual Machine is the entire transaction processing pipeline from validator’s runtime to executing Solana eBPF programs.

The `Bank` (contained in the `Ledger`) coordinates the networks state during any given slot by processing transactions, packing them into a block. Validators replaying a block attempt to rebuild a matching instance of the `Bank`.

* Transactions are processed in batches
    
* Each transactions contains one or multiple instructions
    
* Each instruction contains information to load accounts and determine write locks
    
* Read locks allow parallel data access across Bank instances
    
* Transactions are `sanitized` before they are processed
    
* De-duplication of account keys from a transaction’s instruction is done during sanitization
    
* After accounts are loaded, SVM loads the executable program for each instruction and provisions an eBPF virtual machine to execute the program, returning that result
    
* Caching is used to store the machine code from the translated program byte-code until recomputing the program byte-code is needed or when the cache is full
    

All of these processes are coordinated by the Bank within the SVM.

## Agave SVM API

> ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1754468536756/3bc1b8ab-6ac5-4586-931f-2579fba3df6a.jpeg align="center")
> 
> Credit: Anza’s Blog

The [solana-svm](https://crates.io/crates/solana-svm) Rust crate is used to build SVM applications in a protocol compliant manner. The [TransactionBatchProcessor](https://docs.rs/solana-svm/latest/solana_svm/transaction_processor/struct.TransactionBatchProcessor.html) struct is the central interface of SVM which processes batches of sanitized transactions using components in the transaction pipeline. During this series we will break down each components.

```rust
// From the `solana-svm` crate.
// The method `load_and_execute_sanitized_transactions()` on this struct is used
// to process batched transactions.
pub struct TransactionBatchProcessor<FG: ForkGraph> {
  /// Bank slot (i.e. block)
  slot: Slot,
  /// Bank epoch
  epoch: Epoch,
  /// SysvarCache is a collection of system variables that are
  /// accessible from on chain programs. It is passed to SVM from
  /// client code (e.g. Bank) and forwarded to the MessageProcessor.
  pub sysvar_cache: RwLock<SysvarCache>,
  /// Programs required for transaction batch processing
  pub program_cache: Arc<RwLock<ProgramCache<FG>>>,
  /// Builtin program ids
  pub builtin_program_ids: RwLock<HashSet<Pubkey>>,
}
```

You can read an overview of this API on Anza’s blog - [https://www.anza.xyz/blog/anzas-new-svm-api](https://www.anza.xyz/blog/anzas-new-svm-api)

## Source Code

The source code for each article can be found at [https://github.com/448-OG/SVM-Series/](https://github.com/448-OG/SVM-Series/tree/syscalls)

[Next Article: SVM Series 02: SVM Feature Activation & Management &gt;](https://448.africa/svm-series-03-compute-budget-and-syscalls)