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

Enabling compounding growth for validators' stakes #730

Closed
CarlBeek opened this issue Mar 7, 2019 · 1 comment · Fixed by #936
Closed

Enabling compounding growth for validators' stakes #730

CarlBeek opened this issue Mar 7, 2019 · 1 comment · Fixed by #936
Labels
general:RFC Request for Comments

Comments

@CarlBeek
Copy link
Contributor

CarlBeek commented Mar 7, 2019

Receiving compounding returns on one's stake is something I deem to be vital in a system that should be competitive as an investment instrument (something I argue is essential for drawing in as much staking capital as possible).

In the current spec, the incentives could be deemed as unfair as get_effecitve_balance gives compounding returns to those who have less than 32 Eth (who have been mediocre validators at best) while giving constant (as a function of your balance) returns for those with more than 32 (those who are great validators).

A lack of compounding returns means that there is some point where it is worthwhile for a validator to logout and transfer their excess balance (their balance over 32 Eth) and then become a new active validator again. This will naturally increase the number of transactions in the beacon chain. Precisely where this point is depends on: the length of the exit queue, the fungibility of BETH, and the transfer fee market.

Validators with smaller holdings (say only 32 Eth) are encouraged to withdraw their excess Eth periodically and either send it to a staking pool or some other open-finance alternative. Validators with large stakes, say 32x 32Eth, would be behaving economically irrationally if they do not withdraw all of their stakes when they reach 33 Eth each and launch 33 validator instances of 32 Eth again.

One possible solution would be to change get_effective_balance to clip your balance into [16,64]. By raising the maximum to 64 Eth, honest validators can keep staking until each validator has sufficient rewards to spilt their validator instance into 2 separate instances. This would reduce the number of transfers (and thus size and processing) in the beacon chain whilst making staking a more attractive use of capital.

When implementing this proposal, it would also be sensible to revert transfers to accounts with >32 Eth. Otherwise, validators could consolidate their ether into fewer instances which is accentuates the issue described below:

The downside of this proposal is that validators with more that 32 Eth have to do less work than they are payed for (for as block proposers etc) but they are payed appropriately for the security that they provide.

Another issue is that honest validators (with large accrued stakes) will be shuffled to a single shard (instead of multiple shards as per the economically rational behaviour described above). This means that the minimum number of validators per shard will need to increase.

TLDR:
Currently validator balances over 32 Eth are not rewarded which represents capital inefficiency. Due to the design of the system, the better a validator's behaviour, the greater the burden of this capital inefficiency they occur. I propose providing rewards all the way up to 64 Eth. This does have some downsides though.

@hwwhww hwwhww added the general:RFC Request for Comments label Mar 12, 2019
@djrtwo
Copy link
Contributor

djrtwo commented Apr 17, 2019

I believe we decided to enable transfers for balances beyond MAX_EFFECTIVE_BALANCE rather than to enable compounding.

Important to note that we had previously discussed removing transfers at phase 2, but this would imply we want to keep them in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
general:RFC Request for Comments
Projects
None yet
3 participants