ElasticState -- Intelligent 3-Tier Storage Engine
The Problem
Every blockchain today treats all state equally. A validator that transacted 5 seconds ago and a wallet that has not moved in 3 years sit in the same data structure, consuming the same resources. As chains grow, state bloat becomes the dominant bottleneck -- RocksDB compaction slows down, bloom filter pressure increases, and every full node must store the entire history of every account at the same access speed.
Ethereum's state trie holds 300M+ accounts in a single Merkle Patricia Trie. Solana's account store exceeds 500 GB. Both treat a billion-dollar DeFi protocol and a dust account identically. This is why "state rent" and "state expiry" have been debated for years without resolution -- they punish users for a problem that is actually an infrastructure design failure.
The Solution
ElasticState automatically routes account data through three storage tiers based on activity, giving sub-microsecond access to hot data while compressing dormant accounts by up to 90%.
+------------------------------------------------------+
| HOT TIER -- DashMap (in-memory) |
| Active accounts (last 7 days) |
| Access: <1us | Capacity: 100K entries / 8 GB |
+------------------------------------------------------+
| WARM TIER -- RocksDB (LZ4 compression) |
| Recent accounts (7-90 days inactive) |
| Access: ~100us | Fast SSD reads |
+------------------------------------------------------+
| COLD TIER -- RocksDB (ZSTD max compression) |
| Dormant accounts (90+ days inactive) |
| Access: ~1-10ms | 90% storage reduction |
| Includes Merkle proofs for light client verification|
+------------------------------------------------------+
How It Works
-
Write-through: Every state mutation writes to both the main RocksDB (source of truth for state root) AND the appropriate ElasticState tier. The main DB stays canonical; ElasticState is a read-acceleration layer.
-
Auto-promotion on read: A cold account accessed during transaction execution is automatically promoted to the warm tier. A warm account accessed repeatedly migrates to hot. Users never notice -- access is seamless.
-
Background demotion: Every 100 blocks (~20 minutes), a background task scans the hot cache and demotes accounts inactive for 7+ days to the warm tier. Accounts inactive 90+ days in warm are compressed to cold.
-
Zero-copy checkpoints: RocksDB's built-in
CheckpointAPI creates instant snapshots via hard-links every 1,000 blocks. No I/O overhead, no lock contention. Old checkpoints auto-pruned (keep last 5).
Comparison
| Chain | State Model | Problem |
|---|---|---|
| Ethereum | Single Merkle Patricia Trie | 300M+ accounts in one structure. State rent debated since 2017, still unresolved. |
| Solana | Flat account store | 500+ GB. "Account rent" charges users to exist. |
| Cosmos | IAVL tree | State grows linearly. No tiering. |
| Vexidus | ElasticState 3-tier | Hot accounts in memory (<1us), cold accounts compressed 90%. Main DB stays small. |
Key Design Decisions
- Feature-flagged (
--elastic-stateCLI flag). Backward-compatible -- nodes without it behave identically to before. - State root integrity preserved. The main RocksDB default CF is the ONLY input to
compute_state_root(). ElasticState is a read cache that cannot affect consensus. - No state rent. Vexidus will never charge users to keep their accounts alive. ElasticState solves the problem at the infrastructure level -- dormant accounts are compressed, not evicted.
- Merkle proofs for cold accounts. Cold-tier accounts include verifiable proofs, enabling future light clients to verify historical state without downloading the full chain.
Parameters
| Parameter | Default | CLI Flag |
|---|---|---|
| Hot cache entries | 100,000 | --elastic-hot-entries |
| Hot cache memory | 8 GB | --elastic-hot-memory-mb |
| Hot to Warm threshold | 7 days inactive | -- |
| Warm to Cold threshold | 90 days inactive | -- |
| Demotion interval | Every 100 blocks (~20 min) | -- |
| Warm compression | LZ4 (fast) | -- |
| Cold compression | ZSTD (max, ~90% reduction) | -- |
| Feature flag | Off (backward-compatible) | --elastic-state |
RPC
vex_getStorageStats -- Returns tier counts, memory usage, storage reduction percentage.