Possible msg.data or transaction data regression from v2.3.1 to v2.3.2+

It appears there may be a regression related to msg.data (opcode: CALLDATASIZE) or transaction data-related JSON-RPC behaviour in contracts between v2.3.1 and v2.3.2 of ganache-core.

In particular, the following tests failed when upgrading from ganache-cli@6.2.3 to ganache-cli@6.2.4-beta.0 and higher, where the only related thing that changed was the upgrade to ganache-core from 2.3.1 to 2.3.2-beta.4. The following tests are failing on non-beta versions of ganache-cli@6.2.4 and ganache-cli@6.2.5 (see passing CI when pinned to 6.2.3 and failing CI when upgraded to 6.2.5).

Test

Test code

What this test checks for:

We have a DepositableDelegateProxy that allows a sender to send ETH to a delegate proxy if less than 10k gas and no data is sent with the transaction (FWD_GAS_LIMIT is defined in a base contract, DelegateProxy).

This test tries to assert the data condition: a ETH transfer should fail if data is sent as part of the transaction, even if less than 10k gas is used. On ganache-cli@6.2.3, this test passes by causing a revert to occur. However, on ganache-cli@6.2.4 and higher, the test fails because the transaction completes.

Upon looking into the behaviour (logging both the gasleft() and msg.data values), it appears that msg.data is the culprint; on ganache-cli@6.2.3, this test sends a msg.data of length 1 whereas on ganache-cli@6.2.4, it thinks msg.data is of length 0.

Expected Behavior

msg.data should have the correct data filled in.

Current Behavior

msg.data seems to not have the correct data in recent versions of ganache-core.

Possible Solution

Not sure if it’s the CALLDATASIZE opcode or a JSON-RPC endpoint. Maybe this was caused due to an undocumented API change (we’re using truffle@4.1.14 so it could be related to how truffle-contract expects to send the data although all other transactions except for those sent with contract.sendTransaction() seem to work fine).

Steps to Reproduce (for bugs)

See above

Context

Would like our tests to pass with newer ganache versions 😃

Your Environment

• Version used: ^6.2.4
• Operating System and version: macOS 10.14
• Link to your project: https://github.com/aragon/aragonOS

[sohkai]

Sounds like we should also update the test to use 0x01 (I just assumed the left padding wouldn’t be required, but I can see it also being strict), although node’s behaviour is hilariously awful.

[davidmurdoch]

@sohkai The actual bug @eshaben fixed here goes against the JSON-RPC spec in order to match with the behavior shown in geth. Passing 0x1 in a transaction’s data field is actually invalid; the value should be 0x01 (since it should be an UNFORMATTED DATA type). In order to align with geth we now 0 pad these data fields when necessary.

What was happening in ganache-core is that we were creating a native Buffer from the given hex value, "1". Buffer then checks the length of this value and determines it to be 0, creates a 0-length Buffer instance, then writes the "1" to it, which obviously doesn’t work. There is a node issue and comment about Buffer.from’s ambiguity here: https://github.com/nodejs/node/issues/8569#issuecomment-316336196, which you may find interesting.