Sei v2 - The First Parallelized EVM Blockchain

Sei v2 - The First Parallelized EVM Blockchain

An additional technical note exploring further detail can be found here on the Sei Developer Forum

In this post, Sei Labs introduces and proposes an upgrade to Sei: v2 - the first parallelized EVM.

Sei v2 takes the proven advantages of Sei and makes it accessible to a global base of EVM developers. This allows Sei to get the best of Solana and Ethereum - a hyper optimized execution layer that benefits from the tooling and mindshare around the EVM.

Nontechnical summary

Sei has been live on the mainnet beta since August 2023, and during this time, it has been pushing the edge of what had previously been considered possible to do with a globally distributed set of nodes:

  • Sei has consistently been finalizing blocks at 390ms, making it the fastest chain in existence
  • Sei has consistently seen activity of over 45 TPS, making it the chain with the second highest number of successful transactions per second currently in operation [1]

All of this has been done so with no outages nor unanticipated network downtime. This has reinforced the underlying technical thesis that an integrated blockchain leads to substantially better performance than using a modular chain.

Sei currently allows for Cosmwasm smart contracts, which are written in Rust. As Sei continues to garner more developer interest, the biggest request from developers has been additional flexibility in the execution environments that Sei supports. In particular, EVM support is top of mind for many developers. 

As a result, we propose Sei V2: Sei’s first major upgrade to become the first fully parallelized EVM. This upgrade will result in Sei having the following functionality:

  • Backwards compatibility of EVM smart contracts - allowing developers to deploy audited smart contracts from EVM compatible blockchains with no code changes 
  • Reusability of familiar and widely used applications and tooling such as Metamask
  • Optimistic parallelization - allowing the chain to support parallelization without requiring developers to define any dependencies
  • SeiDB - improvements to the storage layer to prevent state bloat, improve state read/write performance, and make it easier for new nodes to state sync and catch up
  • Interoperability with the existing chain, allowing for seamless composability between EVM and any other execution environments supported on Sei.

From a performance perspective, Sei V2 will offer 28,300 batched transactions per second of throughput, while offering 390 ms block times and 390 ms finality. This allows Sei to support many more users and far more interactive experiences than existing blockchains, while offering far cheaper per-transaction costs.

Sei’s major upgrade is nearly code complete right now. Once audits are complete, this upgrade will be released in a public testnet in Q1 2024, and will get deployed to mainnet sometime in H1 2024. 

How it works

Sei is composed of different software components that all work with each other to support the blockchain. Some of these components are tied to the consensus layer, and others are tied to the execution layer. 

Sei V2 will be changing the way the execution layer works to support optimistic parallelization and optimized state storage. Additionally, it will also create a new component to support EVM smart contracts. These EVM smart contracts will benefit from all of the changes made to consensus and parallelization, and also be able to interact with existing Cosmwasm smart contracts.

Summary of Proposed Changes

Backwards compatibility

Rather than requiring developers to completely rewrite their smart contracts to deploy on Sei, Sei V2 is built with backwards compatibility in mind. This means that every major contract that exists on Ethereum can seamlessly be redeployed on Sei with no code changes required [2]  

From a technical perspective, as part of the Sei chain binary, Sei nodes will automatically import Geth, a Go implementation of the Ethereum Virtual Machine. Geth will be used to process ethereum transactions, and any resulting updates (state updates, or invocations of non-EVM related contracts) will be made with a special interface that Sei has created for the EVM. 

Geth Implementation as part of the Core Sei Binary

This approach allows for full bytecode compatibility, allowing for anything that can run with Geth to be processed easily by Sei. Additionally, since the RPC interface will be identical for Sei as EVM, existing tooling from Ethereum can be seamlessly reused. For example, users can use Metamask by just switching the RPC they’re connected to, and developers can use tooling such as Foundry, Remix, and Hardhat.

Optimistic parallelization

Sei currently requires smart contract developers to optionally define the state that smart contracts are using. This optional approach unfortunately introduces greater developer friction.

