-
Notifications
You must be signed in to change notification settings - Fork 73
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
Conversation
… finalizing a block in instant finality
…ck_state. Add missing set of transactions in block.
… not at beginning.
…rk database. Remove fetch_block_state_* methods.
@@ -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 ) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
…egacy. Also add block_exists as a performance improvement.
…roducer schedule test.
There was a problem hiding this 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,
libraries/chain/block_state.cpp
Outdated
block->transactions = std::move(trx_receipts); | ||
} | ||
|
||
// Used for transition from dbpos to instant-finality |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// Used for transition from dbpos to instant-finality | |
// Used for transition from dpos to instant-finality |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
Hmm, either nomenclature works I think. Not sure which I would consider more accurate. Open to changing the name. Thoughts @arhag @linh2931 ? |
There was a problem hiding this 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
Outdated
}, v); | ||
} | ||
|
||
std::optional<block_id_type> fork_db_fetch_block_id(uint32_t block_num) const { |
There was a problem hiding this comment.
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 ) { |
There was a problem hiding this comment.
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.
ilog("Transition to instant finality happening after block ${b}", ("b", bsp->block_num())); | ||
hs_irreversible_block_num = bsp->block_num(); | ||
|
||
log_irreversible(); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
Either is fine. Or |
Note:start |
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 withset_finalizer
call.block_token
as a wrapper ofblock_state_ptr
andblock_state_legacy_ptr
.block_state
no longer used outside of chain library except for leap-utilblocklog_actions::read_log
which will be fixed by IF: fork database transition not thread safe #2083instant-finality
nodeos_run_test.py
integration test which tests transition.controller::block_exists
instead of always pulling the complete block out of the block log.Resolves #2045