Problem understanding TransparentUpgradeableProxy

[carlitox477]

I really don't understand how it work.

First we deploy it

encoded_initializer=encode_function_data()
    proxy=TransparentUpgradeableProxy.deploy(
        implementation.address, #implementation contract address
        admin_address, #Admin address
        encoded_initializer, #Data: encoded function call
        {
            "from": account,
            "gas": 10**6}
        )

What exactly does the encoded_initializer in the TransparentUpgradeableProxy constructor? I understand that it is related to assigned value to the contract on implementation.address

On the other hand, we use the proxy to interact with the implementation.address, but really can anyone interact with implementation.address if they wish to unless we forbid it?

In addition, when we do:

proxy_box = Contract.from_abi(
        "Box",
        proxy.address,
        Box.abi
        )

This does nothing in the blockchain. It is used so python can create a new mapping to the functions "added" to the proxy (I supposed that we just change attributes in a mapping when we called the TransparentUpgradeableProxy constructor, but to keep it simple I just say added XD), am i right?

[cromewar]

Hello @carlitox477 I'll try to answer you questions.

What exactly does the encoded_initializer in the TransparentUpgradeableProxy constructor?

contract TransparentUpgradeableProxy is ERC1967Proxy {
    /**
     * @dev Initializes an upgradeable proxy managed by `_admin`, backed by the implementation at `_logic`, and
     * optionally initialized with `_data` as explained in {ERC1967Proxy-constructor}.
     */
    constructor(
        address _logic,
        address admin_,
        bytes memory _data
    ) payable ERC1967Proxy(_logic, _data) {
        assert(
            _ADMIN_SLOT ==
                bytes32(uint256(keccak256("eip1967.proxy.admin")) - 1)
        );
        _changeAdmin(admin_);
    }

This is low level stuff for solidity contracts, this actually takes data directly from the ABI, you may have a initializer for the contract, for example a specific function, so encode_function_data send the initializer ABI data, on the course we don't use one and just take the default.

can anyone interact with implementation.address if they wish to unless we forbid it?

The answer is yes, but the user will not have access to the features yo have on the upgraded version, anyways you will point the users to the proxy address instead of the Box contract address, as you can see bellow all the transactions are made on the proxy address contract. Also you might push the user to not use the original project.

"This does nothing in the blockchain. It is used so python can create a new mapping to the functions "added"....."

Yes, this just take low level information on the ABI from the box contract. and uses the proxy to execute the functions on the contract.

I hope this information might help, @PatrickAlphaC am I missing something else?

Best regards, Cromewar.

[PatrickAlphaC]

Cromewar that's spot on!!

With upgradeable smart contracts, anyone can interact with the implementation, but we don't care since all our data is stored in the proxy. So if we have a variable called value on the implementation, it actually gets stored in the proxy contract.

Crazy right?

So our implementation can't have a constructor, since we won't be storing any data in the implementation. We have an initializer function which is called right as we deploy our contract. You can think of the initializer as the constructor, that gets call right after you deploy.

Hopefully that makes sense.