lighthouse/beacon_node
Age Manning 7456e1e8fa Separate BN for block proposals (#4182)
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>
2023-04-26 01:12:36 +00:00
..
beacon_chain add attestation inclusion distance in http api (#4148) 2023-04-26 01:12:35 +00:00
builder_client Set user agent on requests to builder (#4199) 2023-04-18 02:47:36 +00:00
client remove dup log (#4155) 2023-04-03 03:02:58 +00:00
eth1 exchangeCapabilities & Capella Readiness Logging (#3918) 2023-01-31 18:26:23 +01:00
execution_layer Fix Rust 1.69 lints (#4222) 2023-04-21 18:29:28 +00:00
genesis Fix the new BLS to execution change test 2023-01-25 15:47:07 +11:00
http_api add attestation inclusion distance in http api (#4148) 2023-04-26 01:12:35 +00:00
http_metrics Add content-type header to metrics server response (#3970) 2023-02-28 02:20:50 +00:00
lighthouse_network Separate BN for block proposals (#4182) 2023-04-26 01:12:36 +00:00
network Separate BN for block proposals (#4182) 2023-04-26 01:12:36 +00:00
operation_pool Use head state for exit verification (#4183) 2023-04-14 01:11:46 +00:00
src Separate BN for block proposals (#4182) 2023-04-26 01:12:36 +00:00
store Remove Redundant Trait Bound (#4169) 2023-04-12 01:48:22 +00:00
tests Appease Clippy 1.68 and refactor http_api (#4068) 2023-03-13 01:40:03 +00:00
timer Use async code when interacting with EL (#3244) 2022-07-03 05:36:50 +00:00
Cargo.toml Release v4.1.0 (#4191) 2023-04-20 00:51:38 +00:00