How do Seilors work in parallel to win the fastest chain race?

“Seilor rabbit-hole series” Part 2

Sei is the first sector-specific L1 blockchain, optimized for exchanges. One of its main performance features is Market-Based parallelization.

The “Seilor rabbit-hole series” aim is to communicate the major breakthroughs of Sei. From its native order-matching engine, market-based parallelization, and twin-turbo consensus, it's hard for users to remain uninterested.

This second part of the “Seilor rabbit-hole series”, answers how the parallelization design choice is one of the main elements that guarantee the Speed and MEV protection that institutional actors require.

Sei and the concept of parallelization

One of Sei's major developments is parallelization, a term that is unfamiliar to many, yet a rewarding mechanism for those who can leverage it. To start, let's define it:

parallelization is the process of dividing a large problem or computation into smaller, independent parts that can be solved concurrently. Its aim is to improve the performance of computation by using multiple processors or cores or by distributing the work across multiple computing nodes in a network.

Parallelization is widely used to speed up computations in various fields, including scientific simulations, financial modeling, and big data processing. In the case of blockchain systems, parallelization is used to scale the network and improve throughput.

In classic networks like Bitcoin or Ethereum, transactions are processed sequentially.
To get around this, Sei has multiple stages of transaction processing. Sei's block processing starts with BeginBlock, followed by DeliverTx and EndBlock. Block parallelization occurs in the DeliverTx (where non orderbook related transactions are processed) and endblock phases (where orderbook related transactions are aggregated and executed at the same price).

In Sei and other networks adopting this architecture design, transactions are processed simultaneously rather than sequentially, allowing multiple transactions to be processed at the same time.

Block Parallelization - Sei Whitepaper
Block Parallelization - Sei Whitepaper

Implementing parallelization can be challenging, but the rewards are significant. Most notably, one potential issue with parallelization is "double spending" where a user can spend resources they don't have due to the simultaneous execution of different transactions affecting the same key. There are many ways to overcome this problem, such as transaction "locking" a wallet until it's executed. If the parallelization implementation is successful, the network will benefit from faster transactions and the ability to handle more user activity.

Why is Parallelization a Big Deal?

Many layer 1 blockchains use sequential processing, which may lead to problems that are significant enough to slow down adoption and pose a risk to current users.

First let's focus on why slower output is not optimal. In order for individuals to enjoy healthy trading and everyday-use, we need quick block processing to ensure proper execution without network congestion. Such performance at scale, suitable for both enterprise and mass adoption, is exactly what Sei Labs has been working on.

If you missed our previous release, you can learn more about the frontrunning problem and how Sei is limiting it, here.

To reduce bad MEV, prevent congestion, and improve the user experience, Sei introduces market-based parallelization, further improving its network.

How Sei Parallelization is Market-based?

Let’s see how Sei’s market-based block parallelization is one of the most important features set to further solve the current DeFi problems (like illiquidity, limited scalability, and centralization). To onboard the next generation of DEXs Sei modifies the way parallelization is implemented. Most transactions are processed simultaneously during the DeliverTx phase (where changes to public keys are made), however, Order Book (CLOB) related transactions are processed during the EndBlock phase (where changes are recorded and finalized). The parallelization in both phases plays a big role in block optimization and frequent-batch auctioning.

As we well know from the previous Seilor Rabbit hole article the order matching engine executes the transactions atomically in one block (order placing and execution are collapsed). To fully understand why the design is market-based we need oversight over the lifecycle of a transaction.

Let’s see an example for clarity:

A user sends a 10$ transaction (Tx Processing stage) which happens to be one of the many trade orders (SEI/BTC) that need to be matched. This transaction (with different orders) is then sent to the dex module (DEX EndBlock), where multiple orders across different transactions in that block, will be aggregated by market (i.e. all orders for a BTC perpetual).

Finally, To cut down on gas costs and increase speed, these orders are combined into one smart contract for that particular market (i.e SEI/BTC Spot pair on Sushiswap and BTC futures on Vortex). So during the block processing, Sei will correctly route all orders to their respective smart contracts and markets.

Lifecycle of a transaction - Sei Whitepaper
Lifecycle of a transaction - Sei Whitepaper

What about the others?

When it comes to comparison, speed, and differences there are two projects which share the stage with Sei. DYdX and Injective protocol are both implementing various techniques to improve their throughput and deliver a better user experience.

  • In the case of the first, to ensure faster transactions and no hiccups during high-volume phases dYdX V3 utilizes layer 2 scaling solutions such as rollups, which allow dYdX to process a large volume of transactions off-chain and reduce the load on the Ethereum network.
    Furthermore, dYdX is also migrating to Cosmos (in its V4) to allow for an off-chain order book, interoperability, higher speed, and even more, decentralized governance. Launching an app chain seems to be the best option to achieve TradFi-grade performance and reduce malicious MEV bots.

  • With a similar architecture, the Injective protocol is also a layer 2 based on the Cosmos SDK, accompanied by Frequent batch auction.

Sei’s superiority should come, in theory, from its on-chain OME, twin-turbo consensus, and parallelization, therefore, resulting in transactions being executed fast, and reliably even during peak trade volume.


With hard work, continuous iterations, experience, and creativity, true innovation can be achieved. Market-based parallelization, one of the many features which make Sei so interesting, results in tremendous advancement for the DeFi sector because it reduces the risks associated with using DEXs. A key problem is leaving many potential users on the sideline out of fear. Now there is a brighter path and a more excited DeFi community filled with hope and trust for the future.

Article by 3Vlabs.io, author Boil Hristov.

References

  1. White-paper “Sei: The Sector Specific Layer 1
    Specialized for trading, giving exchanges the unfair advantage”
    , Sei Labs.

  2. “Parallel Blockchain Scaling” by Laurentz, Medium

  3. “How to Detect and Avoid Front Running in Crypto and NFT Trading” by Nikolay Kaloyanov, Hi Resources


Follow @3vLabs for more #3Vinsights curated by our research collective ranging from early-stage project analysis to brief crypto pills.

Subscribe to 3V Labs
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
Verification
This entry has been permanently stored onchain and signed by its creator.