Skip to content

[Tracking] [DA Footprint Limit] DA Footprint Block Limit #16998

@mslipper

Description

@mslipper

Status Quo (Sep 9)

  • The Design Doc is written and has been reviewed, but there are a few open discussions that are being worked on. This is not blocking implementation, as all changes from these discussions will only be marginal changes to any existing implementation. The open discussion points are
    • Good default value: The design doc currently proposes a default value of 800, but there are still discrepancies with Base's observations, possibly 10x. Until these are fully sorted out, we cannot pick a default value. To this end, I'm currently collecting data on DA usage estimation directly in op-geth to compare with out analysis and see which is right.
    • Linear offset/custom target: Base is concerned about the implied DA footprint target and may want to use a more complex curve where a custom target and limit for the DA footprint can be chosen, independent of the elasticity. This is related to the first point to review the data analyses and would make the implementation more complex.
    • Data type for the gas scalar: Final decision on whether a uint16 is sufficient or we should use a uint32 for the gas scalar.
  • Specs: there's a first draft but it needs a lot more work. The draft currently described the constant-variant, but we're now making the gas scalar configurable, so this needs to be added. It also needs editorial changes.
  • EL implementations
    • op-geth: The Spike should work, but is missing a unit test. Other work can already build on it. It currently only handles the constant variant. In a follow-up, the variable gas scalar variant needs to be implemented, reading it from the L1Block state.
    • op-reth: TBD
  • CL implementations
    • op-node: There's a draft to make the gas scalar configurable.
  • Tests: We need action tests and acceptance tests, ideally two variants for each: using the default gas scalar, and another one where the scalar is set on the SystemConfig (not sure if this can be achieved in an acceptance test? Needs contracts call by the SystemConfig owner).

Sub-issues

Metadata

Metadata

Labels

H-jovianHardfork: change is planned for jovian upgradeM-trackingMeta: tracking issue

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions