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

add lower bound slot condition on block gossip #1616

Merged
merged 2 commits into from
Feb 12, 2020
Merged

Conversation

djrtwo
Copy link
Contributor

@djrtwo djrtwo commented Feb 12, 2020

Add lower bound in beacon block gossip condition in response to Least Authority audit.

specs/phase0/p2p-interface.md Outdated Show resolved Hide resolved
Co-Authored-By: Diederik Loerakker <proto@protolambda.com>
Copy link
Collaborator

@protolambda protolambda left a comment

Choose a reason for hiding this comment

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

LGTM

@djrtwo djrtwo merged commit 8d9541e into dev Feb 12, 2020
@djrtwo djrtwo deleted the min-block-slot-gossip-val branch February 12, 2020 22:54
@@ -251,6 +251,7 @@ There are two primary global topics used to propagate beacon blocks and aggregat

- `beacon_block` - This topic is used solely for propagating new signed beacon blocks to all nodes on the networks. Signed blocks are sent in their entirety. The following validations MUST pass before forwarding the `signed_beacon_block` on the network
- The block is not from a future slot (with a `MAXIMUM_GOSSIP_CLOCK_DISPARITY` allowance) -- i.e. validate that `signed_beacon_block.message.slot <= current_slot` (a client MAY queue future blocks for processing at the appropriate slot).
- The block is from a slot greater than the latest finalized slot (with a `MAXIMUM_GOSSIP_CLOCK_DISPARITY` allowance) -- i.e. validate that `signed_beacon_block.message.slot > compute_start_slot_at_epoch(state.finalized_checkpoint.epoch)` (a client MAY choose to validate and store such blocks for additional purposes -- e.g. slashing detection, archive nodes, etc).
Copy link
Collaborator

Choose a reason for hiding this comment

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

We should consider that depending on the configuration of the mesh a portion of such blocks may not reach slashing detectors and archive nodes at all.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I'm a bit mixed on how these DoS vectors should be handled wrt slashing detection.

Let's chat about it on next networking call

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

Successfully merging this pull request may close these issues.

3 participants