Delphi Digital: Why are we optimistic about Sei Network?

Written by: Delphi Digital

Compiled by: Babywhale, Foresight News

On January 4, cryptocurrency exchange MEXC announced the launch of a $20 million special fund to support the development of key projects on Sei Network. Earlier, on August 31, Sei Labs announced the completion of a $5 million seed round financing, led by Multicoin Capital, with participation from Coinbase Ventures, GSR, Flow Traders, Hudson River Trading, Delphi Digital, Tangent, and others. One month after the official announcement of the financing, Sei Network launched a $50 million ecosystem fund to support the development of DeFi applications on its platform.

As one of the investors in Sei Network, Delphi Digital wrote a report explaining why it is optimistic about Sei Network. The author summarizes the key points from the report for discussion.

A Network Designed Specifically for DeFi

When building a blockchain, we often try to categorize it into two different types: general-purpose chains or application-specific chains. General-purpose chains are used for permissionless innovation, while application-specific chains are used for specific use cases that require permission. However, "application-specific chains" are not strictly black and white; it is determined by the chain itself. Sei is an upcoming Cosmos ecosystem chain designed to be a Layer 1 blockchain "specifically designed for DeFi."

"Specifically designed for DeFi" means making fundamental changes (and trade-offs) to the base layer, allowing DeFi applications to thrive. Sei has a built-in order matching engine, sub-second settlement speeds, parallel order processing, and single-block order execution. All these customized features are implemented at the base layer. It is important to note that Sei is not a DEX; it is a Layer 1 blockchain optimized for DeFi. At the same time, Sei is not merely an application chain; unlike THORChain, which focuses solely on cross-chain swaps as a "pure" application chain, it is a blockchain developed for products such as DEXs, contracts, and futures.

To understand why these changes are desired at the underlying network level, we can look at Serum and Solana. Solana is a general-purpose Layer 1 blockchain marketed as "the Nasdaq on-chain," aiming for a 400-millisecond block confirmation time and extremely high throughput. The main point of Solana is that order book trading platforms will eventually take over AMMs, and the metrics on Solana support this view. Serum is an order book application built on Solana and is the most used application in the Solana ecosystem, accounting for about 1/3 of the trading on Solana. Serum serves as the "order book layer" for projects like Mango Markets, Zeta, Atrix, Bonfida, and Jupiter. When people think of Solana, they often think of Serum.

However, this architecture also has some drawbacks, most notably that, since Solana is a general-purpose chain, Serum (and the applications built on it) constantly competes for resources with other applications. Activities unrelated to Serum, such as gaming and minting NFTs, can lead to congestion on the chain, as we have previously experienced with several "downtimes" of Solana. Sei chooses to "cut its coat according to its cloth," stripping away all non-DeFi activities from their chain. A simple explanation is that Sei is akin to Serum launching its own Layer 1 blockchain: making specific trade-offs to optimize the base layer for DeFi and giving DeFi applications built on it an "unfair advantage" over non-DeFi applications.

The main trade-off here is that Sei will not be permissionless like Solana, as developing applications on it requires whitelisting through governance. While you lose some of the advantages of permissionless innovation, you can create a more optimized environment. Native order matching engines, price oracles, parallel order execution, and single-block order execution are some of the features Sei has built at the infrastructure level. Sei is an application chain, but the on-chain order book creates a composable architecture that allows for synchronous composability between CosmWasm applications on Sei and shares liquidity through the native order matching engine. As a Cosmos chain supporting IBC, it inherently has asynchronous composability.

Sei has implemented some of its optimizations through ABCI++, an upcoming upgrade to Cosmos's ABCI that makes every step of consensus programmable. Sei has been trying to make three improvements with ABCI++: optimizing block production, smart block broadcasting, and parallel order execution.

Optimizing Sei with ABCI++

For order book trading, block production time, transaction settlement, and latency are the most important factors for market makers. Market makers need to update their prices in each block, so shorter block times mean smaller price gaps between blocks, resulting in lower risks for market makers. Any time exceeding a few hundred milliseconds is unacceptable (and a few hundred milliseconds may still be too high in the long run). A standard Cosmos chain has about a 6-second block confirmation time, making order books less than optimal. However, the charm of Cosmos lies in its customizability, and Sei has been focused on making changes to optimize consensus and make it as fast as possible (targeting around 300-600ms). Sei's three main focus areas are:

Optimizing block production, smart block broadcasting, and parallel order execution.

Sei achieves this through the use of ABCI++. ABCI is the interface between applications and consensus, primarily serving to execute blocks determined by consensus. With ABCI, applications only interact with consensus during decision-making and have almost no control over which transactions are selected from the mempool. ABCI++ adds programmability to every step of consensus, allowing applications to reorder, modify, drop, delay, or add transactions, and to shorten block production times by introducing optimizations that produce blocks.

