Solana’s SIMD-223 upgrade marked a significant evolution in blockchain technology. It made state hashing more efficient and helped the network to scale better, even with billions of accounts. By reducing validator CPU usage and increasing TPS, this upgrade builds a stronger foundation for running high-performance dApps at scale. Besides improvement on network consensus, it introduces challenges regarding the validator upgradation logic. Validators must synchronise upgrades carefully to avoid forks, which could disrupt consensus. This change supports Solana’s rapid scaling while preserving its high-throughput architecture.
This case study evaluates Solana's transition from Merkle tree-based state hashing, focusing on the implications of SIMD-215 and SIMD-223.
1. System Architecture & Technical Analysis
Role and Purpose of the Accounts Delta Hash:
The Accounts Delta Hash is a Merkle-based hash of the accounts modified in a block. It is included in the bank hash calculation during the block freezing process and tracks account modifications for each block. The hash is derived from the delta state of accounts in a slot and includes the previous bank hash value. Initially, the Accounts Delta Hash was essential for block verification, as it was used to track accounts for modifications within each block. It also serves security purposes. For instance, when a validator boots up from a snapshot, it needs to quickly verify that the account set matches what the rest of the network sees. The hash is combined with the previous bank hash value to maintain a chain of trust.
Impact of SIMD-215 on Solana’s Hashing Model:
With SIMD-215, Solana moved away from its Merkle tree-based model and adopted a new hash method called the Accounts Lattice Hash, powered by the homomorphic LtHash function. Each account’s 2048-byte data is hashed using LtHash(a) and then added to the block’s bank hash. This helps speed up processing while keeping it secure. Unlike the previous model, every block includes a hash of all accounts, not just those modified. This scheme supports incremental updates, improves consensus with high scalability and TPS throughput, eliminates CPU computational bottlenecks, and provides 128-bit post-quantum security. It replaces the dual Accounts Delta Hash and Epoch Accounts Hash model. State changes are updated by subtracting old LtHash(a) values and adding new ones. These updates are reflected in the Accounts Lattice Hash, which represents all modified accounts in a block.
Removing Accounts Delta Hash: Modifications and Block Processing Impact:
SIMD-223 removes the Accounts Delta Hash from the bank hash, which is redundant after SIMD-215 introduced the Accounts Lattice Hash. The Accounts Lattice Hash replaces both the Accounts Delta Hash and the Epoch Accounts Hash, streamlining consensus and eliminating the latter upon feature activation—a consensus-breaking change. Solana’s bank hash now includes the Accounts Lattice Hash. As part of this update, the Merkle tree logic was removed, and calculations no longer rely on the Accounts Delta Hash. Thanks to these updates, sealing time is shorter and block processing is faster. That’s because LtHash scales linearly, unlike Merkle’s O(n log n). Validators must adjust their consensus logic to verify the state using only the Accounts Lattice Hash. This streamlines block processing, enabling higher transactions per second (TPS).
2. Validator Performance & Scalability
Impact of Change on Block Production and Validator Efficiency:
SIMD-223 eliminates Merkle tree construction (O(n log n)), reducing CPU load and enabling faster block production. The Accounts Lattice Hash allows for linear state updates, which speeds up block sealing. That means higher throughput and better support for demanding, low-latency dApps. The new approach reduces the CPU load during per-block hashing and speeds up validation. It also opens the door to higher throughput, possibly boosting TPS by hundreds or even thousands. Validators now skip Merkle hashing for each modified account, easing the computational burden. This supports Solana’s goal of scaling to billions of accounts. The Accounts Lattice Hash offers efficient state verification without per-block Merkle hashing, making block production more efficient by eliminating the need to compute the Accounts Delta Hash.
Hashing Overhead Comparison
- Pre-SIMD-215: Epoch Accounts Hash (infrequent, high cost) + Accounts Delta Hash (per block, moderate fee).
- Post-SIMD-215: Accounts Lattice Hash (per block, low cost) + Accounts Delta Hash.
- Post-SIMD-223: Accounts Lattice Hash reduces CPU load, enabling faster block production. This streamlines validators' processing of blocks, aligning with low-latency execution.
Impact on Solana's Scalability
SIMD-223 supports large-scale state sizes with minimal latency by replacing the Accounts Delta Hash with the Accounts Lattice Hash, eliminating costly Merkle tree computations. Its linear-scaling updates boost TPS, enabling low-latency dApps in a high-throughput architecture.
3. Comparison with Other Blockchains
Solana's Account Model and Hashing vs. Other Blockchains:
One thing that sets Solana apart is its account model. Everything — from programs to wallets — is just an account with data, lamports, and an owner. That’s a big shift from models like Ethereum’s EOAS and contracts, NEAR’s named accounts, or Bitcoin’s UTXO-based setup. Owner programs with PDAS manage modifications, unlike key-based systems in others. Smart contracts separate code/state for parallel execution, unlike Ethereum’s unified model. Base58/PDAS addresses are less user-friendly than Ethereum’s ENS. Solana’s parallel processing boosts throughput, unlike Ethereum’s sequential EVM. Unlike Ethereum’s Keccak-256 or Polkadot’s BLAKE2, Solana's Merkle-Tree optimises Proof-of-History.
Solana's State Updates vs. Ethereum, Polkadot, and Other L1S:
In Ethereum, the Merkle trie-based state requires the state to be updated as each transaction is processed. This involves recomputing affected trie nodes with every block and modification, which adds overhead to state changes. Polkadot uses BABE/GRANDPA to manage state updates per parachain. Post-SIMD-223, Solana’s ltHash approach enhances efficiency by eliminating redundant hashing inherent in the Merkle-tree-based model. It enables parallel computation, aligning with Solana’s parallel execution model, offering superior scalability over Ethereum and Polkadot.
Removing Merkle-Based Hashing and Solana’s High-Throughput Architecture:
In Ethereum, the Merkle trie-based state requires the state to be updated as each transaction is processed. This involves recomputing affected trie nodes with every block and modification, which adds overhead to state changes. Polkadot uses BABE/GRANDPA to manage state updates per parachain. Post-SIMD-223, Solana’s ltHash approach enhances efficiency by eliminating redundant hashing inherent in the Merkle-tree-based model. It enables parallel computation, aligning with Solana’s parallel execution model, offering superior scalability over Ethereum and Polkadot.
Removing Merkle-Based Hashing and Solana’s High-Throughput Architecture:
Removing the Merkle-based hashing (Accounts Delta Hash) from Solana’s consensus-critical path aligns with its high-throughput architecture, as the homomorphic ltHash scales linearly with account changes. Merkle trees hinder high-TPS performance, unlike Solana’s LtHash. The trade-off is the loss of direct inclusion proofs. However, Solana’s new approach provides full-state commitment, supporting its high-throughput infrastructure for applications requiring instant finality, unlike Ethereum’s slower, Merkle-based confirmations.
4. Risk and Trade-Offs
Non-Backwards Compatible Change: Impact on Network Consensus:
SIMD-223 and SIMD-215 modify the bank hash by removing the Accounts Delta Hash. As a result, these upgrades are not backwards compatible — nodes running older versions will no longer be able to stay in consensus. Validators must upgrade to compute only the Accounts Lattice Hash, necessitating a coordinated hard fork.
Steps validators must take to adopt the change:
Validators must upgrade to the updated Agave validator codebase following the activation of SIMD-223/215. Pre-computation of the Accounts Lattice Hash is recommended. Monitor fork risks during the transition and adapt procedures to accommodate changes in the bank hash.
Risks and challenges of removing Accounts Delta Hash:
If some validators lag, forks may occur, disrupting Solana’s transaction inclusion guarantees. The Accounts Lattice Hash’s reliance on lattice-based cryptography assumes 128-bit collision resistance, with untested edge cases in large-scale deployments. Snapshot hashes could cause state mismatches. The ltHash’s lack of Merkle-style inclusion proofs may impact certain use cases. Prevent forks with a validator dashboard to monitor adoption.
Trade-offs and alternatives:
The ltHash’s 128-bit security (BLAKE3) is robust but lacks Merkle proofs, impacting light clients and cross-chain bridges. Verkle trees were considered but deemed too slow for Solana. Other alternatives, such as incremental hashing based on elliptic curves and XOR accumulators, were evaluated and rejected for performance or security reasons. The LtHash balances speed and security, increasing reliance on full nodes for state verification.
5. Solana Hash System Improvement: Executive Summary
SIMD-223 supercharges Solana, making it faster, scalable, and ready for billions of users and apps.
Before and After Comparison:
Old System Approach And Analogy:
Old system is slow and complex hashing, like rewriting and entire book to change a page.
New System Approach And Analogy:
Fast, Simple Hashing and updating only the changed page.
Conclusion:
The SIMD-223 upgrade marks a major milestone in Solana’s evolution, replacing the inefficient Merkle-based Accounts Delta Hash with the high-performance Accounts Lattice Hash. This delivers significantly lower CPU usage, faster block sealing, and improved scalability to support billions of accounts and higher TPS.
While the non-backwards-compatible change requires careful validator coordination to avoid forks, the gains in efficiency and throughput strongly reinforce Solana’s high-performance architecture.
Overall, SIMD-223 strengthens Solana’s position as a leading high-throughput blockchain, better equipped for large-scale dApp adoption.
Top comments (0)