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.
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.
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.
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).
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.