Request for view states method after sync is complete

[CryptoKiddies]

This is a feature request. I would like to be able to view the number of known and pulled states when geth is in sync–which is a good thing–but viewing states isn't possible when eth.syncing == false. Thanks!

System information

Geth version: geth v.1.8.3
OS & Version: Ubuntu 16.04

[karalabe]

I don't think that would be an easy thing to keep track of, unless we maintain a counter in each and every trie node. When I modify the state, entire subtries get replaced with new ones. Unless we know exactly how many nodes the cut-off subtrie contained, we'd need to iterate, which is prohibitively expensive.

Maintaining a counter inside the trie node might in theory be a possible solution, I'm just afraid of how much overhead that would be to add 8 bytes to every node (if we have 120M nodes on mainnet, that's 900MB of counter data).

[CryptoKiddies]

I'm all for keeping the client as lightweight as possible, so I'll be fine without the feature bloat. Cheers.

[andrewheadricke]

This would indeed be very handy.. lots of users are complaining about the super long sync times and the fact that no one knows how many state entries are needed to be downloaded is compounding the problem. Currently at 175M apparently :)

Geth is able to keep track of the state entry count while syncing, even when it performs its intermittent block updates whilst downloaded state entries. But I understand that its probably not trivial once sync completes.

Even if the node itself didn't keep a count due to resource constraints, what if nodes that just finish syncing announce their state entries count to the network, so that other downloaders at least have a rough idea. Or even better, perhaps once a node completes the sync it stores {blockNumber: 1234, stateEntryCount: 170M} and shares this information as part of its node info request.. then downloaders could find the most recently synced node and use its stateEntryCount as an approximate guess. Obviously the more recent the block the more accurate the state entry count.

Another option, what about an offline command whilst the node is not running.. to scan the DB and output a count?

[deke997]

@andrewheadricke Came here to suggest the same thing. Let's have each newly synced node announce state entry count.

I thought I was going crazy with fast sync taking this long, but after I found a lot of digging, I found a post from February 2019 which stated the synced state entry count to be ~284M. I am currently at 270M and still syncing, so I now believe I am almost there.

Even just a centralized google doc with most recent state entry counts from newly synced people would be helpful at this point 😅😅😅

[deke997]

Update: As of February 24 2019, state count was ~292M

#15616 (comment)

[deke997]

Update: My node is finally synced. Final state entry count as of 3/20/2019 is 292,494,140.

I started collecting some data during the last 20M state entries, and I made a chart and found the rate of state entry importation. Note that this is after the sync has pretty much caught up with the network in terms of block imports. I'm not sure if the rate is different while it's importing a ton of blocks in the beginning. Anyway, the chart shows 187M state entry imports per 24 hours on average. Yikes.

Machine is a 12 core VPS with 6GB of ram and a 250GB SSD

[adamschmideg]

See also EIP 2029

[nyetwurk]

Please push this forwards; providing sync progress is impossible without some way of getting a reference from ... somewhere. Even just adding it as a response to a query (e.g. eth.syncing)
to a synced node would be useful.. it doesn't have to be part of the protocol initially. For those of us developing UIs and/or monitoring systems, just having the ability to pull it from a reference node is sufficient.

[holiman]

This will not be fixed for fast-sync, but we have much better possibilities of providing a sensible eta in snap sync.