Sei has released a new whitepaper detailing its latest Giga upgrade. Most readers find the 17-page deep dive into technical content challenging to digest. This article breaks down the updates and explains how they enhance blockchain performance across different layers.
1. Block Production with Asynchronous Execution
The core concept and foundation of Giga are as follows:
“If we have an ordered list of transactions and a consistent initial state of the blockchain, and all honest nodes process these transactions in the same order, the nodes will arrive at the same final state.”
In this scenario, the outcome depends solely on the initial state and the order of transactions. This means consensus only needs to agree on the sequence of transactions within a block, and each node can independently compute the final state.
In this model, consensus is decoupled from execution, enabling asynchronous block processing.
Once a block is finalized, nodes process it and submit its state in subsequent blocks.
The block is then validated through state consensus to ensure all nodes have computed the correct final state.
A key detail here is that execution occurs in parallel with consensus (block production). While computing one block, nodes simultaneously receive others.
Thus, blocks are executed in a total order (not in parallel), but block production itself happens concurrently with consensus. For any given block, these processes are entirely asynchronous.
Naturally, performing consensus and execution on the same block simultaneously seems impossible. Therefore, while executing block n, nodes receive block n+1 for the next step.
If consensus deviates (e.g., due to malicious behavior by a third of the nodes), the chain halts—similar to standard BFT protocols.
Failed transactions within a block do not invalidate it; they remain in a failed state. Since block production and execution are separate, 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 (akin to Germany’s speed-limit-free highways). Autobahn separates data availability from transaction ordering, employing an intriguing model.
Like lanes on a highway, multiple channels exist, with each node having its own. Nodes use these channels to propose transaction ordering. A proposal is simply an ordered set of transactions.
Autobahn periodically performs a tipcut operation, aggregating multiple proposals to finalize the transaction order.
Each validator has its own channel to propose transaction batches.
When a node receives a valid proposal, it sends a vote to acknowledge receipt.
Once a proposal collects enough votes, it forms a Proof of Availability (PoA), ensuring at least one honest node in the network has received the data.
Tipcuts occur in milliseconds, and multiple proposals from Autobahn are "cut."
Proposers are incentivized to wait and publish a single block if possible, but execution time limits (similar to gas limits) slightly alter this dynamic.
A proposal on one channel typically equates to one block, meaning multiple blocks are cut simultaneously during a tipcut.
Afterward, the slot leader shares the tipcut with other nodes to finalize the order. While voting on one tipcut, nodes are already preparing the next.
Nodes that miss batches can asynchronously fetch them from validators listed in the PoA—this is the essence of data availability requirements.
Under synchronous conditions, Autobahn confirms proposals in two communication rounds if the leader is honest. If the leader fails, the mechanism elects a new one to maintain progress.
The next tipcut proposal can begin during the commit phase of the current one, reducing latency since execution runs parallel to production.
In practice, this is a multi-proposer model where many nodes can simultaneously propose block ordering. Each validator proposes its own block and receives PoA confirmation, boosting network throughput and efficiency.
3. Parallel Execution and Its Applications
As mentioned earlier, block execution occurs in parallel with consensus, though blocks themselves are executed sequentially. You might wonder whether this qualifies as true parallel execution.
The answer is both yes and no.
While blocks are executed in order, transactions within a block can be processed in parallel—provided they don’t modify (write to) the same state or depend on each other’s outcomes.
In short, their execution paths must not interfere. Giga lacks a mempool; transactions are immediately included by nodes.
Giga assumes most transactions are conflict-free and processes them simultaneously across multiple CPU cores.
Changes from each transaction are temporarily stored in a private buffer, not immediately applied to the blockchain.
After processing, the system checks for conflicts with prior transactions.
If a conflict exists, the transaction is reprocessed. If not, its changes are finalized on the blockchain.
In high-conflict scenarios, the system switches to sequential processing to ensure progress.
In essence, parallel execution distributes transactions across cores, allowing non-conflicting ones to run concurrently.
4. Storage Challenges and Optimizations
With high transaction volumes, data must be secure yet accessible. Giga’s storage differs from traditional blockchain storage:
Data is stored in a flat key-value format, reducing updates/checks during modifications.
Hierarchical storage is used: recent data stays on SSDs (fast), while less-used data migrates to slower, cost-effective systems.
If a node crashes, it replays logs to restore the correct state and applies updates to RocksDB (a specialized database) for organization.
The storage system employs a cryptographic accumulator to prove data correctness without heavy computation. The accumulator updates in batches, enabling validators and light nodes to quickly agree on the blockchain’s current state.
5. What Does It Mean to Be a Multi-Proposer EVM L1 Blockchain?
L1 infrastructure can undergo various improvements, but different L1s face distinct challenges—from economic issues like MEV to technical hurdles like state management.
Being the first multi-proposer L1 is ambitious, especially for an EVM chain, as the EVM wasn’t originally designed for such a system.
Yet, Sei is exploring ways to retain EVM compatibility and developer-friendly tools.
Parallel execution, consensus-during-execution, and multi-proposer operations can boost performance by ~50x, though risks remain.
This is Sei’s second major update, following its transition from a Cosmos chain to an EVM chain. Now, it introduces a speed-optimized execution client.
The next steps—and the real-world impact of these optimizations—are worth watching.
