From 1c1958bb520df13599db38b925b56e0d1a090dcd Mon Sep 17 00:00:00 2001 From: geoknee Date: Thu, 2 Oct 2025 12:29:59 +0100 Subject: [PATCH 01/14] initial draft --- security/fma-l1-fusaka.md | 82 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 security/fma-l1-fusaka.md diff --git a/security/fma-l1-fusaka.md b/security/fma-l1-fusaka.md new file mode 100644 index 00000000..82368a30 --- /dev/null +++ b/security/fma-l1-fusaka.md @@ -0,0 +1,82 @@ +# Upgrade 12 (L1 Pectra Defense): Failure Modes and Recovery Path Analysis + + + + +- [Introduction](#introduction) +- [Generic Items](#generic-items) +- [Audit Requirements](#audit-requirements) +- [Action Items](#action-items) + + + +| | | +| ------------------- | ------------------- | +| Author | George Knee | +| Created at | 2nd October 2025 | +| Needs Approval From | | +| Other Reviewers | | +| Status | DRAFT | + +## Introduction + +This document is intended to be shared in a public space for reviews and visibility purposes. It covers Upgrade 16b, which involves the following changes: + +- (Consensus Layer) Ability to compute an accurate reflection of the L1 Blob Base Fee on L2, even when L1 activates Blob Parameter Only forks. +- (Smart Contracts) For chains using Fault Proofs, L1 contracts updates which reference an updated absolute prestate hash. + +Each change has its own section below with a list of Failure Modes. + +Below are references for this project: + +- [Github tracker](https://github.com/ethereum-optimism/optimism/issues/17471) +- [Specs clarification](https://github.com/ethereum-optimism/specs/pull/790) +- [OP Contracts Manager specs](https://specs.optimism.io/experimental/op-contracts-manager.html?highlight=opcm#op-contracts-manager) +- [Optimism Docs on Pectra (including L1 activation times)](https://oplabs.notion.site/fusaka-upgrade-readiness-doc) + +## Failure Modes and Recovery Paths + +### FM1: Consensus bug (client software) + +- op-geth cherry pick + +### FM2: Consensus bug (proof system) + + + + +## Generic Items + +Although this upgrade is technically a soft fork (it does not need to be coordinated across nodes other than being applied before Pectra activates on L1) many of the items in [./fma-generic-hardfork.md](./fma-generic-hardfork.md) apply. In particular: + +- Chain Halt at activation. +- Invalid `DisputeGameFactory.setImplementation` execution. +- Chain split across clients. + +- [x] Check this box to confirm that these items have been considered and updated if necessary. + +## Audit Requirements + +## Appendix + +The following table shows how each EIP from Pectra will affect OPStack chains: + +| EIP | Description | Impact on L2 Consensus Rules | +| -------- | ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | +| EIP-7594 | PeerDAS |TODO. | + | + +## Action Items + +Below is what needs to be done before launch to reduce the chances of the above failure modes occurring, and to ensure they can be detected and recovered from: + +- [ ] (BLOCKING): Resolve all comments on this document and incorporate them into the document itself (Assignee: document author) +- [ ] (BLOCKING): Action tests will be added which are run on op-node and Kona https://github.com/ethereum-optimism/optimism/issues/13967. Ideally they run against the usual mainline version of op-geth -- if this is not possible the tests can run against a patched version until op-geth is ready to support such tests. +- [ ] (BLOCKING): The changes will be deployed to a local multi-client devnet with both op-geth and op-reth running as well as Pectra activated on L1. https://github.com/ethereum-optimism/optimism/pull/14046 +- [ ] (non-BLOCKING): The changes will be deployed to a devnet which targets a public, Fusaka- and BPO1,2-enabled L1 [devnet]([url](https://devnets.optimism.io/balrog.html)) +- [ ] (non-BLOCKING): We will update the op-sepolia and op-mainnet vm-runners to use the new absolute prestate. The vm-runner runs the op-program in the MIPS FPVM using inputs sampled from a live chain. + + + + + From 34372f14e2d2b8ff9b4d40be35fa23425ab8b4bb Mon Sep 17 00:00:00 2001 From: geoknee Date: Thu, 2 Oct 2025 13:32:44 +0100 Subject: [PATCH 02/14] add EIP table --- security/fma-l1-fusaka.md | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/security/fma-l1-fusaka.md b/security/fma-l1-fusaka.md index 82368a30..53707cdc 100644 --- a/security/fma-l1-fusaka.md +++ b/security/fma-l1-fusaka.md @@ -59,12 +59,24 @@ Although this upgrade is technically a soft fork (it does not need to be coordin ## Appendix -The following table shows how each EIP from Pectra will affect OPStack chains: +The following table shows how each EIP from Fusaka (see [meta EIP](https://eips.ethereum.org/EIPS/eip-7607)) will affect OPStack chains: + +| EIP | Description | Compatibility Concerns | Components Affected | +| --- | --- | --- | --- | +| [7594](https://eips.ethereum.org/EIPS/eip-7594) | **PeerDAS (Headline feature)** | Blob Transaction senders must compute and attach “cell proofs”| `op-batcher` (tx-mgr), `proyxd`, `blob-archiver` | +| [7642](https://eips.ethereum.org/EIPS/eip-7642) | `eth/69` History expiry and simpler receipts | None | `op-geth` and `op-reth` | +| [7823](https://eips.ethereum.org/EIPS/eip-7823) | Set upper bounds for MODEXP | None | `op-geth` and `op-reth` | +| [7825](https://eips.ethereum.org/EIPS/eip-7825) | Transaction Gas Limit Cap | May limit superchain-ops (contract upgrade transactions on L1) and require them to be broken up. | `op-batcher`, `op-proposer`, `op-challenger`, `op-geth`, `op-reth` | +| [7883](https://eips.ethereum.org/EIPS/eip-7883) | ModExp Gas Cost Increase | Could effect the proofs system, making playing dispute games more expensive. | `op-challenger`, `op-proposer`, `op-geth`, `op-reth`, `contracts` | +| [7892](https://eips.ethereum.org/EIPS/eip-7892) | **Blob Parameter Only Hardforks (Headline feature)** | A framework to enable changing the blob schedule on L1 with less overhead / more frequently. Any such change will affect the L1 Cost, and a new prestate is implied when the schedule is updated. | `op-geth` and `op-reth` | +| [7917](https://eips.ethereum.org/EIPS/eip-7917) | Deterministic proposer lookahead | None, only affects consensus layer on L1 (PoS) | | +| [7918](https://eips.ethereum.org/EIPS/eip-7918) | Blob base fee bounded by execution cost | No action is necessary, since the change happens inside the `excessBlobGas` function. | `op-geth` and `op-reth` | +| [7934](https://eips.ethereum.org/EIPS/eip-7934) | RLP Execution Block Size Limit | Should be none, unless we have any huge L1 contracts that we exceed this limit. | `contracts`, `op-deployer`, block builders | +| [7935](https://eips.ethereum.org/EIPS/eip-7935) | Set default gas limit to XX0M | Actual limit not set yet. It will not decrease though, so should be backwards compatible. Doesn’t strictly require a hardfork. | | +| [7939](https://eips.ethereum.org/EIPS/eip-7939) | Count Leading Zeros (CLZ) opcode | None | | +| [7951](https://eips.ethereum.org/EIPS/eip-7951) | Precompile for secp256r1 support | None | EL clients | +| [7910](https://eips.ethereum.org/EIPS/eip-7910) | eth_config JSON-RPC method | Non breaking change, no defence needed | `op-geth` and `op-reth` | -| EIP | Description | Impact on L2 Consensus Rules | -| -------- | ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | -| EIP-7594 | PeerDAS |TODO. | - | ## Action Items From e4a4df08db37b7ee969dc29b273dea79d5fe9f0c Mon Sep 17 00:00:00 2001 From: geoknee Date: Thu, 2 Oct 2025 13:34:28 +0100 Subject: [PATCH 03/14] title --- security/fma-l1-fusaka.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/security/fma-l1-fusaka.md b/security/fma-l1-fusaka.md index 53707cdc..dc2cb3ee 100644 --- a/security/fma-l1-fusaka.md +++ b/security/fma-l1-fusaka.md @@ -1,4 +1,4 @@ -# Upgrade 12 (L1 Pectra Defense): Failure Modes and Recovery Path Analysis +# Upgrade 16b (L1 Fusaka Defense): Failure Modes and Recovery Path Analysis From 5ff7f9c561ca806160cc57717de4c68c5bbacc48 Mon Sep 17 00:00:00 2001 From: geoknee Date: Thu, 2 Oct 2025 15:40:35 +0100 Subject: [PATCH 04/14] update --- security/fma-l1-fusaka.md | 78 ++++++++++++++++++++++++++++++--------- 1 file changed, 61 insertions(+), 17 deletions(-) diff --git a/security/fma-l1-fusaka.md b/security/fma-l1-fusaka.md index dc2cb3ee..58e522da 100644 --- a/security/fma-l1-fusaka.md +++ b/security/fma-l1-fusaka.md @@ -22,6 +22,7 @@ This document is intended to be shared in a public space for reviews and visibility purposes. It covers Upgrade 16b, which involves the following changes: +- (`op-batcher`) Ability to submit cell proof blob sidecars (not just blob proof sidecars) - (Consensus Layer) Ability to compute an accurate reflection of the L1 Blob Base Fee on L2, even when L1 activates Blob Parameter Only forks. - (Smart Contracts) For chains using Fault Proofs, L1 contracts updates which reference an updated absolute prestate hash. @@ -36,11 +37,54 @@ Below are references for this project: ## Failure Modes and Recovery Paths -### FM1: Consensus bug (client software) +### FM1: op-batcher release not rolled out in time -- op-geth cherry pick +- **Description:** There is a chance we don't ship the changes we need to op-batcher, before the forks activate on L1. Also a problem if node or chain operators fail to update in time, even if our releases are available. The impact would be a safe head stall and sequencer window expiry / reorg if the L1 rejects the batcher's blob transactions. This can happen even in the patched batcher, if a config flag is not flipped, -### FM2: Consensus bug (proof system) +- **Risk Assessment:** High severity, Medium Likelihood +- **Mitigations:** + - Get a basic release candidate ready as early as possible + - Communicate widely and clearly about the need to update and any live ops that need to happen. + - Check with L1 nodes on already forked networks: do they accept legacy batcher blob transactions? + +- **Detection:** + - Usual alerts and dashboards +- **Recovery Path(s)**: + - Even an old batcher can switch to calldata as a good mitigation + +### FM2: op-node or kona node release not rolled out in time + +- **Description:** There is a chance we don't ship the changes we need to op-node or kona node, before the forks activate on L1. For example, the code we need to patch op-node exists in go-ethereum, but is only released late on in the development cycle (close to when we need to ship the patch). Also a problem if node or chain operators fail to update in time, even if our releases are available. The impact would be an incorrect blob base fee, causing L2 users to be excessively overcharged, even leading to an effective denial of service due to high fees on L2. Moreover, there is a likelihood of a chain split if nodes are updated in an uncoordinated way. We have seen this failure mode [play out on Sepolia](https://www.notion.so/oplabs/OP-Sepolia-L1-Cost-Blob-Schedule-Bug-1adf153ee1628009b429ee10828fb300#1adf153ee1628009b429ee10828fb300) and it required a hardfork to fix. + +Note that, with the current blob parameter schedule, it is actually only BPO1 which will cause the problem, not Fusaka itself. + + +- **Risk Assessment:** High severity, Medium Likelihood +- **Mitigations:** + - Get a basic release candidate ready as early as possible + - Communicate widely and clearly about the need to update and any live ops that need to happen. + - Take extra care when doing the _next_ upstream merge of op-geth, even after the Fusaka project is done. Are there any consensus changes we need to worry about? + +- **Detection:** + - We will know easily if we have made the releases on time. +- **Recovery Path(s)**: + - We may need a one-off fork to fix any chain split. + + + +### FM3: Unintended / incorrect behaviour by lagging behind upstream Geth +- **Description:** We made a decision to delay updating op-geth with the full changes from go-ethereum's official Fusaka release for testnets, and we will continue to wait to do that even when they make the official Fusaka release for mainnet. The reason for this was to delay the adoption of Go 1.24, which those releases would force us into, but which cost us operational time and effort. This is not as risky as it first appears, since we are not adopting Fusaka on L2. In fact it could be argued to be the less risky approach, since we make a much more targetted and tightly-scoped change to our existing state transition rules by going this route. Still, there is a chance we don't pull in an important bug fix or security patch. + + +- **Risk Assessment:** High severity, Low Likelihood +- **Mitigations:** + - Do a thorough review of the upstream merge we are **not** doing, to see if there are any critical fixes we are missing out on. + - Take extra care when doing the _next_ upstream merge of op-geth, even after the Fusaka project is done. Are there any consensus changes we need to worry about? + +- **Detection:** + - We may get an immunifi report or suffer an attack of some kind. +- **Recovery Path(s)**: + - If the above review reveals an important patch, we can cherry pick it into op-geth. @@ -63,19 +107,19 @@ The following table shows how each EIP from Fusaka (see [meta EIP](https://eips. | EIP | Description | Compatibility Concerns | Components Affected | | --- | --- | --- | --- | -| [7594](https://eips.ethereum.org/EIPS/eip-7594) | **PeerDAS (Headline feature)** | Blob Transaction senders must compute and attach “cell proofs”| `op-batcher` (tx-mgr), `proyxd`, `blob-archiver` | -| [7642](https://eips.ethereum.org/EIPS/eip-7642) | `eth/69` History expiry and simpler receipts | None | `op-geth` and `op-reth` | -| [7823](https://eips.ethereum.org/EIPS/eip-7823) | Set upper bounds for MODEXP | None | `op-geth` and `op-reth` | -| [7825](https://eips.ethereum.org/EIPS/eip-7825) | Transaction Gas Limit Cap | May limit superchain-ops (contract upgrade transactions on L1) and require them to be broken up. | `op-batcher`, `op-proposer`, `op-challenger`, `op-geth`, `op-reth` | -| [7883](https://eips.ethereum.org/EIPS/eip-7883) | ModExp Gas Cost Increase | Could effect the proofs system, making playing dispute games more expensive. | `op-challenger`, `op-proposer`, `op-geth`, `op-reth`, `contracts` | -| [7892](https://eips.ethereum.org/EIPS/eip-7892) | **Blob Parameter Only Hardforks (Headline feature)** | A framework to enable changing the blob schedule on L1 with less overhead / more frequently. Any such change will affect the L1 Cost, and a new prestate is implied when the schedule is updated. | `op-geth` and `op-reth` | +| [7594](https://eips.ethereum.org/EIPS/eip-7594) | **PeerDAS (Headline feature)** | Blob Transaction senders must compute and attach “cell proofs”| `op-batcher` (tx-mgr), `proyxd` | +| [7642](https://eips.ethereum.org/EIPS/eip-7642) | `eth/69` History expiry and simpler receipts | None | | +| [7823](https://eips.ethereum.org/EIPS/eip-7823) | Set upper bounds for MODEXP | None | | +| [7825](https://eips.ethereum.org/EIPS/eip-7825) | Transaction Gas Limit Cap | May limit superchain-ops (contract upgrade transactions on L1) and require them to be broken up. | `superchain-ops` | +| [7883](https://eips.ethereum.org/EIPS/eip-7883) | ModExp Gas Cost Increase | | | +| [7892](https://eips.ethereum.org/EIPS/eip-7892) | **Blob Parameter Only Hardforks (Headline feature)** | A framework to enable changing the blob schedule on L1 with less overhead / more frequently. Any such change will affect the L1 Cost, and a new prestate is implied when the schedule is updated. | `op-node` / `op-program` and `kona` | | [7917](https://eips.ethereum.org/EIPS/eip-7917) | Deterministic proposer lookahead | None, only affects consensus layer on L1 (PoS) | | -| [7918](https://eips.ethereum.org/EIPS/eip-7918) | Blob base fee bounded by execution cost | No action is necessary, since the change happens inside the `excessBlobGas` function. | `op-geth` and `op-reth` | -| [7934](https://eips.ethereum.org/EIPS/eip-7934) | RLP Execution Block Size Limit | Should be none, unless we have any huge L1 contracts that we exceed this limit. | `contracts`, `op-deployer`, block builders | +| [7918](https://eips.ethereum.org/EIPS/eip-7918) | Blob base fee bounded by execution cost | No action is necessary, since the change happens inside the `excessBlobGas` function. | | +| [7934](https://eips.ethereum.org/EIPS/eip-7934) | RLP Execution Block Size Limit | | | | [7935](https://eips.ethereum.org/EIPS/eip-7935) | Set default gas limit to XX0M | Actual limit not set yet. It will not decrease though, so should be backwards compatible. Doesn’t strictly require a hardfork. | | | [7939](https://eips.ethereum.org/EIPS/eip-7939) | Count Leading Zeros (CLZ) opcode | None | | -| [7951](https://eips.ethereum.org/EIPS/eip-7951) | Precompile for secp256r1 support | None | EL clients | -| [7910](https://eips.ethereum.org/EIPS/eip-7910) | eth_config JSON-RPC method | Non breaking change, no defence needed | `op-geth` and `op-reth` | +| [7951](https://eips.ethereum.org/EIPS/eip-7951) | Precompile for secp256r1 support | None | | +| [7910](https://eips.ethereum.org/EIPS/eip-7910) | eth_config JSON-RPC method | Non breaking change. | | ## Action Items @@ -83,11 +127,11 @@ The following table shows how each EIP from Fusaka (see [meta EIP](https://eips. Below is what needs to be done before launch to reduce the chances of the above failure modes occurring, and to ensure they can be detected and recovered from: - [ ] (BLOCKING): Resolve all comments on this document and incorporate them into the document itself (Assignee: document author) -- [ ] (BLOCKING): Action tests will be added which are run on op-node and Kona https://github.com/ethereum-optimism/optimism/issues/13967. Ideally they run against the usual mainline version of op-geth -- if this is not possible the tests can run against a patched version until op-geth is ready to support such tests. -- [ ] (BLOCKING): The changes will be deployed to a local multi-client devnet with both op-geth and op-reth running as well as Pectra activated on L1. https://github.com/ethereum-optimism/optimism/pull/14046 -- [ ] (non-BLOCKING): The changes will be deployed to a devnet which targets a public, Fusaka- and BPO1,2-enabled L1 [devnet]([url](https://devnets.optimism.io/balrog.html)) +- [ ] (BLOCKING): Action tests will be added which are run on op-node and Kona +- [ ] (BLOCKING): The changes will be deployed to a local multi-client devnet with both op-geth and op-reth running as well as Fusaka and BPO1 and BPO2 activated on L1. +- [ ] (non-BLOCKING): The changes will be deployed to a devnet which targets a Fusaka- and BPO1,2-enabled L1 - [ ] (non-BLOCKING): We will update the op-sepolia and op-mainnet vm-runners to use the new absolute prestate. The vm-runner runs the op-program in the MIPS FPVM using inputs sampled from a live chain. - +- [ ] (non-BLOCKING) Do a review of the upstream merge which we are **not yet adopting** https://github.com/ethereum-optimism/op-geth/pull/689. From 23b329d2dd369c2d94194c0cc7edac7911b4c690 Mon Sep 17 00:00:00 2001 From: geoknee Date: Thu, 2 Oct 2025 15:45:58 +0100 Subject: [PATCH 05/14] format --- security/fma-l1-fusaka.md | 128 +++++++++++++++++++++----------------- 1 file changed, 71 insertions(+), 57 deletions(-) diff --git a/security/fma-l1-fusaka.md b/security/fma-l1-fusaka.md index 58e522da..1cc6d22b 100644 --- a/security/fma-l1-fusaka.md +++ b/security/fma-l1-fusaka.md @@ -13,7 +13,7 @@ | | | | ------------------- | ------------------- | | Author | George Knee | -| Created at | 2nd October 2025 | +| Created at | 2nd October 2025 | | Needs Approval From | | | Other Reviewers | | | Status | DRAFT | @@ -37,102 +37,116 @@ Below are references for this project: ## Failure Modes and Recovery Paths -### FM1: op-batcher release not rolled out in time +### FM1: `op-batcher` release not rolled out in time -- **Description:** There is a chance we don't ship the changes we need to op-batcher, before the forks activate on L1. Also a problem if node or chain operators fail to update in time, even if our releases are available. The impact would be a safe head stall and sequencer window expiry / reorg if the L1 rejects the batcher's blob transactions. This can happen even in the patched batcher, if a config flag is not flipped, +- **Description:** + There is a chance we don't ship the changes we need to `op-batcher` before the forks activate on L1. + Also a problem if node or chain operators fail to update in time, even if our releases are available. + The impact would be a safe head stall and sequencer window expiry / reorg if the L1 rejects the batcher's blob transactions. + This can happen even in the patched batcher, if a config flag is not flipped. - **Risk Assessment:** High severity, Medium Likelihood - **Mitigations:** - Get a basic release candidate ready as early as possible - - Communicate widely and clearly about the need to update and any live ops that need to happen. + - Communicate widely and clearly about the need to update and any live ops that need to happen - Check with L1 nodes on already forked networks: do they accept legacy batcher blob transactions? - **Detection:** - Usual alerts and dashboards -- **Recovery Path(s)**: - - Even an old batcher can switch to calldata as a good mitigation +- **Recovery Path(s):** + - Even an old batcher can switch to calldata as a good mitigation -### FM2: op-node or kona node release not rolled out in time +--- -- **Description:** There is a chance we don't ship the changes we need to op-node or kona node, before the forks activate on L1. For example, the code we need to patch op-node exists in go-ethereum, but is only released late on in the development cycle (close to when we need to ship the patch). Also a problem if node or chain operators fail to update in time, even if our releases are available. The impact would be an incorrect blob base fee, causing L2 users to be excessively overcharged, even leading to an effective denial of service due to high fees on L2. Moreover, there is a likelihood of a chain split if nodes are updated in an uncoordinated way. We have seen this failure mode [play out on Sepolia](https://www.notion.so/oplabs/OP-Sepolia-L1-Cost-Blob-Schedule-Bug-1adf153ee1628009b429ee10828fb300#1adf153ee1628009b429ee10828fb300) and it required a hardfork to fix. +### FM2: `op-node` or `kona` node release not rolled out in time -Note that, with the current blob parameter schedule, it is actually only BPO1 which will cause the problem, not Fusaka itself. +- **Description:** + There is a chance we don't ship the changes we need to `op-node` or `kona` before the forks activate on L1. + For example, the code we need to patch `op-node` exists in go-ethereum, but is only released late in the development cycle. + Also a problem if node or chain operators fail to update in time, even if our releases are available. + The impact would be: + - Incorrect blob base fee → L2 users overcharged + - Possible denial of service due to high L2 fees + - Chain split if nodes update uncoordinatedly -- **Risk Assessment:** High severity, Medium Likelihood + We have seen this failure mode [play out on Sepolia](https://www.notion.so/oplabs/OP-Sepolia-L1-Cost-Blob-Schedule-Bug-1adf153ee1628009b429ee10828fb300#1adf153ee1628009b429ee10828fb300), requiring a hardfork to fix. + + With the current blob parameter schedule, only BPO1 causes the problem, not Fusaka itself. + +- **Risk Assessment:** High severity, Medium Likelihood - **Mitigations:** - - Get a basic release candidate ready as early as possible - - Communicate widely and clearly about the need to update and any live ops that need to happen. - - Take extra care when doing the _next_ upstream merge of op-geth, even after the Fusaka project is done. Are there any consensus changes we need to worry about? + - Prepare release candidate early + - Communicate clearly about upgrade requirements + - Take extra care in the *next* upstream merge of `op-geth` (post-Fusaka) for consensus changes - **Detection:** - - We will know easily if we have made the releases on time. -- **Recovery Path(s)**: - - We may need a one-off fork to fix any chain split. - + - Obvious if releases aren’t shipped on time +- **Recovery Path(s):** + - One-off fork may be needed to fix chain split +--- -### FM3: Unintended / incorrect behaviour by lagging behind upstream Geth -- **Description:** We made a decision to delay updating op-geth with the full changes from go-ethereum's official Fusaka release for testnets, and we will continue to wait to do that even when they make the official Fusaka release for mainnet. The reason for this was to delay the adoption of Go 1.24, which those releases would force us into, but which cost us operational time and effort. This is not as risky as it first appears, since we are not adopting Fusaka on L2. In fact it could be argued to be the less risky approach, since we make a much more targetted and tightly-scoped change to our existing state transition rules by going this route. Still, there is a chance we don't pull in an important bug fix or security patch. +### FM3: Lagging behind upstream Geth +- **Description:** + We decided to delay updating `op-geth` with Fusaka changes, to avoid forced Go 1.24 adoption. + This is lower risk since L2 does not adopt Fusaka directly. However, we may miss bug/security patches upstream. - **Risk Assessment:** High severity, Low Likelihood - **Mitigations:** - - Do a thorough review of the upstream merge we are **not** doing, to see if there are any critical fixes we are missing out on. - - Take extra care when doing the _next_ upstream merge of op-geth, even after the Fusaka project is done. Are there any consensus changes we need to worry about? - + - Thoroughly review the skipped upstream merge for critical patches + - Take extra care in the next merge post-Fusaka - **Detection:** - - We may get an immunifi report or suffer an attack of some kind. -- **Recovery Path(s)**: - - If the above review reveals an important patch, we can cherry pick it into op-geth. - - + - Immunefi report or an exploit +- **Recovery Path(s):** + - Cherry-pick missing fixes into `op-geth` +--- ## Generic Items -Although this upgrade is technically a soft fork (it does not need to be coordinated across nodes other than being applied before Pectra activates on L1) many of the items in [./fma-generic-hardfork.md](./fma-generic-hardfork.md) apply. In particular: +Although this upgrade is technically a soft fork, many of the items in [fma-generic-hardfork.md](./fma-generic-hardfork.md) apply: + +- Chain Halt at activation +- Invalid `DisputeGameFactory.setImplementation` execution +- Chain split across clients -- Chain Halt at activation. -- Invalid `DisputeGameFactory.setImplementation` execution. -- Chain split across clients. +- [x] Confirm these items have been considered and updated if necessary. -- [x] Check this box to confirm that these items have been considered and updated if necessary. +--- ## Audit Requirements -## Appendix +(tbd) + +--- -The following table shows how each EIP from Fusaka (see [meta EIP](https://eips.ethereum.org/EIPS/eip-7607)) will affect OPStack chains: +## Appendix | EIP | Description | Compatibility Concerns | Components Affected | | --- | --- | --- | --- | -| [7594](https://eips.ethereum.org/EIPS/eip-7594) | **PeerDAS (Headline feature)** | Blob Transaction senders must compute and attach “cell proofs”| `op-batcher` (tx-mgr), `proyxd` | -| [7642](https://eips.ethereum.org/EIPS/eip-7642) | `eth/69` History expiry and simpler receipts | None | | +| [7594](https://eips.ethereum.org/EIPS/eip-7594) | **PeerDAS (Headline feature)** | Blob Tx senders must compute and attach “cell proofs” | `op-batcher` (tx-mgr), `proyxd` | +| [7642](https://eips.ethereum.org/EIPS/eip-7642) | `eth/69` History expiry & simpler receipts | None | | | [7823](https://eips.ethereum.org/EIPS/eip-7823) | Set upper bounds for MODEXP | None | | -| [7825](https://eips.ethereum.org/EIPS/eip-7825) | Transaction Gas Limit Cap | May limit superchain-ops (contract upgrade transactions on L1) and require them to be broken up. | `superchain-ops` | -| [7883](https://eips.ethereum.org/EIPS/eip-7883) | ModExp Gas Cost Increase | | | -| [7892](https://eips.ethereum.org/EIPS/eip-7892) | **Blob Parameter Only Hardforks (Headline feature)** | A framework to enable changing the blob schedule on L1 with less overhead / more frequently. Any such change will affect the L1 Cost, and a new prestate is implied when the schedule is updated. | `op-node` / `op-program` and `kona` | -| [7917](https://eips.ethereum.org/EIPS/eip-7917) | Deterministic proposer lookahead | None, only affects consensus layer on L1 (PoS) | | -| [7918](https://eips.ethereum.org/EIPS/eip-7918) | Blob base fee bounded by execution cost | No action is necessary, since the change happens inside the `excessBlobGas` function. | | -| [7934](https://eips.ethereum.org/EIPS/eip-7934) | RLP Execution Block Size Limit | | | -| [7935](https://eips.ethereum.org/EIPS/eip-7935) | Set default gas limit to XX0M | Actual limit not set yet. It will not decrease though, so should be backwards compatible. Doesn’t strictly require a hardfork. | | -| [7939](https://eips.ethereum.org/EIPS/eip-7939) | Count Leading Zeros (CLZ) opcode | None | | +| [7825](https://eips.ethereum.org/EIPS/eip-7825) | Tx Gas Limit Cap | May limit `superchain-ops` on L1 | `superchain-ops` | +| [7883](https://eips.ethereum.org/EIPS/eip-7883) | ModExp Gas Cost Increase | Increases cost of dispute games | | +| [7892](https://eips.ethereum.org/EIPS/eip-7892) | **Blob Parameter Only Hardforks (Headline feature)** | Framework for blob schedule changes; affects L1 cost; new prestate implied | `op-node` / `op-program`, `kona` | +| [7917](https://eips.ethereum.org/EIPS/eip-7917) | Deterministic proposer lookahead | None (L1 PoS only) | | +| [7918](https://eips.ethereum.org/EIPS/eip-7918) | Blob base fee bounded by execution cost | No action needed (`excessBlobGas`) | | +| [7934](https://eips.ethereum.org/EIPS/eip-7934) | RLP Execution Block Size Limit | TBD | | +| [7935](https://eips.ethereum.org/EIPS/eip-7935) | Default gas limit to XX0M | Backwards compatible | | +| [7939](https://eips.ethereum.org/EIPS/eip-7939) | CLZ opcode | None | | | [7951](https://eips.ethereum.org/EIPS/eip-7951) | Precompile for secp256r1 support | None | | -| [7910](https://eips.ethereum.org/EIPS/eip-7910) | eth_config JSON-RPC method | Non breaking change. | | +| [7910](https://eips.ethereum.org/EIPS/eip-7910) | `eth_config` JSON-RPC method | Non-breaking | | +--- ## Action Items -Below is what needs to be done before launch to reduce the chances of the above failure modes occurring, and to ensure they can be detected and recovered from: - -- [ ] (BLOCKING): Resolve all comments on this document and incorporate them into the document itself (Assignee: document author) -- [ ] (BLOCKING): Action tests will be added which are run on op-node and Kona -- [ ] (BLOCKING): The changes will be deployed to a local multi-client devnet with both op-geth and op-reth running as well as Fusaka and BPO1 and BPO2 activated on L1. -- [ ] (non-BLOCKING): The changes will be deployed to a devnet which targets a Fusaka- and BPO1,2-enabled L1 -- [ ] (non-BLOCKING): We will update the op-sepolia and op-mainnet vm-runners to use the new absolute prestate. The vm-runner runs the op-program in the MIPS FPVM using inputs sampled from a live chain. -- [ ] (non-BLOCKING) Do a review of the upstream merge which we are **not yet adopting** https://github.com/ethereum-optimism/op-geth/pull/689. - - - - +- [ ] (BLOCKING) Resolve comments and incorporate into doc +- [ ] (BLOCKING) Add action tests for `op-node` and `kona` +- [ ] (BLOCKING) Deploy to local multi-client devnet (op-geth + op-reth + Fusaka + BPO1/BPO2) +- [ ] (non-BLOCKING) Deploy to public Fusaka/BPO-enabled devnet +- [ ] (non-BLOCKING) Update `op-sepolia` & `op-mainnet` vm-runners with new absolute prestate +- [ ] (non-BLOCKING) Review skipped upstream merge [op-geth#689](https://github.com/ethereum-optimism/op-geth/pull/689) From d852d379b88a277f5273144bc1daf1e0957529c1 Mon Sep 17 00:00:00 2001 From: geoknee Date: Thu, 2 Oct 2025 15:46:20 +0100 Subject: [PATCH 06/14] no audit --- security/fma-l1-fusaka.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/security/fma-l1-fusaka.md b/security/fma-l1-fusaka.md index 1cc6d22b..38fb7933 100644 --- a/security/fma-l1-fusaka.md +++ b/security/fma-l1-fusaka.md @@ -118,7 +118,7 @@ Although this upgrade is technically a soft fork, many of the items in [fma-gene ## Audit Requirements -(tbd) +none --- From e3b9634b454da70745078774e7bd6512397784d8 Mon Sep 17 00:00:00 2001 From: geoknee Date: Thu, 2 Oct 2025 15:49:53 +0100 Subject: [PATCH 07/14] remove toc --- security/fma-l1-fusaka.md | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/security/fma-l1-fusaka.md b/security/fma-l1-fusaka.md index 38fb7933..af0030c6 100644 --- a/security/fma-l1-fusaka.md +++ b/security/fma-l1-fusaka.md @@ -1,15 +1,5 @@ # Upgrade 16b (L1 Fusaka Defense): Failure Modes and Recovery Path Analysis - - - -- [Introduction](#introduction) -- [Generic Items](#generic-items) -- [Audit Requirements](#audit-requirements) -- [Action Items](#action-items) - - - | | | | ------------------- | ------------------- | | Author | George Knee | From 4719e13464d444744a8d544a0535b402c00efac9 Mon Sep 17 00:00:00 2001 From: geoknee Date: Thu, 2 Oct 2025 15:50:29 +0100 Subject: [PATCH 08/14] Revert "remove toc" This reverts commit e3b9634b454da70745078774e7bd6512397784d8. --- security/fma-l1-fusaka.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/security/fma-l1-fusaka.md b/security/fma-l1-fusaka.md index af0030c6..38fb7933 100644 --- a/security/fma-l1-fusaka.md +++ b/security/fma-l1-fusaka.md @@ -1,5 +1,15 @@ # Upgrade 16b (L1 Fusaka Defense): Failure Modes and Recovery Path Analysis + + + +- [Introduction](#introduction) +- [Generic Items](#generic-items) +- [Audit Requirements](#audit-requirements) +- [Action Items](#action-items) + + + | | | | ------------------- | ------------------- | | Author | George Knee | From c9181736c1547d6f1b9f5ea0f516740676106d2a Mon Sep 17 00:00:00 2001 From: geoknee Date: Thu, 2 Oct 2025 16:19:03 +0100 Subject: [PATCH 09/14] tweak --- security/fma-l1-pectra.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/security/fma-l1-pectra.md b/security/fma-l1-pectra.md index 9630353a..0518c057 100644 --- a/security/fma-l1-pectra.md +++ b/security/fma-l1-pectra.md @@ -25,14 +25,11 @@ This document is intended to be shared in a public space for reviews and visibil - (Consensus Layer) Ability to parse and validate blocks and receipts with EIP-7702 transactions, as well as blocks with a non-nil EIP-7685 requestsHash field. - (Smart Contracts) For chains using Fault Proofs, L1 contracts updates which reference an updated absolute prestate hash. -Each change has its own section below with a list of Failure Modes. - Below are references for this project: - [Github tracker](https://github.com/orgs/ethereum-optimism/projects/84/views/11) - [Specs clarification (Logs)](https://specs.optimism.io/protocol/derivation.html#on-future-proof-transaction-log-derivation) - [Specs clarification (L1 Retrieval)](https://specs.optimism.io/protocol/derivation.html#l1-retrieval) -- [OP Contracts Manager specs](https://specs.optimism.io/experimental/op-contracts-manager.html?highlight=opcm#op-contracts-manager) - [Optimism Docs on Pectra (including L1 activation times)](https://docs.optimism.io/notices/pectra-changes) ## Failure Modes and Recovery Paths From 8ec2da02792f2cb35e6f4cbf4c539c22513731e9 Mon Sep 17 00:00:00 2001 From: geoknee Date: Mon, 6 Oct 2025 16:01:21 +0100 Subject: [PATCH 10/14] add failure mode for beacon API changes --- security/fma-l1-fusaka.md | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/security/fma-l1-fusaka.md b/security/fma-l1-fusaka.md index 38fb7933..852ae0c6 100644 --- a/security/fma-l1-fusaka.md +++ b/security/fma-l1-fusaka.md @@ -58,7 +58,29 @@ Below are references for this project: --- -### FM2: `op-node` or `kona` node release not rolled out in time +### FM2a: `op-node` or `kona` node release not rolled out in time (blob verification) + +- **Description:** + There is a chance we don't ship the changes we need to `op-node` or `kona` before the forks activate on L1. + Changes to the beacon API https://ethereum.github.io/beacon-APIs/?urls.primaryName=dev are breaking with respect + to the current op-node, op-program and kona. Both rely on the `/eth/v1/beacon/blob_sidecars` API which is being + deprecated. It will be replaced with `/eth/v1/beacon/blobs`, which has the notable difference that it does + not return KZG commitments or KZG blob proofs (see [EIP 4844](https://eips.ethereum.org/EIPS/eip-4844)). The + affected components will be updated to i) pull blobs from the new endpoint once it is available and ii) perform + blob verification _without_ the aid of a KZG proof. If either fix fails to deploy in time there would be a + safe head stall and possible eventual sequencer window expiry. + +- **Risk Assessment:** Medium severity, Medium Likelihood +- **Mitigations:** + - Prepare release candidate early and test on L1-Fusaka-enabled devnets + - Communicate clearly about upgrade requirements + +- **Detection:** + - Usual monitoring / alerts +- **Recovery Path(s):** + - Switch the batcher to use calldata + +### FM2c: `op-node` or `kona` node release not rolled out in time (blob base fee calculation) - **Description:** There is a chance we don't ship the changes we need to `op-node` or `kona` before the forks activate on L1. From 7ba83988d48c44ccdc700144c1207be2416b945b Mon Sep 17 00:00:00 2001 From: geoknee Date: Mon, 6 Oct 2025 16:11:08 +0100 Subject: [PATCH 11/14] updates based on review --- security/fma-generic-hardfork.md | 4 ++-- security/fma-l1-fusaka.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/security/fma-generic-hardfork.md b/security/fma-generic-hardfork.md index 728de5b9..9f2423fe 100644 --- a/security/fma-generic-hardfork.md +++ b/security/fma-generic-hardfork.md @@ -62,9 +62,9 @@ Since there is no chain halt, we can just live with it and fix it in an upcoming - **Recovery Path(s)**: Reschedule the upgrade, releasing a new binary (without immediate urgency). -#### Invalid `DisputeGameFactory.setImplementation` execution +#### Invalid prestate supplied to the OP Contracts Manager (OPCM) -- **Description:** This occurs when either the call to the `DisputeGameFactory` could not be made due to grossly unfavorable base fees on L1, an invalidly approved safe nonce, or a successful execution to a misconfigured dispute game implementation. +- **Description:** This occurs when either the call to the `OPCM` could not be made due to grossly unfavorable base fees on L1, an invalidly approved safe nonce, or a successful execution to an incorrect prestate. - **Risk Assessment:** - Low likelihood. The low likelihood is a result of tenderly simulation testing of safe transactions, code review of the upgrade playbook, and manual review of the dispute game implementations (which are deployed on mainnet and specified in the governance proposal so they may be reviewed). diff --git a/security/fma-l1-fusaka.md b/security/fma-l1-fusaka.md index 852ae0c6..01e3333f 100644 --- a/security/fma-l1-fusaka.md +++ b/security/fma-l1-fusaka.md @@ -128,10 +128,10 @@ Below are references for this project: ## Generic Items -Although this upgrade is technically a soft fork, many of the items in [fma-generic-hardfork.md](./fma-generic-hardfork.md) apply: +This upgrade is an unnamed L2 hardfork, activated by an L1 hardfork: so the items in [fma-generic-hardfork.md](./fma-generic-hardfork.md) apply: - Chain Halt at activation -- Invalid `DisputeGameFactory.setImplementation` execution +- Invalid absolute prestate provided. - Chain split across clients - [x] Confirm these items have been considered and updated if necessary. From b4000ced546b3613ab0efeb38383aa5b4700148c Mon Sep 17 00:00:00 2001 From: geoknee Date: Mon, 6 Oct 2025 21:18:44 +0100 Subject: [PATCH 12/14] add FM3 --- security/fma-l1-fusaka.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/security/fma-l1-fusaka.md b/security/fma-l1-fusaka.md index 01e3333f..18da4d58 100644 --- a/security/fma-l1-fusaka.md +++ b/security/fma-l1-fusaka.md @@ -126,6 +126,27 @@ Below are references for this project: --- +### FM4: New chain deployments consume more than 16,777,216 gas + +- **Description:** + EIP [7825](https://eips.ethereum.org/EIPS/eip-7825) introduces a + per-transaction gas cap, which our standard deployment + might well exceed (especially with more dispute game types being deployed)., + +- **Risk Assessment:** Low severity, High Likelihood +- **Mitigations:** + - Deploy Fusaka goes live (not ideal) + - Avoid expanding the set of standard contracts deployed + - Tune the "padding" we apply in `op-deployer` (see https://github.com/ethereum-optimism/optimism/pull/17710) + - Rearchitect the deployment script to break up the transaction into several smaller transactions +- **Detection:** + - Obvious, deployment transaction reverts +- **Recovery Path(s):** + - N/A + +--- + + ## Generic Items This upgrade is an unnamed L2 hardfork, activated by an L1 hardfork: so the items in [fma-generic-hardfork.md](./fma-generic-hardfork.md) apply: From ef5d6832c8ce73b66380ceba113198704b0faa19 Mon Sep 17 00:00:00 2001 From: geoknee Date: Mon, 6 Oct 2025 21:19:54 +0100 Subject: [PATCH 13/14] typos --- security/fma-l1-fusaka.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/security/fma-l1-fusaka.md b/security/fma-l1-fusaka.md index 18da4d58..3d84b4fa 100644 --- a/security/fma-l1-fusaka.md +++ b/security/fma-l1-fusaka.md @@ -131,11 +131,11 @@ Below are references for this project: - **Description:** EIP [7825](https://eips.ethereum.org/EIPS/eip-7825) introduces a per-transaction gas cap, which our standard deployment - might well exceed (especially with more dispute game types being deployed)., + might well exceed (especially with more dispute game types being deployed). - **Risk Assessment:** Low severity, High Likelihood - **Mitigations:** - - Deploy Fusaka goes live (not ideal) + - Deploy before Fusaka goes live (only works for a short time) - Avoid expanding the set of standard contracts deployed - Tune the "padding" we apply in `op-deployer` (see https://github.com/ethereum-optimism/optimism/pull/17710) - Rearchitect the deployment script to break up the transaction into several smaller transactions From 244177d9a8b5875e0d00bb33a2bb3786f6d173b7 Mon Sep 17 00:00:00 2001 From: George Knee Date: Tue, 7 Oct 2025 10:34:38 +0100 Subject: [PATCH 14/14] Update security/fma-l1-fusaka.md Co-authored-by: Josh Klopfenstein --- security/fma-l1-fusaka.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/security/fma-l1-fusaka.md b/security/fma-l1-fusaka.md index 3d84b4fa..7b4a3655 100644 --- a/security/fma-l1-fusaka.md +++ b/security/fma-l1-fusaka.md @@ -63,7 +63,7 @@ Below are references for this project: - **Description:** There is a chance we don't ship the changes we need to `op-node` or `kona` before the forks activate on L1. Changes to the beacon API https://ethereum.github.io/beacon-APIs/?urls.primaryName=dev are breaking with respect - to the current op-node, op-program and kona. Both rely on the `/eth/v1/beacon/blob_sidecars` API which is being + to the current op-node, op-program and kona. All three rely on the `/eth/v1/beacon/blob_sidecars` API which is being deprecated. It will be replaced with `/eth/v1/beacon/blobs`, which has the notable difference that it does not return KZG commitments or KZG blob proofs (see [EIP 4844](https://eips.ethereum.org/EIPS/eip-4844)). The affected components will be updated to i) pull blobs from the new endpoint once it is available and ii) perform