Execution - Solana Virtual Machine (SVM)
Last updated
Last updated
At the most basic level, a VM in the blockchain context is the software that executes machine instructions to process transactions. When a transaction reaches a blockchain, it is processed by the virtual machine. Every language, whether Solidity, Rust, or Move, is ultimately converted (compiled) to bytecode which is executed by a blockchain’s virtual machine.
Different languages support compilation to different bytecodes. For example, Solidity is typically compiled to Ethereum Virtual Machine (EVM) bytecode, but the Solang compiler enables you to compile Solidity to other bytecodes such as WebAssembly (wasm) or Berkeley Packet Filter (BPF).
There are many virtual machines. How should you decide which is best for you?
Performance: Some virtual machines are designed to enable greater parallelism across transactions, such as the Solana Virtual Machine (SVM) which Eclipse uses. Others such as the EVM typically have been single-threaded.
Security: Some languages such as Rust can more easily protect against many bugs that Solidity does not. For example, Ethereum smart contracts are vulnerable to so-called reentrancy attacks.
Community: Popular blockchains like Ethereum and Solana have fostered thriving developer communities around the EVM and SVM respectively. This means better tooling and developer support compared to newer virtual machines like the Move VM or Fuel VM.
Ease-of-use: Languages such as Solidity are easier to code in, and not all bytecodes support compilation from Solidity.
Eclipse Mainnet runs the Solana Virtual Machine (SVM), but we can also support programs built for the Ethereum Virtual Machine (EVM) using Neon EVM. We will add other bytecode formats in the future as dApps request them. You can even use existing tooling for the EVM such as Truffle or Remix or tooling for the SVM such as the Solana CLI or Seahorse Lang.
The SVM and its Sealevel runtime famously enable parallel transaction execution. Transactions which don’t touch overlapping state can be executed in parallel rather than sequentially.
This allows the SVM to directly scale with hardware as processors continue to add more cores at lower cost. Single-threaded runtimes (such as today’s EVM) fundamentally do not benefit from reducing the cost per core. For over a decade now, single-threaded performance speedups have been continually diminishing. Nearly all improvements continue to come from increasing the number of cores, so it’s critical to take advantage of this trend by parallelizing workloads:
There are some very early unproven attempts to parallelize the EVM, but adding this on while maintaining compatibility brings fundamental tradeoffs including suboptimal performance without addressing other bottlenecks (e.g., state growth). Contracts declaring state dependencies upfront (as in the SVM) allows for optimal parallelization.
Most fee markets today are global, meaning that one hot application increases fees for all users of the chain. One NFT mint shouldn't render the chain useless for everything else. Solana's amazing work on local fee markets solves this cross-app state contention. In its current implementation, the scheduler prioritizes transactions without conflicts, allowing conflict-free transactions to go through with lower fees. Longer term, local fee markets will be implemented at a protocol level. This ensures that fee spikes for a single app don't impact the rest of the chain.
Local fee markets are possible thanks to Solana’s uniquely parallelized runtime. Trying to implement local fee markets for state hotspots in the EVM using heuristics (i.e., without declaring state access upfront) would present inefficiencies and likely attack vectors.
There's also early research underway that would allow applications to easily internalize the local value attributable to them, which today generally requires more creative app-level design.
Before the EVM even bumps up against sequential execution as a bottleneck, state growth is its far more pressing bottleneck.
Because there is no global Merkle tree for state, Solana doesn't incur the overhead of updating a Merkle tree for each state update. Instead, after each epoch (~2.5 days), the entire state is merklized. This is much cheaper than real-time merklization (as in the EVM).
More importantly, the EVM has dynamic account access (i.e., transactions can touch any state on-demand). That dynamic state lookup means that state cannot be loaded into memory prior to execution. In the SVM, each transaction specifies all the state that’s needed for execution.
As a result, state size doesn't impact SVM execution. The network could safely double the snapshot size every 2 years without running into major issues assuming validators upgrade their storage disks every 2 years.
Furthermore, teams like Helius are actively improving the accessibility of historical data and reducing state size with compression.
Neon EVM is an EVM operating as a smart contract that can be deployed on any SVM chain. This brings full EVM compatibility to Eclipse Mainnet (including EVM bytecode support and the Ethereum JSON-RPC) with greater throughput than single-threaded EVMs. Because each Neon EVM instance has its own local fee market, apps can just deploy their own contract to attain the benefits of an app chain without fragmenting UX, security, or liquidity.
Separately, the Solang compiler enables compilation of Solidity smart contracts code into SVM bytecode.
Onboarding EVM users to non-EVM chains has historically been a major hurdle, but the recently unveiled Metamask Snaps are set to break down that barrier. EVM users can continue to use MetaMask without needing to switch wallets. The UX is comparable to interacting with any EVM chain, thanks to Drift's open-source contributions building out a great MetaMask Snap implementation. Eclipse Mainnet users will be able to interact with apps natively in MetaMask or use a Solana-native wallet like Salmon.
Here's a sneak peek of the UX from Drift:
Firedancer is the highly anticipated Solana client being developed by Jump to drastically increase the network's throughput, resilience, and efficiency. At launch we will stick as closely as possible to the Solana core client, but we plan to adopt Firedancer once the code is live and stable.
Solana's runtime has a greatly reduced attack surface area which prevents the infamous reentrancy exploits we’ve seen far too often. Specifically, the Solana runtime only allows programs to self-recurse, rather than allowing arbitrary reentrant cross program invocations. Moreover, separating state and code results in stateless code, which is typically easier to test effectively.
The SVM is register-based and has a much smaller instruction set vs. the EVM, making SVM execution easier to prove in ZK. For optimistic rollups, the register-based design allows for easier checkpointing.
