How to use solidity v4 with openzeppelin upgrades

:computer: Environment

Migrating a solc v0.4 project from truffle + web3 + openzeppelin-eth + zos-lib to buidler + ethers + waffle + @openzeppelin/buidler-upgrades.

:memo:Details

I am wondering what packages to use to replace openzeppelin-eth + zos-lib packages while still using solc v0.4

:1234: Code to reproduce

3 Likes

Hi @thegostep,

Welcome to the community :wave:

I assume that this is a project deployed on mainnet and you want to use OpenZeppelin Upgrades plugins to test and check upgrades.

What version of openzeppelin-eth are you using? It looks like the last Solidity 0.4 version of the upgrade safe fork of OpenZeppelin Contracts was openzeppelin-eth 2.0.2.

I don’t know if there were storage layout changes between versions of openzeppelin-eth or whether you can upgrade to a later version. (For example, storage layout changes means that we can’t upgrade from OpenZeppelin Contracts Ethereum Package 2.5 to 3.0).

My assumption is that you can use the latest compatible version of openzeppelin-eth (this could be 2.0.2) and use the OpenZeppelin Upgrades Buidler plugins but will need to manually configure the network file (https://docs.openzeppelin.com/upgrades-plugins/1.x/network-files#network.json).

Are you able to share a repository with the code that you want to migrate?

Thanks @abcoathup

Here is the PR I am working on. https://github.com/ampleforth/uFragments/pull/164

The simple solution is to keep openzeppelin-eth and zos-lib, but they annoyingly come bundled with web3 and it’s never great to use deprecated dependencies.

1 Like

Hello @thegostep, I’m working on a migration tool for this very use case. I’ll contact you privately.

1 Like

The migration tool that @martriay mentioned is for OpenZeppelin CLI users. We looked at your project in more detail and see that you don’t use the CLI so it’s not relevant for you.

I see that the real issue here is that you need to use openzeppelin-eth 2.0.2 because of solc 0.4 support, but that package has a peer dependency on zos-lib because of Initializable.sol, which then forces a lot of deprecated dependencies that you understandably don’t want.

I’m looking into the options and I’ll get back to you in a little bit!

1 Like

I’ve published openzeppelin-eth@2.0.2-standalone as a variant that comes with Initializable.sol vendored in and without a peer dependency on zos-lib. You should be able to use this version of openzeppelin-eth together with the upgrades plugins on Buidler, and you can uninstall zos-lib entirely.

yarn add openzeppelin-eth@2.0.2-standalone
yarn remove zos-lib

Let me know how it goes!

1 Like

this is great - thanks !

2 Likes

@thegostep I would love to know why you’re using Solidity 0.4 and not upgrading. Is it a choice or are you stuck with it for backwards compatibility?

We’re currently trying to figure out what to do with Solidity 0.7 support, whether to keep supporting 0.6, etc.

1 Like

Hey @frangio - We are looking into upgrading to v0.6 right now. The team has two major concerns: 1) storage layout changes that go unnoticed from a version refactor. 2) latest compiler versions that are unaudited.

I am currently making the assessment of whether or not to move forward with the upgrade and the first step was to modernize our testing and deployment infra.

2 Likes