unit-e
unit-e copied to clipboard
Re-calculate nChainWork/chain_stake on startup instead of saving it in the block index
bitcoin has a notion of chain work which is the sum of all the work (an ever increasing number) that has been put into a chain. It helps when deciding between forks (it select the one which has more work). The chain work in bitcoin is stored in CBlockIndex
and it's memory only, which means that when loading the block index it recalculates it while starting up.
This is favorable over storing it in the block index as that particular field is a uint256
and contributes a significant amount of space to the blockindex. Even with fast sync we still have the blockindex (but not all the content of the blocks) so this would not prevent it and the block index is supposed to be kept small.
Currently, as a means to get us started, we are saving it in the block index, but we should go back to calculating it.
Another reason to not have it in the block index is that for most parts of the chain we do not need it at all as that will be covered by snapshot/fast sync. I.e. when you start a new node you do not have to recalculate that value but you look it up from the latest snapshot and calculate from there.
The snapshot has been augmented with this functionality already in #225
When dealing with this field properly we should also rename it to chain_stake
.
The need totally makes sense, solution wise maybe it would be useful to have a generic dataset persisted and read from disk on startup and can be easily extended with more data, regardless of the snapshot - which might be there or not, might be too old or not contain all relevant params etc. I also see a solution like that designed side by side with #487 (loading/clearing to/from memory coordinated with what's on disk)