eth/api: add rpc method to obtain which states are accessible

[holiman]

From time to time, it's useful to know what roots are "accessible", meaning they can be used for tracing, or can be used when doing a setHead to hit a good target block. This PR adds a method to the debug namespace, to iterate over the blocks and check where we have the roots on disk.

This is also pretty interesting from a diagnostic perspective, as it reveals a bit about what the actual periods between flushes are.
IN the example below, I use the pivot block as 'from', and latest as 'end'.

~/go/src/github.com/ethereum/go-ethereum$ ./build/bin/geth --maxpeers 0 --nodiscover console
...
INFO [09-26|23:56:58.391] Loaded most recent local header          number=13,303,855 hash=d8199b..65e2fe td=31,341,758,120,762,708,097,878 age=25m23s
INFO [09-26|23:56:58.391] Loaded most recent local full block      number=13,303,855 hash=d8199b..65e2fe td=31,341,758,120,762,708,097,878 age=25m23s
INFO [09-26|23:56:58.391] Loaded most recent local fast block      number=13,303,855 hash=d8199b..65e2fe td=31,341,758,120,762,708,097,878 age=25m23s
INFO [09-26|23:56:58.391] Loaded last fast-sync pivot marker       number=12,642,813

...
> debug.getAccessibleState(12642813,"latest")
INFO [09-26|23:57:32.644] Finding roots                            from=12,642,813 to=13,303,855 at=12,642,813 found=0
INFO [09-26|23:57:40.644] Finding roots                            from=12,642,813 to=13,303,855 at=12,735,093 found=9 latest=12,732,323
INFO [09-26|23:57:48.645] Finding roots                            from=12,642,813 to=13,303,855 at=12,840,717 found=15 latest=12,828,350
INFO [09-26|23:57:56.645] Finding roots                            from=12,642,813 to=13,303,855 at=12,950,199 found=20 latest=12,925,977
INFO [09-26|23:58:04.645] Finding roots                            from=12,642,813 to=13,303,855 at=13,060,495 found=30 latest=13,056,890
INFO [09-26|23:58:12.645] Finding roots                            from=12,642,813 to=13,303,855 at=13,171,648 found=36 latest=13,159,668
INFO [09-26|23:58:20.645] Finding roots                            from=12,642,813 to=13,303,855 at=13,268,748 found=42 latest=13,257,043
[12642813, 12662058, 12676997, 12677123, 12677124, 12683998, 12701162, 12719253, 12732323, 12745298, 12761795, 12779974, 12797517, 12812053, 12828350, 12843978, 12905224, 12925850, 12925976, 12925977, 12951621, 12977361, 13000665, 13009051, 13009177, 13009178, 13009270, 13009271, 13033813, 13056890, 13080492, 13107495, 13138771, 13138897, 13138898, 13159668, 13178422, 13196629, 13211116, 13226916, 13242935, 13257043, 13272809, 13286898, 13303728, 13303854]

After the pivot marker, there was ~19K blocks until next flush, then 14K. It seems that my machine flushes usually around 14K intervals in the 13M segment. At certain points, there are consecutive block/states: 13138897, 13138898 -- those come from shutdowns.

This PR can be improved further automatically skipping checks below the pivot block. It takes a huge amount of time to dump from 0, "latest" if it has to load 12M headers and do 12M db state lookups before it starts finding anything.

[markya0616]

Is this api a standard api? If not, should we follow below discussions to standardize it first?

#23277 (comment)

[holiman]

Is this api a standard api

No, it's not. It's in the debug namespace, and the relevance of it is bound do the client implementation persistence model. For geth, this endpoint is usefull as a diagnostic tool, but may be less so for other clients.

[holiman]

Changed it a bit, so that it now skips over the pre-pivot section, and also that it only returns the first result.

> debug.getAccessibleState(0, "latest")
INFO [09-27|11:30:47.703] Found fast-sync pivot marker             number=12,642,813
INFO [09-27|11:30:47.703] Finding roots                            from=0 to=13,307,009 at=0
12642813
> debug.getAccessibleState("latest", 0)
INFO [09-27|11:30:55.383] Found fast-sync pivot marker             number=12,642,813
INFO [09-27|11:30:55.383] Finding roots                            from=13,307,009 to=0          at=13,307,009
13307009

[s1na]

It would've been nice to a get a list of all blocks with accessible state in that range but I suppose that's gonna take too long

[holiman]

It would've been nice to a get a list of all blocks with accessible state in that range but I suppose that's gonna take too long

That's actually what I implemented first. Then it became kind of annoying, because if you just want the latest, then you're going to have to either pick a short:ish segment and hope to find one, or pick a longer segment and wait it out.

So I instead changed it to just return the first, and if you want them all, you'll have to make a little script to iterate based on the results.

[karalabe]

LGTM