Sealevel — Parallel Processing Thousands of Smart Contracts

Understand 1 of 8 key technologies that make Solana the most performant blockchain in the world

Solana is the most performant permissionless blockchain in the world. On current iterations of the Solana Testnet, a network of 200 physically distinct nodes supports a sustained throughput of more than 50,000 transactions per second when running with GPUs. Achieving as such requires the implementation of several optimizations and new technologies, and the result is a breakthrough in network capacity that signals a new phase in blockchain development.

There are 8 key innovations that make the Solana network possible:

• Proof of History (POH) — a clock before consensus;
• Tower BFT — a PoH-optimized version of PBFT;
• Turbine — a block propagation protocol;
• Gulf Stream — Mempool-less transaction forwarding protocol;
• Sealevel — Parallel smart contracts run-time;
• Pipelining — a Transaction Processing Unit for validation optimization
• Cloudbreak — Horizontally-Scaled Accounts Database; and
• Archivers — Distributed ledger store

In this blog post, we’ll explore Sealevel, Solana’s parallel smart contracts runtime. Before we start, one thing to consider is that EVM and EOS’s WASM-based runtimes are all single threaded. That means that one contract at a time modifies the blockchain state. What we’ve built in Solana is a runtime that can process tens of thousands of contracts in parallel, using as many cores as are available to the Validator.

The reason why Solana is able to process transactions in parallel is that Solana transactions describe all the states a transaction will read or write while executing. This not only allows for non-overlapping transactions to execute concurrently, but also for transactions that are only reading the same state to execute concurrently as well.

Programs and Accounts

Cloudbreak, our accounts database, is a mapping of Public Keys to Accounts. Accounts maintain balances and data, where data is a vector of bytes. Accounts have an “owner” field. The owner is the Public Key of the program that governs the state transitions for the account. Programs are code and have no state. They rely on the data vector in the Accounts assigned to them for state transitions.

1. Programs can only change the data of accounts they own.
2. Programs can only debit accounts they own.
3. Any program can credit any account.
4. Any program can read any account.

By default, all accounts start as owned by the System Program.

1. System Program is the only program that can assign account ownership.
2. System Program is the only program that can allocate zero-initialized data.
3. Assignment of account ownership can only occur once in the lifetime of an account.

A user-defined program is loaded by the loader program. The loader program is able to mark the data in the accounts as executable. The user performs the following transactions to load a custom program:

1. Create a new public key.
2. Transfer coin to the key.
3. Tell System Program to allocate memory.
4. Tell System Program to assign the account to the Loader.
5. Upload the bytecode into the memory in pieces.
6. Tell Loader program to mark the memory as executable.

At this point, the loader verifies the bytecode, and the account to which the bytecode is loaded into can be used as an executable program. New Accounts can be marked as owned by the user-defined program.

The key insight here is that programs are code, and within our key-value store, there exists some subset of keys that the program and only that program has write access.

Transactions

Transactions specify an instruction vector. Each instruction contains the program, program instruction, and a list of accounts the transaction wants to read and write. This interface is inspired by low level Operating System interfaces to devices:

size_t

readv(int d, const struct iovec *iov, int iovcnt);

struct iovec {

char *iov_base; /* Base address. */

size_t iov_len; /* Length. */

};

Interfaces such as readv or writev tell the kernel ahead of time all the memory the user wants to read or write. This allows the OS to prefetch, prepare the device, and execute the operation concurrently if the device allows it.

On Solana, each instruction tells the VM which accounts it wants to read and write ahead of time. This is the root of our optimizations to the VM.

1. Sort millions of pending transactions.
2. Schedule all the non-overlapping transactions in parallel.

What’s more is that we can take advantage of how CPU and GPU hardware are designed.

SIMD instructions allow for a single piece of code to execute over multiple data streams. This means that Sealevel can execute an additional optimization, which is unique to Solana design:

1. Sort all the instructions by program ID.
2. Run the same Program over all accounts concurrently.

To get an idea of why this is such a powerful optimization, take a look at the CUDA Developer Guide:

“The CUDA architecture is built around a scalable array of multithreaded Streaming Multiprocessors (SMs). When a CUDA program on the host CPU invokes a kernel grid, the blocks of the grid are enumerated and distributed to multiprocessors with available execution capacity.”

A modern Nvidia GPU has 4000 CUDA cores, but about 50 multiprocessors. While a multiprocessor can execute only a single program instruction at a time, it can execute that instruction over 80 different inputs in parallel. So, if the incoming transactions that are loaded by Sealvel all call the same program instructions, such as CryptoKitties::BreedCats, Solana can execute all the transactions concurrently over all the available CUDA cores.

There is no free lunch in performance, so for SIMD optimizations to be feasible, the executed instructions should contain a small number of branches and should all take the same branch. The multiprocessor is bound by the slowest path execution will take in the batch. Even with this consideration, parallel processing via Sealevel presents a foundational development in the way that blockchain networks function compared to single-threaded runtimes, enabling exceptionally high throughput and usability.

Solana’s implementation of Sealevel, alongside innovations like Proof of History, Proof of Replication, and Gulf Stream combine to create the most performant blockchain in the world. Solana’s testnet is live today. You can see it at https://testnet.solana.com. For cost purposes, we are only running a handful of nodes. However, we have spun it up on many instances to over 200 physically distinct nodes (not on shared hardware) across 23 data centers on AWS, GCE, and Azure for benchmarking.

The runtime is functioning today, and developers can deploy code on the testnow now. Developers can build smart contracts in C today, and we are aggressively working on the Rust toolchain. Rust will be the flagship language for Solana smart contract development. The Rust toolchain is publicly available as part of the Solana Javascript SDK, and we are further iterating on the Software Development Kit.

Solana will soon launch a public beta incentivizing validators to run nodes via Tour de SOL — analogous to Cosmos’s Game of Stakes — that challenges the public at large to test the limits of the Solana network while earning tokens for doing so.