[RFC] Built-in beacon-node incentivization

[Swader]

I believe we have an opportunity to make an impact on the ecosystem if we approach the problem of beacon node incentivization (history) from day 0.

I propose we build Nimbus with a beacon node service built in, which would let beacon node runners provide a Vipnode-like service by running the node with a specific miner-like flag. E.g.

nimbus --maxPeers 50 --weiPerEpoch 5e18 --wallet myNimbusWallet.eth

This lets a user set the price per epoch per validator using the node, and the validator can pre-pay a certain amount. Nimbus would log this validator's public address in the database along with the number of epochs the validator has purchased access to. This then decreases the number of peer slots by one for that duration.

The ability to modify the per epoch price of access makes sure there is some market competition, and the fact that Nimbus can do this at all would increase adoption dramatically in the early days. What's more, it's likely that inspired by our success in this context other clients would adopt a same or similar process, perhaps even based on some standard put forth by the Nimbus team, making the API identical across clients and driving cross-client competition for beacon node providing, thereby discouraging the appearance of Infura-like entities.

For some manner of security, it should be impossible to run a beacon node provider without also validating natively on it, to have extra stake in providing truthful BN data.

[Buttaa]

what speaks against earning a small amount of ETH for running a beacon node?
this would also give people who have less than the required amount to stake an entry to earn ETH.

[Swader]

That's a discussion best left for Eth2.0 specs, as Nimbus is purely about implementing what's already been specced. In a nutshell, you can't let beacon node operators earn eth for providing the service because there's nothing to prevent them from providing you with wrong data. You need to be a staker in the network in order to be punishable for bad behavior. So this proposal implies that the one running a beacon node would also run a validator, in addition to 50 slots for other validators to connect to this node.

[MH-Yin]

Is there any progress on this issue? I looked at the recent official documentation and didn't see an introduction to this although it's been three years, I'd be very grateful if you have any relevant conclusions