Is Somnia, claiming to be the fastest and most cost-effective parallel EVM Layer 1, just boasting?

This article will analyze with the following two questions:

Question 1: The market has become desensitized to the 'high-speed public chain'; why is it said that Somnia may be different?

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

➡️➡️➡️ Simple • Clean • Edition ⬅️⬅️⬅️

This section summarizes Somnia from three dimensions: technology, background, and ecosystem, allowing everyone to understand the highlights and advantages of the Somnia project.

💠 Somnia's technological highlights

🔹 Multi-stream consensus algorithm: Data chain + consensus chain, beneficial for preventing MEV, reducing redundancy, and simultaneously lowering costs while increasing efficiency.

🔹 Innovative EVM compiler: Achieving instruction-level parallel EVM, addressing high-frequency interactions in extreme cases.

🔹 Self-developed IceDB database engine: Enhancing data read and write speeds and network stability.

🔹 Data compression technology: Enhancing data transmission efficiency.

💠 Somnia's background advantages

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

🔹 Financing: A total of $270 million was invested by well-known institutions such as MSquared, a16z, SoftBank, and Mirana.

💠 Somnia's ecosystem progress

🔹 Ecosystem map: Somnia's testnet has already supported 4 AI/social products, 7 games, 4 NFT projects, and 6 DeFi applications, with 2 more AI/social products, 11 games, and 1 DeFi application set to launch soon.

🔹 Ecosystem data: Since its launch in late February 2025, Somnia's testnet has produced over 100 million blocks, with an average production time of 0.1 seconds per block. A total of 96,878,557 wallet addresses have participated in the testnet, with a transaction volume of 26.43 million in the last day.

On the block explorer, the number of transactions and blocks can often be seen flashing continuously. Somnia refers to it as 'sub-second' and is visually noticeable.

💠 Why is it said that Somnia may be different?

🔹 High-frequency interactions: Although the market has become desensitized to the concept of 'high-speed public chains', Somnia does not just pursue technical metrics, but focuses on how to make Web3 technology truly serve application scenarios, especially in high-frequency related interaction fields such as gaming and social networking.

🔹 Integration of Web3 and Web3: 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 transition into the Web3 world, potentially leading to a truly user-experience-centered application ecosystem.

➡️➡️➡️ Detailed • Explanation • Edition ⬅️⬅️⬅️

The previous section introduced the highlights, advantages, and ecosystem progress of Somnia; this section will delve into Somnia's technology. Let everyone understand how Somnia technically achieves high-frequency interactions, how it achieves low cost and high performance, and why Somnia differs from other parallel EVM projects.

💠 Multi-stream consensus algorithm: Data chain + consensus chain

🔹 Overview: Data chain + consensus chain structure

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

The so-called multi-stream means that Somnia records transaction information across multiple data chains, with each data chain recorded by a single validator who cannot interfere with the data chains of others.

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

🔹 Overview: The workflow of Somnia's multi-stream consensus

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

b Each time cycle (e.g., 30 seconds, 1 second, etc.), the validators of the data chain upload and download data fragments from the top of the data chains with those of other data chains.

C Validators write a complete data slice that includes a collection of all data fragments at the top of the data chains into the consensus chain.

Validators sort transactions and update statuses based on the sorted transactions, with all validators synchronously writing to Somnia's IceDB database.

🔹 Highlights: Somnia's transaction sorting is beneficial to preventing MEV

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

We understand that there is no true randomness in computing programs; rather, it is achieved through algorithms that implement pseudo-randomness. Deterministic pseudo-random functions have two characteristics: they are unpredictable, meaning the next generated random number cannot be predicted, but each validator generates the same random number in a fixed order during execution.

In this way, all validators run the same deterministic pseudo-random function, generating a series of identical random numbers, and sort data chains based on these random numbers. On this basis, transactions for this cycle are sorted.

For example, the sorted data chains are B, A, C…

Thus, the transaction sorting will have the transactions from data chain B first, followed by data chain A, and then data chain C… Of course, this process will remove duplicate transactions based on hash values.

Of course, the sorting of data chains is fixed, but the transaction order in different data chains may vary. For example, in data chain A, transaction 1 may come before transaction 2, while in data chain B, transaction 2 may come before transaction 1. Since the order of data chains is B before A, the final transaction order is transaction 2 first, followed by transaction 1.

The advantage of this sorting method is that it is difficult for MEV attackers to bribe validators, as they do not know how the validators' corresponding data chains will be sorted. If there are 100 validator nodes on the network, and an MEV attacker bribes 50 validators, as long as there is one validator that has not been bribed (and includes the attacked transaction) ahead of these 50 validators, the consensus chain will account for transactions in the correct order, leading to MEV attack failure.

