Support BigInt especially for EVM parameters and return values

[Muhammad-Altabba]

A suggestion to add support for BigInt which need to be serialized and de-serialized at taco-web and the nodes. This is especially that int number cannot hold large int numbers that evm supports and return as bigint.

Not handling bigints would cause currently an exception, if there was a bigint.

(The description above has been updated to point to int numbers instead of mentioning just numbers)

Reviewers:
@derekpierre @KPrasch

[derekpierre]

Seems like the JSON spec doesn't actually support numbers being that high -https://datatracker.ietf.org/doc/html/rfc8259#section-6. We'll need to figure out a strategy for using bigint for rpc/contract conditions. I don't think it is necessary for non-blockchain conditions eg. JSON API etc.

Feels like some bigint indication would be more explicit, than just having it be a string and not knowing if it is actually a string or a number. Perhaps using an n suffix eg. "987654321987654321987654321n". . You could do something like use a union for bigIntOrNumberSchema, and then serialize as regular number if < safe_integer, else serialize as string with 'n' appended...just thinking out loud.

Nodes (nucypher/nucypher) will also need to process those bigint strings in the resulting JSON.

Other thoughts (cc @KPrasch , @manumonti , @cygnusv ).

[derekpierre]

@Muhammad-Altabba this is a great find. It is a pretty significant bug that we need to address sooner rather than later. Please prioritize working on this over anything else you are working on. Let's come up with a resolution and move to have it fixed. Depending on what is decide, we can also update the nucypher code accordingly for nodes to properly handle the representation of bigints in the JSON.

It can be reproduced in the taco playground - https://playground.taco.build/.

If you try decrypting with that condition, the nodes return the following:

Decryption Failed: Threshold of responses not met

Invalid condition grammar: Invalid condition grammar: {\'return_value_test\': ["Return value comparison for \'eth_getBalance\' call output should be \'<class \'int\'>\' and not \'<class \'float\'>\'."]}

[Muhammad-Altabba]

@Muhammad-Altabba this is a great find. It is a pretty significant bug that we need to address sooner rather than later. Please prioritize working on this over anything else you are working on. Let's come up with a resolution and move to have it fixed. Depending on what is decide, we can also update the nucypher code accordingly for nodes to properly handle the representation of bigints in the JSON.

It can be reproduced in the taco playground - https://playground.taco.build/.

If you try decrypting with that condition, the nodes return the following:

Decryption Failed: Threshold of responses not met

Invalid condition grammar: Invalid condition grammar: {\'return_value_test\': ["Return value comparison for \'eth_getBalance\' call output should be \'<class \'int\'>\' and not \'<class \'float\'>\'."]}

Many thanks @derekpierre ,
And actually what you discovered is related to the opened issue but it is something else. The issue propose supporting the data type bigint. But you discovered an issue when the number is larger than the max safe int. Which is then handled as a float number and cause the execution to fail on the nodes. But adding the new feature (supporting bigint) and fixing the bug (with numbers larger than max safe int), are both solvable together by updating the json serialization process. And TACo nodes need to agree to the data serialization format. I am proposing serialization as hex string in the PR.

Here is an integration test that should pass once the new feature has been supported and the bug has been handled:
c080418

[derekpierre]

I saw that your proposal is a hex string, but I am concerned about how the node can differentiate between bytes and an int - see comment here - #637 (comment). Ideas?

[Muhammad-Altabba]

I saw that your proposal is a hex string, but I am concerned about how the node can differentiate between bytes and an int - see comment here - #637 (comment). Ideas?

You are faster than my replies 😄 sorry I was still writing some other message...

For this point, I think it is safe to convert to hex because it is for comparison. I mean I think it would not matter if the value was bytes or int as long as the comparison is what matter. Except if you see some edge case?