Skip to content

Update fp-changes.mdx #689

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.

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

Merged
merged 6 commits into from
May 17, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
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
42 changes: 33 additions & 9 deletions pages/builders/notices/fp-changes.mdx
Original file line number Diff line number Diff line change
@@ -1,23 +1,42 @@
---
title: Preparing for Fault Proofs Breaking Changes
title: Preparing for Fault Proofs Changes
lang: en-US
description: Learn how to prepare for Fault Proofs breaking changes.
description: Learn how to prepare for Fault Proofs changes.
---

import { Steps, Callout } from 'nextra/components'

# Preparing for Fault Proofs Breaking Changes
# Preparing for Fault Proofs Changes

This page outlines breaking changes related to Fault Proof upgrade for bridges, centralized exchanges, and custom solutions that use withdrawals. This page outlines changes for OP Mainnet and OP Sepolia only, and details for other OP Chains are forthcoming.
If you experience difficulty at any stage of this process, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions).
OP Labs has submitted a [proposal to governance](https://gov.optimism.io/t/upgrade-proposal-fault-proofs/8161) to upgrade OP Mainnet to support Fault Proofs. If this proposal passes, fault proofs would launch on OP Mainnet approximately June 2024. This document details changes that apply to users, bridges, and centralized exchanges, as well as any custom solutions that use withdrawals. This page outlines changes for OP Mainnet and OP Sepolia only. Details for other OP Chains are forthcoming.

If you experience difficulty at any stage of this process, please reach out to [OP Labs Developer Support](https://github.com/ethereum-optimism/developers/discussions).

<Callout type="error">
**IMPORTANT NOTICE FOR BRIDGES AND USERS**

**ALL** withdrawals that are not finalized before the Fault Proofs upgrade executes will need to be reproven after the upgrade is complete.

* Reproving simply requires that you execute the [withdrawal proving flow](https://docs.optimism.io/stack/protocol/rollup/withdrawal-flow) again.
* Withdrawals prior to the Fault Proofs upgrade must wait a 7-day challenge period before finalization. As a result, any withdrawal initiated less than 7 days before the upgrade cannot be finalized before the upgrade is executed. You may want to consider waiting until after the upgrade is complete to begin a withdrawal during this 7-day window.
</Callout>
Comment on lines +18 to +22
Copy link
Contributor

Choose a reason for hiding this comment

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

The notice about re-proving withdrawals is crucial and well-highlighted. However, consider simplifying "Withdrawals prior to the Fault Proofs upgrade" to "Withdrawals before the upgrade" for conciseness.

- Withdrawals prior to the Fault Proofs upgrade must wait a 7-day challenge period before finalization.
+ Withdrawals before the upgrade must wait a 7-day challenge period before finalization.

Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.

Suggested change
**ALL** withdrawals that are not finalized before the Fault Proofs upgrade executes will need to be reproven after the upgrade is complete.
* Reproving simply requires that you execute the [withdrawal proving flow](https://docs.optimism.io/stack/protocol/rollup/withdrawal-flow) again.
* Withdrawals prior to the Fault Proofs upgrade must wait a 7-day challenge period before finalization. As a result, any withdrawal initiated less than 7 days before the upgrade cannot be finalized before the upgrade is executed. You may want to consider waiting until after the upgrade is complete to begin a withdrawal during this 7-day window.
</Callout>
**ALL** withdrawals that are not finalized before the Fault Proofs upgrade executes will need to be reproven after the upgrade is complete.
* Reproving simply requires that you execute the [withdrawal proving flow](https://docs.optimism.io/stack/protocol/rollup/withdrawal-flow) again.
* Withdrawals before the upgrade must wait a 7-day challenge period before finalization. As a result, any withdrawal initiated less than 7 days before the upgrade cannot be finalized before the upgrade is executed. You may want to consider waiting until after the upgrade is complete to begin a withdrawal during this 7-day window.
</Callout>


<Callout type="warning">
* Fault Proofs are scheduled to launch on testnet on **Tuesday, March 19, 2024**.
* Withdrawals between OP Sepolia and Sepolia will no longer be instant, since they are using the Fault Proofs mechanism.
**IMPORTANT NOTICE FOR BRIDGES AND USERS**

Maximum withdrawal delay times are increasing with the Fault Proofs upgrade.
* Withdrawals will generally take 7 days to finalize (unchanged from before Fault Proofs).
* Withdrawals that are proven against an output proposal that receives a validity challenge are delayed by an additional 3.5 days. Valid proposals that are challenged maliciously can be delayed by up to an additional 9 days at a very high cost to the malicious actor. Additional delays of this type are expected to be infrequent.
</Callout>

<Callout type="warning">
As of the Fault Proofs update to OP Sepolia in March 2024, **OP Sepolia withdrawals are no longer instant.** This is because the Fault Proof mechanism now applies to OP Sepolia transactions.
</Callout>

## Overview of Changes

If you are operating a custom bridge, review this section for changes you need to make. If you are using Optimism SDK or Viem for your bridging, you can [skip to the next section](#for-bridges-and-centralized-exchanges).

The `L2OutputOracle` is being entirely removed and replaced by the `OptimismPortal` and `DisputeGameFactory`. The `L2OutputOracle` smart contract is currently used by the trusted Proposer role to store L2 state output proposals.
Presently, developers use these outputs to prove that their withdrawals actually happened on L2. But with fault proofs, developers will have to change how their client software proves withdrawals in the first step of the two-step withdrawal process.

Expand All @@ -39,7 +58,12 @@ Developers should then verify this proposal locally as the default game type wil

## For Bridges and Centralized Exchanges

The proposed Fault Proof upgrade requires developers to enable Fault Proof changes before the Sepolia release. This impacts bridges, centralized exchanges, and custom solutions that use withdrawals.
The proposed Fault Proof upgrade requires developers to enable Fault Proof changes before the Op Mainnet release. This impacts bridges, centralized exchanges, and custom solutions that use withdrawals.

<Callout type="error">
Withdrawals that haven't finalized before the upgrade occurs will be unable to be finalized post-upgrade without resubmitting. This means these withdrawals will need to go through a new 7-day period. The time accrued before the upgrade will not count.
This means the withdrawal time could be as long as 13-14 days during the upgrade window. (If you submit it \~6 days before the upgrade, then must re-submit after the upgrade, you will have to wait a new seven days.)
</Callout>

<Steps>
### Update Logic to Support Fault Proofs
Expand All @@ -50,7 +74,7 @@ The proposed Fault Proof upgrade requires developers to enable Fault Proof chang

* **Option 1: Optimism SDK Update.** If you use OptimismSDK for bridging, simply update to version 3.2.0 or higher.
The Optimism SDK changes do not break the API and require no changes other than updating to the correct software version to support the new `OptimismPortal` logic. The Optimism SDK will automatically begin to use the new logic once it detects that the FPM update has gone live.
* **Option 2: Viem Update.** Viem changes will break the API and require both updating to latest version and replacing use of the currently used decorator with the `experimental` decorator that supports fault proofs. When fault proofs are on Mainnet in the future, `publicActionsL2` will be updated to support fault proofs by default, and it will be recommended that developers switch to the stable API.
* **Option 2: Viem Update.** Viem changes will break the API and require both updating to latest version and replacing use of the currently used decorator with the `experimental` decorator that supports fault proofs. When Fault Proofs are on OP Mainnet, `publicActionsL2` will be updated to support fault proofs by default, and it will be recommended that developers switch to the stable API.
Copy link
Contributor

Choose a reason for hiding this comment

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

Include "the" before "latest version" to correct the grammar.

- ...updating to latest version and replacing use of the currently used decorator...
+ ...updating to the latest version and replacing use of the currently used decorator...

Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.

Suggested change
* **Option 2: Viem Update.** Viem changes will break the API and require both updating to latest version and replacing use of the currently used decorator with the `experimental` decorator that supports fault proofs. When Fault Proofs are on OP Mainnet, `publicActionsL2` will be updated to support fault proofs by default, and it will be recommended that developers switch to the stable API.
* **Option 2: Viem Update.** Viem changes will break the API and require both updating to the latest version and replacing use of the currently used decorator with the `experimental` decorator that supports fault proofs. When Fault Proofs are on OP Mainnet, `publicActionsL2` will be updated to support fault proofs by default, and it will be recommended that developers switch to the stable API.


### Update Withdrawal Monitor

Expand Down
13 changes: 2 additions & 11 deletions words.txt
Original file line number Diff line number Diff line change
Expand Up @@ -7,12 +7,10 @@ ADDIU
ADDU
allocs
ANDI
Ankr
Apeworx
Arweave
authrpc
Badgeholders
badgeholders
BGEZ
BGTZ
Biconomy
Expand Down Expand Up @@ -118,7 +116,6 @@ Holesky
holesky
IGNOREPRICE
ignoreprice
Immunefi
implicity
Inator
inator
Expand All @@ -131,13 +128,13 @@ ipcfile
IPCPATH
ipcpath
IPFS
ipfs
JALR
JOURNALREMOTES
journalremotes
JSPATH
jspath
jwtsecret
leadup
leveldb
lightkdf
logfile
Expand Down Expand Up @@ -166,7 +163,6 @@ minsuggestedpriorityfee
Mintable
Mintplex
MIPSEVM
Mitigations
Moralis
Mordor
MOVN
Expand Down Expand Up @@ -245,8 +241,6 @@ productionized
Protip
proxyd
pseudorandomly
Pyth
Pyth's
Quicknode
quicknode
quickstarts
Expand All @@ -258,6 +252,7 @@ rejournal
REMOTEDB
remotedb
replayability
reproven
REQUIREDBLOCKS
requiredblocks
Rollups
Expand All @@ -266,9 +261,6 @@ RPCPREFIX
rpcprefix
RPGF
SELFDESTRUCT
SEPOLIA
Sepolia
sepolia
seqnr
SEQUENCERHTTP
sequencerhttp
Expand Down Expand Up @@ -324,7 +316,6 @@ VMDEBUG
vmdebug
VMODULE
vmodule
voxel
wagmi
XORI
xtensibility
Expand Down
Loading