Delphi Digital: Why we like Sei Network

Although Sei Network has made many optimizations and innovations in improving transaction speed, it has also partially sacrificed decentralization.

Written by: Delphi Digital

Compiled by: Babywhale, Foresight News

On January 4, cryptocurrency exchange MEXC announced the launch of a US$20 million special fund to support the development of key projects in Sei Network. As early as August 31, Sei Labs announced that it had completed a US$5 million seed round of financing, led by Multicoin Capital, with participating investors including Coinbase Ventures, GSR, Flow Traders, Hudson River Trading, Delphi Digital, Tangent, etc. One month after the official announcement of the completion of financing, Sei Network launched a US$50 million ecological fund to support DeFi applications developed on it.

As one of the investors of Sei Network, Delphi Digital has written a report to explain why it is optimistic about Sei Network. The author here summarizes the key contents of the report for everyone to discuss.

A network designed for DeFi

When building blockchains, we usually try to categorize them into two different categories: general-purpose chains or application chains. Universal chains are used for permissionless innovation, while application chains are used for specific use cases that require permissions. But the "application chain" is not black and white, but is determined by the chain itself. Sei is an upcoming Cosmos ecological chain that aims to become a Layer 1 blockchain "designed for DeFi."

“Designed for DeFi” means making fundamental changes (and trade-offs) to the base layer so that DeFi applications can flourish. Sei has a built-in order matching engine, sub-second settlement speed, parallel processing of orders, single-block order execution, etc. All these customized functions are completed at the base layer. What you need to know is that Sei is not a DEX, it is a Layer 1 blockchain optimized for DeFi. At the same time, Sei is not a pure application chain, unlike THORChain, which only focuses on cross-chain exchanges, but a blockchain developed for the characteristics of products such as DEX, contracts, and futures.

To understand why we would want to make these changes to the underlying network, we can look at Serum and Solana. Solana is a general-purpose Layer 1 blockchain promoted as the “Nasdaq on the chain” that targets 400 millisecond block confirmation times and extremely high throughput. Solana’s main thesis is that order book trading platforms will eventually take over AMMs, and the indicators on Solana support this view. Serum is an order book application built on Solana. It is the most used application in the Solana ecosystem, accounting for about 1/3 of the transactions on Solana. Serum is the "order book layer" on Solana and is used by projects such as Mango Markets, Zeta, Atrix, Bonfida, and Jupiter. When people think of Solana, they usually think of Serum.

However, this architecture also has some drawbacks, most notably, because Solana is a universal chain, Serum (and the applications built on top of it) are constantly competing for resources with other applications. Activities that have nothing to do with Serum, such as gaming and minting NFTs, can cause congestion on the chain, as we have experienced with Solana’s several “outages” before. Sei chose to “cut their feet to fit the shoes” and strip all non-DeFi activities from their chain. A simple explanation is that Sei is equivalent to Serum launching its own Layer 1 blockchain: making specific trade-offs to make the base layer optimized for DeFi, and giving DeFi applications built on it more non-DeFi applications. unfair advantage".

The main trade-off here is that Sei won’t be permissionless like Solana, as developing apps 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 engine, price oracles, parallel order execution, and single-block order execution are some of the things Sei has built at the infrastructure level. Sei is an application chain, but Sei’s on-chain order book creates a composable architecture that allows synchronized composability between CosmWasm applications on Sei and the sharing of liquidity through the native order matching engine. As a Cosmos chain that supports IBC, it is inherently asynchronously composable.

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

Optimizing Sei with ABCI++

For focused order book trading, block production time, trade settlement and latency are most important to market makers. Market makers need to update their prices in every block, so shorter block times mean smaller price gaps between blocks, smaller spreads, and less risk for market makers. Anything over 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 a block confirmation time of about 6 seconds, making the order book a sub-optimal solution. However, the beauty of Cosmos is its customizability, and Sei has been focused on making changes to optimize consensus and make it as fast as possible (targeting ~300-600ms). Sei's three main areas of focus are:

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

Sei does this by leveraging ABCI++. ABCI is the interface between applications and consensus. Its main function is to execute blocks determined by consensus. With ABCI, applications only interact with the consensus for decision-making and have little control over which transactions are picked from the mempool. ABCI++ adds programmability to every step of consensus, allowing applications to reorder, modify, abandon, delay, or add transactions, as well as reduce block production time by introducing the ability to optimize block production.

After the consensus proposal step, applications can begin to optimize processing of blocks, in parallel with the pre-vote and pre-commit phases. Sei will then begin to change the state "through optimization" to a temporary candidate state until it is accepted by consensus. If not accepted (rarely), the block is abandoned. In this step, there is a lot of data to process and it can be quite slow. But by optimizing state change processing, we can shorten the time for block generation 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, this block will include all transaction details, and the amount of data will be very large, but the validator has already obtained about 99.9% of these transactions through their local mempool, so it is not Need to wait to receive this data from the block proposer again. Rather than sending all the details, proposers will now simply send the hash of each transaction in the block, and validators will be able to quickly reconstruct the block by using their own local mempool.

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

The third optimization to the block production process revolves around transaction execution. Transaction processing on the Cosmos chain using ABCI is performed sequentially. In this process, transactions are processed one by one regardless of which market they are in, which greatly hinders throughput. And as the load increases, the latency will also increase exponentially. Using parallel processing, independent markets that do not overlap can be processed simultaneously. Instead of processing the first trade in Market B after the trade in Market A, you can process them simultaneously. Transactions within a specific market still need to be processed in order to avoid non-determinism, which occurs when two different validators get different results for the same state (e.g. one validator processes before user B User A's order, but another validator processes User B's order before A, causing the user's settlement price to conflict).​

Sei did some load testing around parallelization (while also hosting the validators) to see what improvements could be made in terms of block times, latency, and throughput. Generally speaking, through parallelized execution, block times can be reduced by 75-90% compared to sequential processing, with parallel latencies of 40-120ms and sequential latencies of 200-1370ms. With 10,000 orders/block and 20 different contracts (markets), parallelism can reduce the block time from 1.33s to 0.81s, the delay from 371ms to 48ms, and the throughput from 7500 orders/s to 12,200 orders/s. Significant improvements are seen at all load levels (orders/blocks), with greater marginal optimization as load volume increases.​

In addition to the three major improvements mentioned above, Sei also adds other features to the base layer, such as:

Native price oracle. An oracle is built into the base layer; validators need to agree on a price when producing a block. Blocks are not created until validators agree on a price. Allow other modules to obtain reliable price information from the on-chain market.

Single block order execution. Allows order placement and execution in a single block (requires multiple blocks in Serum).

Order Bundling. Market makers can update prices in multiple markets in one transaction.

Frequent lot auctions. Market orders can be aggregated at the end of the block for liquidation at a single price; the aim is to try and 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 what makes Cosmos unique: customizability.​

Using high-performance hardware configuration validators

In the first version of the Sei project documentation, the recommended specifications were similar to the standard Cosmos chain. The hardware requirements were then increased, and in certain load tests the requirements were increased even further. The order book model has high hardware requirements, and low-performance machines will reduce the overall performance of the network. While not a Solana-level requirement, Sei has made it clear that they want their validator to outperform common blockchains. Additionally, they are pushing for the centralization of validator geographies to further reduce latency.

Why Colocation? If validators are geographically dispersed, information will take longer to transmit, resulting in higher delays in reaching consensus and generating blocks. Order book trading platforms need to reduce latency as much as possible. Sei has once again released some of their test results surrounding colocation:

1. Colocation reduces latency by approximately 46% compared to geographical dispersion.

2. 50 validators is the limit of acceptable latency.

There are obvious trade-offs to having all validators in the same geographical area, but the performance improvement is hard to ignore. When Sei launches mainnet, they will likely 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 for that test. So p95 means that 95% of requests will be faster than the p95 value.

Summarize

Delphi Digital’s report also includes content on ecology, tokens, etc. This article will temporarily skip them and only show Sei Network’s innovations in technology and mechanisms. It can be seen that Sei has made innovations in parallel processing and block broadcasting, which has improved the speed of network transaction confirmation; but on the other hand, Sei requires validators with high-performance hardware configuration and the geographical location of these validators. Relatively centralized to further satisfy its support for the order book model trading platform, Delphi also admitted the centralization problem of the solution in the report, but stated that its performance improvement cannot be ignored.

The author believes that, as mentioned in the article, the Cosmos ecological application chain is extremely customizable, and Web3 should be inclusive enough for the ideology of how the blockchain should be presented. We can support projects with a high degree of decentralization. Projects that sacrifice some decentralization for efficiency can also be accepted. However, whether Sei Network can be as "fast" as it says, we still need to use real data to give the answer after the mainnet goes online.