Solidity OpenZeppelin – Difference Between init and init_unchained in Proxy Contracts

contract-upgradingopenzeppelinproxy-contractssolidity

I am learning to develop upgradeable smart contracts using openzeppelin library for ERC721 and ERC1155 contracts. However, I don't understand what does the unchained function mean. More specifically what's the difference between init and init_unchained functions. Below 2 functions show them being called in an ERC1155 upgradeable contract provided by Openzeppelin

function __ERC1155_init(string memory uri_) internal onlyInitializing {
        __ERC1155_init_unchained(uri_);
    }

function __ERC1155_init_unchained(string memory uri_) internal onlyInitializing {
        _setURI(uri_);
    }

Best Answer

From OpenZeppelin's docs, there is the following section:

Initializer functions are not linearized by the compiler like constructors. Because of this, each __{ContractName}_init function embeds the linearized calls to all parent initializers. As a consequence, calling two of these init functions can potentially initialize the same contract twice.

The function __{ContractName}_init_unchained found in every contract is the initializer function minus the calls to parent initializers, and can be used to avoid the double initialization problem, but doing this manually is not recommended. We hope to be able to implement safety checks for this in future versions of the Upgrades Plugins.

This basically means that multiple inheritance doesn't play nice with initializers.

Generally, a _<CONTRACT_NAME>_init_unchained method defines the initialization of the derived contract while excluding initializing the parents that it derives from (you'd have to explicitly initialize those parents in your contract), while a _<CONTRACT_NAME>_init method defines the initialization of the derived contract along with all the parents that it derives from. In your case, the unchained method happens to require no parent initialization .

In some cases with multiple inheritance, the derived contract that you define could have an collision where two its parent contracts share a parent contract that they both derive from. In such a case, the _<CONTRACT_NAME>_init call on the shared parent that exists in both initializers of the collided contracts would result in attempting to initialize the shared parent contract twice, which causes an error. OpenZeppelin's upgradable contracts have been improving a lot in the past few years in order to minimize the possibility of such collisions. Consider using the Contracts Wizards and ticking the "upgradeability" check box to showcase writing smart contracts with multiple inheritance without being faced with such issues.

Related Solutions

[Ethereum] the difference between an internal/external and public/private function in solidity

The paragraph specifically mentions that only function types are by default internal, and contract functions are by default public, even though I agree the wording is a little bit confusing. It says nowhere that they are at the same time both public and internal.

I think that there is some confusion to what a function type is. The same way you specify the type for a 256 int variable with the keyword uint256, you can also specify the type of a variable that will hold a function. The only difference is that this type declaration is a little more complex since functions are more complex and it looks like this:

function (param types) {internal|external} [pure|constant|view|payable] [returns (return types)] varName;

You can then assign to the variable varName a function that has the same type that you defined. This is only possible inside another function.

As a very simple example:

contract Example{
    function(uint256) returns (uint256) varName;

    function simpleFunction(uint256 parameter) returns (uint256){
        return parameter;
    }

    function test(){
        varName = simpleFunction;
    }
}

Where varName is the variable of function type, while simpleFunction and test are normal contract functions

Just so you have a simple definition for all those access classifiers:

public - all can access
external - Cannot be accessed internally, only externally
internal - only this contract and contracts deriving from it can access
private - can be accessed only from this contract

As you can notice private is a subset of internal and external is a subset of public.

Solidity Reference Passing – How to Pass By Reference in Solidity

When you declare a parameter as storage you are limiting the function to only accept parameters with that qualifier.

The qualifiers storage, memory and calldata specify where the data is located. You can convert implicitly storage to memory and calldata to memory, but the reverse is not possible.

string public stor = "banana";

function test(string calldata calld) external view {
    string memory memo = "pizza";

    foo(memo, stor);
    foo(calld, stor);  // Creates a copy of calld in memory and passes as parameter
    foo(stor, stor);   // Creates a copy of stor in memory and passes as parameter
    
    foo(memo, stor);
    // foo(memo, memo); // Cannot convert from memory to storage
    // foo(memo, calld); // Cannot convert from calldata to storage
}

function foo(string memory, string storage) internal view {
    
}

/* This fails because you can only use calldata on external functions
function bar(string calldata) internal view {
    
} */

Value types like bool, uintXXX, bytesYY, address, etc. are passed by value. Non-value tyeps like structs, arrays, string are passed by reference.

Functions that are public, internal and private can use types passed by reference but only if they are call from the same contract.
Functions public and external will receive a copy when called by a regular user of from another contract.

I don't know why, but at least since solc 0.3 it wasn't allowed.

Best Answer

Related Solutions

[Ethereum] the difference between an internal/external and public/private function in solidity

Solidity Reference Passing – How to Pass By Reference in Solidity

Related Topic