Compare All Storage Models

Side-by-side comparison of how Bitcoin, Ethereum, Substrate, Cosmos, Solana, Sui, Aptos, and Verkle trees store state — and how that shapes their capabilities.

Quick Reference

Chain	Model	DB	Proof Size	Write Cost	Parallel ⚡	History 📚	Contracts 📜
₿Bitcoin	UTXO + Merkle	LevelDB	O(log n) — binary Merkle	Low	✅	—	—	Deep Dive
ΞEthereum	Merkle Patricia Trie	LevelDB / RocksDB	~10KB (many hash nodes)	High (trie update = many node rewrites)	—	—	✅	Deep Dive
●Substrate / Polkadot	Composed Key Trie	RocksDB / ParityDB	Medium (optimized trie)	Medium	—	—	✅	Deep Dive
⚛Cosmos / Tendermint	IAVL Tree (Immutable	GoLevelDB / RocksDB	Medium	Medium (AVL rebalance + versioning)	—	✅	✅	Deep Dive
◎Solana	Flat Account Store	RocksDB (accounts-db)	N/A (no state trie)	Very Low (direct account writes)	✅	—	✅	Deep Dive
◈Sui	Object Model +	RocksDB	Small (SMT fixed depth)	Low for owned objects	✅	—	✅	Deep Dive
⬡Aptos	Jellyfish Merkle Tree	RocksDB	Small (JMT optimized)	Low	✅	—	✅	Deep Dive
◊Verkle Trees (Future ETH)	Verkle Tree (Polynomial	LevelDB / RocksDB	~150 bytes (vs 10KB for MPT!)	Medium (polynomial operations)	—	—	✅	Deep Dive

Detailed Comparison

Key Formation

₿ Bitcoin

hash(tx) → Merkle path

Ξ Ethereum

keccak256(address) → 64 nibbles → MPT

● Substrate

Twox128(pallet) ++ Twox128(storage) ++ hash(key)

⚛ Cosmos

module_prefix + key → IAVL AVL path

◎ Solana

pubkey → DIRECT (no tree!)

◈ Sui

object_id → SMT 256-bit path

⬡ Aptos

keccak256(address ++ struct_tag) → JMT

◊ Verkle

address ++ suffix → 256-way Verkle path

Underlying DB

₿ Bitcoin

LevelDB (blocks + chainstate)

Ξ Ethereum

LevelDB or RocksDB

● Substrate

RocksDB or ParityDB

⚛ Cosmos

GoLevelDB or RocksDB

◎ Solana

RocksDB (AccountsDB)

◈ Sui

RocksDB

⬡ Aptos

RocksDB

◊ Verkle

LevelDB or RocksDB (same as ETH)

Write Cost

₿ Bitcoin

Low — UTXO insert/delete

Ξ Ethereum

High — O(log n) trie nodes re-hashed per write

● Substrate

Medium — similar trie traversal

⚛ Cosmos

Medium — AVL rebalance + node creation

◎ Solana

Very Low — direct account write

◈ Sui

Low for owned, medium for shared objects

⬡ Aptos

Low — JMT optimized sparse tree

◊ Verkle

Medium — polynomial commitment update

Proof Size

₿ Bitcoin

O(log₂ n) × 32 bytes — binary Merkle

Ξ Ethereum

~10KB per account (many MPT nodes)

● Substrate

Medium — similar to ETH but optimized encoding

⚛ Cosmos

Medium — IAVL AVL path

◎ Solana

N/A — no global state Merkle proof!

◈ Sui

Small — SMT with sparse compression

⬡ Aptos

Small — JMT optimized proofs

◊ Verkle

~150 bytes (100× smaller than ETH MPT!)

Deep Dives

Same KV DB — Different Structure on Top

All blockchains use key-value databases (LevelDB / RocksDB) under the hood.
The DIFFERENCE is entirely in how they build keys and what data structure sits on top:

Bitcoin:   DB["C" + txid + vout]         → flat UTXO set + separate Merkle tree in block header
Ethereum:  DB[keccak256(RLP(trie_node))] → 16-way Patricia Trie
Substrate: DB[trie_path_hash]            → Trie with composed keys
Cosmos:    DB[iavl_node_hash]            → Immutable Versioned AVL Tree
Solana:    DB[pubkey]                    → No tree at all! Direct lookup
Sui:       DB[object_id]                 → Sparse Merkle Tree
Aptos:     DB[jmt_node_hash]             → Jellyfish Merkle Tree (sparse binary)

Storage Model Family Tree

Blockchain Storage

UTXO Model

Bitcoin

Account + Trie

ETH, Substrate, Cosmos

Flat Account

Solana

Object Model

Sui, Aptos

The Core Mental Model

┌─────────────────────────────────────────────────────────────────────────────┐ │ SAME UNDERLYING KV DATABASE (LevelDB / RocksDB) │ │ DB[key] = value │ └─────────────────────────────────────────────────────────────────────────────┘ ↓ ↓ ↓ ↓ ┌──────────┐ ┌──────────────┐ ┌──────────┐ ┌──────────────┐ │ Bitcoin │ │ Ethereum │ │ Solana │ │ Cosmos/Sui │ │ UTXO │ │ MPT Trie │ │ Flat │ │ Tree/Object │ └──────────┘ └──────────────┘ └──────────┘ └──────────────┘ key = 'C'+txid key = hash(node) key = pubkey key = hash(node) val = utxo_bytes val = RLP(node) val = account val = encoded_node No global trie 16-way trie No trie Binary/AVL tree Merkle in header 64-nibble depth 1 DB read Provable state Simple + fast Powerful + expensive Ultra-fast Balanced No contracts Full EVM Programs Move language