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.