Support multiple l2s based on a single forking token / ForkingManager

[edmundedgar]

Our current system assumes that there's a single L2, and does the forking of the L2 inside the ForkingManager.

Functionally it doesn't need to be this way as the escalation game leading up to the forking is done on L1. If these were unbundled you could potentially make a different L2 sharing the same token and forking at the same time. This would also work better if we did Eigenlayer integration etc.

Specific changes to make this work:

• Break the code that forks the L2 out of the ForkingManager
• Make sure we can handle the fact that the forking of the L2 is no longer done atomically at the same time as the forking of the token. (This should be OK as we know in advance what the forking timestamp is and we have a delay before forking, but it creates some extra code paths)

[josojo]

what the benefit of forking a second L2 at the same, rather than building all the applications from the two L2s on one L2?

• probably enabling different sequencer behaviours?

[edmundedgar]

Right, potentially different sequencer behaviours. Also there may just be better rollup systems altogether, or better for some purposes. There are a bunch of things where we thought "this could be an L3", but those cases could be their own L2s but share the same universe of simultaneous forking.

We could also potentially do the releases differently, eg maybe we first release an L1 forkable token on its own that will work as an arbitrator for reality.eth questions etc if you're prepared to either use it as your token or use it for governance with eigenlayer-style insurance, then ship the mainnet L2 a bit later.

[m13v]

the part that breaks down once you unbundle token forking from L2 forking isn't the extra code paths, it's the window between them. any L1 action that lands between token-fork and L2-fork has to be safe on both sides, including any cross-domain messaging to the eventual L2s. multichain governance has the same shape: you cannot atomically commit a vote across chains, so the gap gets treated as a known unsafe window and execution is gated until things settle. the code paths are easy. defining the invariants that hold across the gap is the actual work, and the restaking-integration case makes it worse because operator sets can shift inside that window too.