Sei - First Specific Level 1
Annotation
The history of new technologies has demonstrated the dynamics of the program-infrastructure cycle, where programs stimulate demand for better infrastructure, which allows new types of programs to be created. General purpose blockchains have offered the initial infrastructure that has led to the explosion of decentralized programs over the past few years. As key programs go through the first phase of implementation, they face limitations in scalability, speed, and reliability. Just as the web2 infrastructure has specialized in key use cases as the industry has evolved, the blockchain infrastructure must specialize in key types of programs to allow the largest web3 programs to reach mainstream adoption.
We introduce the Sei blockchain, a level 1 sectoral blockchain specialized in trading. At the protocol level, Sei introduces new approaches to transaction sequencing, block processing, and parallelization specialized in exchanges. In addition, Sei offers a highly optimized order placement and matching mechanism that is built into the chain itself.
Introduction
By far, the exchange is the most common type of application in cryptocurrency. The vast majority of cryptocurrencies are still exchanged offline through centralized exchanges. Decentralized exchanges (#DEXs) have the potential to be one of the killer uses of crypto, similar to centralized exchanges. They are already everywhere, covering AMMs, order books,# NFT markets, and in-game exchanges. DEXs cause a large network effect and major ecosystems are built around them.
Ironically, DEX is also the most under-maintained application in cryptocurrency. They require a unique set of reliability, scalability, and speed requirements that are different from other programs. The main reason why it is difficult for #DEX to compete with centralized exchanges is the lack of proper infrastructure. In an effort to support all types of applications, general purpose blockchains cannot provide the unique environment needed for DEXs to offer the best user experience.
As a result, we offer #Sei, which is an L1 sector blockchain that specializes in trading and will bridge the performance gap between centralized and decentralized exchanges. At the protocol level, Sei uses Twin-Turbo consensus and multiple stages of parallelization to reduce latency and increase throughput. #Sei also has its own order matching engine that fills deals through frequent batch auctions, helping to ensure a fair price and preventing a race. This paper will also look at some of the user experience customization that Sei has, including native price oracles and transaction order grouping.
Protocol improvement
Sei is built using Cosmos SDK and Tendermint Core. As of this writing, Sei has forked the Cosmos SDK and Tendermint Core and added significant specialized features and optimizations.
Twin Turbo Consensus
Intelligent block distribution.
Once a full node receives a transaction from a user, it must relay it to other nodes on the network. Full nodes will randomly report this transaction to other nodes in the network. Once a validator receives a transaction, it validates the transaction and adds it to the validator's local memory pool.
Those who propose blocks will look at the current state of their mempool and propose a block to commit. Since most, if not all, transactions will be received by validators using the transaction propagation approach described above, authors will include unique transaction IDs in the block proposal, along with a link to the full block. Authors first distribute the offer to other validators on the network, and then the entire block (containing the full content of each transaction). The proposal will be sent in one message, and the entire block will be broken into pieces and transferred to the network. If a validator has all the transactions for an offer in its local mempool, it will reconstruct the entire block from its mempool instead of waiting for all parts of the block to arrive. If he doesn't have all the transactions, he will wait to get all the pieces of the block from the network and build a block with all his transactions.
This process greatly reduces the total amount of time a validator waits to receive a block. When validators receive all transactions as part of a block proposal, they follow the Tendermint BFT consensus to agree on the order of transactions. Specifically, before a block and associated state changes are committed to the blockchain, there will be a pre-vote stage, a pre-commit stage, and a commit stage.
As part of the Tendermint consensus, validators will receive a block proposal, verify the authenticity of the block, and then proceed to the pre-voting stages.
Instead of waiting for the pre-commit stage to complete to start processing the transaction (Figure 2a), validators will start the process at the same time to optimistically process the first block proposal they receive for any height (Figure 2b). Optimistic block processing will write the state of the candidate to the cache.
If this block is accepted by the network, the data from the cache will be pinned. If the network rejects a block, then the data from the cache will be discarded and future rounds for that height will not use optimistic block processing.
Parallelization
As part of the #Cosmos SDK, when validators receive a block and start processing it to update the state of the network, they first run the BeginBlock logic, then the DeliverTx logic, and then the EndBlock logic. Each is fully configurable, and Sei has configured DeliverTx and EndBlock to parallelize transaction processing.
Sei first processes all transactions in the block at the DeliverTx stage. This results in a state change for most types of transactions (sending tokens, governance proposals, smart contract calls, etc.). However, transactions related to the central limit order book (CLOB) only go through basic processing during the DeliverTx phase, and most state changes are applied in the EndBlock logic. This is done to support frequent batch auctions where orders are aggregated and a single clearing price is calculated at which orders are executed.
For optimal performance, #Sei added parallelization to DeliverTx and EndBlock.