-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
R4R: Allow the undelegation of more coins than were delegated; More validity checks. #3717
Conversation
This reverts commit 2f9a0da.
Codecov Report
@@ Coverage Diff @@
## develop #3717 +/- ##
===========================================
- Coverage 61.46% 61.34% -0.12%
===========================================
Files 189 189
Lines 14057 14094 +37
===========================================
+ Hits 8640 8646 +6
- Misses 4876 4894 +18
- Partials 541 554 +13 |
panic(fmt.Sprintf("Validator consensus-address %v not found", consAddr)) | ||
// ignore evidence that cannot be handled. | ||
return | ||
// NOTE: |
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.
We aren't talking about having the validators in storage here, we're talking about just the public keys associated with the consensus addresses. Why would Tendermint ever send the application a consensus address for which the application hadn't stored a public key?
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.
it's in the comment below. because the app deletes the validator after the unbonding period is over (say), and the simulator or tendermint doesn't yet know exactly when this happens. so currently the simulator is breaking the app because it's not very intelligent with inserting evidence. same could happen w/ tendermint.
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.
Indeed the app does delete the validator after the unbonding period is over (x/slashing/hooks.go:35
), and the simulation could still send evidence - which I would consider a bug in the simulation, but I guess the simulation's job is to model whatever the actual Tendermint might do - does Tendermint submit evidence past the unbonding period (if max evidence age is set equal to it)?
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.
It doesn't seem likely that programmers will get it all right, even if Tendermint were to support evidence... it just seems like a difficult thing to do, or even to prove from the perspective of a developer, even if the criterion for evidence correctness were to be defined by the app in another ABCI message (say). So let's go with defensive here, which we can undo later easily (since it's a single if statement). Later apps can upgrade to become less permissive, and that's fine once Tendermint+SDK's been upgraded to support evidence at only allowable heights.
Notifying the programmer/operator of these issues can be done via WARN logging/notification of some sort, which should be built out on the Tendermint side.
k.AllocateTokensToValidator(ctx, proposerValidator, proposerReward) | ||
remaining = feesCollected.Sub(proposerReward) | ||
} else { | ||
// proposer can be unknown if say, the unbonding period is 1 block, so |
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.
If the unbonding period is greater than 1 block, the proposer should never be unknown, right? Should we panic in that case (we can fetch the unbonding period from the params) - or at least log a warning?
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.
ditto on at least a log here.
@@ -38,37 +37,33 @@ func RandStringOfLength(r *rand.Rand, n int) string { | |||
} | |||
|
|||
// Generate a random amount | |||
// Note: The range of RandomAmount includes max, and is, in fact, biased to return max. | |||
// Note: The range of RandomAmount includes max, and is, in fact, biased to return max as well as 0. | |||
func RandomAmount(r *rand.Rand, max sdk.Int) sdk.Int { |
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.
func RandomAmount(r *rand.Rand, max sdk.Int) sdk.Int { | |
func BiasedRandomAmount(r *rand.Rand, max sdk.Int) sdk.Int { |
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 don't think this is necessary to differentiate... RandomAmount might as well be biased all the time intelligently...
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.
IMHO it's not intuitive. Can the same be said for the native go library's rand functions?
} | ||
|
||
// RandomDecAmount generates a random decimal amount | ||
// Note: The range of RandomDecAmount includes max, and is, in fact, biased to return max. | ||
// Note: The range of RandomDecAmount includes max, and is, in fact, biased to return max as well as 0. | ||
func RandomDecAmount(r *rand.Rand, max sdk.Dec) sdk.Dec { |
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.
func RandomDecAmount(r *rand.Rand, max sdk.Dec) sdk.Dec { | |
func BiasedRandomDecAmount(r *rand.Rand, max sdk.Dec) sdk.Dec { |
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.
A few minor notes and a question about whether we should panic if the proposer is unknown and the unbonding period is greater than 1 block (which seems likely to be the normal case); otherwise LGTM.
panic(fmt.Sprintf("Validator consensus-address %v not found", consAddr)) | ||
// ignore evidence that cannot be handled. | ||
return | ||
// NOTE: |
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 put all documentation above the return statement.
k.AllocateTokensToValidator(ctx, proposerValidator, proposerReward) | ||
remaining = feesCollected.Sub(proposerReward) | ||
} else { | ||
// proposer can be unknown if say, the unbonding period is 1 block, so |
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.
ditto on at least a log here.
This looks like it needs some comments addressed. |
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.
LGTM 👍
WIP