Since the creation of Bitcoin in 2009, cryptocurrencies have revolutionized financial systems. Decentralized exchanges (DEXes) have become popular, but they face challenges such as scalability and latency. In this context, Sei offers a specialized solution for crypto trading.
Introduction to Sei Network
🔹 Origin and Specifics of Sei Network
@SeiNetwork is a layer 1 blockchain specialized in decentralized trading, developed on Cosmos. It addresses the challenges of DEXs such as scalability and security by focusing exclusively on crypto trading.
🔹 Objective of Sei Network in the Context of DEXs
As you know, decentralized exchanges play a significant role in the ecosystem by providing alternatives to CEXs. However, DEXs face significant limitations that hinder their widespread adoption.
Sei Network aims to address these challenges by providing an infrastructure optimized for DEXs. By optimizing every aspect of its blockchain for crypto trading, Sei Network aims to offer a seamless, secure, and efficient decentralized trading experience.
Technical Operation of Sei Network
🔹 Architecture of Sei Network
Sei Network is built on an architecture optimized to meet the specific needs of crypto trading. As a layer 1 blockchain, it utilizes the Cosmos SDK framework and Tendermint Core while bringing specific optimizations for decentralized trading. One of the primary optimizations is its Twin Turbo consensus. But Sei doesn’t stop there; this blockchain also employs parallelization. Don’t worry; we’ll explain what that is in full detail.
🔹 Information : The Cosmos SDK is a toolbox for blockchain developers. It consists of pre-built, modular components. For example, one of the SDK modules allows implementing token transfers within a network with a simple copy-paste operation. In essence, it’s a development kit for blockchains.
🔹 Twin Turbo Consensus and Its Operation
The Twin Turbo consensus forms the core of Sei Network’s mechanics. Thanks to its intelligent block propagation mechanism, it offers minimal latency and high scalability, allowing transactions to be finalized in just 380 ms and achieving 12,500 TPS. That’s just enormous; for comparison, Sei is 5x faster than Solana.
This consensus operates through intelligent block propagation and optimistic transaction processing, ensuring optimal execution speed.
Here’s how the Twin Turbo mechanism works on Sei:
- Transaction reception and dissemination: When a node receives a transaction, it broadcasts it to other nodes in the network.
- Verification and addition to the mempool: The validator that receives the transaction verifies it for validity, then adds it to its mempool, which is a local buffer memory. (Local buffer memory = a temporary storage area)
ℹ️ Information : We are interrupting this explanation to quickly explain what a mempool is:
A mempool is a virtual queue where transactions awaiting validation by the network are temporarily stored. When someone sends cryptocurrencies to someone else, that transaction is first added to the mempool. Network validators then choose transactions from the mempool to include in the next block to be added to the blockchain, based on various factors such as transaction fees. Once a transaction is included in a block and added to the blockchain, it’s considered confirmed.
- Block Proposal: Validators examine the current state of their mempool and propose a block containing the unique identifiers of transactions in the mempool, along with a reference to the complete block.
- Block Proposal Propagation: The block proposal is sent to other validators in the network. The complete block is also propagated, but it’s divided into several parts to facilitate transmission.
- Block Reconstruction: If a validator has all the transactions from the proposal in its own mempool, it can reconstruct the entire block from it, saving time. Otherwise, the validator must wait for all parts of the complete block to arrive to construct the block.
- Consensus on Transaction Order: Once all validators have received all transactions, they can agree on the order in which these transactions will be included in the block, following the Tendermint consensus.
⚠️ Disclaimer: The continuation on the Twin Turbo consensus is very technical and may be challenging to understand for someone not very tech-savvy. The main points about Twin Turbo for beginners have already been mentioned above.
➮ How Does Twin Turbo Work in Practice? Intelligent Block Propagation
Firstly, when a full node receives a transaction from a user, it must broadcast this transaction to other nodes in the network. Full nodes will randomly broadcast this transaction to other nodes in the network. Once a transaction is received by a validator, it verifies the validity of the transaction and adds it to its local buffer.
Following this, block proposers will examine the current state of their buffer and propose a block to be validated from among all those in their buffer.
As most, if not all, transactions will have already been received by validators through the transaction broadcasting approach mentioned above, proposers will include unique transaction identifiers in the block proposal, along with a reference to the complete block.
Next, block proposers will broadcast the proposal to other validators in the network, followed by the entire block (containing the complete content of each transaction).
The proposal will be sent as a single message, while the entire block will be split into parts and broadcasted across the network.
Now, two scenarios open up for validators:
• 1st scenario: If a validator has all the transactions from the proposal in its local buffer, it will reconstruct the entire block from its buffer rather than waiting for all parts of the block to arrive.
• 2nd scenario: If it does not have all the transactions, it will wait to receive all parts of the block from the network and construct the block with all its transactions.
This process significantly reduces the overall waiting time for a validator to receive a block.
Once validators have all the transactions that are part of the block proposal, they will follow the Tendermint BFT consensus² (from Cosmos) to agree on the ordering of transactions. In particular, there will be a pre-vote stage, a pre-commit stage, and a commit stage before the block and associated state changes are validated on the blockchain. (We’ll revisit these two stages a little later).
➮ Optimistic Block Processing
For the Tendermint consensus, validators will receive a block proposal, verify the validity of the block, and then proceed to the pre-vote stages. Rather than waiting after the pre-commit stage to begin processing transactions (Image “a” below), validators will initiate a process where they competitively handle optimistically the first block proposal they receive for a given height (Image “b” below) while awaiting the pre-commit stage.
Optimistic block processing will write the candidate into a cache. If this block is accepted by the network, then the cache data will be validated. If the network rejects the block, then the cache data will be discarded, and future cycles for that height will not utilize optimistic block processing. The theoretical latency improvement due to optimistic block processing is given by this mathematical formula:
min(Tprevote + Tprecommit, N * T)
Where Tprevote is the pre-vote latency time, Tprecommit is the pre-commit latency, N is the number of transactions, and T is the average latency of a single transaction. In essence, we take the minimum between: the Tprevote + Tprecommit and the number of transactions × the average latency of a single transaction.
🔹 Transaction Processing Parallelization
To further increase its processing speed, Sei Network has introduced transaction processing parallelization. This approach allows for multiple transactions to be processed simultaneously, thereby enhancing the overall efficiency and speed of the blockchain.
ℹ️ Information : If you’re wondering, “What is transaction parallelization in the context of a blockchain?” read on:
Parallelization in a blockchain, also known as parallel execution, is a technique that allows multiple transactions to be processed simultaneously instead of sequentially, one after the other. This significantly enhances transaction speed and blockchain network scalability.
In simpler terms: Think of a blockchain like a highway with cars (transactions) traveling on it. In a regular highway, cars must follow a single lane and wait their turn to move forward. This can cause traffic jams when there are many cars on the road.
Now, imagine a highway with multiple lanes, where cars can move forward simultaneously in different lanes without hindering each other. Each lane represents a parallel process in a blockchain. Cars can move faster, and there’s less risk of congestion because more lanes are available for traffic.
In the context of blockchain, parallelization allows multiple transactions to be processed simultaneously across different “lanes” (like lanes on a highway), speeding up the overall process and reducing waiting times. However, just like on a highway, it’s important to manage traffic to avoid accidents (transaction conflicts) and maintain smooth traffic flow (data integrity and decentralization).
Here’s a simplified explanation of what this entails:
- Identification of independent transactions: The system first identifies which transactions can be processed independently, meaning those that do not interact with the same data or states. For example, if two transactions affect different smart contracts, they can be executed in parallel because they don’t overlap.
- Simultaneous execution: Once independent transactions are identified, they are executed simultaneously across different network nodes. This means multiple nodes can work on different transactions at the same time, thereby accelerating the overall process.
- Management of dependencies and conflicts: The system must also manage dependencies and potential conflicts between transactions. For instance, if two transactions attempt to modify the same data simultaneously, there may be a conflict. The system must be able to resolve these conflicts effectively to maintain data integrity.
However, while parallelization offers many benefits, it also comes with drawbacks. For instance, the simultaneous coordination of multiple transactions can be complex and require more network resources. Additionally, it may potentially compromise the decentralization of the blockchain if coordination isn’t managed properly.
➮ Parallelization
Sei utilizes Cosmos SDK as the foundation for application logic. Within this logic, when validators receive a block and begin processing it to update the network state, they initially execute the BeginBlock logic, followed by the DeliverTx logic, and then the EndBlock logic (see “ℹ️ Information” below to understand what this is). Each of these steps is fully configurable, and Sei has configured DeliverTx and EndBlock to parallelize transaction processing, as depicted in the image below (the first diagram shows a situation without parallelization, and the second one below illustrates parallelization used by Sei).
ℹ️ Information :
➮ What is BeginBlock
In a blockchain (built on Cosmos), BeginBlock is a function or mechanism used within the consensus to mark the beginning of validating a new block. This function is typically invoked at the start of the block validation process.
BeginBlock can be used to perform various actions at the beginning of block validation. These actions may include:
• Variable initialization: BeginBlock can be used to initialize specific variables or states necessary for block validation. For example, this could include initializing a counter to track the number of transactions in the block being validated.
• Checking prerequisites: BeginBlock can be used to check prerequisites necessary for block validation. This could include checking for the availability of necessary resources, such as computing power or tokens required to validate the block.
• Updating network parameters: BeginBlock can also be used to update network parameters at the beginning of validating a new block. This could include updating governance rules or consensus parameters based on decisions made by network participants.
• Managing pending transactions: BeginBlock can be used to manage pending transactions and prepare the block for validation. This could include selecting transactions to include in the block being validated.
➮ What is DeliverTx
DeliverTx refers to a function or specific step in the transaction validation process within a blockchain node.
When a transaction is submitted to a blockchain node, it goes through several validation steps to ensure it is correct and legitimate. One of these steps is DeliverTx.
DeliverTx is typically responsible for:
• Checking the syntax validity of the transaction: This involves verifying that the transaction is well-formed and adheres to the rules defined by the blockchain protocol.
• Checking the semantic validity of the transaction: This involves verifying that the transaction complies with business rules or constraints specific to the blockchain. For example, in a cryptocurrency blockchain, DeliverTx would verify that the sender has sufficient funds to perform the transaction.
• Updating the blockchain state: If the transaction is valid, DeliverTx is responsible for updating the blockchain state accordingly. This may include adding new blocks to the chain, updating account balances, or any other necessary modifications to reflect the transaction in the current state of the blockchain. In short: DeliverTx = transaction processing process.
➮ What is EndBlock
EndBlock is a function or mechanism used within the consensus to mark the end of a particular block. This function is typically invoked at the end of validating each block in the consensus process.
EndBlock can be used to perform various actions once a block is validated. These actions may include:
• Miner rewards: In blockchains that use a proof-of-work (PoW) or proof-of-stake (PoS) mechanism, EndBlock can be used to distribute rewards to miners or validators who participated in validating the block.
• Updating network parameters: EndBlock can also be used to update network parameters, such as governance rules or consensus parameters, based on decisions made by network participants.
• Fee collection: Some blockchains may collect transaction fees on each block. EndBlock can be used to collect these fees and distribute them according to the rules defined by the protocol.
• Execution of smart contracts: If the blockchain supports smart contracts, EndBlock can be used to execute specific smart contracts at the end of each block.
➮ These are all features/steps that can be tinkered with to optimize the performance of a blockchain built on Cosmos (@cosmos).
Sei initially processes all transactions within a block during the DeliverTx phase. This results in state changes for most types of transactions (token transfers, governance proposals, smart contract invocations, etc.).
However, transactions related to the order matching engine undergo only basic processing during the DeliverTx phase, and most of their state changes are applied during the EndBlock logic. This facilitates frequent batch auctions, where orders are grouped, and a uniform clearing price is calculated for execution. Sei has added parallelism to both DeliverTx and EndBlock for optimal performance (most blockchains parallelize only the DeliverTx part).
➮ Parallelization of DeliverTx Transactions
Instead of processing transactions sequentially during DeliverTx, Sei processes transactions in parallel. This allows for multiple transactions to be processed simultaneously, leading to improved performance. Sei’s data is stored in a key-value data store. To avoid race conditions and non-determinism (essentially ensuring no dependencies and conflicts), Sei must ensure that multiple parallel processes do not update the same key.
This works by maintaining a list of transaction message types and the keys they need to access (referred to as a “dependency mapping”). Messages that update different keys can be executed in parallel, but messages updating the same key must be executed sequentially and in a deterministic order (the order is determined by the transaction ordering within the block).
ℹ️ Information : we are providing the definition of mapping because you’ll need it for the following:
In this context, “mapping” refers to a correspondence or association between different elements. More specifically, it involves associating transaction message types with specific keys that these messages need to access. This association determines how each type of message affects the data stored in the system. Thus, the “dependency mapping” indicates which resources each transaction message uses and whether there are dependencies between them that require sequential or parallel processing.
In simpler terms, “mapping” refers to a kind of table or correspondence that indicates what action should be taken for each type of transaction message. This helps to understand which parts of the system are involved in each transaction and whether some should be processed one after the other or simultaneously. In other words, it’s like a guide telling the system how to handle each type of transaction.
Before executing transactions for a block, all dependencies between transactions are identified by constructing a Directed Acyclic Graph (DAG) of dependencies between the various resources that each message in each transaction needs to access.
Let’s take a simple example with a module X. All messages concerning this module update a shared key called ABC. Therefore, all these messages must be processed sequentially in the same part of the DAG.
In many cases, message content is necessary to offer additional parallelism. For example, token transfers from account A to B and from account C to D can be executed in parallel because they update different keys (there is no link between A, B, and C, D). However, defining only the mapping based on message type (and ignoring message content) would result in the sequential execution of these two transfers.
To make this more flexible, dependency mappings can be considered as predefined templates that are adjusted with specific details when used. For example, in the case of a token transfer, the sender and recipient accounts are integrated into the template to allow for more precise and efficient management.
For message types defined by the blockchain (such as delegation, oracle updates, bank transfers, etc.), mappings are established at the launch of the blockchain and can be adjusted through a governance proposal process. There is a particular situation for gas fees, which apply to each transaction. This is managed by temporarily storing data in a memory location, which is emptied at the end of the transaction processing process (DeliverTx).
For message types created by developers building on Sei, smart contracts must specify their own resource dependencies. These dependencies are established during contract initialization and can be adjusted by the contract administrator through update transactions. If these dependencies are properly defined, smart contracts can benefit from parallelism and pay lower gas fees. Conversely, in the absence of defined dependencies, smart contracts will operate sequentially, thereby blocking other transactions (because, as a reminder, two transactions that are interrelated cannot be executed in parallel; they are required to run “one after the other”). This forces transactions to these smart contracts to pay higher gas fees as they block the rest of the network. If the dependencies of a particular smart contract are incorrectly specified, transactions for that contract will fail and result in higher gas fees. However, this will not affect the network as a whole, and other transactions will still be processed successfully.
🔹 The Central Limit Order Book (CLOB)
A key element of Sei Network’s architecture is the Central Limit Order Book (CLOB), a decentralized version of order books used by all DApps built on the Sei blockchain. The CLOB helps avoid the capital inefficiencies inherent in Automated Market Makers (AMMs), thus providing better liquidity and trading experience.
ℹ️ Information : A crypto Order Book is essentially an electronic ledger that displays all buy and sell orders for a pair of currencies or digital assets. On the buy side, it shows how much currency a person is willing to buy at a certain price, while on the sell side, it indicates how much currency is offered for sale at a given price. By viewing the Order Book, traders can get an idea of the current demand and supply in the market.
🔹 Native Oracles
Sei Network utilizes its own native oracles to determine token exchange rates. Validators act as oracles to ensure accuracy and reliability of cryptocurrency pair prices. This mechanism allows for quick price updates and ensures transparency in the process.
On Sei, each validator must contribute by providing prices for authorized assets, which are then aggregated together, and an average exchange rate is calculated. Validators must avoid penalties by actively participating and providing accurate data. If you prefer to use a different account than that of your validator to provide prices, you can set it up by defining a “feeder” for your validator. This ensures that the oracle remains reliable and exchanges proceed smoothly.
Creation and Operation of DEX on Sei Network
🔹 Native Order Matching Engine
Sei Network offers a native engine specially designed for order matching, providing an efficient and secure solution for DEX creation. This engine allows each DEX developed on the Sei blockchain to deploy its own Central Limit Order Book (CLOB), thereby facilitating the decentralized trading process.
🔹 Order Lifecycle on Sei Network
On Sei Network, the order lifecycle is structured to ensure swift and efficient execution. All transactions related to a CLOB, including order placement, execution, and settlement, are processed within a single block. This process ensures seamless and transparent order management, enabling users to enjoy an optimal decentralized trading experience.
🔹 Trading Fees on Sei Network DEX
At launch, Sei Network’s engine does not impose any trading fees. However, governance has the option to implement trading fees in the future. DEXs built on Sei Network are free to apply trading fees as they see fit, offering users a variety of options based on their preferences and needs.
Role of the SEI token
🔹 Utilities of the SEI Token
The $SEI token plays several roles within the Sei Network ecosystem, offering various functionalities and benefits to holders. Among its primary utilities are:
• Network security through staking: SEI holders can participate in staking to secure the network by locking a certain amount of $SEI tokens and validating transactions.
• Payment of transaction fees: $SEI is used as a means of payment for transaction fees on the Sei Network blockchain, ensuring the smooth operation of the network.
• Participation in governance: $SEI holders have the right to participate in Sei Network’s governance decisions by voting on change proposals and protocol upgrades.
• Rewards and grants: $SEI can be used to distribute grants and rewards to users and contributors who actively participate in the development and improvement of the Sei Network ecosystem.
🔹 Mechanism for Distribution and Reserve of the SEI Token
The $SEI token is gradually issued over time according to a predefined mechanism. Currently, only 22% of the tokens are in circulation, with the remainder reserved for:
• Staking rewards • Incentives to participate in the ecosystem • Airdrops and incentive testnets
🔹 Tokenomics
➮ We will provide you with the pie chart showing the distribution of $SEI tokens.
➮ We will also provide a link for you to visit Token Unlock (an application providing extensive information on tokenomics, including token releases): Token Unlock – Sei Network
As shown in the graph, we’re not yet in the major release period. During this period, there will likely be consistent selling pressure on $SEI as private investors begin to receive their tokens.
➮ We are also providing a link to CryptoRank (which is also an application providing extensive information on tokenomics and focusing on vesting, statistics on private investors, etc.): CryptoRank – Sei Network
History, Team, and Investors of Sei Network
🔹 Genesis and Team behind Sei Network
Sei Network is the result of collaboration among a diverse and experienced team from various backgrounds and renowned companies. The project came to fruition in 2022 when professionals from companies such as Robinhood, Google, Databricks, Goldman Sachs, and Nvidia pooled their skills to found Sei Labs, the startup behind the Sei Network blockchain.
The Sei Labs team, although not extensively documented in available sources, comprises high-level talent in areas such as software development, finance, blockchain, and project management. Among the key team members are likely experienced blockchain developers, cybersecurity experts, and marketing and communications specialists.
🔹 Fundraising and Investors of Sei Network
The fundraising efforts of Sei Network have occurred in multiple stages, enabling the startup to finance its development and growth activities. Here’s an overview of the main fundraising rounds and involved investors:
• In August 2022, Sei Labs completed a $5 million fundraising round. Participating investors included names such as Coinbase Ventures, Delphi Digital, Hudson River Trading, GSR, Hypersphere, Flow Traders, and Kronos Research.
• In April 2023, Sei Network successfully raised $30 million in a new funding phase. Investors in this fundraising round included Distributed Global, Multicoin, Asymmetric, Flow Traders, Hypersphere, Bixin Ventures, and OKX Venture.
• In April 2023, a third fundraising round was conducted, this time raising $50 million. Among the investors involved in this financing phase were Bitget and Foresight Venture.
• These successive fundraising rounds have allowed Sei Network to secure significant financial resources to support its development and expansion. They have also bolstered the project’s credibility and legitimacy in the eyes of the crypto community and institutional investors.
Ecosystem, Community, and Roadmap
🔹 Current State of the Ecosystem
Regarding the ecosystem, we will be quite critical.
On Sei, there aren’t many dApps built yet. We advise you to check the available dApps on Sei here: https://sei.io/ecosystem.
In terms of Total Value Locked (TVL), it’s also concerning. According to DeFiLlama, as of the time of writing, we have a TVL of $20.97 million, which is very low and puts Sei in the Top 60 blockchains by TVL on DeFiLlama. The dApp with the highest TVL is Astroport (a dApp shared across the Cosmos ecosystem).
Additionally, we expected to find more dApps built solely on Sei (native dApps) since Sei is not EVM and specializes in DEXs. However, as the screenshot below shows, there aren’t many.
Sei has an excuse: The @SeiNetwork blockchain is still very young.
🔹 Community Engagement
In terms of community engagement, we had a dubious airdrop of a very small portion of tokens for users. To make up for it, Sei has implemented an engagement system where users can complete tasks in exchange for rewards. This mainly revolves around “ranks” and is called the Sei Marines. Here are the ranks:
🚢 Sei Crew
🚢 Sei Officer
🚢 Sei Captain
🚢 Sei Major
🚢 Sei Colonel
The rewards associated with this incentive program can range up to a full-time job in Web3.
🔹 Roadmap
Overall, the future of Sei Network looks promising, with a rapidly expanding and dynamic ecosystem and an engaged community ready to support continued growth and innovation in the blockchain space.
Regarding the roadmap: the next major change on Sei is Sei V2. This update is expected to make Sei compatible with the EVM.
Sei v2, a true revolution
🔹 EVM Compatibility and Transaction Parallelization
Sei v2 is a major update to the Sei protocol aimed at making the blockchain compatible with the Ethereum Virtual Machine (EVM). This means that smart contracts written for Ethereum can now be executed on the Sei blockchain without requiring any code modifications (currently, smart contracts on Sei are written in Rust). Additionally, Sei v2 introduces transaction parallelization for the EVM, allowing multiple transactions to be executed simultaneously, thereby enhancing network performance.
🔹 SeiDB
SeiDB is an enhancement to the storage layer of the Sei blockchain. This improvement aims to enhance the read and write performance of the network’s state, making data read and write operations on the blockchain faster and more efficient. Furthermore, SeiDB will facilitate new nodes’ synchronization with the network, making the adoption of the Sei blockchain easier for new users.
🔹 Improved Performance
With these updates, Sei v2 will offer improved performance compared to the previous version. Transaction processing capacity will be significantly increased, with a capacity of 28,300 transactions per second. There will also be an increase in execution speed, meaning transactions will be confirmed and finalized more quickly on the Sei v2 network.
🔹 Technical Changes
On the technical front, Sei v2 brings significant changes to the blockchain’s execution layer. These changes enable support for transaction parallelization on the EVM network and optimize the storage of the network’s state. Additionally, a new component is introduced to support EVM smart contracts, enabling smooth interaction between EVM smart contracts and existing smart contracts on the Sei blockchain.
As you know, EVM-compatible networks form the largest blockchain network currently. By becoming EVM-compatible, Sei will benefit from this network. For example, thanks to EVM compatibility, smart contracts written in Solidity on Ethereum can be “copy-pasted” onto Sei. We could see major dApps from EVM networks coming to Sei, such as Aave, Curve, Uniswap, and more. This could be a major turning point for this blockchain and could bring the liquidity that is currently lacking, as seen in the section: “Ecosystem, Community, and Roadmap.”
ℹ️ Information : If you’re wondering, “What in the world is the EVM?” then read on: 👇
EVM stands for “Ethereum Virtual Machine.” It’s a key component of Ethereum technology. The EVM is an execution environment that allows smart contracts to run on the Ethereum network and all other EVM-compatible chains.
Smart contracts on Ethereum are written in programming languages like Solidity, then compiled into bytecode that is executed by the EVM. The EVM is designed to be a Turing-complete virtual machine, meaning it can execute any algorithm or program.
The EVM ensures the consistency and security of smart contract execution by applying the consensus rules defined by the Ethereum protocol. Every node in the Ethereum network runs a copy of the EVM to validate and execute transactions and smart contracts on the Ethereum blockchain.
In summary, Sei Network is a blockchain specialized in decentralized exchanges (DEX), providing an optimized infrastructure for cryptocurrency trading. With innovations like the Twin-Turbo consensus, Sei aims to overcome scalability and latency challenges to offer fast and efficient transactions. With its high performance, transaction parallelization, and commitment to decentralized trading optimization, Sei Network could play a major role in shaping the evolution of the crypto ecosystem.
Related Posts
The Incredible Story of SlumDOGE MILLIONNAIRE
NEAR Protocol: Diving into the Heart of a Dapp-Centric Blockchain
