op-batcher: handle EIP-7623 in DA switching calculation

[geoknee]

Closes #13791

Updates the batcher's DA switching logic to understand the new calldata costs coming when Pectra activates on L1.

Infers the Pectra activation status from the block header already fetched by the batcher's publishing loop.

Also some refactoring and unit tests added.

TODO

• make any necessary changes to alerting / dashboards (Q: does this modify the rough x16 factor we use to compare blob cost with calldata cost? A: Yes, it moves to a 40x factor)-
• preemptively handle e2e tests which may break when run against a Prague enabled L1

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 0.00%. Comparing base (6819d8a) to head (b635865).
Report is 94 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff              @@
##           develop   #13870       +/-   ##
============================================
- Coverage    46.40%        0   -46.41%     
============================================
  Files          994        0      -994     
  Lines        83988        0    -83988     
============================================
- Hits         38974        0    -38974     
+ Misses       42067        0    -42067     
+ Partials      2947        0     -2947     

Flag	Coverage Δ
cannon-go-tests-32	?
cannon-go-tests-64	?
contracts-bedrock-tests	?

Flags with carried forward coverage won't be shown. Click here to find out more.

see 994 files with indirect coverage changes

[tynes]

wire up isPectra flag to.... a configuration variable? Once this EIP activates on L1 we may not even need the switching logic...

Is it easy to get this from a geth config library someplace, where you can use the L1 chain id (fetched via eth_chainId) to know which config to use and then use the timestamp to tell if its activated yet?

It also may be possible to detect pectra using the L1 block header, you can use header.requests != nil i think, see https://eips.ethereum.org/EIPS/eip-7685

[geoknee]

wire up isPectra flag to.... a configuration variable? Once this EIP activates on L1 we may not even need the switching logic...

Is it easy to get this from a geth config library someplace, where you can use the L1 chain id (fetched via eth_chainId) to know which config to use and then use the timestamp to tell if its activated yet?

It also may be possible to detect pectra using the L1 block header, you can use header.requests != nil i think, see https://eips.ethereum.org/EIPS/eip-7685

Thanks for the tip! So far I went with your suggestion around EIP-7685. We are already fetching the header just before generating data to send to L1, so no new network requests or other configuration would be needed to detect Pectra activation with this approach 1e4de7b.

[geoknee]

	// Back of the envelope calculation for equilibrium point:
	//
	// Definitions:
	// let c = baseFee + tipCap
	// let b = blobBaseFee
	// let M = multiplier
	// let n = numBlobsPerTx
	// let g = blobgasperblob = 1<<17 = 131072
	//
	// Assumptions:
	// Assume a single frame calldata tx with 120_000 bytes (480_000 tokens)
	// Assume an n frame blob tx with 130_044n bytes
	// equilibrium cost per byte requires: (21_000 + M*480_000)c/120_000 = (21_000c + g*n*b)/130_044*n
	// c(21/120 +4M)  = 21_000c/130_044n + b * (g/130_044)
	// c(21/120 + 4M - 0.16/n) = b * (g/130_044)
	// b/c = 0.9921569824 * (4M + 0.175 - 0.16/n)
	// So pre-Pectra the equilibrium point is approximately at blobbaseFee = (baseFee + tipCap) * 16.05 - 0.16/n
	// and post-Pectra the equilibrium point is approximately at blobbaseFee = (baseFee + tipCap) * 39.6 - 0.16/n

(edited)

[geoknee]

@sebastianst I am wondering whether this e2e test

optimism/op-e2e/system/da/eip4844_test.go

Lines 252 to 253 in 38f9864

	func TestBatcherAutoDA(t *testing.T) {
	op_e2e.InitParallel(t)

needs updating once we have the ability to activate Pectra on L1. It could be that the numbers are such that the test can cover pre and post Pectra behavior with no changes. Hard to tell before we have the actual Pectra support on L1. We do have a Pectra enabled kurtosis devnet, so perhaps we can point the test at that already?

[sebastianst]

@sebastianst I am wondering whether this e2e test

optimism/op-e2e/system/da/eip4844_test.go

Lines 252 to 253 in 38f9864

	func TestBatcherAutoDA(t *testing.T) {
	op_e2e.InitParallel(t)

needs updating once we have the ability to activate Pectra on L1. It could be that the numbers are such that the test can cover pre and post Pectra behavior with no changes. Hard to tell before we have the actual Pectra support on L1. We do have a Pectra enabled kurtosis devnet, so perhaps we can point the test at that already?

@geoknee yes we could use the same test to cover both, pre and post-Pectra L1. But then again, if we unit test the logic in the batcher that does the switching for both, pre and post-Pectra, I don't think that we need to have this e2e test cover both. The job of the e2e test then stays to confirm that the overall switching in the batcher works, which is fine to confirm for only one case IMO, and then the unit tests cover all scenarios.

[geoknee]

@geoknee yes we could use the same test to cover both, pre and post-Pectra L1.

Did that here bfdac6e. Rabbit holed a bit on this test, but it should work now for both pre and post pectra. It starts the fee ratio at over 40 (asserts batcher using calldata) and reduces it to under 16 (asserts batcher using blobs).