Upgrade to contracts-upgradeable 3.3 + with EIP712

Support Upgrades
1

Hello and first thanks again for this great tool :+1:

I ugraded from
@openzeppelin/contracts-ethereum-package": "^3.0.0
image

to :
@openzeppelin/contracts-upgradeable": "^3.3.0
image

It compiled without issue. But at npx oz upgrade in testnet i had this error due to a change between versions :

image
image1042×121 22.3 KB

Anyway it was deployed in rinkeby successfully with –force option, so i suppose this is a non-blocking error.

Then i tried to use main rep with drafts and work done on EIP712 :

Added to main contract with initialize functions :

contract DarkPay is Initializable, [...] ERC20PermitUpgradeable   { ... }

function __DarkPay_init(string memory name, string memory symbol) internal initializer {
[...]
 __ERC20Permit_init_unchained(name);
 }

Then got this new variables error :

image
image1035×302 67.7 KB

Did i miss something about current EIP712 implementation ? Is it OK to add to an existing upgradable contract ?
Perhaps the issue is just i can’t add EIP712 to an existing, deployed contract.

I should’ve updated also @openzeppelin/contract-loader & @openzeppelin/upgrades ?

Thanks !

Stem

1 Like
2

Hi @DarkPay,

I will have to come back to you if you can upgrade from OpenZeppelin Contracts Ethereum Package 3.0 to OpenZeppelin Contracts Upgradeable 3.3.

As OpenZeppelin Contracts Ethereum Package has an Initializable with a uint256[50] private ______gap;, whilst Initializable in OpenZeppelin Contracts Upgradeable is without a gap state variable.

Please note: We’ve decided it’s best to focus our upgradeability efforts on the Upgrades Plugins exclusively, and have halted development on the OpenZeppelin CLI. We will continue to provide support for the CLI until the end of 2020.
See: Building for interoperability: why we’re focusing on Upgrades Plugins

I suggest you look to migrate to Upgrades Plugins: https://docs.openzeppelin.com/upgrades-plugins/1.x/migrate-from-cli

3

Hi @DarkPay,

The lack of the gap variable in the new Initializable makes it incompatible with ethereum package deployments. We’re really sorry about this inconvenience. The fact that you were able to deploy using --force does not mean it is safe at all; it is not safe.

Fortunately it’s possible to insert the gap in the right place using multiple inheritance so that the new layouts match with the old one. You should define the following contract:

import '@openzeppelin/contracts-upgradeable/proxy/Initializable.sol';

contract InitializableGap is Initializable {
    uint256[50] ____gap;
}

You can include this in your inheritance immediately after Initializable like this:

contract DarkPay is Initializable, InitializableGap, [...] ERC20PermitUpgradeable   { ... }

This will insert the gap so that storage layout matches the layout from contracts-ethereum-package.

Again, we’re sorry about this inconvenience but let us know if you try this workaround and if it works for you.

1 Like