Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What should we do about representing large numbers in JSON? #72

Open
gnidan opened this issue Jan 11, 2024 · 1 comment
Open

What should we do about representing large numbers in JSON? #72

gnidan opened this issue Jan 11, 2024 · 1 comment
Labels
question Further information is requested

Comments

@gnidan
Copy link
Member

gnidan commented Jan 11, 2024

This format needs to be able to represent 32-byte storage slot addresses and such. Do we require these be expressed as 0x-prefixed hexadecimal strings? Or do we require these be expressed as native JSON numbers?

JSON doesn't have the same restrictions as JavaScript when it comes to numbers... there's no limit on precision (for non-integer numbers), and there are no bounds at all. You can have a million digit number with another million digits after the decimal point and encode this just as a regular number in JSON, and that's fine... JSON says no loss of precision or overflow.

Problem is: we can't exactly expect JSON parsers to be cool with this kind of thing right out of the box. JSON is so closely associated with JavaScript that we should be mindful of JS's JSON.parse() behavior, which does not convert encoded integer values into bigints (and which has absolutely no native high-precision data type for decoded non-integers).

We also might want to be wary of the conventions used for expressing numbers in decimal vs. in hex... if this format expects (but does not require) that addresses, etc. be written in hexadecimal, but then parsers just consume everything as a number, then a naively written debugger might accidentally display everything in base 10 (when really, some things, like length fields, should be base-10, but offset fields should be base-16, etc.)

These are significant downsides, but the upside of using a number type for representing numbers is that... sometimes you have to do math with numbers. And if you're trying to do math with numbers that are actually strings, well, that's an extra step.

Right now I'm leaning towards the idea that strings are the only right answer, but it's tempting to put our foot down and insist that implementers leave their quotation marks at home.

@gnidan gnidan added the question Further information is requested label Jan 11, 2024
@raxhvl
Copy link
Contributor

raxhvl commented Jan 16, 2024

This package has about 6M weekly downloads, I would assume that most JS clients rely on it since parsing JSON to BigInt is non trivial.

Like you said, other option could be to pass numbers as string and use reviver during JSON.parse() to convert them to BigInt. But that will be an additional step for ALL clients.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants