WIP: Altered RNG / vesting debugging

[cwgoes]

cc @rigelrozanski

Reproduce with:

go test ./cmd/gaia/app -run TestFullGaiaSimulation -SimulationEnabled=true -SimulationNumBlocks=400 -SimulationVerbose=true -SimulationCommit=true -SimulationSeed=20 -v -timeout 24h

• 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 explorer

---

For Admin Use:

• Added appropriate labels to PR (ex. wip, ready-for-review, docs)
• Reviewers Assigned
• Squashed all commits, uses message "Merge pull request #XYZ: [title]" (coding standards)

[codecov]

Codecov Report

Merging #3712 into develop will decrease coverage by 0.01%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop    #3712      +/-   ##
===========================================
- Coverage    61.18%   61.17%   -0.02%     
===========================================
  Files          190      190              
  Lines        14008    14008              
===========================================
- Hits          8571     8569       -2     
- Misses        4901     4903       +2     
  Partials       536      536

[cwgoes]

... if you undelegate fractional shares, tokens are truncated, so the exchange rate can exceed 1.

(x/stake/types/validator.go:385)

[cwgoes]

Why do we allow fractional share withdrawals? Not obvious. edit: see #3712 (comment)

Would preventing them fix this? Could there still be a case when a validator is slashed and withdrawal-truncations result in a > 1 exchange rate?

[cwgoes]

For the exchange rate to be >1:

R = T / S ~ rate = tokens / shares

1 < (T - floor(s*T/S)) / (S - s) ~ inequality (rate greater than one) after undelegation

S - s < T - floor(s * T / S)

S - T < s - floor(s * T / S)

[rigelrozanski]

@cwgoes we need fractional share withdrawals if you're to be allowed to fully withdraw your shares from a validator. Let's say I delegate 100 atoms to a validator with a non-integer exchange rate and I receive 123.457 shares in return. If I am only able to withdraw 123 shares then I can only ever get back 99 atoms

[cwgoes]

@cwgoes we need fractional share withdrawals if you're to be allowed to fully withdraw your shares from a validator. Let's say I delegate 100 atoms to a validator with a non-integer exchange rate and I receive 123.457 shares in return. If I am only able to withdraw 123 shares then I can only ever get back 99 atoms

I see, that makes sense.

[cwgoes]

Let's donate to the community pool (credit to @alexanderbez / @rigelrozanski).

[jaekwon]

Make this call RandomAmount so that we can tweak that one function...
in the future we could make RandomAmount's probability to include bias for 0 and small numbers as well.

[jaekwon]

i.e. keeps the code dry in a good way.

[alexanderbez]

Do we actually want to keep said changes as it's biased?

[jaekwon]

result should be exclusive of max, so this is incorrect... will add pseudocode 1 min...

[smoelius]

I think that everywhere RandomAmount and RandomDecAmount are used, it makes sense to include the upper bound. (Though, I agree that leaving out the upper bound is more common and intuitive.)

[jaekwon]

it shouldn't include max, it should be exclusive.

[jaekwon]

var randInt = big.NewInt(0)
switch r.Intn(3) {
case 0:
	// randInt = big.NewInt(0)
case 1:
	randInt = max.BigInt() - 1 // max - 1 
case 2:
	randInt = big.NewInt(0).Rand(r, max) // up to max - 1
}
return randInt

[jaekwon]

This makes the various cases laid out better, is easier to extend and tweak.

[jaekwon]

everything incorporated here: #3717

[cwgoes]

Closing in favor of #3717.