Author: Pavel Paramonov, Founder of Hazeflow
Compiled by: Felix, PANews
Sei has released a new white paper that outlines the latest Giga upgrade. Most readers find the 17 pages of in-depth technical content difficult to read. Therefore, this article will explain the contents of this update and how to enhance blockchain performance at different levels.
1. About Asynchronous Execution of Block Generation
The main ideas and foundations of Giga are as follows:
"If our list of transactions 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 outcome depends solely on the initial state and the order of transactions. This means that consensus only needs to agree on the order of transactions within the block, and each node can independently compute 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 that all nodes have calculated the correct final state.
An important detail here is that execution and consensus (generation) occur in parallel. While a node is executing the computation of a block, it also receives other blocks.
Therefore, blocks are actually executed in total order (rather than in parallel), while the block generation process itself occurs in parallel with consensus. However, for any given block, these processes are completely asynchronous.
Clearly, it seems impossible to simultaneously achieve consensus and execution on the same block. Therefore, when executing block n, nodes will receive block n+1 for the next step.
If there is a consensus deviation (for example, if one-third of the nodes behave maliciously), the chain will pause, similar to standard BFT protocols.
Transactions that fail during execution within a block do not invalidate the block; they simply remain in a failed state, as block generation and execution are separate, and the final state of the current block will be submitted in subsequent blocks.
2. How the Multi-Proposer Model is Achieved and What Autobahn Is?
The consensus protocol itself is called 'Autobahn' (just like the unlimited-speed German highway). Autobahn separates data availability from transaction ordering, supported by an interesting model.
Just like the lanes on any highway, there are multiple lanes, with each node having its own channel. Nodes use these channels to propose transaction ordering. A proposal is simply an ordered set of transactions.
Autobahn sometimes performs 'tipcut' operations, aggregating multiple proposals to finalize the order of transactions.
As mentioned earlier, each validator has its own channel to propose batches of transactions.
When a node receives a valid proposal, it sends a vote to confirm that the proposal has been received.
Once the proposal collects votes, a Proof of Availability (PoA) is formed, ensuring that the data has been received by at least one honest node in the network.
The occurrence time of Tipcut is measured in milliseconds, and multiple proposals from Autobahn will eventually be 'cut.'
Proposers are incentivized to wait for block publication and publish a single block when possible, but the execution time limit for each block (similar to Gas limits) slightly alters this dynamic.
A proposal on one channel typically corresponds to one block, which means that when Tipcut occurs, multiple blocks can be cut simultaneously.
After this, the leader of the slot sends the Tipcut to other nodes to complete the ordering. Nodes are effectively preparing the next Tipcut while voting on a single Tipcut.
Nodes that miss a batch can asynchronously fetch from the validators listed in the PoA: this is the essence of the need for data availability.
Under synchronous conditions, if the leader is correct, Autobahn will complete proposal confirmation in two rounds of communication. If the leader fails, the mechanism will elect a new leader to maintain progress.
The next tip-cut proposal can actually begin during the submission phase of the current tip-cut, reducing latency since 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 proof of ownership (PoA) of those blocks from the network, which helps to improve the throughput and overall efficiency of the network.
3. Parallel Execution and Its Applicable Situations
As previously mentioned, the block execution process occurs in parallel with consensus, although 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 sequentially, transactions within a block can indeed be executed in parallel. If transactions do not modify (write to) the same state and the outcome of one transaction does not affect another, they can be executed in parallel.
In short, their execution paths should not depend on each other. Giga does not have a memory pool; transactions are immediately included by nodes.
Giga assumes that there are no conflicts between most transactions and processes these transactions simultaneously across multiple processor cores.
Changes for each transaction are temporarily stored in a private buffer and are not immediately applied to the blockchain.
After processing is complete, the system checks whether the transaction conflicts with previous transactions.
If there is a conflict, the transaction will be reprocessed. If there is no conflict, its changes will be applied to the blockchain and finalized.
There may also be scenarios with high-frequency conflicts, in which case the system switches to processing one transaction at a time to ensure progress.
Simply put, parallel execution allocates transactions across multiple cores, allowing those without conflicts to run simultaneously.
4. Storage Issues and Optimization
Due to the high transaction volume, data needs to be both secure and easily accessible, so its storage should differ slightly from traditional blockchain storage. Giga stores data in a simple key-value format, a relatively flat structure that helps reduce the number of updates or checks required when data changes.
Additionally, Giga adopts a hierarchical 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 the logs to restore the correct state and apply the updates to RocksDB (a dedicated database) to organize the data.
The storage system employs a Cryptographic Accumulator, which can prove the correctness of the data without heavy computation. The accumulator updates in a batch manner, allowing validators and light nodes to quickly reach consensus on the current state of the blockchain.
5. What Does It Mean to Be a Multi-Proposer EVM L1 Blockchain?
L1 infrastructure can undergo various improvements, and different L1s face various technical challenges, from economic issues such as MEV to technical issues like state management.
Being the first L1 chain to support multiple proposers is quite challenging, especially for EVM L1, as EVM was not originally designed to support multi-proposer systems.
However, Sei is attempting different approaches to retain EVM and many tools that developers are accustomed to.
Parallel transaction execution, consensus during execution, and multiple proposers operating in parallel all contribute to performance improvements, 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, following its transformation from a Cosmos chain to an EVM chain, and now Sei has launched an execution client optimized for speed.
The upcoming developments and the subsequent effects of these optimizations are worth paying attention to.
Related Reading: Exploring the Performance, Compliance, and Interoperability of Blockchain Sei
