-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove distinction between fork_db pending_head and head; persist if_irreversible_block_id in fork_db; add fork_db_pending_lib_num #333
Comments
heifner
added a commit
that referenced
this issue
Jul 2, 2024
heifner
added a commit
that referenced
this issue
Jul 2, 2024
heifner
added a commit
that referenced
this issue
Jul 3, 2024
heifner
added a commit
that referenced
this issue
Jul 3, 2024
heifner
added a commit
that referenced
this issue
Jul 3, 2024
heifner
added a commit
that referenced
this issue
Jul 3, 2024
heifner
added a commit
that referenced
this issue
Jul 3, 2024
heifner
added a commit
that referenced
this issue
Jul 3, 2024
heifner
added a commit
that referenced
this issue
Jul 3, 2024
heifner
added a commit
that referenced
this issue
Jul 3, 2024
heifner
added a commit
that referenced
this issue
Jul 3, 2024
…on to avoid confusion with local variables named fork_head
heifner
added a commit
that referenced
this issue
Jul 5, 2024
heifner
added a commit
that referenced
this issue
Jul 5, 2024
heifner
added a commit
that referenced
this issue
Jul 5, 2024
heifner
added a commit
that referenced
this issue
Jul 8, 2024
heifner
added a commit
that referenced
this issue
Jul 8, 2024
heifner
added a commit
that referenced
this issue
Jul 8, 2024
…m pending_head() which will be clearer when renamed to head().
heifner
added a commit
that referenced
this issue
Jul 8, 2024
heifner
added a commit
that referenced
this issue
Jul 8, 2024
heifner
added a commit
that referenced
this issue
Jul 9, 2024
heifner
added a commit
that referenced
this issue
Jul 9, 2024
heifner
added a commit
that referenced
this issue
Jul 9, 2024
…ast block due to block id difference.
heifner
added a commit
that referenced
this issue
Jul 9, 2024
Merged
Merged
heifner
added a commit
that referenced
this issue
Jul 9, 2024
…a friend instead of block_state_accessor
heifner
added a commit
that referenced
this issue
Jul 9, 2024
heifner
added a commit
that referenced
this issue
Jul 10, 2024
heifner
added a commit
that referenced
this issue
Jul 10, 2024
heifner
added a commit
that referenced
this issue
Jul 10, 2024
heifner
added a commit
that referenced
this issue
Jul 10, 2024
heifner
added a commit
that referenced
this issue
Jul 10, 2024
Re-open for additional work of savanna lib calculation moved to forkdb. |
heifner
added a commit
that referenced
this issue
Jul 10, 2024
heifner
added a commit
that referenced
this issue
Jul 10, 2024
heifner
added a commit
that referenced
this issue
Jul 10, 2024
heifner
added a commit
that referenced
this issue
Jul 10, 2024
Move savanna pending lib calculation to forkdb add()
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 savedif_irreversible_block_id
.Prior to #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 thedpos_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 byif_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 theif_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 calledfork_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 havefork_db_pending_lib_id
(and we could add a convenience functionfork_db_pending_lib_num
to complement it if we wish), then we can get rid offork_db_head_irreversible_blocknum
.There is no need for a distinction between
pending_head
andhead
in fork database. There is only a singlehead
which can be thought of as the pending head. This means that thechain_head
may not be at thehead
of the fork database. This can be because it is in the middle of advancing thechain_head
(or doing a fork switch to it), or it can be because it is in irreversible mode. If nodeos is in irreversible mode, thenchain_head
is either at thefork_db_pending_lib_id
or it is shortly behind it and in the middle of advancing towards it.The text was updated successfully, but these errors were encountered: