FT Contract `baby.tkn.near` overflows DB max amount value

[telezhnaya]

ft_balance_of contract baby.tkn.near, block 6t8yYevd1HSXbkuCsfdu1KunTnWp8ctJZKsqoWMLgfud, account_id babyshiba.near
340171165809803503152000000000000000000
u128::max
340282366920938463463374607431768211456

In Rust applications, we use u128 for balance values. In the DB, we use numeric(38, 0) (it's i128 in Rust terminology), because of the limitations of Redshift and AlloyDB. They do not support numeric types bigger than numeric(38, 0).

340171165809803503152000000000000000000 does not fit into that.

It actually raises several questions:

• does anybody checked how the contract acts with the numeric overflows? The view call returns string, but it's written in Rust and it uses u128 inside.
• We accidentally opened Narnia by releasing JS contracts support. "Good" JS implementations will use libraries with big numbers, they will give us numbers larger than u128 as well.
• What should we do with such cases on the DB side?

I see several options on the DB side:

• Change the type of all balances to numeric(39, 0). It makes no sense to make it bigger because numeric(39, 0) fully covers u128. The disadvantage of this solution is that we will not be able to use some of the databases.
• Mark baby.tkn.near and all the contracts with the same issue as inconsistent for now. I'll go with this option for now, but it's not honest. They did not reach the overflow on Rust side.

---

FYI: it makes sense to compare these numbers with NEAR total supply. It's 1104019057751524304514351326173247 which fits into numeric(34, 0), so the difference is 10^5.

[telezhnaya]

Temporary fix https://github.com/near/near-indexer-events/commit/9b4bb8dcfe2aad112ba55a7079e7911cf903b549 We need to make the better decision here

[frol]

Well, NEP-141 defines the constraints:

All amounts, balances and allowance are limited by U128 (max value 2**128 - 1).

Thus, we can ban the contracts that overflow that (so we at least are not in that bad state). However, it is not fair to ban those that overflow I128 (I believe we could have limited the amounts to I128 range, but we did not 😢).

I feel numeric(39, 0) is the right way to go, and when we face the problem with the specific database, we will address it there (unless we already use one that fails to deal with numeric(39, 0))

[telezhnaya]

I'm just testing the solution on the random periods of blocks trying to validate the code. I haven't seen the previous history for this contract and account.

@frol my guess here: there was an overflow inside the contract, some blocks before (I don't have proofs for that, just a guess). I banned the contract for now (I agree, it's not honest) I'll investigate this case deeper when I run the solution from genesis.

I feel numeric(39, 0) gives us the constraint on the DB that we want to avoid :(

[telezhnaya]

I finally changed the type to numeric(40, 0) (could be numeric(39, 0)) because otherwise, we have to ban wrap.near :(