[Infrastructure] Why Sei Aims to be the Fastest Blockchain — Intersection of Scalability and Decentralization

Let’s learn about Sei’s ecosystem and technology, aiming to bring innovation to the financial experience by being the fastest blockchain.

17 min readAug 16, 2023

Disclaimer: This post is for informational purposes only, and the author is not liable for the consequences arising from any investment or legal decision based on the information contained in this post. Nothing contained in this post suggests or recommends investing in any particular asset. Making any decisions based only on the information or content of this post is NOT advised.

TL;DR

Sei offers an optimal trading experience through its native order matching system, anti-front-running mechanism, and network-level oracles.
Sei has implemented its unique Twin Turbo consensus mechanism and transaction parallel processing system to achieve its vision of on-chain financial innovation.
In order to achieve its scalability and security, Sei has raised the entry barrier for validators, compromising some decentralization — but it has ensured operational decentralization through the distribution of hosting infrastructure and geographical locations.
On August 15, 2023, Sei launched its mainnet. With a vision to provide the best trading experience, let's observe what changes Sei brings to the blockchain market.

1. Sei's Vision: Financial Innovation

Until today, financial innovation has primarily occurred through front-end improvements, enhancing user experiences. For example, companies that have reached unicorn status can be imagined, such as PayPal, Toss, Robinhood, and numerous others. Paradoxically, this also signifies that financial innovation in the backend has not occurred for a long time. The expectation of bringing about backend innovations in the financial sector has often been associated with pointing to blockchain technology's applications and the direction of mass adoption.

Innovation, whether disruptive or sustaining, is based on the premise of not deteriorating existing user experiences. So, is the current financial system being built by blockchain maintaining this premise without worsening the traditional user experience? In a world where real assets are tokenized and traded as securities on traditional exchanges, most transactions are conducted online. In such cases, users of exchanges typically trade at their desired time with the desired price and quantity, provided there are no other factors like liquidity constraints. As seen in examples from traditional finance, an order book-style exchange is a verified means of guaranteeing this user experience. The emergence of an order book in the DeFi development trajectory seems like a natural progression.

However, an order book records participants' orders and provides information about orders aggregated at specific points in time. Even if the order book is presented in the frontend, if the update of the order book takes more than a minute due to backend limitations, the order book loses its significance as a problem-solving tool. While the algorithmic advancements of AMMs (Automated Market Makers) in reflecting intentions regarding price and quantity are essential in terms of user experience, an environment where users can perceive 'sufficiently accurate' information and express their intentions is equally crucial.

In order to construct an ecosystem where not only the level of user experience provided by CEXs (Centralized Exchanges) is delivered but also there exists a tangible incentive for users to trade within that environment, Sei is rapidly progressing based on the vision of a 'decentralized NASDAQ'. In other words, Sei's emergence is rooted in the aspiration to surpass existing environments, including Ethereum, and achieve sufficient scalability through more innovative approaches, ultimately accomplishing financial innovation.

2. How Sei Provides the Best Trading UX

Since the release of the Bitcoin whitepaper, the blockchain scalability issue has been an ongoing concern and has led to numerous attempts at resolution. Sei, too, is a Layer 1 blockchain that emerged to address this scalability problem. Among the various attempts, what stands out about Sei is its clear direction towards the question of "why a fast blockchain is needed." Sei has deeply considered the construction of an ecosystem under a very clear value proposition of true financial innovation. Users are anticipated to soon encounter the fruits of this contemplation in the market. Particularly, towards the end of this article, we will discuss Sei's considerations and achievements regarding not only scalability but also stability during its mainnet launch process, based on A41’s validator operation experiences. For insights into why Sei aims for a 'general-purpose app chain' rather than a dApp, refer to our previous article.

Sei has only one value prop: exchange apps - whether it’s an NFT marketplace or gaming economy - will offer the best user experience by building on Sei.

The aforementioned value proposition of Sei can be summarized as delivering the best user experience, which in turn accomplishes financial innovation. Let's consider whether such innovation is indeed a crucial matter in the context of blockchain. In blockchain, finance encompasses all objects both online and offline — including the 'fun' through games or the 'utility' of protocols — represented in various forms such as tokens or NFTs, leading to infinite scalability. To truly realize innovations in the backend of finance, the emergence of products like Sei that aim to provide the 'best user experience' is highly welcome.

