The wisdom is that having a full node is enough to reconstruct all past information the archive nodes keeps readily constructured, hence available faster.
I was reading the Geth IceBerg 1.8 release notes and saw the notes about state pruning and checked the notest at https://github.com/ethereum/go-ethereum/wiki/Tracing:-Introduction.
There's a section about accessing state, which notes
Geth by default does in-memory pruning of state, discarding state entries that it deems is no longer necessary to maintain. This is configured via the --gcmode option. Often, people run into the error that state is not available.
Say you want to do a trace on block B. Now there are a couple of cases:
1. You have done a fast-sync, pivot block P where P <= B. 2. You have done a fast-sync, pivot block P where P > B. 3. You have done a full-sync, with pruning 4. You have done a full-sync, without pruning (--gcmode=archive)
Here's what happens in each respective case:
1. Geth will regenerate the desired state by replaying blocks from the closest point in time before B where it has full state. This defaults to 128 blocks max, but you can specify more in the actual call ... "reexec":1000 .. } to the tracer. 2. Sorry, can't be done without replaying from genesis. 3. Same as 1) 4. Does not need to replay anything, can immediately load up the state and serve the request.
- If one needs to examine trace closer to genesis, should, or is it useful, to set
"reexec": nnnnparameter accordingly as very high or can Geth replay equally well with the default of 128?
- Does Geth store the information it has used during previous tracing calls?
The larger consideration behind this is that what options are there if I'd like to use Geth to sync, but instead of storing the full archive node state in a filesystem (local, or mounted) I could ingest the data, as queried to avoid parsing the actual block data, to some other storage and then keep updating this other storage using Geth as new blocks come available.
This could prompt an extra question:
- Is it possible to collect all the trace data during Geth syncing and storing as it goes such a way that it looks like (or can be constructed to look like) the RPC calls? I may have overlooked such an option.