Skip to content
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: Transition from dpos to instant-finality #2085

Merged
merged 19 commits into from
Jan 16, 2024

Conversation

heifner
Copy link
Member

@heifner heifner commented Jan 14, 2024

  • Transition from dpos to instant-finality on the block after set_finalizer host function call. This is a temporary method of transition until we work out the algorithm to use in production.
    • fork_database switched over after block with set_finalizer call.
  • Add block_token as a wrapper of block_state_ptr and block_state_legacy_ptr.
  • Enable instant-finality nodeos_run_test.py integration test which tests transition.
  • Performance improvement via controller::block_exists instead of always pulling the complete block out of the block log.
  • Fixes producer schedule switch bug after instant-finality is enabled.
  • LIB does not advance after switching to instant-finality. This is expected as we are not generating vote messages yet.

Resolves #2045

@heifner heifner added the OCI Work exclusive to OCI team label Jan 14, 2024
@@ -3757,10 +3772,10 @@ void controller::start_block( block_timestamp_type when,
bs, std::optional<block_id_type>(), deadline );
}

void controller::finalize_block( block_report& br, const signer_callback_type& signer_callback ) {
void controller::finish_block( block_report& br, const signer_callback_type& signer_callback ) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I would have called it complete_block as it switches to the completed_block stage.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@arhag mentioned calling it finish_block so just went with that. I'm ok with either finish_block or complete_block.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No strong feeling about this but I like the symmetry of:

assemble_block(building_block) -> assembled_block
complete_block(assembled_block) -> completed_block

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think finish_block highlights the last step of those block building stages. Sounds more natural.

libraries/chain/controller.cpp Outdated Show resolved Hide resolved
libraries/chain/controller.cpp Outdated Show resolved Hide resolved
@heifner heifner marked this pull request as ready for review January 15, 2024 17:51
Copy link
Contributor

@greg7mdp greg7mdp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, thanks for all the fixes Kevin.

Naming personal perference again, instead of block_token, I would prefer block_handle, I think it is somewhat more accurate,

block->transactions = std::move(trx_receipts);
}

// Used for transition from dbpos to instant-finality
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// Used for transition from dbpos to instant-finality
// Used for transition from dpos to instant-finality

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

libraries/chain/block_state.cpp Outdated Show resolved Hide resolved
libraries/chain/block_state.cpp Outdated Show resolved Hide resolved
@heifner
Copy link
Member Author

heifner commented Jan 15, 2024

Nice, thanks for all the fixes Kevin.

Naming personal perference again, instead of block_token, I would prefer block_handle, I think it is somewhat more accurate,

Hmm, either nomenclature works I think. Not sure which I would consider more accurate. Open to changing the name. Thoughts @arhag @linh2931 ?

Copy link
Member

@linh2931 linh2931 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like your combining block_state_legacy and block_state into block_token. The fewer the _legacy, the better.

libraries/chain/controller.cpp Show resolved Hide resolved
}, v);
}

std::optional<block_id_type> fork_db_fetch_block_id(uint32_t block_num) const {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can be named as fork_db_fetch_block_id_by_num to match fork_db_fetch_block_by_num.

@@ -3757,10 +3772,10 @@ void controller::start_block( block_timestamp_type when,
bs, std::optional<block_id_type>(), deadline );
}

void controller::finalize_block( block_report& br, const signer_callback_type& signer_callback ) {
void controller::finish_block( block_report& br, const signer_callback_type& signer_callback ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think finish_block highlights the last step of those block building stages. Sounds more natural.

libraries/chain/controller.cpp Outdated Show resolved Hide resolved
ilog("Transition to instant finality happening after block ${b}", ("b", bsp->block_num()));
hs_irreversible_block_num = bsp->block_num();

log_irreversible();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will log_irreversible be executed twice as there was one above?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will be executed twice. But if_irreversible_block_num is set before the second call. log_irreversible determines internally if it should do anything. Always safe to call it multiple times.

@linh2931
Copy link
Member

Nice, thanks for all the fixes Kevin.
Naming personal perference again, instead of block_token, I would prefer block_handle, I think it is somewhat more accurate,

Hmm, either nomenclature works I think. Not sure which I would consider more accurate. Open to changing the name. Thoughts @arhag @linh2931 ?

Either is fine. Or block_ptr or block_ctx to be shorter?

Base automatically changed from gh_2034_part2 to hotstuff_integration January 16, 2024 02:44
@heifner heifner merged commit cbb6b28 into hotstuff_integration Jan 16, 2024
26 checks passed
@heifner heifner deleted the GH-2045-if-transision branch January 16, 2024 02:45
@ericpassmore
Copy link
Contributor

Note:start
group: IF
category: INTERNALS
summary: Initial early version of transition from legacy finality to new Faster Finality. Additional work required on transition to address all scenarios.
Note: end

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
OCI Work exclusive to OCI team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants