I have a private network based on geth v1.9.25. I upgraded from v1.8.27. Recently, I saw that I'm unable to access the previous blocks at all. Like, e.g. eth.getBlockByNumber(1) gives me null, even though I can get the latest blocks just fine. I have a few questions regarding that:

  1. Does this have anything to do with the ancient deep freezing of the previous blocks? If so, is it possible to a, disable it (can't find anything relevant in the configurations) and b, recover/bring the frozen blocks back/thaw them out into active db from the ancient db? I'm looking into the debug options but I can't seem to find anything like what I'm looking for.

  2. Does this mean that "full" sync doesn't keep track of the blocks? I understand that gcmode=archive is required for complete state persistence but I was under the impression that syncmode=full will at least persist the entire blockchain (all blocks). I have read up on EVM tracing and haven't found anything contradictory to my understanding.

Update @ Apr 29

This doesn't seem to be normal behavior for geth. I've confirmed with experiments with geth v1.9.25 and rinkeby chain. So there's something wrong with my version (I've brought in consensus from Quorum to v1.9.25).

1 Answer 1


Update: I had originally thought the OP's question was about stored state, but have since realized that even the block headers seem to be unavailable. Answers have been edited a bit to reflect this, but still kept in their general format to help anyone who might have the headers but is wondering where their state went.

Full nodes verify the entire chain, but they do not persist its entire state. I believe different clients persist different amounts, but they have in common that without running an archive node, the state is not persisted. Looking into how long Geth stores state for, I found a reference to "3 epochs" (in the blog post linked below), and I've found references to epochs being 30,000 blocks, meaning Geth would store state for the last 90K blocks. If someone knows more accurate information on that point, please point it out.

To answer your questions more directly:

  1. Only headers and receipts go into the freezer, not state source. If only the state is missing, then it isn't a problem at all - everything is functioning as it should (see below). If the headers are missing, then there may be some corruption in the freezer. Unfortunately, this means resyncing afaik - there is no way to regenerate the freezer. In the case of the OP this could be more problematic if the whole private network was upgraded at the same time, and experienced the same corruption.

  2. A full (non-archive) node does not keep track of all of the states of all of the blocks, but it does keep all of the headers and receipts. So I suppose the answer is yes and no - there are parts of the old blocks it keeps (enough to keep track of the blockchain, and verify data about the actual blocks), but not the state from that block.

  • 1
    Regarding #2, when you say "there are parts of the old blocks it keeps (enough to keep track of the blockchain...". yes, this is exactly how it is supposed to be. It has to at least keep the block data. Not the state. However, in my case, I can't get the blocks that have been frozen, like I said in the example, the first block, for instance, after genesis. Or even the latest blocks frozen, as I can tell from logs. This can't be normal behavior.
    – ygh
    Apr 29, 2021 at 0:37
  • I should've dug more into eth.getBlockByNumber - I had assumed from the question that it was returning state. Looking at it on eth.wiki, is it possible that it's trying to return the full tx objects, and not just their hashes? What happens if you do eth.getBlock(1, false) - that looks like it should be just the hashes Apr 29, 2021 at 5:46
  • 1
    eth.getBlock(1,false) still returns null.
    – ygh
    Apr 29, 2021 at 5:49
  • 1
    you're right, that does sound like some kind of corruption - I'd recommend asking in Geth's Discord or the Eth R&D Discord Apr 29, 2021 at 5:51

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.