feat(contracts): implement OPSuccinctPermissionedFaultDisputeGame

[fakedev9999]

The OPSuccinctPermissionedFaultDisputeGame is a specialized child contract of the OPSuccinctFaultDisputeGame that implements role-based access control to restrict who can participate in the game. This contract can serve as a fallback in cases where a permissionless system is undesirable or if the existing permissionless system encounters issues.

Overview

In a typical fault proof system, multiple entities may freely propose and challenge state roots in order to reach consensus. However, permissionless designs can introduce complexity and costs that some networks might prefer to avoid. By contrast, the OPSuccinctPermissionedFaultDisputeGame restricts participation via two new roles: a Proposer and a Challenger.

Each relevant interaction—including prove, challenge, resolve—is accessible only to addresses that have been granted one of these roles. Furthermore, the initialize() function is exclusively reserved for the Proposer.

In the event that you wish to switch back to a permissionless approach, the RESPECTED_GAME_TYPE parameter in the OptimismPortal can be changed to switch back.

Optimism's implementation

See PermissionedDisputeGame.sol

[github-actions]

Metric	Value
Batch Start	23,462,730
Batch End	23,462,735
Witness Generation (seconds)	0
Execution Duration (seconds)	54
Total Instruction Count	2,513,717,967
Oracle Verify Cycles	384,152,718
Derivation Cycles	1,279,369,030
Block Execution Cycles	743,490,333
Blob Verification Cycles	179,282,718
Total SP1 Gas	0
Number of Blocks	5
Number of Transactions	54
Ethereum Gas Used	32,624,072
Cycles per Block	502,743,593
Cycles per Transaction	46,550,332
Transactions per Block	10
Gas Used per Block	6,524,814
Gas Used per Transaction	604,149
BN Pair Cycles	0
BN Add Cycles	0
BN Mul Cycles	0
KZG Eval Cycles	0
EC Recover Cycles	462,314
P256 Verify Cycles	0

[ratankaliani]

One concern I have with this design is that in most practical settings to reach Stage 1, you want to have multiple challengers and proposers.

Do you think it's better to have a pass-through contract where games can be created where this logic can be validated?

Or do you want to allow passing arrays for both of these arguments?

My worry with this design is that it's not easily extensible.

[fakedev9999]

@ratankaliani made a very good point #370 (comment)

But in CWIA pattern, we can't have immutable args with types of array or mapping.
One alternative is to have a separate "Access Manager" contract and add another immutable arg ACCESS_MANAGER_ADDRESS to the constructor of the game contract and do the clone and initalize pattern.

However, it seems better to have an entrypoint contract that wraps over the Factory since:

• it's easily extensible for permissioned games (we don't need to have a separate contract for permission control, but just an array or a mapping)
• we can easily add the "Bank" contract feature at the same time without having a separate WETH kind of contract.