Sei V2 will remove the need for developers to define state access themselves. Instead, the chain will optimistically run all transactions in parallel. Whenever there are conflicts (transactions touching the same state), the chain will track what parts of storage each transaction is touching. Transactions touching different parts of storage will be rerun in parallel, and transactions touching the same state will be rerun sequentially. This will recursively continue until there are no more conflicts that are unaccounted for. Since the transactions are ordered in a block, this is a deterministic process that will ease the developer workflow while maintaining parallelization at the chain level.

Tx Lifecycle in the Event of Optimistic Parallelization Conflict

Optimistic parallelization will apply to all transactions that are run on Sei, including Sei native transactions, Cosmwasm transactions, and EVM transactions. More details about the technical implementation can be found here

SeiDB

Sei currently uses a vanilla database layer which is composed of an IAVL tree data structure. This data structure is less efficient from both a storage and latency perspective because of its schema and additional metadata, leading to greater write amplification and slower disk access.

Sei has re-architectured the storage interface to optimize for different use cases. Sei has done this by breaking the single IAVL tree into 2 components - state store and state commitment (motivation). The state store layer provides low latency direct access to raw key-value pairs which will help RPC nodes better serve queries. Storing historical data as raw key-value pairs removes the overhead of redundant metadata and helps reduce the disk usage by orders of magnitude. The state store also uses a write-ahead log to help with recovery in the event of a crash. The state commitment layer uses a highly optimized in-memory IAVL tree that is responsible for committing data which will help validators reach consensus even faster since the amount of disk access is reduced.

In addition to this change, rigorous benchmarking was done on various industry leading databases, and Sei V2 will be moving towards using PebbleDB instead of GoLevelDB, which results in substantially improved read/write performance for multi-threaded access. 

More details about the technical implementation can be found here

Interoperability

Because Sei is an integrated chain, all transactions going to different components of Sei (Cosmwasm, EVM, bank, staking) are able to communicate with each other. Although these transactions serve different purposes, they ultimately have many similar features such as gas, sender, and transaction body. When the chain receives these transactions, they are processed as Sei native transactions and are forwarded to appropriate sections of storage (i.e. CosmWasm transactions are sent to the wasm module and executed). This leads to a more seamless developer experience - EVM developers can easily access native tokens and other chain features such as staking. 

How Transaction types Would Interact with Sei's Multiple Virtual Machines

Performance metrics

At the time of writing, SeiDB and Optimistic parallelization are code complete. EVM implementation is still a work in progress, and should be code complete in the next couple of months. As a result, Sei V2 will be ready for a testnet launch in early 2024. 

Initial performance numbers for SeiDB and optimistic parallelization are indicating the following performance:

Performance Metrics

These tests were performed in a twenty node cluster that was equally split across Ohio, California, Frankfurt, and Ireland. Each node was an AWS 8xlarge, with 32 cores and 64GB RAM.

Conclusion

This proposal outlines a route for Sei to support and supercharge multiple virtual machines, starting with the first parallelized EVM.

Applications currently built on any EVM chain will be able to deploy on Sei to support many more users and far more ‘web-2’ like interactive experiences than on existing blockchains.

Furthermore they can offer far cheaper per-transaction costs, higher throughput and suffer from none of the centralization tradeoffs, complexity or the overhead of operating an Ethereum L2 rollup.

In this way, Sei is making the EVM simple again.

A governance proposal will be raised in the coming weeks for this proposal to be discussed and voted on.

An additional technical note exploring further detail can be found here on the Sei Developer Forum - contributions, questions and thoughts are welcomed.

Footnotes

[1] This figure represents activity, and not the maximum threshold of transactions that Sei can handle.

[2] The biggest difference between Ethereum L1 and Sei V2 is way that state is stored - Ethereum uses a Patricia Merkle Tree, whereas Sei uses an IAVL tree, so anything that requires a state proof will need to be rewritten.