ENDGAME: How SALT breaks the bottleneck that's been strangling blockchains

Welcome Back!

We’ve covered a lot of technical topics throughout our ENDGAME series.

The differences in our block architecture (mini-blocks), how the network stays performant while keeping hardware requirements low (node specialization), and why we’re able to unlock capacity upper bounds by leveraging new-gen data availability solutions (EigenDA).

Today, we're delving deeper into the breakthrough that enables all those optimizations to actually work. See, you can have the smartest block architecture, the most efficient node specialization, and unlimited data availability—but if your database can't keep up, everything else becomes meaningless.

That's where SALT comes in (short for "Small Authentication Large Trie"), our revolutionary approach to blockchain state management that eliminates the I/O bottleneck that has been choking every blockchain since Bitcoin. SALT enables the raw execution speed that transforms MegaETH from a blockchain offering only incremental improvements to one that delivers real-time performance.

To keep things succinct, here are the high points of what SALT tackles. If you want to see some of the finer details on how we achieve the claims — read beyond.

The TLDR:

Our team created SALT as a net-new solution to a problem impacting performance for several blockchain generations (state root updates), and it comes with these highlights:

• 100% In-RAM State Trees
  For the first time, the entire authentication structure fits comfortably in reasonable amounts of RAM, eliminating a leading performance degradation culprit (disk I/O).
• Growth and Performance are Independent
  Traditional approaches slow as data grows. SALT maintains performance whether you're storing millions or billions of keys.
• Parallelizable
  SALT is purely CPU-bound and can be sped up almost linearly by using more CPU cores to update the vector commitments.

The Hidden Performance Killer

Here's a shocking statistic: In Ethereum, updating state, the cryptographic representation of all account balances and data on the blockchain, can take up to 10x longer than actually processing the transactions themselves.

Think about that for a moment.

You spend 1 second running the transaction logic (computing balances, executing smart contracts, doing all the "real work") and then you spend 10 seconds just updating the database to reflect those changes.

Here, we show the range of time wasted across varying hardware configurations of an early version of the Reth client, and the time "wasted" can get pretty dramatic:

Comparing time-wasted across varying hardware configurations processing 100,000 historical Ethereum

This bottleneck comes from the process of updating the Merkle Patricia Trie (MPT). Every time transactions are made, the MPT needs to be updated, and these updates require random disk reads and writes that kill performance.

Blockchain 101: What Is a Merkle Tree?

When people talk about "blockchain state," they're referring to a database that tracks:

• Every account's balance
• Every token balance
• All smart contract storage

Basically, every piece of data that matters on the blockchain.

This database is organized as a Merkle tree, a special data structure that looks like a tree:

• Leaves: The actual data (like "Alice has 5 ETH")
• Nodes: Mathematical fingerprints (hashes) that summarize the data below them
• Root: A single hash at the top that represents the entire state of the blockchain

How Merkle Patricia Trie's inner structure function

The magic of Merkle trees is that you can cryptographically prove any piece of data belongs to the tree using just a small "proof" without having to download the entire database. This is paramount for performant chains as speed (and the associated data) lead to database growth.

Ethereum uses a specific variant called a Merkle Patricia Trie (MPT), which combines this tree structure with efficient key-value storage. The MPT maps keys (representations of wallet addresses) to values (the actual account balances). The MPT's structure lets you quickly find and verify any key-value pair.

E.g., "I have this key [address], give me the value [balance]."

The Sparsity Problem: Why MPTs Are Broken

Here's where things get interesting. MPTs should be efficient, but they have a fatal flaw: sparsity.

Let's make an analogy.

Imagine you're organizing a library with a hierarchical system:

• Level 1: Genre (Fiction, Non-fiction, etc.)
• Level 2: Subgenre (Mystery, Romance, etc.)
• Level 3: Author's last name (A-Z)
• Level 4: Specific book

