-
Notifications
You must be signed in to change notification settings - Fork 70
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
IF: Unification: IF transition of fork database usage #2045
Comments
|
heifner
added a commit
that referenced
this issue
Jan 14, 2024
… finalizing a block in instant finality
heifner
added a commit
that referenced
this issue
Jan 14, 2024
heifner
added a commit
that referenced
this issue
Jan 14, 2024
heifner
added a commit
that referenced
this issue
Jan 14, 2024
heifner
added a commit
that referenced
this issue
Jan 14, 2024
…ck_state. Add missing set of transactions in block.
heifner
added a commit
that referenced
this issue
Jan 14, 2024
…rk database. Remove fetch_block_state_* methods.
heifner
added a commit
that referenced
this issue
Jan 15, 2024
heifner
added a commit
that referenced
this issue
Jan 15, 2024
…egacy. Also add block_exists as a performance improvement.
heifner
added a commit
that referenced
this issue
Jan 15, 2024
heifner
added a commit
that referenced
this issue
Jan 15, 2024
heifner
added a commit
that referenced
this issue
Jan 15, 2024
heifner
added a commit
that referenced
this issue
Jan 15, 2024
heifner
added a commit
that referenced
this issue
Jan 15, 2024
heifner
added a commit
that referenced
this issue
Jan 16, 2024
IF: Transition from dpos to instant-finality
Resolved by #2085 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Support transition from reversible blocks in old fork database to blocks in new fork database. Convert block_header_state_legacy to block_header_state for the appropriate block. Handle transition at the appropriate time.
Consider how a fork re-org would be handled in the middle of the transition.Also handle any remaining small TODOs leftover from #1941 (e.g. in leap-util). leap-util todo fix moved to #2083 since not needed for testnet.
As soon as the transition begins, producer schedule changes will be rejected until the transition completes. The host function would not fail. It would just silently drop the new proposed producer schedules. This allows us to avoid needing to update proposer policy for the blocks created during the transition.For this issue, we want a simpler (but unsafe) transition in which the block that first proposes the finalizer policy immediately becomes irreversible and atomically transitions from the old algorithm to the IF algorithm going forward.
This should also have a Boost test to show the transition works correctly.
The text was updated successfully, but these errors were encountered: