Confirmation Rule #3339
Confirmation Rule #3339
Conversation
… than block.slot + 1
…use conversion to int to avoid overflows
Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>
fork_choice/confirmation-rule.md
Outdated
|
|
||
| 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?
There was a problem hiding this comment.
Another way would be to change the doc to
Returns True if the range from
start_slottoend_slot(inclusive of both) includes an entire epoch
In this way, we are not saying that if the range includes an entire epoch, then the function returns True.
Only that whenever the function returns True than the range includes an entire epoch.
The above works with both inclusive and exclusive.
fork_choice/confirmation-rule.md
Outdated
| 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.
There was a problem hiding this comment.
Yes. It is different.
This does not always yield exactly the same result as in the paper, but it does in most cases, and it is quicker to compute.
fork_choice/confirmation-rule.md
Outdated
| 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?
fork_choice/confirmation-rule.md
Outdated
|
|
||
| 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?
There was a problem hiding this comment.
Any block descendant of the latest finalized checkpoint is treated in the same way
fork_choice/confirmation-rule.md
Outdated
| 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).
There was a problem hiding this comment.
The protocol is run at the beginning of each slot regardless of whether we propose or not a block in that slot. Also, we do not run the protocol on blocks for the current slots regardless.
fork_choice/confirmation-rule.md
Outdated
| min( | ||
| ceil_div(total_active_balance * CONFIRMATION_BYZANTINE_THRESHOLD, 100), | ||
| CONFIRMATION_SLASHING_THRESHOLD, | ||
| ffg_support_for_checkpoint | ||
| ) |
There was a problem hiding this comment.
Is ceil_div(total_active_balance * CONFIRMATION_BYZANTINE_THRESHOLD, 100) always smaller than or equal to CONFIRMATION_SLASHING_THRESHOLD?
There was a problem hiding this comment.
In the paper, it is ceil_div((total_active_balance - remaining_ffg_weight) * CONFIRMATION_BYZANTINE_THRESHOLD, 100). I wonder whether it is a typo.
There was a problem hiding this comment.
Is ceil_div(total_active_balance * CONFIRMATION_BYZANTINE_THRESHOLD, 100) always smaller than or equal to CONFIRMATION_SLASHING_THRESHOLD
Not necessarily.
There was a problem hiding this comment.
Is ceil_div(total_active_balance * CONFIRMATION_BYZANTINE_THRESHOLD, 100) always smaller than or equal to CONFIRMATION_SLASHING_THRESHOLD?
Which paper are you referring to?
hwwhww
force-pushed
the
confirmation_rule
branch
from
1d3f67d
to
e6d9150
Compare
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.