Solidity – Why Use Assembly calldataload at Offset 0xC4 in Solidity?

solidity

ChainBridge has a piece of solidity code:

assembly {

            amount := calldataload(0xC4)   // **why get data from 0xC4？

            recipientAddress := mload(0x40)
            lenRecipientAddress := calldataload(0xE4)   // offset 0x20 beside amount is the length variable, I know that.
            mstore(0x40, add(0x20, add(recipientAddress, lenRecipientAddress)))  // load address to the free memory

            calldatacopy(
                recipientAddress, // copy to destinationRecipientAddress
                0xE4, // copy from calldata @ 0x104        **Why copy from 0xE4？
                sub(calldatasize(), 0xE) // copy size (calldatasize - 0x104)    
                //** Why the length is calldatasize()-0xE? Is the original comment by the author correct?
            )
        }

The function deposit has 5 arguments, I know that the assembly code wants to get amount from the data argument. But I can't figure out

why the offset is 0xC4, I try to calculate the offset from the first argument of the the function deposit. Is the offset of data argument: 4bytes(method sig)+32bytes(bytes32)+32bytes(uint8)+32bytes(uint64)+32bytes(address)? But the sum up is not 0xC4.
why does calldatacopy use an offset 0xE4 and 0xE
Is the original comment by the author correct?

The data argument consists of: amount, lenRecipientAddress and recipientAddress

The invocation path is : bridgeContract.depoist -> ERC20Handler.deposit, the input of data please refer the link, the data argument is passed transparently.

Another confuses me is that the ERC721Handler depoist function.
The input data is like this, the data consists of id,lenRecipientAddress and recipientAddress. The only difference is ERC721Handler use 32bytes id, the ERC20Handler use 32bytes amount, but their total length is the same. So from my perspective both of ERC20Handler and ERC721Handler should have the exact same code, but the last line code sub(calldatasize(), 0xE4) is different, the offset 0xE4 in ERC721Handler is different to the 0xE in the ERC20Handler.

The ERC721Handler's depoist:

calldatacopy(
                destinationRecipientAddress,    // copy to destinationRecipientAddress
                0xE4,                           // copy from calldata after destinationRecipientAddress length declaration @0xE4
                sub(calldatasize(), 0xE4)       // copy size (calldatasize - (0xE4 + 0x20))  
                //** Why use 0xE4? Is the original comment by the author correct?
            )

The invocation path is : bridgeContract.depoist -> ERC721Handler.deposit, the data argument is passed transparently.

Best Answer

1/ The calculation is missing the two slots required by data, first slot is the offset within the calldata, and the second slot is the length in bytes. That will be 4 + 32 x 4 + 32 x 2 = 196 = 0xc4.

2/ 0xe4 is the start of recipientAddress length. The 0xe seems to be a mistake, from the comment they wanted to write sub(calldatasize(), 0xe4). It shouldn't be a problem since data calldatacopy will return 0 for bytes outside calldatasize().

3/ ~~It appears to be correct~~. The numbers are wrong.

Related Solutions

Solidity Log Events – How to Split Calldata Bytes to Multiple Log Events?

Arbitrary Split approach

Edit: Added this section to address arbitrary split destinations

By the time you are splitting, you should know the length of the target data. Below is an example implementation of copying the bytes to their destination inside solidity, which should be trivially extendable to N buckets.

pragma solidity ^0.4.15;

contract HelpLogs {

  event LogFirstHalf(bytes _data);
  event LogSecondHalf(bytes _data);

  function logit(bytes data) external {
      uint midpoint = data.length / 2;
      bytes memory data1 = new bytes(midpoint);
      for (uint i = 0; i < midpoint; i++) {
          data1[i] = data[i];
      }
      bytes memory data2 = new bytes(data.length - midpoint);
      for (i = 0; i < data.length - midpoint; i++) {
          data2[i] = data[i + midpoint];
      }
      LogFirstHalf(data1);
      LogSecondHalf(data2);
  }
}

Note that the gas usage is higher than it needs to be, because it works byte-by-byte. It would be faster to use 32-byte words, with bitmasking. A good reference is memcpy from Arachnid's solidity-string utils library.

[Edit: old] Fixed Bucket Approach

You can split the data externally without the 21 kgas overhead. Send the pre-split data as two parameters to a single function call:

pragma solidity ^0.4.15;

contract HelpLogs {

  event LogFirstHalf(bytes _data);
  event LogSecondHalf(bytes _data);

  function logit(bytes dataPart1, bytes dataPart2) external {
    LogFirstHalf(dataPart1);
    LogSecondHalf(dataPart2);
  }
}

This will cost less gas than splitting inside the EVM.

