Add back support for fractional tokens

[garious]

We had fractional tokens in earlier versions, but pulled the feature because we couldn't settle on an encoding. It's also not clear what that should look like in the context of atomics. Time to revisit.

[bgorlick]

Can you elaborate a little more on your thinking here, with regards to "in the context of atomics" and use cases where you are concerned non-fractional will be insufficient? One potential issue is if the value of a token and resource costs in the physical world becomes grossly asymmetrical, and therefore inaccessible. Could stifle adoption, and utility.

[garious]

A first go at requirements:

• It must be able to represent the maximum number of tokens.
• It should be wide enough to represent twice the maximum, such that the internal representation can be negative, which is useful in storing deltas before a block is finalized.
• We should maximize the precision with whatever bits are left.
• There must be support for atomic addition and subtraction on the GPU.
• There should be support for atomic addition and subtraction on the CPU.
• The math should be precise, unlike say some floating point math.

That help?

[garious]

Leaning heavily toward saying, "tokens <=> satoshis". So fixed-point numbers for user-facing API. We just need to choose where to put the decimal point. Very tempting to give the integer part 32 bits, but technically that's 1, arguably 2, wasted bits.

[garious]

Sticking with the satoshis equivalent. Fractional tokens can be a client-side abstraction.

[garious]

Change SDK's API to operate on sols, not satoshis. Encode as a fixed point number, with the top 30 bits for the integer part. The sum of all tokens should then be 1,073,741,823.9999999999417923. And I believe the smallest amount would be 0.5^34? 5.820766091346741e-11, which means essentially no room for inflation and transaction fees can get at least a million times smaller than the proposed fee.

[garious]

Depends on #1526 (not strictly, but server would fail if you made use of that top bit)

[garious]

This ticket is confusing, closing. What's encoded in transactions is lamports and the ratio of lamports to sols is documented in the book. The only other work here is covered in #2267