1// MPT (Current Ethereum) vs Verkle Trees (EIP-6800)
2
3// ─── CURRENT: Merkle Patricia Trie ───────────────────
4// Proof structure: list of hashes along the path
5// Proof element: a 32-byte hash
6// Depth: up to 64 nibbles = up to 64 proof elements
7// Size: 64 elements × 32 bytes = 2,048 bytes
8// + Node data overhead → typically 10–40 KB per account proof
9
10// ─── FUTURE: Verkle Tree ────────────────────────────
11// Proof structure: polynomial commitment + opening proof
12// Uses: KZG polynomial commitments
13// Key magic: prove MANY values with ONE small proof!
14
15// Single-value proof sizes:
16// MPT: ~600 bytes per node × many nodes = ~10KB
17// Verkle: ~150 bytes total (compressed)
18
19// Batch proof (proving many accounts at once):
20// MPT: proof grows linearly with number of accounts
21// Verkle: proof stays nearly constant size!
22// → Proving 1,000 accounts: MPT ~10MB, Verkle ~200KB

1// Verkle Tree Structure
2// Similar to a trie but uses KZG commitments instead of hashes
3
4// Node structure:
5struct VerkleNode {
6    commitment: G1Point,  // 48-byte KZG commitment (vs 32-byte hash)
7    children: [Option<VerkleNodeRef>; 256], // 256-way (not 16-way!)
8}
9
10// Why 256-way instead of 16-way (MPT)?
11// With KZG, wider branching = smaller proof (not larger!)
12// MPT: 16-way, depth 64 nibbles
13// Verkle: 256-way, depth 32 bytes (same key length)
14// Less depth → fewer proof elements needed
15
16// Key mapping (EIP-6800):
17// Everything keyed by: account_address ++ sub_key
18// No more storage tries! Flat key space:
19//   account_version:     hash(address, 0)
20//   account_balance:     hash(address, 1)
21//   account_nonce:       hash(address, 2)
22//   account_code_hash:   hash(address, 3)
23//   contract_slot_X:     hash(address, trie_key_to_stem(slot))

1// EIP-6800: Ethereum state tree using a Verkle trie
2// (The actual Ethereum upgrade proposal)
3
4// New storage (replaces MPT):
5type VerkleStem = [u8; 31]   // 31-byte stem (address-derived)
6type VerkleKey  = [u8; 32]   // 32-byte key (stem ++ suffix)
7
8// Account data (no more separate storage trie!):
9stem(alice) = keccak256(alice_address)[..31]  // first 31 bytes
10
11// Account header stored at:
12BASIC_DATA_KEY    = stem ++ [0]  // version, balance, nonce, code_size
13CODE_HASH_KEY     = stem ++ [1]  // code hash
14
15// Contract storage at:  
16STORAGE_OFFSET    = 256
17slot_key = stem ++ [STORAGE_OFFSET + slot_mod_256]
18
19// HUGE CHANGE: storage and account in the SAME tree!
20// No more separate "storage trie" per contract
21// All state in one Verkle trie
22// Simpler + more uniform proofs

1// Stateless Ethereum — enabled by Verkle Trees
2
3// CURRENT (with MPT):
4// To run a transaction, validators need:
5// → Full state (currently ~100+ GB)
6// → Every validator must store everything
7// → High hardware requirements = centralization pressure
8
9// FUTURE (with Verkle):
10// "Witness" = proof of all state accessed by a transaction
11// A block's witness proves: all accounts/storage accessed
12
13// Current witness size (MPT): ~10-40 MB per block
14// Verkle witness size: ~200-500 KB per block  (100× smaller!)
15
16// Stateless client workflow:
17// 1. Receiver gets: block_header + transactions + witness
18// 2. Verify witness against state_root (KZG proofs)
19// 3. Execute transactions using witness as "portable state"
20// 4. No need to store full state!
21
22// This enables:
23// → Mobile clients that verify state without storage
24// → Light validators that don't need 100+ GB
25// → Better decentralization