🔹 Highlights: Reducing redundancy, lowering costs, and increasing efficiency

On one hand, each validator in Somnia records a separate data chain, without data verification processes among validators. When transmitting snapshots, only the snapshot information of each data chain is transmitted, which does not include specific transaction information, thereby reducing interaction redundancy.

On the other hand, different data chains in Somnia do not need to synchronize information from other data chains, and the consensus chain does not record transaction information. Instead, it records snapshots of data chain information and sorted transaction references (hash values) every time cycle, reducing storage redundancy.

By reducing interaction redundancy, Somnia can operate more efficiently.

By reducing storage redundancy, Somnia operates at a lower cost.

🔹 Supplement: Anti-tampering of data chains

Although there is no verification of data chain information, validators cannot tamper with transaction information. This is because if a validator tampers with transaction information, it would affect the hash value of the transaction and subsequent transaction hash values, leading to a conflict with the information stored in the consensus chain.

💠 Instruction-level parallel EVM

🔹 Pain Point: Transaction parallelism struggles to alleviate congestion in high-frequency interactions

Somnia's parallel EVM differs from Monad and Reddio; the EVM parallelism of these three chains is transaction parallelism, which means parallelizing transactions to enhance transaction speed.

Monad allows optimistic transaction parallelism, correcting upon detecting conflicts. Reddio parallelizes non-conflicting and independent transactions.

However, when a large number of related transactions occur, transactions cannot be parallelized, leading to easy congestion. There are two extreme examples, for instance, a sudden surge of users trading a token using USDC on the network. These transactions cannot be parallelized due to the need to interact with the LP pool and must be executed sequentially.

Another extreme example is when countless people rush to mint the same NFT, which also cannot be parallelized because the number of NFTs is limited and must be executed sequentially to determine who can successfully mint and who cannot.

Reddio solves this problem by using GPUs to leverage their strong computational power to alleviate the congestion of high-frequency interactions. While it can improve transaction efficiency, it simultaneously increases transaction costs.

🔹 Highlights: Instruction-level parallel EVM

To solve the congestion issue where a large number of related transactions occur simultaneously, making transaction parallelism difficult, Somnia has innovatively developed an EVM compiler.

In the standard EVM execution process, transactions can only be interpreted one by one in a sequential manner. However, Somnia supports splitting transactions into several instruction sets, where non-conflicting and independent instruction sets can be executed in parallel.

Taking Swap transactions as an example, they can be divided into several instruction sets according to functionality: parameter validation, parameter processing, balance checking, authorization checking, pool status checking, price calculation, fee calculation, transferring input tokens, updating pool status and fee records, transferring output tokens, and event emission. Among these, instruction sets that are non-conflicting and have no dependency can be executed in parallel, thereby improving the efficiency of transaction execution.

The key to instruction set parallel EVM is Somnia's original EVM compiler, which compiles EVM bytecode into x86 machine code. Modern CPUs are multi-threaded cores, and each CPU core can execute machine code in parallel across multiple threads, allowing several instruction sets of EVM to be executed in parallel and thus improving the execution speed of a single transaction. Therefore, Somnia can also be referred to as a hardware-level parallel EVM.

🔹 Highlights: Dual advantages of cost and efficiency

Standard EVM interpretation execution: Transaction 1 → Parsed into bytecode → Sequentially interpreted → Transaction 2 → Parsed into bytecode → Sequentially interpreted → Transaction 3 → Parsed into bytecode → Sequentially interpreted…

Somnia's EVM compilation 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…

Comparisons show that the more transactions there are, the more advantages Somnia's EVM compilation execution has.

Thus, for ordinary non-high-frequency transactions, Somnia still uses the standard EVM interpretation execution, parsing the smart contract code into EVM bytecode and interpreting it sequentially.

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

Therefore, Somnia can achieve a dual advantage between cost and efficiency.

💠 IceDB database engine

🔹 Overview: Using LSM trees instead of Merkle tree data structures

The vast majority of blockchains use the Merkle tree data structure. The leaf nodes of the Merkle tree store the hash values of transaction data (or the transaction data itself, which is then hashed), while non-leaf nodes store the hash values of their child nodes' hashes, combining them layer by layer to calculate the hash value, ultimately resulting in a Merkle root, thereby securely verifying the integrity of the data within the block and preventing data tampering.

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

• Store attributes such as total supply (TotalSupply), token symbol (NameSymbol), etc. Each attribute corresponds to a key (attribute name) and a value (attribute value);

