Proposals to make simulator better navigate the state space

[ValarDragon]

• MsgCreateValidator
  • Make different modes for what initial commission rate to put
• MsgEditValidator
  • Have a mode where it schedules future-ops to keep on changing the commission rate in a given direction
• MsgDelegate
  • Have it look at a delegator's existing delegations, decide to increment pre-existing or a new one with 50% probability. (A delegator's delegations may be worth considering caching inside a "extra data" field within simulation.Account)
  • Have different modes for how much to delegate.
• MsgBeginUnbonding
  • Make different modes for how many shares to withdraw. (10%, 50%, 100% for example)
• MsgBeginRedelegate
  • Make different modes for how many shares to withdraw. (10%, 50%, 100% for example)
  • Make it aware of existing delegations to choose who to redelegate from / to, put extra emphasis on someone your already delegated to.
• MsgBankSend
  • Make different modes for what percentage of stake to transfer

Currently we run into a situation where a lot of the accounts have most of their money drained, since most actions are purely random and deplete them by 50%. This is a bad situation, so I think lowering most things that subtract money to like subtract say 10% is important.

[rigelrozanski]

Yeah this is cool it's like a "simulation profile" we should document these profiles too

[cwgoes]

Also we should make the likelihood ratios of particular messages also initially randomized (presently they're constant).

[jackzampolin]

Ok taking a look at this and I have a couple of questions:

• MsgDelegate, MsgBeginRedelegate
  • Does making these messages delegation aware require a global unbonding/redelegation index? If not we could cache them on simulation.Account (as @ValarDragon suggests) in a []Delegation. What should that object look like?
• MsgDelegate, MsgBeginUnbonding and MsgBeginRedelegate
  • We already randomize the amount of delegation as described in the issue, but it's not an input, just a random delegation. Do we require an input, or is random OK?
• MsgBankSend:
  • Currently finds the amount of coins in the sending wallet and picks a random amount of them. Is this good, or do we need to provide an input?
• How to deal with the request for different modes? The SimulateMsg* functions all return functions that look like:

func(r *rand.Rand, app *baseapp.BaseApp, ctx sdk.Context,
		accs []simulation.Account, event func(string)) (
		action string, fOp []simulation.FutureOperation, err error) {}

[cwgoes]

@jackzampolin In order:

1. We won't have an index and are instead using arrays - R4R: allow multiple simultaneous redelegations/ubds between same delegator/validator(s) addresses #3243 - but I don't understand why that would be required; just fetch the current delegations from the store and decide whether or not to modify an existing one.
2. We should avoid using the account's whole balance and instead use some random fraction of it.
3. I think this is OK at the moment, but we could occasionally try to send too many or choose a different distribution.
4. I think by modes @ValarDragon just means alternative cases with specific probabilities within the message simulation functions themselves.

[npinto]

Is this proposal still relevant? If so, could we put it out of the backlog as it feels that this could help better guide our ai-driven search for vulnerabilities via the sim. Thanks ;-)

[alexanderbez]

Yes I think so @npinto

[jackzampolin]

I think @fedekunze took care of a number of these with his latest refactor. Going to go ahead and close this addressed.