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
Comments
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 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. |
To be honest, this is a bug. The intention is for proposing to account for ~ 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..) |
Even if we make it |
This is long dead and essentially resolved post-Merge, so closing. I still think that the the best option would have been to set |
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:
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.
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.
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.
The text was updated successfully, but these errors were encountered: