Sei: The Cosmos-based Layer 1 Blockchain Tailored for Trading
Undoubtedly, decentralized finance, or DeFi, is one of the most popular DApps in the blockchain space. However, many existing DApps suffer from the limitations of their base layers. Take Ethereum, for example. It has become infamous for its ridiculous gas fees, especially during times of network congestion due to airdrops and new popular NFT collections. This has led many users to migrate to alternative blockchains, or even worse, they have to rely on centralized exchanges (CEX), undermining the purpose of a permissionless and decentralized world.
Solutions like dYdX have emerged, which was developed using StarkEx and tailored particularly for DEX specialized for its order book feature, offering faster finality and a much lower fee compared to those DEXs on layer 1. However, a significant drawback of dYdX is its app chain specificity, which prevents seamless interaction with other DApps. Thus, users can forget about composability when using dYdX.
So, can we do better? Absolutely, and that's precisely why we're delving into this article. Today, we're introducing Sei, a Cosmos-based Layer 1 blockchain optimized for trading with the ambition to achieve widespread mass adoption.
Sei Overview
Sei is a layer-1 blockchain based on the Cosmos SDK. However, what sets Sei apart from other Cosmos-based chains is its optimization and customization of both the Cosmos SDK and the Tendermint consensus. This approach makes Sei a high-performance blockchain uniquely tailored for trading, boasting several standout features:
-
Sub-second Finality: Users can enjoy fast finality with a lower bound of just 300 milliseconds.
-
Parallelization: Sei can achieve a high throughput of 20,000 orders per second.
-
Frontrunning Protection: With Sei's native matching engine at its core, users are protected from malicious MEVs, such as frontrunning.
-
Native Price Oracle: Sei's built-in Oracle offers data freshness, and the data updating period is configurable and can be as short as a single block duration.
Curious about the mechanics enabling these standout features? Let's delve in.
Sub-second finality with Twin-Turbo consensus
The Twin-Turbo consensus improves the previous block propagation and processing in Tendermint consensus, resulting in sub-second finality. It achieves this through:
-
Intelligent Block Propagation
-
Optimistic Block Processing
Intelligent Block Propagation
In traditional Tendermint, as discussed in our previous article [1], the process involves three main steps: Propose, Prevote, and Precommit. Users forward their transactions to validators. Then the validators validate these transactions and store them in their local mempool. These transactions are then disseminated with peer validators. At the start of each height, a leader or proposer selects transactions from their mempool to form a block, broadcasting this block to other validators during the Propose phase. However, this method has a redundancy: transactions are broadcasted twice - once during mempool dissemination and then during the Propose step. DAG-based protocols like Narwhal aim to solve this, as discussed in [2].
Sei addresses this issue of re-broadcasting transactions by broadcasting the proposed block into two forms:
-
The proposal contains the digests or hashes of each transaction in the block, which is significantly smaller than the entire block.
-
The entire block contains the full content of all the transactions.
First, the leader sends the proposal, followed by the entire block, which is broken up into small chunks before being disseminated into the network.
Upon receiving the proposal, each validator checks their local mempool whether it has all the transactions required to construct the full block. If it does, it constructs the block from its mempool and immediately moves to the Prevote phase without the need to wait for the full block to arrive. If not, it waits for the chunks containing the missing transactions. Noting that since most of the validators in the networks already have the required transactions in their mempool from the first mempool dissemination, this method significantly reduces the amount of time used in the Propose phase and bandwidth.
Optimistic Block Processing
Figure 1 shows block processing in Tendermint consensus. (Source: Sei whitepaper)
As we move to the subsequent phases, validators engage in the remaining Tendermint consensus steps shown in Figure 1. At the end of the Precommit phase, if the network accepts a proposed block, validators process it to determine the state transition before its commitment. Traditional Tendermint, which involves sequential block processing, introduces latency, acting as a bottleneck. In contrast, Sei uses optimistic block processing. This technique allows validators to initiate block processing in parallel with the other stages, starting as soon as they receive the complete block during the Propose phase (as illustrated in Figure 2). The resulting state, which is only a candidate state at this point, is recorded in the validators’ caches. If the network accepts the block, this state can be immediately committed. Otherwise, the candidate state is discarded from validators' caches, and the subsequent round for the current height reverts to standard, non-optimistic block processing.
Figure 2 shows the optimistic block processing. (Source: Sei whitepaper)
Parallelization
Sei modifies the logic of the state transition function (application logic) within the Cosmos SDK. Unlike traditional blockchains that process block transactions in sequence, Sei can process independent transactions concurrently. This holds for most types of transactions, from token transfers to smart contract invocations. To effectively implement this parallel execution, Sei first identifies transaction dependencies within a block using a directed acyclic graph (DAG).
As a part of Sei's state transition logic, Sei’s native matching engine is invoked as the final step. This logic has to be applied at the end of the process to calculate uniform clearing prices for each market, effectively preventing MEV, which we will explain more in the subsequent section. Although the matching engine's activation is positioned at the final step of the application logic, it can still operate in parallel as long as they do not affect the same market in the same block.
Native matching engine
The matching engine starts with order cancellations to maximize liquidity for matching orders, followed by adding all limit orders to the order book, and then market orders are processed. During market order processing, this stage is vulnerable to MEV. To solve the problem, 'Frequent Batch Auctioning' is used in Sei. By aggregating all the market orders and executing them at once at the uniform clearing price derived from averaging the sell orders, here is the example from Sei's whitepaper section 4.3: if the order book has two sell orders at prices P1 and P2 and two buy orders, B1 and B2, both buy orders will be executed at a price derived from the average of P1 and P2, (P1 + P2)/2.
Native price oracle
To ensure the freshness and accuracy of data, validators in Sei serve as oracles. Each data update cycle concludes within a specified voting window, which can be as short as a single block interval. In the voting phase, validators submit their exchange rates, where the final rate is derived from a weighted median of all proposed rates, with the weight based on each validator's voting power.
Additionally, Sei also implements a mechanism to ensure data integrity. There is a count for a misbehaving validator who either submits incorrect data or fails. If the count is higher than a certain threshold within a specific time window, the validator is slashed as a penalty.
[1] link to Tendermint article
[2] link to Sui Narwhal DAG based mempool article