Mhot: Height-Optimized Authenticated Data Structure
for Blockchain State Commitment

Ethereum stores its state in a Merkle Patricia Trie (MPT). To locate a value, the trie reads the key one hex digit at a time and follows the matching child pointer downward. When two keys share a prefix, they ride the same path until their digits diverge, at which point the trie forks. Branches that only a single key traverses are not kept as individual levels. Instead, the whole stretch is compressed into one node that remembers the shared prefix. Values sit at the leaves. Formally, the forking nodes are branch nodes, the compressed stretches are extension nodes, and the value-bearing endpoints are leaf nodes. This design, a Patricia-compressed radix trie, strips out unary chains but preserves the fixed-prefix indexing rule. Every update walks a root-to-leaf path, so changing any entry recomputes hashes along that whole path.

Ethereum implements this trie with content-addressed, copy-on-write nodes. Each materialized node is identified by the hash of its serialized content. Modifying a key-value pair creates a new leaf representation and recomputes hashes along the path from that leaf to the root (Figure 1). For a realized path of depth $d$, one state modification requires $O(d)$ hash computations and $O(d)$ node writes or lookups. Measurements show that average MPT depth on Ethereum mainnet has grown from 8 to 11 levels as state size increases. A single block now triggers over 8,700 disk I/O operations [chainkv].

This depth-dependent performance creates a denial-of-service (DoS) vector. The Nurgle attack [nurgle] exploits the MPT’s prefix-based indexing and Patricia compression to deepen realized trie paths. Attackers search for keys whose hashed trie indices share long prefixes with existing keys. Because the MPT routes keys by prefix, these keys traverse the same trie region before diverging. When such a key is inserted into a region where Patricia compression has collapsed a long shared prefix into one extension node, the insertion forces that node to split. A compressed path is materialized into additional branch and extension nodes, increasing the realized root-to-leaf depth by 1–2 levels per insertion. Later accesses to the affected keys require more node traversals, hash verifications, and disk lookups. Because Ethereum’s gas pricing charges per opcode rather than per node traversed [nurgle], the attacker pays almost nothing while validators absorb the I/O cost of the deepened paths. Current mitigations, including historical data pruning [eip4444] and gas repricing [eip4762], address symptoms rather than the structural root cause.

These mitigations improve normal-case performance and can reduce the short-term cost of adversarial accesses, but they do not remove the local depth mechanism exploited by Nurgle [nurgle]. If a shard, checkpoint, or cache-backed component still uses a fixed-prefix trie, an adversary can target keys whose distinguishing prefixes fall below the cached or partitioned boundary. The attack surface narrows or shifts, but the local tree still routes by fixed prefixes.

With a fixed 16-ary branching factor, each node consumes 4 prefix bits per level, so 256-bit keys have worst-case depth 64. Storage and system-level mitigations therefore complement, rather than replace, a local authenticated structure whose height resists adversarial prefix construction.

Both Verkle trees and LVMT require trusted setup ceremonies whose compromise would enable proof forgery. Their pairing-based verification also imposes higher costs on resource-constrained light clients than standard hashing does. LVMT inherits the Authenticated Multipoint Evaluation Tree’s in-place update model and thus cannot support historical state queries [lvmt, amt]. Neither natively supports range proofs, proofs that all keys within a specified interval satisfy certain properties, a capability essential for state synchronization protocols.

Prefix-based indexing is the shared root cause of both camps’ limitations. Storage-layer optimizations preserve transparency and range proofs but inherit Nurgle vulnerability because their low span cannot absorb adversarial insertions. Cryptographic solutions achieve Nurgle resistance through high span but sacrifice transparency and range proofs. Achieving attack-resistant depth without these trade-offs requires an indexing paradigm that decouples span from fanout.

An authenticated data structure (ADS) allows an untrusted prover to certify data-operation correctness without requiring the verifier to possess the entire dataset [ads]. Formally, an ADS provides three core primitives.

• $\bullet$

  Commit. Given a dataset $D$, produce a short cryptographic digest $C$ that binds to $D$. In blockchain terminology, $C$ corresponds to the state root stored in block headers.

