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 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). You can even use existing tooling for the SVM such as the Solana CLI or Seahorse Lang.
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. . 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 :
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.
Before the EVM even bumps up against sequential execution as a bottleneck, state growth is its far more pressing bottleneck.
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.\
There are some very early unproven attempts to , 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. . Solana's amazing work on 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.
There's also that would allow applications to easily internalize the local value attributable to them, which today generally requires .
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 (as in the EVM).
More importantly, the EVM has (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, . 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 are actively improving the accessibility of historical data and reducing state size with .
Onboarding EVM users to non-EVM chains has historically been a major hurdle, but the recently unveiled are set to break down that barrier. EVM users can continue to use without needing to switch wallets. The UX is comparable to interacting with any EVM chain, thanks to '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 .
:
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 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.
