diff --git a/pages/builders/node-operators/releases.mdx b/pages/builders/node-operators/releases.mdx index 772e7d384..f0966bf01 100644 --- a/pages/builders/node-operators/releases.mdx +++ b/pages/builders/node-operators/releases.mdx @@ -39,5 +39,5 @@ We follow a consistent tagging convention to make it easier to find the right im | Network | op-node | op-geth | | ---------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | -| OP Mainnet | [v1.7.7](https://github.com/ethereum-optimism/optimism/releases/tag/v1.7.7) | [v1.101315.2](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101315.2) | -| OP Sepolia | [v1.7.7](https://github.com/ethereum-optimism/optimism/releases/tag/v1.7.7) | [v1.101315.2](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101315.2) | +| OP Mainnet | [v1.9.1](https://github.com/ethereum-optimism/optimism/releases/tag/v1.9.1) | [v1.101408.0](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101408.0) | +| OP Sepolia | [v1.9.1](https://github.com/ethereum-optimism/optimism/releases/tag/v1.9.1) | [v1.101408.0](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101408.0) | diff --git a/pages/builders/notices/_meta.json b/pages/builders/notices/_meta.json index 769064261..0b387da16 100644 --- a/pages/builders/notices/_meta.json +++ b/pages/builders/notices/_meta.json @@ -1,4 +1,4 @@ { - "fp-changes": "Preparing for Fault Proofs Breaking Changes", - "fjord-changes": "Preparing for Fjord Breaking Changes" + "granite-changes": "Preparing for Granite Breaking Changes", + "fp-changes": "Preparing for Fault Proofs Breaking Changes" } diff --git a/pages/builders/notices/fjord-changes.mdx b/pages/builders/notices/fjord-changes.mdx deleted file mode 100644 index 29832e28c..000000000 --- a/pages/builders/notices/fjord-changes.mdx +++ /dev/null @@ -1,137 +0,0 @@ ---- -title: Preparing for Fjord Breaking Changes -lang: en-US -description: Learn how to prepare for Fjord upgrade breaking changes. ---- - -import { Steps, Callout } from 'nextra/components' - -# Preparing for Fjord Breaking Changes - -This page outlines breaking changes related to the Fjord network upgrade for wallets and front-end developers, 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 Fjord upgrade for OP Sepolia was activated on **1716998400 Wed May 29 16:00:00 UTC 2024**. The Fjord OP Mainnet upgrade will be optimistically activated **1720627201 Thu July 10 16:00:01 UTC 2024**, pending [governance approval](https://gov.optimism.io/t/upgrade-proposal-9-fjord-network-upgrade/8236). - - -## What's Included in Fjord - -The [Fjord network upgrade](https://specs.optimism.io/fjord/overview.html) includes the following: - -* [RIP-7212](https://specs.optimism.io/protocol/precompiles.html#P256VERIFY): Precompile for secp256r1 Curve Support, to reduce gas costs of many smart wallet applications. -* [Brotli](https://specs.optimism.io/fjord/derivation.html#brotli-channel-compression) as a channel compression option, for \~5-15% lower data availability costs. -* Parameter changes: - * [Max sequencer drift](https://specs.optimism.io/fjord/derivation.html#constant-maximum-sequencer-drift) becomes a constant with value increased to 1800 seconds - * 10x increased values for `MAX_RLP_BYTES_PER_CHANNEL` and `MAX_CHANNEL_BANK_SIZE` ([spec](https://specs.optimism.io/fjord/derivation.html#increasing-max_rlp_bytes_per_channel-and-max_channel_bank_size)) -* The [Fjord hardfork activation block](https://specs.optimism.io/fjord/derivation.html#network-upgrade-automation-transactions) includes several transactions to perform all L2 contract deployments, upgrades, enablements, and proxy updates. -* L1 Gas Cost changes: - * [FastLZ](https://specs.optimism.io/fjord/exec-engine.html#fees) based L1 fee [cost calculation](https://specs.optimism.io/fjord/exec-engine.html#fees) with an upgraded [`GasPriceOracle` L2 predeploy](https://specs.optimism.io/fjord/derivation.html#gaspriceoracle-deployment) to compute it - * `GasPriceOracle` gets a new function `getL1FeeUpperBound` as a cheap new way to calculate an upper bound for the max fee of a new transaction - * `getL1GasUsed` method of the `GasPriceOracle` contract ([spec](https://specs.optimism.io/fjord/predeploys.html#l1-gas-usage-estimation)) is being deprecated - * `L1GasUsed` field of the transaction receipt ([spec](https://specs.optimism.io/fjord/exec-engine.html)) is being deprecated - -## For Wallets and Front-End Developers - -The proposed Fjord upgrade to the OP Stack and OP Mainnet changes the formula for estimating the [L1 Data Fee](/stack/transactions/fees#l1-data-fee) component of the [OP Stack Transaction Fee](/stack/transactions/fees). - -* `getL1Fee` on the [GasPriceOracle contract](https://github.com/ethereum-optimism/optimism/blob/0dcb1b2c7dadec98a24f47e2e2d781a25800d9e1/packages/contracts-bedrock/src/L2/GasPriceOracle.sol#L54) has been updated. It now performs FastLZ compression on-chain, which is a better approximation of the compressibility of a transaction. Combined with a linear regression model, this gives a more accurate prediction of L1 data fees. -* `getL1GasUsed` and the corresponding `L1GasUsed` field of transaction receipts are being deprecated as they no longer accurately reflect gas usage as of Ecotone. The function and field will remain; however, their usefulness is limited as they still assume calldata batching. `getL1Fee` should be used when trying to predict L1 Data fees. -* `getL1FeeUpperBound` is a new method to estimate fee upper bounds when sending transactions. It is much cheaper, in gas costs, than previous methods. This is what wallets and front-ends should use in practice in most cases. -* Read the [Fjord Formula section](/stack/transactions/fees#fjord) of the [Transaction Fees](/stack/transactions/fees) page for more information about the new formula. - -Your application may need to be updated to account for this change. Read below to learn how specific changes in the Fjord upgrade require updates to your application. - -### Preparing Your Wallet or Front-End - -Changes to the L1 Data Fee formula may affect your application if you are computing this fee component on your own. It's strongly recommended that you use [existing tooling](/builders/app-developers/transactions/estimates#tooling) to estimate transaction fees instead of computing them yourself. - -* If you cannot use existing tooling, use the `getL1Fee` function on the `GasPriceOracle` smart contract to compute the L1 Data Fee component of the transaction fee. Avoid implementing the formula yourself, as it may change in the future. -* Alternatively, you should consider using `getL1FeeUpperBound` if you only need to estimate an upper bound of the L1 fee for the purpose of transaction sending. - -## For Chain Operators - -The proposed Fjord upgrade impacts OP chains and requires chain operators to upgrade their chain and configure the sequencer for Fjord. - -* [Max sequencer drift](https://specs.optimism.io/fjord/derivation.html#constant-maximum-sequencer-drift) becomes a constant with value increased to 1800 seconds. This gives chain operators more time to respond to L1 node issues without facing a potential L2 chain halt. -* [Brotli](https://specs.optimism.io/fjord/derivation.html#brotli-channel-compression) is now supported as a channel compression option, for \~5-15% lower data availability costs. -* An update of the fee scalars on the `SystemConfig` is necessary, similar to Ecotone. - - - ### Prepare `SystemConfig` Transaction - - An onchain transaction will be required to update the scalar for Fjord. This needs to be prepared days in advance before the activation to ensure chain operators don't operate at a loss when Fjord activates. - - * Encode the scalar value using the [ecotone scalar encoding tool](https://github.com/ethereum-optimism/optimism/tree/develop/op-chain-ops/cmd/ecotone-scalar) - * Send a `setGasConfig` transaction to `SystemConfig` - * Set `BaseFeeScalar` and `BlobBaseFeeScalar` values based on the [Fjord calculator](https://docs.google.com/spreadsheets/d/1V3CWpeUzXv5Iopw8lBSS8tWoSzyR4PDDwV9cu2kKOrs/edit#gid=186414307) - - ### 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 Fjord 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. Please skip to [Step 3: Prepare Batcher](#prepare-batcher). - - - 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 Fjord activation date in your `rollup.json` config file. You will still need to set the `override.fjord` 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 Fjord will activate. - * Set `override.fjord` in both `op-node` and `op-geth` to the UNIX timestamp of the block you want to activate the Fjord 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. - - ### Prepare Batcher - - Preparing your batcher to activate Brotli compression is optional but recommended to achieve better channel compression. - - * You can activate Brotli compression for your batcher by setting the `compression-algo` flag. - * `brotli-10` is the recommended Brotli level and works fine for most chain configurations. - * However, chain operators can experiment with `brotli-11` if it gives them better compression and their batcher can still keep up with the increased compression computation needs. - - - `brotli` defaults to `brotli-10`. If the flag is unset, it still defaults to `zlib`. - - - * You can also run the batcher help to see available options: `go run ./op-batcher/cmd --help |less` - - ```jsx - --compression-algo value (default: zlib) ($OP_BATCHER_COMPRESSION_ALGO) - The compression algorithm to use. Valid options: zlib, brotli, brotli-9, - brotli-10, brotli-11 - ``` - - - - To verify proper configuration, chain operators should confirm in the startup logs of their `op-node` and `op-geth` that the correct Fjord activation timestamps are set. - - -## For Node Operators - -Node operators will need to upgrade to Fjord before the activation date. For Sepolia, the op-node release [v1.7.7](https://github.com/ethereum-optimism/optimism/releases/tag/v1.7.7) and op-geth release [v1.101315.2](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101315.2) contain these changes. - -These following steps are necessary for EVERY node operator: - - - ### Update to the Latest Release - - * [`op-geth`](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101315.2) - * [`op-node`](https://github.com/ethereum-optimism/optimism/releases/tag/v1.7.7) - - ### Configure the Fjord 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 Fjord 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.fjord` 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 Fjord time is set to `activation-timestamp` in the op-node startup logs - * Check that the Fjord time is set to `activation-timestamp` in the op-geth startup logs - diff --git a/pages/builders/notices/granite-changes.mdx b/pages/builders/notices/granite-changes.mdx new file mode 100644 index 000000000..c63a91052 --- /dev/null +++ b/pages/builders/notices/granite-changes.mdx @@ -0,0 +1,82 @@ +--- +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 optimistically activated **1726070401 - Tue 11 Sep 2024 16:00:01 UTC**, pending [governance approval](https://gov.optimism.io/t/upgrade-proposal-10-granite-network-upgrade/8733). + + +## 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](https://docs.optimism.io/stack/protocol/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. + + + + 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/words.txt b/words.txt index db3931bdf..b4c313d08 100644 --- a/words.txt +++ b/words.txt @@ -83,7 +83,6 @@ Drand Eigen ENABLEDEPRECATEDPERSONAL enabledeprecatedpersonal -enablements enginekind Erigon erigon