From 93eee24d5343dfef4cad5d373b578a18bd2d863b Mon Sep 17 00:00:00 2001 From: leruaa Date: Wed, 8 Jan 2025 06:42:07 -0800 Subject: [PATCH 01/12] add FMA for operator fee --- security/fma-operator-fee.md | 59 ++++++++++++++++++++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 security/fma-operator-fee.md diff --git a/security/fma-operator-fee.md b/security/fma-operator-fee.md new file mode 100644 index 00000000..8f34e524 --- /dev/null +++ b/security/fma-operator-fee.md @@ -0,0 +1,59 @@ +# [Operator Fee]: Failure Modes and Recovery Path Analysis + + + + +- [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) + - [Generic items we need to take into account:](#generic-items-we-need-to-take-into-account) +- [Action Items](#action-items) + + + +| | | +| ------------------ | -------------------------------------------------- | +| 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. + +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 operator fee scalars update 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. + +### Generic items we need to take into account: + +See [./fma-generic-hardfork.md](./fma-generic-hardfork.md). + +- [X] Check this box to confirm that these items have been considered and updated if necessary. + +## 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)_ From f4b61a50fc4e6f8a0f2ce9c24bf5dd5d1b00a9fc Mon Sep 17 00:00:00 2001 From: leruaa Date: Fri, 10 Jan 2025 12:34:33 -0800 Subject: [PATCH 02/12] feedbacks --- security/fma-operator-fee.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/security/fma-operator-fee.md b/security/fma-operator-fee.md index 8f34e524..5f47ba2a 100644 --- a/security/fma-operator-fee.md +++ b/security/fma-operator-fee.md @@ -25,6 +25,8 @@ 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) @@ -36,9 +38,10 @@ Below are references for this project: - **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. +- **Risk Assessment:** + High impact, low likelihood. **Mitigations:** - Every operator fee scalars update should be carefully tested and reviewed before deployment. + Every update to the operator fee scalars should be carefully tested and reviewed before deployment. - **Detection:** Monitoring gas cost estimation. - **Recovery Path(s)**: From 389b9cd1b46a1c1c6e3ba967effa47d9309a169d Mon Sep 17 00:00:00 2001 From: Ratan Kaliani Date: Mon, 3 Feb 2025 11:46:48 -0800 Subject: [PATCH 03/12] feat: add more failure modes --- security/fma-operator-fee.md | 42 ++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/security/fma-operator-fee.md b/security/fma-operator-fee.md index 5f47ba2a..7be50336 100644 --- a/security/fma-operator-fee.md +++ b/security/fma-operator-fee.md @@ -47,6 +47,48 @@ Below are references for this project: - **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. + + ### Generic items we need to take into account: See [./fma-generic-hardfork.md](./fma-generic-hardfork.md). From d801ed227af8c8ff36499a69977cef491e3e0186 Mon Sep 17 00:00:00 2001 From: Ratan Kaliani Date: Mon, 3 Feb 2025 12:32:37 -0800 Subject: [PATCH 04/12] fix: TOC --- security/fma-operator-fee.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/security/fma-operator-fee.md b/security/fma-operator-fee.md index 7be50336..2ef84bb1 100644 --- a/security/fma-operator-fee.md +++ b/security/fma-operator-fee.md @@ -6,6 +6,9 @@ - [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) - [Generic items we need to take into account:](#generic-items-we-need-to-take-into-account) - [Action Items](#action-items) From 2dc92dbb3fd6bab5525bb64129022f6885f0ffd9 Mon Sep 17 00:00:00 2001 From: Ratan Kaliani Date: Mon, 3 Feb 2025 12:36:51 -0800 Subject: [PATCH 05/12] feat: remove generic items --- security/fma-operator-fee.md | 8 -------- 1 file changed, 8 deletions(-) diff --git a/security/fma-operator-fee.md b/security/fma-operator-fee.md index 2ef84bb1..0b9f6ef1 100644 --- a/security/fma-operator-fee.md +++ b/security/fma-operator-fee.md @@ -9,7 +9,6 @@ - [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) - - [Generic items we need to take into account:](#generic-items-we-need-to-take-into-account) - [Action Items](#action-items) @@ -91,13 +90,6 @@ Below are references for this project: - Use archive nodes to maintain historical data. - Consider implementing receipt compression retroactively if needed. - -### Generic items we need to take into account: - -See [./fma-generic-hardfork.md](./fma-generic-hardfork.md). - -- [X] Check this box to confirm that these items have been considered and updated if necessary. - ## 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: From 467dd1990604d8296a6c69174d99faa876ff6d02 Mon Sep 17 00:00:00 2001 From: leruaa Date: Tue, 4 Feb 2025 07:43:30 -0800 Subject: [PATCH 06/12] feat: add a generic item --- security/fma-generic-hardfork.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/security/fma-generic-hardfork.md b/security/fma-generic-hardfork.md index 4407ad52..eeb78fbc 100644 --- a/security/fma-generic-hardfork.md +++ b/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. \ No newline at end of file From 6fa315d6261d25e9ac7b2acccb8e3c339ad17e15 Mon Sep 17 00:00:00 2001 From: leruaa Date: Mon, 10 Feb 2025 06:08:42 -0800 Subject: [PATCH 07/12] fix: handle feedbacks --- security/fma-generic-hardfork.md | 14 -------------- security/fma-operator-fee.md | 32 ++++++++++++++++++++++++-------- 2 files changed, 24 insertions(+), 22 deletions(-) diff --git a/security/fma-generic-hardfork.md b/security/fma-generic-hardfork.md index eeb78fbc..4407ad52 100644 --- a/security/fma-generic-hardfork.md +++ b/security/fma-generic-hardfork.md @@ -86,17 +86,3 @@ 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. \ No newline at end of file diff --git a/security/fma-operator-fee.md b/security/fma-operator-fee.md index 0b9f6ef1..cd98fb81 100644 --- a/security/fma-operator-fee.md +++ b/security/fma-operator-fee.md @@ -19,7 +19,7 @@ | Created at | 2025-01-08 | | Initial Reviewers | | | Need Approval From | maurelian | -| Status | Draft | +| Status | In Review | ## Introduction @@ -43,9 +43,9 @@ Below are references for this project: - **Risk Assessment:** High impact, low likelihood. **Mitigations:** - Every update to the operator fee scalars should be carefully tested and reviewed before deployment. + Before setting or updating the operator fee params, the operator should carefully read the [corresponding specs](https://specs.optimism.io/protocol/isthmus/exec-engine.html#operator-fee) and simulate the impact of operator fee on the whole transaction cost. - **Detection:** - Monitoring gas cost estimation. + Monitor the transaction costs and alert if it's above a threshold. - **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. @@ -69,9 +69,13 @@ Below are references for this project: - **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. + Action and E2E tests covering the receipt hydration logic has been added. + + * [Fee E2E test](https://github.com/ethereum-optimism/optimism/blob/develop/op-e2e/system/fees/fees_test.go) + * [Operator Fee Constistency action test](https://github.com/ethereum-optimism/optimism/blob/develop/op-e2e/actions/proofs/operator_fee_test.go) + - **Detection:** - Monitor transaction receipts and compare reported fees with expected calculations. Watch for discrepancies in accounting systems. + The action or E2E tests or local testing may pick up an issue. - **Recovery Path(s):** Deploy fix for receipt hydration logic. Historical receipts will remain incorrect but can be recalculated using on-chain data if needed. @@ -90,10 +94,22 @@ Below are references for this project: - Use archive nodes to maintain historical data. - Consider implementing receipt compression retroactively if needed. +### Generic items we need to take into account: `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:** + The [Operator Fee Constistency](https://github.com/ethereum-optimism/optimism/blob/develop/op-e2e/actions/proofs/operator_fee_test.go ) action test runs with all known hardforks activated at genesis, and checks that operator fee parameters are correctly reported to the `L1Block` contract. +- **Detection:** + The action or E2E tests or local testing may pick up an issue. +- **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. + ## 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)_ +- [ ] Coordinate with wallet providers to update their fee estimation logic \ No newline at end of file From 4eba257b2eabca2ecc44190ac0bbd51d1846c61b Mon Sep 17 00:00:00 2001 From: leruaa Date: Tue, 11 Feb 2025 02:51:51 -0800 Subject: [PATCH 08/12] fix: handle more feedbacks --- security/fma-operator-fee.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/security/fma-operator-fee.md b/security/fma-operator-fee.md index cd98fb81..c195ead4 100644 --- a/security/fma-operator-fee.md +++ b/security/fma-operator-fee.md @@ -17,8 +17,8 @@ | ------------------ | -------------------------------------------------- | | Author | leruaa | | Created at | 2025-01-08 | -| Initial Reviewers | | -| Need Approval From | maurelian | +| Initial Reviewers | Mark Tyneway | +| Need Approval From | Blaine Malone | | Status | In Review | ## Introduction @@ -45,7 +45,9 @@ Below are references for this project: **Mitigations:** Before setting or updating the operator fee params, the operator should carefully read the [corresponding specs](https://specs.optimism.io/protocol/isthmus/exec-engine.html#operator-fee) and simulate the impact of operator fee on the whole transaction cost. - **Detection:** - Monitor the transaction costs and alert if it's above a threshold. + By default, the operator fee parameters are set to 0 and the feature is disabled. There are [E2E tests](https://github.com/ethereum-optimism/optimism/blob/develop/op-e2e/system/fees/fees_test.go) that ensure there is no impact on the transaction cost when the operator fee is disabled. + + On chains that enable operator fee, the operator should monitor the transaction cost and ensure that the operator fee is not too high. - **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. @@ -54,11 +56,12 @@ Below are references for this project: - **Description:** If wallets fail to update their fee estimation logic, users will no longer be shown the accurate costs of a transaction. - **Risk Assessment:** + This failure mode can only happen on chains that enable the operator fee feature. 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. + Using a given waalet, compare the estimated transaction cost with the actual transaction cost, and check if the difference relates to the operator fee, using the formula. - **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. @@ -77,7 +80,7 @@ Below are references for this project: - **Detection:** The action or E2E tests or local testing may pick up an issue. - **Recovery Path(s):** - Deploy fix for receipt hydration logic. Historical receipts will remain incorrect but can be recalculated using on-chain data if needed. + Deploy fix for receipt hydration logic. Historical receipts will remain incorrect but can be recalculated using on-chain data if needed. The fix will not require a hardfork. ### FM4: Database Growth Impact on Nodes From b82616486f8a57265ff583da43af9d8495e30892 Mon Sep 17 00:00:00 2001 From: leruaa Date: Wed, 12 Feb 2025 00:36:05 -0800 Subject: [PATCH 09/12] handle blmalone feedbacks --- security/fma-operator-fee.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/security/fma-operator-fee.md b/security/fma-operator-fee.md index c195ead4..190f4ba4 100644 --- a/security/fma-operator-fee.md +++ b/security/fma-operator-fee.md @@ -39,7 +39,7 @@ Below are references for this project: ### 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. + If the operator fee scalars are incorrectly initialized or updated, there is a risk that the transactions fees will be too high. This could lead to a situation where the chain becomes unusable. - **Risk Assessment:** High impact, low likelihood. **Mitigations:** @@ -51,6 +51,8 @@ Below are references for this project: - **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. + With cast it can be done like this: `cast send "setOperatorFeeScalars(uint32, uint64)" ` + ### FM2: Broken Fee Estimation (Wallets) - **Description:** @@ -61,7 +63,7 @@ Below are references for this project: **Mitigations:** Coordinate with wallet providers to update their fee estimation logic. This includes MetaMask, Coinbase Wallet, and others. - **Detection:** - Using a given waalet, compare the estimated transaction cost with the actual transaction cost, and check if the difference relates to the operator fee, using the formula. + Using a given wallet, compare the estimated transaction cost with the actual transaction cost, and check if the difference relates to the operator fee, using the formula. - **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. @@ -75,12 +77,12 @@ Below are references for this project: Action and E2E tests covering the receipt hydration logic has been added. * [Fee E2E test](https://github.com/ethereum-optimism/optimism/blob/develop/op-e2e/system/fees/fees_test.go) - * [Operator Fee Constistency action test](https://github.com/ethereum-optimism/optimism/blob/develop/op-e2e/actions/proofs/operator_fee_test.go) + * [Operator Fee Consistency action test](https://github.com/ethereum-optimism/optimism/blob/develop/op-e2e/actions/proofs/operator_fee_test.go) - **Detection:** The action or E2E tests or local testing may pick up an issue. - **Recovery Path(s):** - Deploy fix for receipt hydration logic. Historical receipts will remain incorrect but can be recalculated using on-chain data if needed. The fix will not require a hardfork. + Deploy fix for receipt hydration logic. Historical receipts will remain incorrect but can be recalculated using on-chain data if needed. The fix would be on the execution layer and will not require a hardfork. ### FM4: Database Growth Impact on Nodes From 112acd2495845d034f8c34ab9b5725ff933fc9fb Mon Sep 17 00:00:00 2001 From: leruaa Date: Wed, 12 Feb 2025 14:50:07 -0800 Subject: [PATCH 10/12] feat: add database growth rate action --- security/fma-operator-fee.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/security/fma-operator-fee.md b/security/fma-operator-fee.md index 190f4ba4..8551f5c9 100644 --- a/security/fma-operator-fee.md +++ b/security/fma-operator-fee.md @@ -117,4 +117,5 @@ Below are references for this project: 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: -- [ ] Coordinate with wallet providers to update their fee estimation logic \ No newline at end of file +- [ ] Coordinate with wallet providers to update their fee estimation logic +- [ ] Implement automated monitoring on dabase growth rate \ No newline at end of file From a71087c658c689b71f6668df9a9cf07f0c46db86 Mon Sep 17 00:00:00 2001 From: leruaa Date: Thu, 13 Feb 2025 06:44:17 -0800 Subject: [PATCH 11/12] feat: add Database Growth simulation --- security/fma-operator-fee.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/security/fma-operator-fee.md b/security/fma-operator-fee.md index 8551f5c9..c3bb61ee 100644 --- a/security/fma-operator-fee.md +++ b/security/fma-operator-fee.md @@ -91,10 +91,19 @@ Below are references for this project: - **Risk Assessment:** Medium impact, high likelihood. - **Mitigations:** - - Implement history expiry solutions like EIP-4444 when available. + 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. + + The following simulation can give a view of the impact of operator fee on the node storage: Operator fee adds 12 bytes per L2 block (4 for operator fee scalar, 8 for operator fee constant). It also add 12 bytes + per transaction (in the transaction receipt) So, with the arbitrary number of 20 txs per block we have: + + ``` + (12 bytes + 240 bytes / 2 seconds) x 365 days × 24 hours × 60 minutes × 60 seconds = 3,973,536,000 bytes in 1 year. + ``` + + So, about 3,7 GB for 1 year. - **Recovery Path(s):** - Use archive nodes to maintain historical data. - Consider implementing receipt compression retroactively if needed. From 09b0af20c2daf435c0f1433c7b6ff023fdb6eb1d Mon Sep 17 00:00:00 2001 From: leruaa Date: Thu, 13 Feb 2025 09:47:40 -0800 Subject: [PATCH 12/12] feat: move to "Implementing Actions" --- security/fma-operator-fee.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/security/fma-operator-fee.md b/security/fma-operator-fee.md index c3bb61ee..19acd597 100644 --- a/security/fma-operator-fee.md +++ b/security/fma-operator-fee.md @@ -19,7 +19,7 @@ | Created at | 2025-01-08 | | Initial Reviewers | Mark Tyneway | | Need Approval From | Blaine Malone | -| Status | In Review | +| Status | Implementing Actions | ## Introduction