Skip to content

op-node: prepare for Fusaka #17493

Closed
#17568
Closed
op-node: prepare for Fusaka#17493
#17568
Assignees
geoknee
Labels
H-l1-fusaka-defenseSoft fork for being compatible with an L1 which has activated FusakaM-needs-triageMeta: this issue needs to be labelled
@geoknee

Description

@geoknee
geoknee
opened on Sep 17, 2025

We need to ensure compatibility in the following areas:

  1. Derivation pipeline.

Converting excess blob gas into the L1cost. We need to hardcode the Fusaka and blob parameter only hardfork EIP 7892 activation times, which vary by L1 chain. We can then editing this code accordingly, :

optimism/op-service/eth/blob.go

Lines 286 to 308 in 44d3429

// CalcBlobFeeDefault calculates the blob fee for the given header using eip4844.CalcBlobFee,
// using the requests hash field of the header as a best-effort heuristic whether
// Prague is active, and the default Ethereum blob schedule.
//
// This is to deal in a best-effort way with situations where the chain config is not
// available, but it can be assumed that per the definition of the Prague fork that
// Prague is active iff the requests hash field is present.
func CalcBlobFeeDefault(header *types.Header) *big.Int {
// We make the assumption that eip4844.CalcBlobFee only needs
// - London and Cancun to be active
// - the Prague time to be set relative to the header time
// and that the caller assumes the default prod Ethereum Blob schedule config.
dummyChainCfg := &params.ChainConfig{
LondonBlock: common.Big0,
CancunTime: ptr(uint64(0)),
BlobScheduleConfig: params.DefaultBlobSchedule,
}
// We assume that the requests hash is set iff Prague is active.
if header.RequestsHash != nil {
dummyChainCfg.PragueTime = ptr(uint64(0))
}
return eip4844.CalcBlobFee(dummyChainCfg, header)
}

It should be sufficient to simply modify the dummyConfig to schedule the various forks according to some lookup keyed by the L1 chain ID. Then, the upstream code will handle applying the right blob parameters.

  1. API related code.

Are we able to fetch data from L1 after Fusaka?

Note that in future work we may be able to avoid hardcoding the per-fork blob parameters and read them from an L1 RPC. However this is out of scope for this project.

We should also take account of EIP 7918 which bounds the blob base fee by execution cost. I don't believe this is a concern for compatibility, however, and more for when we adopt that EIP on L2.

Metadata

Metadata

Assignees

Labels

H-l1-fusaka-defenseSoft fork for being compatible with an L1 which has activated FusakaM-needs-triageMeta: this issue needs to be labelled

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions