Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support verifying proxy contracts from older versions #674

Open
ericglau opened this issue Oct 17, 2022 · 4 comments
Open

Support verifying proxy contracts from older versions #674

ericglau opened this issue Oct 17, 2022 · 4 comments

Comments

@ericglau
Copy link
Member

When performing Etherscan verification with the Hardhat Upgrades plugin's verify task, verification fails if the proxy contract was deployed from an older version of the Hardhat Upgrades plugin where the proxy contract source code or compiler version was different.

For example, in this thread, an existing ProxyAdmin contract was previously deployed using compiler version 0.8.2 and failed to verify with compiler version 0.8.9.

We should include a repository of proxy contract artifacts from previous versions of the plugins, and attempt to verify against those.

@faalbane
Copy link

Greetings; any updates with this issue?

@ericglau
Copy link
Member Author

ericglau commented Oct 31, 2022

This isn't something we are working on at the moment, although workarounds are possible:

  • If any proxy contract(s) failed to verify with the plugin and are not already verified on the network that you are using, you could still verify them manually using the instructions here (or contact us to assist with verifying the proxy contracts).

  • For proxy contracts deployed with older versions of the plugin that used compiler version 0.8.2, here are the Solc JSON input and build-info files:
    verify-0.8.2.zip

  • Another workaround is to temporarily downgrade @openzeppelin/upgrades-core to match the version that you used to deploy the proxy, use that to run the verify task, then upgrade the package again.

@ericglau
Copy link
Member Author

Here are some technical details on what is needed for this issue. If anyone would like to contribute a PR, we would be happy to discuss it further / review.

The function that we use to verify a contract tries to match the existing contract's creation code with known bytecode of proxy contract artifacts produced by the compiler. Currently there is only one set of artifact files provided, which corresponds to the different types of proxy contracts that can be deployed by that version of the plugin.

The source code stored in the Solc JSON input and the compiler version string are also retrieved from the build-info file, and there is currently only one build-info file in the plugin corresponding to the latest source code.

The fix would be to make this include multiple sets of artifact JSONs and build-info files with the plugin, and support searching through those different sets for a possible match.

Previous artifact JSONs can be found in previous versions of the @openzeppelin/upgrades-core npm package.
Previous build-info files can be found in previous versions of the @openzeppelin/upgrades-core npm package starting from v1.15.0. Older build-info files would need to be rebuilt from older tags in this repository.

@ericglau
Copy link
Member Author

ericglau commented May 10, 2023

Additional implementation notes:
When performing source code verification, the proxy contract artifacts produced by the compiler are used for matching the contract's bytecode. However, this bytecode is also available in the build-info file's output section (under each contract's section, in evm.bytecode.object as a non-0x-prefixed hex string).

Therefore, we can simplify the above to only include previous build-info files without previous artifact JSONs, and change the verification to read bytecode from the build-info files instead of artifact JSONs.

Important: Another requirement is that before each release, we should have an automated way to add the build-info file from the previous release into the set of files for matching.

  • Instead of including previous build-info files in the plugin, which would cause its size to keep growing over time, another possibility is to keep the previous files online in a known location.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants