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

Author: TVBee

This article will analyze the following two questions:

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

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

➡️➡️➡️ Brief • Clean • Version ⬅️⬅️⬅️

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 Technical Highlights

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

🔹 Innovative EVM Compiler: Achieves instruction-level parallel EVM, solving high-frequency interactions in extreme cases.

🔹 Self-developed IceDB Database Engine: Enhances data read/write speed and network stability.

🔹 Data Compression Technology: Improves 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. They have developed software, games, and Web3 metaverse products.

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

💠 Somnia's Ecosystem Progress

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

🔹 Ecosystem Data: From its launch in late February 2025 to the time of writing (June 26, 2025), Somnia's testnet has produced over 100 million blocks, with an average block production time of 0.1 seconds. A total of 96,878,557 wallet addresses participated in the testnet, with a recent daily transaction volume of 26.43 million.

On the block explorer, transaction counts and block counts can often be seen flashing continuously, with Somnia claiming "sub-second" speeds, which are visible to the naked eye.

💠 Why might Somnia be different?

🔹 High-frequency Interaction: Although the market has become desensitized to the concept of "high-speed public chains," Somnia is not just pursuing technical metrics but is focused on how Web3 technology can truly serve application scenarios, especially in high-frequency interactive fields like gaming and social networking.

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

➡️➡️➡️ Detailed • Explanation • Version ⬅️⬅️⬅️

The previous section introduced the highlights, advantages, and ecosystem progress of Somnia. This section will provide an in-depth interpretation of Somnia's technology, explaining how Somnia achieves high-frequency interactions technically, how it maintains low costs and high performance, and why Somnia is different from other parallel EVM projects.

💠 Multi-stream Consensus Algorithm: Data Chain + Consensus Chain

🔹 Overview: Data Chain + Consensus Chain Structure

Somnia employs a new multi-stream (MULTISTREAM) consensus 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, preventing any validator from interfering with the data chains of others.

The so-called consensus means that Somnia executes consensus on the consensus chain, sorting transactions and recording references to transactions on the consensus chain. The consensus chain is jointly executed and maintained by all validators.

🔹 Overview: 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 transaction to the data chain.

b At each time interval (e.g., every 30 seconds, 1 second, etc.), the validators of the data chains upload and download the top data shards of their respective data chains.

c Validators write a complete data slice, which includes all the top data shards from the data chains, to the consensus chain.

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

🔹 Highlight: Somnia's Transaction Sorting Helps Prevent MEV

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

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

Thus, all validators running the same deterministic pseudo-random function will generate a series of identical random numbers and sort the data chains based on these random numbers. On this basis, transactions for that period are sorted.

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

Then the transaction order is that transactions from data chain B come first, followed by those from data chain A, and then data chain C… Of course, this process will remove duplicate transactions based on hash values.

While the sorting of data chains is fixed, the order of transactions within different data chains may vary. For instance, 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 sorting of data chains is B before A, the final transaction order is transaction 2 before transaction 1.

The advantage of this sorting method is that it is difficult for MEV attackers to bribe validators because they do not know how the validators' corresponding data chains will be sorted. If there are 100 validator nodes in total, even if 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 record the transactions in the correct order, and the MEV attack will fail.

🔹 Highlight: Reducing Redundancy, Lowering Costs, and Increasing Efficiency

On one hand, each validator in Somnia records a separate data chain without a data verification process between validators. When transmitting snapshots, only the snapshot information of each data chain is transmitted, excluding specific transaction information, thus reducing interaction redundancy.

On the other hand, the various data chains 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) at each time interval. This reduces storage redundancy.

By reducing interaction redundancy, Somnia can operate more efficiently.

By reducing storage redundancy, Somnia incurs lower operational costs.

🔹 Supplement: Data Chain Tamper Resistance

Although there is no information verification for data chains, validators cannot tamper with transaction information. If a validator tampers with transaction information, it will affect the transaction's hash value and the hash values of subsequent transactions, leading to a conflict with the information stored on the consensus chain.

💠 Instruction-Level Parallel EVM

🔹 Pain Point: Transaction Parallelism Struggles to Alleviate High-Frequency Interaction Congestion

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

Monad optimistically allows transaction parallelism and corrects conflicts when detected. Reddio parallelizes transactions that are non-conflicting and have no dependencies.