Solidity – Understanding Dynamic Types in Calldata Encoding for Solidity and EVM

From Function Selector and Argument Encoding:

All in all, a call to the function f with parameters a_1, ..., a_n is encoded as
function_selector(f) enc((a_1, ..., a_n))

Therefore, the function arguments are encoded as a tuple. In our case, we have:

function actionTest(Actions.ActionArgs[] memory actions) external;

So the arguments of actionTest are encoded as a tuple of length 1, i.e.:

(Actions.ActionArgs[] memory actions,)

From the Formal Specification of the ABI Encoding:

We distinguish static and dynamic types. Static types are encoded in-place and dynamic types are encoded at a separately allocated location after the current block.

Definition: The following types are called “dynamic”:

bytes

string

T[] for any T

T[k] for any dynamic T and any k >= 0

(T1,...,Tk) if Ti is dynamic for some 1 <= i <= k

All other types are called “static”.

Since Actions.ActionArgs[] is dynamic (by rule 3), by rule 5 the tuple (Actions.ActionArgs[],) is also dynamic. Therefore actionTest’s argument-list of is encoded dynamically. Therefore at position 0x00 in the abi-encoded argument-list, we can find the position at which the first (and only) argument’s abi-encoded bytes will start.

Yes, it feels redundant, because for an argument-list of length 1, this value is always going to be 0x20. But in the general case, if there had been more arguments, the value would have differed.

Applying these rules, the bytes are decodable as follows:

0x6a919f90
args@0x000:                                                 0000000000000000000000000000000000000000000000000000000000000020 head(args[0]) = where tail(args[0]) starts within args
args@0x020: args[0]@0x000:                                  0000000000000000000000000000000000000000000000000000000000000001 actions.length
args@0x040: args[0]@0x020: actions@0x000:                   0000000000000000000000000000000000000000000000000000000000000020 head(actions[0]) = where tail(actions[0]) starts within actions
args@0x060: args[0]@0x040: actions@0x020: actions[0]@0x000: 0000000000000000000000000000000000000000000000000000000000000008 ActionType.Call
args@0x080: args[0]@0x060: actions@0x040: actions[0]@0x020: 0000000000000000000000000000000000000000000000000000000000000007 accountId = 7
args@0x0a0: args[0]@0x080: actions@0x060: actions[0]@0x040: 0000000000000000000000000000000000000000000000000000000000000001 amount.sign = true
args@0x0c0: args[0]@0x0a0: actions@0x080: actions[0]@0x060: 0000000000000000000000000000000000000000000000000000000000000000 amount.denomination = AssetDenomination.Wei = 0
args@0x0e0: args[0]@0x0c0: actions@0x0a0: actions[0]@0x080: 0000000000000000000000000000000000000000000000000000000000000000 amount.ref = AssetReference.Delta = 0
args@0x100: args[0]@0x0e0: actions@0x0c0: actions[0]@0x0a0: 00000000000000000000000000000000000000000000000000000000000003e8 amount.value = 0x3e8 = 1000
args@0x120: args[0]@0x100: actions@0x0e0: actions[0]@0x0c0: 0000000000000000000000000000000000000000000000000000000000000008 primaryMarketId = 8
args@0x140: args[0]@0x120: actions@0x100: actions[0]@0x0e0: 0000000000000000000000000000000000000000000000000000000000000009 secondaryMarketId = 9
args@0x160: args[0]@0x140: actions@0x120: actions[0]@0x100: 000000000000000000000000e0679aa631740f3dae1d3ce302f1f3d45f3ed61d otherAddress
args@0x180: args[0]@0x160: actions@0x140: actions[0]@0x120: 0000000000000000000000000000000000000000000000000000000000000005 otherAccountId = 5
args@0x1a0: args[0]@0x180: actions@0x160: actions[0]@0x140: 0000000000000000000000000000000000000000000000000000000000000160 where data starts within actions[0]
args@0x1c0: args[0]@0x1a0: actions@0x180: actions[0]@0x160: 0000000000000000000000000000000000000000000000000000000000000040 byte-length of data = 64 bytes
args@0x1e0: args[0]@0x1c0: actions@0x1a0: actions[0]@0x180: 00000000000000000000000031c8e1cb963d9cc02fcbc5d0cf881bbb1ffaf15f msg.sender
args@0x200: args[0]@0x1e0: actions@0x1c0: actions[0]@0x1a0: 00000000000000000000000000000000000000000000000000000000000003e8 1000

Best Answer

Related Solutions

Solidity Log Events – How to Split Calldata Bytes to Multiple Log Events?

Solidity – Understanding Dynamic Types in Calldata Encoding for Solidity and EVM

Related Topic