• $\bullet$

  Prove. Given a query $q$ and its result $a$, generate a proof $\pi$ demonstrating that $a$ is the correct answer for $q$ under the committed dataset.

• $\bullet$

  Verify. Given the commitment $C$, query $q$, claimed result $a$, and proof $\pi$, compute $\texttt{Verify}(C,q,a,\pi)\in\{0,1\}$ to determine whether $a$ is authentic.

A secure ADS has two properties. Computational binding makes proof forgery computationally infeasible. Succinctness bounds proof size $|\pi|$ and verification time to $O(\log|D|)$, with some constructions achieving $O(1)$ for both [verkle, kzg].

Consensus protocols agree only on block headers containing the state root, not the full state. Blockchains therefore rely on ADS to make these compact commitments verifiable, enabling light clients to verify query responses against the block header rather than trusting RPC providers.

Modern execution clients (e.g., Erigon [erigon], Reth [reth]) decouple plain state storage from ADS. The underlying database handles execution-layer I/O directly, while the client propagates state updates to ADS for commitment maintenance. Under this architecture, the ADS functions as a dedicated commitment engine. Its primary performance metric is write throughput, measured as batch updates committed per second.

HOT [hot] breaks exponential coupling (§2.2) by branching on discriminative bits rather than contiguous prefixes. Given a set of keys $K$ within a subtree, a bit position $i$ is discriminative if at least two keys in $K$ differ at that position. The discriminative bit positions of $K$ are

Prefix-based indexing, in contrast, consumes a fixed block of contiguous bits at each level regardless of whether those bits distinguish any keys.

Discriminative-bit indexing couples span and fanout linearly. A compound node with fanout $k$ consumes up to $k-1$ discriminative bits at arbitrary positions. A prefix-based node with the same fanout resolves only $\log_{2}k$ contiguous bits per level, requiring far more levels to cover the full key. Concretely, a compound node with $k=27$ entries consumes up to 26 discriminative bits, well within practical limits.

Compound nodes aggregate multiple binary decisions into a single node containing up to $k$ entries, where $k=32$ is typical. Each compound node stores three components. The extraction mask identifies discriminative bit positions within this node’s scope. The sparse partial keys record only the discriminative bits for each entry. The entry data holds either a child pointer or a leaf value.

The result is adaptive span. In dense key regions, a node covers few bit positions with many entries; in sparse regions, a node spans many positions with few entries. Tree height adapts to actual key distribution rather than following fixed prefix widths. For any key set and fanout parameter $k$, HOT achieves provably minimal height among radix tries [hot]. For uniformly random 256-bit keys with $k=32$, this yields a theoretical minimum depth of $\lceil 256/31\rceil=9$ levels, nearly $6\times$ fewer than the 52 levels required by a prefix-based trie with the same fanout ($\log_{2}32=5$ bits per level).

Earlier work measures path length in depth, while HOT uses height following [hot]; both count compound-node hops from root to leaf. HOT defines the height of an internal node $n$ as $h(n)=\max_{i}h(c_{i})+1$, and $h(n)=0$ for leaves. Unequal child heights create height gaps, which allow new nodes to be absorbed without increasing the global tree height.

HOT preserves height optimality via four insertion modes (Figure 2) that adapt the structure based on node height relations [hot]. Only Parent Pull-Up increases global height, while Normal Insert, Leaf Pushdown, and Intermediate Node Creation perform local restructuring that may lengthen individual paths. §6.6 examines whether such local path increases can be exploited for Nurgle-style attacks.

Binna et al. [hot] prove that HOT’s dynamic construction produces the same structure as Static Minimum Height Partitioning (SMHP) [smhp] of the underlying binary Patricia trie. This equivalence guarantees that HOT minimizes compound nodes on any root-to-leaf path.

Structural determinism means that a given key set produces an identical trie structure regardless of insertion order. HOT inherits this property from its underlying Patricia trie representation, since both the Patricia trie and SMHP partitioning are uniquely determined by the key set [hot].

