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

Verify proxy/implementation on etherscan #541

Draft
wants to merge 10 commits into
base: develop
Choose a base branch
from

Conversation

jordaniza
Copy link
Contributor

@jordaniza jordaniza commented Feb 19, 2024

Description

Adds a call to the etherscan API at the end of the deploy script. This call passes the address of proxy contracts, along with their implementation, to etherscan.

In theory, this should work. In practice the etherscan API on testnets have been extremely unreliable, sometimes verifying, sometimes returning verification errors.

It is possible to re-run the stage with yarn deploy --network XXX --tags VerifyProxies, which will fetch the list of deployment addresses from the build cache. I've had some success waiting for a bit then re-running the step. We may prefer to add some deployment instructions to advise users with errors to wait a while for the block explorer to properly index the contract verification.

Task ID: OS-1062

Type of change

  • New feature (non-breaking change which adds functionality)

Checklist:

  • I have selected the correct base branch.
  • I have performed a self-review of my own code.
  • I have commented my code, particularly in hard-to-understand areas.
  • My changes generate no new warnings.
  • Any dependent changes have been merged and published in downstream modules.
  • I ran all tests with success and extended them if necessary.
  • I have updated the CHANGELOG.md file in the root folder.
  • I have updated the DEPLOYMENT_CHECKLIST file in the root folder.
  • I have updated the UPDATE_CHECKLIST file in the root folder.

@jordaniza jordaniza changed the title tests and implementation, pending live deploy Verify proxy/implementation on etherscan Feb 19, 2024
Copy link
Contributor

@Rekard0 Rekard0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is some style/formatting errors

Copy link
Contributor

@heueristik heueristik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left a few comments.

One more thing: Do we need mock-deployments.json to be tracked with git or should we .gitignore it?

packages/contracts/utils/etherscan.ts Outdated Show resolved Hide resolved
packages/contracts/utils/etherscan.ts Show resolved Hide resolved
Comment on lines +67 to +69
To avoid having to manually set 'Is this a Proxy?' in etherscan, you may call the Proxy Verification script, once your contracts have been verified. To do this run: `yarn verifyProxies --network <network>`.

```shell
npx hardhat verify --network goerli DEPLOYED_CONTRACT_ADDRESS "Hello, Hardhat!"
```
This can be run multiple times provided you haven't used the `--reset` flag to clear the deployment data. The etherscan API can be a little flaky at times so be patient with it and try multiple times if necessary.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would bet that this is because of rate limiting. Have you tried waiting 6s between the requests as we do it in our deploy script?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't believe it is: the error messaging indicates the contracts cannot be found sometimes, although this appears to be inconsistent. I think it may be due to delays in indexing the contracts on the explorers, and propagating the data.

Copy link
Contributor

@heueristik heueristik Mar 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We had the same problem with Polygon. In this case, we added a one-time delay to the script.

// add a timeout for polygon because the call to `implementation()` can fail for newly deployed contracts in the first few seconds
if (network.name === 'polygon') {
console.log(`Waiting 30secs for ${network.name} to finish up...`);
await setTimeout(30000);
}

I think having a script that runs robustly and doesn't need to be executed multiple times, is important.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will take a look, if it doesn't work I will shelf the PR for now to avoid getting stuck on it.

DEPLOYMENT_CHECKLIST.md Outdated Show resolved Hide resolved
UPDATE_CHECKLIST.md Outdated Show resolved Hide resolved
packages/contracts/utils/etherscan.ts Outdated Show resolved Hide resolved
packages/contracts/test/deploy/verify-proxies.ts Outdated Show resolved Hide resolved
packages/contracts/utils/etherscan.ts Outdated Show resolved Hide resolved
packages/contracts/utils/etherscan.ts Show resolved Hide resolved
packages/contracts/utils/etherscan.ts Outdated Show resolved Hide resolved
jordaniza and others added 2 commits February 27, 2024 13:01
@jordaniza
Copy link
Contributor Author

I left a few comments.

One more thing: Do we need mock-deployments.json to be tracked with git or should we .gitignore it?

I think we should commit this file, it is a hardcoded snapshot of a point in time deployment and so is not autogenerated. We could strip much of the data out and keep the mock minimal if you would prefer.

@heueristik
Copy link
Contributor

I left a few comments.
One more thing: Do we need mock-deployments.json to be tracked with git or should we .gitignore it?

I think we should commit this file, it is a hardcoded snapshot of a point in time deployment and so is not autogenerated. We could strip much of the data out and keep the mock minimal if you would prefer.

The file is 1.35 MB large, so yes - let's try to reduce file size.

@jordaniza
Copy link
Contributor Author

I left a few comments.
One more thing: Do we need mock-deployments.json to be tracked with git or should we .gitignore it?

I think we should commit this file, it is a hardcoded snapshot of a point in time deployment and so is not autogenerated. We could strip much of the data out and keep the mock minimal if you would prefer.

The file is 1.35 MB large, so yes - let's try to reduce file size.

Trimmed to just the addresses and added a comment to explain it

@jordaniza jordaniza marked this pull request as draft March 4, 2024 12:04
@jordaniza
Copy link
Contributor Author

Adding the delay didn't resolve the issue on Optimism Sepolia. Need to understand why but will require further investigation. Moving the PR to draft for now and will revisit once I have time.

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

Successfully merging this pull request may close these issues.

3 participants