Conversation
Codecov Report
@@ Coverage Diff @@
## develop #2508 +/- ##
=======================================
Coverage 60% 60%
=======================================
Files 151 151
Lines 8844 8844
=======================================
Hits 5307 5307
Misses 3167 3167
Partials 370 370 |
|
Ref #2509 as a followup |
| func getValidatorPowerRank(validator types.Validator) []byte { | ||
|
|
||
| potentialPower := validator.Tokens | ||
| powerBytes := []byte(potentialPower.ToLeftPadded(maxDigitsForAccount)) // power big-endian (more powerful validators first) |
There was a problem hiding this comment.
can to delete ToLeftPadded now I believe
There was a problem hiding this comment.
Hmm it could be useful in general for other serialization purposes though.
| // todo: deal with cases above 2**64, ref https://github.com/cosmos/cosmos-sdk/issues/2439#issuecomment-427167556 | ||
| tendermintPower := potentialPower.RoundInt64() | ||
| tendermintPowerBytes := make([]byte, 8) | ||
| binary.BigEndian.PutUint64(tendermintPowerBytes[:], uint64(tendermintPower)) |
There was a problem hiding this comment.
I don't think this is the approach we want to take. Now we lose sorting past the tmpower. Instead we should make the entire Decimal/Int get marshalled in constant size for the store key, imo.
There was a problem hiding this comment.
Maybe... what's the benefit of sorting past TM power precision?
(I agree with changing how TM power is calculated as was discussed in the issue)
There was a problem hiding this comment.
per discussion in slack, I now agree. Lets only use tmpower everywhere.
3 participants
Ref #2439, although it doesn't address all of that issue (only fixing the current key, not changing the Tendermint power calculation).
docs/)PENDING.mdwith issue #Files changedin the github PR explorerFor Admin Use: