Author: Pavel Paramonov, Founder of Hazeflow; Compiled by: Felix, PANews
Sei released a new white paper introducing the latest Giga upgrade. Most readers found the 17-page in-depth technical content difficult to read. Therefore, this article will explain the content of this update and how to improve blockchain performance at different levels.
1. About 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 depends only on the initial state and transaction order. This means consensus only needs to agree on the order of transactions within a block, and each node can independently calculate the final state.
- In this model, consensus is separated from execution, allowing blocks to be executed asynchronously.
- Once a block is finalized, nodes will process it and submit its state in subsequent blocks.
- The block is then verified through state consensus to ensure all nodes have calculated the correct final state.
An important detail here is that execution and consensus (generation) are carried out in parallel. Nodes receive other blocks while computing the execution of a block.
Therefore, blocks are actually executed in total order (not in parallel), while the block generation process itself does indeed occur in parallel with consensus. However, for any given block, these processes are completely asynchronous.
Obviously, it seems impossible to reach consensus and execute the same block simultaneously. Therefore, while executing block n, nodes will receive block n+1 for the next step.
If consensus deviates (for example, if one-third of the nodes act maliciously), the chain will pause, similar to standard BFT protocols.
Failed transactions within a block will not invalidate that block, they will simply remain in a failed state, because block generation and execution are separate, and the current block's final state will be committed in subsequent blocks.
2. How the Multi-Proposer Model is Implemented and What is Autobahn?
The consensus protocol itself is called "Autobahn" (like the unrestricted German highway). Autobahn separates data availability and transaction ordering, with an interesting model behind it.
Like lanes on any highway, there are multiple lanes, with each node having its own channel. Nodes use these channels to propose transaction ordering. Proposals are simply ordered collections of transactions.
Autobahn sometimes performs a "tipcut" operation, which aggregates multiple proposals to finalize transaction order.
- As previously mentioned, each validator has its own channel to propose transaction batches.
- When a node receives a valid proposal, it sends a vote to confirm receipt of the proposal.
- After collecting votes, the proposal forms a Proof of Availability (PoA), ensuring the data has been received by at least one honest node in the network.
- Tipcut occurs in milliseconds, and multiple proposals from Autobahn will be "cut".
Proposers are incentivized to wait to publish blocks and publish single blocks where possible, but block execution time limits (similar to gas limits) will slightly alter this dynamic.
A proposal on one channel is typically equivalent to a block, meaning when Tipcut occurs, multiple blocks will be cut simultaneously.
Afterward, the slot leader will send the Tipcut to other nodes to complete ordering. Nodes are actually preparing the next Tipcut while voting on a single Tipcut.
Nodes that miss batches can asynchronously retrieve from validators listed in the PoA: this is the essential reason for data availability.
Under synchronization conditions, Autobahn completes proposal confirmation in two communication rounds if the leader is correct. If the leader fails, the mechanism will elect a new leader to maintain progress.
The next tip-cut proposal can actually begin during the commit phase of the current tip-cut, thereby reducing latency because execution and generation occur in parallel.
In fact, the entire model is a multi-proposer model where many nodes can simultaneously propose ordering for their blocks. Each validator proposes its own block and receives a proof of network possession of these blocks (PoA), which helps improve network throughput and overall efficiency.
3. Parallel Execution and Its Applicability
As mentioned earlier, the block execution process occurs in parallel with consensus, although blocks are actually executed sequentially. You might wonder if this constitutes true parallel execution.
The answer is both yes and no.
While blocks are executed sequentially, transactions within a block can indeed be executed in parallel. If transactions do not modify (write to) the same state, and one transaction's result does not affect another, they can be executed in parallel.
In short, their execution paths should not be interdependent. Giga has no memory pool, and transactions are immediately included by nodes.
- Giga assumes most transactions do not conflict and processes these transactions on multiple processor cores simultaneously.
- Changes for each transaction are temporarily stored in a private buffer and not immediately applied to the blockchain.
- After processing, the system checks whether the transaction conflicts with previous transactions.
- If a conflict exists, the transaction will be reprocessed. If no conflict exists, its changes will be applied to the blockchain and finalized.
High-frequency conflict scenarios are possible, in which case the system will switch to processing one transaction at a time to ensure transaction progression.
Simply put, parallel execution distributes transactions across multiple cores, allowing transactions without conflicts to run simultaneously.
4. Storage Issues and Optimization
Due to high transaction volumes, data needs to be both secure and accessible, so its storage method should differ slightly from traditional blockchain storage. Giga stores data in a simple key-value format, a relatively flat structure that helps reduce multiple updates or checks required when data changes.
Additionally, Giga adopts a hierarchical storage approach: recent data is retained on SSDs (high-speed), while less-used data is migrated to slower, more cost-effective storage systems.
If a node crashes, it can replay logs to recover the correct state and apply updates to RocksDB (a specialized database) to organize data.
The storage system uses a Cryptographic Accumulator that can prove data correctness without heavy computation. The accumulator is updated in batches, enabling validators and light nodes to quickly reach consensus on the blockchain's current state.
5. What Does Becoming a Multi-Proposer EVM L1 Blockchain Mean?
L1 infrastructure can undergo various improvements, with different L1s facing various technical challenges, from economic issues like MEV to technical aspects such as state management.
Being the first L1 chain supporting multi-proposers is challenging, especially for EVM L1, as EVM was not originally designed to support multi-proposer systems.
However, Sei is attempting different approaches to preserve EVM and tools many developers are accustomed to using.
Parallel transaction execution, reaching consensus during execution, and multiple proposers operating in parallel all contribute to performance improvement, with execution throughput potentially increasing by about 50 times. However, these improvements may also face some of the risks mentioned above.
This is Sei's second major update, previously transitioning from a Cosmos chain to an EVM chain, and now Sei has launched an execution client optimized for speed.
The subsequent development and follow-up effects of these optimization measures are worth watching.
