Add OpenZeppelin's upgrades validation for proxies

[outdoteth]

Fixes: #141

Also, this PR builds on #142 so that needs to be merged first.

This integrates open zeppelin's upgrades plugin: https://github.com/OpenZeppelin/openzeppelin-upgrades
and uses their upgrade verification logic to ensure that a contract is a valid implementation.

Some examples of the cool new errors generated 😄 :

This is what happens with this plugin:

1. Add a subtask to solidity compile and format solc output to match open zeppelin's required format. Save this output into cache/validations.json
2. User runs a proxy deploy task. E.g.:

    await deploy("Foo", {
        from: deployer,
        contract: "ContractA",
        proxy: {
            proxyContract: "TransparentUpgradeableProxy",
            viaAdminContract: {
                name: "ProxyAdmin",
                args: [],
            },
        },
    });

3. Fetch "ContractA" from cache/validations.json and put it through openzeppelin_assertIsValidImplementation to ensure the contract doesn't contain any constructors etc. and is valid.
4. Save "ContractA" to ".openzeppelin" manifest

Then on upgrade, there is an additional step.

5. User runs deploy task again on "Foo" but upgrades implementation to "ContractB":

    await deploy("Foo", {
        from: deployer,
        contract: "ContractB", // Change to ContractB from ContractA
        proxy: {
            upgradeIndex: 1, // we are upgrading the contract here
            proxyContract: "TransparentUpgradeableProxy",
            viaAdminContract: {
                name: "ProxyAdmin",
                args: [],
            },
        },
    });

6. Repeat steps 2-4 but with "ContractB" instead
7. Then pass the proxy contract and the new implementation into openzeppelin_assertIsValidUpgrade. This will fetch the old implementation and compare it against the new implementation to make sure it is valid.
8. Save "ContractB" to ".openzeppelin" manifest

[outdoteth]

Possible TODOs:

• Make the validation have a toggle so the user can opt out if needed.
• Allow the user to pass validation config to openzeppelin verifier.

But I think this serves as a good starting point for now and is sufficient to be merged.

[gregegan]

@outdoteth @wighawag - This looks extremely helpful, we're actually trying to solve for figuring out storage slot comparisons during proxy upgrades. What is the status of this PR? Would love to get this merged in if it's 👍

[outdoteth]

@gregegan no update from me. Waiting for @wighawag to review.

[wighawag]

Hey all, sorry for the lack of update, need to look deeper but currently not available.
Once I have more time, I ll look into it

[nishuzumi]

This is a very important feature that will take a lot of work out of it. Hope to merge soon

[wighawag]

I just had a quick look and saw that there is a dependency on hardhat-upgrades

Any way to remove the dependency on hardhat-upgrades which is itself a plugin ?

having plugin import other plugin is not great

[outdoteth]

@wighawag Yes it should be possible. There are only 3 small utility functions which are used from that package. I'll take a look tomorrow.

[nishuzumi]

@wighawag Yes it should be possible. There are only 3 small utility functions which are used from that package. I'll take a look tomorrow.

Hi, what about now

[wighawag]

would be better if we did not use openzeppelin file but instead include the data in the deployment file where it should belong

[fr0zn]

Any updates on this one?

[naderhen]

If this PR isn't progressing, is anyone aware of a good way to validate upgrades that are deployed via hardhat-deploy? I recently moved my project over to hardhat-deploy (for so many reasons, this project is amazing!), but would definitely miss the confidence that OZ's validation gives me when releasing upgrades.

I'm not super familiar with the architecture here, but I may be able to help keep things moving with a point in the right direction.

[fullkomnun]

I submitted an updated PR with support for openzeppelin's upgradability validations #358
@outdoteth @wighawag

[pnghai]

@outdoteth I doubt that pending conflicts are blocking this fork from merging with main branch?