Interpreting Sei's New White Paper: What Technological Innovations Does the Giga Upgrade Introduce?

Author: Pavel Paramonov, Founder of Hazeflow

Compiled by: Felix, PANews

Sei has released a new white paper that introduces the latest Giga upgrade. Most readers find the 17 pages of 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 Execution of 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 the order of transactions. This means that consensus only needs to be reached 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 status in subsequent blocks.
• Then verify the block through state consensus to ensure that all nodes have computed 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 one block, it will also receive other blocks.

Therefore, blocks are executed in total order (rather than in parallel), and the block generation process does indeed occur in parallel with consensus. However, for any given block, these processes are completely asynchronous.

It is clear that it seems impossible to reach consensus and execute on the same block simultaneously. Therefore, when executing block n, the nodes will receive block n+1 for the next step.

If there is a deviation in consensus (for example, if one-third of the nodes in the network 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 maintain a failed status, as block generation and execution are separate, and the final state of the current block will be submitted in subsequent blocks.

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

The consensus protocol itself is called "Autobahn" (just like the unlimited-speed German highway). Autobahn separates data availability from transaction ordering, backed by an interesting model.

Just like any lane on a highway, there are multiple lanes, and each node has its own channel. Nodes use these channels to propose transaction ordering. A proposal is simply an ordered collection of transactions.

Autobahn sometimes performs a "tipcut" operation, which aggregates 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.
• After the proposal is collected and voted on, a Proof of Availability (PoA) will be generated to ensure 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 the final proposals from Autobahn will be "cut.".

Proposers are incentivized to wait for the block to be published and, if possible, to publish a single block, but the execution time limit for each block (similar to a Gas limit) slightly alters this dynamic.

A proposal on a channel usually corresponds to a block, which means that when a Tipcut occurs, multiple blocks can be cut off simultaneously.

After that, the leader of the slot will send the Tipcut to other nodes to complete the sorting. The nodes are actually preparing the next Tipcut while voting on a single Tipcut.

Nodes that miss a batch can asynchronously obtain data from the validators listed in the PoA: this is the fundamental reason for 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 start during the current tip-cut submission phase, thereby reducing latency, as execution proceeds in parallel with generation.

In fact, the entire model is a multi-proposer model, where many nodes can propose blocks for ordering simultaneously. Each validator proposes its own block and receives proof of ownership (PoA) for those blocks from the network, which helps improve the network's throughput and overall efficiency.

3. Parallel Execution and Its Applications

As previously mentioned, the block execution process and consensus occur in parallel, 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.

Although blocks are executed in order, 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 transaction, then they can be executed in parallel.

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

• Giga assumes that there are no conflicts between most transactions and processes these transactions simultaneously across 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 will check if this 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 of high-frequency conflicts, in which case the system will switch to processing one transaction at a time to ensure that transactions can proceed.

In simple terms, parallel execution allocates transactions to multiple cores, allowing those transactions that do not conflict to run simultaneously.

4. Storage Issues and Optimization

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

In addition, Giga also 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 recover the correct state and apply updates to RocksDB (a specialized database) to organize the data.

The storage system uses a Cryptographic Accumulator to prove the correctness of the data without the need for heavy calculations. The accumulator is updated in batches, allowing validators and light nodes to quickly agree on the current state of the blockchain.

5. What does becoming a multi-proposer EVM L1 blockchain mean?

L1 infrastructure can undergo various improvements, and different L1s face a range of technical challenges, from economic issues like MEV to technical issues such as state management.

As the first L1 chain to support multiple proposers, it is quite challenging, especially for EVM L1, because the original design of EVM was not intended to support a multiple proposer system.

However, Sei is trying different methods to retain the EVM and many tools that developers are accustomed to using.

Parallel transaction execution, reaching consensus during execution, and multiple proposers operating in parallel all contribute to improved performance, with execution throughput potentially increasing by approximately 50 times. However, these improvements may also face some of the risks mentioned above.

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

The subsequent development and the follow-up effects of these optimization measures are worth paying attention to.

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