Layer1 Introduction | A Simple Guide to Understand the Highlights of Sei Network V2

A parallel processing blockchain designed specifically for transactions, Sei Network, launched its token and mainnet in August this year. After causing a market frenzy, Jayendra Jog, the founder of Sei Labs, recently announced the release of Sei v2. The update will integrate EVM, optimize parallel processing mechanisms, and enhance ledger storage structures.

Table of Contents

What is Sei Network?

Sei: Born for Transactions

Sei Parallel Processing Mechanism

Sei v2 Update Direction

Virtual Machine: EVM Support

Original Design: Sei v1 Uses CosmWasm Virtual Machine

Update Focus: Sei v2 Integrates EVM Support

Optimizing Sei Parallel Processing Mechanism

Original Design: Sei v1 Requires Defined Resource Scope for Contracts

Update Focus: Sei v2 Simplifies Contract Parallel Execution Mechanism

Optimizing Ledger Storage Structure: SeiDB

Original Design: Sei v1 Stores Large Amounts of State Data

Update Focus: Sei v2 Separates Ledger Structure

Consensus Mechanism

Sei Competes in the Frontline through Trade-offs

What is Sei Network?

Sei: Born for Transactions

Sei Network has a clear market positioning, providing an efficient environment for the trading of virtual assets. In addition to common tokens, virtual assets include NFTs, social graphs, game items, aiming to create the best user experience by offering a dedicated underlying environment for transactions.

There are many types of virtual asset transactions(source)

Trading is not limited to cryptocurrencies, so the trading of virtual assets is the most widespread demand in the online world. The team believes that the most successful Web3 applications involve trading attributes:

Advertisement - Please scroll down if the text is not finished

• Indirect transactions: Most users on the chain conduct virtual asset transactions by using Uniswap and OpenSea.
• Direct transactions: Projects that are directly subject to transactions are mostly games or NFT projects, such as Axie Infinity or BAYC.

Therefore, the demand for transactions will never disappear and is an important link in the future of Web3. To complete the positioning of the best transaction network, it is necessary to provide a highly efficient environment, and Sei uses parachain processing design and consensus mechanisms to achieve this goal.

Sei parallel processing mechanism

Sei Network’s mainnet has been online for over three months. According to official data, the network currently averages 20,000 TPS with a final confirmation time of 390 milliseconds. The team claims it is the most efficient network in the industry, thanks to its innovative parallel processing mechanism.

When transactions on the Sei blockchain do not involve the same resources (addresses), all transactions can be processed simultaneously without the need to order transaction sequences. This significantly improves network operational efficiency.

Sei v2 update direction

When looking at a blockchain project, there are three main evaluation points: ledger structure, consensus mechanism, and virtual machine. Coupled with Sei’s unique parallel processing mechanism, you can clearly understand the differences in this update of Sei v2.

Sei Network v2 main updates (source)

Founder Jayendra said that Sei v2 only adds new features and will not affect existing features. Users and developers do not need to perform any additional operations for this update.

The Sei v2 proposal mainly contains three updates:

• Support EVM
• Optimize parallel processing mechanism
• Optimize ledger storage structure

This update is expected to be completed in Q1 2024.

Virtual machine: supports EVM

Original design: Sei v1 uses CosmWasm virtual machine

Sei is built using the Cosmos SDK and uses the CosmWasm virtual machine, a component provided by the latter. CosmWasm is a virtual machine component specially built for the Cosmos ecosystem. The underlying layer is WebAssembly (Wasm) and is named after it. Blockchains built using the Cosmos SDK can add CosmWasm to their chain without adjusting existing logic.

WebAssembly can support a variety of common programming languages, including Rust, C, C++, etc., so if you are a Rust developer, you can easily write smart contracts on CosmWasm, so Sei attracts developers outside the circle.

Update highlights: Sei v2 will support EVM integration

However, the Sei Labs team found that despite high developer engagement, they were losing the Ethereum Virtual Machine (EVM) ecosystem. EVM is the virtual machine used by most existing industry applications and products. Losing this ecosystem could hinder Sei’s rapid development at this stage, for example, existing Ethereum projects cannot fork into the Sei ecosystem.

To address this, the team updated the dedicated code repository, Core Sei Binary, introducing a dedicated interface for EVM RPC and Geth nodes. This allows EVM transactions to seamlessly be deployed and interact with the Sei network.

Choosing Geth was based on its relative stability. Jayendra Jog mentioned that currently, 80% of Ethereum nodes use Geth, and it supports full EVM bytecode compatibility. This means developers can replicate contracts from other EVMs and run them seamlessly on the Sei network.

Main updates of Sei Network v2 (source)

Sei v2 will also use EVM RPC, allowing users to easily use wallet operations such as Metamask, while developers can continue to use tools such as Foundry, Remix and Hardhat.

Therefore, Sei v2 will enable composability between EVM and Cosmwasm transactions. Sei’s Geth has a precompiler that allows calling Cosmwasm contracts, and Sei’s wasmd module can also reversely call EVM contracts, which will make the assets in Sei’s ecosystem more valuable.

