protocol: forge scripts deploy in Go

[protolambda]

Description

This introduces the idea of running the Forge scripts, primarily the chain deployment / genesis setup scripts, in Go.
This improves the integration with Go tooling and tests, to unlock the customization we need for things like Interop, and to generally improve test coverage of our deployments.

Metadata

Fix ethereum-optimism/optimism#11360

[sbvegan]

Good call out here, for example, a recent partner was having trouble using the solidity genesis allocs creation on the op-contracts/v1.3.0 release so they opted for something ~200 commits into the future that played nicely with the tooling instead of using the legacy genesis creation method.

With that being called out, if this lands after a L1 contract release, it would be nice to have this type of functionality cut in a different minor release so its accessible for new chain deployments between say op-contracts/v1.6.0 and op-contracts/v1.7.0.

[sbvegan]

The modular deploy configuration will be nice improvement, especially for our beta features (CGT and Alt-DA Mode). Similar to my comment above, it would be nice to have this worked into the CGT contract releases.

[sbvegan]

I'm very excited for any contract deployment quality of life improvements. Beyond my initial comments, I'm going to work on collecting additional customer contract deployment pain in this notion document. I'll reach out to developer support who may have additional insight.

[tynes]

I have slight concern about possible bugs in the foundry Go precompile implementation resulting in e2e tests not running against "the same" contracts. I suppose the precompile isn't super complex, but adding layers of abstraction does make me feel worried

[tynes]

Are you proposing that this is used outside of testing, ie for L2 genesis generation?

[tynes]

I see in the follow up section this is mentioned

[tynes]

I think that this could be a good approach although I would need more convincing to think its a good idea to use this for anything other than testing. I would much rather contribute features directly to foundry that help make our deployments better rather than us building tooling that subsumes foundry

[mds1]

Aside from implementation risk, another risk is the subset used by OP Stack scripts will continue to grow, and I worry contract devs might want to use a new cheat, but then PRs get blocked by needing go support for that cheat.

Ultimately, is the resulting state from a script what the go tests need? If so, I think it will be a lot simpler to call the forge script from go, with a way conditionally call vm.dumpState at the end. Go can then read in the resulting file that was written and apply that state. This is effectively what kontrol does to initialize proofs so it doesn't need to execute the EVM/cheats

If we don't want to use the filesystem as an interface, forge has a --json arg to output JSON to stdout. We can probably get a forge script --json --dumpstate feature added so that it automatically dumps state to the JSON as part of stdout

[mds1]

Great idea

[protolambda]

Summary of design-review call:

The primary concern is if whether or not we can use forge script as-is to serve tooling and op-e2e.

Arguments for:

• Ideal to upstream changes to forge, if we can identify something that unlocks integration with Go
• Can be implemented (with caching to mitigate performance problems) as in deployment-chains: Idea to resolve deployment composition and customization #52
• Forge cheatcodes all work out of the box

Arguments against:

• Need for well-defined inputs/outputs
  • The more we side-channel data through files, the more the Go integration has to prepare and manage edge-cases of (caches, missing data, IO errors, etc.).
  • Difficult to bundle Go L2 genesis generation and Forge L2 genesis generation, do to multi-step process and intermediate files. Hurts devrel experience.
• Performance concerns
  • Intermediate disk access
  • Encoding the configs in JSON (or toml), split between 32 byte leafs, reconstructing them multiple times, JSON parsing again, etc.
  • Multiple state dumps / loads per test setup.
  • FFI calls to forge processes (and forge versioning etc. affecting tests)
• No cache-invalidation complexity

And L1 deployments can be unified by making a broadcast a no-op in the Go context, so we can run the same deploy functions, but generate state in-place.

There is some hesitation, but we can try the Go forge-script approach, and fall back to the other approach if the Go approach does not work.