What is Solana Virtual Machine (SVM)
SVM is the heart of the Solana blockchain. It is the component that enables Solana to run smart contracts and process transactions. If you have used any Solana application, you have indirectly interacted with SVM; e.g., whenever you have swapped tokens on Jupiter, or minted an NFT on Magic Eden, SVM has been responsible for performing those operations for you.
In the technical jargon, the smart contracts are compiled into eBPF bytecode. eBPF stands for extended Berkeley Packet Filter, a programming language and virtual machine that enables you to run sandboxed programs in a privileged context (such as an operating system kernel). It was originally introduced in Linux for high-performance network packet processing and filtering. Solana leverages this architecture as it is capable of achieving high performance. Programmers generally write smart contracts using the high-level languages C/C++ or Rust, which are then converted into eBPF code and finally executed by SVM, resulting in extremely fast processing performance (approaching native machine code speed). Additionally, the compiler includes a Just-In-Time compilation (JIT) phase that allows the VM to achieve even higher performance.
To reiterate, the SVM is installed on each of the network’s validator nodes. When a smart contract is deployed, its execution takes place in this specific environment. The execution environment is sandboxed so that, for example, if the smart contract developer accidentally wrote some infinite loop code or attempted to read or modify some memory that the code did not have permission for, the VM would terminate that specific program without impacting any other program or the network as a whole. Each VM running each transaction yields the same results, which guarantees that the consensus state remains in sync with the ledger on every node.
How Solana Virtual Machine Handles Parallel Processing and Why It Matters
The way Solana executes transactions is very different from other blockchains. In general, blockchains only execute one transaction at a time; for example, Ethereum and Bitcoin do just that. Solana takes a different approach. The SVM can process thousands of transactions at the same time.
The way this occurs is via the Solana runtime, Sealevel. Sealevel allows for Solana to parallelize transaction processing. Before a transaction is processed, the SVM identifies all the accounts that a transaction will read from or write to. So if two transactions, Tx and Ty, attempt to read or write to different accounts at the same time, the SVM will run both transactions at the same time, on two different threads. The VM is also able to recognize if transactions are in conflict. So, if another transaction, Txz, attempts to read from or write to the same account that Tx and Ty read from or write to, the VM will run transactions Tx and Ty first, followed by Txz.
Solana utilizes many processor cores. A standard server can have anywhere from 32 cores to 64 or even more. Typically, only 1 of those cores is utilized for processing transactions. In the case of Solana, all the available cores are used. In the above case, if a stream of 10,000 transactions arrived, 5,000 of which have conflicting transactions with other transactions, the remaining transactions would be distributed among the available cores, while processing the conflicting transactions in serial or batches.
The Solana runtime uses a Multi-Version Concurrency Control (MVCC) database technique. MVCC is the same technique used by databases like PostgreSQL to handle concurrent queries to the database. The Solana runtime creates a copy of an account in memory for every transaction. Each copy remains consistent and can be used by any transaction. When it comes time to write to that account, all of the changes are merged together, provided no conflicting changes were detected. There is no need to rollback since Solana verifies every detail before it proceeds. If two transactions try to modify the same account at once, then they are serialized, but everything else is still able to execute in parallel.
In reality, consider a high demand NFT minting where 1000s of people are all minting. All of those transactions have to go through one after the other on Ethereum. The gas fees for doing it at once will go through the roof. It will cost someone like $500 in gas fees and not everyone will be successful. However, with Solana, all transactions where people are minting different NFT IDs (which of course they are) will go through in parallel at the same time. You will pay your $0.00025 transaction fee and you will either get your NFT or you won't.
Solana's Proof of History (PoH) is what makes this whole process of executing in parallel actually work in a distributed system. Proof of History creates a clock that is cryptographically verified before the transaction reaches SVM. Every transaction has a specific moment in time where it happened, cryptographically verified and not able to be faked.
The PoH's timestamp is what allows the SVM to process transactions in that order. It doesn't have to wait around to see when each one happens. The order of the transactions that come in is the order they are processed and the order they are finalized in. For example, let's say transaction A has timestamp 1000, and transaction B has timestamp 1001. The transaction B might finish processing way before A because of different complexities of each transaction. However, when they are finalized the state that they produce will still be as if A was processed before B. Tower BFT (the consensus) and the PoH work together. Tower BFT is what validators use to vote on which transactions should be included in a block and how many blocks are in a chain. They build up a tower of blocks of transactions. Every single vote of the validators stacks another block on the tower. The more votes that get added on top of the stack, the harder it becomes to reverse the block of transactions. The SVM knows that once 2/3rds or more of the validators have voted, then it is finalized and the transactions can be processed. Usually takes about 400 milliseconds.
From a developer perspective, the SVM allows apps to be built that have never really been possible before. For instance, you can build high frequency trading bots on Solana because they will be confirmed in under a second. You can build games that give feedback from the user as soon as they input an action. You can build NFT marketplaces that can handle 100s of simultaneous people minting in order to be able to keep a low gas fee of $0.00025 on every transaction whether that be a 1000 transactions per second or 65000 transactions per second.
Take for instance Serum (now OpenBook), the decentralized exchange. They created a fully on-chain order book that lets a user place an order and have it confirmed in under a second for $0.00025 per transaction. On Ethereum, the gas fees to do one swap would be $50-500 depending on the network congestion at the time. It would just be too expensive for a decentralized exchange to run. Market makers can place 100s of orders per second at a very low fee on Serum. There is enough liquidity and the tightest spreads on any market. If there were not enough liquidity on Serum, there are other options like Raydium or Orca, all of which have a fully on-chain order book. The fact that it is able to do that with such a low fee is due to the SVM.
