-
Notifications
You must be signed in to change notification settings - Fork 21k
accounts/abi/abigen: use golang uint256.Int for solidity uint256 params #31607
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
Conversation
I would say overall, it makes sense to add this. |
Fixes type safety of abigen bindings for uint256 solidity parameters.
Rebased and force-pushed to include a9444ea, which is required for the AppVeyor tests to pass. |
…31790) This is an alternative approach to #31607 , that doesn't break backwards-compatibility with abigen. Note that this does change the behavior of `Argument.Pack`: previously, packing negative values for a `uint` parameter would cause them to be represented in signed binary representation via two's complement. Now, it will fail explicitly in this case. However, I don't see a reason to support this functionality. The ABI already explicitly supports signed integers. There's no reason that a smart contract author would choose to store signed values in a `uint` afaict. --------- Co-authored-by: MariusVanDerWijden <[email protected]>
closing this in favor of #31790 |
Simpler, yes a bit. Mainly, the advantage of the alternative approach is that it's backwards-compatible, whereas making changes to function signatures in the bindings like this PR does is not. |
…thereum#31790) This is an alternative approach to ethereum#31607 , that doesn't break backwards-compatibility with abigen. Note that this does change the behavior of `Argument.Pack`: previously, packing negative values for a `uint` parameter would cause them to be represented in signed binary representation via two's complement. Now, it will fail explicitly in this case. However, I don't see a reason to support this functionality. The ABI already explicitly supports signed integers. There's no reason that a smart contract author would choose to store signed values in a `uint` afaict. --------- Co-authored-by: MariusVanDerWijden <[email protected]> Signed-off-by: jsvisa <[email protected]>
…31790) This is an alternative approach to ethereum/go-ethereum#31607 , that doesn't break backwards-compatibility with abigen. Note that this does change the behavior of `Argument.Pack`: previously, packing negative values for a `uint` parameter would cause them to be represented in signed binary representation via two's complement. Now, it will fail explicitly in this case. However, I don't see a reason to support this functionality. The ABI already explicitly supports signed integers. There's no reason that a smart contract author would choose to store signed values in a `uint` afaict. --------- Co-authored-by: MariusVanDerWijden <[email protected]> Cherry-picked from ethereum/go-ethereum#31790 (commit ethereum/go-ethereum@fe95bfdc8). Applied to Kaia codebase to improve ABI type safety and Solidity compatibility.
Currently, abigen generates a big.Int binding in Golang for uint256 Solidity parameters.
The danger is that negative big.Int values are serialized into very large uint256 values due to two’s complement. For example,
big.NewInt(-1)
is serialized to the maximum uint256 value.Consider this binding where the type of amount in Solidity is uint256, but the generated binding uses big.Int.
The risk is that, due to programmer error, an accidental call like
erc20Token.Mint(..., big.NewInt(-1))
is made. Unexpectedly, the call will not return an error, but instead serializes a transaction whereamount=0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
due togo-ethereum/common/math/big.go
Line 170 in 4ff5093
Another similar scenario is demonstrated in this test mirokuratczyk@170d120, which fails with
Generating a uint256.Int binding in Golang for uint256 Solidity parameters ensures proper type safety and makes this unexpected behavior impossible.