lighthouse
lighthouse copied to clipboard
sigp
Separate BN for block proposals
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.
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.
I'm happy to review this and merge it for v3.3.0 if you have appetite to fix the merge conflicts @AgeManning
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
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?
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.
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.