op-contracts: Add script to upgrade from 1.8.0 L2OO to 1.8.0 permissioned.

[ajsutton]

Description

Adds an upgrade package to transition from 1.8.0 in L2OO configuration to 1.8.0 in permissioned configuration. This is based on the 1.3.0->1.6.0-permissioned docker image with minor changes to handle deploying the correct version of contracts like AnchorStateRegistry which was not released as part of 1.8.0, so needs to be deployed via a blueprint of the 1.6.0 implementation.

A runbook using this is added in ethereum-optimism/superchain-ops#393

Metadata

Part of #12990

[ajsutton]

Simulated execution of upgrade on sepolia devnet: https://dashboard.tenderly.co/public/safe/safe-apps/simulator/682a6103-b284-427b-8b80-a4ba29f02f75/state-diff
It's not a particularly realistic case as it's already running permissionless proofs but useful to check things. There's an unexpected change in SystemConfig though with key 0x0000000000000000000000000000000000000000000000000000000000000066 being zeroed. That's the scalar which is complicated by an unreleased Ecotone change to the contracts which is now shipping with Holocene. I'm guessing the upgrade didn't reinitialise SystemConfig and it's not possible anymore to reinitialise it without changing the scalar. It may be better to not try and reinitialise since we're making the changes we need via StorageSetter anyway.

[Inphi]

The DeployUpgrade script looks good to me.

Could you add a README explaining how to use the upgrade scripts.

[tynes]

This is where the bug is. I believe that you need to call scalar() and then assert its on version 1 (most significant byte is 0x01) then decode it with the inverse of

optimism/packages/contracts-bedrock/src/L1/SystemConfig.sol

Line 406 in 34d5f66

scalar = (uint256(0x01) << 248) | (uint256(_blobbasefeeScalar) << 32) | _basefeeScalar;

The logic is also here for decoding

[tynes]

$ cast call 0xa6b72407e2dc9EBF84b839B69A24C88929cf20F7 "basefeeScalar()"
0x0000000000000000000000000000000000000000000000000000000000000000

Can confirm it does return 0

$ cast call 0xa6b72407e2dc9EBF84b839B69A24C88929cf20F7 "scalar()"
0x010000000000000000000000000000000000000000000000000d273000001db0

this does not return 0, this is the scalar value

[tynes]

This is a consistency problem due to new storage slots being introduced for the basefee scalar rather than it being a function that modifies the single source of truth of the scalar

see:

optimism/packages/contracts-bedrock/src/L1/SystemConfig.sol

Lines 403 to 404 in 34d5f66

	basefeeScalar = _basefeeScalar;
	blobbasefeeScalar = _blobbasefeeScalar;

This probably should have been implemented in a way that didn't add new storage slots to prevent this consistency issue

[ajsutton]

I've removed the re-initialization of SystemConfig from this task as it assumes that the chain is already running op-contracts/v1.8.0 and the StorageSetter is already being used to zero out the L2OO address and set the DisputeGameFactory address so the initialisation would be a no-op apart from this scalar issue.

How to handle the scalar is being tracked in ethereum-optimism/superchain-ops#394 but that is part of the upgrade to op-contracts/v1.8.0 and this runbook is starting from already running 1.8.0 (just in L2OO config but the SystemConfig should already have been upgraded).

[ajsutton]

We'll need to update this link one the runbook is merged.