Layer1 Introduction | A simple explanation to quickly understand the highlights of Sei Network v2

share
Layer1 Introduction | A simple explanation to quickly understand the highlights of Sei Network v2

Sei Network, a parallel processing public chain designed for trading, launched its token in August this year and initiated its mainnet. After causing a stir in the market, Jayendra Jog, the founder of Sei Labs, recently announced the upcoming release of Sei v2, which will integrate EVM, optimize parallel processing mechanisms, and ledger storage structure.

What is Sei Network?

Built for Trading

Sei Network is positioned to provide an efficient environment for trading virtual assets. In addition to common tokens, virtual assets include NFTs, social graphs, and game items. By offering a specialized trading infrastructure, Sei Network aims to create the best user experience.

Various types of virtual asset trading Source

Trading extends beyond cryptocurrencies, making virtual asset trading one of the most widespread demands in the online world. The team believes that the most successful Web3 applications involve trading attributes:

  • Indirect trading: Most on-chain users engage in virtual asset trading using platforms like Uniswap and OpenSea.
  • Direct trading: Projects directly involved in trading are often games or NFT projects, such as Axie Infinity or BAYC.

Therefore, the demand for trading is ever-present and is a crucial aspect of the future Web3. To achieve the optimal position for a trading network, an efficient environment is necessary, and Sei achieves this goal through its parallel processing design and consensus mechanism.

Sei's Parallel Processing Mechanism

Sei Network's mainnet has been online for over 3 months. According to official data displayed, the network currently averages 20,000 TPS and 390 milliseconds of finality confirmation, making it one of the most efficient networks in the industry, thanks to its innovative parallel processing mechanism.

When transactions on the Sei blockchain do not involve the same resource addresses, all transactions can be processed concurrently without the need to order them, thereby enhancing network operational efficiency.

Sei v2 Update Direction

When evaluating a blockchain project, there are three main focus points: ledger structure, consensus mechanism, and virtual machine. With Sei's unique parallel processing mechanism, it is clear to understand the differences in Sei v2's update content.

Main updates in Sei Network v2 Source

Founder Jayendra states that Sei v2 only adds new features and does not affect existing functionality, so users and developers do not need to take any additional actions for this update.

Sei v2's proposal mainly includes three updates:

  • Support for EVM
  • Optimization of parallel processing mechanism
  • Optimization of ledger storage structure

This update is expected to be completed in the first quarter of 2024.

Virtual Machine: EVM Support

Original Design: Sei v1 Uses CosmWasm Virtual Machine

Sei is built on the Cosmos SDK and utilizes the CosmWasm virtual machine component provided by the latter. CosmWasm is a virtual machine component designed for the Cosmos ecosystem, named after WebAssembly Wasm at its core. Blockchains built using the Cosmos SDK can incorporate CosmWasm into their chains without adjusting existing logic.

WebAssembly supports various common programming languages, including Rust, C, C++, allowing Rust developers to easily write smart contracts on CosmWasm. This makes Sei attractive to developers outside the circle.

Key Update: Sei v2 will integrate EVM

However, the Sei Labs team found a high level of developer engagement but lacked the Ethereum Virtual Machine (EVM) ecosystem. EVM is the virtual machine used by most existing industry applications and products. The absence of this ecosystem could hinder Sei's rapid development at the current stage, such as the inability for existing Ethereum projects to fork into the Sei ecosystem.

To address this, the team introduced a dedicated codebase, Core Sei Binary, which integrates EVM RPC and a Geth node interface, allowing seamless on-chain interaction of EVM transactions with the Sei network.

Geth was chosen for its relative stability. Jayendra Jog stated that currently, 80% of Ethereum nodes use Geth, which supports complete EVM bytecode compatibility. This means developers can fully replicate other EVM contracts to run on Sei.

Main updates in Sei Network v2 Source

Sei v2 will also use EVM RPC, allowing users to easily operate with wallets like Metamask, while developers can continue to use tools like Foundry, Remix, and Hardhat.

Therefore, Sei v2 will enable composability between EVM and Cosmwasm transactions. Sei's Geth has a pre-compiler that allows calling Cosmwasm contracts, and Sei's wasmd module can also invoke EVM contracts in return, making assets within Sei's ecosystem more valuable.

Optimizing Sei's Parallel Processing Mechanism

Original Design: Sei v1 Contracts Require Resource Scope Definition

