The market has become completely desensitized to "high-speed public chains", so why might Somnia be different?

This article will analyze the following two questions:

Question 1: The market has become completely desensitized to "high-speed public chains", so why is Somnia different?

Question 2: Is Somnia exaggerating by claiming to be the fastest and most cost-effective parallel EVM Layer 1?

➡️➡️➡️ Simple version⬅️⬅️⬅️

This section summarizes Somnia from three dimensions: technology, background, and ecology, so that everyone can understand the highlights and advantages of the Somnia project.

?Somnia's technical highlights

?Multi-stream consensus algorithm: data chain + consensus chain, which is conducive to preventing MEV, reducing redundancy, reducing costs and increasing efficiency.

?Innovative EVM compiler: Implement instruction-level parallel EVM to solve high-frequency interactions in extreme cases.

?Self-developed IceDB database engine: improves data reading and writing speed and network stability.

?Data compression technology: improve data transmission efficiency.

?Somnia's background advantage

?Team: The development team comes from Improbable, a multinational technology company founded in 2012 and headquartered in London, UK. It has developed software, games, and Web3 metaverse products.

? Financing: MSquared, a16z, SoftBank, Mirana and other well-known institutions invested a total of US$270 million.

?Somnia's Ecological Progress

?Ecosystem: Somnia testnet has hosted 4 AI/social products, 7 games, 4 NFT projects and 6 Defi applications. Another 2 AI/social products, 11 games and 1 Defi application are about to be launched.

?Ecosystem data: From the launch in late February 2025 to the time of writing this article (June 26, 2025), the Somnia test network has produced more than 100 million blocks, with an average production time of 0.1 seconds per block. A total of 96,878,557 wallet addresses participated in the test network, and the transaction volume in the last day was 26.43 million.

On the block browser, you can often see the number of transactions and blocks flashing continuously. Somnia calls it "sub-second" and visible to the naked eye.

?Why might Somnia be different?

?High-frequency interaction: Although the market has completely become desensitized to the concept of "high-speed public chain", Somnia does not just pursue technical indicators, but focuses on how to make Web3 technology truly serve application scenarios, especially in high-frequency related interaction fields such as games and social networking.

?Web3 and Web3 integration: Somnia's unique background may play a key role in the integration of Web3 and Web2. Somnia has the potential to provide Web2 users with a seamless channel into the Web3 world, which may bring about a truly user experience-centric application ecosystem.

➡️➡️➡️ Detailed explanation version⬅️⬅️⬅️

The previous part introduced [WHAT] Somnia's highlights, advantages and ecological progress. This part will provide an in-depth interpretation of Somnia's technology, so that everyone can understand [HOW] how Somnia achieves high-frequency interaction in technology, how to achieve low cost and high performance, and [WHY] why Somnia is different from other parallel EVM projects.

?Multi-stream consensus algorithm: data chain + consensus chain

?Overview: Data chain + consensus chain structure

Somnia uses a new multi-stream consensus (MULTISTREAM) algorithm.

The so-called multi-stream means that Somnia records transaction information on multiple data chains. Each data chain is recorded by one validator, and each validator cannot interfere with the data chains of other validators.

Somnia executes consensus on the consensus chain, sorts transactions, and records references to transactions on the consensus chain. The consensus chain is jointly executed and maintained by all validators.

?Overview: Somnia multi-stream consensus workflow

a After a user sends a request to the Somnia network, the validator that receives the request writes the transaction into the data chain separately.

b. Every time period (e.g. 30 seconds, 1 second, etc.) of the consensus chain, the validators of the data chain upload and download the data shards at the top of the data chain with other validators of the data chain.

C validator writes the set of data shards at the top of all data chains into the consensus chain as a complete data slice.

d. The validator sorts the transactions, updates the status according to the sorted transactions, and all validators synchronously write to Somnia’s IceDB database.

?Highlights: Somnia’s transaction ordering is beneficial for preventing MEV

Somnia uses a deterministic pseudo-random function to sort transactions.

We know that there is no real randomness in the computing program, but pseudo-randomness achieved through algorithms. Deterministic pseudo-random functions have two characteristics: First, randomness. It is impossible to predict what the next random number generated will be, but each verifier will generate the same random number in a fixed order when executing.

In this way, all validators run the same deterministic pseudo-random function, which will generate a series of identical random numbers and sort the data chain according to the random numbers. On this basis, the transactions in this cycle are sorted.

For example, the sorted data chain is B, A, C...

Then the transaction order is that the transactions in data chain B come first, followed by data chain A, data chain C... Of course, this process will remove duplicate transactions based on the hash value.