These properties establish HOT as the structural basis for blockchain state commitment, but the original design operates in memory and provides no persistence or authentication.

A blockchain authenticated data structure must satisfy five requirements. Short commit paths reduce the computation per update, directly affecting block execution time. Structural determinism guarantees that identical key sets produce identical tree structures, a prerequisite for validators to agree on state roots. Trust minimization avoids trusted third parties, restricting security assumptions to cryptography alone. Memory efficiency reduces disk I/O by caching frequently accessed state in memory. Attack resistance prevents adversaries from exploiting structural flaws to extend storage paths and exhaust client I/O [eip3102, eip6800, ethereum, eip1186, eip2929, eip150, nurgle].

Short commit paths and structural determinism follow from HOT’s height optimality and greedy partitioning, while memory efficiency derives from adaptive linearized node layout and SIMD-accelerated operations; we validate attack resistance empirically (§6). Two design challenges remain. First, the original HOT’s page-based node identifiers are machine-dependent and carry no cryptographic meaning; content-addressable indexing (§4.2) resolves this by deriving each identifier from the hash of its content, satisfying trust minimization without a trusted setup. Second, embedding authentication in high-fanout compound nodes risks inflating proof size; our authentication mechanism targets logarithmic overhead to keep proofs practical (§4.3).

Indexing HOT nodes demands a custom strategy; approaches that work for conventional tries fail for HOT’s compound-node structure. We consider and reject two naive alternatives before arriving at our solution.

Traditional radix tries index nodes by path prefix, but HOT’s compound nodes track only discriminative bits without recording complete prefixes, so prefix-based indexing does not apply. One might instead use accumulated discriminative bits as identifiers; however, HOT’s insertion algorithm dynamically adjusts which bits are discriminative, causing cascading identifier updates across affected subtrees.

We design Mhot around content-addressable indexing, where each node’s database key equals the hash of its serialized content. This scheme exploits HOT’s structural determinism (§3.2), which guarantees that identical key sets yield identical tree structures. A node’s content depends uniquely on the keys it covers, since extraction masks, sparse partial keys, and child references are all determined by those keys; identical logical nodes therefore produce identical hashes regardless of creation time, so all validators derive the same identifiers for the same state. Hash-based indexing also requires no trusted setup, satisfying the trust minimization requirement.

Like MPT [ethereum], content-addressable storage inherits copy-on-write semantics (see Figure 1), where modifying any node invalidates its hash and all ancestor references. This approach expands child references from the original 4–8-byte pointers to 40-byte identifiers (Figure 3), adding up to ${\sim}1$ KB per fully-populated node at $k=32$. We accept this overhead because uniform, fixed-format references simplify serialization and eliminate branching in traversal code.

Mhot fixes the key length at 256 bits to match the output of Keccak-256 used for Ethereum’s storage key derivation. As a result, extraction masks and sparse partial keys have fixed maximum sizes and are stored in fixed-length fields, while only the child reference array grows dynamically with the number of entries. This layout enables simple, single-pass serialization. Figure 3 illustrates the node structure.

Each compound node embeds $k$ child hashes, so proof size grows linearly with fanout. A naive inclusion proof must contain all $k-1$ sibling hashes at each level so the verifier can reconstruct parent hashes up to the root, yielding $O(h\cdot k)$ hashes per proof. With 32-byte Keccak-256 hashes, this totals $h(k{-}1)\cdot 32\approx 5$ KB for typical parameters ($k=32$, $h=5$).

We address this using a two-layer Merkle architecture that trades additional commitment-time computation for compact proofs. Each compound node computes a Children Merkle Root (CMR), a binary Merkle root over its $k$ child hashes. Membership proofs then include only $O(\log k)$ binary Merkle siblings per node, instead of all $k-1$ child hashes, reducing per-node overhead from $O(k)$ to $O(\log k)$. For $k=32$, this yields roughly a $6\times$ reduction in hash overhead. In practice, single-point proofs are about 1.1–1.4 KB, compared to 2.3–2.9 KB for MPT (§6).

