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

superchain: write all hardforks, SuperchainConfig address to config .tomls #810

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

bitwiseguy
Copy link
Collaborator

@bitwiseguy bitwiseguy commented Dec 19, 2024

Overview

To automate the SuperchainConfig address addition to each chain config file, I temporarily added the following code to /ops/cmd/update-configs.go:

rpcEndpoint := superchain.Superchains[chain.Superchain].Config.L1.PublicRPC
if rpcEndpoint == "" {
	panic("l1 PublicRPC missing")
}

address, err := validation.CastCall(superchain.Addresses[chain.ChainID].OptimismPortalProxy, "superchainConfig()(address)", nil, rpcEndpoint)
if err != nil {
	fmt.Printf("cast error, chainID: %d, chainName: %s\n", chain.ChainID, chain.Name)
	continue
}
fmt.Printf("cast result: %s, chainID: %d\n", address, chain.ChainID)
chain.Addresses.SuperchainConfig = superchain.MustHexToAddress(address[0])

Then I ran the following command, which was already in place to populate the hardfork timestamps in each chain config .toml:

go run ./ops update-configs

This same command can be run anytime we introduce a new hardfork activation timestamp in one of the superchain.toml files and want to write that value to config files for chains that have opted-in to inherit that timestamp (i.e. chains that have set superchain_time in their chain config .toml).

Metadata

@bitwiseguy bitwiseguy requested a review from a team as a code owner December 19, 2024 20:26
@bitwiseguy
Copy link
Collaborator Author

bitwiseguy commented Dec 19, 2024

A few open questions:

  1. Orderly and Lyra have old versions of OptimismPortalProxy and I was not able to read the SuperchainConfig address from that contract. Should I assume that the superchain_config_addr in the superchain.toml file is the correct one to use for those chains? Or is there another way to find the address that is set? Or is it possible they're not using a SuperchainConfig at all and the address should remain absent in their chain configs?
  2. Should the protocol_versions_addr and op_contracts_manager_proxy_addr that are in the superchain.toml file also be written to each chain config .toml file or should they be treated differently than superchain_config_addr?

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