feat: add FMA for operator fee #186
Conversation
| - [Spec](https://github.com/ethereum-optimism/specs/pull/382) | ||
|
|
||
| ## Failure Modes and Recovery Paths | ||
|
|
There was a problem hiding this comment.
Database growth increase results in need for 4444 faster or other history expiry solution
There was a problem hiding this comment.
What are the other potential history expiry solutions? Just state pruning?
Also, the operator fee won't result in significant database growth on it's own right?
There was a problem hiding this comment.
This is a question for you to answer :)
Basically whatever the extra data to the L1 attributes txs is, that is stored to the db every 2s for OPM and Base, every 1s for Unichain/Ink/Soneium, so that adds up to be a lot over time. Its just a consideration and not a blocker. Eventually we need to use a diff based L1 attributes tx to not repeat data being sent over and over again
There was a problem hiding this comment.
@leruaa has this been resolved?
|
Any other failure modes that come to mind @tynes? Are there other external parties beyond wallets that may fail to update their fee estimation logic that we should be aware of? |
|
we have some considerations for generic hardforks here: could be useful to look at this too |
leruaa
force-pushed
the
fma-operator-fee
branch
from
a324fc9 to
8846b49
Compare
| - **Mitigations:** | ||
| - Implement history expiry solutions like EIP-4444 when available. | ||
| - **Detection:** | ||
| - Monitor database growth rate compared to pre operator fee baseline. |
There was a problem hiding this comment.
A few of the detections are monitoring related. If we don't have monitors setup for these types of metrics already we will have to stand those up, which would be an action item to track
There was a problem hiding this comment.
I'll ask if OP Labs have monitoring in place related to database growth rate.
There was a problem hiding this comment.
Before we merge, has this been resolved @leruaa?
leruaa
force-pushed
the
fma-operator-fee
branch
from
8846b49 to
6fa315d
Compare
leruaa
force-pushed
the
fma-operator-fee
branch
from
7a5cc90 to
4eba257
Compare
|
@blmalone That's ok for me! |
security/fma-operator-fee.md
Outdated
| - **Risk Assessment:** | ||
| Medium impact, high likelihood. | ||
| - **Mitigations:** | ||
| - Implement history expiry solutions like EIP-4444 when available. |
There was a problem hiding this comment.
This is medium impact and high likelihood, but we have no mitigations others than waiting for EIP-4444, and no action items for this? It seems like we are just accepting this failure mode which doesn't seem good
There was a problem hiding this comment.
I added an action item
There was a problem hiding this comment.
Thanks! So what happens if growth rate is too high and database size becomes a problem, what options do we have to mitigate? Is there any kind of benchmarking of anticipated growth rate we are going to do before shipping?
There was a problem hiding this comment.
Operator fee adds 12 bytes per L2 block (4 for operator fee scalar, 8 for operator fee constant). It also add 12 bytes per transactions (in the transaction receipt) So, with the arbitrary number of 20s 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.
About 3,7 GB for 1 year
I aded this simulation in the FMA.
|
@leruaa @ratankaliani - do you folks have it in your next steps/plans to create a new PR that will help us track your work on the action items from this Pr, since we merged it and are now in
as mentioned by Blaine in his last comment |
Description
This PR introduces the FMA for the operator fee feature, set to be included in Isthmus.
Additional context