Skip to content

Commit 38b7cc0

Browse files
leruaaratankaliani
leruaa
and
ratankaliani
authored
feat: add FMA for operator fee (#186)
* add FMA for operator fee * feedbacks * feat: add more failure modes * fix: TOC * feat: remove generic items * feat: add a generic item * fix: handle feedbacks * fix: handle more feedbacks * handle blmalone feedbacks * feat: add database growth rate action * feat: add Database Growth simulation * feat: move to "Implementing Actions" --------- Co-authored-by: Ratan Kaliani <[email protected]>
1 parent f91f648 commit 38b7cc0

File tree

1 file changed

+130
-0
lines changed

1 file changed

+130
-0
lines changed

‎security/fma-operator-fee.md

+130
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,130 @@
1+
# [Operator Fee]: Failure Modes and Recovery Path Analysis
2+
3+
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
4+
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
5+
6+
- [Introduction](#introduction)
7+
- [Failure Modes and Recovery Paths](#failure-modes-and-recovery-paths)
8+
- [FM1: Operator Fee scalars are set to incorrect values](#fm1-operator-fee-scalars-are-set-to-incorrect-values)
9+
- [FM2: Broken Fee Estimation (Wallets)](#fm2-broken-fee-estimation-wallets)
10+
- [FM3: Bug in Receipt Hydrating Logic](#fm3-bug-in-receipt-hydrating-logic)
11+
- [FM4: Database Growth Impact on Nodes](#fm4-database-growth-impact-on-nodes)
12+
- [Action Items](#action-items)
13+
14+
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
15+
16+
| | |
17+
| ------------------ | -------------------------------------------------- |
18+
| Author | leruaa |
19+
| Created at | 2025-01-08 |
20+
| Initial Reviewers | Mark Tyneway |
21+
| Need Approval From | Blaine Malone |
22+
| Status | Implementing Actions |
23+
24+
## Introduction
25+
26+
This document covers initial deployment of Operator Fee.
27+
28+
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.
29+
30+
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.
31+
32+
Below are references for this project:
33+
34+
- [Design Doc](../protocol/operator-fee.md)
35+
- [Spec](https://github.com/ethereum-optimism/specs/pull/382)
36+
37+
## Failure Modes and Recovery Paths
38+
39+
### FM1: Operator Fee scalars are set to incorrect values
40+
41+
- **Description:**
42+
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.
43+
- **Risk Assessment:**
44+
High impact, low likelihood.
45+
**Mitigations:**
46+
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.
47+
- **Detection:**
48+
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.
49+
50+
On chains that enable operator fee, the operator should monitor the transaction cost and ensure that the operator fee is not too high.
51+
- **Recovery Path(s)**:
52+
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.
53+
54+
With cast it can be done like this: `cast send <l1_system_config_address> "setOperatorFeeScalars(uint32, uint64)" <operator_fee_scalar> <operator_fee_constant>`
55+
56+
### FM2: Broken Fee Estimation (Wallets)
57+
58+
- **Description:**
59+
If wallets fail to update their fee estimation logic, users will no longer be shown the accurate costs of a transaction.
60+
- **Risk Assessment:**
61+
This failure mode can only happen on chains that enable the operator fee feature.
62+
Medium impact, medium likelihood.
63+
**Mitigations:**
64+
Coordinate with wallet providers to update their fee estimation logic. This includes MetaMask, Coinbase Wallet, and others.
65+
- **Detection:**
66+
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.
67+
- **Recovery Path(s)**:
68+
Notify wallets of the new fee structure and ask them to update their fee estimation logic if the operator fee is enabled.
69+
70+
### FM3: Bug in Receipt Hydrating Logic
71+
72+
- **Description:**
73+
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.
74+
- **Risk Assessment:**
75+
Medium impact, low likelihood.
76+
- **Mitigations:**
77+
Action and E2E tests covering the receipt hydration logic has been added.
78+
79+
* [Fee E2E test](https://github.com/ethereum-optimism/optimism/blob/develop/op-e2e/system/fees/fees_test.go)
80+
* [Operator Fee Consistency action test](https://github.com/ethereum-optimism/optimism/blob/develop/op-e2e/actions/proofs/operator_fee_test.go)
81+
82+
- **Detection:**
83+
The action or E2E tests or local testing may pick up an issue.
84+
- **Recovery Path(s):**
85+
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.
86+
87+
### FM4: Database Growth Impact on Nodes
88+
89+
- **Description:**
90+
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.
91+
- **Risk Assessment:**
92+
Medium impact, high likelihood.
93+
- **Mitigations:**
94+
Implement history expiry solutions like EIP-4444 when available.
95+
- **Detection:**
96+
- Monitor database growth rate compared to pre operator fee baseline.
97+
- Track disk usage metrics across internal nodes.
98+
99+
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
100+
per transaction (in the transaction receipt) So, with the arbitrary number of 20 txs per block we have:
101+
102+
```
103+
(12 bytes + 240 bytes / 2 seconds) x 365 days × 24 hours × 60 minutes × 60 seconds = 3,973,536,000 bytes in 1 year.
104+
```
105+
106+
So, about 3,7 GB for 1 year.
107+
- **Recovery Path(s):**
108+
- Use archive nodes to maintain historical data.
109+
- Consider implementing receipt compression retroactively if needed.
110+
111+
### Generic items we need to take into account: `L1Block` badly hydrated
112+
113+
- **Description:** At each hardfork, new data can be add to the `L1Block` contract, and the method called to hydrate it change (for instance
114+
`setL1BlockValuesEcotone` to `setL1BlockValuesIsthmus`). If there is a bug in a future method ending up to operator fee params no
115+
longer being updated in the `L1Block` contract, the operator fee will no longer be taken into account in transactions fee.
116+
- **Risk Assessment:** medium severity / low likelihood
117+
- **Mitigations:**
118+
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.
119+
- **Detection:**
120+
The action or E2E tests or local testing may pick up an issue.
121+
- **Recovery Path(s):**
122+
- If the bug is located in op-node, a new version must be deployed.
123+
- If the bug is located in the `L1Block` contract, the contract must be upgraded to fix the bug.
124+
125+
## Action Items
126+
127+
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:
128+
129+
- [ ] Coordinate with wallet providers to update their fee estimation logic
130+
- [ ] Implement automated monitoring on dabase growth rate

0 commit comments

Comments
 (0)