We adopt binary Merkle trees to preserve standard hash-based verification without trusted setup. Although each CMR incurs $O(k)$ hashing cost at commit time, this overhead is absorbed by the batched commit pipeline (§4.4). §5.1 formalizes the construction and extends it to compact multiproofs.

Each insertion rehashes the entire root-to-leaf path. When multiple insertions share ancestors, naive processing repeatedly rehashes the same dirty nodes, i.e., nodes modified since the last commit. We eliminate this redundancy by proposing three optimizations as below.

Copy-on-write occurs at most once per node per block. Once a node enters the pending map with a temporary ID, subsequent traversals update it in place rather than cloning. When an insertion first modifies a finalized node, we clone it into the pending map (Algorithm 1, lines 11–12); subsequent insertions that traverse the same node find a temporary reference and update it in place without cloning (line 9). The resulting memory overhead is $O(h)$ pending nodes per insertion, where $h$ is tree height.

Because HOT records node height as a built-in property, Mhot can use height directly to schedule commit. Nodes at the same height have no Merkle dependencies on one another, so they can be hashed in parallel with one barrier between levels, without fine-grained synchronization or uneven subtree splits. The same height grouping aligns with the storage layout in §4.5, allowing finalized nodes to be flushed in locality-preserving batches. MPT-style tries do not expose this height order directly, so recovering such a schedule requires extra bookkeeping [geth-parallel-node-fetching].

Embedding hashes enlarges node footprint; three techniques mitigate this overhead.

The next section formalizes Mhot’s proof mechanisms (§5), followed by performance evaluation (§6).

The naive approach of including all children’s hashes directly in each proof node yields proof sizes of $O(h\cdot k)$, where $h$ is tree height and $k$ is fanout. For typical parameters ($k=32$, $n=10^{8}$), this produces approximately 5KB per proof—unacceptable for bandwidth-constrained applications.

Mhot addresses this through a two-layer Merkle architecture. The inter-node layer maintains the tree structure connecting compound nodes. The intra-node layer introduces a Merkle tree [merkle] over children within each compound node, enabling logarithmic-size proofs for child membership.

This architecture reduces per-node overhead from $O(k)$ to $O(\log k)$ hashes.

All proof types discussed in the following embed $\Pi_{J}^{\mathrm{CMR}}$ within each node entry, ensuring proof size scales with $O(\log k)$ rather than $O(k)$ per node.

Mhot’s single-point proofs rely on the fact that HOT search constitutes an optimistic search. Unlike traditional Patricia tries where searching for a non-existent key may fail mid-traversal, HOT’s sparse matching semantics guarantee that search always reaches some leaf—though this leaf may differ from the query key. The search only matches discriminative bits at each node; the reached leaf shares all discriminative bit values with the query but is not guaranteed to be lexicographically adjacent. A final comparison between the reached leaf and the query key determines membership.

This invariant unifies membership and non-membership proofs as they both execute identical search algorithms, differing only in the final comparison.

Algorithm 3 presents the verification procedure.

A naive approach to verifying $m$ membership proofs requires $O(m\cdot h\cdot(k-1))$ sibling hashes. Mhot reduces this through two optimizations: path sharing (keys traversing the same node share that node’s metadata) and compact multiproofs (proving $t$ children within a node requires $O(t(\log k-\log t))$ sibling hashes rather than $O(t(k-1))$).

Compact multiproofs exploit shared ancestors among the $m$ proven leaves to eliminate redundant sibling hashes, reducing proof size from the naive $m\cdot h$ to as few as $h+m-1$ when leaves are clustered [merkle-multiproof].

