Multiple denom units for token size (aka atoms and sub-atoms etc.)

[rigelrozanski]

As was indicated here #2319
Our API's are currently only taking in integers, which is the intended usage as the "unit" of all tokens submitted are supposed to be the indivisable smallest unit posssible (aka a "satoshi")

I remember several conversations from Berkley where we spec'd out possible solutions where the API's could send a different denom to represent a larger units of a token (whereby decimal input would be allowed)

Can't find any documentation on this so I'm opening this issue as a reminder (CC @sunnya97 )

[ValarDragon]

The discussion we were having in berkeley was in an effort to avoid having to switch to big ints, due to the significant performance hit that has. I think we decided to switch to just using big ints to avoid the megacoin idea. (As it seemed that we were creating less efficient big ints otherwise) Now we just have a fixed amount of precision. (256 bits)

I made benchmarks at one point, but I think I did something wrong when making them. (Maybe my benchmarks were dominated by CPU to memory reads? From what I recall of how I did them, that seems likely) I think it may be worth re-weighting the speed properly of int64 vs big int, and switching back to the MegaCoin idea with int64's or int128's, instead of big ints.

[ValarDragon]

Just made a quick set of much more sensible benchmarks than what I originally had done, and heres the results:

$ go test --bench=.
goos: linux
goarch: amd64
BenchmarkBigInt64BitAddition-8     	50000000	        30.5 ns/op
BenchmarkInt64Addition-8   	        1000000000	      1.07 ns/op
PASS

This is just an addition of two numbers, that are well under 32 bits. (So multiply the int64 addition time by a factor of 4 or 5 perhaps) Benchmark code: https://gist.github.com/ValarDragon/5b12b4b3cd9879843611663cd6224049

Since were only going to be doing addition on coins in like almost all scenarios, it may be worth reconsidering mega-coins pre 1.0.

[alexanderbez]

Can you provide a quick overview of the "megacoin" concept?

[ValarDragon]

Sure! The idea of mega-coins was suppose you want to have 256 bits for coins, but in almost all cases you only ever need 64 bits of precision. (We needed 256 bits for some ethermint stuff iirc) Then we'd separate these into 64 bit blocks. So we'd have atoms, "kilo atoms", "mega atoms". (Those weren't the suggested names, but the idea is similar to talking about wei vs ethereum)

So if the number of atoms your dealing with overflowed 64 bits, the bank keeper would move it into this kilo-atom. But the majority of computation would be the fast 64bit arithmetic. This would be completely hidden from you normally, UI's and etc would just convert the different mega-coins into a single coin and handle accordingly. IBC would also just be big ints, and these mega coins would only be a hub-specific (or our bank implementation specific) idea for getting fast arithmetic with these.

[alexanderbez]

Awesome -- thank you!

[jackzampolin]

I think we have addressed this. Closing