Delphi Digital: Why We Are Bullish on Sei Network.

23-01-13 11:42

Read this article in 20 Minutes

AI summary

View the summary

Original Title: "Delphi Digital: Why We Are Bullish on Sei Network"

Original Author: Delphi Digital

Original Translation: Babywhale, Foresight News

On January 4th, the cryptocurrency trading platform MEXC announced the launch of a $20 million special fund to support the development of Sei Network's key projects. As early as August 31st, Sei Labs announced that it had completed a $5 million seed round of financing, led by Multicoin Capital, with participation from Coinbase Ventures, GSR, Flow Traders, Hudson River Trading, Delphi Digital, Tangent, and others. One month after announcing the completion of the financing, Sei Network launched a $50 million ecological fund to support the development of DeFi applications on its platform.

As one of the investors of Sei Network, Delphi Digital has written a report to explain why it is optimistic about Sei Network. Here, the author summarizes and organizes the key points in the report for everyone to discuss together.

专为 DeFi 而设计的网络

Designed specifically for DeFi

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

"Designed specifically for DeFi" means fundamentally changing (and balancing) the underlying layer to enable the flourishing of DeFi applications. Sei has a built-in order matching engine, settlement speeds in microseconds, parallel processing of orders, and single-block order execution. All of these customized features are completed at the underlying 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 a simple application chain, unlike THORChain, which focuses only on cross-chain exchange of "pure" application chains, but rather a blockchain developed for the characteristics of products such as DEX, contracts, and futures."

In order to understand why these changes are being made on the underlying network, we can look at Serum and Solana. Solana is a general Layer 1 blockchain, touted as the "NASDAQ on-chain", with a goal of 400 millisecond block confirmation times and extremely high throughput. Solana's main point of view is that order book trading platforms will eventually take over AMMs, and Solana's metrics also support this view. Serum is an order book application built on top of Solana and is the most widely used application in the Solana ecosystem, accounting for about one-third of the transactions on Solana.

Serum is the "order book layer" on Solana, used by projects such as Mango Markets, Zeta, Atrix, Bonfida, Jupiter, etc. When people think of Solana, they usually think of Serum.

However, this architecture also has some drawbacks. The most noteworthy is that, as Solana is a general-purpose chain, Serum (and the applications built on top of it) constantly compete for resources with other applications. Activities unrelated to Serum, such as gaming and NFT minting, can cause congestion on the chain, as we have experienced with Solana's several "outages" before. Sei, on the other hand, chooses to "cut the feet to fit the shoes" and strip all non-DeFi activities from their chain. A simple explanation is that Sei is like Serum launching its own Layer 1 blockchain: making specific trade-offs to optimize the base layer for DeFi and giving DeFi applications built on top of it an "unfair advantage" over non-DeFi applications.

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

Sei has implemented some optimizations through ABCI++. ABCI++ is an upcoming upgrade to Cosmos' ABCI, making each step of consensus programmable. Sei has been trying to make three improvements using ABCI++: optimizing block production, intelligent block broadcasting, and parallel execution of orders.

Use ABCI++ to optimize Sei

For those who focus on 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 differences between blocks, smaller spreads, and less risk for market makers. Any delay of more than a few hundred milliseconds is unacceptable (and in the long run, a few hundred milliseconds may still be too high). A standard Cosmos chain has a block confirmation time of about 6 seconds, which makes the order book not the optimal solution. However, the appeal of Cosmos lies in its customizability, and Sei has always focused on making changes to optimize consensus and make it as fast as possible (with a target of about 300-600ms). Sei's three main areas of focus are:

Optimize block production, intelligent block broadcasting, and parallel execution of orders.

Sei achieves this by utilizing ABCI++. ABCI is the interface between the application and the consensus, and its main function is to execute blocks determined by the consensus. With ABCI, the application only interacts with the consensus during decision-making, and has little control over which transactions are selected from the mempool. ABCI++ adds programmability to every step of the consensus, allowing the application to reorder, modify, abandon, delay, or add transactions, as well as shorten block production time by introducing optimization capabilities.