In a perfect world, every category would be full. But in reality, most categories are nearly empty. Maybe Mystery only has 2 authors, and those authors only wrote 3 books each. You've built this elaborate organizational system, but most of the "shelves" are empty, making the library significantly larger than necessary.

MPTs suffer from the exact same problem. As you go deeper into the tree, nodes become increasingly underutilized. A node that could hold 16 children might only have 2.

The Merkle Patricia Trie analogized to a library, displaying why sparcity becomes a problem

Our researchers discovered that sparsity inflates MPT sizes by hundreds of times compared to the theoretical optimum.

This creates massive waste as nodes are underutilized, and more nodes than ideal are needed to store the entire state, causing the tree to grow too large to fit in RAM.

The RAM vs Disk Catastrophe

Here's where the performance killer reveals itself: RAM is fast, disks are slow (even modern SSDs) .

When you update an MPT, you need to trace a path from the changed data all the way back to the root, updating every node along the way. With the majority of these nodes scattered randomly throughout the disk, the system is forced to perform random disk I/O operations in order to access and update them.

This is notable because even the fastest SSDs are orders of magnitude slower than RAM for random access patterns, so optimal conditions would be to only have to access RAM for this task.

To reduce the amount of time wasted on disk I/O, the obvious solution would be to keep the entire MPT in RAM, but recall what we covered regarding sparsity; MPTs at deeper levels become so bloated that they balloon storage requirements, and to accommodate them would explode the validator hardware costs. So they spill onto slower disk storage, killing performance and creating the slowdown we see in blockchains today.

Enter SALT: Taming the Sparsity Beast

SALT takes a radically different approach. Instead of trying to fix MPTs, we replaced them entirely with a two-tier architecture designed around one core insight:

Not all parts of the tree are equally sparse.

The top levels of any tree tend to be well-utilized (lots of data flows through them), while the bottom levels are sparse (each branch only has a few items).

Reviewing MPT constructions through a storage requirement lens

SALT embraces this reality by using two completely different approaches for each tier:

• A complete tree where every node utilizes each of its children (no empty slots)
• Every node is guaranteed to be full (no wasted space)
• Stays entirely in RAM
• Provides fast cryptographic proofs for the overall structure

• Flat lists that handle sparse data efficiently
• No tree structure means no wasted intermediate nodes
• Stays on the disk but only incurs one I/O request per state update (thus being optimal)

The key insight: Instead of forcing sparse data into tree structures (which creates tons of mostly-empty nodes), SALT flattens sparse data into simple lists.

Think of it like this: Rather than building an elaborate filing system with mostly empty shelves (traditional MPT), SALT creates a small, efficient index in your office (the main trie) that points to storage units (buckets) where the actual files are kept in simple, uniform piles.

A view of SALT's data structure

Why this matters: In traditional MPTs, storing 1000 account balances creates a sparse tree with dozens of intermediate nodes, each requiring its own cryptographic hash. When you update an account, you need to perform random disk I/O to update multiple hashes along the path.

With SALT buckets, those same 1000 balances get exactly one cryptographic commitment (MegaETH uses Vector Commitment instead of Hashes) that represents the entire bucket. Instead of dozens of individual hashes, you have just 1 commitment per bucket, regardless of whether that bucket contains 10 accounts or 10,000 accounts.

When you update an account, you:

• Update the bucket (efficient, no tree traversal needed within the bucket)
• Recompute the single Vector Commitment for that bucket
• Update the Vector Commitments along the fixed path up the main trie (fast, because it's in RAM)

The Performance Revolution

The numbers speak for themselves:

SALT vs MPT Storage Efficiency:

• MPT: ~16.8 GB for 1.5 billion keys
• SALT: ~1 GB for 4.3 billion keys

SALT achieves 0.25 bytes per key overhead , essentially optimal efficiency.

A performance metric comparison of SALT vs a traditional MPT

Moreover, SALT’s main trie has a fixed size, and buckets grow efficiently, so adding more accounts doesn’t noticeably degrade performance. This is crucial for massively scalable ecosystems.