accounts/abi/abigen: use golang uint256.Int for solidity uint256 params

[mirokuratczyk]

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.

// Solidity: function mint(address to, uint256 amount) returns()
func (_Token *TokenTransactor) Mint(opts *bind.TransactOpts, to common.Address, amount *big.Int) (*types.Transaction, error)

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 where amount=0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff due to

go-ethereum/common/math/big.go

Line 170 in 4ff5093

// U256 encodes x as a 256 bit two's complement number. This operation is destructive.

Another similar scenario is demonstrated in this test mirokuratczyk@170d120, which fails with

=== RUN   TestToken
    token_test.go:53: Expect token balance to equal transfer value: 115792089237316195423570985008687907853269984665640564039457584007913129639935 != -1
--- FAIL: TestToken (0.04s)

Generating a uint256.Int binding in Golang for uint256 Solidity parameters ensures proper type safety and makes this unexpected behavior impossible.

[jwasinger]

I would say overall, it makes sense to add this.

[mirokuratczyk]

Rebased and force-pushed to include a9444ea, which is required for the AppVeyor tests to pass.