Before delving into how Sei achieves the essential scalability for the innovation it aims for, let's delve a bit deeper into the vision Sei is painting. Below, we will examine aspects from trading order matching to MEV protection systems, exploring the infrastructure and ecosystem Sei is constructing to achieve financial innovation. Specifically, we'll look at how Sei proposes solutions to enhance the user experience for each of the three elements of trading: (1) price, (2) quantity, and (3) execution time.

2.1 Native Order Matching Engine

Liquidity fragmentation isn't solely a problem between Layer 1 and Layer 2 solutions. While the need for bridging does complicate addressing liquidity fragmentation, the problem also exists among dApps (decentralized applications) operating on the same layer. As liquidity depth becomes shallower, price volatility increases. Solving such fragmentation issues is crucial to provide users with a positive experience. As mentioned earlier, Sei exists not as a single dApp but as an app chain. Leveraging this advantage, Sei has actively built a 'native order matching engine' as a solution to tackle liquidity fragmentation within the layer. Quite literally, this means that all dApps built on Sei can uniformly utilize the liquidity pool concentrated in one place.

Let's consider the necessity for such an engine using Nasdaq's CLOB (Central Limit Order Books) as an example. CLOB is a system used in the market-making process on Nasdaq. After a new order book is created (effectively similar to the market-making process), users can execute various market strategies by setting parameters such as order quantities, prices, and execution conditions for orders within each order book.

Sei's proprietary engine appears to be designed to facilitate such market strategies. Consequently, dApps on Sei that use this engine can easily leverage CLOB. For instance, even if CLOB is deployed on Sei within a DEX (Decentralized Exchange), Sei's order matching engine corresponds to the liquidity of each order book to various CLOB transactions. Unlike Serum, which requires three separate transactions to match and execute orders due to its distinct order book system, Sei can perform these tasks within a single block through the DEX module and hooks like EndBlocker within the mentioned engine. Furthermore, considering scenarios where these order books multiply extensively, Sei also offers order bundling functionality, allowing multiple order books to be updated in a single transaction. In essence, the necessity of a proprietary order matching engine as a foundational infrastructure to allow users to experience optimal prices, quantities, and execution times becomes evident.

2.2 Native Oracle

In the context of blockchain, an oracle is considered a challenging issue to address, alongside the trilemma, due to the synchronization problems between off-chain and on-chain data. Considering that oracle modules, which update information, are directly related to the "price" experienced by users during transaction processes, reflecting reliable information in the price is essential to achieve Sei's vision.

To address this, Sei provides its own oracle module at the network level. Other modules and contracts reference this oracle module, and it's worth briefly examining how this oracle module secures and provides trustworthy information. Fundamentally, validators participate not only in the consensus process but also as oracles. If any malicious behavior occurs within the oracle (such as sending absent or erroneous data), penalties are imposed on the respective validator. Validators can directly collect price information, or users who are not validators can collect and provide information to validators (feeding). In essence, even the decentralized oracle approach pursued by Chainlink, at its core, operates through consensus among validators and penalty mechanisms. Considering this, utilizing validators that are inherently aligned with the Sei network and its relationships to provide trustworthy information seems meaningful. However, imposing such a burden on validators could potentially drive network centralization. Nevertheless, the fact that there's also an implementation direction where entities other than validators bear this burden somewhat mitigates these concerns. In terms of decentralization, a deeper exploration will be undertaken in section 4 below.

2.3 Frontrunning Prevention: Frequent Batch Auctions (FBA)

Up to this point, we've examined Sei's infrastructure for accurately reflecting the user's intended price and quantity in a trade, two of the three elements of a trade. As the remaining element, the timing of the execution is closely related to scalability. Therefore, we will explore this aspect in section 3 below.

However, providing precise price information and preventing liquidity fragmentation alone doesn't offer users the optimal trading experience. The concept known as Maximal Extractable Value (MEV), which was highlighted in a 2019 paper, is now considered one of the culprits deteriorating the experience of ordinary blockchain users. MEV is extracted in various ways, and specific aspects of extraction are detailed in a previous article. In this context, we will examine the solution proposed by Sei to mitigate frontrunning, which is identified as negatively impacting user experience.

