4

I run 2 nodes:

  1. a non-pruned, txindex=1 node that has been running for years (I can't tell exactly but I think I have been moving the same datadir around since 2014/15), core v23.0.0
  2. a pruned node that I synced last week, core v24.0.1

They are both synced.

I noticed that the chainstate of node 1 is 4.9G and node 2 is 5.5G (measured with du -h chainstate).

Number of files in each dir is also different, 2677 for node 1 and 3081 for node 2 (ls -A chainstate | wc -l).

I didn't expect that, because as far as I understand chainstate should be identical between nodes (I know that blocks/ dir can vary significatively in size because of revXXXX.blk files).

So I'm curious about what's in the chainstate and how it can vary by that much between nodes.

2
  • Are there any log or lock files in either directory?
    – bigjosh
    Commented Mar 2, 2023 at 20:15
  • Also, since different nodes can see transactions come in different order, maybe this is causing the indexes to build differently (even though then end up logically the same)?
    – bigjosh
    Commented Mar 2, 2023 at 20:16

1 Answer 1

3

The chainstate/ directory contains a LevelDB database. There is no guarantee whatsoever that two LevelDB databases with the same content are identical (or even have the same size).

LevelDB internally structures their database storage as a number of table files, each containing keys of some range of keys with the corresponding values. Multiple files can cover overlapping ranges of keys. There are heuristics internally in the database logic to determine when these table files get merged and compacted into new ones, but there are hard to predict, as they depend on the exact order things were written in.

And it's very much expected that was what written to these two databases you observe differs, even if their contents is identical. One node has been running for years, so it'll have generally a write with updates once per block or per few blocks at most. The node that just recently completed initial block download (IBD) will have seen far fewer (but bigger) writes matching many blocks at once, as Bitcoin Core flushes much less frequently during IBD for performance reasons. Furthermore, due to internal in-memory caching in Bitcoin Core, many UTXOs will have been created and spent between two updates in the IBD case, causing them to never hit disk at all.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.