Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

A Fast Ethereum-Compatible Forkless Database

Herbert Jordan, Kamil Jezek, Pavle Subotic, Bernhard Scholz

TL;DR

The paper tackles the storage bottleneck in Ethereum-compatible blockchains using forkless designs by introducing LiveDB and ArchiveDB, native databases with Ethereum-compatible authentication. LiveDB provides a mutable in-memory overlay with a file-mapped on-disk layer to avoid read amplification and enable intrinsic pruning, while ArchiveDB extends the approach to historical data with an append-only, copy-on-write model and selective freezing. The authors demonstrate nearly 10x throughput improvements and substantial storage reductions for validators, plus significant space savings for archive nodes, validated on a real-world Sonic testnet with large-scale replay data. The work offers practical impact by enabling scalable, forkless blockchain deployments that remain compatible with Ethereum proofs and root hashes, potentially accelerating adoption of high-throughput consensus protocols.

Abstract

The State Database of a blockchain stores account data and enables authentication. Modern blockchains use fast consensus protocols to avoid forking, improving throughput and finality. However, Ethereum's StateDB was designed for a forking chain that maintains multiple state versions. While newer blockchains adopt Ethereum's standard for DApp compatibility, they do not require multiple state versions, making legacy Ethereum databases inefficient for fast, non-forking blockchains. Moreover, existing StateDB implementations have been built on key-value stores (e.g., LevelDB), which make them less efficient. This paper introduces a novel state database that is a native database implementation and maintains Ethereum compatibility while being specialized for non-forking blockchains. Our database delivers ten times speedups and 99% space reductions for validators, and a threefold decrease in storage requirements for archive nodes.

A Fast Ethereum-Compatible Forkless Database

TL;DR

The paper tackles the storage bottleneck in Ethereum-compatible blockchains using forkless designs by introducing LiveDB and ArchiveDB, native databases with Ethereum-compatible authentication. LiveDB provides a mutable in-memory overlay with a file-mapped on-disk layer to avoid read amplification and enable intrinsic pruning, while ArchiveDB extends the approach to historical data with an append-only, copy-on-write model and selective freezing. The authors demonstrate nearly 10x throughput improvements and substantial storage reductions for validators, plus significant space savings for archive nodes, validated on a real-world Sonic testnet with large-scale replay data. The work offers practical impact by enabling scalable, forkless blockchain deployments that remain compatible with Ethereum proofs and root hashes, potentially accelerating adoption of high-throughput consensus protocols.

Abstract

The State Database of a blockchain stores account data and enables authentication. Modern blockchains use fast consensus protocols to avoid forking, improving throughput and finality. However, Ethereum's StateDB was designed for a forking chain that maintains multiple state versions. While newer blockchains adopt Ethereum's standard for DApp compatibility, they do not require multiple state versions, making legacy Ethereum databases inefficient for fast, non-forking blockchains. Moreover, existing StateDB implementations have been built on key-value stores (e.g., LevelDB), which make them less efficient. This paper introduces a novel state database that is a native database implementation and maintains Ethereum compatibility while being specialized for non-forking blockchains. Our database delivers ten times speedups and 99% space reductions for validators, and a threefold decrease in storage requirements for archive nodes.

Paper Structure

This paper contains 24 sections, 13 figures, 5 algorithms.

Table of Contents

  1. Introduction
  2. LiveDB
  3. Overview
  4. In-Memory Representation
  5. On-Disk Persistent Representation
  6. Discussion
  7. Intrinsic Pruning
  8. File Mapped Array Persistence Layer
  9. Separation of Hash and ID
  10. Ethereum Compatibility
  11. ArchiveDB
  12. Read Amplification and Pruning
  13. Hashing
  14. Healing
  15. Optimizations
  16. ...and 9 more sections

Figures (13)

  • Figure 1: LiveDB Architecture
  • Figure 2: LiveDB with keys and C fields
  • Figure 3: LiveDB and its Persistance
  • Figure 4: Evolution of Ethereum stateDB: 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 5: Distinction Between Nodes Addressed as Hashes or as Indices with its Impact on Access Time Complexity
  • ...and 8 more figures

Theorems & Definitions (10)

  • Example 1
  • Example 2
  • Example 3
  • Example 4
  • Example 5
  • Example 6
  • Example 7
  • Example 8
  • Example 9
  • Example 10