Frontrunning is a malicious MEV extraction technique that sorts and processes transactions to extract gains "prior" to the user after observing the user's transaction. As gains ultimately stem from price fluctuations, Sei has developed a system to prevent frontrunning by establishing batches that can provide the same price within a single block through its own order matching engine. This system is referred to as Frequent Batch Auctions (FBA), and let's explore how it provides consistent prices.

FBA aggregates all market orders at the end of a block and executes them at the same uniform clearing price. As previously mentioned, Sei's built-in order matching engine conducts order matching and execution within a single block, and FBA similarly utilizes this feature to execute market orders at the same price within a single block. Irrespective of the order in which trades occur, during the time of that block (about 500ms), everyone posting trades will obtain the same price. With this in mind, even if the transaction order is altered due to frontrunning, (1) the potential gains for MEV bots will likely disappear and (2) users will be able to execute trades without price fluctuations.

Let's consider a simple example with only two orders in the order book. Order A wants to sell tokens at $10, and order B wants to sell them at $12. If two different buyers appear in the order book, without FBA, the first buyer selects order A, buys tokens at $10, and the next buyer follows order B, purchasing tokens at $12. Depending on the sequence of buyers' entries, or the sorting order of transactions, users wanting to buy at the market price might incur losses. However, in a scenario where FBA is functioning, orders will be executed at the average price (P1 + P2) / 2 since a uniform clearing price is shared within a single block.

2.4 Summary

So far, we've looked at the approaches Sei has taken to provide a flexible trading experience. As mentioned, there's a deep consideration of how the blockchain, a decentralized infrastructure, can fully reflect the user's intent and experience regarding the essential components of a trade: price, quantity, and execution timing. Starting as a general-purpose app chain rather than a DApp on other chains, Sei seems to aim (1) to avoid resource competition with unrelated DApps and (2) to fully leverage the autonomy of its own design, such as the order matching engine and oracle.

However, to achieve Sei's goal of financial innovation and the best user experience, there remains a fundamental problem that needs to be addressed - scalability. Considering a trading environment comparable to centralized exchanges (CEX), achieving satisfactory scalability at a typical level may prove challenging to cater to the diverse layers of participants involved in trading, from regular traders to market makers. Moreover, due to the nature of most blockchain consensus algorithms where block creation and finality are separated, incomplete blocks hold no meaning from a trader's perspective. Therefore, there's a need to accelerate the time for finality. Yet, if there are frequent chain forks that compromise stability, there might be no reason to use such a platform. Thus, to achieve Sei's objectives, there are still many hurdles to overcome. Let's explore how they attempted to address these challenges in the section below.

3. How Sei Achieves Its Desired Scalability

First, let's examine the metrics related to scalability. When discussing scalability in the context of blockchain, Transaction Per Second (TPS) is commonly used. TPS is calculated by dividing the number of transactions in a block by the time it takes for the block to be created (in seconds). However, TPS is not a suitable metric for expressing blockchain scalability, as transactions ultimately need the block to be finalized. Therefore, an alternative metric to consider is Time To Finality (TTF), which represents the time it takes for transactions to be confirmed. Since finality, along with transaction creation, plays a crucial role in a user's financial trading experience, Sei aims to expedite the time to finality.

Sei has opted for the Tendermint BFT consensus algorithm, which prioritizes safety over liveness. As a result, it offers deterministic finality instead of probabilistic finality. Among existing blockchains, Sei boasts the fastest transaction finality of just 500ms, which is significantly faster compared to Ethereum (which takes 13-20 minutes for transaction finality), Solana (1-2 seconds), and Aptos (0.9 seconds). Let's delve into Sei's strategy for achieving rapid finality.

3.1 Twin Turbo Consensus

The Twin Turbo consensus is the most significant technological advancement that sets Sei apart. Sei's consensus algorithm combines two methods: Intelligent Block Propagation and Optimistic Block Processing, and this amalgamation is called Twin Turbo.

The diagram above illustrates the conventional block creation mechanism, highlighting two areas of optimization:

(1) Each validator has a mempool, and data for transactions already exists in these mempools. In essence, most validators already share data for the majority of transactions.

(2) The block consensus process involves proposal, validator voting, consensus, and propagation. In the above diagram, these processes are serialized, and if there are parts that can be parallelized, the process could become more efficient.

