feat: add FMA for operator fee

security/fma-generic-hardfork.md

@@ -86,3 +86,17 @@ Since there is no chain halt, we can just live with it and fix it in an upcoming
 - [ ] ACTION ITEM (BLOCKING): We have implemented extensive cross-client / differential testing of the new functionality.
 - **Detection:** Replicas of one kind of client will diverge from the sequencer
 - **Recovery Path(s)**: Most likely we would have the op-node/op-geth chain be the canonical one as this is the reference implementation. Other clients would need to be patched to resolve any discrepancies.
+
+### Operator fee: `L1Block` badly hydrated
+
+- **Description:** At each hardfork, new data can be add to the `L1Block` contract, and the method called to hydrate it change (for instance
+    `setL1BlockValuesEcotone` to `setL1BlockValuesIsthmus`). If there is a bug in a future method ending up to operator fee params no
+    longer being updated in the `L1Block` contract, the operator fee will no longer be taken into account in transactions fee.
+- **Risk Assessment:** medium severity / low likelihood
+- **Mitigations:** 
+    Add end to end tests to ensure that the operator fee is taken into account in transactions fee.
+- **Detection:** 
+    Monitor the operator fee vault balance and alert if it's no longer increasing for every transactions.
+- **Recovery Path(s):**
+    - If the bug is located in op-node, a new version must be deployed.
+    - If the bug is located in the `L1Block` contract, the contract must be upgraded to fix the bug.

security/fma-operator-fee.md

@@ -0,0 +1,99 @@
+# [Operator Fee]: Failure Modes and Recovery Path Analysis
+
+<!-- START doctoc generated TOC please keep comment here to allow auto update -->
+<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
+
+- [Introduction](#introduction)
+- [Failure Modes and Recovery Paths](#failure-modes-and-recovery-paths)
+  - [FM1: Operator Fee scalars are set to incorrect values](#fm1-operator-fee-scalars-are-set-to-incorrect-values)
+  - [FM2: Broken Fee Estimation (Wallets)](#fm2-broken-fee-estimation-wallets)
+  - [FM3: Bug in Receipt Hydrating Logic](#fm3-bug-in-receipt-hydrating-logic)
+  - [FM4: Database Growth Impact on Nodes](#fm4-database-growth-impact-on-nodes)
+- [Action Items](#action-items)
+
+<!-- END doctoc generated TOC please keep comment here to allow auto update -->
+
+|                    |                                                    |
+| ------------------ | -------------------------------------------------- |
+| Author             | leruaa                                             |
+| Created at         | 2025-01-08                                         |
+| Initial Reviewers  |                                                    |
+| Need Approval From | maurelian                                          |
+| Status             | Draft                                              |
+
+## Introduction
+
+This document covers initial deployment of Operator Fee.
+
+The OperatorFee is a new transaction fee that allows new OP chain variants to account for their unique cost structure. For example, the existing fee structure isn't friendly to chains using alt-DA's, since the l1fee only accounts for Ethereum's blobGasFee instead of an alt-DA's fee.
+
+Also, For OP Stack variants that want to utilize ZK proofs, the cost of ZK proving a transaction is a significant resource that is not taken into consideration in the current fee structure.
+
+Below are references for this project:
+
+- [Design Doc](../protocol/operator-fee.md)
+- [Spec](https://github.com/ethereum-optimism/specs/pull/382)
+
+## Failure Modes and Recovery Paths
+
+### FM1: Operator Fee scalars are set to incorrect values
+
+- **Description:** 
+  If the operator fee scalars are incorrectly initialized or updated, there is a risk that the transcations fees will be too high. This could lead to a situation where the chain become unusable.
+- **Risk Assessment:**
+  High impact, low likelihood.
+  **Mitigations:**
+  Every update to the operator fee scalars should be carefully tested and reviewed before deployment.
+- **Detection:** 
+  Monitoring gas cost estimation.
+- **Recovery Path(s)**:
+  If the operator fee parameters are set to unreasonable values, the rollup operator should update the `operatorFeeScalar` and `operatorFeeConstant` to reasonable values as soon as possible.
+
+### FM2: Broken Fee Estimation (Wallets)
+
+- **Description:** 
+  If wallets fail to update their fee estimation logic, users will no longer be shown the accurate costs of a transaction.
+- **Risk Assessment:**
+  Medium impact, medium likelihood.
+  **Mitigations:**
+  Coordinate with wallet providers to update their fee estimation logic. This includes MetaMask, Coinbase Wallet, and others.
+- **Detection:** 
+  Confirm that wallets are using the correct fee estimation logic post-launch. This can be done manually on chains that have added an operator fee.
+- **Recovery Path(s)**:
+  Notify wallets of the new fee structure and ask them to update their fee estimation logic if the operator fee is enabled.
+
+### FM3: Bug in Receipt Hydrating Logic
+
+- **Description:**
+  If there is a bug in the receipt hydrating logic, the operator fee may not be correctly reflected in transaction receipts, leading to incorrect fee reporting and potential accounting issues.
+- **Risk Assessment:**
+  Medium impact, low likelihood.
+- **Mitigations:**
+  Extensive testing of receipt hydration with various transaction types and fee configurations. Ensure backwards compatibility with existing receipt formats.
+- **Detection:**
+  Monitor transaction receipts and compare reported fees with expected calculations. Watch for discrepancies in accounting systems.
+- **Recovery Path(s):**
+  Deploy fix for receipt hydration logic. Historical receipts will remain incorrect but can be recalculated using on-chain data if needed.
+
+### FM4: Database Growth Impact on Nodes
+
+- **Description:**
+  The addition of operator fee fields increases the size of transaction receipts, leading to faster database growth. This could accelerate the need for solutions like EIP-4444 or other history expiry mechanisms.
+- **Risk Assessment:**
+  Medium impact, high likelihood.
+- **Mitigations:**
+  - Implement history expiry solutions like EIP-4444 when available.
+- **Detection:**
+  - Monitor database growth rate compared to pre operator fee baseline.
+  - Track disk usage metrics across internal nodes.
+- **Recovery Path(s):**
+  - Use archive nodes to maintain historical data.
+  - Consider implementing receipt compression retroactively if needed.
+
+## 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:
+
+- [ ] Resolve all comments on this document and incorporate them into the document itself (Assignee: document author)
+- [ ] _Action item 2 (Assignee: tag assignee)_
+- [ ] _Action item 3 (Assignee: tag assignee)_