The market has completely desensitized to "high-speed public chains", why is Somnia different?

Author: TVBee

This article will be analyzed with the following two questions:

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

Question 2: Is Sommia bragging about the fastest and most cost-effective parallel EVM Layer 1?

➡️➡️➡️ Jane • Clean • Edition ⬅️⬅️⬅️

In this part, Sonnia is summarized from three dimensions: technology, background and ecology, so that you 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: Implements parallel EVM at the instruction level to solve high-frequency interactions in extreme cases.

🔹 Self-developed IceDB database engine: improves data read/write speed and network stability.

🔹 Data compression technology: Improve data transmission efficiency.

💠Somnia's background advantages

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

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

💠Ecological progress in Somnia

🔹 Ecological Landscape: The Somnia testnet has already settled in 4 AI/social products, 7 games, 4 NFT projects and 6 Defi applications, and another 2 AI/social products, 11 games and 1 Defi application will be launched soon.

🔹 Ecological data: From its launch in late February 2025 to the time of writing (June 26, 2025), the Somnia testnet 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 testnet, with a trading volume of 26.43 million in the last 1 day.

On block explorers, you can often see the number of transactions and blocks constantly flashing, which Sonnia calls "sub-secondary", which is visible to the naked eye.

💠 Why might Somnia be different?

🔹 High-frequency interaction: Although the market has completely 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 vs. Web3 Convergence: Somnia's unique background may play a key role in the convergence of Web3 and Web2. Somnia has the potential to provide Web2 users with seamless access to the Web3 world, potentially leading to a truly user-centric application ecosystem.

➡️➡️➡️ Details• Explanation• Edition ⬅️⬅️⬅️

The previous part introduced the highlights, advantages and ecological progress of [WHAT] Somnia, and this part will provide an in-depth interpretation of Somnia's technology. Let everyone understand how [HOW] Somnia technically achieves high-frequency interaction, 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 multistream consensus (MULTISTREAM) algorithm.

In the so-called multi-stream, Somnia records transaction information on multiple data chains, each data link is recorded by 1 validator, and each validator cannot interfere with the data chain 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 executed and maintained by all validators.

🔹 Overview: Workflow for Somnia multi-stream consensus

a After a user makes a request to the Somnia network, the validator who receives the request writes the transaction to the datachain separately.

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

C The validator writes the collection of data shards at the top of all data chains to the consensus chain as a complete data slice.

d Validators sort the transactions, and all validators are synchronously written to the IceDB database of Somnia according to the updated status of the sorted transactions.

🔹 Highlights: Somnia's transaction sequencing is good for MEV prevention

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

We know that there is no real randomness in the calculation program, but pseudo-randomness through algorithms. Deterministic pseudorandom functions have two characteristics: one is randomness, which does not predict what the next random number will be, but each validator will generate the same random number in a fixed order when executed.

In this way, all validators run the same deterministic pseudo-random function, which generates a series of identical random numbers and sorts the data chain according to the random numbers. On this basis, the transactions for this period are sorted.

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

Then the transaction ordering is that the transaction of data chain B comes first, followed by data chain A and data chain C...... Of course, this process removes duplicate transactions based on the hash value.

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

The advantage of this ordering method is that it is difficult for a MEV attacker to bribe the validator because he does not know what the data chain corresponding to the validator will be. If there are a total of 100 validator nodes on the network, assuming that even if a MEV attacker bribes 50 validators, as long as there is a validator (including the attacked transaction) who has not been bribed in front of these 50 validators, the consensus chain will be recorded in the correct order of transactions, and the MEV attack will fail.

🔹 Highlights: Reduce redundancy, reduce costs and increase efficiency

On the one hand, Somnia records a separate data chain for each validator, and there is no data validation process between validators. When transferring snapshots, only the snapshot information of each data link is transmitted, and the snapshot information does not include specific transaction information, so the redundancy of the interaction is reduced.

On the other hand, each data chain in Somnia does not need to synchronize the information of other data chains, and the consensus chain does not record transaction information, but records a snapshot of the data chain information and the sorted transaction references (hash values) every other time period. In this way, the redundancy of storage is reduced.

Thanks to the reduced redundancy of interactions, Somnia can be more efficient when working.

Somnia needs to work at a lower cost due to reduced redundancy of storage.

🔹 Added: Tamper-proof data links

While there is no verification of the information in the data chain, the validator cannot tamper with the transaction information. Because once a validator tamperes with the transaction information, it will affect the hash value of the transaction and the hash value of its subsequent transactions, resulting in a conflict between its information and the information stored in the consensus chain.

💠 Parallel EVM at the instruction level

🔹 Pain point: It is difficult to improve the congestion of high-frequency interactions in parallel transactions

Somnia's parallel EVM is different from Monad and Reddio, and the EVM parallelism of these three chains is transaction parallelism, that is, transactions are paralleled to improve the speed of transactions.

Monad is optimistic in allowing transactions to be parallel, detecting conflicts and correcting them. Reddio, on the other hand, is a parallel transaction that does not conflict and has no dependencies.

