The op-challenger on Beta Testnet Didn’t Call claimCredit in FaultDisputeGame

[qzhodl]

By comparing the transaction history of the FaultDisputeGame contract on the OP Mainnet and the Beta Testnet, there’s a noticeable difference in behavior:

OP Mainnet:
0x87eea4023f9e8487294a8bccf29f5fcfedf47195
On the mainnet, the op-challenger performed claimCredit calls at the end of the dispute process, successfully reclaiming the initial bond (0.08 ETH) from the game.
Example propose tx: 0x711fa1…

Beta Testnet:
0x65af74a36da43a43d58fe02492ff1a46cd7a8ab0
On the beta testnet, no claimCredit calls are made. One possible reason is that the initial bonds are set to zero, which would remove the incentive to call claimCredit at the end of the game. (Pending confirmation from @blockchaindevsh.)

Questions:

1. Should we also set non-zero initial bonds in our deployment to mitigate DoS risks when creating dispute games?
2. Does the op-deployer expose a configuration option for setting the initial bond amount?

[blockchaindevsh]

op-challenger will skip claiming if the credit is zero.(src)

The init bond can be configured by calling this method, yeah we need to set a reasonable bond for main net if we want to make FDG public.

The initial FDG is permissioned, we need to set it when upgrading to permission-less.

[qzhodl]

The init bond can be configured by calling this method, yeah we need to set a reasonable bond for main net if we want to make FDG public.

Yes, the initial bond can be set separately by calling setInitBond after the op-deployer deployment. However, my question is more general: are there any other manual configuration steps required after running op-deployer? For example, calling setInitBond.

Our original assumption was that op-deployer would handle all contract configuration automatically, but this doesn’t appear to be the case.

[blockchaindevsh]

No other steps are required before we upgrade the FDG to permission-less.

Initially the FDG is permissioned so it doesn't need init bond, only needs to set the init bond when upgrading it to permission-less.

Previously we upgraded the FDG following the steps here but it has changed in the latest code, e.g. "bootstrap disputegame" command is gone, I think we need to follow this step now.

[qzhodl]

No other steps are required before we upgrade the FDG to permission-less.

Initially the FDG is permissioned so it doesn't need init bond, only needs to set the init bond when upgrading it to permission-less.

Previously we upgraded the FDG following the steps here but it has changed in the latest code, e.g. "bootstrap disputegame" command is gone, I think we need to follow this step now.

Even in the permissioned FDG case, my understanding is that anyone can initiate a permissioned dispute game, but only whitelisted addresses are allowed to challenge it. If that’s correct, does the system still require initial bonds to be configured?

[blockchaindevsh]

It's true, but the pre-condition doesn't hold, only white listed can initiate a permissioned FDG:src.

[qzhodl]

Previously we upgraded the FDG following the steps here but it has changed in the latest code, e.g. "bootstrap disputegame" command is gone, I think we need to follow this step now.

So we may need to update the https://github.com/QuarkChain/pm/blob/main/L2/beta_testnet_fdg_upgrade.md doc?

[blockchaindevsh]

No need to update that doc since it's for beta testnet, but we do need to create one for the next network.

[qzhodl]

op-challenger will skip claiming if the credit is zero.(src)

I noticed that if the credit is 0, the claimCredit function is not called. However, if claimCredit isn’t invoked, then closeGame also won’t be triggered, meaning setAnchorState won’t be executed. In that case, wouldn’t it result in the AnchorStateRegistry never being updated?

Reference:

optimism/packages/contracts-bedrock/src/dispute/FaultDisputeGame.sol

Line 960 in 4508612

closeGame();

[blockchaindevsh]

Yeah the anchor state won't be updated, but it's fine as long as the game is resolved, the portal withdraw doesn't depend on the anchor state being updated now, I think it's kinda of decouple, as implied here.

[qzhodl]

Yeah the anchor state won't be updated, but it's fine as long as the game is resolved, the portal withdraw doesn't depend on the anchor state being updated now, I think it's kinda of decouple, as implied here.

Then what’s the purpose of setAnchorState? Does it imply that everything would still function correctly even if the anchor state is never updated?

[blockchaindevsh]

Looks like the anchor root is only used here, so setAnchorState only decides the dispute range of FDG.

Besides, the AnchorStateRegistry recently added a retirementTimestamp field, which can be used to discard old FDGs.