After the proposal step of consensus, applications can begin optimizing block processing in parallel with the pre-vote and pre-commit phases. Then, Sei will begin to "optimize" state changes to a temporary candidate state until accepted by consensus. If not accepted (which is rare), the block will be discarded. At this step, a large amount of data needs to be processed, which can be quite slow. However, through optimized state change processing, we can shorten block times and significantly reduce latency (by about 300ms).

In addition to optimizing block production, Sei is also improving block information broadcasting. In Tendermint, when a validator proposes a block, it includes all transaction details, resulting in a large amount of data. However, validators have already obtained about 99.9% of these transactions from their local mempool, so there is no need to wait to receive this data again from the block proposer. Instead of sending all details, proposers now only need to send the hash of each transaction in the block, allowing validators to quickly reconstruct the block using their own local mempool.

Sei has named these two optimizations "Twin-Turbo Consensus" and states that by implementing these two optimizations (optimizing block production and smart block broadcasting), throughput has increased by 83%.

The third optimization of the block production process revolves around transaction execution. In Cosmos chains using ABCI, transaction processing is executed sequentially, meaning that transactions in any market are processed one by one, significantly hindering throughput. As the load increases, latency also increases exponentially. With parallel processing, independent markets that do not overlap can be processed simultaneously. Instead of processing the first transaction in market B after the transaction in market A, they can be processed at the same time. Transactions within a specific market still need to be processed in order to avoid uncertainty, which occurs when two different validators arrive at different results for the same state (for example, one validator processes user A's order before user B's, but another validator processes user B's order before A's, leading to conflicting settlement prices).

Sei has conducted some load tests (also hosting validators) to observe what improvements can be made in terms of block time, latency, and throughput. Generally, through parallel execution, block times can be reduced by 75-90% compared to sequential processing, with parallel latency ranging from 40-120ms and sequential latency from 200-1370ms. With 10,000 orders/block and 20 different contracts (markets), parallel processing can reduce block time from 1.33s to 0.81s, latency from 371ms to 48ms, and throughput from 7500 orders/s to 12200 orders/s. Significant improvements can be seen across all load levels (orders/block), with greater marginal optimization as the load increases.

In addition to the three main improvements mentioned above, Sei has also added other features at the base layer, such as:

Native Price Oracles. Building oracles at the base layer; validators need to reach consensus on prices when producing a block. A block will not be built until validators reach consensus on the price. This allows other modules to obtain reliable price information from on-chain markets.

Single Block Order Execution. Allowing orders to be placed and executed within a single block (which requires multiple blocks in Serum).

Order Bundling. Market makers can update prices for multiple markets in a single transaction.

Frequent Batch Auctions. Market orders can be aggregated at the end of a block for settlement at a single price; the goal is to try to minimize front-running.

In addition to software improvements, Sei has also been testing smaller validator structures and higher hardware requirements. While there are trade-offs in decentralization, these come with significant performance improvements and once again highlight the uniqueness of Cosmos: customizability.

Using High-Performance Hardware Configurations for Validators

In the first version of Sei's project documentation, the recommended specifications were similar to those of standard Cosmos chains. Subsequently, the hardware requirements were raised, and in specific load tests, the requirements were even further increased. The order book model has high hardware demands, and low-performance machines can degrade the overall performance of the network. While not at the level of Solana's requirements, Sei has made it clear that they want their validators to exceed common blockchain standards. Additionally, they are pushing for the geographical centralization of validators to further reduce latency.

Why host validators? If validators are geographically dispersed, the transmission of information takes longer, leading to higher latency in reaching consensus and producing blocks. Order book trading platforms need to minimize latency as much as possible. Sei has again released some test results regarding hosting:

1. Compared to geographical dispersion, hosting can reduce latency by about 46%.

2. 50 validators is the limit for acceptable latency.

Having all validators in the same geographical area presents clear pros and cons, but the performance improvements are hard to ignore. When Sei launches its mainnet, they are likely to move towards this centralized, smaller set of validators. In the chart below, p50/p75/p95 refers to the probability that x% of requests will be faster than a specific value. For example, p50 means that 50% of requests will be faster than the p50 value of the test. So p95 means that 95% of requests will be faster than the p95 value.

Summary

Delphi Digital's report also includes content on ecology, tokens, and more, which this article will temporarily skip, only showcasing Sei Network's innovations in technology and mechanisms. It can be seen that Sei has made innovations in parallel processing and block broadcasting, improving the network's transaction confirmation speed; however, on the other hand, Sei requires validators with high-performance hardware configurations, while also needing these validators to be geographically concentrated to further support its order book model trading platform. Delphi acknowledges the centralization issue of this solution in the report but states that the performance improvements are still significant.

The author believes that, as mentioned in the text, the customizability of application chains in the Cosmos ecosystem is extremely high, and Web3 should present a sufficiently inclusive ideology regarding how blockchains should be. We can support projects with high degrees of decentralization, and we can also embrace projects that sacrifice some decentralization for efficiency. However, whether Sei Network can achieve the speed it claims still needs to be answered with real data after the mainnet launch.