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

Unexpected multi-deposit incentive #1609

Closed
JustinDrake opened this issue Feb 5, 2020 · 12 comments
Closed

Unexpected multi-deposit incentive #1609

JustinDrake opened this issue Feb 5, 2020 · 12 comments
Labels

Comments

@JustinDrake
Copy link
Collaborator

JustinDrake commented Feb 5, 2020

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
Copy link
Contributor

vbuterin commented Feb 5, 2020

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
Copy link
Collaborator Author

JustinDrake commented Feb 5, 2020

Allow deposits up to 32.5 ETH instead of 32.

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

@Buttaa
Copy link

Buttaa commented Feb 5, 2020

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
Copy link
Contributor

mcdee commented Feb 5, 2020

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
Copy link
Contributor

prestonvanloon commented Feb 6, 2020

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
Copy link
Contributor

mcdee commented Feb 6, 2020

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
Copy link
Contributor

prestonvanloon commented Feb 6, 2020

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
Copy link
Contributor

djrtwo commented Feb 6, 2020

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
Copy link
Contributor

prestonvanloon commented Feb 6, 2020

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
Copy link
Contributor

mcdee commented Feb 6, 2020

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
Copy link
Contributor

djrtwo commented Feb 18, 2020

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
Copy link
Contributor

djrtwo commented Mar 17, 2020

addressed in v0.11.0 release

@djrtwo djrtwo closed this as completed Mar 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants