[Ethereum] Using a high level delegate call in upgradable contracts since Byzantium

contract-designcontract-developmentproxy-contractssolidityupgrading

Since Byzantium we can implement upgradable proxy contracts much easier with the use of returndatacopy and returndatasize assembly instructions. This means we no longer have to register return types and sizes like when using the EtherRouter.

The most reliable way we know how to structure a proxy contract is like the Zeppelin Proxy where the delegatecall is made in assembly. However, it also seems to work when doing the delegatecall as a high level Solidity call where the proxy contract fallback function looks like this instead:

function () public {

    bool callSuccess = upgradableContractAddress.delegatecall(msg.data);

    if (callSuccess) {
        assembly {
            returndatacopy(0x0, 0x0, returndatasize)
            return(0x0, returndatasize)
        }
    } else {
        revert();
    }
}

This approach (see the whole proxy here) is a bit more succinct and requires less knowledge of assembly to understand. My minimal tests for this approach seem to work.

So in what situations will this high level approach not work?

And if there aren't any, how likely is it that the compiled bytecode for the high-level delegatecall will change between versions of Solidity, breaking this approach for those versions?

Best Answer

One issue is that you copy your data into memory starting at address 0. This will work for return sizes less than 64 bytes, but will start overwriting other memory at that point.

Instead you should do something more like

let m := mload(0x40)
returndatacopy(m, 0, returndatasize)
return(0, returndatasize)

Related Solutions

Solidity – Why Solidity Never Frees Memory: Understanding the Mechanism

Solidity always places new objects at the free memory pointer and memory is never freed (this might change in the future).

This means simply that memory management in Solidity is currently very rudimentary. The compiler maintains a pointer to the end of the last allocated block and that's it. Allocating a new memory variable means moving that pointer forward.

The compiler never tries to reclaim already allocated memory. Even when all references to your memory variable go out of scope, there's no mechanism that would detect it and mark the space as available for reuse.

This is true for the duration of a single external call to the contract. Each new call starts with zeroed memory and freshly initialized free memory pointer.

There are some operations in Solidity that need a temporary memory area larger than 64 bytes and therefore will not fit into the scratch space. They will be placed where the free memory points to, but given their short lifetime, the pointer is not updated. The memory may or may not be zeroed out. Because of this, one should not expect the free memory to point to zeroed out memory.

This part refers to a small optimization the compiler performs when it needs a very short-lived memory block for the current operation. Instead of properly allocating it by updating the free memory pointer, it just writes past the pointer, knowing that the memory there is not in use. The text warns you that if you try to read from this area of unallocated memory using inline assembly, you might find some leftovers from such an operation and you should not assume that the memory there is always zeroed-out.

Solidity – How to Alter the Gas Stipend with High-Level Delegate Call

You can specify the gas using the gas modifier (in brackets) before the function args, e.g.:

(bool success, bytes memory returndata) = target.delegatecall{ gas: 10000 }(data);

The modifiers are documented here:

https://docs.soliditylang.org/en/v0.8.16/types.html#address

Related Topic