Of course, the order of data chains is fixed, but the order of transactions in different data chains may be different. For example, in data chain A, transaction 1 may be in front and transaction 2 may be in the back, while in data chain B, transaction 2 may be in front and transaction 1 may be in the back. Since the order of data chains is B before A, the final transaction order is transaction 2 in front and transaction 1 in the back.

The advantage of this sorting method is that it is difficult for a MEV attacker to bribe a validator because he does not know how the data chain corresponding to the validator will be sorted. If there are 100 validator nodes on the network, even if a MEV attacker bribes 50 validators, as long as there is a validator that has not been bribed (and contains the attacked transaction) that is ranked ahead of these 50 validators, the consensus chain will record the transactions in the correct order, and the MEV attack will fail.

?Highlights: Reduce redundancy, reduce costs and increase efficiency

On the one hand, each Somnia validator records a data chain separately, and there is no data verification process between validators. When transmitting snapshots, only the snapshot information of each data chain is transmitted, and the snapshot information does not include specific transaction information, thus reducing the redundancy of interaction.

On the other hand, each Somnia data chain does not need to synchronize information with other data chains, and the consensus chain does not record transaction information. Instead, it records data chain information snapshots and sorted transaction references (hash values) every other period of time. This reduces storage redundancy.

Since redundancy in interactions is reduced, Somnia can be more efficient when working.

Since storage redundancy is reduced, Somnia requires less cost to work.

?Additional information: Anti-tampering of data chain

Although there is no information verification on the data chain, the verifier cannot tamper with the transaction information. Once the verifier tampers with the transaction information, it will affect the hash value of the transaction and the hash value of its subsequent transactions, causing its information to conflict with the information stored in the consensus chain.

?Instruction-level parallel EVM

?Pain point: Parallel transactions are difficult to improve the congestion of high-frequency interactions

Somnia's parallel EVM is different from Monad and Reddio. The EVM parallelism of these three chains is transaction parallelism, that is, transactions are carried out in parallel, thereby increasing the transaction speed.

Monad optimistically allows transactions to run in parallel, and corrects conflicts when they are detected, while Reddio runs transactions in parallel that do not conflict and have no dependencies.

However, when a large number of related transactions appear, transactions cannot be processed in parallel, so congestion is likely to occur. There are two extreme examples, such as a large number of users suddenly appearing on the network using USDC to trade a certain token. Because these transactions have to be traded with the LP pool, they cannot be processed in parallel and can only be executed sequentially.

Another extreme example is that countless people are rushing to mint the same NFT, which also cannot be done in parallel because the number of NFTs is limited and must be executed sequentially to determine who can successfully mint and others fail.

Reddio solves this problem by using GPUs, which can take advantage of their powerful computing power to resolve the congestion caused by high-frequency interactions. Although this can improve transaction efficiency, it also increases transaction costs.

?Highlights: Instruction-level parallel EVM

In order to solve the congestion problem caused by a large number of related transactions being carried out simultaneously and which is difficult to solve with parallel transactions, Somnia innovatively developed an EVM compiler.

In the standard EVM execution process, the instructions in the transaction can only be interpreted and executed one by one in sequence. However, Somnia supports splitting transactions into several instruction sets, and non-conflicting and non-dependent instruction sets can be executed in parallel.

Taking Swap transactions as an example, they can be divided into several instruction sets according to their functions: parameter verification, parameter processing, balance check, authorization check, pool status check, price calculation, fee calculation, transfer of input tokens, update of pool status and fee records, transfer of output tokens, and event emission. Among them, instruction sets that do not conflict and have no dependencies can be executed in parallel, thereby improving the execution efficiency of transactions.

The key to the instruction set parallel EVM is Somnia's original EVM compiler, which compiles the EVM bytecode into x86 machine code. Modern CPUs are multi-threaded cores, and each CPU core can parallelize machine code on multiple threads, so several instruction sets of EVM can be parallelized to increase the execution speed of a single transaction. Therefore, Somnia can also be called a hardware-level parallel EVM.

?Highlights: Dual advantages of cost and efficiency

Standard EVM interpretation and execution: Transaction 1 → Parse into bytecode → Sequential interpretation and execution → Transaction 2 → Parse into bytecode → Sequential interpretation and execution → Transaction 3 → Parse into bytecode → Sequential interpretation and execution…

Somnia's EVM compilation and execution: contract code → parsed into bytecode → dynamically compiled into machine code → parallel execution of transaction 1's instruction set → parallel execution of transaction 2's instruction set → parallel execution of transaction 3's instruction set...

From the comparison, we can see that the more transactions there are, the more advantages Somnia's EVM compilation and execution has.

