Original compilation: Babywhale, Foresight News
Original compilation: Babywhale, Foresight News
On January 4, the cryptocurrency exchange MEXC announced the launch of a special fund of 20 million US dollars to support the development of key projects of Sei Network. And as early as August 31, Sei Labs announced that it had completed$5 million seed round, Multicoin Capital led the investment, and participating investors included Coinbase Ventures, GSR, Flow Traders, Hudson River Trading, Delphi Digital, Tangent, etc. One month after the official announcement to complete the financing, Sei Network launched$50 million eco-fund, to support DeFi applications developed on it.
As one of the investors of Sei Network, Delphi Digital wrote 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 together.
A network designed for DeFi
When building blockchains, we generally try to classify them into two distinct categories: universal chains or application chains. Universal chains are for permissionless innovations, while application chains are for specific use cases that require permission. 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 be a Layer 1 blockchain "designed for DeFi".
"Designed for DeFi" means making fundamental changes (and trade-offs) to the base layer that allow DeFi applications to thrive. 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 done 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 the "pure" application chain that only focuses on cross-chain exchange like THORChain, but a blockchain developed for the characteristics of products such as DEX, contracts, and futures.
To understand why one would want to make these changes on the underlying network, we can look at Serum and Solana. Solana is a general-purpose Layer 1 blockchain advertised as an "on-chain Nasdaq" targeting 400ms block confirmation times and extremely high throughput. Solana's main point is that order book trading platforms will eventually take over AMMs, and the metrics on Solana support this point. Serum is an order book application built on top of 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 top of Solana, used by projects like Mango Markets, Zeta, Atrix, Bonfida, Jupiter, and more. When people think of Solana, they usually think of Serum.
There are however some downsides to this architecture, most notably, since Solana is a general-purpose chain, Serum (and applications built on top of it) are constantly competing for resources with other applications. Activities unrelated to Serum, such as gaming and minting NFTs, can cause congestion on the chain, as we have previously experienced with Solana's several "outages". Sei chose to "cut the feet and fit the shoes", stripping all non-DeFi activities off their chain. A simple explanation is that Sei is equivalent to Serum launching its own Layer 1 blockchain: making specific trade-offs, making 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 will not be permissionless like Solana because wanting to develop applications on it requires whitelisting through governance. While you lose some of the advantages that come with permissionless innovation, you can create a more optimal environment. Native order matching engine, price oracle, parallel order execution and single block order execution are some of the things that Sei builds at the infrastructure level. Sei is an application chain, but Sei's on-chain order book creates a composable architecture that allows synchronous composability between CosmWasm applications on Sei and shares liquidity through the native order matching engine. As an IBC-enabled Cosmos chain, 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 broadcast, and parallel execution of orders.
Optimizing Sei with ABCI++
Optimized block production, smart block broadcast and parallel execution of orders.
Optimized block production, smart block broadcast and parallel execution of orders.
Sei does this by utilizing ABCI++. ABCI is the interface between the application and the consensus, and its main role is to execute the blocks determined by the consensus. With ABCI, applications only interact with the consensus at decision time 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 shorten block production time by introducing the ability to optimize block generation.
After the proposal step of consensus, applications can start optimizing processing blocks, in parallel with the pre-vote and pre-commit phases. Then, Sei will start "by optimization" to change the state to a temporary candidate state until it is accepted by consensus. If it is not accepted (very rare), the block is abandoned. In this step, there is a lot of data to process and it can be quite slow. But by optimizing the state change handling, we can shorten the block generation time and significantly reduce the latency (about 300 ms reduction).
In addition to optimizing block production, Sei is also improving block information broadcasting. In Tendermint, when a verifier proposes a block, this block will include all transaction details, and the amount of data will be very large, but the verifier has obtained about 99.9% of these transactions through their local mempool, so it is not necessary to Need to wait to receive this data again from the block proposer. Instead of sending all the details, the proposer can now just send the hash of each transaction in the block, and the validators will be able to quickly rebuild the block by using their own local mempool.
Sei dubbed the two optimizations "Twin-Turbo Consensus" and said that by implementing them (optimized block production and smart block broadcast), throughput increased by 83%.
A third optimization to the block production process revolves around transaction execution. The transaction processing of the Cosmos chain using ABCI is executed sequentially. In this process, transactions are processed one by one regardless of the market, which greatly hinders the throughput. And as the load increases, the latency will also increase exponentially. Using parallel processing, non-overlapping independent markets can be processed simultaneously. Instead of processing the first transaction in market B after the transaction in market A, it is better to process them at the same time. Transactions within a particular 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 processed before user B User A's order, but another validator processes User B's order before A, causing users' settlement prices to conflict).
Sei has done some work around parallelizationload test(also co-hosting the validators) to see what kind of improvements you can get in terms of block times, latency, and throughput. In general, block times can be reduced by 75-90% compared to sequential processing by parallelizing execution, with parallel latencies of 40-120 ms and sequential latencies of 200-1370 ms. With 10,000 orders/block and 20 different contracts (markets), parallelism was able to reduce block time from 1.33 s to 0.81 s, latency from 371 ms to 48 ms, and throughput from 7,500 orders /s to 12200 orders/s. Significant improvements are seen across all load levels (orders/blocks), with greater marginal optimization as the load increases.
In addition to the above three major improvements, Sei also adds other features in the base layer, such as:
Native price oracles.Build oracles in 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 bundles.Market makers can update prices for multiple markets in one transaction.
Frequent lot auctions.Market orders can be aggregated at the end of a block for liquidation at a single price; the purpose 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 terms of decentralization, these come with significant performance gains and again highlight what makes Cosmos unique: customizability.
Use a high-performance hardware configuration verifier
In the first version of the Sei project documentation, the recommended specifications are similar to standard Cosmos chains. The hardware requirements were then raised, and in certain load tests, the requirements were raised even further. The order book model has high requirements on hardware, 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 validators to outperform common blockchains. Additionally, they are pushing for geographic centralization of validators to further reduce latency.
Why Hosting? If validators are geographically dispersed, it takes longer for information to travel, leading to higher latency in reaching consensus and producing blocks. Order book trading platforms need to minimize latency as much as possible. Sei posted again some of their test results around hosting:
1. Colocation reduces latency by approximately 46% compared to geographic dispersion.
2. 50 validators is the limit of acceptable latency.
Summarize
Summarize
Delphi Digital’s report also includes ecology, tokens, etc., which are temporarily skipped in this article, and only show Sei Network’s innovations in technology and mechanism. It can be seen that Sei has made innovations in parallel processing and block broadcasting, which has increased the speed of network transaction confirmation; but on the other hand, Sei needs validators with high-performance hardware configurations, and the geographic location of these validators Relatively centralized to further satisfy its support for the order book model trading platform, Delphi also acknowledged the centralization problem of the solution in the report, but said that its performance improvement still cannot be ignored.
The author believes that, as mentioned in the article, the Cosmos ecological application chain is extremely customizable, and Web3 should be tolerant enough for the ideology of the blockchain. We can support projects with a high degree of decentralization. Projects that sacrifice some degree of decentralization for efficiency are also acceptable. However, whether Sei Network can be as "fast" as it says, it still needs to use real data to give the answer after the mainnet goes live.
