feat: add zk dispute game

[Joxess]

Description

This document introduces the design for integrating a ZK-based dispute game into the OP Stack as a first-class game type alongside the existing fault proof system. It defines the contract architecture, lifecycle, and OPCM integration needed to support single-round ZK proof disputes with full permissionless access, DelayedWETH bond management, and verifier agnosticism. The design builds on the existing OptimisticZkGame/OPSuccinctFaultDisputeGame contracts, aligning them with the OP Stack security model, enabling per-chain deployment through the MCP clone pattern and generalizing the verifier interface to support multiple zkVM backends.

This implements the ZK-based dispute game integration as a follow-up to #356

[ajsutton]

Looks good overall, just the change to avoid resolving as CHALLENGER_WINS if the parent is blacklisted/retired.

[wwared]

I'm concerned about removing the ROLLUP_CONFIG_HASH from the on-chain verifier, but it's very possible I'm missing some context on how this can be done safely

[wwared]

I believe the design already covers this case, but I wanted to call out a specific use case we want to support: eager finalization/resolution of games/state roots by submitting proofs for them. I know the design already supports submitting proofs for unchallenged roots, but I am not 100% sure about what the requirements on the state of the parents of this proof would be. The prover would need to submit proofs for any parent games in the parent chain that have not been resolved yet, correct? Do we have any estimate on how many proofs or how many blocks that might usually involve?

The case I am worrying about is that the prover might need to prove too many states to resolve the entire chain to get finality for the state they're actually interested in, so we might need to do some benchmarking and finetuning of the challenge period to ensure this use case remains viable for enabling on-demand speedier withdrawals without compromising security

[ajsutton]

I know the design already supports submitting proofs for unchallenged roots, but I am not 100% sure about what the requirements on the state of the parents of this proof would be. The prover would need to submit proofs for any parent games in the parent chain that have not been resolved yet, correct? Do we have any estimate on how many proofs or how many blocks that might usually involve?

Yes a proof would have to be provided for all parents that haven't already resolved. The use case for pre-emptive proofs isn't really that you'd prove a single game, it's that you would be continuously proving all proposals - effectively running a full ZK chain.

If you were trying to prove a single game, the number of blocks you'd need to prove would be equal to the number of blocks in the challenge period - after that point the parent games would already be resolvable.

[Joxess]

I've done the last major changes in the doc based on the discussions held since yesterday about the zk program and absolutePrestate definition, with a new section called "ZK Program Implications", cc: @pauldowman, @ajsutton, @wwared, @stevennevins

Looking forward to the design review!