Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update PRESIGNED-PAUSE.md with the GAP disclaimer. #347

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Update PRESIGNED-PAUSE.md with the GAP disclaimer. #347

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
c1d2621
add gap information to superchains-ops + doctoc
Ethnical Oct 17, 2024
6fb7c06
add the task 017 `PRESIGNED_PAUSE`
Ethnical Oct 17, 2024
8d08241
fix the comments
Ethnical Oct 18, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
64 changes: 40 additions & 24 deletions PRESIGNED-PAUSE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,25 +1,27 @@
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->

- [Objective](#objective)
- [Approving the transaction](#approving-the-transaction)
- [1. Update repo and move to the appropriate folder for this rehearsal task](#1-update-repo-and-move-to-the-appropriate-folder-for-this-rehearsal-task)
- [2. Setup Ledger](#2-setup-ledger)
- [3. Sign the transactions](#3-sign-the-transactions)
- [3.1. Validate integrity of the simulation.](#31-validate-integrity-of-the-simulation)
- [3.2. Validate correctness of the state diff.](#32-validate-correctness-of-the-state-diff)
- [3.3. Extract the domain hash and the message hash to approve.](#33-extract-the-domain-hash-and-the-message-hash-to-approve)
- [4. Approve the signature on your ledger](#4-approve-the-signature-on-your-ledger)
- [5. Send the output to Facilitator(s)](#5-send-the-output-to-facilitators)
- [[Before Ceremony] Instructions for the facilitator](#before-ceremony-instructions-for-the-facilitator)
- [1. Update input files](#1-update-input-files)
- [2. Prepare the transactions](#2-prepare-the-transactions)
- [[After Ceremony] Instructions for the facilitator](#after-ceremony-instructions-for-the-facilitator)
- [1. Collect the signatures](#1-collect-the-signatures)
- [2. Merge the signatures](#2-merge-the-signatures)
- [3. Verify the signatures](#3-verify-the-signatures)
- [4. Simulate the transaction with signatures](#4-simulate-the-transaction-with-signatures)
- [5. Store and execute the transaction](#5-store-and-execute-the-transaction)
- [Superchain Presigned Pause](#superchain-presigned-pause)
- [Objective](#objective)
- [Ensure no gaps with PSPs coverage](#1-ensure-no-gaps-with-psps-coverage)
- [Approving the transaction](#approving-the-transaction)
- [1. Update repo and move to the appropriate folder for this rehearsal task](#1-update-repo-and-move-to-the-appropriate-folder-for-this-rehearsal-task)
- [2. Setup Ledger](#2-setup-ledger)
- [3. Sign the transactions](#3-sign-the-transactions)
- [3.1. Validate integrity of the simulation.](#31-validate-integrity-of-the-simulation)
- [3.2. Validate correctness of the state diff.](#32-validate-correctness-of-the-state-diff)
- [3.3. Extract the domain hash and the message hash to approve.](#33-extract-the-domain-hash-and-the-message-hash-to-approve)
- [4. Approve the signature on your ledger](#4-approve-the-signature-on-your-ledger)
- [5. Send the output to Facilitator(s)](#5-send-the-output-to-facilitators)
- [[Before Ceremony] Instructions for the facilitator](#before-ceremony-instructions-for-the-facilitator)
- [1. Update input files](#1-update-input-files)
- [2. Prepare the transactions](#2-prepare-the-transactions)
- [[After Ceremony] Instructions for the facilitator](#after-ceremony-instructions-for-the-facilitator)
- [1. Collect the signatures](#1-collect-the-signatures)
- [2. Merge the signatures](#2-merge-the-signatures)
- [3. Verify the signatures](#3-verify-the-signatures)
- [4. Simulate the transaction with signatures](#4-simulate-the-transaction-with-signatures)
- [5. Store and execute the transaction](#5-store-and-execute-the-transaction)

<!-- END doctoc generated TOC please keep comment here to allow auto update -->

Expand All @@ -40,6 +42,19 @@ doesn’t even need to be funded. These are offchain signatures.

A Facilitator will collect the signatures and execute the contract.

### Ensure no gaps with PSPs coverage

We need to ensure there is no gaps in the PSPs coverage during upgrade.
This means that, if we are upgrading core components of the system. It can break the PSPs coverage, thus we need to ensure before the upgrade that the PSPs coverage will not be broken.
In the case there are broken changes, we need to blindly simulate the PSPs with the **new changes** and presign the new PSPs with the **new changes**.
This will allow us to have the PSPs coverage during the upgrade and after the upgrade with the new components.
We need to keep the PSPs before the upgrade and after the upgrade.

> [!WARNING]
> This will require to making some **overrides** in _superchains-ops_ tasks to simulate successfully with the new changes. We already had to do this for the PSPs in the [task 017](https://github.com/ethereum-optimism/superchain-ops/blob/main/tasks/eth/017-presigned-pause/PresignPauseFromJson.s.sol)

This is worth noting, if there is another entity that depends on the PSPs, we need to share these before the upgrade occurs.
Comment on lines +48 to +56
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Phrasing nits. I also removed "We need to keep the PSPs before the upgrade and after the upgrade." because I think we should expand on that in a new section that documents the process (two vaults, one is temporary, etc)

Suggested change
This means that, if we are upgrading core components of the system. It can break the PSPs coverage, thus we need to ensure before the upgrade that the PSPs coverage will not be broken.
In the case there are broken changes, we need to blindly simulate the PSPs with the **new changes** and presign the new PSPs with the **new changes**.
This will allow us to have the PSPs coverage during the upgrade and after the upgrade with the new components.
We need to keep the PSPs before the upgrade and after the upgrade.
> [!WARNING]
> This will require to making some **overrides** in _superchains-ops_ tasks to simulate successfully with the new changes. We already had to do this for the PSPs in the [task 017](https://github.com/ethereum-optimism/superchain-ops/blob/main/tasks/eth/017-presigned-pause/PresignPauseFromJson.s.sol)
This is worth noting, if there is another entity that depends on the PSPs, we need to share these before the upgrade occurs.
Upgrades to certain components of the system can invalidate existing PSPs and cause them to no longer work, thus we need to ensure before the upgrade that PSPs coverage continues without a gap.
In this case of breaking changes, we need to simulate the PSPs against the **new changes** and presign the new PSPs against these **new changes**.
This will allow us to have continuous PSP coverage before, during, and after the upgrade.
> [!WARNING]
> This will require to making some **overrides** in _superchains-ops_ tasks to simulate successfully with the new changes. We already had to do this for the PSPs in the [task 017](https://github.com/ethereum-optimism/superchain-ops/blob/main/tasks/eth/017-presigned-pause/PresignPauseFromJson.s.sol)
Additionally, if there is another entity that depends on the PSPs, we need to share these before the upgrade occurs.


## Approving the transaction

### 1. Update repo and move to the appropriate folder for this rehearsal task
Expand Down Expand Up @@ -117,7 +132,7 @@ just \
Where `0` is the index of the address you want to use in the derivation path.

For each transaction we will be performing 3 validations
and ensure the domain hash and message hash are the same
and ensure the domain hash and message hash are the same
between the Tenderly simulation and your
Ledger:

Expand Down Expand Up @@ -156,9 +171,9 @@ Now click on the "State" tab. Verify that:
storage key hash is evaluated from the following expression:
`bytes32(uint256(keccak256("superchainConfig.paused")) - 1)` per the
`SuperchainConfig` [implementation](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.5.0-rc.1/packages/contracts-bedrock/src/L1/SuperchainConfig.sol#L19).
3. There are no other significant state changes except for 2 nonce
2. There are no other significant state changes except for 2 nonce
changes from the Safe and the signer address.
4. You will see a state override (not a state change). This is
3. You will see a state override (not a state change). This is
expected and its purpose is to generate a successful Safe execution
simulation without collecting any signatures.

Expand Down Expand Up @@ -230,10 +245,10 @@ 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.

The signed transactions are in the `tx` folder. They will be named
The signed transactions are in the `tx` folder. They will be named
according to the address used to sign, i.e.
`tx/draft-92.signer-0x8c78B948Cdd64812993398b4B51ed2603b3543A6.json`
was signed by `0x8c78B948Cdd64812993398b4B51ed2603b3543A6`. Share
was signed by `0x8c78B948Cdd64812993398b4B51ed2603b3543A6`. Share
these 3 files with the Facilitator, and congrats, you are done!

## [Before Ceremony] Instructions for the facilitator
Expand Down Expand Up @@ -304,6 +319,7 @@ just \
This will overwrite the original `draft-*.json` files with the all merged signatures.

You can check the file contents with the following command:

```
cat tx/draft-*.json | jq
```
Expand Down