-
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: Genesis Vesting Accounts & Simulation #3308
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #3308 +/- ##
===========================================
- Coverage 55.53% 55.44% -0.09%
===========================================
Files 134 134
Lines 9794 9802 +8
===========================================
- Hits 5439 5435 -4
- Misses 4012 4024 +12
Partials 343 343 |
@@ -64,7 +64,7 @@ func createSingleInputSendMsg(r *rand.Rand, ctx sdk.Context, accs []simulation.A | |||
toAcc = simulation.RandomAcc(r, accs) | |||
} | |||
toAddr := toAcc.Address | |||
initFromCoins := mapper.GetAccount(ctx, fromAcc.Address).GetCoins() | |||
initFromCoins := mapper.GetAccount(ctx, fromAcc.Address).SpendableCoins(ctx.BlockHeader().Time) |
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.
Note we need to make sure we only send "sendable" amount of coins.
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.
Ah - but sometimes (randomly) I think we should try to spend more than we can!
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 we try to send any more than "sendable", then subtractCoins
will panic. Did you mean something else?
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 transaction tries to spend more, it should fail - right?
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.
yes, it'll fail and panic at subtractCoins
.
cmd/gaia/app/sim_test.go
Outdated
// TODO: Do the vesting periods need to be shrunk to account for short | ||
// simulations? | ||
startTime := genesisTimestamp.Unix() | ||
endTime := r.Int63n((startTime+(60*60*24*2))-startTime) + startTime |
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.
@cwgoes is the end time generated here reasonable? Or should it be much shorter...in the manner of seconds?
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 think this is OK - a few-hundred block sim will run several days in virtual time.
Randomize it some more though - some vesting accounts should vest very quickly; others very slowly.
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.
Updated -- lmk your thoughts.
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.
On the right track, several comments. In the simulation we should randomize parameters almost always.
cmd/gaia/app/sim_test.go
Outdated
// create a vesting account under the following conditions: | ||
// - not an initially bonded (genesis) validator | ||
// - every 10th account past the initial bonded validator set | ||
if int64(i) > numInitiallyBonded && i+1%10 == 0 { |
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.
Can we use a random condition instead (each account has some chance of being vesting)?
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.
Also there's no reason the initially bonded validators can't have vesting accounts.
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.
Can we use a random condition instead (each account has some chance of being vesting)?
Sure, how do you suggest we do so?
Also there's no reason the initially bonded validators can't have vesting accounts.
True, but this caused me headache because the vesting accounts won't have DelegatedVesting
populated and thus future delegations/undelegations will fail. I think if we want to support this, we have to add such fields to GenesisAccount
which is a bit ugly imho. Perhaps we should be okay with vesting accnts never being in the initial bonded set.
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.
Updated.
cmd/gaia/app/sim_test.go
Outdated
// TODO: Do the vesting periods need to be shrunk to account for short | ||
// simulations? | ||
startTime := genesisTimestamp.Unix() | ||
endTime := r.Int63n((startTime+(60*60*24*2))-startTime) + startTime |
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 think this is OK - a few-hundred block sim will run several days in virtual time.
Randomize it some more though - some vesting accounts should vest very quickly; others very slowly.
cmd/gaia/app/sim_test.go
Outdated
startTime := genesisTimestamp.Unix() | ||
endTime := r.Int63n((startTime+(60*60*24*2))-startTime) + startTime | ||
|
||
if r.Int()%2 == 0 { |
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.
See above comment (would prefer this to be a random condition).
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.
Updated.
@@ -64,7 +64,7 @@ func createSingleInputSendMsg(r *rand.Rand, ctx sdk.Context, accs []simulation.A | |||
toAcc = simulation.RandomAcc(r, accs) | |||
} | |||
toAddr := toAcc.Address | |||
initFromCoins := mapper.GetAccount(ctx, fromAcc.Address).GetCoins() | |||
initFromCoins := mapper.GetAccount(ctx, fromAcc.Address).SpendableCoins(ctx.BlockHeader().Time) |
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.
Ah - but sometimes (randomly) I think we should try to spend more than we can!
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.
Looks like @cwgoes concerns were handled. Tested locally and looking good for me.
GetVestedCoins
bug where block time is past vesting end timeint64
fromtime.Time
*BaseAccount
as this will allow vesting accounts to have the account number/sequences inheritedcloses: #3305
Targeted PR against correct branch (see CONTRIBUTING.md)
Linked to github-issue with discussion and accepted design OR link to spec that describes this work.
Wrote tests
Updated relevant documentation (
docs/
)Added entries in
PENDING.md
with issue #rereviewed
Files changed
in the github PR explorerFor Admin Use: