Create Granite notice page skeleton #870
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
WalkthroughThe Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Guide
participant WalletDev
participant ChainOperator
participant NodeOperator
User->>Guide: Access Granite upgrade instructions
Guide->>WalletDev: Provide necessary changes and preparations
Guide->>ChainOperator: Inform about upgrade implications and configurations
Guide->>NodeOperator: Outline steps for upgrading to latest releases
Recent review detailsConfiguration used: .coderabbit.yaml Files selected for processing (4)
Files skipped from review due to trivial changes (1)
Additional context usedPath-based instructions (2)
LanguageTool
Additional comments not posted (6)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
✅ Deploy Preview for docs-optimism ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
sbvegan
approved these changes
Aug 29, 2024
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Comment on lines
+26
to
+82
| ## For Chain Operators | ||
|
|
||
| The proposed Granite upgrade impacts OP chains and requires chain operators to upgrade their chain and configure the sequencer for Granite. | ||
|
|
||
| <Steps> | ||
|
|
||
| ### Prepare Sequencer Node | ||
|
|
||
| <Callout type="warning"> | ||
| 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. | ||
| </Callout> | ||
|
|
||
| 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. | ||
| </Steps> | ||
|
|
||
| <Callout type="info"> | ||
| 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. | ||
| </Callout> | ||
|
|
||
| ## 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: | ||
|
|
||
| <Steps> | ||
| ### 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 | ||
|
|
||
| <Callout type="warning"> | ||
| 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). | ||
| </Callout> | ||
|
|
||
| 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 | ||
| </Steps> |
There was a problem hiding this comment.
Improve clarity and conciseness.
The sections for chain operators and node operators are well-written but can be improved for clarity and conciseness.
Apply this diff to improve the sections:
-The proposed Granite upgrade impacts OP chains and requires chain operators to upgrade their chain and configure the sequencer for Granite.
+The proposed Granite upgrade impacts OP chains and requires chain operators to upgrade their chain and configure the sequencer.
<Steps>
- ### Prepare Sequencer Node
+ ### Prepare the Sequencer Node
<Callout type="warning">
- 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.
+ 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 you 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.
</Callout>
- 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:
+ 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:
* **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 the 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.
<Callout type="info">
- 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.
+ 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.
</Callout>
## For Node Operators
-Node operators will need to upgrade to Granite before the activation date.
+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:
+The following steps are necessary for every node operator:
<Steps>
- ### Update to the Latest Release
+ ### Update to the Latest Releases
* [`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
+ ### Configure the Granite Activation Dates
<Callout type="warning">
- 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).
+ 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).
</Callout>
- 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:
+ 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 in 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
+ ### Verify the 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
<!-- This is an auto-generated comment by CodeRabbit -->
Comment on lines
+9
to
+16
| # 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). | ||
|
|
||
| <Callout type="info"> | ||
| 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). | ||
| </Callout> |
There was a problem hiding this comment.
Improve conciseness and clarity.
The introductory section is well-written but can be improved for conciseness and clarity.
Apply this diff to improve the section:
-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).
+This page outlines breaking changes related to the Granite network upgrade for chain and node operators.
+If you experience any difficulty, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions).
<Callout type="info">
- 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).
+ 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 **1726070401 - Tue 11 Sep 2024 16:00:01 UTC**, pending [governance approval](https://gov.optimism.io/t/upgrade-proposal-10-granite-network-upgrade/8733).
</Callout>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. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| # 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). | |
| <Callout type="info"> | |
| 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). | |
| </Callout> | |
| # Preparing for Granite Breaking Changes | |
| This page outlines breaking changes related to the Granite network upgrade for chain and node operators. | |
| If you experience any difficulty, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions). | |
| <Callout type="info"> | |
| 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 **1726070401 - Tue 11 Sep 2024 16:00:01 UTC**, pending [governance approval](https://gov.optimism.io/t/upgrade-proposal-10-granite-network-upgrade/8733). | |
| </Callout> |
Comment on lines
+18
to
+24
| ## 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. |
There was a problem hiding this comment.
Improve conciseness and grammatical correctness.
The section is informative but can be improved for conciseness and grammatical correctness.
Apply this diff to improve the section:
-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).
+This upgrade is proposed in response to security vulnerabilities identified during 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 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.
+The upgrade includes a set of smart contract upgrades to fix the vulnerabilities identified in the audit and 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 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.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. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| ## 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. | |
| ## What's Included in Granite | |
| This upgrade is proposed in response to security vulnerabilities identified during 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 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 a set of smart contract upgrades to fix the vulnerabilities identified in the audit and 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 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. |
Tools
LanguageTool
[style] ~20-~20: Consider a shorter alternative to avoid wordiness.
Context: ...d fallback mechanism has been activated in order to avoid any potential instability while t...(IN_ORDER_TO_PREMIUM)
[grammar] ~22-~22: Probable usage error. Use “and” after ‘both’.
Context: ...vulnerabilities identified in the audit as well as an L2 hardfork to improve the stability...(BOTH_AS_WELL_AS)
[style] ~22-~22: Consider a shorter alternative to avoid wordiness.
Context: ...anchor state for the fault proof system in order to prevent referencing invalid anchor stat...(IN_ORDER_TO_PREMIUM)
Merged
Merged
This was referenced Oct 28, 2024
This was referenced Nov 18, 2024
This was referenced Dec 11, 2024
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Creates a notice page for the Granite upgrade.