Skip to content

Latest commit

 

History

History
193 lines (133 loc) · 5.12 KB

File metadata and controls

193 lines (133 loc) · 5.12 KB

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:

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

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:

make sign

If on mainnet:

Coinbase signer:

make sign-cb

Op signer:

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 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:

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.
  2. Collect outputs from all participating signers.
  3. Concatenate all signatures and export it as the SIGNATURES environment variable, i.e. export SIGNATURES="[SIGNATURE1][SIGNATURE2]...".
  4. 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:

Data:  0xDEADBEEF
Signer: 0xC0FFEE01
Signature: AAAA
Data:  0xDEADBEEF
Signer: 0xC0FFEE02
Signature: BBBB

If on testnet, then you should run:

Coinbase facilitator:

SIGNATURES=AAAABBBB make execute

If on mainnet, then you should run:

Coinbase facilitator:

SIGNATURES=AAAABBBB make approve-cb

Optimism facilitator:

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:

make execute