5 - Solidity II.

How does the encoding look like?

The first four bytes of the input data for a function call (that is originated by a transaction or a message call) specify the function to be called (or the fallback function can be targetted and in such a case the selector won’t match). It is the first four bytes of the Keccak (SHA-3) hash of the signature of the function. The rest of the bytes are encoded arguments. The arguments are encoded according to the specification in: https://docs.soliditylang.org/en/v0.8.22/abi-spec.html#contract-abi-specification.

Example of the first four bytes of the Keccak (SHA-3) hash of the signature (without return types) of the function: keccak256(“foo(uint32,bool)”)[0:4].

Of course, the contracts have to be compiled in such a way that they will be able to decode the input data and process it correctly. This is, of course, done by the Solidity compiler.

Receive

The receive function is used for receiving Ether, without any data. A contract can have at most one receive function.

It is declared without the function keyword: receive() external payable { …​ }. This function cannot have arguments, cannot return anything and must have external visibility and payable state mutability.

It is invoked on plain Ether transfers, i.e. using transfer or send. Thus if a contract defines a receive function and someone sends Ether to it, the receive function will be invoked.

contract Receiver {
    receive () external payable {
        //this function is called when the contract receives ether
    }
}
contract Sender {
    function send(address payable _receiver) public payable {
        //the _receiver address represent the address of the deployed Receiver contract
        _receiver.transfer(msg.value);
    }
}

Fallback

The fallback function is a special kind of function that is executed on a call to a contract if none of the other functions match the given function identifier. That is if Alice sends a transaction to contract A targeting the function foo and contract A does not have a function foo, then the fallback function is executed.

It is declared using either fallback () external [payable] {..} or fallback (bytes calldata input) external [payable] returns (bytes memory output) {..}.

Function overriding

When a function is marked as virtual, it can be overridden by a function with the same name and parameters in a derived contract. The overriding function must use the override keyword.

pragma solidity 0.8.17;

contract A {
    function foo() public virtual returns(uint256) {
        return 1;
    }
}

contract B is A {
    function foo() public override returns(uint256) {
        return 2;
    }
}

Multiple inheritance

Solidity allows for multiple inheritances, ie. a contract inheriting from multiple different contracts (eg A is B, C). This can be problematic when multiple contracts override the same method (which method should be called?). In such a case, an order (linearization) for the method resolution has to be established. To produce the linearization, Solidity uses an algorithm inspired by the C3 linearization algorithm (https://en.wikipedia.org/wiki/C3_linearization). The C3 algorithm basically creates a graph of the inheritance hierarchy and uses a topological sort to produce the linearization.

Especially, the order in which the base classes are given in the is directive is important: You have to list the direct base contracts in the order from “most base-like” to “most derived”.

A simplifying way to explain this is that when a function is called that is defined multiple times in different contracts, the given bases are searched from right to left (ie from the most derived contract) in a depth-first manner, stopping at the first match.

pragma solidity 0.8.22;

contract A { }

contract B is A { }

contract C is A { }

contract D is B, C { }

Constructors

A constructor is an optional function declared with the constructor keyword which is executed upon contract creation, and where you can run contract initialisation code.

If no explicit constructor is provided, a default constructor is generated. The default constructor has no arguments and an empty body.

In the case of inheritance, one can pass arguments to the base contracts in the following way:

pragma solidity 0.8.22;

contract A {
    uint256 x;
    constructor(uint256 x_) { x = x_; }
}

contract B is A {
    constructor(uint256 y) A(y * y) {}
}

One area where inheritance linearization is especially important and perhaps not as clear is when there are multiple constructors in the inheritance hierarchy. The constructors will always be executed in the linearized order, regardless of the order in which their arguments are provided in the inheriting contract’s constructor.

Interfaces, Abstract contracts

Solidity also supports interfaces and abstract contracts. Interfaces specify the functions that a contract should implement, but do not provide an implementation of these functions. Abstract contracts are similar to interfaces, but they can also contain implemented functions (and declare variables). Both of those constructs are used extensively.

Abstract contracts are useful where common functionality is convenient, but the implementation of certain functions can only be done in child contracts. Abstract contracts enforce the implementation of those functions because they can’t be deployed. A good example of abstract contracts can be found in: https://github.com/LayerZero-Labs/solidity-examples/blob/3fae7e07c7687d2f526dcc38b28e952a159165a7/contracts/lzApp/NonblockingLzApp.sol#L40.

abstract contract A {
    function f() public virtual;

    function bar() public returns(bool){
        return false;
    }
 }

interface I {
    function f() external;
    function fooha() external;
}

contract Implementor is A, I {
    function f() public override {}
    function foo() public override {}
    function fooha() public override {}
}

Upgrading smart contracts

The following example discusses the use of assembly in so-called proxies. A proxy is a contract that delegates all calls to another contract. Delegating a call means that the proxy will execute the code of the delegated contract in the context of the proxy, ie. the proxy will provide the state and the other contract the logic. It can be seen that if the other contract would be swapped for some new one then the logic will be changed and thus the proxy will be upgraded.

The main advantage of using a proxy is that the proxy can be upgraded without changing the address and modifying the proxy state.

The following example shows how the proxy delegates calls to the logic contract.

fallback() external payable {
        address logic = getAddress(LOGIC_CONTRACT_ADDRESS);

        // solhint-disable-next-line no-inline-assembly
        assembly {
            calldatacopy(0, 0, calldatasize())

            let result := delegatecall(gas(), logic, 0, calldatasize(), 0, 0)

            returndatacopy(0, 0, returndatasize())

            switch result
            case 0 {
                revert(0, returndatasize())
            }
            default {
                return(0, returndatasize())
            }
        }
    }

Library vs contract

Libraries have multiple differences compared to contracts: