Int53 does not match golang int64 type size

[zakircode]

Hi!

In the Tendermint34 package, there is an overflow of Int53 type when decoding the data returned on the blockchain, such as block height and voting power, the int64 type used by tendermint, the range is: -2^63-1 to 2^63 but Int53 only has - (2^53 - 1) to 2^53 - 1.

cosmjs tendermint34 reponses types

tendermint rpc responses types

Integer parse error

[webmaster128]

Right. This is intentional in order to be able to use JavaScript numbers. For which use case do you run into this problem? Do you have a height > 2^53?

[zakircode]

Because I'm doing a test, my validator voting power is overflowing.

[webmaster128]

Arg, we fixed this before when we hit the limit of the 32 bit range (confio/ts-relayer#204). Now you exceed the 53 bit range? How is that possible? Using some crazy Ethereum tokens for staking?

[zakir-code]

This is because the precision of the staking token I use is 18. If the number of delegations is 10^20 and the power reduce is 100, then the voting power is 10^18 which is greater than 2^53-1

[zakir-code]

In more extreme cases, set DefaultPowerReduction to 100

[webmaster128]

For the Tendermint 0.35 client we can use BigInt for the voting powers. Then we are safe. It would be the first usage of bigint in CosmJS API. Hope it would not cause trouble for devs.

[webmaster128]

Do you know the expected value range in the proposer_priority field, especially in your scenario? This seems to be Int64 in Go (signed), which means we cannot use the Uint64 type client side. Curious if this can remain number as now.

[webmaster128]

Given that Cosmos SDK 0.46 will use Tendermint 0.34 (#1093 (comment)), I think we'll make the change for both Tendermint 0.34 and 0.35 client from CosmJS 0.29 on.

[zakir-code]

Do you know the expected value range in the proposer_priority field, especially in your scenario? This seems to be Int64 in Go (signed), which means we cannot use the Uint64 type client side. Curious if this can remain number as now.

The proposer_priority field exists with a negative number. In fact, the case of exceeding int64 is very special and generally does not appear, so now you can continue to use number

[webmaster128]

Thanks.

#1187 is ready for review now.