After the consensus proposal step, the application can start optimizing the processing of blocks in parallel with the pre-vote and pre-commit stages. Then, Sei will begin "optimizing" the state transition to a temporary candidate state until it is accepted by the consensus. If it is not accepted (which is rare), the block will be abandoned. There is a lot of data to process in this step, which can be quite slow. However, by optimizing the state transition process, we can shorten the block time 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, the block will include all transaction details, which can be very large in size. However, validators have already obtained about 99.9% of these transactions from their local mempool, so they do not need to wait to receive this data again from the block proposer. Instead of sending all the details, the proposer now only needs to send the hash value of each transaction in the block, and validators will be able to quickly reconstruct the block using their own local mempool.

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

The third optimization of the block production process revolves around transaction execution. In the Cosmos chain that uses ABCI, transaction processing is executed in chronological order. During this process, transactions in any market are processed one by one, greatly hindering throughput. And as the load increases, the delay will also increase exponentially. By using parallel processing, non-overlapping independent markets can be processed simultaneously. Instead of processing the first transaction in market B after processing the transactions in market A, it is better to process them simultaneously. Transactions within a specific market still need to be processed in order to avoid uncertainty. When two different validators obtain different results for the same state, uncertainty occurs (for example, one validator processes user A's order before user B, but another validator processes user B's order before A, resulting in a conflict in the settlement price for the user).

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

Native price oracle. Establish an oracle in the underlying layer; validators need to reach consensus on prices when producing a block. The block will not be established until validators reach consensus on prices. Allows other modules to obtain reliable price information from the on-chain market.

Single block order execution. Allows for placing and executing orders within a single block (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 and settled at a single price; the goal is to attempt to minimize front-running as much as possible.

In addition to software improvements, Sei has also been testing smaller validator structures and higher hardware requirements. Although there have been trade-offs in decentralization, these have been accompanied by significant performance improvements, highlighting once again the uniqueness of Cosmos: customizability.

Use high-performance hardware configuration validator

In the first version of the Sei project documentation, the recommended specifications and standards are similar to those of the Cosmos chain. Later, the hardware requirements were increased, and in specific load tests, the requirements were further increased. The order book model has high hardware requirements, and low-performance machines will reduce the overall performance of the network. Although not at the level of Solana's requirements, Sei has made it clear that they want their validators to exceed those of common blockchains. Additionally, they are pushing for centralization of validator geographic locations to further reduce latency.

Why host a server? If validators are geographically dispersed, information transmission takes longer, resulting in higher latency in achieving consensus and generating blocks. Order book trading platforms need to minimize latency as much as possible. Sei has once again released some test results regarding server hosting:

1. Compared to geographic dispersion, hosting on a dedicated server can reduce latency by approximately 46%.

2. 50 validators is the maximum limit that can withstand delay.

There are clear advantages and disadvantages to having all validators in the same geographic area, but the performance improvement cannot be ignored. When Sei launches its mainnet, they are likely to move towards this centralized, smaller validator set. In the chart below, p50/p75/p95 refers to the probability that x% of requests will be faster than a certain 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 other aspects. This article will temporarily skip over these and only showcase Sei Network's innovations in technology and mechanisms. It can be seen that Sei has made innovations in parallel processing and block broadcasting, improving network transaction confirmation speed. However, on the other hand, Sei requires validators with high-performance hardware configurations, and these validators need to be geographically concentrated to further meet its support for the order book model trading platform. Delphi acknowledges the centralization issue of this solution in the report, but also states that its performance improvement cannot be ignored.

The author believes that, as mentioned in the article, the Cosmos ecosystem's application chain is highly customizable, and Web3 should already be inclusive of what ideology should be presented for blockchain. We can support projects with high decentralization, as well as accept projects that sacrifice some decentralization for efficiency. However, whether Sei Network can be as "fast" as they claim remains to be seen with real data after the mainnet goes live.