-
Notifications
You must be signed in to change notification settings - Fork 829
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
params: source chainConfig and genesis from superchain-registry #113
Conversation
e4f45a0
to
7fc5a31
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good generally. I haven't looked over the super chain repo code yet but will do that next.
Co-authored-by: Adrian Sutton <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes lgtm. The statehash thing is interesting & probably make a big difference for mainnet.
Description
To make OP-Stack chain configurations available across OP-Stack client implementations, we are experimenting with a "superchain-registry": one place that hosts all superchain configurations, which can then be embedded into the software for convenience & OP-Stack wide rollout of config changes.
These config utils are optional functionality (
geth init
with a custom genesis setup will always work, chains can be registered after launch at any time), but aims to increase convenience of running a node.Using the registry data, a
core.Genesis
can be created from the embedded block-contents and genesis-allocation. This depends on tooling to build the genesis-allocation from a list of contract-references + contract bytecode registry: we need to deduplicate the many predeploy proxies, and deduplicate contracts between OP-Stack chains, to make embedding of the genesis-data sustainable while the number of OP-Stack chains in the Superchain grows.This also provides a new CLI option:
--beta.op-network=...
: to choose the network configuration. Alternative ways to configure/load a chain are still fully supported. Geth does not have a--network=name
flag like many consensus-layer clients do, and adding new flags for each network is not sustainable. Thus the choice for a CLI flag that picks an OP-Stack network. This a beta feautre, and may be changed or removed at a later point, since the superchain-registry is a work-in-progress that has not been approved yet by Optimism Governance.Note about OP-Mainnet and OP-Goerli legacy: these two networks currently rely on a datadir to run post-bedrock. Building the chain-config is useful for
op-program
, but the genesis is not, yet (!). With the recent introduction of snap-sync, we can re-introduce the OP-Mainnet/Goerli genesis setup, and utilize snap-sync to fetch the state (instead of requiring a datadir!) and skip pre-bedrock block verification (other than data-consistency checks like the header hash-chain).Metadata
Fix CLI-4208