SonicDB S6: A Storage-Efficient Verkle Trie for High-Throughput Blockchains

Abstract: The Ethereum state database uses Merkle Patricia Trie (MPT), which suffers from large witness proof sizes and high storage overhead. Verkle Tries have been proposed as a replacement, offering witness proofs below 150 bytes through vector commitments and Inner Product Argument aggregation. However, deploying a Verkle Trie in a high-throughput, short block-time blockchain such as Sonic, which produces a block every 300 milliseconds, introduces substantial engineering challenges related to storage efficiency, commitment computation costs, and the need to serve both live and historical state queries in real time. We present SonicDB S6, a production Rust Verkle Trie database for the Sonic blockchain, which leverages its non-forking property to enable aggressive storage optimizations. Occupancy-aware node specializations, selected via an O(kn2) dynamic program, reduce live storage by 98%. Delta nodes that record only changed slots reduce archive storage by 95%. Batched updates, multi-threaded commitment computation, and homomorphic Pedersen caching yield 2.85x higher throughput than a persistent Geth Verkle baseline while sustaining production block-rate performance.

• The paper presents SonicDB S6, which overcomes storage inefficiencies in high-throughput blockchains by leveraging occupancy-aware node specialization and delta nodes.
• It employs a dual-mode storage architecture—LiveDB for current state and ArchiveDB for historical queries—achieving up to 98% storage reduction in LiveDB.
• The design integrates multi-threaded cryptographic commitment updates and a dynamic programming approach for specialization selection, boosting throughput by 2.85×.

SonicDB S6: Storage-Efficient Verkle Tries for High-Throughput Blockchains

Introduction and Motivation

The rapid block times characterizing modern high-throughput blockchains such as Sonic impose severe constraints on state storage and access. The longstanding Merkle Patricia Trie (MPT) used by Ethereum exhibits both storage inefficiency and prohibitive witness proof sizes, limiting the practicality of stateless validation and high-frequency archival state queries. Vector-commitment-based Verkle tries promise drastically reduced witness sizes and greater structural regularity but introduce incremental storage and computation bottlenecks, especially when deployed in subsecond block environments. The SonicDB S6 system is engineered to overcome these limitations by leveraging Sonic's non-forking execution property, introducing novel engineering approaches to Verkle trie storage, update, and proof generation.

Figure 1: Ethereum Verkle Trie structure.

Dual-Mode Storage Architecture: LiveDB and ArchiveDB

SonicDB S6 explicitly separates storage into a strictly in-place LiveDB and a fully persistent ArchiveDB, exploiting the non-forking guarantee of the Sonic blockchain. LiveDB maintains only the current state and serves validator requirements, supporting destructive, occupancy-aware node layouts with aggressive node specialization and storage reclamation. ArchiveDB, conversely, implements versioned copy-on-write semantics to ensure that any historical block state is retrievable, but with minimal I/O and storage amplification through delta nodes and sparse specialization.

Figure 2: LiveDB update of a single leaf node. Because no historical data is retained, changes are applied in place.

Figure 3: ArchiveDB update of a single leaf node. The changed node is copied and updated, and every ancestor up to the root is duplicated and updated with its new child identifier.

Delta nodes in ArchiveDB record only the slots which have changed relative to a base node, under a tunable threshold $\tau$. This avoids chaining and ensures that any lookup requires at most two node reads, yielding predictable and bounded read amplification even at extreme chain heights.

Figure 4: Conversion between a base node and a delta node with delta size $\tau = 4$.

Figure 5: Loading a delta node: the on-disk form is read first, then the base node is fetched and merged to produce the materialized view.

Occupancy-Aware Node Specialization and Optimization

The central storage optimization is realized via coarse-grained but occupancy-aware node specializations. Rather than allocating all 256 slots in every Verkle node (as would be naive for a $b=256$-branch trie), specializations enable memory layout tuned to the true number of non-empty children or values (as observed empirically, the majority of nodes are extremely sparse).

Figure 6: Full node

The specialization space is defined precisely—a node with $i$ actual children or values can reside in a specialization supporting up to $j \geq i$. The problem of optimally selecting the set of such specializations (given observed node occupancy distributions and storage cost models) is formalized and expressed as an $\mathcal{O}(k n^2)$ dynamic programming problem. This approach enables S6 to select, for a given $k$, the set of specialization boundaries that optimize the trade-off between storage footprint and runtime migration overhead.

