I see the block chain is stored according to the block chain format specification. But I also see there is a database, which is currently a leveldb database. Why is the block chain stored in two different ways? Seems redundant.
1 Answer
There are basically four pieces of data that are maintained:
blocks/blk*.dat
: the actual Bitcoin blocks, in network format, dumped in raw on disk. They are only needed for rescanning missing transactions in a wallet, reorganizing to a different part of the chain, and serving the block data to other nodes that are synchronizing.blocks/index/*
: this is a LevelDB database that contains metadata about all known blocks, and where to find them on disk. Without this, finding a block would be very slow.chainstate/*
: this is a LevelDB database with a compact representation of all currently unspent transaction outputs and some metadata about the transactions they are from. The data here is necessary for validating new incoming blocks and transactions. It can theoretically be rebuilt from the block data (see the-reindex
command line option), but this takes a rather long time. Without it, you could still theoretically do validation indeed, but it would mean a full scan through the blocks (207 GB as of march 2019 - https://www.blockchain.com/charts/blocks-size) for every output being spent.blocks/rev*.dat
: these contain "undo" data. You can see blocks as 'patches' to the chain state (they consume some unspent outputs, and produce new ones), and see the undo data as reverse patches. They are necessary for rolling back the chainstate, which is necessary in case of reorganisations.
So yes, everything but the block data itself is indeed redundant, as it can be rebuilt from it. But validation and other operations would become intolerably slow without them.
-
1Ok, thanks. Does rev*.dat just keep data for rolling back the chainstate/* database? (I imagine rolling back the blockchain is fairly simply, and just involves pruning off the end blocks and adding the new ones.) Commented May 21, 2013 at 21:17
-
3Indeed, just the chainstate; the rest is trivial. In particular, it contains the amounts and output scripts that were consumed by a block. Commented May 21, 2013 at 23:08
-
Hi. Say I want to implement the entire DB in SQL. Is it possible? If so, what are the pros and cons?? Commented Dec 7, 2015 at 19:10
-
1