Therefore, for ordinary non-high-frequency transactions, Somnia still uses the standard EVM interpretation and execution. Each time the EVM is executed, the smart contract code is parsed into EVM bytecode and then interpreted and executed in sequence.

For centralized high-frequency transactions, Somnia uses the EVM compiler to compile the EVM bytecode into x86 machine code. Then, the machine code is repeatedly executed according to the parameters to quickly complete centralized high-frequency transactions, which is an effect that transaction-level parallel EVM cannot achieve.

Therefore, Somnia can achieve dual advantages between cost and efficiency.

?IceDB database engine

?Overview: Use LSM tree to replace Merkle tree data structure

Most blockchains use the Merkle Tree data structure. The leaf nodes of the Merkle Tree store the hash value of the transaction data (or the transaction data itself, and then hash it), and the non-leaf nodes store the hash value of the hash value of its child nodes. The hash values are calculated layer by layer, and finally a Merkle Root is calculated, which can safely verify the integrity of the data in the block and prevent the data from being tampered with.

Taking the data storage Merkle tree of the ERC20 token contract as an example, the leaf nodes of the Merkle tree include:

• Stores attributes such as the total supply of tokens (TotalSupply), token symbols (NameSymbol), etc. Each attribute corresponds to a key (attribute name) and a value (attribute value);

• The holding status of all addresses holding the token. Each address corresponds to a key (address hash) and a value (amount of tokens held);

• All authorizations of the token, each authorization address corresponds to a key (address hash) and a value (authorized quantity);

…

Suppose an ERC token has 4 attributes, 32,000 holding addresses, and 2,764 authorized addresses. This number is obviously not much. But there are 32,768 leaf nodes in total. To write the Merkle rights of the token, 65,535 hash calculations are required.

Somnia's self-developed IceDB database engine does not use the commonly used Merkle tree data structure, so there is no hash root in its block information.

IceDB uses LSM tree (Log-Structured Merge-Tree), which is a log-based tree data structure. Its main feature is that data is written in appends rather than modified in place, so there is no tampering problem.

When writing to the IceDB database, data is first written to the MemTable in memory. When the MemTable is full, it is flushed to disk to form an SSTable. LSM periodically merges SSTables and deletes duplicate keys.

This process does not require hash calculation, only new data needs to be written to MemTable. Therefore, whether the data is written to memory, cache or disk, the writing speed of IceDB database is significantly faster.

?Highlights: Faster reading and writing

The LSM tree data structure has obvious performance advantages in writing data. In addition, the Somnia technical documentation mentions that "a data cache is created that can optimize both reads and writes, making the average read and write time of IceDB between 15 and 100 nanoseconds."

?Features: Read and write performance reports and fair and efficient Gas

In most blockchain networks, although the validator nodes will eventually tend to store the same data. However, in a short period of time, the data stored in the memory and disk of different validator nodes will have certain discrepancies. This causes users to consume different Gas when reading and writing data due to accessing different locations. On the other hand, due to different access locations, it may take a long time for users to read and write data. During this time window, the network Gas may change. Therefore, it is difficult to determine a fair and effective Gas. If the Gas is underestimated, the node may be passive due to low income and affect the efficiency of the network. If the Gas is overestimated, users pay unnecessary extra fees, and it may even provide opportunities for MEV attacks.

Under the IceDB database engine, every time a user reads or writes data, if the required data is not found in the cache, the user needs to read the data from the memory and SSD respectively, count the frequency of reading data from the memory and SSD, and return a "performance report". The "performance report" provides a deterministic basis for calculating the Gas required by the user, thus making the network Gas more fair and efficient, which is conducive to the network stable currency.

?Data compression technology

According to the power-rate theory of information volume and frequency distribution introduced in the Somnia technical documentation, data can be highly compressed by summarizing the information according to its probability of occurrence.

Each data chain in Somnia is managed by a validator. The validator does not need to send the entire block, but only needs to send the information stream. Stream compression has a higher compression rate, so it is beneficial to improve network transmission capacity.

In addition, Somnia uses BLS signatures to increase the speed of signature transmission and verification.

Under Somnia's multi-stream consensus algorithm, the validator nodes of the data chain send each other data shards of the data chain. There is no centralized leader for centralized data upload and download, and bandwidth can be evenly distributed among validators. Each validator needs to send data shards to other validators and download data shards sent by other validators at the same time. Therefore, the bandwidth required for upload and download of each validator is symmetrical. Therefore, the transmission capacity of the Somnia network will be more balanced and stable.

?Written at the end

Although Web3 appears to be more advanced than Web2, in fact, Web2’s technical system is often more complex and mature. When Web2 developers participate in Web3 development, their technical background can bring more innovation to the blockchain world.