Is it safe to upgrade from contracts-ethereum-package to contracts-upgradeable on existing contract

Support Upgrades
1

:computer: Environment

"@openzeppelin/truffle-upgrades": "^1.5.0",
"truffle": "^5.1.67",
"@openzeppelin/contracts-ethereum-package": "^3.0.0",
"@openzeppelin/contracts-upgradeable": "^3.4.0"

:memo:Details

Background
I have contract A that is written with @openzeppelin/contracts-ethereum-package, and I have contract B that written with @openzeppelin/contracts-upgradeable. As I have also upgraded @openzeppelin/truffle-upgrades from 1.2 to 1.5 so the deployProxy doesn’t work with the old contract A migration and raised The requested contract was not found. So I have to update contract A to also use @openzeppelin/contracts-upgradeable. And now the migration works.

Question
I just want to double check. Is it safe to update the existing contract A from @openzeppelin/contracts-ethereum-package to @openzeppelin/contracts-upgradeable

:1234: Code to reproduce

1 Like
2

Hi @leckylao,

it is not safe to upgrade from @openzeppelin/contracts-ethereum-package (a similar previous package) to @openzeppelin/contracts-upgradeable .

_From: https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable/blob/master/README.md_

Also see: https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable/issues/109#issuecomment-783556754

You could use the workaround for the missing storage gap in the Initializable contract: Upgrade to contracts-upgradeable 3.3 + with EIP712 - #3 by frangio

You would then need appropriate high level tests to check for upgrade safety across versions.

3

Thank you. Would try the workaround

1 Like
4

Hi @leckylao! Is your code available in a repository that I can try? I’m not sure why you saw the error “The requested contract was not found” and I want to take a look.

1 Like
5

I believe it’s caused by the new version of truffle-upgrade that in the migration the new deployProxy looking for the new namespace. Which also caused the problem that I can’t run test with the old contract as can’t migrate it and have to test using mainnet fork. Don’t really like a breaking upgrade that caused triple work on the development as a feedback.

1 Like
6

Hi @frangio @abcoathup,

I have applied the workaround and got the following error from the plugin upgrade check

Error: New storage layout is incompatible

../@openzeppelin/contracts-upgradeable/proxy/Initializable.sol:25: Renamed `initialized` to `_initialized`

../@openzeppelin/contracts-upgradeable/proxy/Initializable.sol:30: Renamed `initializing` to `_initializing`

InitializableGap.sol:7: Renamed `______gap` to `____gap`

ERC20UpgradeableWithGap.sol:40: Upgraded `_allowances` to an incompatible type
  - In mapping(address => mapping(address => uint256))
    - Bad upgrade from uint256 to mapping(address => uint256)

ERC20UpgradeableWithGap.sol:44: Upgraded `_name` to an incompatible type
  - Bad upgrade to string

ERC20UpgradeableWithGap.sol:45: Upgraded `_symbol` to an incompatible type
  - Bad upgrade to string

Is this looks ok? And is there a way to bypass the checker?

1 Like
7

Can you share the exact version you were using of @openzeppelin/contracts-ethereum-package, and the version of @openzeppelin/contracts-upgradeable that you are trying to upgrade to?

If possible I need to see the exact version, which is found in the lockfiles (package-lock.json, yarn.lock) and not in package.json.

1 Like
8 
npm list @openzeppelin/contracts-ethereum-package  
└── @openzeppelin/contracts-ethereum-package@3.0.0
npm list @openzeppelin/contracts-upgradeable     
└── @openzeppelin/contracts-upgradeable@3.4.0
1 Like
9

Hey @leckylao, sorry for the delay in replying.

The renaming of _gap is just a matter of adding the missing underscores.

The first two errors from Initializable.sol can’t be worked around at the moment, unfortunately…

The remaining errors are carryover from the previous errors, they are not errors themselves.

1 Like
10

Is that means the workaround doesn’t work yea? Could you confirm?

In that case I might just keep on using contracts-ethereum-package then.

1 Like
11

Yes, you should keep using contracts-ethereum-package for now. Apologies for this inconvenience!

1 Like
12

I reckon also update the docs to let users keep using the old lib if already using it. And also mention the workaround doesn’t really work.

1 Like