From f42998cc8edfe9d0857523f533e6d9f188a40c4f Mon Sep 17 00:00:00 2001 From: soyboy <85043086+sbvegan@users.noreply.github.com> Date: Mon, 28 Oct 2024 15:59:59 -0600 Subject: [PATCH] removing fp and granite notices --- next-env.d.ts | 2 +- pages/builders/notices.mdx | 6 +- pages/builders/notices/_meta.json | 2 - pages/builders/notices/fp-changes.mdx | 100 --------------------- pages/builders/notices/granite-changes.mdx | 86 ------------------ public/_redirects | 4 +- 6 files changed, 5 insertions(+), 195 deletions(-) delete mode 100644 pages/builders/notices/fp-changes.mdx delete mode 100644 pages/builders/notices/granite-changes.mdx diff --git a/next-env.d.ts b/next-env.d.ts index 4f11a03dc..a4a7b3f5c 100644 --- a/next-env.d.ts +++ b/next-env.d.ts @@ -2,4 +2,4 @@ /// // NOTE: This file should not be edited -// see https://nextjs.org/docs/basic-features/typescript for more information. +// see https://nextjs.org/docs/pages/building-your-application/configuring/typescript for more information. diff --git a/pages/builders/notices.mdx b/pages/builders/notices.mdx index 81a3ecb0a..53ca1701f 100644 --- a/pages/builders/notices.mdx +++ b/pages/builders/notices.mdx @@ -8,12 +8,8 @@ import { Card, Cards } from 'nextra/components' # Notices -This section provides information on preparing for fault proofs breaking changes, preparing for granite breaking changes and deprecation of the optimism sdk. You'll find overview, tutorial to help you understand and work with these topics. +This section offers essential information for builders to stay up-to-date with the latest changes in the OP Stack. - - - - diff --git a/pages/builders/notices/_meta.json b/pages/builders/notices/_meta.json index b85000edf..f75d9972e 100644 --- a/pages/builders/notices/_meta.json +++ b/pages/builders/notices/_meta.json @@ -1,5 +1,3 @@ { - "granite-changes": "Preparing for Granite breaking changes", - "fp-changes": "Preparing for fault proofs breaking changes", "sdk-deprecation": "Preparing for Optimism SDK deprecation" } diff --git a/pages/builders/notices/fp-changes.mdx b/pages/builders/notices/fp-changes.mdx deleted file mode 100644 index 0ef6d47cd..000000000 --- a/pages/builders/notices/fp-changes.mdx +++ /dev/null @@ -1,100 +0,0 @@ ---- -title: Preparing for fault proofs breaking changes -lang: en-US -description: Learn how to prepare for Fault Proofs changes. ---- - -import { Steps, Callout } from 'nextra/components' - -# Preparing for fault proofs breaking changes - -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). - - - **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](/stack/transactions/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. - - - - **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. - - - - 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. - - -## 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. - -### `L2OutputOracle` - -The `OptimismPortal` is changing slightly with Fault Proof Mainnet because it now points to the `DisputeGameFactory` contract instead of the `L2OutputOracle` contract. -Most notable change for developers is that withdrawals will have to be proven against the `rootClaim` of some dispute game rather than referencing an output in the `L2OutputOracle` contract. - -### `OptimismPortal` - -The `OptimismPortal` smart contract is the low-level contract on L1 used to execute deposits and withdrawals. -Previously, developers would look at the `L2OutputOracle` to find the exact next output that included their withdrawal. -Now, developers must look at the `OptimismPortal` contract to determine the `respectedGameType` and then use this information to query the `DisputeGameFactory` for a list of recent `DisputeGame` contracts with the correct game type. - -### `DisputeGameFactory` - -It is recommended that developers search for a reasonable number of recent games, say 100 games, and pick the first proposal with a sufficient block number. -Developers should then verify this proposal locally as the default game type will allow for permissionless proposals and there is no longer a strong guarantee that proposals will be valid. - -## For bridges and centralized exchanges - -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. - - - Withdrawals that haven't finalized before the upgrade occurs will be unable to be finalized post-upgrade without reproving. 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-prove after the upgrade, you will have to wait a new seven days.) - - - - ### Update logic to support fault proofs - - - Most teams use the Optimism SDK or Viem to handle this logic under the hood and will simply need to update their software version ahead of the upgrade. However, any project performing withdrawals programmatically will need to update their client code (see [`OptimismPortal`](#optimismportal) for details). - - - * **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.** Update to the latest version of Viem (version of >=2.9.0). Viem will automatically begin to use the new logic once it detects that the FPM update has gone live. - - ### Update withdrawal monitor - - The Withdrawal Monitor service is an important part of the two-step withdrawal system that checks if anyone has been able to prove withdrawals that do not actually appear on L2. - The Withdrawal Monitor is now slightly slower at startup time but is more reliable, simpler, and compatible with more infrastructure to more easily support any OP Stack chain. - Changes to the Withdrawal Monitor are entirely backwards compatible. - - * **Option 1: Withdrawal from source.** If building or using withdrawal-monitor from source, make sure that you are using the latest develop branch. All withdrawal monitor changes are fully backwards compatible. - * **Option 2: Docker image.** If using docker, use the latest chain-mon docker image. - - ### Update dispute monitor - - The Dispute Monitor service detects when invalid outputs have been proposed. Given the large number of changes to the output proposal system, the current Fault Monitor is being replaced in favor of a new Dispute Monitor purposely built for the fault proof monitor system. - - - Any team running the current Fault Monitor will see the monitor stop functioning when the Fault Proof Monitor upgrade goes live. These teams should run the new service and update their alerting accordingly. - - - -## Next steps - -* See the [Fault Proofs Explainer](/stack/fault-proofs/explainer) to learn more about the three main components of the Fault Proof System. -* You can also read more about [Cannon FPVM](/stack/fault-proofs/cannon) and [Mips.sol](/stack/fault-proofs/mips), the onchain smart contract implementation of Cannon. diff --git a/pages/builders/notices/granite-changes.mdx b/pages/builders/notices/granite-changes.mdx deleted file mode 100644 index 5fc68df94..000000000 --- a/pages/builders/notices/granite-changes.mdx +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: Preparing for Granite breaking changes -lang: en-US -description: Learn how to prepare for Granite upgrade breaking changes. ---- - -import { Steps, Callout } from 'nextra/components' - -# Preparing for Granite breaking changes - -This page outlines breaking changes related to the Granite network upgrade for chain operators and node operators. -If you experience difficulty at any stage of this process, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions). - - - The Granite upgrade for OP Sepolia was activated on **1723478400 - Mon Aug 12 16:00:00 UTC**. The Granite OP Mainnet upgrade will be activated at **1726070401 - Wed 11 Sep 2024 16:00:01 UTC**, here is the [governance vote](https://vote.optimism.io/proposals/46514799174839131952937755475635933411907395382311347042580299316635260952272). - - -## What's included in Granite - -This upgrade is proposed in response to security vulnerabilities identified during a series of third-party security audits by Spearbit, Cantina, and Code4rena. None of the vulnerabilities have been exploited, and user assets are not and were never at risk. However, out of an abundance of caution, the permissioned fallback mechanism has been activated in order to avoid any potential instability while the vulnerabilities are patched. For more information on the permissioned fallback mechanism and the OP Stack's defense-in-depth approach to Fault Proof security, see the [fault proof documentation](/stack/fault-proofs/fp-security). - -The upgrade includes both a set of smart contract upgrades to fix the vulnerabilities identified in the audit as well as an L2 hardfork to improve the stability and performance of the fault proof system. In addition, we propose extending the capabilities of the Guardian and DeputyGuardian to set the anchor state for the fault proof system in order to prevent referencing invalid anchor states. Aside from implementing these fixes, the primary impact of this upgrade would be to reset user withdrawals at the planned time, similar to the initial Fault Proof upgrade. - -Please refer to the [governance proposal](https://gov.optimism.io/t/upgrade-proposal-10-granite-network-upgrade/8733) for the full details. - -## For chain operators - -The proposed Granite upgrade impacts OP chains and requires chain operators to upgrade their chain and configure the sequencer for Granite. - - - - ### Prepare sequencer node - - - If you are operating an OP Chain that has an entry in the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json), the Granite activation date is part of the `op-node` and `op-geth` nodes, and are using the [--network](/builders/node-operators/configuration/consensus-config#network) and [--op-network](/builders/node-operators/configuration/execution-config#op-network-betaop-network) flags. No action is needed for the sequencer after preparing the `SystemConfig` transaction. - - - For custom chains not included in the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json), you will need to manually configure the [activation timestamp](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/superchain.toml). You have two configuration options for your sequencer node: - - * **Option 1:** Set the Granite activation date in your `rollup.json` config file. You will still need to set the `override.granite` flag in `op-geth` with the UNIX timestamp. - * **Option 2:** Alternatively, chain operators can use the override flags to configure your sequencer node by specifying a time in the future when Granite will activate. - * Set `override.granite` in both `op-node` and `op-geth` to the UNIX timestamp of the block you want to activate the Granite hardfork or corresponding env vars for this. - * In general, run `op-node --help` or `op-geth --help` to see flags, their descriptions and environment variables. - - ### Rollup configuration breaking changes - - Alt-DA mode has had a name change. What was formerly known as Plasma Mode has been renamed and you may need to [update your rollup configuration file](/builders/chain-operators/features/alt-da-mode#breaking-changes-renaming-plasma-mode-to-alt-da-mode). - - - - To verify proper configuration, chain operators should confirm in the startup logs of their `op-node` and `op-geth` that the correct Granite activation timestamps are set. - - -## For node operators - -Node operators will need to upgrade to Granite before the activation date. -The op-node release [v1.9.1](https://github.com/ethereum-optimism/optimism/releases/tag/v1.9.1) -and op-geth release [v1.101408.0](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101408.0) contain these changes. - -These following steps are necessary for every node operator: - - - ### Update to the latest release - - * [`op-node`](https://github.com/ethereum-optimism/optimism/releases/tag/v1.9.1) - * [`op-geth`](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101408.0) - - ### Configure the Granite activation date - - - If you are operating a node for an OP Chain that has an entry in the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json), the Granite activation date is part of the `op-node` and `op-geth` nodes. So, no action is needed for the sequencer after upgrading to the latest release. Please skip to [Step 3: Verify Your Configuration](#verify-your-configuration). - - - For node operators of custom chains not included in the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json), you will need to manually configure the [activation timestamp](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/superchain.toml). This can be done one of two ways: - - * **Option 1:** Set the activation time in the `rollup.json` for `op-node`. You will still need to set the `override.granite` flag in `op-geth` if you use this option. - * **Option 2:** Set the activation time via overrides (CLI) in both `op-node` and `op-geth`. These will need to be set on `op-node` and `op-geth` for the sequencer and all other nodes. - - ### Verify your configuration - - Make the following checks to verify that your node is properly configured. - - * `op-node` and `op-geth` will log their configurations at startup - * Check that the Granite time is set to `activation-timestamp` in the op-node startup logs - * Check that the Granite time is set to `activation-timestamp` in the op-geth startup logs - diff --git a/public/_redirects b/public/_redirects index d586cee18..55ee480e3 100644 --- a/public/_redirects +++ b/public/_redirects @@ -101,4 +101,6 @@ /stack/protocol/rollup/deposit-flow /stack/transactions/deposit-flow /stack/protocol/outages /stack/rollup/outages /stack/operators/features/op-txproxy /builders/chain-operators/tools/op-txproxy -/stack/operators/features/proxyd /builders/chain-operators/tools/proxyd \ No newline at end of file +/stack/operators/features/proxyd /builders/chain-operators/tools/proxyd +/builders/notices/granite-changes https://github.com/ethereum-optimism/docs/blob/ef619668ae44276edecdfd657157254b9809e2d6/pages/builders/notices/granite-changes.mdx +/builders/notices/fp-changes https://github.com/ethereum-optimism/docs/blob/ef619668ae44276edecdfd657157254b9809e2d6/pages/builders/notices/fp-changes.mdx \ No newline at end of file