Add capability to bind to different interfaces for attestation production and block proposals

[benjaminion]

Related to #5929.

As a staker wanting to avoid DDoS attacks on my node as a block producer, I'd like the beacon node to publish attestations/sync contributions on one network interface and blocks on a different netwok interface.

I imagine we could add options like,

• --p2p-proposer-interface - when present this would be used for block proposals and only for block proposals with all the normal traffic remaining on --p2p-interface.
• Analogues to the other --p2p-* options where appropriate (such as min/max peers, port numbers, etc.)

This would benefit stakers with two network connections available who wish to have sentry node capability while running only one instance of a beacon node. The workaround would be for me to run two separate beacon nodes, one on each network and to make use of the sentry node functionality. That would incur a substantial overhead.

[ajsutton]

I think the challenge here is that when we publish blocks we do so over an already established TCP connection to our peers. That connection will have been determined by the routing table and we can't change the source it comes from.

To achieve this we'd need to setup two independent libp2p stacks, each maintaining their own set of peers and then blocks could be published through one of them. Both would need to gossip as normal though meaning it would be a significant increase in network usage - akin to running an additional beacon node with no validators attached.

[benjaminion]

Right. But that's no worse than the alternative I mentioned of having to run two separate BNs, and overall it saves a bunch of disk space and memory to have them in one instance rather than two.

A downside of having one instance rather than two would be if an attacker could DoS the beacon node (rather than just the network connection) then it would not be in a fit state to publish anything via the second interface.

[Nashatyrev]

At the moment I have the prototype (calling it Heku aka Hacker Teku) which is able to run up to ~1000 distinct virtual nodes on their own distinct IPs (or several nodes per IP). It uses the same libp2p stack and a single Gossip instance which saves a lot of CPU/memory comparing to the similar number of real nodes. At the moment the setup may run on 16Gb RAM and 8 cores

Different IPs are now spawn up via minimal AWS instance with iptable settings (to forward inbound connections) and SOCKS5 (for outbound connections). Using different net interfaces shouldn't be a big deal as well

So that could be an alternative approach to dedicated sentry nodes