Sei's Twin Turbo consensus algorithm is designed based on these two considerations.

3.1.1 Intelligent Block Propagation

Let's begin by understanding Intelligent Block Propagation. In the conventional Tendermint consensus process, when a block proposer propagates a block to other validators, they send the entire transaction information within the block. This not only involves a significant amount of data but also involves redundant work, as other validators already have the same information in their mempools. Sei takes advantage of this by compressing the transactions into a hash value when the network's block proposer propagates the block. Validators who receive this hash can then compare it with the transactions in their mempools and reconstruct the block.

Recently, Sei discovered and fixed a bug in the Intelligent Block Propagation code. This resulted in a reduction in block time to 250ms. This effect brought a nearly 39% improvement over Sei's already fast finality. However, the overly fast block time introduced variability in block creation, as infrastructural players like validators and RPC nodes faced technical challenges in verifying transactions within such rapid block times. Sei adopted a more conservative approach to maintain network security, increasing the block time by 100ms to establish a faster yet more stable network.

3.1.2 Optimistic Block Processing

Working in tandem with Intelligent Block Propagation, Optimistic Block Processing is a modification of the existing Tendermint consensus process. The conventional block proposal occurs after the voting period. In this process, Tendermint executes BeginBlock, DeliverTx, EndBlock, and Commit alongside the content of the block proposal. This process can be illustrated as follows:

After a block is proposed, voting occurs through Prevote and Precommit stages, akin to a pre-voting concept. Subsequently, during the processing of the block's state changes, the block is processed, and finally, it is committed, leading to block creation. However, the serialization in the diagram above is not mandatory, and the processing information needed while processing a block is already available to validators during the Prevote stage. Hence, Sei parallelizes this process, compressing the block processing stage.

In this new approach, calling ProcessProposal before Prevote initiates asynchronous block processing, irrespective of voting. Once voting concludes and FinalizeBlock is called, it waits for block processing to finish and then commits, completing the block propagation process. This asynchronous approach to Sei's block propagation can lead to around 33% acceleration.

3.2 Transaction Parallelization

To increase the throughput of a blockchain, there are two main approaches: modifying consensus algorithms for faster agreement and improving the efficiency of transaction execution for higher processing capacity. In addition to the faster consensus algorithms mentioned earlier, Sei introduced parallel processing of transactions to enhance efficiency. Recent protocols like Aptos**,** Solana, and Sui have also introduced transaction parallel processing algorithms. Ethereum, on the other hand, plans to support parallel processing on Layer 2 solutions due to its Ethereum Virtual Machine (EVM) processing transactions serially.

By introducing transaction parallel processing, Sei achieved scalability to handle up to 8,000 transactions per second. However, processing all transactions in parallel can lead to "non-determinism" among validators. Nondeterminism refers to the phenomenon where running the same code multiple times does not yield the same result. It arises when different transactions need to be processed in a specific order. To prevent non-deterministic transaction execution, Sei modified the Cosmos SDK's serial processing. It gathers transactions that can be processed in parallel regardless of their order and process them concurrently. Transactions that cannot be processed in parallel are handled serially, similar to the existing system. "Order-agnostic" means that the transactions are not dependent on each other's order.

Sei constructs a Directed Acyclic Graph (DAG) to determine transaction dependencies. A DAG essentially represents dependencies with arrows. Transactions with arrows pointing to them are interdependent, indicating they need to be processed serially. Transactions without such arrows can be processed in parallel. As shown in the diagram above, compared to processing all transactions sequentially, processing transactions with interdependencies serially while processing others in parallel reduces the overall transaction processing time.

jsonCopy code
{
    "resource_dependencies": {
        "first_blue_read": [],
        "first_red_read": [chan_msg1_first_red_write],
        "first_red_write": [chan_msg1_second_red_read],
        "first_blue_write": [chan_msg1_first_blue_read]
    },
    "completion_signals": [
        chan_msg2_last_blue_read,
        chan_msg2_last_red_read,
        chan_msg2_red_write,
        chan_msg2_blue_write
    ]
}

This module is used to identify transaction dependencies. In simple terms, the "resource_dependencies" section indicates the dependencies before and after each transaction. For example, "first_blue_read" signals the transaction completion that corresponds to it when "chan_msg2_last_blue_read" is completed. Sequentially, "first_red_read" is executed after receiving the signal from "chan_msg2_red_write." When Sei's block proposal occurs, this module constructs a DAG of transaction dependencies and selects transactions that can be processed in parallel. By doing so, Sei achieves faster completion of all transactions.

