Add Fault Proof upgrade template directory (#269)

* set up fault proof upgrade scripts

* update readme

* fix comments and nits

* add upgrade fault proof contracts template

* rename setup-hardfork -> setup-upgrade-fault-proofs

Makefile

@@ -2,10 +2,12 @@ PROJECT_DIR = $(network)/$(shell date +'%Y-%m-%d')-$(task)
 DEPLOY_DIR = $(network)/$(shell date +'%Y-%m-%d')-deploy
 INCIDENT_DIR = $(network)/$(shell date +'%Y-%m-%d')-$(incident)
 GAS_INCREASE_DIR = $(network)/$(shell date +'%Y-%m-%d')-increase-gas-limit
+FAULT_PROOF_UPGRADE_DIR = $(network)/$(shell date +'%Y-%m-%d')-upgrade-fault-proofs
 TEMPLATE_GENERIC = setup-templates/template-generic
 TEMPLATE_DEPLOY = setup-templates/template-deploy
 TEMPLATE_INCIDENT = setup-templates/template-incident
 TEMPLATE_GAS_INCREASE = setup-templates/template-gas-increase
+TEMPLATE_UPGRADE_FAULT_PROOFS = setup-templates/template-upgrade-fault-proofs
 
 ifndef $(GOPATH)
     GOPATH=$(shell go env GOPATH)
@@ -40,6 +42,10 @@ setup-gas-increase:
 	rm -rf $(TEMPLATE_GAS_INCREASE)/cache $(TEMPLATE_GAS_INCREASE)/lib $(TEMPLATE_GAS_INCREASE)/out
 	cp -r $(TEMPLATE_GAS_INCREASE) $(GAS_INCREASE_DIR)
 
+# Run `make setup-upgrade-fault-proofs network=<network>`
+setup-upgrade-fault-proofs:
+	cp -r $(TEMPLATE_UPGRADE_FAULT_PROOFS) $(FAULT_PROOF_UPGRADE_DIR)
+
 ##
 # Solidity Setup
 ##

README.md

@@ -38,6 +38,7 @@ To execute a new task, run one of the following commands (depending on the type
 - For incident response commands: `make setup-incident network=<network> incident=<incident-name>`
 - For gas increase commands: `make setup-gas-increase network=<network>`
 - For full new deployment (of L1 contracts related to Base): `make setup-deploy network=<network>`
+- For fault proof upgrade: `make setup-upgrade-fault-proofs network=<network>`
 - For contract calls, upgrades, or one-off contract deployments: `make setup-task network=<network> task=<task-name>`
 
 Next, `cd` into the directory that was created for you and follow the steps listed below for the relevant template.
@@ -92,6 +93,24 @@ This template is increasing the throughput on Base Chain.
 1. Check in the task when it's ready to sign and collect signatures from signers
 1. Once executed, check in the records files and mark the task `DONE` in the README.
 
+## Using the fault proof upgrade template
+
+This template is used to upgrade the fault proof contracts. This is commonly done in conjunction with a hardfork.
+
+1. Ensure you have followed the instructions above in `setup`
+1. Go to the folder that was created using the `make setup-upgrade-fault-proofs network=<network>` step
+1. Specify the commit of [Optimism code](https://github.com/ethereum-optimism/optimism) and [Base contracts code](https://github.com/base-org/contracts) you intend to use in the `.env` file
+1. Run `make deps`
+1. Add the new absolute prestate to the `.env` file. This can be found in the op-program prestates [releases.json](https://github.com/ethereum-optimism/optimism/blob/develop/op-program/prestates/releases.json) file.
+1. NOTE: If this task is for mainnet, the directory should work as-is. If this task is for testnet, you will need to follow the following steps:
+   1. Update the `UpgradeDGF` script to inherit `MultisigBuilder` instead of `NestedMultisigBuilder`
+   1. Comment out the mainnet environment variables and uncomment the testnet vars in `.env`
+   1. Comment out the nested multisig builder commands in the Makefile and uncomment the multisig builder commands
+1. Build the contracts with `forge build`
+1. Remove the unneeded validations from `VALIDATION.md` and update the relevant validations accordingly
+1. Check in the task when it's ready to sign and collect signatures from signers
+1. Once executed, check in the records files and mark the task `DONE` in the README.
+
 ## Using the generic template
 
 This template can be used to do contract calls, upgrades, or one-off deployments.

setup-templates/template-upgrade-fault-proofs/.env

@@ -0,0 +1,15 @@
+OP_COMMIT=
+BASE_CONTRACTS_COMMIT=
+
+ABSOLUTE_PRESTATE=
+
+# Sepolia Config
+# SYSTEM_CONFIG=0xf272670eb55e895584501d564AfEB048bEd26194
+# OWNER_SAFE=0x0fe884546476dDd290eC46318785046ef68a0BA9
+# LEDGER_ACCOUNT=1
+
+# Mainnet Config
+SYSTEM_CONFIG=0x73a79Fab69143498Ed3712e519A88a918e1f4072
+OWNER_SAFE=0x7bB41C3008B3f03FE483B28b8DB90e19Cf07595c
+CB_SIGNER_SAFE_ADDR=0x9855054731540A48b28990B63DcF4f33d8AE46A1
+OP_SIGNER_SAFE_ADDR=0x9BA6e03D8B90dE867373Db8cF1A58d2F7F006b3A

setup-templates/template-upgrade-fault-proofs/Makefile

@@ -0,0 +1,70 @@
+include ../../Makefile
+include ../.env
+include .env
+
+ifndef LEDGER_ACCOUNT
+override LEDGER_ACCOUNT = 0
+endif
+
+.PHONY: deploy
+deploy:
+	forge script --rpc-url $(L1_RPC_URL) DeployDisputeGames \
+	--ledger --hd-paths "m/44'/60'/$(LEDGER_ACCOUNT)'/0/0" --broadcast -vvvv
+
+##
+# MultisigBuilder commands
+# The following commands can be used for tasks that utilize the MultisigBuilder.
+# Note that --ledger --hd-paths <PATH> can be replaced with --private-key $(PRIVATE_KEY)
+# in any command when using a local key.
+##
+
+# .PHONY: sign
+# sign:
+# 	$(GOPATH)/bin/eip712sign --ledger --hd-paths "m/44'/60'/$(LEDGER_ACCOUNT)'/0/0" -- \
+# 	forge script --rpc-url $(L1_RPC_URL) UpgradeDGF --sig "sign()"
+
+# .PHONY: execute
+# execute:
+# 	forge script --rpc-url $(L1_RPC_URL) UpgradeDGF \
+# 	--sig "run(bytes)" $(SIGNATURES) \
+# 	--ledger --hd-paths "m/44'/60'/$(LEDGER_ACCOUNT)'/0/0" --broadcast -vvvv
+
+##
+# NestedMultisigBuilder commands
+# The following commands can be used for tasks that utilize the NestedMultisigBuilder.
+# Note that --ledger --hd-paths <PATH> can be replaced with --private-key $(PRIVATE_KEY)
+# in any command when using a local key.
+# See more documentation on the various steps in NestedMultisigBuilder.sol.
+##
+
+# This step is run by signers on the "children" safes
+.PHONY: sign-cb
+sign-cb:
+	$(GOPATH)/bin/eip712sign --ledger --hd-paths "m/44'/60'/$(LEDGER_ACCOUNT)'/0/0" -- \
+	forge script --rpc-url $(L1_RPC_URL) UpgradeDGF \
+	--sig "sign(address)" $(CB_SIGNER_SAFE_ADDR)
+
+.PHONY: sign-op
+sign-op:
+	$(GOPATH)/bin/eip712sign --ledger --hd-paths "m/44'/60'/$(LEDGER_ACCOUNT)'/0/0" -- \
+	forge script --rpc-url $(L1_RPC_URL) UpgradeDGF \
+	--sig "sign(address)" $(OP_SIGNER_SAFE_ADDR)
+
+# This step is run once per "child" safe, and can be run by anyone (doesn't have to be a signer)
+.PHONY: approve-cb
+approve-cb:
+	forge script --rpc-url $(L1_RPC_URL) UpgradeDGF \
+	--sig "approve(address,bytes)" $(CB_SIGNER_SAFE_ADDR) $(SIGNATURES) \
+	--ledger --hd-paths "m/44'/60'/$(LEDGER_ACCOUNT)'/0/0" --broadcast
+
+.PHONY: approve-op
+approve-op:
+	forge script --rpc-url $(L1_RPC_URL) UpgradeDGF \
+	--sig "approve(address,bytes)" $(OP_SIGNER_SAFE_ADDR) $(SIGNATURES) \
+	--ledger --hd-paths "m/44'/60'/$(LEDGER_ACCOUNT)'/0/0" --broadcast
+
+# This step is run once after all children safes have approved and can be run by anyone (doesn't have to be a signer)
+.PHONY: execute
+execute:
+	forge script --rpc-url $(L1_RPC_URL) UpgradeDGF \
+	--sig "run()" --ledger --hd-paths "m/44'/60'/$(LEDGER_ACCOUNT)'/0/0" --broadcast

setup-templates/template-upgrade-fault-proofs/README.md

@@ -0,0 +1,193 @@
+# Upgrade Fault Proofs
+
+Status: PENDING
+
+## Description
+
+This task contains two scripts. One for deploying new versions of the `FaultDisputeGame` and `PermissionedDisputeGame` contracts, and one for updating the `DisputeGameFactory` contract to reference the new dispute game contracts.
+
+## Procedure
+
+### 1. Update repo:
+
+```bash
+cd contract-deployments
+git pull
+cd <network>/<date>-upgrade-fault-proofs
+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. Run relevant script(s)
+
+#### 3.1 Deploy new Dispute Game Implementations
+
+```bash
+make deploy
+```
+
+This will output the new addresses of the `FaultDisputeGame` and `PermissionedDisputeGame` contracts to an `addresses.json` file. You will need to commit this file to the repo before signers can sign.
+
+#### 3.2 Sign the transaction
+
+**If on testnet**:
+
+```bash
+make sign
+```
+
+**If on mainnet**:
+
+Coinbase signer:
+
+```bash
+make sign-cb
+```
+
+Op signer:
+
+```bash
+make sign-op
+```
+
+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 extract the domain hash and message hash to approve on your Ledger:
+
+1. Validate integrity of the simulation.
+2. Validate correctness of the state diff.
+3. Validate and extract domain hash and message hash to approve.
+
+##### 3.2.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 Sepolia or 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 see the derivation path Note above.
+
+##### 3.2.2. Validate correctness of the state diff.
+
+Now click on the "State" tab, and refer to the [State Validations](./VALIDATION.md) instructions for the transaction you are signing.
+Once complete return to this document to complete the signing.
+
+##### 3.2.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.
+
+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.
+
+Once the validations are done, it's time to actually sign the
+transaction.
+
+> [!WARNING]
+> 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:
+
+```shell
+Data:  <DATA>
+Signer: <ADDRESS>
+Signature: <SIGNATURE>
+```
+
+Double check the signer address is the right one.
+
+##### 3.2.4 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!
+
+### [For Facilitator ONLY] How to execute
+
+#### Execute the transaction
+
+1. IMPORTANT: Ensure op-challenger has been updated before executing.
+1. Collect outputs from all participating signers.
+1. Concatenate all signatures and export it as the `SIGNATURES`
+   environment variable, i.e. `export
+SIGNATURES="[SIGNATURE1][SIGNATURE2]..."`.
+1. Run the `make execute` or `make approve` command as described below to execute the transaction.
+
+For example, if the quorum is 2 and you get the following outputs:
+
+```shell
+Data:  0xDEADBEEF
+Signer: 0xC0FFEE01
+Signature: AAAA
+```
+
+```shell
+Data:  0xDEADBEEF
+Signer: 0xC0FFEE02
+Signature: BBBB
+```
+
+If on testnet, then you should run:
+
+Coinbase facilitator:
+
+```bash
+SIGNATURES=AAAABBBB make execute
+```
+
+If on mainnet, then you should run:
+
+Coinbase facilitator:
+
+```bash
+SIGNATURES=AAAABBBB make approve-cb
+```
+
+Optimism facilitator:
+
+```bash
+SIGNATURES=AAAABBBB make approve-op
+```
+
+#### If on mainnet, execute the transaction
+
+Once the signatures have been submitted approving the transaction for all nested Safes run:
+
+```bash
+make execute
+```

setup-templates/template-upgrade-fault-proofs/VALIDATION.md

@@ -0,0 +1,41 @@
+# Validation
+
+This document can be used to validate the state diff resulting from the execution of the upgrade transactions.
+
+For each contract listed in the state diff, please verify that no contracts or state changes shown in the Tenderly diff are missing from this document. Additionally, please verify that for each contract:
+
+- The following state changes (and none others) are made to that contract. This validates that no unexpected state changes occur.
+- All addresses (in section headers and storage values) match the provided name, using the Etherscan and Superchain Registry links provided. This validates the bytecode deployed at the addresses contains the correct logic.
+- All key values match the semantic meaning provided, which can be validated using the storage layout links provided.
+
+## Mainnet State Changes
+
+### `0x43edB88C4B80fDD2AdFF2412A7BebF9dF42cB40e` (`DisputeGameFactory`)
+
+- **Key**: `0x4d5a9bd2e41301728d41c8e705190becb4e74abe869f75bdb405b63716a35f9e` <br/>
+  **Before**: `0x00000000000000000000000068f600e592799c16d1b096616edbf1681fb9c0de` <br/>
+  **After**: Newly deployed `PermissionedDisputeGame` address converted to bytes32 <br/>
+  **Meaning**: Updates the `PermissionedDisputeGame` implementation address from `0x68f600e592799c16D1b096616eDbf1681FB9c0De` to the newly deployed contract address.
+  **Verify**: You can verify the key derivation by running `cast index uint32 1 101` in your terminal.
+- **Key**: `0xffdfc1249c027f9191656349feb0761381bb32c9f557e01f419fd08754bf5a1b` <br/>
+  **Before**: `0x000000000000000000000000b7fb44a61fde2b9db28a84366e168b14d1a1b103` <br/>
+  **After**: Newly deployed `FaultDisputeGame` address converted to bytes32 <br/>
+  **Meaning**: Updates the `FaultDisputeGame` implementation address from `0xB7fB44a61fdE2b9DB28a84366e168b14D1a1b103` to the newly deployed contract address.
+  **Verify**: You can verify the key derivation by running `cast index uint32 0 101` in your terminal.
+
+## Sepolia State Changes
+
+### `0xd6E6dBf4F7EA0ac412fD8b65ED297e64BB7a06E1` (`DisputeGameFactory`)
+
+- **Key**: `0x4d5a9bd2e41301728d41c8e705190becb4e74abe869f75bdb405b63716a35f9e` <br/>
+  **Before**: `0x00000000000000000000000068f600e592799c16d1b096616edbf1681fb9c0de` <br/>
+  **After**: Newly deployed `PermissionedDisputeGame` address converted to bytes32 <br/>
+  **Meaning**: Updates the `PermissionedDisputeGame` implementation address from `0x68f600e592799c16D1b096616eDbf1681FB9c0De` to the newly deployed contract address.
+  **Verify**: You can verify the key derivation by running `cast index uint32 1 101` in your terminal.
+- **Key**: `0xffdfc1249c027f9191656349feb0761381bb32c9f557e01f419fd08754bf5a1b` <br/>
+  **Before**: `0x000000000000000000000000b7fb44a61fde2b9db28a84366e168b14d1a1b103` <br/>
+  **After**: Newly deployed `FaultDisputeGame` address converted to bytes32 <br/>
+  **Meaning**: Updates the `FaultDisputeGame` implementation address from `0xB7fB44a61fdE2b9DB28a84366e168b14D1a1b103` to the newly deployed contract address.
+  **Verify**: You can verify the key derivation by running `cast index uint32 0 101` in your terminal.
+
+You should also see nonce updates for the `ProxyAdminOwner` (`0x0fe884546476dDd290eC46318785046ef68a0BA9`) and the address you're signing with.