What is Sealevel?
Sealevel is Solana’s parallel smart contract runtime, enabling validators to execute thousands of simultaneous transactions across multiple CPU cores. It acts like a traffic control tower that directs traffic through multiple lanes of a busy highway. Where EVM runs transactions in order, Sealevel spreads work out on 8 CPU cores, 16 CPU cores, or 32 CPU cores.
The runtime is a critical component of Solana’s transaction processing pipeline, which also includes the Transaction Processing Unit (TPU) and Transaction Validation Unit (TVU). All Solana transactions are precompiled with information on the data it needs to modify. This means the runtime can determine if two transactions will interfere with each other. For instance, if transaction A tries to change Alice’s balance and transaction B tries to change Bob’s balance, Sealevel can run both on different CPU cores since they won’t be overwriting the same piece of data.
How Sealevel Enables Parallel Processing
When Sealevel receives a batch of transactions, it first analyzes what accounts they will modify and then organizes them based on that. Suppose you’ve packed 1,000 transactions into a block. Sealevel will then organize them based on which accounts they need to access. If 500 transactions are modifying account X, while another 100 are modifying account Y, these will be processed in separate bins or CPUs. All other transactions will be run in parallel until all bins have been exhausted. Any accounts modified by multiple transactions (a potential race condition) will be queued, and those will run after the rest.
In addition, Solana modified its runtime to allow programs to execute inside a modified version of the Berkeley Packet Filter (BPF) virtual machine, a widely used packet filtering system in modern Linux kernels. It is secure, has been extensively tested, and is a popular way of running programs written in any modern language. Programs can run directly in BPF, allowing them to be written in Rust or C, compiled as BPF, and then executed and compiled on-chain during deployment. BPF VMs will execute the BPF bytecode of the program within a secure, sandboxed environment. It is sandboxed so it does not read and write memory outside of its allocated space. It ensures it will not be able to corrupt another process or crash a validator node.
The runtime is highly optimized for read-only operations. If a transaction is reading account information, it can retrieve information for 100 accounts or 500 accounts. This is because there will be no race conditions as no writes are being made in these transactions. BPF VMs can also take advantage of CPU SIMD instructions and other hardware optimization. If multiple operations are being performed on the same data, the hardware can do these all at once. If a transaction fails while running, any changes it makes will be reverted.
Benefits and Impact on Solana’s Performance
This execution model is what allows Solana to process 3,000+ transactions per second today, as well as handle much more during NFT mints or popular DApps. While Ethereum runs transactions sequentially at about 15-30 transactions per second and most other chains run about 100-500 transactions per second. Sealevel uses all CPU cores available to process these transactions instead of waiting to process the previous transaction.
This is possible because the higher the amount of CPU cores a validator has, the more transactions it will be able to process. For instance, if a validator switches out their 16 core CPU processor for a 32 core CPU processor, that validator will theoretically have been able to process twice as much transactions. Other networks require upgrades to their protocol to allow for more transactions per block. However, it is rare that CPU becomes the constraint during transaction processing; instead it usually takes the form of data or networking speed. With high end processors such as the AMD EPYC processors, validators should be able to process thousands of transactions per second in production environments.
For developers, this is crucial for building applications such as high frequency trading bots that can submit transactions and have them confirmed within blocks of 400ms and gas costs under 0.001. Other chains would not be economically viable for these types of use cases. Developers do not have to worry about race conditions with these use cases. With the combination of parallel processing, it means games, games with real time gameplay updates and fast DeFi can be created on Solana and users have a great experience with it.
