Separate BN for block proposals by AgeManning · Pull Request #3328 · sigp/lighthouse

AgeManning · 2022-07-13T08:38:03Z

It is a well-known fact that IP addresses for beacon nodes used by specific validators can be de-anonymized. There is an assumed risk that a malicious user may attempt to DOS validators when producing blocks to prevent chain growth/liveness.

Although there are a number of ideas put forward to address this, there a few simple approaches we can take to mitigate this risk.

Currently, a Lighthouse user is able to set a number of beacon-nodes that their validator client can connect to. If one beacon node is taken offline, it can fallback to another. Different beacon nodes can use VPNs or rotate IPs in order to mask their IPs.

This PR provides an additional setup option which further mitigates attacks of this kind.

This PR introduces a CLI flag --proposer-only to the beacon node. Setting this flag will configure the beacon node to run with minimal peers and crucially will not subscribe to subnets or sync committees. Therefore nodes of this kind should not be identified as nodes connected to validators of any kind.

It also introduces a CLI flag --proposer-nodes to the validator client. Users can then provide a number of beacon nodes (which may or may not run the --proposer-only flag) that the Validator client will use for block production and propagation only. If these nodes fail, the validator client will fallback to the default list of beacon nodes.

Users are then able to set up a number of beacon nodes dedicated to block proposals (which are unlikely to be identified as validator nodes) and point their validator clients to produce blocks on these nodes and attest on other beacon nodes. An attack attempting to prevent liveness on the eth2 network would then need to preemptively find and attack the proposer nodes which is significantly more difficult than the default setup.

Fix closure lifetimes by cloning HTTP client

Fix closure lifetimes by using functions

AgeManning · 2022-08-02T01:11:23Z

I'll keep this updated with current unstable.

I've been testing with the simulator and we need to build some extra tests into our testnet setup to test this at a larger scale before merging.

Getting some extra eyes on this would be good.

michaelsproul · 2022-11-09T03:43:30Z

I'm happy to review this and merge it for v3.3.0 if you have appetite to fix the merge conflicts @AgeManning

AgeManning · 2022-11-09T22:38:07Z

Yeah Ok. Will do. Will probably need a bit of real-world testing I imagine. Maybe we can recruit help from any interested parties to test

michaelsproul · 2022-11-09T23:11:21Z

I'm feeling a bit of a YOLO mood for v3.3.0, so I think we could merge to unstable and test more thoroughly after that?

paulhauner · 2023-02-21T00:06:38Z

I'm going to bump this to v3.5.1 since I don't think we have the time to get this in and tested for v3.5.0.

validator_client/src/block_service.rs

paulhauner

One suggestion to try and get Github to refresh itself and align with https://github.com/AgeManning/lighthouse/tree/bn-proposer

paulhauner · 2023-04-12T08:08:50Z

beacon_node/src/cli.rs