The compact multiproof generation algorithm (Algorithm 5 traverses the tree bottom-up, collecting sibling hashes only for nodes where one child is known but the other is not.

Lower bound queries—finding the smallest key $\geq Q$—are fundamental to range operations in authenticated storage systems. Unlike membership queries where the search target either exists or does not, lower bound queries must locate a key that may differ from the query itself.

In prefix-organized tries such as MPT, siblings represent lexicographically adjacent key ranges, making neighbor identification straightforward. HOT organizes nodes by discriminative bits instead, so siblings may span non-contiguous ranges. We therefore construct lower bound proofs by authenticating the search path that HOT’s bit-comparison traversal follows to locate the smallest key $\geq Q$.

A critical subtlety arises from the nature of optimistic search. The search finds a leaf $K^{\prime}$ that matches the query $Q$ on all discriminative bits encountered during traversal, but $K^{\prime}$ need not be lexicographically close to $Q$—the two may differ arbitrarily on non-discriminative bits. When searching for $Q$ terminates at leaf $K^{\prime}$ where $K^{\prime}\neq Q$, let $d=\mathrm{diffbit}(Q,K^{\prime})$ denote the first differing bit position. Three cases arise:

• $\bullet$

  Exact match ($K^{\prime}=Q$): The query key exists; $K^{\prime}$ is trivially the lower bound.

• $\bullet$

  Overshot ($Q[d]=0$, $K^{\prime}[d]=1$): The search entered a right subtree, so $Q<K^{\prime}$ lexicographically. However, $K^{\prime}$ may not be minimal within this subtree; the true lower bound is the leftmost leaf reachable from the fork point.

• $\bullet$

  Undershot ($Q[d]=1$, $K^{\prime}[d]=0$): The search ended in a left subtree where all keys are less than $Q$. The algorithm must examine right siblings at the fork point to find a subtree containing keys $\geq Q$.

The lower bound proof must authenticate both the leaf $K^{\prime}$ reached by optimistic search and the path to the actual result.

When $K^{\prime}\neq Q$, the adjustment information specifies how to navigate from the search path to the true lower bound:

where $d=\mathrm{diffbit}(Q,K^{\prime})$ is the first differing bit, $b=Q[d]$ indicates overshot ($b=0$) or undershot ($b=1$), $f$ is the fork depth, and AdjPath authenticates the path from the fork point to the result leaf.

Range queries are essential for authenticated storage applications such as blockchain state synchronization, where clients must verify that a returned dataset contains exactly the entries within specified bounds [devp2p, rangeproofimportant]. The central challenge is completeness: an adversarial prover might return a subset of the true range, omitting entries to deceive the verifier.

Mhot constructs range proofs by composing lower bound proofs with multi-point proofs. The lower bound proofs (Section 5.4) establish the range boundaries, while the multi-point proof (Section 5.3) authenticates all entries within.

This rank computation enables $O(1)$ completeness verification: the verifier simply checks whether $|\text{entries}|=\mathrm{rank}(\text{last})-\mathrm{rank}(\text{first})$. If an adversary omits even a single entry, the count mismatch triggers rejection. Algorithm 4 presents the complete verification procedure.

The verification algorithm enforces a critical security invariant: boundary proofs must be verified before accepting any entries. This ordering prevents empty-proof attacks where an adversary provides valid but incomplete entry lists. The rank-based count check then ensures exactly the correct number of entries appears.

Write throughput measures how fast the commitment engine processes batch updates (§3.1). We denote Mhot with asynchronous flush as Mhot-AF (asynchronous flush).

As tree size grows, all systems show throughput degradation. At 500k keys, Mhot-AF maintains 135k ops/s while LVMT drops to 90k ops/s and RainBlock to 50k ops/s. At 1M keys, Mhot-AF delivers 104k ops/s versus MPT’s 17k ops/s (6$\times$), LVMT’s 80k ops/s (1.3$\times$), and RainBlock’s 38k ops/s (2.7$\times$). At larger scales, LVMT’s $O(1)$ root update complexity narrows the gap, though Mhot retains an advantage through reduced tree traversal depth.

As tree size grows, MPT’s WA rises from 2.7 at 100k to 4.8 at 1M keys, reflecting the cost of maintaining deep Merkle paths with per-epoch commits. Mhot maintains WA of 0.9–1.6 across scales, a 3–3.7$\times$ reduction over MPT. LVMT consistently records the lowest WA (0.8–1.0).

Mhot’s batched flush strategy introduces per-epoch variance: most epochs complete with near-zero WA, while flush epochs reach 4–8 depending on accumulated changes. For aggregate storage efficiency (most relevant to long-running nodes), Mhot’s lower WA reduces total I/O over time. LVMT records 10–15% lower WA than Mhot, but incurs 3–4 orders of magnitude higher verification latency (§6.5).

Tree height directly impacts proof size and verification latency. Each additional level requires more node traversals and more sibling hashes in membership proofs.

Mhot maintains stable height of 6 under real-world traces. Its variable-span compound nodes adapt to local key density by packing discriminative bits greedily, absorbing prefix collisions without proportional height increase. This consistency across workloads matters for blockchain deployments where key distributions vary unpredictably.

We evaluate single-point membership proofs across systems (Figure 7 and Table 2), then examine Mhot’s scalability for multi-point and range proofs (Figure 8).

Mhot-Blake3 achieves the most compact proofs across all scales, ranging from 1,139 bytes at 100K keys to 1,423 bytes under real-world traces. LVMT-random produces larger proofs (2,227–3,011 bytes) due to KZG commitment overhead, while LVMT-deepest reveals worst-case behavior with proofs reaching 4,411–19,123 bytes under real traces (13$\times$ larger than Mhot). MPT proofs range from 2,304 to 2,867 bytes, twice Mhot’s size. Mhot’s proof size advantage stems from its two-layer Merkle architecture: the intra-node Merkle tree requires only $O(\log k)$ sibling hashes per node rather than $O(k)$, where $k=32$ is the maximum fanout.

For prove latency, LVMT-random achieves the lowest values (5.1–7.7 $\mu$s), while Mhot-Blake3 (8.9–11.9 $\mu$s) outperforms Mhot-Keccak (31.5–42.5 $\mu$s) by 3.5$\times$ due to Blake3’s lower computational overhead. LVMT-deepest reaches 10.6–61.4 $\mu$s under real traces. MPT (6.2–8.9 $\mu$s) remains stable.

Table 2 presents verification latency. Hash-based schemes (Mhot, MPT) operate in microseconds, while LVMT’s KZG polynomial commitment verification requires milliseconds due to pairing operations. Mhot-Blake3 verifies proofs in 5.3 $\mu$s, comparable to MPT (10–12 $\mu$s) while providing smaller proofs. LVMT’s verification latency of 32–147 ms represents three to four orders of magnitude overhead compared to hash-based schemes, which is a critical trade-off for applications requiring fast verification such as light clients.

The Nurgle attack [nurgle] exploits prefix collisions to inflate tree depth for targeted keys, increasing their proof costs. We evaluate resistance under the threat model where an adversary controls 52 prefix bits (matching the original Nurgle analysis) and commands an entire block’s gas budget (300M gas, approximately 15,000 insertions).

Figure 9 illustrates this effect. Before the attack, 82.3% of keys reside at level 0 and 17.4% at level 1 (average depth 0.18). After inserting 15,000 attack keys targeting specific prefixes, 99.9% of attack keys are placed at level 3, far deeper than legitimate keys. Although existing keys remain unaffected, the polluted prefix regions force any future keys sharing these prefixes to be placed at level 3 or deeper. This behavior constitutes a degradation-of-service attack against future users whose addresses collide with the targeted prefixes.

Reduced commitment latency may also benefit block validation throughput, though quantifying this effect requires end-to-end pipeline evaluation.

Systemic mitigations reorganize state above the local tree. Chainspace [chainspace] splits state across shards and certifies shard-local commitments through quorum signatures, while RainBlock [rainblock] distributes state in DSM-TREE shards and offloads disk access to storage nodes. These designs expose parallelism above the tree at the cost of data placement, network coordination, quorum certification, and cross-shard access, and compose with Mhot, since each shard or checkpoint still requires a local authenticated structure that remains exposed to depth inflation when prefix-based. Mhot fills that local structural role inside layered, partitioned, or checkpointed deployments.