Linear Storage vs. Random Access

A common misconception is that blk00000.dat contains Blocks 0 through 1,000 in perfect order. In reality, the blk.dat files are chronological logs, not ordered databases.

1. Out-of-Order Storage

When you sync a Bitcoin node (Initial Block Download), you often download blocks from many peers simultaneously.

• Peer A might send you Block 100,000.

• Peer B might send you Block 100,005.

• Bitcoin Core writes these blocks to the file in the order they arrive.

Consequently, Block 100,005 might appear in the file before Block 100,001.

2. The Role of the Block Index (LevelDB)

Since the blk.dat files are unordered, the node needs a way to find a specific block without scanning terabytes of data. This is handled by the Block Index.

• The index is a LevelDB database located in the blocks/index/ directory.

• It maps a Block ID (Hash) to a File Pointer.

• Example Entry: Hash X -> File 00042, Offset 10,240, Size 950,000.

3. The Undo Files (rev.dat)

Alongside the blk.dat files, you will find rev.dat files. These contain "Undo Data."

• If a Chain Reorganization occurs, the node must "disconnect" blocks.

• The rev.dat files store the UTXOs that were destroyed by the block, allowing the node to put them back into the database if the block is discarded.

4. Pruning

If you run a "Pruned Node," your software will delete old blk.dat files once they have been processed and validated.

• The node still keeps the UTXO Set (Chainstate).

• The node deletes the raw block data to save disk space.

• A pruned node cannot serve old blocks to new peers.

File Type	Purpose
blkXXXXX.dat	Raw Block Data (The Chain)
revXXXXX.dat	Undo Data (For Reorgs)
index/ (LevelDB)	Map of Hash -> File Position

In the next section, we will perform a Byte-by-Byte Walkthrough of a raw blk.dat record.