Run monorepo test suite against state resulting from proposal

[mds1]

This is discussed in #140 (comment) through the use of forge-proposal-simulator (FPS). How to best do this needs some thought, and we should make sure our approach is forward compatible with batched upgrades (i.e. currently superchain-ops is focused on upgrading one task at a time but soon we will want to upgrade L1 contracts of many chains in 1 transaction—in that case we want to run the monorepo tests for each chain).

This is a big task, and likely will require changes both to this repo and the monorepo. We should check out how FPS does this, consider using that to avoid rolling our own solution, and may @ElliotFriedman will be kind enough to lend some time to help us out here :)

[ElliotFriedman]

This sounds like a perfect use case for FPS! I don't have context on how you guys structure your repositories or tests. Would you be able to summarize things here so I can make a recommendation on architecture?

[mds1]

Yes definitely! So I recall last time we chatted about this a tricky part was that the upgrade transactions are executed in this repo, but our test suite is in the monorepo (https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts-bedrock). However this repo does already have the monorepo as a dependency, so that might help

First, some background on the monorepo setup:

• The core test suite is a standard forge test suite. We also have a few kontrol proofs, and a few differential ffi tests to ensure go and solidity implementations match.
• We run all tests (including the go ffi tests) with just test, and the proofs are run with just test-kontrol.
• Only running just test would be be a great start and kontrol can be added later.

Now on this repo, superchain-ops

• "Tasks"are transactions to broadcast, like contract upgrade transactions or transactions that just change a config value. This is essentially the same as what Maker calls "spells"
• All tasks live in a directory of tasks/{L1-network}/{taskName}, and contain input.json bundles that define the transaction to be sent, along with a single solidity script that simulates the task based on that JSON bundle.
• Some tasks are "single" meaning it's a regular safe that needs to send the transaction, like the 5/7 Foundation Safe. Other tasks are "nested" meaning it's a 2/2 Safe that needs to send the transaction (where each signer on that 2/2 is a Safe, specifically the Foundation and the Security Council)
• The core logic to parse the bundle and simulate the transaction happens using the https://github.com/base-org/contracts/ dependency. We run the simulation in foundry within that dep, and have a postCheck hook that runs a bunch of assertions on the post-simulation state

I would say it's safe to consider most options on the table. Some examples I thought about:

• Does changing the shape of the input.json bundles help?
• Does replacing base-org/contracts with FPS help?
• Maker executes tests against their proposals like this, by basically defining a static test suite that always runs. This could also be an option for us, i.e. parameterize the key tests in the monorepo, that way we can import them here and run them