op-deployer: add command to verify contracts on etherscan by bitwiseguy · Pull Request #14359 · ethereum-optimism/optimism

bitwiseguy · 2025-02-13T20:38:04Z

Overview

Provides a user-friendly command to verify L1 contracts on etherscan. The following information is used for verification:

contract addresses: pulled from the state.json file
contract artifact info (source code, compile settings): pulled from artifacts specified by l1ContractLocator field in the state.json.
constructor args: encode by pulling data from deployed contracts and state.json file

Usage

Verify all contracts:

go run ./cmd/op-deployer verify \
  --l1-rpc-url "xxx" \
  --etherscan-api-key xxx

Verify one of the contract bundles (i.e. superchain, implementations, opchain)

go run ./cmd/op-deployer verify \
  --l1-rpc-url "xxx" \
  --etherscan-api-key xxx
  --contract-bundle superchain

Verify a single contract

go run ./cmd/op-deployer verify \
  --l1-rpc-url "xxx" \
  --etherscan-api-key xxx
  --contract-bundle superchain
  --contract-name ProxyAdminAddress

Testing

Manually tested by running the following sequence:

Modified the implementation source code for ProxyAdmin, SuperchainConfig, and ProtocolVersions by just adding an extra function to each one called fakeFunction so that the bytecode was unique and the contract was not automatically verified by etherscan.
just build - compile the contracts
Ran the following command to deploy the superchain contract bundle to sepolia

go run ./cmd/op-deployer bootstrap superchain \
  --l1-rpc-url="xxx" \
  --private-key="xxx" \
  --artifacts-locator="file:///Users/<username>/repos/op-labs/optimism/packages/contracts-bedrock/forge-artifacts" \
  --required-protocol-version="0x33a0e51eCD7188d2F13769D7B4feE4390e970C7D000000000000000000000000" \
  --recommended-protocol-version="0x33a0e51eCD7188d2F13769D7B4feE4390e970C7D000000000000000000000000" \
  --superchain-proxy-admin-owner="0x83D4eB702690413a0A1E5819ECc48b62160dFb42" \
  --protocol-versions-owner="0x83D4eB702690413a0A1E5819ECc48b62160dFb42" \
  --guardian="0x83D4eB702690413a0A1E5819ECc48b62160dFb42" \
  --paused=true

Ran the following command to verify that contract bundle on sepolia:

go run ./cmd/op-deployer verify \
  --l1-rpc-url "xxx" \
  --etherscan-api-key xxx \
  --contract-bundle superchain

Contract addresses used for this test:

  "superchainDeployment": {
    "proxyAdminAddress": "0x9513783d80312af0e50f37849039738571d6b413",
    "superchainConfigProxyAddress": "0x96b69609c739e66a2be0803cd0e14037d0ea3bb7",
    "superchainConfigImplAddress": "0x77fa21851150a174d00addc5b2cd2f9321904474",
    "protocolVersionsProxyAddress": "0xed4278224700e847a24414fdea46dad6339b0252",
    "protocolVersionsImplAddress": "0x01206c8e4654faf1387c8eb334fa56723b1f791c"
  }

codecov · 2025-02-13T20:38:17Z

Codecov Report

Attention: Patch coverage is 0% with 17 lines in your changes missing coverage. Please review.

Project coverage is 90.56%. Comparing base (2e75688) to head (b9226fe).
Report is 65 commits behind head on develop.

Files with missing lines	Patch %	Lines
op-chain-ops/foundry/artifact.go	0.00%	17 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##           develop   #14359       +/-   ##
============================================
+ Coverage    46.45%   90.56%   +44.10%     
============================================
  Files         1032      117      -915     
  Lines        88560     5543    -83017     
============================================
- Hits         41143     5020    -36123     
+ Misses       44346      518    -43828     
+ Partials      3071        5     -3066

Flag	Coverage Δ
cannon-go-tests-32	`?`
cannon-go-tests-64	`?`
contracts-bedrock-tests	`94.58% <ø> (ø)`

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
op-chain-ops/foundry/artifact.go	`45.76% <0.00%> (-18.53%)`	⬇️

... and 918 files with indirect coverage changes

🚀 New features to boost your workflow:

❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

bitwiseguy · 2025-02-13T20:41:26Z

op-chain-ops/foundry/artifact.go

 	Settings struct {
 		// Remappings of the contract imports
-		Remappings json.RawMessage `json:"remappings"`
+		Remappings []string `json:"remappings"`


This change made it easier to construct the etherscan verification request

bitwiseguy · 2025-02-13T20:42:01Z

packages/contracts-bedrock/foundry.toml


 optimizer = true
 optimizer_runs = 999999
+use_literal_content = true


This forced just build to include the source code in the artifacts, which we need for contract verification

@mds1 is this an OK change to make?

It feels like a smell that we need to make this change, but it should be ok. An alternative is to create a [verify] profile here that adds this setting. If we keep this, we should add a comment explaining this so contract devs know why it's here

But we are already compiling the code with forge so should be able to just get the required info more easily. For example forge build --build-info --build-info-path cache generates a JSON file in the cache dir containing all build info including the source code, and forge verify-contract --show-standard-json-input spits out the standard JSON file that you can submit directly to etherscan

Are we strongly against shelling out to forge instead here? A few thoughts about this PR:

I worry that this is a lot of code to maintain and we are duplicating functionality that the foundry team has spent a lot of effort on to make robust, so this is likely to become flaky

We also need to basically duplicate etherscan.go for each block explorer we want to support, blockscout being the other main one. They do all have very similar APIs though so we can reuse a lot of code

Forge can infer constructor args based on the initcode it fetches from the block explorer, which is usually correct and avoids having to implement and maintain constructors.go

Are we strongly against shelling out to forge instead here?

I was attempting to preserve the "stand-alone binary without external dependencies" property of op-deployer. I don't feel strongly about that, but was trying to follow the existing pattern. Seems like there was a lot of effort put into implementing other forge functionality in go. Is there any difference in the forge verify-contract feature compared to the other forge features that are implemented in go, or are you more asking about the op-deployer design as a whole and why it doesn't shell out to forge in all cases?

Forge can infer constructor args based on the initcode it fetches from the block explorer, which is usually correct and avoids having to implement and maintain constructors.go

I imagine we can do the same in go and make constructors.go much simpler. I wasn't aware that constructor args could be derived that way, therefore I went with the existing complex solution. If we stick with a go implementation for contract verification, perhaps the entire constructors.go file could just be:

func inferConstructorArgs(deployedAddress common.Address, compiledBytecode string) (string, error) { // Get deployed bytecode from chain deployedCode, err := client.CodeAt(context.Background(), deployedAddress, nil) if err != nil { return "", err } // Remove "0x" prefix if present compiledBytecode = strings.TrimPrefix(compiledBytecode, "0x") deployedHex := hex.EncodeToString(deployedCode) // Find where compiled bytecode ends in deployed bytecode if !strings.Contains(deployedHex, compiledBytecode) { return "", fmt.Errorf("compiled bytecode not found in deployed bytecode") } // Extract constructor args (everything after the compiled bytecode) constructorArgs := strings.TrimPrefix(deployedHex, compiledBytecode) return constructorArgs, nil }

Is there any difference in the forge verify-contract feature compared to the other forge features that are implemented in go, or are you more asking about the op-deployer design as a whole and why it doesn't shell out to forge in all cases?

Just asking about the verify-contract feature, not op-deployer as a whole. The rationale here is that contract verification has been a pain point for foundry users for a long time (see how many foundry issues there are for unable to verify), so I worry that over time we will encounter similar issues if we try reimplementing verification. However if you have an approach that works, and we can simplify some of it as discussed in the below paragraph, then I'm ok starting with this approach to avoid needing forge as a dep, and we can always change if it ends up being problematic

Re constructors.go, it's a bit more complex than your snippet because you need to fetch the initcode (creation code) not the deployed code. You can see forge's implementation here, notably the part where they fetch creation code using this Get Contract Creator and Creation Tx Hash Etherscan API endpoint. (Fetching it yourself gets tricky because you have you have to binary search over all blocks then trace the transaction where it was deployed, so I recommend using the etherscan endpoint)

But yes we can definitely simplify constructors.go significantly using that approach!

@mds1 - I spoke with @mslipper yesterday. I am going to refactor this pr so that we shell out to forge verify-contract as you suggested instead of reimplementing that functionality in go (and having to deal with the continued maintenance for that feature). I will reach back out when the refactor is complete

Ok sounds great, thank you for the update!

bitwiseguy · 2025-02-15T02:03:22Z

op-deployer/pkg/deployer/verify/constructors.go

This is the most useful file to unit test. It will help us detect drift with the smart contract source code and the solidity function calls made here.

It would also be nice to detect updates in smart contract constructor args compared to what is expected here, but not sure how to do that yet. Perhaps when the contracts are deployed we store the encoded constructor args in the state.json file (could be a mapping of address --> string encoded args). That way we don't have to reconstruct the args during op-deployer verify runtime. Would make the verification less error-prone

op-chain-ops/foundry/artifact.go

op-deployer/pkg/deployer/flags.go

op-deployer/pkg/deployer/verify/artifacts.go

mslipper · 2025-02-16T22:18:12Z

op-deployer/pkg/deployer/verify/constructors.go

@@ -0,0 +1,323 @@
+package verify


Let's chat about this live next week. I see why you need to do this but it's a lot of complexity that I fear will become very brittle as the codebase evolves.

Yea agreed on the complexity and brittleness as downsides. See this comment for an alternative approach where we always store constructor args at the time the contract is deployed, and therefore don't have to regenerate them later. For that solution, I think we'd have to update the solidity scripts to return the constructor args for each contract as script outputs

mslipper · 2025-02-26T23:31:26Z

How we looking here @bitwiseguy?

bitwiseguy · 2025-03-05T19:39:18Z

Closing in favor of #14633

bitwiseguy requested review from a team as code owners February 13, 2025 20:38

bitwiseguy requested review from protolambda and skeletor-spaceman February 13, 2025 20:38

bitwiseguy commented Feb 13, 2025

View reviewed changes

bitwiseguy commented Feb 15, 2025

View reviewed changes

bitwiseguy force-pushed the ss/deployer-verify-contracts branch from 6caa487 to a67339c Compare February 15, 2025 16:35

mslipper reviewed Feb 16, 2025

View reviewed changes

op-chain-ops/foundry/artifact.go Show resolved Hide resolved

mslipper reviewed Feb 16, 2025

View reviewed changes

op-deployer/pkg/deployer/flags.go Outdated Show resolved Hide resolved

mslipper reviewed Feb 16, 2025

View reviewed changes

op-deployer/pkg/deployer/verify/artifacts.go Outdated Show resolved Hide resolved

mslipper reviewed Feb 16, 2025

View reviewed changes

bitwiseguy added 12 commits February 25, 2025 15:23

op-deployer: add 'verify' contracts command

8e0bbaa

fix rate limiter values

0db1736

verified SuperchainConfigImplAddress

a24f8fb

verified superchain bundle (including constructor support)

4821991

cleanup logs and flags

00e04e2

cleanup: remove unused code

8ca109e

verified implementations bundle

e232930

verified opchain bundle

9ee5079

update searchRemappings comment

40dbf87

use more type-safe structs

275b090

use l2-chain-id flag instead of l2-chain-index

c4d0c69

update to use new artifacts.Download function definition

b9226fe

bitwiseguy force-pushed the ss/deployer-verify-contracts branch from 6f7f3d0 to b9226fe Compare February 25, 2025 20:51

bitwiseguy closed this Mar 5, 2025

Conversation

bitwiseguy commented Feb 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Overview

Usage

Testing

Uh oh!

codecov bot commented Feb 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bitwiseguy Feb 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mds1 Feb 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bitwiseguy Feb 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bitwiseguy Feb 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mslipper commented Feb 26, 2025

Uh oh!

bitwiseguy commented Mar 5, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Comments

bitwiseguy commented Feb 13, 2025 •

edited

Loading

codecov bot commented Feb 13, 2025 •

edited

Loading

bitwiseguy Feb 17, 2025 •

edited

Loading

mds1 Feb 17, 2025 •

edited

Loading

bitwiseguy Feb 15, 2025 •

edited

Loading

bitwiseguy Feb 17, 2025 •

edited

Loading