 |
Today at 01:56:03 AM |
|
The UTXO set (also called the coins database or chainstate) is the most performance-critical data structure in a Bitcoin node. It represents the entire current state of all spendable bitcoins.
Now, let’s talk about how it is being stored.
1. Location and Database Engine
a. Stored in the chainstate/ directory inside your Bitcoin data folder (e.g., ~/.bitcoin/chainstate/ on Linux).
b. Uses LevelDB (a lightweight, fast key-value store from Google). LevelDB stores data in a series of SSTables (Sorted String Tables) on disk with LSM-tree (Log-Structured Merge-tree) architecture. bitcoin-institute.pages.dev
This is separate from the block storage (blocks/ directory with blk*.dat flat files and index/ LevelDB).
2. In-Memory Caching (Coins Cache)
• Bitcoin Core does not read/write to LevelDB for every operation (too slow).
• It maintains an in-memory write-back cache (CCoinsViewCache).
• Reads check the cache first; misses load from LevelDB and cache the result.
• Writes (new blocks/transactions) accumulate in the cache.
• Changes are batch-written to LevelDB when the cache is full, on periodic flushes, or shutdown. bitcoin-institute.pages.dev
• Controlled by -dbcache (default ~450 MiB; higher values speed up IBD significantly).
3. Key-Value Structure (Since v0.15+)
Key (Outpoint):
• Prefix: 'C' (0x43 byte) — distinguishes from other data.
• 32-byte transaction ID (txid in little-endian).
• Variable-length integer (varint) for the output index (vout).
Example key (hex): 43 + little-endian txid + varint vout. github.com
Value (Coin data — highly compressed):
• Code (varint): Encodes block height + coinbase flag (whether the output came from a coinbase transaction).
• Amount (compressed): Special variable-length encoding for satoshis (very space-efficient).
• Script (locking script): Often compressed or prefixed with type info (e.g., for common P2PKH, P2WPKH, P2TR patterns). Full script for complex cases. github.com
|
