epoching: fuzz tests on epoched undelegations and redelegations #66
Conversation
| @@ -98,7 +98,8 @@ func SetupWithGenesisValSet(t *testing.T, valSet *tmtypes.ValidatorSet, genAccs | |||
| validators := make([]stakingtypes.Validator, 0, len(valSet.Validators)) | |||
| delegations := make([]stakingtypes.Delegation, 0, len(valSet.Validators)) | |||
|
|
|||
| bondAmt := sdk.NewInt(1000000) | |||
| // sdk.DefaultPowerReduction is 1 unit of voting power, which by default needs 1000000 tokens | |||
| bondAmt := sdk.DefaultPowerReduction.MulRaw(1000) | |||
There was a problem hiding this comment.
So this is 1,000,000,000 tokens, enough to survive 1000 reductions, whereas the previous wiped out the validator in one go?
There was a problem hiding this comment.
Exactly. Cosmos SDK specifies DefaultPowerReduction = 1000000. In the previous implementation, each genesis validator is given 1000000 tokens and thus 1 unit of voting power. Any undelegation with more than >=1 tokens will make the voting power to be zero and thus wipes out this validator.
| genAddr := genAccs[0].GetAddress() | ||
|
|
||
| // unbond a random amount of tokens from the validator | ||
| numNewVals := rand.Int63n(7) + 1 // numNewVals \in [1, 7] since UBD queue contains at most DefaultMaxEntries=7 validators |
There was a problem hiding this comment.
Oh really? What happens after 7 entries? Can the unbonding validator abuse it somehow?
There was a problem hiding this comment.
I should have been more specific. MaxEntries means that for any pair of delegatorAddr and validatorAddr, there can be <=MaxEntries concurrent undelegations at any time slot. If this delegator submits more than MaxEntries delegation requests, then only MaxEntries of them will be processed and others will be rejected. This is processed in https://github.com/cosmos/cosmos-sdk/blob/v0.45.5/x/staking/keeper/delegation.go#L814-L816. Will update the comments to make it more clear.
| numNewVals := rand.Int63n(1000) + 1 | ||
| for i := int64(0); i < numNewVals; i++ { | ||
| helper.WrappedDelegate(genAddr, val, coinWithOnePower.Amount) |
There was a problem hiding this comment.
Not sure if it's really worth doing this 1000 times at the extreme end. You could randomise the amount and the validator to delegate to instead. I mean, what do you learn if you do the exact same thing 10 times vs 900 times?
There was a problem hiding this comment.
Yeah we can also randomise the amount to achieve the same goal. The only advantage of randomising the number of delegation requests is to also fuzz the delegation/undelegation/redelegation queues. This is also how I found the MaxEntries thing.
| // Note that in Babylon, redelegation happens unconditionally upon `EndEpoch`, rather than upon checkpointed. Meanwhile in Cosmos SDK, redelegation happens upon `EndBlock`. | ||
| // This is because slashable security only requires `unbonding` -> `unbonded` to depend on checkpoints, and redelegation does not unbond any stake from the system. |
There was a problem hiding this comment.
Does this mean that no tokens enter the unbonding queue during a BeginRedelegate, because they just get moved between validators? If so, why this this comment still say that the unbonding queue can take at most 7 items?
There was a problem hiding this comment.
Does this mean that no tokens enter the unbonding queue during a BeginRedelegate, because they just get moved between validators?
Exactly. Upon redelegations, there is no token leaving the system, unlike upon undelegations. Thus, redelegations do not affect PoS security, in both PoS and checkpointed PoS.
If so, why this this comment still say that the unbonding queue can take at most 7 items?
I guess the MaxEntries thing aims at some sort of rate limiting, specifying that a validator operator should not spam undelegation/redelegation requests.
I will add more documentations to make this clear.
Fixes BM-63
This PR provides fuzz tests on
MsgWrappedUndelegateandMsgWrappedBeginRedelegate, where we perform a random number of undelegations/redelegations, enter a new epoch, and assert the messages have taken effect. The implementation follows the testing infra and the test onMsgWrappedDelegateintroduced in #65.This PR will mark the end of testing the epoching module solely. Some other tests such as
MsgWrappedCreateValidatorrequire working with other modules such asx/checkpointing/. We will implement these tests in the integration test phasewhen
SimAppis ready.