Solidity – How to Calculate Output of abi.encode in Remix

remixsolidity

I'm still learning solidity but having some hard times while trying to understand how abi.encode works. I mean when i try to see it's output i see a long hex value. For example if i call this function :

function getHexTest() public pure returns(bytes memory){
        return abi.encode("1","2");
    }

I see this output on remix:

0x000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000001310000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000013200000000000000000000000000000000000000000000000000000000000000

So i couldn't understand how this works and how this value calculated exactly. Because it's not equal to these values hex ascii or any other thing. So question is how this is structured? I see different examples in documentation like encoding functions and arguments but to be able o fully understand i need to understand this first.

Best Answer

Incoming (parameters) or outcoming data package for a contract is formed according to the following principle:

Data types, which are limited on the length (address, uint32, bytes32), are transmitted with alignment to 32-byte word (64-hex numbers)
Data types, which are varying on the length (strings or arrays), are transmitted according to the following scheme:
- In the object position in the list, we transmit the offset of the block and its data relatively to the beginning of the package (with alignment to 32-byte word)
- A number of data items is transmitted in the first 32-byte word of the block
- The data themselves are transmitted in the consequent 32-byte words

Let’s consider, for example, a block, where the following data are sent: address, string, uint32, address[] (a hexadecimal address relative to the beginning of the block is given in the beginning of every 32-byte sting for the convenience)

000:000000000000000000000000570f5d143ee469d12dc29bf8b3345fa5536476d9
020:0000000000000000000000000000000000000000000000000000000000000080
040:0000000000000000000000000000000000000000000000000000000000001234
060:00000000000000000000000000000000000000000000000000000000000000c0
080:0000000000000000000000000000000000000000000000000000000000000003
0a0:4e65770000000000000000000000000000000000000000000000000000000000 
0c0:0000000000000000000000000000000000000000000000000000000000000002 
0e0:000000000000000000000000aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 
100:000000000000000000000000bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

In the 000 string, we send the following address: 0х570f5d143ee469d12dc29bf8b3345fa5536476d9.
In the 020 string, we send a link to the block, which describes a variable of a string type – 0x80 bytes from the beginning of block.
In the 040 string, we send an integer 0x1234.
In the 060 string, we send a link to a block, which describes an array address[] – 0xc0 bytes from the beginning of the block.
In the 080 string, we send a symbols counter via a variable of the type string – 3.
In the 0a0 string, we send symbols of the variable of the type string – a word New.
In the 0c0 sting, we send a counter of the array address[] items – 2.
In the 0e0 string, we send the first element of the address[] array - 0хaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.
In the 100 string, we send the second element of the address[] array - 0хbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.

In you keys we recieve 2 string variable:

0x000: 0000000000000000000000000000000000000000000000000000000000000040 (offset of 1st string)
0x020: 0000000000000000000000000000000000000000000000000000000000000080 (offset of 2nd string)
0x040: 0000000000000000000000000000000000000000000000000000000000000001 (size of 1st string)
0x060: 3100000000000000000000000000000000000000000000000000000000000000 (data of 1st string)
0x080: 0000000000000000000000000000000000000000000000000000000000000001 (size of 2nd string)
0x0a0: 3200000000000000000000000000000000000000000000000000000000000000 (data of 2nd string)

Related Solutions

Solidity Delegatecall – How Delegatecall Works from Solidity 0.5.0 Onwards

The delegatecall arguments are incorrect, you should use:

function delegatedCalculation(uint firstNumber, uint secondNumber) public {
        bool status;
        bytes memory result;
        (status, result) = linkedContract.delegatecall(abi.encodePacked(bytes4(keccak256("calculate(uint256,uint256)")), firstNumber, secondNumber));
    }

Or simply you can write the following if there is no return value, as this is the case for your calculate, method:

function delegatedCalculation(uint firstNumber, uint secondNumber) public {
        (bool status,) = c2.delegatecall(abi.encodePacked(bytes4(keccak256("calculate(uint256,uint256)")), firstNumber, secondNumber));
}

Note that:

To calculate the selector you should use uint256 not uint.
Use abi.encodePacked to pack all the parameters into a bytes type.
delegatecall will return a bool indicating success or failure and a bytes with the returned value (if any)

Test it in remix and it works. Hope this helps you.

EDIT: The clarification made in the docs is in the breaking changes section, this is probably what you were looking for.

The functions .call(), .delegatecall(), staticcall(), keccak256(), sha256() and ripemd160() now accept only a single bytes argument. Moreover, the argument is not padded. This was changed to make more explicit and clear how the arguments are concatenated. Change every .call() (and family) to a .call("") and every .call(signature, a, b, c) to use .call(abi.encodeWithSignature(signature, a, b, c)) (the last one only works for value types). Change every keccak256(a, b, c) to keccak256(abi.encodePacked(a, b, c)). Even though it is not a breaking change, it is suggested that developers change x.call(bytes4(keccak256("f(uint256)"), a, b) to x.call(abi.encodeWithSignature("f(uint256)", a, b)).

Functions .call(), .delegatecall() and .staticcall() now return (bool, bytes memory) to provide access to the return data. Change bool success = otherContract.call("f") to (bool success, bytes memory data) = otherContract.call("f").

You can check sample for call and delegatecall with solidity 0.5 here: https://gist.github.com/Muhammad-Altabba/55ac6974ac9396d723fdfd792d51eb5d

Solidity and Gas Optimization – Cold Access VS Warm Access: Understanding Gas Cost Differences

Those articles didn't use a good example to explain the situation, that's why you are confused.

Cold/warm access refers always to storage, never to memory. You have cold access the first time you read a variable, warm access when you read it again.

The only difference between the methods Caching and NotCaching is that myArray.length is read 10 times in Caching from storage, while in NotCaching it's from memory (so even cheaper than warm storage). In both cases the elements of myArray are read each once (so cold access in both). The difference in gas should be then around 10*100 = 1000. The extra 500 is probably due to multiple keccak256 calculations of the state slots in the loop.

You can write better examples on remix, for example I made this:

contract ColdWarmGas {
    uint256 x = 1;  // storage variable
    uint256 y = 2;  // storage variable

    // 2381 gas
    function test1() external view returns (uint256 a) {
        a = x;      // cold read
        a = a + x;  // warm read
    }

    // 4473 gas
    function test2() external view returns (uint256 a) {
        a = x;      // cold read
        a = a + y;  // cold read
    }

    // 4632 gas
    function test3() external view returns (uint256 a) {
        a = x;      // cold read
        a = a + y;  // cold read
        a = a + y;  // warm read
    }
}

You can see that adding a warm read adds around 100 gas, while a cold one over 1000.

Best Answer

Related Solutions

Solidity Delegatecall – How Delegatecall Works from Solidity 0.5.0 Onwards

Solidity and Gas Optimization – Cold Access VS Warm Access: Understanding Gas Cost Differences

Related Topic