Skip to content

Commit dbe366c

Browse files
sebastianstsebastianst
committed
Jovian: Calldata footprint block limit
1 parent b1c2e40 commit dbe366c

File tree

1 file changed

+158
-0
lines changed

1 file changed

+158
-0
lines changed

‎protocol/calldata-block-limit.md

Lines changed: 158 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,158 @@
1+
# Jovian: Calldata Footprint Block Limit
2+
3+
| | |
4+
| ------------------ | -------------------------------------------------- |
5+
| Author | _Sebastian Stammler_ |
6+
| Created at | _2025-08-12_ |
7+
| Initial Reviewers | _TBD_ |
8+
| Need Approval From | _TBD_ |
9+
| Status | _Draft<!--/ In Review / Implementing Actions / Final-->_ |
10+
11+
## Purpose
12+
13+
Evaluate proposal to add a calldata block limit to mitigate DA spam and prevent priority fee auctions from occurring.
14+
This proposal is an alternative to [Custom Calldata Floor Gas](https://github.com/ethereum-optimism/design-docs/pull/294),
15+
avoiding the need to change individual transaction gas mechanics at all.
16+
17+
## Summary
18+
19+
A calldata footprint block limit is introduced to mitigate DA spam and prevent priority fee auctions. By tracking
20+
calldata footprint alongside gas, this approach adjusts the block gas limit to account for high calldata usage without
21+
altering individual transaction gas mechanics. Preliminary analysis shows minimal impact on most blocks on production
22+
networks like Base or OP Mainnet.
23+
24+
## Problem Statement + Context
25+
26+
<!-- Describe the specific problem that the document is seeking to address as well
27+
as information needed to understand the problem and design space.
28+
If more information is needed on the costs of the problem,
29+
this is a good place to that information. -->
30+
31+
The current L1 cost model doesn't account for *limited L1 data availability (DA) throughput*.
32+
This can lead to network congestion for batchers if the throughput on L2s surpasses that of L1 blob space, or if blob
33+
space is congested for other reasons.
34+
35+
Current L1 throughput is 6 blobs per block at target with a max of 9 blobs per block.
36+
This is approx. `128 kB * 6 / 12 s = 64 kB/s` or `96 kB/s`, resp. The L1 cost is proportional to the L1 origin’s base
37+
fee and blob base fee. But Most OP Stack chains have gas targets high enough to accept far more than 128kb of calldata
38+
per (2s) block. So the calldata floor cost doesn't nearly limit calldata throughput enough to prevent.
39+
40+
The current measure to counter high DA throughput that's being deployed on productio networks is batcher throttling.
41+
When a network is throttled at the builder policy-level, however, its base fee can dive and lead to priority fee
42+
auctions and other unwanted user experience issues.
43+
44+
Also see the design doc [Custom Calldata Floor Gas](https://github.com/ethereum-optimism/design-docs/pull/294) for a
45+
more detailed analysis of the same problem and context and a similar solution.
46+
47+
## Proposed Solution
48+
49+
A _calldata footprint block limit_ is introduced to limit the total amount of calldata that can fit into a block. The
50+
base fee update rules take this new total calldata footprint into account, so the base fee market isn't broken like
51+
for policy-level throttling solutions.
52+
53+
The main idea is to introduce a new _calldata footprint_ resource that is tracked next to gas, and limit it by the same
54+
block gas limit. This is inspired by the
55+
[Multidimensional Gas Metering](https://ethresear.ch/t/a-practical-proposal-for-multidimensional-gas-metering/22668)
56+
design, but the regular gas isn't touched, like in this design for L1 Ethereum.
57+
58+
Similarly to the regular gas usage of transaction calldata, we calculate a transaction’s _calldata footprint_ by taking
59+
its calldata, calculate the transaction size estimation from
60+
[Fjord](https://specs.optimism.io/protocol/fjord/exec-engine.html#fjord-l1-cost-fee-changes-fastlz-estimator)
61+
and multiply it by a factor, the _calldata footprint cost_, to get to the transaction’s calldata footprint.
62+
63+
```python
64+
size_estimate = max(minTransactionSize, intercept + fastlzCoef*fastlzSize / 1e6)
65+
calldata_footprint = size_estimate * calldata_footprint_cost
66+
```
67+
68+
Now when evaluating whether a transactions still fits into a block, we take the maximum over the two resources, regular
69+
total gas use of all transactions, and new total calldata footprint, and see if this max is still below the block gas
70+
limit. The Multidimensional Gas Metering design introduces a new block field `gas_metered` to differentiate it from
71+
`gas_used` as the sum total of all transaction's gas used. However, it is proposed to just repurpose a block's
72+
`gas_used` field to hold the maximum over both resources' totals:
73+
74+
75+
```python
76+
block.gas_used = max(sum(tx.gas_used), sum(tx.calldata_footprint))
77+
```
78+
79+
This also has the advantage that the base fee update mechanics just keep working, now taking into account high block
80+
calldata footprint.
81+
82+
The calldata footprint cost is comparable to the usual calldata floor cost. If it's set to a higher value, say 400, you
83+
can expect roughly a 1/10 of incompressible calldata to fit into a block compared to only limiting it by
84+
transaction gas usage alone. If the block is mostly low-calldata transactions that use much more regular gas than calldata
85+
footprint, this new mechanism wouldn’t have any effect. This is the case for the vast majority of blocks.
86+
87+
### Impact on OP Stack Chains
88+
89+
We did some initial analysis of the impact on Base and OP Mainnet and found that the vast majority of blocks
90+
wouldn't be affected by the introduction of a calldata footprint limit.
91+
92+
```
93+
BASE - 2025-07-22
94+
💰 Cost Comparison Analysis (43200 blocks):
95+
==================================================
96+
Cost Avg Util Max Util Exceeds
97+
--------------------------------------
98+
160 2.21% 27.50% 0/43200
99+
400 5.52% 68.75% 0/43200
100+
800 11.04% 137.49% 13/43200
101+
102+
103+
OPM - 2025-08-01
104+
💰 Cost Comparison Analysis (1000 blocks):
105+
==================================================
106+
Cost Avg Util Max Util Exceeds
107+
------------------------------------
108+
160 0.37% 9.83% 0/1000
109+
400 0.93% 24.59% 0/1000
110+
800 1.87% 49.17% 0/1000
111+
```
112+
113+
More analysis are added here soon.
114+
115+
### Resource Usage
116+
117+
<!-- What is the resource usage of the proposed solution?
118+
Does it consume a large amount of computational resources or time? -->
119+
120+
Additional resource usage for block builders or verifiers is considered negligible, because the estimated DA sizes of
121+
transactions are already calculated since Fjord and the other calculations are trivial, only involving basic arithmetic.
122+
123+
### Single Point of Failure and Multi Client Considerations
124+
125+
<!-- Details on how this change will impact multiple clients. Do we need to plan for changes to both op-geth and op-reth? -->
126+
127+
## Failure Mode Analysis
128+
129+
<!-- Link to the failure mode analysis document, created from the fma-template.md file. -->
130+
131+
## Impact on Developer Experience
132+
<!-- Does this proposed design change the way application developers interact with the protocol?
133+
Will any Superchain developer tools (like Supersim, templates, etc.) break as a result of this change? -->
134+
135+
* No impact expected on users or tooling simulating individual transactions. In particular, no impact on wallets
136+
expected.
137+
* The invariant is broken that the sum total of all transactions' _gas used_ is the block's _gas used_.
138+
If the calldata footprint limit was reached first during block building, the gas used sum will be smaller as the
139+
block's gas used field will be the total calldata footprint instead. This may impact some analytics-based services
140+
like block explorers and those services need to be educated about the necessary steps to adapt their services to this
141+
new calculation of the block gas used.
142+
143+
## Alternatives Considered
144+
145+
<!-- List out a short summary of each possible solution that was considered.
146+
Comparing the effort of each solution -->
147+
148+
* [Custom Calldata Floor Gas](https://github.com/ethereum-optimism/design-docs/pull/294) - introduces customization of
149+
the calldata floor cost. Comparable effects, but changes gas mechanics of individual transactions.
150+
* [L1 congestion fee](https://github.com/ethereum-optimism/design-docs/pull/312) - only proposal that could partially
151+
mitigate the L1 inclusion lag but is more complex to implement and harder to model and forecast the impact on
152+
production networks. It also doesn't set a hard cap on calldata footprint throughput, but relies on market incentives
153+
to drive down calldata use during (modeled) congestion.
154+
155+
## Risks & Uncertainties
156+
157+
<!-- An overview of what could go wrong.
158+
Also any open questions that need more work to resolve. -->

0 commit comments

Comments
 (0)