Sei Network. An ocean of new opportunities for DeFi.

DeFi space will no longer be the same…

Artem
5 min readOct 21, 2022

I was introduced to the Sei Network only a week ago. And I am absolutely delighted! I have been trading for more than 5 years and use DeFi quite a lot. Many of the problems I have encountered during these years have already been solved by the Sei team.
The team has studied the key problem points and has come up with some really interesting solutions — their approach increases data accuracy and decreases the processing time between users and the platform. You might ask, how did they do that?

Let’s get acquainted with their know-how and how they solve existing problems of DEX optimization, as well as problems with compatibility, scaling, overloading and high spread.

Breaking Tendermint

The problem
There is no way to find out about the block proposal before the voting period begins

The solution
The Sea team made major changes to the Tendermint configuration to fit their needs

With the advent of ABCI++, the application layer now has a chance to know about the block proposal before the voting period commences. This, in theory, presents an opportunity for the application to optimistically process the block proposal in parallel with the voting process, thus reducing the overall block time.
source: github

This processing of the proposal will shorten the block processing time.

DeFi-specific parallelization

Source: @jayendra_jog

The problem
High spread and low throughput due to technical limitations of sequential processing of orders.

The solution
Sei has implemented a parallel order matching system, which essentially allows order matching processes for different markets (trading pairs) to run simultaneously. However the problem of nondeterminism appears. It is a case when one and the same code is processed twice, but the result is different. The team has found a solution here, too. To get around nondeterminism only the orders which cannot overlap (i.e., were created in different markets) are processed in parallel, and the orders created in one market are processed sequentially. Again the win-win scheme.

And as a result, the transactional finality (block time) is 600ms

Source: https://blog.bybit.com/

Optimistic block processing

Option A — standard block processing | Option B — optimistic block processing

The problem
Processing of the block starts only after its full validation (sending prevote and precommit messages and their processing by Validators). Obviously, the more data needs to be processed, the more time it will take.

The solution
The Sei team realized that, statistically, most of the first blocks of the chain are processed and eventually accepted. Instead of having validators idle, they should process the first blocks of each chain (in parallel with prevote and precommit) and apply them to a temporary candidate state (Option B). In most cases this block will be accepted and then the candidate state is accepted, but if the block is not accepted and the validators have made a mistake, then it is simply discarded and processing continues in the standard way (Option A) at any given height. This is made available thanks to the Tendermint ABCI++ interface (see the Breaking Tendermint chapter)

Intelligent block propagation

Option A — standard sending of blocks | Option B — intelligent block propagation

The problem
99.9% of the validators already had transactions in their mempool, but they were still pending them.

The solution
The Sei team proposes is that the Block Proposer (Validator 1) creates and sends a block proposal (Block ID) with certain hashes of transactions “X”, and Validator 2 checks the presence of hashes X in his mempool , confirms it, and he can construct the block locally (Option B). Now Validator 2 does not wait to receive all transactions. This will happen in 99.99% of cases, and if the event happens to unfold in the worst-case scenario with a 0.001% chance, it will process it in the usual way (Option A). This is why the intelligent block propagation method is win-win in terms of speed.

Native order matching engine

The problem
There is no universal way for applications to be compatible with markets and therefore scalable.

The solution
Sei has built a native order matching engine into the chain itself, and any application can leverage to instantly spin up new markets. Using the Cosmos SDK, Sei will be compatible with IBC. This greatly simplifies the compatibility problem, eliminates a number of potential errors, and opens the door for newcomers to the DeFi market.

So, here’s a quick recap of Sei journey:

  • started with baseline Cosmos metrics <5000 Orders per Second
  • the team made serious changes in Tendermint configuration to fit their needs and got good results — 7400 ops
  • after that they looked into the endblock is processed and added DeFi-specific parallelization12000 ops
  • using optimistic block processing 17000 ops
  • using intelligent block propagation22000 ops

As a result, Sei has more than 4 times the advantage of where they started. By comparison, Solana’s transactional throughput is only 10000 tps. AMAZING!

At the moment the team has launched Seinami Incentivized Testnet and everyone is welcome to join this exciting event. Well, I’m waiting for the launch of the mainnet and goodbye to you. And yes, to get you more acquainted with the project and even communicate with the team, I’ve left links to their social networks here. Good luck, DeFi-#seilors!

--

--

No responses yet