Figure 7: Reusable vs. total node counts and used node counts of a LiveDB.

Figure 8: Pareto frontier - Size vs Mgas/s Leaf Specializations.

On empirical data from Sonic's mainnet, a configuration with just 10 specialization types reduces LiveDB storage by 98% with negligible throughput penalty compared to denser specialization schemes.

Implementation Layers and Commitment Optimization

SonicDB S6 is engineered as a five-layered architecture that partitions concerns between transaction management, trie update logic, node management (including advanced caching and lock-guarded access via quick_cache), low-level storage, and parallel file I/O. Each layer contributes optimizations tuned to the unique read-write and durability requirements of stateful and archival queries.

Figure 9: Layered Architecture

Concurrency is supported via transaction batching, batched trie path traversal, and concurrent I/O. Pedersen vector commitments—the cryptographic foundation of Verkle tries—are a computational bottleneck. S6 leverages incremental commitment updates via the Pedersen homomorphism, windowed multi-scalar multiplication with adaptive precomputations, and dynamic thread-parallel work-stealing traversal of the dirty set to cap commitment recomputation time within the strict block-finalization deadline. For nodes with only a few slot mutations, incremental updates avoid full group operation costs.

Performance and Scaling Evaluation

The most significant empirical claims, substantiated by extensive benchmarking over 40–55 million blocks, are:

• LiveDB storage reduction by 98% (1,078 GiB → 22 GiB) using optimized specializations.
• ArchiveDB storage reduction by 95% (16,141 GiB → 809 GiB) when combining delta nodes and node specializations.
• End-to-end database throughput is $2.85\times$ higher than a persistent Geth Verkle + LevelDB baseline, with LiveDB 3.2x faster and ArchiveDB lagging by only ~24%, sufficient for real-time archival replay at one block per 300 ms.

  Figure 10: LiveDB vs Geth Verkle (LevelDB) performance for the first 40M blocks.

  

  Figure 11: LiveDB vs ArchiveDb performance for the first 40M blocks.

  

  Figure 12: Archive DB growth rate with different combinations of delta node implementations.

The data further confirm that the number of non-null slots in most nodes is extremely low, establishing that unoptimized approaches would dramatically over-spend on disk allocations if dense representations are not mitigated.

Implications and Future Directions

The architectural decisions behind SonicDB S6 hold broad implications for both practical blockchain system deployment and the evolution of authenticated data structures under high-rate, low-latency constraints. By clearly separating obligations for state mutability (live) and full historical access (archive), S6 demonstrates that non-forking protocols provide a fundamentally different substrate for aggressive storage and I/O optimization. The design of delta nodes (no chaining, bounded read amplification), optimal node specialization selection, and multi-threaded cryptographic recomputations suggest strategies applicable beyond Verkle tries, including other vector-commitment-based authenticated dictionaries and stateless client architectures.

Fine-grained dynamic management of node layout and concurrent resource access is critical not just for storage savings but also for sustaining validator throughput under severe block time constraints. The same techniques may enable scalability breakthroughs for stateless clients and high-frequency blockchains more broadly. For theoretical work, the dynamic programming formulation for specialization selection and the empirical measurement of storage-access trade-offs could be extended to adaptive, workload-aware specialization at runtime.

Given the strong empirical reductions in both state size and computation time, future research may explore hybrid trie structures, cross-layer proof aggregation for enhanced statelessness, and deeper hardware/software co-designs for cryptographic vector commitment computation.

Conclusion

SonicDB S6 delivers a storage and computationally efficient Verkle trie system, tailored for the Sonic blockchain but with relevance to the design of high-performance, authenticated state databases. Core contributions include occupancy-aware node specializations selected via rigorous optimization, delta nodes with bounded read and write amplification for archival queries, and a multi-threaded, multi-layered commitment computation pipeline. The design attains dramatic reductions in disk space and significant throughput improvements over prior Verkle trie deployments. These results validate the underlying design philosophy and chart a direction for future work on scaling authenticated data structures in blockchain and related settings (2604.06579).