Sei Introduces Key Mechanisms in Giga Upgrade: Asynchronous Execution, Multi-Proposer Consensus, Transaction Parallel Processing, and Storage Optimization
This article is derived from the work of Pavel Paramonov, founder of Hazeflow, and was organized, compiled, and written by Felix, PANews.
(Background: $SEI Soars 70% in a Single Month! Launches SIP-3 Proposal: Transforms into Pure EVM, Targeting 100,000 Transactions per Second)
(Further Context: MetaMask to Support Solana Network in May, Marking Its First Step Beyond EVM Chains—Little Fox Wallet Ventures Out of Ethereum’s Comfort Zone)
Sei Releases New Whitepaper Introducing Giga Upgrade
Sei has released a new whitepaper detailing the latest Giga upgrade. Many readers find the 17-page deep technical content challenging to read. Therefore, this article explains the update and how it enhances blockchain performance at different levels.
1. Asynchronous Block Generation
The main idea and foundation of Giga are as follows:
“If our transaction list is ordered, and the initial state of the blockchain is consistent, and all honest nodes process these transactions in the same order, then the nodes will reach the same final state.”
In this case, the result only depends on the initial state and transaction order. This means consensus only needs to agree on the order of transactions within the block, and each node can independently calculate the final state.
In this model, separating consensus from execution allows blocks to be executed asynchronously. Once the block is finalized, nodes process it and submit its state in subsequent blocks. Then, the state consensus verifies the block to ensure all nodes have computed the correct final state.
One important detail here is that execution and consensus (generation) occur concurrently. While a node executes a block’s calculations, it also receives other blocks. Thus, blocks are effectively executed in total order (not concurrently), but the block generation process itself occurs concurrently with consensus. However, for any given block, these processes are entirely asynchronous.
Clearly, it seems impossible to simultaneously achieve consensus and execution for the same block. Therefore, when executing block n, nodes will receive block n+1 to proceed to the next step.
If consensus diverges (for example, if a third of the nodes act maliciously), the chain will pause, similar to standard BFT protocols. Transactions within a block that fail execution will not invalidate the block but will remain in a failed state, as block generation and execution are separate, and the final state of the current block is submitted in subsequent blocks.
2. How the Multi-Proposer Model Works and What is Autobahn?
The consensus protocol itself is called “Autobahn” (similar to Germany’s unrestricted highways). Autobahn separates data availability and transaction ordering, backed by an interesting model.
Like any highway with multiple lanes, there are several lanes, and each node has its own channel. Nodes use these channels to propose transaction orderings. A proposal is simply an ordered set of transactions.
Autobahn sometimes performs a “tipcut” operation, aggregating multiple proposals to finalize the transaction order.
As mentioned earlier, each validator has its own channel to propose transaction batches. When a node receives a valid proposal, it sends a vote to confirm the proposal has been received.
Once a proposal collects votes, it forms a Proof of Availability (PoA), ensuring that data has been received by at least one honest node in the network.
Tipcut occurs in milliseconds, and multiple proposals from Autobahn will eventually be “cut.”
Proposers are motivated to wait for a block to be published and, where possible, release a single block. However, the execution time limit for each block (similar to a gas limit) slightly changes this dynamic.
A proposal in a single channel typically corresponds to one block, meaning that when Tipcut occurs, multiple blocks are simultaneously cut.
Afterwards, the slot leader sends the Tipcut to other nodes to complete the ordering. Nodes actually begin preparing for the next Tipcut while voting on a single Tipcut.
Nodes that miss a batch can asynchronously fetch from the PoA listed validators: this is the essential reason for data availability.
Under synchronous conditions, if the leader is correct, Autobahn completes the proposal confirmation in two rounds of communication. If the leader fails, the mechanism elects a new leader to maintain the program.
The next tip-cut proposal can actually start during the current tip-cut submission phase, reducing latency, as execution and generation run concurrently.
In essence, the whole model is a multi-proposer model, where many nodes can simultaneously propose the ordering of their blocks. Each validator proposes its own block and receives a PoA from the network that owns those blocks, helping increase the network’s throughput and overall efficiency.
3. Parallel Execution and Its Applicability
As previously mentioned, the block execution process occurs concurrently with consensus, even though the blocks themselves are actually executed in order. You might wonder if this constitutes true parallel execution.
The answer is both yes and no.
While blocks are executed in order, the transactions within a block can indeed be executed in parallel. If transactions do not modify (write to) the same state, and the result of one transaction does not affect another, they can be executed in parallel.
In short, their execution paths should not depend on one another. Giga does not have a memory pool, and transactions are immediately included by nodes.
Giga assumes that most transactions do not conflict with each other and processes them simultaneously on multiple processor cores.
Each transaction’s changes are temporarily stored in a private buffer and are not immediately applied to the blockchain. After processing, the system checks if the transaction conflicts with previous transactions.
If there’s a conflict, the transaction is reprocessed. If there is no conflict, its changes are applied to the blockchain and finalized.
There may also be cases of high-frequency conflicts, in which case the system switches to one-transaction-at-a-time processing to ensure progress.
Simply put, parallel execution allocates transactions to multiple cores, allowing those without conflicts to execute simultaneously.
4. Storage Issues and Optimization
Given the high volume of transactions, data needs to be both secure and accessible, so its storage should differ from traditional blockchain storage. Giga stores data in a simple key-value format, a relatively flat structure that helps reduce the need for multiple updates or checks when data changes.
Additionally, Giga adopts a layered storage approach: recent data is kept on SSDs (high-speed), while less frequently used data is migrated to slower, more cost-effective storage systems.
If a node crashes, it can replay logs to restore the correct state and apply updates to RocksDB (a specialized database) to organize the data.
The storage system employs a cryptographic accumulator, which proves the correctness of data without requiring heavy computation. The accumulator updates in batches, enabling validators and light nodes to quickly reach consensus on the blockchain’s current state.
5. What Does Being a Multi-Proposer EVM L1 Blockchain Mean?
L1 infrastructure can undergo various improvements, and different L1 chains face a variety of technical challenges, from economic issues like MEV to technical issues like state management.
As the first multi-proposer L1 chain, this is particularly challenging for EVM L1, as the EVM was not originally designed to support multi-proposer systems.
However, Sei is exploring different ways to retain EVM and many of the tools developers are accustomed to using. Parallel transaction execution, consensus during execution, and multi-proposers working concurrently all help improve performance, with execution throughput increasing by about 50 times. However, these improvements may face some of the risks mentioned earlier.
This is Sei’s second major update, following its transformation from a Cosmos chain to an EVM chain, and now Sei is launching an execution client optimized for speed.
Looking ahead, the further development and the subsequent effects of these optimizations are worth watching.
