adlerjohn
commented
3 years ago I'm inclined towards (B). That way the logic of exponents (to borrow terminology from floating point numbers) can be kept entirely on the contract side and doesn't affect the FuelVM at all. The FuelVM would just see some color that's nonfungible with other colors.
I would expect most major tokens to use some standard way of bridging. We can provide tooling for this, that automatically suggests the exponent based on the supply and number of decimals. And once a token is registered, the tooling can automatically suggest just re-using that instead of registering a new color.
SilentCicero
Problem
Many Ethereum ERC20 tokens use anywhere from 6 to 18 decimal places of precision. Fuel only allows for 64 bit words which is not enough to accommodate potentially 256 bits of precision for general math operations (without the use of a big number library). This means we need a common scheme to round token values in a meaningful way into something that can be operated on in the 64 bit space.
Many different tokens have different decimal values which are not necessarily enforced or properly encoded into the contracts. So using the
decimalspecifier in token contracts can be problematic.Goal
Ideally, we would like to make a deposit into Fuel with an 18 decimal token, then use either a multiplier of some kind to carry the necessary base of the token across its use in Fuel.
This way, we can operate on the 8 bytes of the number, and carry the multiplier for when it needs to be used in either depositing or withdrawals back into the original decimal value.
Proposed Solution A:
For every amount or value in Fuel is accompanied by a single byte multiplier value. The single byte would be a value between 0 and 256 which would specify a base. So if the multiplier was 1, it would mean a multiplier value of 10, 2 would mean a multiplier value of 100 and so on. This way all inputs and outputs carry the multiplier with them. This will happen from depositing, through transferring, through withdrawals.
Proposed Solution B:
We change the token ID scheme to include a multiplier. The multiplier is then only presented at deposit or withdrawal when tokens need to go back to their original Ethereum setting.
This means a single token on Ethereum could have many id's on Fuel, each specifying different multipliers.
A problem with this approach is that it could fractionalize tokens on Fuel, which might be problematic.
Todo
Note, there are likely other options here for rounding. These are just ideas at this stage. Open to feedback.