feat(optimism): Add support for all Superchain configs and enable their usage

[cakevm]

Add functions to read Genesis JSON from a zip file, allowing large JSON files to be removed from the repository.

Requires to work: alloy-rs/alloy#2073 to read the ChainConfig from the toml files

Added BSL-1.0 license. See here for compatibility to MIT/Apache 2.0

@mattsse: Seeking for advice how to get rid of std:io

[mattsse]

@clabby @refcell

is there a use case for these static chainspecs in kona?

I guess it would depend how we proceed with #14571

we likely need to separate parts of the chainspec logic, like hardfork activations and maybe fee params not necessarily genesis

so we could feature gate these to std for now probably

[clabby]

@clabby @refcell

is there a use case for these static chainspecs in kona?

I guess it would depend how we proceed with #14571

we likely need to separate parts of the chainspec logic, like hardfork activations and maybe fee params not necessarily genesis

so we could feature gate these to std for now probably

Yeah, we could use them :D

fwiw, @refcell already has some rust bindings set up for the superchain-registry here. We use these bindings to pull in our RollupConfigs (think CL ChainSpec) from the upstream source of truth. It'd be awesome for us to saturate these ChainSpecs from that information. The genesis files over there are also all compressed w/ zstd.

[cakevm]

@mattsse This PR is ready for review. no-std is finally working. Here some remarks:

• This PR is a step forward in reading config and genesis from the Superchain registry files. I only did it for base for now, as I’d like to keep this PR lean and make it more generic in another PR.
• I could not find a reasonable way to handle ZIP, TOML, and ZSTD in no-std. For that reason, the config files are preprocessed and converted to JSON, and the compression method is changed.
• I added the superchain_registry module with the intention of potentially extracting it to Alloy later for others to use. This helps limit the exposed methods and assess what we actually need.
• I kept the "config:null" workaround until I get feedback from: Wish for clarification if "config" field in genesis files can be used ethereum-optimism/superchain-registry#901
• I remove the op chain specific json files from the other chainspec. I could not see any usage
• All genesis files are now in total 7,5MB. Compression methods like brotli gave better results. But I settled for more convenient to use miniz_oxide. This is something that could be improved in the future.

[cakevm]

Small update: Now setting fields (e.g., eip150_block: Some(0),) like op-geth instead of defaulting to None. I feel this makes comparisons easier. I skipped it before because I could not see the requirement.

If you serialize and compare genesis used in BASE_MAINNET and BASE_SEPOLIA, you will see new fields introduced by this PR. The rest is the same:

base-mainnet:

14442a14443,14444
>     "cancunTime": 1710374401,
>     "canyonTime": 1704992401,
14445a14448,14449
>     "deltaTime": 1708560000,
>     "ecotoneTime": 1710374401,
14448a14453,14454
>     "fjordTime": 1720627201,
>     "graniteTime": 1726070401,
14449a14456
>     "holoceneTime": 1736445601,
14456a14464
>       "eip1559DenominatorCanyon": 250,
14460a14469
>     "shanghaiTime": 1704992401,

base-sepolia:

15224a15225,15226
>     "cancunTime": 1708534800,
>     "canyonTime": 1699981200,
15227a15230,15231
>     "deltaTime": 1703203200,
>     "ecotoneTime": 1708534800,
15230a15235,15236
>     "fjordTime": 1716998400,
>     "graniteTime": 1723478400,
15231a15238
>     "holoceneTime": 1732633200,
15238a15246
>       "eip1559DenominatorCanyon": 250,
15242a15251
>     "shanghaiTime": 1699981200,

How to get this result: Checkout main, and this PR and serialize the genesis value. Then compare the results with:
diff <(jq --sort-keys . base_before.json) <(jq --sort-keys . base_after.json)

[cakevm]

@mattsse again ready for review

I have extended this PR to have the full implementation for Superchain configs making now all chains easier to use out-of-the-box.

Remarks:

• I believe overall performance can be improved by combining genesis and config into a single file and using a different compression method. However, for now, it looks reasonable.
• I generated the code in chainspec using a shell script. I thought this would save some build time instead of using build.rs. I tried to avoid it.
• For ChainMetadata, I left many unused fields. However, I felt it was better to keep it 1:1 with the original version. That said, I’m fine with stripping it down to only the necessary fields.
• I tested with base and unichain mainnet.
• I kept the original network options, such as base_sepolia, to avoid introducing breaking changes.

Since we learned from Holesky that misconfigured settings can cause significant issues, let's take some time to get this right.

[cakevm]

Just a quick remark, I tried to do a full fresh sync for unichain-mainnet and it is failing currently.

I am still investigating what is wrong here. I was able to sync to head before, and can not tell right now what has changed.

2025-03-04T11:38:30.239429Z ERROR Stage encountered an execution error: EVM reported invalid transaction (0x6b37cec971c7f9c17d2355d737ffc0531b540b08d818d9a7c74bbf87098e7f7c): deposit transaction halted post-regolith; error will be bubbled up to main return handler stage=Execution bad_block=760073
2025-03-04T11:38:30.239514Z  INFO Unwinding{stage=Finish}: Starting unwind from=500001 to=500001 bad_block=Some(760073)

Link to tx: https://unichain.blockscout.com/tx/0x6b37cec971c7f9c17d2355d737ffc0531b540b08d818d9a7c74bbf87098e7f7c

Update: Waiting for the fix with: bluealloy/revm#2144

[mattsse]

okay, I finally picked this up again.

I put this off for a while because dealing with chainspecs gives me headaches, especially if this changes the way we do this, so this change is critical.

therefor I'd like to make a few changes to this

• keep all ChainSpec static that we currently have, this way we can ensure that we don't accidentally break anything.

ideally we can also simplify the parsing and get rid of the additional types.

and we need some docs in the readme about how this all works.

[cakevm]

Find here some doc how it works

[cakevm]

Nevermind, checking the test. Base is now missing :D

[cakevm]

@mattsse Ready to review it again (lint is failing caused by the unrelated const fn stuff)

[mattsse]

very nice, sorry that this took so long.

I have a few ideas for followups here but for the initial integration this is great

[mattsse]

I think this solution is fine for this PR

we can make this a bit nicer if we change how the create_chain_spec! macro is invoked or by introducing our own:

https://github.com/paradigmxyz/reth/blob/main/crates/cli/cli/src/chainspec.rs#L54-L57

so that we need a massive list of supported chains, but I think this is actually fine:

Built-in chains:
dev, optimism, optimism_sepolia, optimism-sepolia, base, base_sepolia, base-sepolia, arena-z, arena-z-testnet-sepolia, automata, base-devnet-0-sepolia-dev-0, bob, boba-sepolia, creator-chain-testnet-sepolia, cyber, cyber-sepolia, ethernity, ethernity-sepolia, funki, funki-sepolia, hashkeychain, ink, ink-sepolia, lisk, lisk-sepolia, lyra, metal, metal-sepolia, mint, mode, mode-sepolia, oplabs-devnet-0-sepolia-dev-0, orderly, pivotal-sepolia, polynomial, race, race-sepolia, redstone, settlus-mainnet, settlus-sepolia-sepolia, shape, shape-sepolia, snax, soneium, soneium-minato-sepolia, sseed, swan, swell, tbn, tbn-sepolia, unichain, unichain-sepolia, worldchain, worldchain-sepolia, xterio-eth, zora, zora-sepolia