In the pursuit of scalability, Sei's adoption of Twin Turbo consensus and transaction parallel processing stands out as significant technological innovations. However, scalability is not the sole criterion in blockchain. The three essential elements of a blockchain are scalability, decentralization, and security, known as the "blockchain trilemma." Achieving all three perfectly is challenging, so many blockchains prioritize two of these values according to their philosophy and make some sacrifices to attain the third. Sei has emphasized being "faster than anyone else" as its unique selling point. Equally important, Sei seeks to describe how it achieves decentralization and security, drawing from experiences on A41's Sei testnet.

4. Compromising Decentralization for Scalability: Efforts for Security

4.1 Balancing Decentralization with Scalability and Security

Sei's objective and philosophy revolve around providing users with a "fast and secure" chain that offers the best trading experience. Due to this focus, scalability and security take precedence over decentralization. Sei achieved scalability and even compressed block times and finality for the sake of its vision of innovation in finance. Furthermore, Sei implemented various mechanisms to provide traditional financial-level trading strategies and experiences on the blockchain infrastructure itself. However, as mentioned earlier, these scalability measures and mechanisms increase the burden on validators. In essence, the requirements for running a node as a Sei validator are quite demanding.

These high operational requirements serve as a barrier to entry for validator participation. Essentially, only entities with sufficient operational experience will participate in the network, potentially leading to centralization of validation. Nonetheless, Sei's network philosophy aims to provide the most convenient environment for users trading on its network. This, combined with the necessity for self-verified oracles and rapid block speeds, inevitably makes the role of validators more substantial. Therefore, it is essential to explore how Sei's efforts address decentralization in this context.

4.2 Ensuring Decentralization

According to a Messari report on evaluating validator decentralization, operational decentralization can be assessed from three perspectives: node software, hosting infrastructure, and geographic distribution. Node software refers to the client program used to operate a node. If all validators use the same program and it has vulnerabilities, it poses a risk to decentralization. Hosting infrastructure and geographic distribution, on the other hand, can lead to political, social, and economic centralization, even if the software itself is sound.

In this context, validators play a pivotal role in securing decentralization in terms of hosting infrastructure and geographic distribution. Achieving operational decentralization involves the validators' decisions. Without considering distribution in hosting infrastructure and geographic locations, single points of failure can occur.

4.3 Sei Foundation and Validator Efforts for Decentralization

Considering Sei's scalability efforts, including block times and finality, even network latency becomes a significant obstacle. Network delays are primarily linked to the physical distances in the network's underlying fiber optic connections. Block times, often measured in milliseconds, can be influenced by these distances. Let's delve into real-world examples.

The Round Trip Time (RTT) between a node in Germany and a node in Miami is over 100ms, whereas RTT between nodes within Europe is around 25-35ms. With Sei's requirement to participate in millisecond-level consensus, validators naturally choose regions and cloud service providers with lower network latency. However, if all validators only choose the options that favor their network participation, the physical node locations would become centralized, leading to single points of failure.

The Sei Foundation recognizes this issue and actively supports validators in moving their nodes to diverse regions and service providers. During this decentralization process, they monitored the potential performance degradation and ensured that validators' profitability would not suffer. In response, validators experimented with and shared results of using various regions and cloud services, contributing to network decentralization improvement. Gradually, this collaborative effort led to a situation where nodes are distributed across different cloud services and countries, alleviating the issue of single points of failure.

5. Conclusion

This article provided an overview of Sei's vision to achieve unparalleled scalability and finality among existing blockchains. We explored the thought process behind achieving this vision, the technical innovations, and the experiences of validators. Moreover, we discussed the Sei Foundation's and validators' efforts to achieve decentralization, an essential value in the blockchain space.

Sei has taken the first step toward Nasdaq's decentralization and ushered in true financial innovation. This journey has involved substantial infrastructure development, scalability efforts, and contributions from the Sei Foundation and validators to ensure the preservation of decentralization values. As we conclude, we hope that Sei's efforts will leave a lasting mark on the blockchain ecosystem, leading the way for new mass adoption.