Add genesis files

[roninjin10]

Description

OP requires genesis files to be deployed from genesis. See OP devnet: https://github.com/ethereum-optimism/optimism/blob/develop/bedrock-devnet/devnet/__init__.py .

Tasks

• [ ] Add genesis files to repo

Approach

Copy paste in hardcoded files from .devnet (this is the approach I think I'm going with)

In the .devnet folder after running make devnet up there are json files. I believe we could simply just copy an instance of these files in. Then using the embed package we can load them into the appropriate structs.

Alternative approaches

Same way devnet does it (don't like this approach)

We could just call the same code the devnet is calling

func generateL1Genesis(deployConfigPath, l1AllocsPath, l1DeploymentsPath, outfile string) error {
    ctx := cli.NewContext(nil, &cli.FlagSet{}, nil)
    ctx.Set("deploy-config", deployConfigPath)
    ctx.Set("l1-allocs", l1AllocsPath)
    ctx.Set("l1-deployments", l1DeploymentsPath)
    ctx.Set("outfile.l1", outfile)

    // Call the L1 genesis action directly
    return genesis.Subcommands[0].Action(ctx)
}

Naively trying to run this code threw a lot of errors and in general this way feels a bit hacky so I abandoned the approach right away. I'm uncertain if this approach will work well given mocktimism is currently not in the optimism repo and the current devnet uses foundry to deploy the contracts not golang.

Copy paste in hardcoded files from .devnet (this is the approach I think I'm going with)

In the .devnet folder after running make devnet up there are json files. I believe we could simply just copy an instance of these files in. Then using the embed package we can load them into the appropriate structs.

Generate using op-chain-ops (This might possibly be the correct approach)

To get a genesis file we simply need the DeployConfig struct. We could fill in this struct with hardcoded values and then pass this into BuildL1DeveloperGenesis. This seems to be the main way the OP repo does it

Related consideration - Contract deployments

Contract deployments. Currently mocktimism is built for anvil so we have foundry as a dependency. We could deploy the contracts with foundry like the devnet does. In general this feels unecessary. I think just deploying the artifacts using the generated op-bindings code makes a lot more sense

[roninjin10]

mark 21 minutes ago I think dynamic gen using existing codepaths will make breaking changes/newly added smart contracts just work

Will 18 minutes ago Tyty this is exactly why I wanted to make sure I ran this by ya'll. What's the best entrypoint for existing code paths? My intuition is it's not the op-node cli (which the python script calls) but instead it's actually the BuildL1DeveloperGenesis and the l2 equivelent in op-chain-ops

Will 13 minutes ago Best way to deploy the contracts is another open question. My plan was to use op-bindings. But the more DRY way of doing it I think would be to use our foundry scripts. The big downside of using foundry scripts though is we ultimately want to distribute this as a single binary so using the foundry scripts in that context I believe will require some hacks such as copying contracts-bedrock into a temp directory (which might be ok)

mark 10 minutes ago The opnode just wraps those functions New

mark 9 minutes ago I believe there are ways to load state into anvil via rpc :true: 1

mark 8 minutes ago If we spit out the genesis json dynamically then loaded it via rpc, could that work well?

Will 6 minutes ago Yea there are in fact a thing we are implementing is the ability to dump the entire state and load the state of all chains spun up in the devnet. So I could generate genesis put it in the same place this feature would be putting the files and then once the files are there use the same code paths to load the genesis state that the state dump state loading code would be using.

Will 4 minutes ago Looking at the deploy scripts I am actually leaning more towards I'm gonna have to find a way to reuse these even if it's a bit hacky. It seems not good to maintain a seperate way of deploying the contracts

Will 3 minutes ago Actually a way of not making this not hacky is instead generating the genesis state including the l1 contracts in the build of mocktimism instead of at runtime (edited)

Will 1 minute ago ^I really really really like this way of doing it. Once I move mocktimism into the monorepo this makes it so I can 100% reuse existing code and for now I can just add OP as a submodule