BigInt and Float support

[jimscarver]

Introduction/Motivation/Abstract

Data limitations create bugs. Without BigInt we are forever plagued by overflow and underflow errors. One may blow up the world. without these types we are unable to marshal objects of those types faithfully using inter blockchain protocol.

Motivating Examples

@dckc pointed out these issues and how agoric contracts convert easily to rholang and there is a lot there we can use ERTP, IBC, CapTP, etc. However when BigInts and Float are used we will introduce bugs as already happened with the POS contract and again recently. See video. https://youtu.be/IbW6uvgCSv4?t=5463

Design

BigInt requires virtually a global change in the rnode source of Int to BigInt.

Adding floating point operations and constants is faily mechanical and requires an update to the rholang spec.

Counter-Examples

Drawbacks

Alternatives

References

[dckc]

I suggest making floats a separate issue; those are much, much less important.

[Bill-Kunj]

I suggest making floats a separate issue; those are much, much less important.

I agree. Arbitrary precision floats are far less important.
Making BigInt universal is vital, as recent problems with PoS demonstrate.
The fact that custom tooling has been required to support the total RPC token supply should be ample evidence.

[Bill-Kunj]

As a general reply to the abstract of this rchip, data limitations create bugs is more properly expressed as data limitations ARE bugs.