Optimize Sei parallel processing mechanism

Original design: Sei v1 contract needs to define resource categories

In the original Sei Network, for transactions to be processed in parallel, developers needed to learn how to “mark the contract’s resource usage.” When developers write contracts on Sei, they are required to define the resources a contract might need to access and their independence. This is crucial for Sei to quickly distinguish resource independence when executing contracts, deciding whether to process transactions in parallel or in a specific order.

To enable parallel execution of contracts, developers must identify the resources, including querying contracts, needed during execution. They then have to write the resource scope in JSON format on the chain. This inadvertently causes challenges for developers and increases the entry threshold and security concerns.

Update focus: Sei v2 simplifies contract parallel operation mechanism

Sei v2 will optimize the parallel processing mechanism and no longer require developers to manually define dependencies. Instead, it can handle the parallelization mechanism by itself, reducing the burden on developers.

The new parallel processing mechanism will execute all transactions in a unified manner. If resource conflicts are found, the network will re-examine the sequence and re-execute.

Sei v2 automatically handles resource overlapping issues (source)

If the transaction involves different accounts, for example, Alice transfers money to Bob and Carol transfers money to Dave, then the transaction will be processed in parallel because there is no overlapping dependency; if the transaction involves the same account, for example, Alice and Bob both transfer money to Carol, then it is necessary to re-run in sequence.

However, there may be concerns about this design. If the worst case scenario occurs, all transactions involve correlation and need to be re-run in order. Re-running these transactions will increase the execution time by 30% compared to the case where they are originally run in order.

Fortunately, according to Ethereum historical data, only about 15% of transactions will actually have resource overlap and need to be reprocessed in order, so the team assessed that the overall performance of Sei will still be significantly improved.

Optimize ledger storage structure: SeiDB

Original design: Sei v1 stores a large amount of state data

However, Sei faces another issue where it permanently stores the entire IAVL tree in the distributed ledger. Due to its rapid finality and parallel processing design, frequent recording of global state changes is required, leading to a significant increase in the overall network ledger size.

The cost of parallel processing is the recording of many invalid intermediate state data. According to the RFC proposed by the Sei team, for example, on the atlantic-2 testnet node, out of the 25 GB of data stored, only 10 GB contains meaningful transaction information. This results in inefficient utilization of node disk space.

Due to data inflation, the disk usage of Sei nodes grows rapidly. The archival node’s hard disk usage on atlantic-2 increases by over 150 GB per day and exceeds 1 TB per week. As the chain state continues to grow, the storage space growth rate will also increase (becoming faster).

It will cause many problems:

• The maintenance cost of nodes will become higher and higher
• Database operations will become slower and slower
• RPC nodes cannot run for long periods of time as the disk fills up quickly

Coupled with the parallel processing design of future v2 round-trip processing and re-validation, the overall network status will change more frequently, resulting in a significant increase in the amount of status data.

Update focus: Sei v2 separated ledger structure

Sei v2 also has an optimized storage mechanism to solve the above problems to prevent the expansion of state data and increase the speed of data reading by all nodes.

Sei v2 splits the state storage ledger into two types, called SeiDB:

• State Commitment (SC): records MemIAVL tree information
• State Store (SS): records complete information

Due to the improvement of SeiDB, the verification node only needs to record the SC ledger information, while the complete state information is recorded by the SS layer, and the transmission will be placed in the write-ahead log first without the need for real-time transmission, which allows the state to be stored asynchronously to improve performance since it does not affect block generation.

Sei v2 reduces the burden of data growth on verification nodes (source)

With improvements in SeiDB, Sei has seen enhancements in various aspects of performance. This includes a 100x increase in block submission time, compression of daily data generation from 100 GB to 5 GB, and a 10x improvement in the catch-up time for all nodes or nodes requiring synchronization information.

Consensus mechanism

Sei Network v2 has not altered its original consensus mechanism and continues to maintain the Twin Turbo design. By enhancing the Cosmos consensus interface Tendermint ABCI, the block confirmation time has been significantly reduced.

Sei Entering Top-Tier Competition

Sei v2 introduces an EVM virtual machine, along with improvements to parallel processing and distributed ledger storage mechanisms. The goal is to enhance the user experience for developers, nodes, and users, thereby increasing ecological influence.

However, over the course of the three months of operation, it was observed that while Sei’s parallel transactions increase TPS and provide fast finality, the trade-off is an increase in state data volume, leading to higher hardware requirements for nodes. The team made a compromise by separating the ledger structure, sacrificing some decentralization for efficiency.

Overall, compared to other Ethereum killers, if the aforementioned updates can be effectively implemented, Sei has the opportunity to enter the top-tier competition. Looking forward to seeing the results of the team’s updates next year.

(Note: This article doesn’t constitute any investment advice.)

Disclaimer：

1. This article is reprinted from [Cointime]. All copyrights belong to the original author [Vanguard 0]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.