Skip to content

Jovian: Calldata footprint block limit #317

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

sebastianst
Copy link
Member

@sebastianst sebastianst commented Aug 12, 2025

A calldata footprint block limit is introduced to mitigate DA spam and prevent priority fee auctions. By tracking
calldata footprint alongside gas, this approach adjusts the block gas limit to account for high calldata usage without
altering individual transaction gas mechanics. Preliminary analysis shows minimal impact on most blocks on production
networks like Base or OP Mainnet.

Closes ethereum-optimism/optimism#17009.

@sebastianst sebastianst force-pushed the seb/calldata-block-limit branch from dbe366c to 372ebdd Compare August 12, 2025 15:05
Comment on lines +93 to +100
BASE - 2025-07-22
💰 Cost Comparison Analysis (43200 blocks):
==================================================
Cost Avg Util Max Util Exceeds
--------------------------------------
160 2.21% 27.50% 0/43200
400 5.52% 68.75% 0/43200
800 11.04% 137.49% 13/43200
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you help me parse this table?

Cost seems to relate to the scale-factor applied to calldata? And so, if the scale factor is 400 or below, calldata is never a cause of block fullness?

at 800, we find that there are 13 blocks which would have been affected by the footprint (?). Is that the number we expect/want? 0.03% of blocks have considerable calldata spam?

Ultimately I'm trying to figure out how we know if scale-factor is set correctly.

like block explorers and those services need to be educated about the necessary steps to adapt their services to this
new calculation of the block gas used.

## Alternatives Considered
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't calldata bytes already cost gas? Couldn't an alternative strategy just be to increase the gas cost of calldata bytes sufficiently?

Comment on lines +145 to +146
block's gas used field will be the total calldata footprint instead. This may impact some analytics-based services
like block explorers and those services need to be educated about the necessary steps to adapt their services to this
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could imagine more than just analytic services, developer tools like cast that might have sanity validation could find themselves in error when the sum no longer represents the actual sum.

For block explorers -- how will they know that footprint is the cause of the block fullness, besides just forensically comparing the gas used fields?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Calldata Footprint Limit] Write design doc
2 participants