Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is it even worth running an Eth1 node for solo stakers in Phase 0? #2152

Closed
benjaminion opened this issue Dec 14, 2020 · 4 comments
Closed

Comments

@benjaminion
Copy link
Contributor

benjaminion commented Dec 14, 2020

An heretical click-baity title. But consider the economics.

In principle, the penalty for not having current knowledge of the deposit contract via an Eth1 node is that you cannot include pending deposits in your blocks, and thus your proposed blocks are invalid. By my calculations, 97% of expected validator rewards accrue from attestations and 3% from block proposals. So the maximum penalty for not connecting to an Eth1 node is 3% of the expected rewards.

In practice, however, it is much less than that. A proposed block is invalid with respect to deposit inclusion only when there are pending deposits to be included. Let's see how often that applies.

Looking at slots 32768 through 65535 on the beacon chain mainnet, a period of heavy onboarding of new validators:

  • 32768 slots contain
  • 32228 blocks,
  • 453 (1.4%) of which contain deposits.

Thus, my expected loss in rewards from not connecting to an Eth1 node is 1.4% * 3% = 0.042%. At, say, 15% annual return on 32 ETH, with an ETH price of $600, my expected missed reward per validator from not running an Eth1 node will be $1.21 per year.

Given the hassle and resource requirements of running an Eth1 node, doing so does not seem economically rational on this basis.

Moreover, there is an implied incentive not to include deposits (or make accurate Eth1 votes) as preventing new validators from entering the network increases my annual return rate.

Recommendations

Obviously, the network is healthier if people are connecting to Eth1 nodes. I suggest the following.

  1. Substantially reduce the number of deposits included per beacon block from 16 to one (set MAX_DEPOSITS to 1). Only four activations may be processed per epoch (rising to 5 and more in future, but always substantially fewer than 32), so inclusion of deposits in blocks is not the rate limiting step for onboarding validators, if most deposits are of 32 ETH.
    Con: None, if validators connect to Eth1 nodes as desired. Otherwise, some increase in invalid blocks.
    Pro: Spread the penalties more broadly for not being connected to an Eth1 node; reduce the maximum block size.

  2. Apply a substantial reward for including a deposit. The should be a good fraction of the deposit amount (1/256?) to incentivise healthy behaviour with respect to Eth1.
    Con: Increased issuance. But the cost is well bounded by the total amount of Eth2 that can be deposited.
    Pro: Incentivise healthy behaviour with respect to Eth1, which is effectively barely incentivised currently. This also resolves Analysis of Eth1 data votes on Medalla #2018 by providing an (indirect) incentive to get Eth1 votes correct.

@dankrad
Copy link
Contributor

dankrad commented Dec 14, 2020

I think this is a good time to point out that if you have several behaviours you want to incentivise, then the best way to do it is not additive but multiplicative. Idea: You rate all validator desired behaviours on a scale from 0.0 to 1.0, and multiply them together. Total rewards are simply max rewards times this factor. Anyone completely failing on any of the behaviours will get no reward.

Independent thought, specific to this problem: I think this can be solved by adding custody of Eth1 blocks to the attestations. Thanks to 0.01 bit proof of custody, this comes with no overhead on the beacon chain and only a 0.1% loss in attestations.

@djrtwo
Copy link
Contributor

djrtwo commented Dec 17, 2020

To be honest, this is a bug. The intention is for proposing to account for ~1 / PROPOSER_REWARD_QUOTIENT of total validator rewards, but it is in fact 1 / PROPOSER_REWARD_QUOTIENT of a base_reward (each base_reward is 1/4th of the total reward so is 1/32 of total rewards, the 3% you mention).

This is already fixed in the accounting reform PR (something we'd like to see in mid next year). This is also naturally balancing in the sense that if some validators don't produce blocks, there are more attestations for the subsequent validator to include (yes, this fails in the event that blocks are entirely full..)

@dankrad
Copy link
Contributor

dankrad commented Dec 17, 2020

Even if we make it 1/8=12.5%, I doubt that the rationality dynamics actually change. Assuming that an Eth1 node is >50% of the cost of running a validator, it will probably be rational to not run one for small scale (<5 validators) stakers.

@benjaminion
Copy link
Contributor Author

This is long dead and essentially resolved post-Merge, so closing.

I still think that the the best option would have been to set MAX_DEPOSITS to 1, but it's academic now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants