Inside Bitcoin
Opening the selected file…
Inside Bitcoin
Opening the selected file…
The code behind the network, with room to understand it.
Release published 2026-10-28 · Snapshot fetched 2026-11-01. Latest stable release at fetch time; development branches and Git history are excluded. Only the selected code window and visible folders load here.
1leveldb Log format2==================3The log file contents are a sequence of 32KB blocks. The only exception is that4the tail of the file may contain a partial block.6Each block consists of a sequence of records:8block := record* trailer?9record :=10checksum: uint32 // crc32c of type and data[] ; little-endian11length: uint16 // little-endian12type: uint8 // One of FULL, FIRST, MIDDLE, LAST13data: uint8[length]15A record never starts within the last six bytes of a block (since it won't fit).16Any leftover bytes here form the trailer, which must consist entirely of zero17bytes and must be skipped by readers.19Aside: if exactly seven bytes are left in the current block, and a new non-zero20length record is added, the writer must emit a FIRST record (which contains zero21bytes of user data) to fill up the trailing seven bytes of the block and then22emit all of the user data in subsequent blocks.24More types may be added in the future. Some Readers may skip record types they25do not understand, others may report that some data was skipped.27FULL == 128FIRST == 229MIDDLE == 330LAST == 432The FULL record contains the contents of an entire user record.34FIRST, MIDDLE, LAST are types used for user records that have been split into35multiple fragments (typically because of block boundaries). FIRST is the type36of the first fragment of a user record, LAST is the type of the last fragment of37a user record, and MIDDLE is the type of all interior fragments of a user38record.40Example: consider a sequence of user records:42A: length 100043B: length 9727044C: length 800046**A** will be stored as a FULL record in the first block.48**B** will be split into three fragments: first fragment occupies the rest of49the first block, second fragment occupies the entirety of the second block, and50the third fragment occupies a prefix of the third block. This will leave six51bytes free in the third block, which will be left empty as the trailer.53**C** will be stored as a FULL record in the fourth block.55----57## Some benefits over the recordio format:591. We do not need any heuristics for resyncing - just go to next block boundary60and scan. If there is a corruption, skip to the next block. As a61side-benefit, we do not get confused when part of the contents of one log62file are embedded as a record inside another log file.642. Splitting at approximate boundaries (e.g., for mapreduce) is simple: find the65next block boundary and skip records until we hit a FULL or FIRST record.673. We do not need extra buffering for large records.69## Some downsides compared to recordio format:711. No packing of tiny records. This could be fixed by adding a new record type,72so it is a shortcoming of the current implementation, not necessarily the73format.752. No compression. Again, this could be fixed by adding new record types.
Independent explanations by MyBitcoinExplorer. Not affiliated with or endorsed by Bitcoin Core. Guides are educational and do not replace the source or its tests.
Bitcoin Core source © its contributors, distributed under the MIT license. Original notices and bundled third-party licenses are retained in the source tree.