Conversation
Contributor
Performance Report馃殌馃殌 Significant benchmark improvement detected
Full benchmark results
|
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
should_apply_proposer_boostandis_proposer_equivocationread proposer equivocations fromstore.blocks, so only valid blocks count. Nodes have to bound how many repeat proposals they fully validate, we import at most one alternate over gossip (#9805, #9795), and with that bound the view depends on arrival order. Given blocks A, B, C from one proposer with C invalid, nodes that see A and B first record the equivocation while nodes that see A and C first never learn that B exists, so the two groups disagree on the boost of the next block and on the equivocation reorg.Counting signed blocks instead removes that. Two signature checks per proposer and slot are all a node ever does, and since siblings arrive in order the first two signed roots are always the most timely ones, so a two-root record per proposer and slot answers
should_apply_proposer_boostexactly. Every effect of a junk signed sibling lands on the attacker's own slot, the next proposer sees the same early sibling as the attesters and reorgs a weak head asget_proposer_headalready asks it to.onBlockrecords imported blocks, the newonSignedBlockHeaderrecords blocks that were seen with a valid proposer signature but not importedhasEquivocatingBlockreads that record instead of scanning the proto arrayisPtcTimelyevaluated at arrivalThis deviates from the current spec text, which is why it is a draft. The spec change is a store field of signed sibling roots and their timeliness fed by a handler taking a signature-valid header, like
on_attester_slashing, with the two fork choice functions reading it and the p2p spec noting that ignored repeat proposals feed it. Supersedes #10070.