In the original Sei Network design, developers had to learn how to "tag contract resource usage" for transactions to be processed in parallel.

When writing contracts on Sei, developers needed to define the resources a contract might access and its independence. This allowed Sei to quickly differentiate resource independence during contract execution, determining whether transactions could be processed concurrently or needed to be ordered.

To execute contracts in parallel, developers had to identify resources that would be accessed during execution, including querying contracts, and write the resource scope in JSON format for on-chain storage. This inadvertently caused confusion for developers, increasing the entry barrier and security issues.

Key Update: Sei v2 Simplifies Contract Parallel Processing Mechanism

Sei v2 will optimize the parallel processing mechanism, eliminating the need for developers to manually define dependency relationships. The new parallel processing mechanism will handle parallelization automatically, reducing the burden on developers.

All transactions will be uniformly executed through the new parallel processing mechanism. In cases of resource conflicts, the network will review the order and re-execute transactions as necessary.

Automated resolution of resource overlap in Sei v2 Source

If transactions involve different accounts, such as Alice transferring to Bob and Carol transferring to Dave simultaneously, without overlapping dependency relationships, these transactions will be processed in parallel. However, if transactions involve the same accounts, such as both Alice and Bob transferring to Carol, they would need to be rerun sequentially.

However, in the worst-case scenario where all transactions are interrelated and require sequential reruns, this may increase execution time by 30% compared to the original sequential processing scenario.

Fortunately, based on historical data from Ethereum, only about 15% of transactions are expected to have resource overlap and require sequential reprocessing. Therefore, the team believes that Sei's overall performance will still significantly improve.

Optimizing Ledger Storage Structure: SeiDB

Original Design: Sei v1 Stores Large State Data

However, Sei faces another challenge of permanently storing the entire IAVL tree in the decentralized ledger. Due to fast finality and parallel processing design, frequent recording of global state changes is required, leading to rapid growth in overall network ledger size.

The cost of parallel processing is recording many invalid intermediate state data. According to an RFC proposed by the Sei team, an example from the atlantic-2 testnet node shows that out of 25 GB of data stored, only 10 GB contains meaningful transaction information, resulting in low disk space utilization efficiency.

As a result of data expansion, Sei node disk usage grows rapidly. The archiving node's hard disk usage increases by over 150 GB per day and over 1TB per week in the atlantic-2 testnet. As the chain state continues to grow, the storage growth rate will increase rapidly.

This will lead to several issues:

  • Increasing maintenance costs for nodes
  • Slower database operations
  • RPC nodes cannot run for extended periods due to quickly filling disks

With the future v2 design processing revalidation, the network's overall state changes will occur more frequently, significantly increasing state data volume.

Key Update: Sei v2 Separates Ledger Structure

To address these challenges, Sei v2 has optimized its storage mechanism to prevent state data expansion and enhance data retrieval speed for all nodes.

Sei v2 splits the state storage ledger into two components known as SeiDB:

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

With the improvements from SeiDB, verifying nodes only need to record SC ledger information, while SS layer records the complete state information. Transmissions are first placed in a write-ahead log without the need for immediate transmission, allowing asynchronous state storage to improve efficiency without affecting block generation.

Reducing the burden of validating node data growth in Sei v2 Source

Through SeiDB enhancements, Sei's performance has seen improvements across the board. This includes a 100x increase in block submission time, compressing daily data generation from 100 GB to 5 GB, and a 10x improvement in catch-up time for all nodes or nodes requiring synchronized information.

Consensus Mechanism

Sei Network v2 has not changed its original consensus mechanism and still maintains the Twin Turbo design. By improving Cosmos' consensus interface Tendermint ABCI, block confirmation time has been significantly reduced.

Sei Enters the Frontline Competition with Trade-offs

Sei v2 has added an EVM virtual machine, improved parallel processing mechanisms, and decentralized ledger storage mechanisms to enhance the experience for developers, nodes, and users, thereby increasing ecosystem influence.

However, through three months of operation, Sei has found that while parallel transactions increase TPS and fast finality, the cost is an increase in state data volume, requiring nodes to have higher hardware specifications. The team made a compromise by separating the ledger structure, sacrificing decentralization to improve efficiency.

Overall, if the above updates can be effectively implemented, Sei has the potential to enter the frontline competition with other Ethereum killers, anticipating the results of the team's updates next year.

This article does not constitute investment advice.