Because the technology that brings sei, namely such as transaction parallelization, twin turbo consensus, create the right basis for DEX exchanges and systems.
Sei blockchain is an industry-first blockchain specialized for trading. At the protocol level, Sei introduces new approaches to transaction sequencing, block processing and parallelization. As well as an optimized order placement and matching mechanism that is built into the blockchain itself.
Naturally, despite all the recent developments, centralized exchanges still hold a huge share of the market. The vast majority of cryptocurrencies are still exchanged there. But they are obviously losing their positions and users.
Decentralized exchanges are becoming one of the most in-demand tools, and are being integrated into all uses, including even derivatives and NFT marketplaces. Large ecosystems are being built around them. The main reason DEX cannot compete with centralized exchanges is the lack of proper infrastructure.
In an attempt to support multiple applications, general-purpose blockchain fails to provide the unique environment and performance required for DEX. Sei solves this problem. At the protocol level, Sei uses Twin-Turbo consensus as well as transaction parallelization to reduce latency and increase throughput. Sei also has a built-in order matching mechanism to help ensure the best prices and prevent outperformance.
Intelligent block distribution Once a complete node receives a transaction from a user, it has to pass it to other nodes in the network randomly. The validator then checks the validity of the transaction and adds it to the local memory pool. The nodes offering the block then look at the current state and offer the block for commit.
Since most, if not all, transactions have already been received by the validators in the way described above, the offering party includes unique transaction identifiers in the block offer, as well as a reference to the complete block. That is, all validators in the network receive the transaction information first, and then the entire block(containing the full contents of each transaction).
The offer will be sent as a single message, while the entire block will be broken down and transmitted to the network. If the validator already has all the parts locally, it will just recover the block, or it will wait for the block to load if it does not have all the transactions in its local memory pool.
If it does not have all the transactions, it will wait to receive all the parts of the block from the network, and build the block with all its transactions. This process, although difficult for ordinary users to understand, greatly reduces the total time a validator waits to receive a block.
Once validators receive all the transactions within the proposed block, they will follow the Tendermint consensus to agree on the order of transactions before the block and associated state changes are committed to the blockchain.
Optimistic block processing In Tendermint consensus, validators receive a block proposal, check its validity, and then move on to the pre-voting steps. In SEI, the validators start the process simultaneously to quickly process the first received block proposal at a certain height.
This processing of the block writes the state of the signature candidate to the cache. If this block is accepted by the network, the data from the cache will be committed. If the network rejects the block, the cache data will be discarded, and future rounds for that network height will not use optimistic block processing. In theory, such processing reduces latency and increases transaction speed.
Parallelization
Within the Cosmos SDK, when validators receive a block and start processing it to update the network state, they first perform BeginBlock logic, then DeliverTx logic, then EndBlock logic.
Each of these logics is fully configurable, and Sei configured DeliverTx and EndBlock to parallelize transaction processing as shown below, that is, in parallel:
Sei first processes all transactions in a block during the DeliverTx phase. This increases the block processing speed for optimal performance.
However, the transactions associated with the central limit order book only undergo basic processing during DeliverTx, and most of their state changes will be applied during the EndBlock logic. This is done to support batch auctions where orders are aggregated and a single clearing price is calculated.
Parallelization of DeliverTx transactions
Token transfers from account A to B and from account C to D can be performed in parallel because they update different keys.
However, defining a mapping based only on message type (and ignoring the message content) will cause the two transfers to be executed sequentially. To provide flexibility with respect to this type of parallelization, dependency mappings can be defined as templates that will be populated with more detailed data at runtime.
In the above example, with the sender's account tokens and beneficiary accounts will be passed to the template to obtain more detailed paralleling. For message types that are defined by the chain (stacking, oracle updates, transfers, etc.), the mappings are set in genesis and can be updated via voting.
There is one special case for the types of messages related to gas charges that naturally affect every transaction. This is handled by writing data to the repository, which is erased at the end of the DeliverTx logic.
Parallelization based on the market
At the end of the block, all orders associated with the CLOB will be processed by Sei's own order matching mechanism. Instead of processing orders sequentially, Sei will process independent orders associated with the CLOB in parallel at the end of the block.
Two orders are independent unless they affect the same asset in the same block. If these dependencies are incorrectly defined, transactions to the dependent smart contract will fail.
Limit orders: This is an order to buy/sell an asset at a specific price or better. When a limit order is submitted, it is usually added directly to the order book and will be matched against incoming market orders.
Market orders: This is an order to buy or sell an asset at the best price available. Market orders are executed immediately if there is liquidity in the order book. To prevent orders from being executed at prices which are very different from those expected by users, users placing trades can also specify a maximum slippage parameter.
Execute or cancel order: This is a special market order Either the entire order is executed immediately if there is enough liquidity in the order book or the order is canceled.
Stop Loss Order: This is an order to close a position by buying or selling at a specific market price.
Cancel order: This removes the order from the order book.
Partial execution, where only part of the total order is executed, is possible for limit, market and stop loss orders. If there is not enough liquidity to execute the entire order.
Hook Support
Sei allows contracts to register so-called hooks in the network. Registered hooks are called every block. A contract can define two hooks. The first is called at the beginning of a block to allow contracts to prepare for any potential transaction that may occur in that block. The second is called at the very end of the block, after matching orders and settlements, allowing contracts to perform any post-trade logic if necessary.
Sei offers several levels of order batching to improve user experience and productivity:
Batching customer orders. Sei transactions can consist of orders routed to multiple trading markets. This helps market makers reduce costs associated with position updates.
Bundling orders at the chain level Each order-related transaction requires the instantiation of a virtual machine (VM). Instead of having multiple instances, Sei bundles all orders across all transactions (per asset) and executes only one instance. This reduces latency by about 1ms per order, which is significant at times of high network load.
Trading Fees No trading fees at the chain level are expected at launch. The team may start applying trading fees in the future. Decentralized exchanges that build on Sei can add their own trading fees depending on the experience they want to offer their users. This will be defined at the smart contract level and will be easily customizable by the developers themselves.
The matching mechanism is an extremely flexible componentized system, so projects are expected to create middleware to exchange on top of the matching mechanism. This will allow new types of DEX to be created.
I hope this article has helped you understand why the sei will help DEX evolve in its blockchain, at the expense of technology twin-turbo consensus, transaction parallelization.
All links of Sei Network:
https://medium.com/@seinetwork
https://docs.seinetwork.io/learn/about-sei