Sei Releases New Whitepaper Describing the Latest Giga Upgrade

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.

The latest Giga upgrade from Sei is a significant step in advancing the capabilities of blockchain technology. This article, compiled by Felix, from PANews, provides a clear and concise summary of the main points discussed in Pavel Paramonov's, Founder of Hazeflow, article on the topic.

The article highlights how Giga introduces asynchronous block generation, a multi-proposer model with Autobahn, and parallel execution to enhance performance at different levels.

At the heart of Giga lies an interesting take on an idea. Usually, people think about a list of transactions. If we know the initial state of the chain and the transactions are applied in the same order by all honest nodes, they will come to the same final state.

In this case, the result depends only on the initial state and the order of transactions. This means that we only need to agree on the order of transactions in a block. Each node can independently compute the final state.

Now, an important detail 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, we can say that blocks are actually executed in total order (not in parallel) and the block generation process itself does happen in "parallel" with consensus. But for any given block, these processes are completely asynchronous.

Obviously, it seems impossible to perform 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. 1/3 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 generation and execution are separate, and the final state of the current block is committed in subsequent blocks.

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

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.

Parallel Execution And Its Applicability

As mentioned, 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 one after the other, transactions within a block can 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.

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.

To put it simply, parallel execution distributes transactions across multiple cores, allowing transactions that do not interfere with each other to run simultaneously.

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