Unexpected multi-deposit incentive

[JustinDrake]

See context from the 3rd AMA here. The problem is that if someone deposits 32 ETH and early on their balance goes down (even just a bit) then they will have to wait until their balance goes back up to 32.5 ETH (because of hysteresis) for the effective balance to become 32 ETH. This could incentivise some validators to make a second deposit which is not ideal.

[vbuterin]

The main solutions I see are:

1. Change the increment/decrement thresholds to x-0.25 and x+0.75
2. Allow deposits up to 32.5 ETH instead of 32.

[JustinDrake]

Allow deposits up to 32.5 ETH instead of 32.

Deposits above 32 ETH are allowed. Any size above 1 ETH is allowed.

[Buttaa]

There are two cases:

1. you deposit and don't get any early punishments (=don't need additional ETH)
2. you get punished early, and then you will need to deposit >=1ETH

not the best UX

[mcdee]

Secondary deposits have rather limited use cases, due to the minimum deposit being 1 Ether.

They come in to play if your balance is in the range (x+0.5Ξ,x+1Ξ) for some integer value of x between 16 and 30, as you can carry out a top-up to get yourself above the latch point for the next effective balance increment. For example, if you had a balance of 29.9Ξ (and hence effective balance of 29Ξ) then a top-up deposit of 1.61Ξ would result in a balance of 31.51Ξ (and hence effective balance of 31Ξ). For any other situation I believe that the effective balance won't increase further than the the increase in balance.

In general, though, a staker that finds themself in this position (i.e. with a balance less than 31Ξ)is unlikely to be sophisticated enough to carry out this operation (unless there have been some serious finality issues).

[prestonvanloon]

My biggest concern is that if I'm not online in my activation epoch, then I'm going to lose rewards for a long period of time. Given this concern, what about some additional logic that the effective balance cannot change within X epochs? I.e. if I was activated at epoch N, my effective balance cannot drop until epoch N+X? If I had any initial liveness issue and I resolved it in X/2 time, then I would be OK.

That would allow some tolerance for first time activations without much change to the rest of the hysteresis effective balance algorithm.

[mcdee]

Given that there is a minimum of 8 hours between someone creating a deposit and the validator becoming active, would another few epochs make a difference in terms of the user bringing the validator online?

If it really is a problem then adding a small safety margin to the initial deposit (e.g. an additional 0.01Ξ) should be enough to cover a number of epochs of not attesting without the balance dropping below 32Ξ.

[prestonvanloon]

Given that there is a minimum of 8 hours between someone creating a deposit and the validator becoming active, would another few epochs make a difference in terms of the user bringing the validator online?

I don't see an issue with this. If someone were to use an attack that involved activating a validator and never participating, they would be penalized more quickly during that N+X period given an inflated effective balance for a short period of time.

Likewise for the honest participant, if there is a liveness issue in that period, they will have a higher penalty. I think the trade off is worth it to mitigate the scenario outlined in the original comment.

Interested to hear feedback on this idea.

[djrtwo]

Given that there is a minimum of 8 hours between someone creating a deposit and the validator becoming active, would another few epochs make a difference in terms of the user bringing the validator online?

I read @mcdee's comment not as a suggestion to implement the + x but instead noting that you have 8+ hours to get online what does an additional x epochs buy you? (other than some added consensus complexity)

I'm in favor of what @vbuterin suggested -- Change the increment/decrement thresholds in the to x-0.25 and x+0.75. This is a simple change and provides a "get online" safety marge of 0.25 ETH before the effective change.

[prestonvanloon]

I read @mcdee's comment not as a suggestion to implement the + x but instead noting that you have 8+ hours to get online what does an additional x epochs buy you? (other than some added consensus complexity)

An additional X epochs gives you some time to build up a bit of earnings as a safe margin.

[mcdee]

There was a discussion about this on Discord. @djrtwo if there is a true hysteresis on the downside then effective balance can be greater than balance. I haven't thought it through, but could that cause problems?

An alternative was to go leave the existing system as is except to much reduce the hysteresis from requiring an additional 0.5 Ether before ticking up to requiring an additional 0.05 Ether. This would maintain the current state where effective balance <= balance at all times, but much reduce the long-term penalty for dropping below an integer Ether boundary.

[djrtwo]

I haven't thought it through, but could that cause problems?

It takes a bit longer for an inactivity leak to step down and affect finality, but in a true inactivity leak (>1/3 of the network offline or a major partition), this won't affect timing much at all

requiring an additional 0.5 Ether before ticking up to requiring an additional 0.05 Ether

I think the x-0.25 and x+0.75 is sufficient and a bit cleaner. I'm going to code it up now and get a PR for review.

[djrtwo]

addressed in v0.11.0 release