Scale or Die at Accelerate 2025: Scaling State on Solana: Batched Merkle Trees & ZK Compression

Solana is set to revolutionize blockchain scalability with the introduction of Batched Merkle Trees and ZK Compression V2, promising up to 250x improvements in efficiency and opening up new possibilities for developers across the ecosystem.

Summary

In a groundbreaking presentation at Accelerate 2025, George, a key figure in Solana's development team, unveiled the latest advancements in state compression technology. The talk focused on a new type of Merkle tree implementation, dubbed "Batched Merkle Trees," which forms the backbone of the upcoming Compression V2 update.

This innovative approach aims to dramatically scale Solana's state beyond its current account model, offering cheaper state management for long-tail applications without compromising on concurrency or parallelization. By leveraging zero-knowledge (ZK) proofs and optimizing Merkle tree operations, Solana is tackling one of the most pressing challenges in blockchain technology: efficient state management at scale.

The new Batched Merkle Trees system introduces significant improvements over the current state-of-the-art, particularly in terms of compute unit efficiency and transaction data optimization. This leap forward promises to make Solana even more attractive for developers building complex, data-intensive applications on the blockchain.

Key Points:

State Compression and ZK Proofs

State compression on Solana aims to scale the blockchain's state beyond the current account model, providing cheaper state management for a wide range of applications. This is achieved by trading compute units and instruction data for rent, effectively eliminating the need for users to pay rent on their data.

The process involves committing state to a Merkle tree, then using proofs to verify and mutate that state when needed. Zero-knowledge proofs, specifically zk-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) proofs, are employed to maintain a constant proof size regardless of the amount of data being proven. This approach optimizes instruction data usage and allows for efficient state updates.

Current Merkle Tree Implementation and Its Limitations

The current implementation of Merkle trees on Solana, while functional, has several limitations. Updates to the Merkle tree require sending Merkle proofs in the instruction data, which can quickly fill up transaction space. While techniques like using a canopy (storing more nodes on-chain) can mitigate this, it doesn't fully solve the problem, especially for multiple Merkle proofs.

Additionally, even when using ZK proofs to compress Merkle proofs, there's still the issue of not having enough information to update the state root directly. The current workaround involves using a queue system where a third-party actor sends Merkle proofs on behalf of users, but this still involves significant on-chain hashing, which is computationally expensive.

Batched Merkle Trees: A New Approach

Batched Merkle Trees represent a significant leap forward in addressing the limitations of the current system. The core idea is to batch as much of the hashing and Merkle tree operations as possible into ZK proofs. This includes not just the inclusion proofs (which are already done in the current system) but also the Merkle tree updates themselves.

The new architecture introduces two queue accounts: an append queue and an update queue. Users interact primarily with these queues rather than directly with the Merkle tree. A node server performs the actual Merkle root updates and computes the more computationally intensive ZK proofs.

This approach allows for massive batching of operations, leading to significant efficiency gains. For instance, append operations see a 20x improvement, while update operations see a 14x improvement compared to the current concurrent Merkle tree implementation. Importantly, these batch operations are independent of tree height, making them scalable for trees of any size.

ZK Compression V2: Putting It All Together

The Batched Merkle Trees concept is a key component of the upcoming ZK Compression V2 update. This new version uses three height-32 Merkle trees (up from height-26 in the previous version) and brings substantial improvements across various operations:

• Account creation sees a 1.6x improvement
• Account updates see a 3.5x improvement when proving by index, and a 1.3x improvement when proving by ZK proof
• Merkle tree update operations see a massive 250x improvement

Perhaps most impressively, because the instruction data for Merkle tree update operations is now less than 200 bytes, up to five of these operations can be included in a single transaction, potentially leading to even greater efficiency gains in practice.

Facts + Figures

• ZK Compression V2 is set to launch in Q2 2025
• The new system uses three height-32 Merkle trees, up from height-26 in the previous version
• Append operations see a 20x improvement with Batched Merkle Trees
• Update operations see a 14x improvement
• Merkle tree update operations see a 250x improvement in efficiency
• Account creation is 1.6x more efficient in the new system
• Account updates are 3.5x more efficient when proving by index
• Account updates are 1.3x more efficient when proving by ZK proof
• Instruction data for Merkle tree update operations is now less than 200 bytes
• Up to five Merkle tree update operations can be included in a single transaction
• The new system uses 600 hash chains for batching operations
• Bloom filters are used to ensure uniqueness of queued updates
• Batched operations are completely independent of tree height, allowing for scalability

Top quotes

1. "We want to scale Solana state beyond the Solana account model with cheaper state for every long tail application without sacrificing concurrency and parallelization."

2. "One Merkle proof and a ZK proof is 128 bytes. Eight Merkle proofs are still 128 bytes. You can use it nicely to optimize the instruction data."

3. "The idea behind batch Merkle is very simple. You want to batch all of these hashing everything you can into ZK proofs."

4. "In comparison to the concurrent Merkle tree, the batch Merkle tree gets us 20x for append operations and a 14x for update operations."

5. "These gains translate quite nicely into the Compression V2. So in the Compression V2, we use 3 out of height 32. Up from 26 before, for a calculation, we get a 1.6x improvement."

Questions Answered

What is the main goal of Solana's new state compression technology?

The main goal of Solana's new state compression technology is to scale the blockchain's state beyond the current account model. It aims to provide cheaper state management for a wide range of applications, particularly long-tail applications, without sacrificing concurrency or parallelization. This technology trades compute units and instruction data for rent, effectively allowing users to store and manage data more efficiently on the Solana blockchain.

How do Batched Merkle Trees improve upon the current Merkle tree implementation?

Batched Merkle Trees improve upon the current implementation by batching as much of the hashing and Merkle tree operations as possible into ZK proofs. This includes both inclusion proofs and Merkle tree updates. The new system uses queue accounts for appends and updates, allowing users to interact primarily with these queues rather than directly with the Merkle tree. This approach leads to significant efficiency gains, with append operations seeing a 20x improvement and update operations seeing a 14x improvement compared to the current concurrent Merkle tree implementation.

What are the key benefits of ZK Compression V2?

ZK Compression V2 brings several key benefits to the Solana ecosystem. It uses three height-32 Merkle trees (up from height-26 in the previous version) and offers substantial improvements across various operations. Account creation sees a 1.6x improvement, account updates see up to a 3.5x improvement, and Merkle tree update operations see a massive 250x improvement in efficiency. Additionally, because the instruction data for Merkle tree update operations is now less than 200 bytes, up to five of these operations can be included in a single transaction, potentially leading to even greater efficiency gains in practice.

How does the new system handle the uniqueness of queued updates?

The new system uses Bloom filters to ensure the uniqueness of queued updates. Bloom filters are very efficient data structures for this purpose. To overcome the difficulty of deleting individual values from a Bloom filter, the system uses two filters. It fills up the first one, and once the second one is filled to a certain extent, it wipes the first one completely. This rotation between two Bloom filters allows the system to maintain uniqueness without the need for individual value deletions.

When is ZK Compression V2 expected to launch?

According to the presentation, ZK Compression V2 is currently in audit and is expected to launch in Q2 of 2025. The technology is open source, allowing developers and researchers to examine and potentially contribute to its development.