Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Set accum of freshly added validator -(total voting power) #2785
Set accum of freshly added validator -(total voting power) #2785
Changes from 3 commits
de44ee9
182fc6c
47cefd9
fc7339a
a5a4953
77c05d8
3b2e79e
7cbcd19
fdf6ceb
51ae57d
c98841c
b95160d
c445aa4
f1ed7fd
ce8357e
f94d626
d852b39
7b9e883
edd0c9a
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still think we should multiply by a constant (maybe 2 or 3)
Without a constant, it will be advantageous to still unbond / rebond in a lot of scenarios to increase your accum.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The scenario is what you describe in #2718 (comment) right?
By using a multiplicative factor, e.g. 2, this would rather mean you can split up in 3 or more validators and do a similar thing you described, is that right? I can change it to 3. And we can do a proper decoupling after launch, OK? (I find such a constant a bit weird though; we need a more solid argument for choosing 2 or 3 explaining the rational behind the choice) @ebuchman @ValarDragon @milosevic @cwgoes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, the attack is mitigated in all cases by using such a constant. (It is not eliminated, solely mitigated) The mitigation comes from unbonding always having a cost for a validator that would normally be proposing, whereas in the described system, there is no cost / it may be profitable to do so anyway. (As suppose your the lowest, then unbonding / rebonding still helps you become not the lowest)
The idea being simulated is when you initially bond, there is a period where you aren't eligible to propose and your accum isn't increasing, but you do contribute to total stake. Perhaps its better to just do that directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would propose to properly write down the math and fix this more complex attack (which involves splitting up validators) in a follow-up PR. How does that sound to you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess. I feel like its worked out in the issue, but given the discussion there perhaps I didn't explain it well enough or I'm missing something. Also correctness of the entire thing can't really be proven, since the algorithm itself is quite biasable. (We'd need a careful definition to prove any deterministic algorithm here secure) So at best it can show that it mitigates the gain from this attack. The constant was just meant as an easy way of simulating you not getting to be a proposer for the first n blocks after you bond, so that would still be better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, how about multiply by 10 and divide by 9?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hrmm, we can multiply by 1.125 quite efficiently,
x + (x >> 3)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that works!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK,
x + (x >> 3)
works but we'd need to make sure we do not overflow here.vals.TotalVotingPower()
is only bound byMaxInt64
(via clipping). Computingx + (x >> 3)
could potentially overflow. A consistent way to deal with this would be to clip (again) in the case of an overflow. Alternatively, we could enforce a stricter bound on totalVotingPower.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.