Deploy proxy contracts from OpenZeppelin Contracts 5.0

[ericglau]

Targets release branch hardhat-upgrades-v3 to allow for alpha version.

---

Deploys proxy contracts from OpenZeppelin Contracts 5.0, but continues to support importing and working with existing deployments from Contracts 4.x and below.

Updates Etherscan verification to verify proxy admins which are deployed by a transparent proxy rather than directly by the plugin.

upgrades-core will have proxy bytecodes for both 5.0 and 4.x proxies for backwards compatibility with older version of hardhat-upgrades.

Fixes #907

• Tested with local npm packages
• Tested with Defender
• Tested with Hardhat Verify

[socket-security]

Updated and removed dependencies detected. Learn more about Socket for GitHub ↗︎

Packages	Version	New capabilities	Transitives	Size	Publisher
ethers	6.6.7...6.8.1	None	+6/-4	17.2 MB	ricmoo
@openzeppelin/contracts-upgradeable	4.8.3...5.0.0	None	+0/-0	1.21 MB	frangio
solidity-ast	0.4.55...0.4.49	None	+0/-82	231 kB	frangio

🚮 Removed packages: @openzeppelin/[email protected]

[socket-security]

👍 Dependency issues cleared. Learn more about Socket for GitHub ↗︎

This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored.

[rsimonton]

@ericglau hello ser, is this blocked? Anxiously awaiting this functionality, thanks.

[Amxx]

The current owner may not be the one used for deployment. Not sure if that would be easy to support, but if that is not the case, we probably want to have a verbose error.

[ericglau]

Good point. Changed it to look for the OwnershipTransferred event that should have been logged during construction and get the original owner from that.

[ericglau]

@rsimonton We're planning to have this available soon. We'll likely do an alpha release once this is merged so that you can start using it (it will be alpha for now since we still need to evaluate some breaking changes, particularly #912)

[ernestognw]

On a side note, I think we should change all of the @openzeppelin/contracts-v5 imports and use @openzeppelin/contracts-v4 for v4 instead.

Should be added before the final 3.0 release, right?

[ericglau]

@ernestognw

On a side note, I think we should change all of the @openzeppelin/contracts-v5 imports and use @openzeppelin/contracts-v4 for v4 instead.

Should be added before the final 3.0 release, right?

I'd prefer that, however these paths are in upgrades-core and we want to keep it backwards compatible. We aren't doing a major release for that package.

Since upgrades-core already packages /artifacts/@openzeppelin/contracts/proxy for v4 proxies, we need to define a different naming scheme for v5 proxies.

[ernestognw]

Since upgrades-core already packages /artifacts/@openzeppelin/contracts/proxy for v4 proxies, we need to define a different naming scheme for v5 proxies.

Right, thanks for clarifying. I'd suggest creating an issue to track this if we ever bump upgrades/core so we can consider a fix, but you decide.

[ernestognw]

Alright, this LGTM 🚀

[ericglau]

Since upgrades-core already packages /artifacts/@openzeppelin/contracts/proxy for v4 proxies, we need to define a different naming scheme for v5 proxies.

Right, thanks for clarifying. I'd suggest creating an issue to track this if we ever bump upgrades/core so we can consider a fix, but you decide.

Opened issue #931 to track.

[rsimonton]

You all are legends!  🫡

[rsimonton]

I don't have time to open an issue atm but it looks like the deployProxy function doesn't support/respect explicitly typed data.

In my case I have contracts A and B, where B extends A. Both are upgradeable. B's initializer adds an additional argument. When calling B's initializer (prior to my incorporating the upgrades plugin) in order for ethers to know which version of initialize to call, I had to explicitly type B's additional argument as described, for example, here.

Trying to do this when calling deployProxy, like so:

     const proxy = await upgrades.deployProxy(
            contractFactory,
            [
                // .. other initializer args here
                ethers.Typed.uint16(foo)
            ],
            {
                kind: "uups",
            }
        )

...the deployment fails with TypeError: ambiguous function description (i.e. matches "initialize(...

Is it possible for the upgrades plugin to support the ethers v6 typed data API? Or is there some other way to work around? Thanks!

[ericglau]

@rsimonton You can try specifying a fragment using the initializer option. See Specifying Fragments (that's from ethers v5 doc but it should be the same for v6).

For example, you can provide the initializer function's signature like:

     const proxy = await upgrades.deployProxy(
            contractFactory,
            [
                // .. other initializer args here
                foo
            ],
            {
                kind: "uups",
                initializer: 'initialize(uint256)',
            }
        )

If this is still a problem for you, please open a separate issue, thanks!