• The holding situation of all token holding addresses for this token corresponds to a key (address hash) and a value (holding amount) for each address;

• Each authorization situation of the token corresponds to a key (address hash) and a value (authorization amount) for every authorization address;

……

If an ERC token has 4 attributes, 32,000 holding addresses, and 2,764 authorization addresses, this number is obviously not large. However, there are a total of 32,768 leaf nodes, requiring 65,535 hash calculations to write the token's Merkle rights.

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

IceDB uses LSM trees (Log-Structured Merge-Tree). This is a log-based tree data structure characterized mainly by appending data rather than modifying it in place, thus eliminating tampering issues.

The writing to the IceDB database first goes to the in-memory MemTable. When the MemTable is full, it is flushed to disk, forming an SSTable. LSM periodically merges SSTables while removing duplicate keys.

This process does not require hash calculations, only needing to write new data to the MemTable, so regardless of whether data is written to memory, cache, or disk, the writing speed of the IceDB database is significantly faster.

🔹 Highlights: Faster read and write speeds

The LSM tree data structure clearly has performance advantages in data writing. In addition, Somnia's technical documentation mentions 'a data cache that can simultaneously optimize reading and writing has been created, resulting in an average read/write time for IceDB between 15 and 100 nanoseconds.'

🔹 Features: Read-write performance report and fair and efficient Gas

In most blockchain networks, while ultimately validator nodes tend to store the same data, there can be discrepancies in the data stored in the memory and disk of different validator nodes in the short term. This leads to users consuming different Gas amounts when reading and writing data due to accessing different locations. On the other hand, varying access locations may result in longer data read/write times, and during this time window, network Gas may change, making it difficult to determine fair and effective Gas. If Gas is underestimated, nodes may work less diligently due to low rewards, impacting network efficiency. If Gas is overestimated, users pay unnecessary extra fees, and it may even provide opportunities for MEV attacks.

Under the IceDB database engine, when users read and write data, if the required data is not found in the cache, they need to read it from both memory and SSD separately. They then count the frequency of reading data from memory and SSD and return a 'performance report'. The 'performance report' provides a deterministic basis for calculating the Gas required by users, making the network Gas fairer and more effective, contributing to network stability.

💠 Data compression technology

According to the information volume and frequency distribution power law theory in Somnia's technical documentation, summarizing based on the probability of information occurrence can achieve high compression rates for data.

Each data chain in Somnia is managed by a single validator, who does not need to send the entire block but only the information stream, and streaming compression has a higher compression ratio, thus enhancing network transmission capability.

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

Under Somnia's multi-stream consensus algorithm, validators of the data chain send data fragments of the data chain to each other without a centralized leader conducting centralized data uploads and downloads, allowing validators to distribute bandwidth evenly. Each validator must send data fragments to other validators while also downloading data fragments sent by them, making the required bandwidth for uploading and downloading symmetrical. Thus, Somnia's network transmission capability will be relatively balanced and stable.

💠 In conclusion

Although Web3 appears to be more advanced than Web2, the technological framework of Web2 is often more complex and mature. When Web2 developers participate in Web3 development, their technical background can bring more innovative possibilities to the blockchain world.

Improbable is a hybrid technology company transitioning from Web2 to Web3. Its Layer 1 product Somnia employs a multi-stream consensus algorithm, reducing storage and data transmission redundancy, thus achieving a simultaneous reduction in costs and an increase in efficiency. Its self-developed EVM compiler can achieve hardware-level parallelism for non-conflicting and independent instruction sets of the same transaction, specifically addressing congestion issues in high-frequency interaction applications. The self-developed IceDB database engine greatly enhances data writing capabilities and simultaneously improves data reading capabilities through data caching. Data compression technology reduces the pressure of data transmission for validators, while the multi-stream consensus design of data chain + consensus chain ensures more balanced and stable transmission capabilities for the Somnia network.

These technologies enable Somnia to successfully complete high-frequency interaction applications like Web2 programs, such as gaming, social networking, and the metaverse. Its cross-Web2 and Web3 background provides an ecological foundation for integrating Web2 and bringing it closer to people's lives.

One of the key focuses of this narrative is the integration of Web3 and Web2. Currently, we have seen the convergence of cryptocurrency ETFs, real-world assets, and financial fields like Payfi. Next, attention should be given to the integration of information products such as social networking and gaming. Somnia is building Layer 1 infrastructure for this integration and continuously advancing in its ecosystem.

Perhaps in the near future, we will see a new ecosystem where Web2 and Web3 truly integrate, enjoying all the rights of Web3 without sacrificing the smooth experience and convenience brought by Web2 applications…