Why are there two methods encoding arguments? "abi.encode" and "abi.encodePacked"

Question

When we call a function on an external contract, the EVM computes a bytes buffer which contains the function signature and arguments.

There are two ways to serialize arguments:

1. abi.encode()
2. abi.encodePacked()

The differences between the two functions are well documented and I have understood them.

What I want to understand is why there are two functions in the first place. It is not clear when we should use the first and when - the second.

How can I see which function is used internally when I execute the following calls?

Call 1:

(success, ) = address(c).call(abi.encodeWithSignature("myfunction(uint256,uint256)", 400,500));

Call 2:

(success, ) = address(c).call(abi.encodeWithSelector(bytes4(keccak256("myfunction(uint256,uint256)")), 400,500)  )

Call 3:

(success, ) = address(c).call(  bytes4(keccak256("myfunction(uint256,uint256)")),    400, 500);

Call 4:

contract_instance.myfunction(400,500);

Thanks a lot!

Answer 1

I'd recommend to use 4 at all times if possible. It is easy to remember and write. The behavior is that it will revert the whole transaction if the call fails, which is the most reasonable alternative in general.

• abi.encode encodes its parameters using the ABI specs. The ABI was designed to make calls to contracts. Parameters are padded to 32 bytes. If you are making calls to a contract you likely have to use abi.encode

• abi.encodePacked encodes its parameters using the minimal space required by the type. Encoding an uint8 it will use 1 byte. It is used when you want to save some space - not call a contract.

• abi.encodeWithSignature - same as encode but with the function signature as the first parameter. Use when the signature is known and you don't want to calculate the selector.

• abi.encodeWithSelector - same as encode but selector is the first parameter. It almost equal to encodeWithSignature - use whatever fits best.

Do not use case 3, as it has been deprecated. A call with abi.encode should do the same job.

Answer 2

Cas 4 is more expensive and safer than other cases:

Due to the fact that the EVM considers a call to a non-existing contract to always succeed, Solidity includes an extra check using the "extcodesize" opcode when performing external calls. This ensures that the contract that is about to be called either actually exists (it contains code) or an exception is raised.

The low-level calls which operate on addresses rather than contract instances (i.e. .call(), .delegatecall(), .staticcall(), .send() and .transfer()) do not include this check, which makes them cheaper in terms of gas but also less safe.

Answer 3

I just want to add on other individual answers by sharing practical code that allows you to exactly see the differences using the concept of concatenation. The outcome of each function that uses both of the methods gives different results.

// SPDX-License-Identifier: GPL-3.0

pragma solidity >=0.7.0 <0.9.0;

contract concatenation {
    string public a;
    string public b;
    function ExampleFunction () external {
        a = string(abi.encode("hello", " world"));
        b = string(abi.encodePacked("hello", " world"));
    }

    // a "Failed to decode output"
    // b string: hello world

   function ExampleFunction2 () external {
        bool y=true;
        a = string(abi.encode(y, " world"));
        b = string(abi.encodePacked(y, " world"));
    }

    // a string: []@[] word
    // b string: [] world

    function ExampleFunction3 () external {
        bool y=true;
        uint256 nonce=123;
        a = string(abi.encode(y, nonce));
        b = string(abi.encodePacked(y, nonce));
    }

    // a string: []{
    // b string: []{
}

This helps me see the differences more clearly and thought of sharing it here.

The main idea is padding. abi.encode uses padding while abi.encodePacked does not. Therefore, this could be seen from above as the first function "ExampleFunction" was unable to stringify an abi encoded string. As you may see here.

Unless there is a compelling reason, abi.encode should be preferred.

Answer 4

abi.encodeWithSignature(string memory signature, ...) returns (bytes memory) is equivalent to abi.encodeWithSelector(bytes4(keccak256(bytes(signature)), ...)