However, when a large number of related transactions occur, they cannot be parallelized, leading to congestion. There are two extreme examples: for instance, if a sudden influx of users is trading a token with USDC, these transactions cannot be parallelized as they must interact with the LP pool and can only 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 they must be executed sequentially to determine who can successfully mint and who cannot.

Reddio addresses this issue by using GPUs to leverage their powerful computing capabilities to resolve congestion in high-frequency interactions. While this can improve transaction efficiency, it also increases transaction costs.

🔹 Highlight: Instruction-Level Parallel EVM

To address the congestion issue caused by a large number of related transactions, Somnia has innovatively developed an EVM compiler.

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

For example, in a Swap transaction, it can be divided into several instruction sets based on 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, non-conflicting and independent instruction sets can be executed in parallel, thus improving transaction execution efficiency.

The key to the instruction set parallel EVM is Somnia's unique 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, thereby increasing the execution speed of individual transactions. Therefore, Somnia can also be referred to as a hardware-level parallel EVM.

🔹 Highlight: Dual Advantages of Cost and Efficiency

Standard EVM interpretation execution: Transaction 1 → parsed into bytecode → sequential interpretation execution → Transaction 2 → parsed into bytecode → sequential interpretation execution → Transaction 3 → parsed into bytecode → sequential interpretation execution…

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…

Comparing the two, the more transactions there are, the more advantageous Somnia's EVM compilation execution becomes.

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

For centralized high-frequency execution transactions, Somnia enables the EVM compiler to compile EVM bytecode into x86 machine code. Then, by repeatedly executing the machine code according to parameters, centralized high-frequency transactions can be completed quickly, achieving results that transaction-level parallel EVMs cannot reach.

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 Merkle Tree data structures. The leaf nodes of a 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' hash values, calculating hash values layer by layer until a Merkle Root is computed, allowing for secure verification of 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:

• Storing attributes such as TotalSupply and NameSymbol, where each attribute corresponds to a key (attribute name) and a value (attribute value);

• The holding status of all wallet addresses for the token, where each address corresponds to a key (address hash) and a value (holding amount);

• The authorization status of the token, where each authorized address corresponds to a key (address hash) and a value (authorized amount);

……

If an ERC token has 4 attributes, 32,000 holding addresses, and 2,764 authorized addresses, this number is clearly not large. However, this results in a total of 32,768 leaf nodes, requiring 65,535 hash calculations to write the Merkle proof for the token.

Somnia's self-developed IceDB database engine does not use the commonly used Merkle Tree data structure, and therefore its block information does not contain a hash root.

IceDB uses LSM trees (Log-Structured Merge-Trees). This is a log-based tree data structure characterized by data being appended rather than modified in place, thus eliminating tampering issues.

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

This process does not require hash calculations; it only requires writing new data to the MemTable, making the write speed of the IceDB database significantly faster, whether writing data to memory, cache, or disk.

🔹 Highlight: Faster Read and Write

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

🔹 Feature: Read and Write Performance Reports and Fair, Effective Gas

In most blockchain networks, although final 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 a short time. This leads to users consuming different amounts of Gas when reading and writing data due to accessing different locations. On the other hand, due to different access locations, the time taken for users to read and write data may be longer, and during this time window, network Gas may change. Therefore, it is difficult to determine fair and effective Gas. If Gas is underestimated, nodes may become passive due to low rewards, affecting 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 data from both memory and SSD, counting the frequency of data read from memory and SSD, and returning a "performance report." The "performance report" provides a deterministic basis for calculating the Gas required by users, making network Gas fairer and more effective, which is beneficial for network stability.

💠 Data Compression Technology

According to the information volume and frequency distribution power law theory introduced 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 needs to send the information stream. Stream compression has a higher compression rate, which helps improve network transmission capacity.

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

Under Somnia's multi-stream consensus algorithm, the validator nodes of the data chains send data shards to each other without a centralized leader for centralized data upload and download, allowing validators to evenly distribute bandwidth. Each validator must send data shards to other validators while downloading data shards sent by others, making the bandwidth required for uploading and downloading symmetrical. Therefore, the network transmission capacity of Somnia is relatively balanced and stable.

💠 In Conclusion

Although Web3 appears to be more advanced than Web2 on the surface, the technical systems of Web2 are often more complex and mature. When Web2 developers participate in Web3 development, their technical backgrounds can bring more innovation to the blockchain world.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。