Interpretation of Sei’s new white paper: What technological innovations are introduced in the Giga upgrade?

Author: Pavel Paramonov , Founder of Hazeflow

Compiled by: Felix, PANews

Sei has released a new whitepaper that describes the latest Giga upgrade. Most readers find the 17 pages of in-depth technical content difficult to read. Therefore, this article will explain what this update is about and how it will improve blockchain performance at different levels.

1. About asynchronous block generation

The main ideas and foundations of Giga are as follows:

“If our list of transactions is in order and the initial state of the blockchain is consistent, and all honest nodes process these transactions in the same order, then they will reach the same final state.”

In this case, the result depends only on the initial state and the order of transactions. This means that 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 process it and commit its state in a subsequent block.
• The block is then validated through state consensus to ensure that all nodes have calculated the correct final state.

An important detail here is that execution and consensus (generation) are done in parallel. While a node is performing computations on one block, it is also receiving other blocks.

Thus, blocks are actually executed in total order (not in parallel), and the block generation process itself does happen 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 at the same time. Therefore, when executing block n, the node will receive block n+1 to proceed to the next step.

If the consensus becomes skewed (e.g. one-third of the nodes in the network act maliciously), the chain will halt, similar to a standard BFT protocol.

Transactions that fail to execute within a block do not invalidate the block, but simply remain in a failed state, because block generation and execution are separate, and the final state of the current block is committed in subsequent blocks.

2. How is the multi-proposer model implemented and what is Autobahn ?

The consensus protocol itself is called “Autobahn” (like the German Autobahn with no speed limit). Autobahn decouples data availability from transaction ordering, and has an interesting model behind it.

Just like any lane on a highway, there are multiple lanes and each node has its own lane. Nodes use these lanes to make proposals about the ordering of transactions. A proposal is just an ordered collection of transactions.

Autobahn sometimes performs a "tipcut" operation, which aggregates multiple proposals to finalize the order of transactions.

• As mentioned before, each validator has his 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.
• After a proposal collects votes, a proof of availability (PoA) is formed to ensure that the data has been received by at least one honest node in the network.
• Tipcuts occur in milliseconds, and eventually multiple proposals from Autobahn will be "cut."

Proposers have an incentive to wait to publish blocks and publish a single block when possible, but the execution time limit for each block (similar to the gas limit) changes this dynamic slightly.

A proposal on a channel is usually equivalent to one block, which means that when a tipcut occurs, multiple blocks will be cut off at the same time.

After that, the leader of the slot sends the Tipcut to other nodes to complete the sorting. In fact, when a node votes on a single Tipcut, it is already preparing for the next Tipcut.

Nodes that missed batches can obtain them asynchronously from the validators listed in the PoA: this is the essence of why data availability is needed.

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 progress.

The next tip-cut proposal can actually start during the commit phase of the current tip-cut, thus reducing latency since execution happens in parallel with generation.

In fact, the entire model is a multi-proposer model, where many nodes can make proposals for their block ordering at the same time. Each validator proposes its own blocks and receives proof (PoA) that the network owns these blocks, which helps improve the throughput and overall efficiency of the network.

3. Parallel execution and its applicability

As mentioned before, the block execution process and consensus happen in parallel, even though the blocks themselves are actually executed sequentially. You might be wondering if this constitutes true parallel execution.

The answer is both yes and no.

Although blocks are executed sequentially, transactions within a block can indeed be executed in parallel if the transactions do not modify (write to) the same state and the result of one transaction does not affect another transaction.

In short, their execution paths should not depend on each other. Giga has no memory pool and transactions are included by nodes immediately.

• Giga assumes that there are no conflicts between most transactions and processes them simultaneously on multiple processor cores.
• Changes to 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 situations where there are high-frequency conflicts, in which case the system switches to processing transactions one at a time to ensure that transactions can move forward.

Simply put, parallel execution distributes transactions across multiple cores, allowing transactions that do not conflict to run simultaneously.

4. Storage issues and optimization

Due to the large volume of transactions, data needs to be both secure and easily accessible, so its storage method should be slightly different from traditional blockchain storage. Giga stores data in a simple key-value format, a relatively flat structure that helps reduce the multiple updates or checks required when data changes.

In addition, Giga uses a tiered storage approach: recent data is kept on SSDs (high speed), while less frequently used data is moved to slower, more cost-effective storage systems.

If a node crashes, it can replay the log to restore the correct state and apply updates to RocksDB, a specialized database, to organize the data.

The storage system uses a cryptographic accumulator that can prove the correctness of data without heavy calculations. The accumulator is updated in batches, allowing validators and light nodes to quickly reach a consensus on the current state of the blockchain.

5. What does it mean to be a multi-proposer EVM L1 blockchain?

There are many improvements that can be made to L1 infrastructure, and different L1s face various technical challenges, ranging from economic issues such as MEV to technical issues such as state management.

Being the first L1 chain to support multiple proposers is challenging, especially for EVM L1, as the EVM was not originally designed to support a multi-proposer system.

However, Sei is trying a different approach to preserve the EVM and the tools that many developers are accustomed to using.

Parallel transaction execution, consensus during execution, and multiple proposers operating in parallel can help improve performance, with execution throughput increasing by about 50 times. However, these improvements may also face some of the risks mentioned above.

This is the second major update of Sei. Previously, Sei transformed from the Cosmos chain to the EVM chain. Now Sei has launched an execution client optimized for speed.

It will be interesting to see what happens next and how these optimization measures pan out.

Related reading: Exploring the performance, compliance and interoperability of blockchain Sei