The market has become completely desensitized to "high-speed public blockchains," so why might Somnia be different?
TechFlow Selected TechFlow Selected
The market has become completely desensitized to "high-speed public blockchains," so why might Somnia be different?
The fastest, most cost-effective parallel EVM Layer 1—Is Somnia all talk?
Navigating Web3 tides with focused insightsAuthor: TVBee
This article analyzes the following two questions:
Question 1: The market has become completely desensitized to "high-speed public blockchains." Why might Somnia be different?
Question 2: Claiming to be the fastest and most cost-efficient parallel EVM Layer 1, is Somnia exaggerating?
➡️➡️➡️ Concise Version ⬅️⬅️⬅️
This section summarizes Somnia from three dimensions—technology, background, and ecosystem—to highlight the project's key strengths.
💠 Technical Highlights of Somnia
🔹 Multistream Consensus Algorithm: Data Chain + Consensus Chain, helps prevent MEV, reduces redundancy, lowers costs, and improves efficiency.
🔹 Innovative EVM Compiler: Enables instruction-level parallel EVM execution, addressing high-frequency interactions under extreme conditions.
🔹 Proprietary IceDB Database Engine: Enhances data read/write speed and network stability.
🔹 Data Compression Technology: Improves data transmission efficiency.
💠 Background Advantages of Somnia
🔹 Team: The development team comes from Improbable, a multinational tech company founded in 2012 with headquarters in London, UK. Improbable has previously developed software, games, and Web3 metaverse products.
🔹 Funding: Raised $270 million from well-known institutions including MSquared, a16z, SoftBank, and Mirana.
💠 Ecosystem Progress
🔹 Ecosystem Landscape: Somnia’s testnet currently hosts 4 AI/social apps, 7 games, 4 NFT projects, and 6 DeFi applications. Additionally, 2 more AI/social apps, 11 games, and 1 DeFi app are即将上线.
🔹 Ecosystem Data: From its launch in late February 2025 to the time of writing (June 26, 2025), over 100 million blocks have been produced on Somnia’s testnet, with an average block production time of 0.1 seconds. A total of 96,878,557 wallet addresses have participated in the testnet, with 26.43 million transactions processed in the last 24 hours.
On block explorers, transaction and block counts are constantly flashing—it’s visibly clear why Somnia claims “sub-second” performance.
💠 Why Might Somnia Be Different?
🔹 High-Frequency Interaction Focus: Despite market fatigue around “high-speed blockchains,” Somnia goes beyond raw technical specs by focusing on how Web3 technology can truly serve real-world applications—especially in gaming and social platforms requiring frequent interactions.
🔹 Web2 and Web3 Integration: Somnia’s unique background may play a pivotal role in bridging Web2 and Web3. It has the potential to offer Web2 users a seamless gateway into the Web3 world, possibly enabling a user-centric application ecosystem.
➡️➡️➡️ Detailed Version ⬅️⬅️⬅️
The previous section covered WHAT makes Somnia stand out—the highlights, advantages, and ecosystem progress. This section dives deeper into Somnia’s technology to explain HOW it achieves high-frequency interaction and low-cost, high-performance operations, and WHY it differs from other parallel EVM projects.
💠 Multistream Consensus: Data Chain + Consensus Chain
🔹 Overview: Structure of Data Chain + Consensus Chain
Somnia employs a novel Multistream consensus algorithm.
The term “multistream” refers to recording transaction data across multiple data chains, with each data chain managed by one validator. Validators cannot interfere with other validators’ data chains.
The term “consensus” means that ordering and validation of transactions occur on a separate consensus chain, where references (hashes) to transactions are recorded. The consensus chain is jointly maintained and executed by all validators.
🔹 Overview: Workflow of Somnia’s Multistream Consensus
a After a user sends a request to the Somnia network, the receiving validator writes the transaction into its data chain.
b At fixed intervals (e.g., every 30 seconds or 1 second), validators exchange the top data shards from their respective data chains with other validators.
c Each validator aggregates all received top shards into a complete data slice and writes it to the consensus chain.
d Validators then order the transactions, update the state based on this order, and synchronize the new state into Somnia’s IceDB database.
🔹 Advantage: Transaction Ordering Helps Prevent MEV
Somnia uses a deterministic pseudorandom function to order transactions.
In computing, true randomness doesn’t exist—only pseudorandomness generated through algorithms. A deterministic pseudorandom function has two key features: it appears random (the next number cannot be predicted), yet produces the same sequence when run by any validator.
All validators execute the same deterministic pseudorandom function, generating identical sequences of random numbers used to determine the order of data chains. Transactions are then ordered accordingly—for example, Data Chain B first, followed by A, then C, etc. Duplicate transactions are removed via hash comparison.
Even though the order within each data chain may differ (e.g., Transaction 1 before 2 in Chain A, but reversed in Chain B), the final global order follows the randomized data chain sequence. If Chain B is placed before Chain A, Transaction 2 will precede Transaction 1 globally.
This mechanism makes MEV attacks extremely difficult. An attacker would need to bribe enough validators so that no unbribed validator—with conflicting transactions—ranks ahead. For example, even if an attacker bribes 50 out of 100 validators, as long as one honest validator containing the targeted transaction appears earlier in the order, the correct transaction sequence will be recorded, rendering the MEV attack ineffective.
🔹 Advantage: Reduced Redundancy, Lower Costs, Higher Efficiency
Firstly, each validator independently maintains one data chain without needing cross-validation with others. During snapshot transfers, only metadata snapshots—not full transaction data—are exchanged, reducing communication overhead.
Secondly, data chains do not sync with each other, and the consensus chain does not store full transaction data. Instead, at regular intervals, it records snapshots of data chain states and ordered transaction references (hashes). This significantly reduces storage redundancy.
Reduced communication redundancy enables higher operational efficiency.
Reduced storage redundancy leads to lower operating costs.
🔹 Additional Note: Tamper Resistance of Data Chains
Although there’s no inter-validator data verification, validators cannot tamper with transactions. Any alteration would change the transaction’s hash and all subsequent hashes, causing mismatches with the data stored on the consensus chain, thus exposing the fraud.
💠 Instruction-Level Parallel EVM
🔹 Pain Point: Transaction-Level Parallelism Fails Under High-Frequency Congestion
Somnia’s parallel EVM differs from those of Monad and Reddio. Those chains use transaction-level parallelism—executing multiple transactions simultaneously to improve throughput.
Monad optimistically allows parallel execution and corrects conflicts afterward. Reddio identifies non-conflicting, independent transactions for parallel processing.
However, during surges of correlated transactions, parallelization breaks down, leading to congestion. Two extreme examples: sudden spikes in USDC trades against a single liquidity pool (all interacting with the same state, must be sequential); or mass minting of a limited-supply NFT (must be processed sequentially to determine winners and losers).
Reddio addresses this using GPUs—leveraging massive computational power to handle high-frequency workloads. While effective, this increases transaction costs.
🔹 Innovation: Instruction-Level Parallel EVM
To solve congestion caused by correlated transactions—which transaction-level parallelism cannot resolve—Somnia developed a proprietary EVM compiler.
In standard EVM execution, instructions within a transaction are interpreted and executed sequentially. Somnia, however, can split a single transaction into multiple instruction sets, allowing non-conflicting, independent sets to run in parallel.
For example, a Swap transaction can be broken down into these instruction sets: parameter validation, parameter processing, balance check, approval check, pool state check, price calculation, fee calculation, input token transfer, pool state update, output token transfer, event emission. Independent sets can execute concurrently, boosting overall efficiency.
The core of this capability lies in Somnia’s custom EVM compiler, which compiles EVM bytecode into x86 machine code. Modern CPUs have multi-threaded cores capable of parallel machine code execution. By compiling EVM instructions into native machine code, Somnia enables intra-transaction parallelism—making it effectively a hardware-level parallel EVM.
🔹 Advantage: Dual Benefits in Cost and Efficiency
Standard EVM interpretation: Transaction 1 → bytecode parsing → sequential interpretation → Transaction 2 → bytecode parsing → sequential interpretation → ...
Somnia’s compiled EVM: Contract code → bytecode parsing → dynamic compilation to machine code → parallel execution of instruction sets across multiple transactions...
As transaction volume grows, Somnia’s approach gains increasing advantage.
For typical, low-frequency transactions, Somnia still uses standard EVM interpretation—parsing smart contract code into EVM bytecode and executing it sequentially.
For concentrated, high-frequency transactions, Somnia activates its EVM compiler to convert bytecode into x86 machine code. Once compiled, repeated executions simply run the optimized machine code—delivering rapid processing of burst traffic, something transaction-level parallelism cannot achieve.
Thus, Somnia achieves dual advantages in both cost and performance.
💠 IceDB Database Engine
🔹 Overview: Replacing Merkle Tree with LSM Tree
Most blockchains use Merkle Trees for data structure. In a Merkle Tree, leaf nodes store hashes of transaction data (or the data itself), while internal nodes store hashes of their children. Hashes are computed layer by layer until a single root hash (Merkle Root) is formed, ensuring data integrity and tamper resistance.
Take an ERC20 token contract as an example. Its Merkle Tree leaves include:
• Token attributes like TotalSupply and NameSymbol—each represented by a key-value pair;
• Balances of all holders—each address mapped to a balance;
• Approval records—each approved address paired with allowance amount;
…
Suppose a token has 4 attributes, 32,000 holders, and 2,764 approvals. That’s 32,768 leaf nodes—requiring 65,535 hash computations just to build the Merkle root. This becomes computationally expensive.
Somnia’s self-developed IceDB engine avoids Merkle Trees entirely—and thus does not include a Merkle root in its block data.
Instead, IceDB uses LSM Tree (Log-Structured Merge-Tree), a log-based tree structure where data is appended rather than overwritten, eliminating in-place modification risks.
Data is first written to an in-memory MemTable. When full, it’s flushed to disk as an SSTable. LSM periodically merges SSTables and removes duplicate keys.
This process requires no hashing—just appending data to MemTable—resulting in significantly faster write speeds across memory, cache, and disk.
🔹 Advantage: Faster Read and Write Performance
LSM Trees inherently excel in write performance. Moreover, according to Somnia’s technical documentation, “a data cache was created to optimize both reads and writes, achieving average read/write times between 15 and 100 nanoseconds.”
🔹 Feature: Performance Reporting and Fair, Efficient Gas
In most blockchain networks, although validator nodes eventually converge on the same data, short-term discrepancies exist in their in-memory and on-disk data. This causes variable gas costs depending on which node serves a read/write request. Additionally, varying access latency means gas prices may fluctuate during the operation window, making fair gas estimation difficult. Underestimation risks node apathy due to low rewards; overestimation wastes user funds and may even enable MEV opportunities.
Under IceDB, whenever a user’s read/write request misses the cache, the system tracks how often data must be fetched from memory versus SSD, generating a “performance report.” This report provides deterministic input for calculating accurate gas fees, leading to fairer, more efficient pricing—benefiting network stability.
💠 Data Compression Technology
Based on information theory and the power-law distribution of data frequency, grouping data by occurrence probability enables high compression ratios.
Each data chain in Somnia is managed by one validator. Instead of transmitting entire blocks, validators send only data streams. Stream-based compression achieves higher efficiency, improving network transmission capacity.
Additionally, Somnia uses BLS signatures to accelerate signature transmission and verification.
Under the multistream consensus model, validators directly exchange data shards peer-to-peer—without a central leader coordinating uploads/downloads. Bandwidth usage is evenly distributed across the network. Each validator uploads its own shard while downloading others’, resulting in symmetric bandwidth requirements. This ensures balanced and stable network throughput.
💠 Final Thoughts
While Web3 may appear more advanced than Web2 on the surface, Web2’s technical systems are often more complex and mature. When Web2 developers enter Web3 development, their deep technical expertise can bring meaningful innovation to the blockchain space.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
TVBee
