Efficient Forkless Blockchain Databases

TL;DR

The paper tackles the high storage and processing costs of StateDBs in forkless blockchains by introducing two specialized databases: LiveDB for the live state and ArchiveDB for historical archiving. LiveDB employs intrinsic pruning via overwriting and a dense, page-based hash structure, while ArchiveDB uses an append-only, delta-style representation to efficiently record block-by-block changes. The Go-based implementation demonstrates ~100x storage reduction and ~10x throughput improvement over a geth-based Fantom client, with minimal overhead from archiving and careful tuning of page size. The work offers a practical architecture to scale forkless blockchains by separating roles and optimizing both live and archival data handling.

Abstract

Operating nodes in an L1 blockchain remains costly despite recent advances in blockchain technology. One of the most resource-intensive components of a node is the blockchain database, also known as StateDB, that manages balances, nonce, code, and the persistent storage of accounts/smart contracts. Although the blockchain industry has transitioned from forking to forkless chains due to improved consensus protocols, forkless blockchains still rely on legacy forking databases that are suboptimal for their purposes. In this paper, we propose a forkless blockchain database, showing a 100x improvement in storage and a 10x improvement in throughput compared to the geth-based Fantom Blockchain client.

Figures (9)

• Figure 1: Evolution of Merkle Patricia Trie: A new version of state $x_1$ is constructed, resulting in a new state $x_2$ by updating the value $v_4$ to $v_4'$ for the key $b \cdot f$.
• Figure 2: Blockchain Database Architecture: Unspecialized and specialized databases for the assigned roles of nodes.
• Figure 3: Hash calculation mechanism: Hashes are aggregated for attributes/storage values across all accounts, and indexers produce hashes for their stored keys.
• Figure 4: Indexer: An indexer consists of a hash table that maps account addresses/storage keys to record numbers and a reverse lookup table that stores the addresses/keys file-mapped array permitting dense hash calculations on the reverse lookup table.
• Figure 5: Paging mechanism: $\frac{n}{p}$ pages where $p$ elements of an attribute are packed into a page.

Theorems & Definitions (1)

• Example 1