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:

Events

Events in the interface are used to notify the off-chain world about the changes in the contract. They must be emitted correctly, as they are part of the evaluation – follow the natspec documentation above each event.

Functions

Functions in the interface must be implemented acording to the defined use cases above. The documentation above each function is only a brief summary – unsuitable alone (without the usecases) for successful implementation.

Interface code

Copy the following code into your IVoteD21.sol file and carefully read the natspec documentation above each event and function.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.26;

/// @notice Interface for a D21 voting system
interface IVoteD21 {

    // ------------------------------ Structures ------------------------------

    /// @notice The subject of voting – can be for example a political party.
    struct Subject {
        string name;
        int256 votes;
    }

    // -------------------------------- Events --------------------------------

    /// @notice Emmited when the owner started the voting period.
    event VotingStarted();

    /// @notice Emmited when the owner added a new voter.
    /// @param voter  Address of the added voter
    event VoterAdded(address indexed voter);

    /// @notice Emmited when a new subject was added.
    /// @param subject  Address of the subject
    /// @param name     Name of the subject
    event SubjectAdded(address indexed subject, string name);

    /// @notice Emmited when a positive vote was given.
    /// @param voter    Address of the voter
    /// @param subject  Address of the subject
    event PositiveVoted(address indexed voter, address indexed subject);

    /// @notice Emmited when a negative vote was given.
    /// @param voter    Address of the voter
    /// @param subject  Address of the subject
    event NegativeVoted(address indexed voter, address indexed subject);

    // ---------------------- Public & external functions ---------------------

    /// @notice Add a new subject into the voting system using the name.
    /// @param name  Name of the subject
    function addSubject(string memory name) external;

    /// @notice Get the subject details.
    /// @param subject  Address of the subject
    /// @return         Subject details
    function getSubject(address subject) external view returns(Subject memory);

    /// @notice Get addresses of all registered subjects.
    /// @return  Array of subject addresses
    function getSubjects() external view returns(address[] memory);

    /// @notice Add a new voter into the voting system.
    /// @param voter  Address of the voter
    function addVoter(address voter) external;

    /// @notice Start the voting period.
    function startVoting() external;

    /// @notice Vote positive for the subject.
    /// @param subject  Address of the subject
    function votePositive(address subject) external;

    /// @notice Vote negative for the subject.
    /// @param subject  Address of the subject
    function voteNegative(address subject) external;

    /// @notice Vote for multiple subjects.
    /// @param subjects  Array of subject addresses
    /// @param votes     Array of votes (true for positive, false for negative)
    function voteBatch(address[] calldata subjects, bool[] calldata votes) external;

    /// @notice Get the remaining time to the voting end in seconds.
    /// @return  Remaining time in seconds
    function getRemainingTime() external view returns(uint256);

    /// @notice Get the voting results, sorted descending by votes.
    /// @return  Array of subjects sorted by votes
    function getResults() external view returns(Subject[] memory);
}

Contract code

Now create file D21.sol and copy the following code as a starting point of your implementation.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.26;

import "./IVoteD21.sol";

contract D21 is IVoteD21 {

    // TODO: IVoteD21 implementation

}