chore: Read Superchain genesis config from compressed files

[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)