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

R4R: Allow the undelegation of more coins than were delegated; More validity checks. #3717

Merged
merged 15 commits into from
Feb 27, 2019

Conversation

jaekwon
Copy link
Contributor

@jaekwon jaekwon commented Feb 22, 2019

WIP

@jaekwon jaekwon changed the base branch from develop to cwgoes/debug-vesting-finding February 22, 2019 21:02
@codecov
Copy link

codecov bot commented Feb 22, 2019

Codecov Report

Merging #3717 into develop will decrease coverage by 0.11%.
The diff coverage is 47.69%.

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

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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)?

Copy link
Contributor Author

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.

@jaekwon jaekwon changed the title WIP: Allow the undelegation of more coins than were delegated; More validity checks. R4R: Allow the undelegation of more coins than were delegated; More validity checks. Feb 25, 2019
k.AllocateTokensToValidator(ctx, proposerValidator, proposerReward)
remaining = feesCollected.Sub(proposerReward)
} else {
// proposer can be unknown if say, the unbonding period is 1 block, so
Copy link
Contributor

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?

Copy link
Contributor

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
func RandomAmount(r *rand.Rand, max sdk.Int) sdk.Int {
func BiasedRandomAmount(r *rand.Rand, max sdk.Int) sdk.Int {

Copy link
Contributor Author

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...

Copy link
Contributor

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
func RandomDecAmount(r *rand.Rand, max sdk.Dec) sdk.Dec {
func BiasedRandomDecAmount(r *rand.Rand, max sdk.Dec) sdk.Dec {

Copy link
Contributor

@cwgoes cwgoes left a 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:
Copy link
Contributor

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

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.

PENDING.md Outdated Show resolved Hide resolved
@jaekwon jaekwon changed the base branch from cwgoes/debug-vesting-finding to develop February 25, 2019 16:56
@cwgoes cwgoes added this to the v0.33.0 (Launch) milestone Feb 25, 2019
@jackzampolin
Copy link
Member

This looks like it needs some comments addressed.

Copy link
Member

@jackzampolin jackzampolin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

@cwgoes cwgoes merged commit 10bd98e into develop Feb 27, 2019
@cwgoes cwgoes deleted the jae/undelegate_more branch February 27, 2019 21:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants