Lighthouse: RFC: Add a --staking or --no-staking flag

[paulhauner]

Overview

During the Medalla launch I noticed that many users didn't provide the --eth1 or --http flags, meaning their validators were unable to function.

Here are two proposals to make it easier for stakers

Proposal A: Staking by default

We could modify the lighthouse bn CLI flags as such:

• Remove --http.
• Remove --eth1.
• Add --no-staking: Disables eth1 connection and indicates to other block/attestation production components that they'll never be needed.
• Add --no-http: disables the http server.

So, we have the following commands:

• lighthouse bn
  
  
  
  • http: yes
  
  
  • eth1: yes
  
  
• lighthouse bn --no-staking
  
  
  
  • http: yes
  
  
  • eth1: no
  
  
• lighthouse bn --no-staking --no-http
  
  
  
  • http: no
  
  
  • eth1: no
  
  
• lighthouse bn --no-http
  
  
  
  • http: no
  
  
  • eth1: yes
  
  
  • Note: I'm struggling to see a use-case for this but I also don't see harm in having it.
  
  

Proposal B: Optional staking

We could modify the lighthouse bn CLI flags as such:

• Add --staking: Is an explicit version of --http --eth1.

So, we have the following commands:

• lighthouse bn
  
  
  
  • http: no
  
  
  • eth1: no
  
  
• lighthouse bn --staking
  
  
  
  • http: yes
  
  
  • eth1: yes
  
  
• lighthouse bn --eth1
  
  
  
  • http: no
  
  
  • eth1: yes
  
  
• lighthouse bn --eth1 --http
  
  
  
  • http: yes
  
  
  • eth1: yes
  
  

Thanks to @AgeManning for this proposal

[michaelsproul]

100% in favour. With the accessibility of staking and the fact that most people want to stake, I think this is a good default :tada:

[AgeManning]

I think this is a consequence of a free-eth testnet.

Everyone wants to run and participate in staking as that is what we have encouraged. For mainnet however, I doubt most users will be running 24h nodes with actual eth on the line. I think most users will then want to run nodes read metrics etc similar to geth.

I'd imagine diverging from the current norm (geth) in that the http and rpc need to be enabled might be worse from a UX perspective and potentially a security risk by default opening ports which we have assumed to be trusted.

I'm happy to go and change this, but I think we'll be reverting again after issues on mainnet.

[paulhauner]

I'd imagine diverging from the current norm (geth) in that the http and rpc need to be enabled might be worse from a UX perspective and potentially a security risk by default opening ports which we have assumed to be trusted.

An alternative would be to add a --staking flag which enables both http and eth1.

This means that you get not-staking by default and it's just one flag if you want to stake.

[paulhauner]

An alternative would be to add a --staking flag which enables both http and eth1.

I've updated the proposal to include this as well. I'm interested to hear preferences!

[AgeManning]

Yeah, I think additionally adding --staking will help from a UX perspective. Keeping the --http option for non-stakers who want the RPC.

I'm in favour of this approach

[markrtgh]

--staking preferred with a warning that the http port is open. Many Ethereum users have lost ETH by not understanding the risks of having an open http port so non-stakers should be required to use --http if they want it open. This would follow the geth convention for security for web3 interactions where users have to use --http or --ws with only IPC active by default without a flag. This may also make things easier for phase 1.5/2 when ETH transactions are activated.

[hermanjunge]

An alternative would be to add a --staking flag which enables both http and eth1.

+1

--staking preferred with a warning that the http port is open.

+1

[pawanjay176]

I'll take this one.