Interpreting the Sei New White Paper: What technological innovations does the Giga upgrade introduce?

SEI introduces mechanisms including asynchronous execution, multi-proposer consensus, transaction parallelism, and storage optimization in the Giga upgrade. This article is written by Pavel Paramonov, founder of Hazeflow, and is compiled, compiled and contributed by Felix, PANews. (Synopsis: $SEI 70% in a single month!) Launch of SIP-3 proposal: transition to pure EVM, aiming for 100,000 transactions per second) (Background added: MetaMask will support the Solana network's "first non-EVM chain" MetaMask wallet out of Ethereum's comfort zone in May) Sei has released a new white paper that introduces the latest Giga upgrade. Most readers find 17 pages of in-depth technical content difficult to read. Therefore, this article will explain what this update is and how to improve blockchain performance at different levels. 1. The main ideas and foundations of block generation giga for asynchronous execution are as follows: "If our transaction list is in order and the initial state of the blockchain is consistent, and all honest nodes process these transactions in the same order, then nodes will reach the same end 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 the block, and each node can calculate the final state independently. In this model, consensus is separated from execution, allowing blocks to execute asynchronously. Once the block is finalized, the node processes it and commits its state in subsequent blocks. The block is then validated by state consensus to ensure that all nodes have computed the correct final state. An important detail here is that execution and consensus (generation) take place in parallel. When a node performs the computation of one block, it also receives other blocks. As a result, blocks are actually executed in total order (rather than in parallel), while the block generation process itself does occur in parallel with consensus. However, for any given block, these processes are completely asynchronous. Obviously, consensus and execution of the same block at the same time seems impossible. Therefore, when block n is executed, the node receives block n+1 for the next step. If consensus is skewed (e.g. a third of nodes in the network act maliciously), the chain is suspended, similar to the standard BFT protocol. Execution of a failed transaction within a block does not invalidate the block, but simply remains 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 separates data availability from transaction ordering, and there's an interesting model behind it. Just like the lanes of any highway, there are multiple lanes, each node with its own passage. Nodes use these channels to make proposals regarding the ordering of transactions. A proposal is just an ordered collection of transactions. Autobahn sometimes performs a "tipcut" operation, where multiple proposals are aggregated to finalize the order of transactions. As mentioned earlier, each validator has its own channel to propose a lot of transactions. When a node receives a valid proposal, it sends a vote to confirm that the proposal has been received. Once a proposal is collected for a vote, a Proof of Availability (PoA) is formed, ensuring 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 are "cut." Proposers have an incentive to wait for blocks to be released and release individual blocks where 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 a block, which means that when a tipcut occurs, multiple blocks are cut off at the same time. Thereafter, the leader of the slot passes the tipcut to other nodes to complete the sorting. The node is actually voting on a single tipcut at the same time that it is already preparing the next tipcut. Nodes that miss batches can be obtained asynchronously from validators listed in the PoA: this is the essence of the need for data availability. Under synchronous conditions, if the leader is correct, Autobahn completes the proposal confirmation in two rounds of communication. If a leader fails, the mechanism elects a new leader to keep the program in order. The next tip-cut proposal can actually start during the commit phase of the current tip-cut, reducing latency because execution happens in parallel with the build. 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 that the network owns those blocks (PoA), which helps improve the throughput and overall efficiency of the network. 3 Parallel execution and its application As mentioned earlier, the block execution process occurs in parallel with consensus, although 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 blocks can indeed be executed in parallel. If transactions do not modify (write) the same state, and the result of one transaction does not affect another, then they can be executed in parallel. In short, their execution paths should not depend on each other. Giga does not have a mempool, and transactions are immediately included by the node. 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. When processing is complete, the system checks if the transaction conflicts with previous transactions. If there is a conflict, the transaction will be reprocessed. If there are no conflicts, its changes are applied to the blockchain and finalized. There may also be high-frequency collisions, in which case the system switches to processing one transaction at a time to ensure that the transaction can move forward. In simple terms, parallel execution distributes transactions across multiple cores, enabling those transactions that do not conflict to execute simultaneously. 4. Storage issues and optimization Due to the high volume of transactions, data needs to be both secure and easily accessible, so it should be stored in a slightly different way than traditional blockchain storage. Gigas store data in a simple key-value format, a relatively flat structure that helps reduce the need for multiple updates or checks when data changes. In addition, Giga uses tiered storage: 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 play back the logs to restore the correct state and apply the updates to RocksDB, a specialized database, to organize the data. The storage system uses a cryptographic accumulator that proves the correctness of the data without heavy calculations. The accumulators are updated in batches, allowing validators and light nodes to quickly agree on the current state of the blockchain. 5. Become a multi-proposer EVM L1 block...