+            Arg::with_name("proposer-only")
+                .long("proposer-only")
+                .help("Sets this beacon node at be a block proposer only node. \
+                       This will run the beacon node in a minimal configuration that is sufficient for block production only. This flag should be used \


Suggested change

This will run the beacon node in a minimal configuration that is sufficient for block production only. This flag should be used \

This will run the beacon node in a minimal configuration that is sufficient for block publishing only. This flag should be used \

This is a minor lint that I'm mostly using to try and get Github to refresh itself. There's some weird discrepancy between this PR and https://github.com/AgeManning/lighthouse/tree/bn-proposer 🤔

Eh, I thought I'd be able to apply this suggestion myself but Github won't let me.

paulhauner · 2023-04-12T08:16:39Z

Hmm, I can't re-open it either. Man, this PR is so weird. Could you please re-open and apply my suggestion please @AgeManning. I was trying to sort it out myself, but it appears I am powerless when it comes to this PR.

It is a well-known fact that IP addresses for beacon nodes used by specific validators can be de-anonymized. There is an assumed risk that a malicious user may attempt to DOS validators when producing blocks to prevent chain growth/liveness. Although there are a number of ideas put forward to address this, there a few simple approaches we can take to mitigate this risk. Currently, a Lighthouse user is able to set a number of beacon-nodes that their validator client can connect to. If one beacon node is taken offline, it can fallback to another. Different beacon nodes can use VPNs or rotate IPs in order to mask their IPs. This PR provides an additional setup option which further mitigates attacks of this kind. This PR introduces a CLI flag --proposer-only to the beacon node. Setting this flag will configure the beacon node to run with minimal peers and crucially will not subscribe to subnets or sync committees. Therefore nodes of this kind should not be identified as nodes connected to validators of any kind. It also introduces a CLI flag --proposer-nodes to the validator client. Users can then provide a number of beacon nodes (which may or may not run the --proposer-only flag) that the Validator client will use for block production and propagation only. If these nodes fail, the validator client will fallback to the default list of beacon nodes. Users are then able to set up a number of beacon nodes dedicated to block proposals (which are unlikely to be identified as validator nodes) and point their validator clients to produce blocks on these nodes and attest on other beacon nodes. An attack attempting to prevent liveness on the eth2 network would then need to preemptively find and attack the proposer nodes which is significantly more difficult than the default setup. This is a follow on from: #3328 Co-authored-by: Michael Sproul <michael@sigmaprime.io> Co-authored-by: Paul Hauner <paul@paulhauner.com>

It is a well-known fact that IP addresses for beacon nodes used by specific validators can be de-anonymized. There is an assumed risk that a malicious user may attempt to DOS validators when producing blocks to prevent chain growth/liveness. Although there are a number of ideas put forward to address this, there a few simple approaches we can take to mitigate this risk. Currently, a Lighthouse user is able to set a number of beacon-nodes that their validator client can connect to. If one beacon node is taken offline, it can fallback to another. Different beacon nodes can use VPNs or rotate IPs in order to mask their IPs. This PR provides an additional setup option which further mitigates attacks of this kind. This PR introduces a CLI flag --proposer-only to the beacon node. Setting this flag will configure the beacon node to run with minimal peers and crucially will not subscribe to subnets or sync committees. Therefore nodes of this kind should not be identified as nodes connected to validators of any kind. It also introduces a CLI flag --proposer-nodes to the validator client. Users can then provide a number of beacon nodes (which may or may not run the --proposer-only flag) that the Validator client will use for block production and propagation only. If these nodes fail, the validator client will fallback to the default list of beacon nodes. Users are then able to set up a number of beacon nodes dedicated to block proposals (which are unlikely to be identified as validator nodes) and point their validator clients to produce blocks on these nodes and attest on other beacon nodes. An attack attempting to prevent liveness on the eth2 network would then need to preemptively find and attack the proposer nodes which is significantly more difficult than the default setup. This is a follow on from: sigp#3328 Co-authored-by: Michael Sproul <michael@sigmaprime.io> Co-authored-by: Paul Hauner <paul@paulhauner.com>

Initial draft, not finished VC yet

ea755b6

AgeManning added the work-in-progress PR is a work-in-progress label Jul 13, 2022

asn-d6 mentioned this pull request Jul 14, 2022

Add Support For Sentry Nodes In Prysm OffchainLabs/prysm#11048

Open

AgeManning and others added 6 commits July 15, 2022 16:07

Mostly complete, still to handle closure lifetimes

a1cbf7c

Fix closure lifetimes by cloning HTTP client

88f22c3

Remove closures and clones

58de945

Merge pull request #2 from michaelsproul/bn-proposer

fbf533b

Fix closure lifetimes by cloning HTTP client

Merge pull request #3 from michaelsproul/bn-proposer-alt

55b3cfb

Fix closure lifetimes by using functions

fmt

a6bfd2d

AgeManning marked this pull request as ready for review July 18, 2022 01:50

AgeManning added 6 commits July 18, 2022 11:58

Fix typo

8fb5473

Re-order target-peer cli config

f6d4345

Draft up a book topic

b339191

Remove CLI default for target-peers to allow override

c56496d

Produce block from default nodes before proposer-only

4277059

Temp simulator update

e76365e

torfbolt mentioned this pull request Jul 23, 2022

Feature: Multiple consensus clients for validator client Consensys/teku#5237

Closed

AgeManning added ready-for-review The code is ready for review and removed work-in-progress PR is a work-in-progress labels Aug 2, 2022

cheatfate mentioned this pull request Sep 19, 2022

Document the new VC roles and strategies features status-im/nimbus-eth2#4140

Closed

michaelsproul added waiting-on-author The reviewer has suggested changes and awaits thier implementation. v3.3.0 Minor release following v3.2.0 and removed ready-for-review The code is ready for review labels Nov 9, 2022

Merge latest unstable

0aac29a

michaelsproul added v3.4.0 Minor release following v3.3.0 and removed v3.3.0 Minor release following v3.2.0 labels Nov 21, 2022

michaelsproul added v3.5.0 Minor release circa Q1 2023 and removed v3.4.0 Minor release following v3.3.0 labels Jan 8, 2023

paulhauner added v3.5.1 Scheduled for March 2023 and removed v3.5.0 Minor release circa Q1 2023 labels Feb 21, 2023

AgeManning closed this by deleting the head repository Feb 22, 2023

AgeManning reopened this Feb 22, 2023

paulhauner added v4.0.0 Mainnet Capella release expected late March 2023 and removed v3.5.1 Scheduled for March 2023 labels Mar 5, 2023

paulhauner reviewed Mar 13, 2023

View reviewed changes

validator_client/src/block_service.rs Show resolved Hide resolved

paulhauner self-assigned this Mar 13, 2023

paulhauner mentioned this pull request Mar 15, 2023

Remove duplication in block service for bn-proposer AgeManning/lighthouse#4

Merged

AgeManning added v4.1.0 Post-Capella minor release and removed v4.0.0 Mainnet Capella release expected late March 2023 labels Mar 20, 2023

paulhauner reviewed Apr 12, 2023

View reviewed changes

paulhauner closed this Apr 12, 2023

AgeManning mentioned this pull request Apr 13, 2023

[Merged by Bors] - Separate BN for block proposals #4182

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Separate BN for block proposals#3328

Separate BN for block proposals#3328
AgeManning wants to merge 14 commits intosigp:unstablefrom
AgeManning:bn-proposer

AgeManning commented Jul 13, 2022

Uh oh!

AgeManning commented Aug 2, 2022

Uh oh!

michaelsproul commented Nov 9, 2022

Uh oh!

AgeManning commented Nov 9, 2022

Uh oh!

michaelsproul commented Nov 9, 2022

Uh oh!

paulhauner commented Feb 21, 2023 •

edited

Loading

Uh oh!

Uh oh!

paulhauner left a comment

Uh oh!

paulhauner Apr 12, 2023

Uh oh!

paulhauner Apr 12, 2023

Uh oh!

paulhauner commented Apr 12, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

	This will run the beacon node in a minimal configuration that is sufficient for block production only. This flag should be used \
	This will run the beacon node in a minimal configuration that is sufficient for block publishing only. This flag should be used \

Conversation

AgeManning commented Jul 13, 2022

Uh oh!

AgeManning commented Aug 2, 2022

Uh oh!

michaelsproul commented Nov 9, 2022

Uh oh!

AgeManning commented Nov 9, 2022

Uh oh!

michaelsproul commented Nov 9, 2022

Uh oh!

paulhauner commented Feb 21, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

paulhauner left a comment

Choose a reason for hiding this comment

Uh oh!

paulhauner Apr 12, 2023

Choose a reason for hiding this comment

Uh oh!

paulhauner Apr 12, 2023

Choose a reason for hiding this comment

Uh oh!

paulhauner commented Apr 12, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

paulhauner commented Feb 21, 2023 •

edited

Loading