search

AntelopeIO / spring

C++ implementation of the Antelope protocol with Savanna consensus
Other
5 stars 2 forks source link

Remove distinction between fork_db pending_head and head; persist if_irreversible_block_id in fork_db; add fork_db_pending_lib_num #333

Closed arhag closed 2 months ago

arhag commented 2 months ago

On startup, when loading the fork database from disk, nodeos should either reconstruct the if_irreversible_block_id using the QC data stored in the fork database to what it should have been prior to shutdown, or it should simply restore a saved if_irreversible_block_id.

Prior to https://github.com/AntelopeIO/spring/pull/325/, we had a function latest_known_lib_num which return the LIB number regardless of whether the node was in a pre-Savanna state or post-Savanna state. But it had a problem during the transition where it would return the dpos_irreversible_block_num (of the legacy consensus algorithm) without capping it to the IF Genesis block number.

Additionally, we still have fork_db_head_irreversible_blocknum which returns the LIB number from the perspective of the best head (whether Savanna or legacy). But this still has the flaw above during the transition and also for a Proper IF block it has the further flaw that it may not be the best known LIB that is tracked by if_irreversible_block_id since it does not include the effect of any integrated QC that was pulled from an invalid block.

We should have a function to complement fork_db_head_block_id that returns the block ID of the block known by the fork database (including the if_irreversible_block_id which can kind of be considered as part of the fork database, and may make sense to officially move into the fork database) to be the best LIB to move towards (this might be called fork_db_pending_lib_id). This is not the same as the current LIB since that is still driven by the root block of the fork database. Once we have fork_db_pending_lib_id (and we could add a convenience function fork_db_pending_lib_num to complement it if we wish), then we can get rid of fork_db_head_irreversible_blocknum.

There is no need for a distinction between pending_head and head in fork database. There is only a single head which can be thought of as the pending head. This means that the chain_head may not be at the head of the fork database. This can be because it is in the middle of advancing the chain_head (or doing a fork switch to it), or it can be because it is in irreversible mode. If nodeos is in irreversible mode, then chain_head is either at the fork_db_pending_lib_id or it is shortly behind it and in the middle of advancing towards it.

heifner commented 2 months ago

Re-open for additional work of savanna lib calculation moved to forkdb.