Confirmation Rule #3339
Confirmation Rule #3339
Conversation
… than block.slot + 1
…use conversion to int to avoid overflows
Co-authored-by: Mikhail Kalinin <noblesse.knight@gmail.com>
… from new confirmation rule
| block_time = pre_state.genesis_time + signed_block.message.slot * spec.config.SECONDS_PER_SLOT | ||
| while store.time < block_time: | ||
| time = pre_state.genesis_time + (spec.get_current_slot(store) + 1) * spec.config.SECONDS_PER_SLOT | ||
| on_tick_step(spec, store, time, test_steps) |
There was a problem hiding this comment.
Is on_tick_and_append_step v.s. on_tick_step here the only difference between this tick_and_add_block and the helper from helpers/fork_choice.py? Could we refactor it to reuse one common helper?
| def on_tick_step(spec, store, time, test_steps): | ||
| spec.on_tick(store, time) | ||
| test_steps.append({"tick": int(time)}) |
There was a problem hiding this comment.
Do you intentionally want to avoid calling output_store_checks because the test format is not shared? If so, I agree, as @mkalinin suggested, it would be nice to apply the optimistic sync style test format - inheriting the common checks from the FC test format.
There was a problem hiding this comment.
Yep, I intentionally avoid calling output_store_checks.
However, this is not because the test format is not shared.
It is because in these tests, we are only interested in checking the confirmation rule behaviour. We are not interested in the checks outputted by output_store_checks`
Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>
|
|
||
| return ( | ||
| end_epoch > start_epoch + 1 | ||
| or (end_epoch == start_epoch + 1 and start_slot % SLOTS_PER_EPOCH == 0)) |
There was a problem hiding this comment.
If start_slot = 0 and end_slot = 31 (where end_epoch == start_epoch == 0), do we count it as "includes an entire epoch"? If not, should we describe the function as exclusive end_slot?
| if is_full_validator_set_for_block_covered(store, block_root): | ||
| return is_one_confirmed(store, block_root) | ||
| else: | ||
| block = store.blocks[block_root] | ||
| return ( | ||
| is_one_confirmed(store, block_root) | ||
| and is_lmd_confirmed(store, block.parent_root) | ||
| ) |
There was a problem hiding this comment.
Is it different from the definition 6 (lmd-safety condition) in the paper? The paper require all the ancestors of the block to be is_lmd_confirmed, regardless of whether full validator set is covered or not.
| current_slot = get_current_slot(store) | ||
| block = store.blocks[block_root] | ||
| parent_block = store.blocks[block.parent_root] | ||
| support = int(get_weight(store, block_root)) |
There was a problem hiding this comment.
Is this the weight from the fork_choice data, which can be queried from the beacon API?
|
|
||
| block_epoch = compute_epoch_at_slot(block.slot) | ||
|
|
||
| # If `block_epoch` is not either the current or previous epoch, then return `store.finalized_checkpoint.root` |
There was a problem hiding this comment.
What is the confirmation rule for the block between finalized checkpoint and justified checkpoint?
| support = int(get_weight(store, block_root)) | ||
| justified_state = store.checkpoint_states[store.justified_checkpoint] | ||
| maximum_support = int( | ||
| get_committee_weight_between_slots(justified_state, Slot(parent_block.slot + 1), Slot(current_slot - 1)) |
There was a problem hiding this comment.
Do we assume that we run the protocol at the beginning of each slot, when the block for the current slot is not proposed? Otherwise, for the block proposed in the current slot (with its parent proposed in the previous slot), Slot(parent_block.slot + 1) > Slot(current_slot - 1).
Introduction
The objective of this PR is to introduce a Confirmation Rule for the Ethereum protocol.
A confirmation rule is an algorithm run by nodes, outputting whether a certain block is confirmed. When that is the case, the block is guaranteed to never be reorged, under certain assumptions, primarily about network synchrony and about the percentage of honest stake.
Detailed Explanation
For a detailed explanation of the algorithm, see this article.
The algorithm specified in this PR corresponds to Algorithm 5 in the paper.
TODO
Here is a non-exclusive list of TODOs
setup.pyare correct. The current changes allow linting the confirmation rule spec, but they may not be entirely correct.Last things to do before merging
linter.ini. These changes have been introduced just to speed up the development process by relaxing the requirement on the maximum line length.fork_choice/confirmation_rule.mdtospecs/bellatrixand delete thefork_choicefolder.