OPCM Fix: Failure when addGameType due to common saltMixer (OPCM - Upgrade 13)

[maurelian]

Context: OPContractsManager.sol#L634

Description:

The function addGameType allows for multiple game types to be simultaneously deployed/upgraded. Additionally, the function allows for the delayedWETH address to be set to address(0), meaning the game type needs a new deployment of the DelayedWETH rather than an upgrade.

However, if two game types (for the same chain id) have their delayedWETH address set to zero, then a collision in the create2 address will prevent the second one from being deployed, reverting the entire transaction -- if the saltMixer parameter is the same, which is likely to happen, as these values are usually version tags.

Furthermore, the same saltMixer is used to deploy the game implementations, which breaks the invariant that the implementation version is typically used as entropy.

As seen in OPContractsManager.sol#L1125, the version is explicitly included in the salt calculation:

computeSalt(_l2ChainId, "v2.0.0", "PermissionedDisputeGame"),

Using the same saltMixer across different deployments violates this pattern and may lead to inconsistencies in contract versioning and deployment tracking.

Recommendation:

A different salt should be used for the delayedWETH for each game type -- or the deployment of a new proxy should be skipped if the create2 address already has code deployed to it.
Furthermore, a different salt variable should be used for deploying the game type implementation, rather than reusing the DelayedWETH salt.

Optimism:

Spearbit: