Improve L1 Pricing Estimation Using MEL in ArbOS#4572
Closed
rauljordan wants to merge 2 commits intomel-validator-createvalidationentryfrom
Closed
Improve L1 Pricing Estimation Using MEL in ArbOS#4572rauljordan wants to merge 2 commits intomel-validator-createvalidationentryfrom
rauljordan wants to merge 2 commits intomel-validator-createvalidationentryfrom
Conversation
Contributor
❌ 350 Tests Failed:
View the top 3 failed tests by shortest run time
📣 Thoughts on this report? Let Codecov know! | Powered by Codecov |
Contributor
Author
|
Closing as we will not get to this for a while, but attached it to NIT-4315 so we can keep track of this branch in the future |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Background
The Problem
ArbOS charges L2 users an "L1 fee" on every transaction to cover the cost of posting their data to Ethereum. This fee is pricePerUnit * calldataUnits, where pricePerUnit is ArbOS's estimate of what it costs per unit of calldata on L1. The challenge: ArbOS lives on L2 and needs to track L1 gas prices with limited information.
Today, the
pricePerUnitof data only updates inside UpdateForBatchPosterSpending in ArbOS which runs when a BatchPostingReport delayed message arrives, which is only after the batch poster actually posts a batch on L1.The update logic is an indirect feedback controller:
If we overcharged users, we lower the price
If we undercharged users, we raise the price
The issue is this pricer is inherently quite inaccurate and has many reasons it can accumulate error over time. For instance, it only fires when batches are posted. If L1 gas spikes between batches, pricePerUnit stays stale and users underpay. If gas drops, they overpay. The feedback is also indirect as it infers instead of observing directly.
The Solution
Thanks to the Message Extraction Layer, we now have a piece of Arbitrum consensus that reads the parent chain to extract batches and produce messages for L2 execution. This consensus system could also inject parent chain information about pricing into ArbOS as delayed messages. This PR attempts to do that and updates the pricer in ArbOS to use live information each parent chain epoch (32 blocks on Ethereum).
A system test is added that proves the new pricer accumulates 10x fewer absolute error than the old pricer and is way better because it does not depend on batches to be posted to have access to L1 pricing information. Moreover, we can inject useful info such as parent chain block hash which can be exposed via a precompile. The new pricer uses an exponential moving average:
Where N is the smoothing window. Recent samples matter more, old samples decay exponentially.
With inertia = 10, each update moves pricePerUnit 10% of the way toward the actual L1 base fee. After 32 updates (one epoch), it's covered ~96% of the gap. This runs every time an epoch pricing message is processed.
The effectiveBaseFee is min(l1BaseFee, blobBaseFee/16) because batch posters choose whichever posting method is cheaper. Post-EIP-4844, blob gas is typically much cheaper. The /16 converts blob gas cost to "per calldata unit" to match the existing unit system.