JSON RPC API using (u)int64 whereas JS can only handle int53

[linuskendall]

Problem

The JSON API uses int64 for fields like lamports. However, the maximum safe integer in browsers is 2^53-1

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER

Proposed Solution

Make lamports a string in the HTTP/RPC API and parse with BigInt on the web3.js client side?

[vpontis]

@linuskendall thanks for opening this!

Yea, we've switched to passing around lamports and token amounts as strings internally and then parsing with BN.js. But we still get number from most of the JSON RPC endpoints.

While it's much nicer to get a number, I fear this will lead to some bad bugs...

[mvines]

We've switch over to strings in a couple of the methods already, and marked the Number field as deprecated. Example: https://docs.solana.com/developing/clients/jsonrpc-api#token-balances-structure

It would be helpful to enumerate the remaining problematic methods to make this issue easier to pick up by somebody willing to clean them up too!

[vpontis]

@mvines The biggest offender right now is lamports which is consistently a number in the web3.js API.

[emdoyle]

@mvines This also occurs when using getBalance, and if I understand correctly it's because the value is coerced by superstruct into a number. Took me a long time to realize this was the reason balances were off by ~40 lamports in my tests client-side :/

This also happens with getAccountInfo (lamports as @vpontis mentioned) so I don't think there is a safe way to retrieve native SOL balances in web3.js at the moment unless I'm missing some other method.

[steveluscher]

The use of JS numbers is terrifying, and has been added as a principle in #1111 as we consider a rewrite of web3.js.

[steveluscher]

I removed the ‘good first issue’ tag. I think this is rather extremely complicated, and will require a months' (years'?) long deprecation strategy for the old fields, and possibly a version bump of the RPC itself.

Some of the groundwork is already being laid in the new web3 rewrite through the use of bigint at the outer edge of the interface. This should let people who program apps using the new RPC to seamlessly upgrade to the new RPC methods (when we cut them over) without changing their app's code or upgrading their other dependencies.

[steveluscher]

@lorisleiva has a devilishly clever solution for this, coming to @solana/web3.js 2.0 (see #3196).

[steveluscher]

I can't believe this is done.

[github-actions]

Because there has been no activity on this issue for 7 days since it was closed, it has been automatically locked. Please open a new issue if it requires a follow up.