However, when a large number of related-party transactions arise, the transactions cannot be parallel, so congestion can easily occur. There are two extreme examples, such as the sudden emergence of a large number of users on the network using USDC to trade a certain token, and these transactions cannot be parallelized because they are to be traded with LP pools, but can only be executed sequentially.

Another extreme example is the countless people rushing to Mint the same NFT, which also cannot be parallel, because the number of NFTs is finite and must be executed sequentially to determine which people can succeed in Mint and others fail.

Reddio's solution to this problem is to use the GPU, which uses the powerful computing power of the GPU to solve this congestion of high-frequency interactions. Although it can improve the efficiency of trading, it also increases the cost of trading.

🔹 Highlight: Instruction-level parallel EVM

In order to solve the congestion problem that a large number of related party transactions are carried out at the same time and transactions are difficult to solve in parallel, Sommia has innovatively developed an EVM compiler.

In a standard EVM execution, the execution of orders in a transaction can only be interpreted sequentially. However, Somnia supports splitting transactions into several instruction sets that do not conflict and have no dependencies.

Taking Swap trading as an example, it can be divided into several instruction sets according to functions: parameter verification, parameter processing, balance check, authorization check, pool status check, price calculation, fee calculation, transfer of input tokens, update pool status and fee records, transfer of output tokens, and event launch. Among them, the instruction set that does not conflict and has no dependencies can be parallelized, so as to improve the execution efficiency of transactions.

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

🔹 Highlights: Cost and efficiency

Standard EVM interpretation execution: transaction 1 → parsed to bytecode → sequential interpretation execution→ transaction 2 →parsed to bytecode → sequential interpretation execution→ transaction 3 →parsed to bytecode → sequential interpretation execution......

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

As can be seen, the more transactions there are, the more advantageous Somnia's EVM compilation and execution will be.

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

For centralized, high-frequency execution of transactions, Somnia enables the EVM compiler, which compiles the bytecode of the EVM into x86 machine code. Then, the machine code can be executed repeatedly according to the parameters to quickly complete centralized high-frequency trading, which is not possible with transaction-level parallel EVM.

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

💠IceDB database engine

🔹 Overview: Use 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 of the transaction data (or the transaction data itself, and then hash it), while the non-leaf nodes store the hash value of the hash value of their child nodes, and the hash value is calculated layer by layer, and finally a Merkle root is calculated, so that the integrity of the data in the block can be securely verified and the data can be tampered with.

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

• Store attributes such as TotalSupply and NameSymbol, each of which corresponds to a key (attribute name) and a value (attribute value);

• The holding status of all the token-holding addresses, each of which corresponds to a key (address hash) and a value (the number of tokens);

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

……

Let's say an ERC token has 4 attributes, 32,000 holding addresses, and 2,764 authorized addresses. This amount is obviously not much. But there are a total of 32,768 leaf nodes, and 65,535 hashes need to be computed to write the Merkle rights of the token.

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 the Log-Structured Merge-Tree (LSM Tree). This is a log-based tree data structure whose main feature is that data is appended and written instead of modified in situ, so there is no tampering problem.

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

This process does not require the hash to be calculated, only new data needs to be written to the MemTable, so whether the data is written to memory, cache, or disk, the IceDB database is significantly faster.

🔹 Highlights: Higher speed reading and writing

The LSM tree data structure has a clear performance advantage in writing data. In addition, the Somnia technical documentation mentions that "a data cache has been created that optimizes both reads and writes, so that the average read and write time of IceDB is between 15 and 100 nanoseconds".

🔹 Features: Read and write performance reports with fair and efficient gas

In most blockchain networks, the final validator node tends to store the same data. However, for a short period of time, there is a certain discrepancy between the memory of different validator nodes and the data stored on disk. As a result, users will consume different amounts of 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, and the network gas may change within this time window. Therefore, it is difficult to determine a fair and efficient Gas. If the gas is underestimated, nodes may be passive due to low revenue, which will affect network efficiency. If the gas is overestimated, users will pay unnecessary additional fees, which may even provide an opportunity for MEV attacks.

Under the IceDB database engine, every time you read or write data, you cannot find the data you need in the cache, so you need to read data from memory and SSD respectively, 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, thus making the network gas more fair and efficient, in favor of the network stablecoin.

💠 Data compression technology

According to the power theory of information volume and frequency distribution introduced in the Somnia technical document, the data can be compressed at a high magnification rate by summarizing the information according to the probability of information occurring.

Each data link in Somnia is responsible for a validator, and the validator does not need to send the entire block, but only needs to send the information stream, and the stream compression has a higher compression rate, so it is conducive to improving the network transmission capacity.

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

Under Somnia's multi-stream consensus algorithm, the validator nodes of the data chain send data shards to each other, and there is no centralized leader to upload and download the data in a centralized manner, and the bandwidth can be evenly distributed among the validators. Each validator sends data shards to other validators and downloads data shards sent by other validators, so the bandwidth required for each validator's upload and download is symmetrical. Therefore, the transmission capacity of the Somnia network will be relatively balanced and stable.

💠 Write at the end

Although Web3 is more high-end than Web2 on the surface, in fact, the technical system of Web2 is often more complex and mature. When Web2 developers are involved in Web3 development, their technical background is able to bring more innovation to the blockchain world.