Skip to main content

​
Motivation

​
The State Root Performance Problem

Every blockchain needs to commit to its state prove that current balances, positions, and data are correct. Ethereum and most chains use full Merkle state roots: recompute the entire tree, hash it, commit. This works. But for high-frequency financial workloads, it’s wasteful. Traditional Merkle Patricia Tries incur O(n log n) costs for global state updates. The bottleneck is disk I/O, not computation. For a binary MPT with billions of keys, this translates to dozens of random disk reads per state update. Recent analysis shows that state root computation can cause up to 10x slowdown in block building. Think about a trading system. In a 75ms block, maybe 10,000 orders execute. But total state all accounts, all positions, all balances might be millions of entries. Recomputing a full Merkle root every block means hashing data that didn’t change.

​
Change-Log Hash Commitments (CLH)

DracoBFT replaces state root computation with Change-Log Hashes computed during block execution. Rather than committing to the entire state, CLH commits only to state modifications. CLH is a lightweight state commitment mechanism with O(m) complexity that replaces O(n log n) global state root computation, where m is the number of unique keys modified per block (typically m ≪ n for state size n).

​
Block-Level Aggregation

If 400 transactions modify the same key, CLH hashes it once (final value), not 400 times.
SystemHash Operations (400 txns, 1 key)
Ethereum MPT~4,000
Tendermint IAVL~2,000
Naive CLH400
DracoBFT CLH1
For order book updates where a single price level may be modified by hundreds of trades within a block, this optimization eliminates 99.75% of hashing operations. Block-level aggregation ensures keys modified multiple times within a block are hashed only once, dramatically reducing I/O for high-frequency workloads.

​
Chained CLH

chainedCLH_B = H(chainedCLH_prev + finalizedCLH_B)
The chained CLH links finalized state across blocks, enabling early fork detection and historical state verification. Only the keys modified in a block get hashed and chained forward. If your account didn’t change this block, we don’t touch it. The commitment chain grows incrementally, not recomputed globally. For financial workloads where a small portion of state changes per block but latency requirements are strict, this is the difference between “we can theoretically handle this throughput” and “we can handle this throughput at the latency real trading demands.”

​
CLH vs other state-commitment approaches

CLH: Pros and Cons