Add Readme

mainnet/2024-03-07-ecotone-sysconfig-updates/.env

@@ -26,5 +26,3 @@ SCALAR=4523128485832663883733241601901871400518358776001584532791339993386251780
 # v1 hex encoding  : 0x01000000000000000000000000000000000000000000000000000000000a31c2
 # uint value for the 'scalar' parameter in SystemConfigProxy.setGasConfig():
 FALLBACK_SCALAR=452312848583266388373324160190187140051835877600158453279131187530911330754
-
-SIGNATURES=

mainnet/2024-03-07-ecotone-sysconfig-updates/README.md

@@ -0,0 +1,303 @@
+# Update Gas Config in L1 `SystemConfig` 
+
+Status: IN TEST
+
+## Objective
+
+Along with the Ecotone hardfork, we need to make changes to the Gas Config in the L1 `SystemConfig` contract. Specifically, we need to set the `_overhead` and `_scalar` values by calling `setGasConfig`. This is an access-controlled method that only the Incident Multisig can call.
+
+This runbook implements scripts to allow our signers to sign two different calls for our Incident Multisig: 
+1. `UpdateGasConfig` -- This script will update the values according to our expected happy path wherein we are actively using Blobs
+2. `RollbackGasConfig` -- This script establishes a rollback call in the case we need to revert to using calldata 
+
+The values we are sending are statically defined in the `.env` file but were generated by running this [script](https://github.com/ethereum-optimism/optimism/tree/4b7627cbb94a75e478a34f33f91121ef6ae794b3/op-chain-ops/cmd/ecotone-scalar) against the values derived from this [comment](https://github.com/ethereum-optimism/protocol-quest/issues/84#issuecomment-1971880164) by @K-Ho.
+
+## Approving the Update transaction
+
+### 1. Update repo and move to the appropriate folder:
+```
+cd contract-deployments
+git pull
+cd mainnet/2024-03-07-ecotome-sysconfig-updates
+make deps
+```
+
+### 2. Setup Ledger
+
+Your Ledger needs to be connected and unlocked. The Ethereum
+application needs to be opened on Ledger with the message "Application
+is ready".
+
+### 3. Simulate and validate the transaction
+
+Make sure your ledger is still unlocked and run the following.
+
+``` shell
+make sign-update-gas-config
+```
+
+Note: there have been reports of some folks seeing this error `Error creating signer: error opening ledger: hidapi: failed to open device`. A fix is in progress, but not yet merged. If you come across this, open a new terminal and run the following to resolve the issue:
+```
+git clone [email protected]:base-org/eip712sign.git
+cd eip712sign
+go install
+```
+
+Once you run the make sign command successfully, you will see a "Simulation link" from the output.
+
+Paste this URL in your browser. A prompt may ask you to choose a
+project, any project will do. You can create one if necessary.
+
+Click "Simulate Transaction".
+
+We will be performing 3 validations and then we'll extract the domain hash and
+message hash to approve on your Ledger then verify completion:
+
+1. Validate integrity of the simulation.
+2. Validate correctness of the state diff.
+3. Validate and extract domain hash and message hash to approve.
+4. Validate that the transaction completed successfully
+
+
+#### 3.1. Validate integrity of the simulation.
+
+Make sure you are on the "Overview" tab of the tenderly simulation, to
+validate integrity of the simulation, we need to check the following:
+
+1. "Network": Check the network is Ethereum Mainnet.
+2. "Timestamp": Check the simulation is performed on a block with a
+   recent timestamp (i.e. close to when you run the script).
+3. "Sender": Check the address shown is your signer account. If not,
+   you will need to determine which “number” it is in the list of
+   addresses on your ledger.
+4. "Success" with a green check mark 
+
+
+#### 3.2. Validate correctness of the state diff.
+
+Now click on the "State" tab. Verify that:
+
+1. Verify that the nonce is incremented for the Incident Multisig under the "GnosisSafeProxy" at address `0x0a7361e734cf3f0394b0fc4a45c74e7a4ec70940`:
+
+```
+Key: 0x0000000000000000000000000000000000000000000000000000000000000005
+Before: 0x0000000000000000000000000000000000000000000000000000000000000009
+After: 0x000000000000000000000000000000000000000000000000000000000000000a
+```
+
+2. Verify that gas config values are appropriately updated under "Proxy" at address `0x73a79fab69143498ed3712e519a88a918e1f4072`:
+
+```
+Key: 0x0000000000000000000000000000000000000000000000000000000000000065
+Before: 0x00000000000000000000000000000000000000000000000000000000000000bc
+After: 0x0000000000000000000000000000000000000000000000000000000000000000
+
+Key: 0x0000000000000000000000000000000000000000000000000000000000000066
+Before: 0x00000000000000000000000000000000000000000000000000000000000a6fe0
+After: 0x0100000000000000000000000000000000000000000000000009fd53000019cf
+```
+
+#### 3.3. Extract the domain hash and the message hash to approve.
+
+Now that we have verified the transaction performs the right
+operation, we need to extract the domain hash and the message hash to
+approve.
+
+Go back to the "Overview" tab, and find the
+`GnosisSafe.checkSignatures` call. This call's `data` parameter
+contains both the domain hash and the message hash that will show up
+in your Ledger.
+
+Here is an example screenshot. Note that the value will be
+different for each signer:
+
+// ADD SCREENSHOT HERE 
+
+It will be a concatenation of `0x1901`, the domain hash, and the
+message hash: `0x1901[domain hash][message hash]`.
+
+Note down this value. You will need to compare it with the ones
+displayed on the Ledger screen at signing.
+
+### 4. Approve the signature on your ledger
+
+Once the validations are done, it's time to actually sign the
+transaction. Make sure your ledger is still unlocked and run the
+following:
+
+``` shell
+make sign-update-gas-config
+```
+
+> [!IMPORTANT] This is the most security critical part of the
+> playbook: make sure the domain hash and message hash in the
+> following two places match:
+
+1. on your Ledger screen.
+2. in the Tenderly simulation. You should use the same Tenderly
+   simulation as the one you used to verify the state diffs, instead
+   of opening the new one printed in the console.
+
+There is no need to verify anything printed in the console. There is
+no need to open the new Tenderly simulation link either.
+
+After verification, sign the transaction. You will see the `Data`,
+`Signer` and `Signature` printed in the console. Format should be
+something like this:
+
+```
+Data:  <DATA>
+Signer: <ADDRESS>
+Signature: <SIGNATURE>
+```
+
+Double check the signer address is the right one.
+
+### 5. Send the output to Facilitator(s)
+
+Nothing has occurred onchain - these are offchain signatures which
+will be collected by Facilitators for execution. Execution can occur
+by anyone once a threshold of signatures are collected, so a
+Facilitator will do the final execution for convenience.
+
+Share the `Data`, `Signer` and `Signature` with the Facilitator, and
+congrats, you are done!
+
+
+## Approving the Rollback transaction
+
+Complete the above steps for `Approving the Update transaction` before continuing below.
+
+### 1. Simulate and validate the transaction
+
+Make sure your ledger is still unlocked and run the following.
+``` shell
+make sign-rollback-gas-config
+```
+Once you run the make sign command successfully, you will see a "Simulation link" from the output. Once again paste this URL in your browser and click "Simulate Transaction".
+
+We will be performing 3 validations and then we'll extract the domain hash and
+message hash to approve on your Ledger then verify completion:
+
+1. Validate integrity of the simulation.
+2. Validate correctness of the state diff.
+3. Validate and extract domain hash and message hash to approve.
+4. Validate that the transaction completed successfully
+
+
+#### 3.1. Validate integrity of the simulation.
+
+Make sure you are on the "Overview" tab of the tenderly simulation, to
+validate integrity of the simulation, we need to check the following:
+
+1. "Network": Check the network is Ethereum Mainnet.
+2. "Timestamp": Check the simulation is performed on a block with a
+   recent timestamp (i.e. close to when you run the script).
+3. "Sender": Check the address shown is your signer account. If not,
+   you will need to determine which “number” it is in the list of
+   addresses on your ledger.
+4. "Success" with a green check mark 
+
+
+#### 3.2. Validate correctness of the state diff.
+
+Now click on the "State" tab. Verify that:
+
+1. Verify that the nonce is incremented for the Incident Multisig under the "GnosisSafeProxy" at address `0x0a7361e734cf3f0394b0fc4a45c74e7a4ec70940`:
+
+```
+Key: 0x0000000000000000000000000000000000000000000000000000000000000005
+Before: 0x000000000000000000000000000000000000000000000000000000000000000a
+After: 0x000000000000000000000000000000000000000000000000000000000000000b
+```
+
+2. Verify that gas config values are appropriately updated under "Proxy" at address `0x73a79fab69143498ed3712e519a88a918e1f4072`:
+
+```
+Key: 0x0000000000000000000000000000000000000000000000000000000000000065
+Before: 0x00000000000000000000000000000000000000000000000000000000000000bc
+After: 0x0000000000000000000000000000000000000000000000000000000000000000
+
+Key: 0x0000000000000000000000000000000000000000000000000000000000000066
+Before: 0x00000000000000000000000000000000000000000000000000000000000a6fe0
+After: 0x01000000000000000000000000000000000000000000000000000000000a31c2
+```
+
+#### 3.3. Extract the domain hash and the message hash to approve.
+
+Now that we have verified the transaction performs the right
+operation, we need to extract the domain hash and the message hash to
+approve.
+
+Go back to the "Overview" tab, and find the
+`GnosisSafe.checkSignatures` call. This call's `data` parameter
+contains both the domain hash and the message hash that will show up
+in your Ledger.
+
+Here is an example screenshot. Note that the value will be
+different for each signer:
+
+// ADD SCREENSHOT HERE 
+
+It will be a concatenation of `0x1901`, the domain hash, and the
+message hash: `0x1901[domain hash][message hash]`.
+
+Note down this value. You will need to compare it with the ones
+displayed on the Ledger screen at signing.
+
+### 4. Approve the signature on your ledger
+
+Once the validations are done, it's time to actually sign the
+transaction. Make sure your ledger is still unlocked and run the
+following:
+
+``` shell
+make sign-rollback-gas-config
+```
+
+> [!IMPORTANT] This is the most security critical part of the
+> playbook: make sure the domain hash and message hash in the
+> following two places match:
+
+1. on your Ledger screen.
+2. in the Tenderly simulation. You should use the same Tenderly
+   simulation as the one you used to verify the state diffs, instead
+   of opening the new one printed in the console.
+
+There is no need to verify anything printed in the console. There is
+no need to open the new Tenderly simulation link either.
+
+After verification, sign the transaction. You will see the `Data`,
+`Signer` and `Signature` printed in the console. Format should be
+something like this:
+
+```
+Data:  <DATA>
+Signer: <ADDRESS>
+Signature: <SIGNATURE>
+```
+
+Double check the signer address is the right one.
+
+### 5. Send the output to Facilitator(s)
+
+Nothing has occurred onchain - these are offchain signatures which
+will be collected by Facilitators for execution. Execution can occur
+by anyone once a threshold of signatures are collected, so a
+Facilitator will do the final execution for convenience.
+
+Share the `Data`, `Signer` and `Signature` with the Facilitator, and
+congrats, you are done!
+
+> [!WARNING]  
+> ONLY PROCEED IF WE MUST FALLBACK TO CALLDATA
+
+## Execute the output
+
+1. Collect outputs from all participating signers.
+2. Concatenate all signatures and export it as the `SIGNATURES`
+   environment variable, i.e. `export
+   SIGNATURES="0x[SIGNATURE1][SIGNATURE2]..."`.
+3. Run `make approve-rollback-gas-config`
+4. Run `make execute-rollback` to execute the transaction onchain.
+