EIP-4844 Implementers' Call #10

[timbeiko]

Meeting Info

• Jan 3, 2023, 15:30 UTC
• Duration: 60 minutes
• Recording: https://youtu.be/9ZwTy0msVdU
• Zoom: https://ethereumfoundation.zoom.us/j/88332629239?pwd=YmNpVVpaVy93RXhOTS9DYmNtWGtLdz09
• Notes & action items

📆 Subscribe to the Ethereum Protocol Call calendar for calendar invites

Agenda

• Spec updates
  • Pre-interop spec freeze 🥶
  • Clarify & rationalize blob transaction hash computations in EIP-4844 EIPs#6245
  • is_data_available should be in fork-choice consensus-specs#3170
  • EIP4844: Clarify ratelimit behavior for sidecar with zero blobs consensus-specs#3174
  • Historical batches consensus-specs#3165
• Devnet 3 updates
  • Capella rebase
• Testing updates
  • simulators/eth2: Common Library hive#667
  • hive: metrics support with prometheus and grafana hive#665
  • simulators/ethereum/engine: Withdrawals Test Suite hive#659
• Large Block Spam Test
• Precompile benchmarking
• Readiness checklist

[terencechain]

Two things to discuss from my side:

1.) How should we handle blobs by range response on "zero" blob sidecar: ethereum/consensus-specs#3174

2.) The testing for devnet has some friction due to the latest breaking changes from the withdrawal spec. Different clients are rebasing based on different withdrawal spec versions. Now that the withdrawal spec is close to finalizing, we should pin down a capella version to rebase 4844.

Feature	Devnet3	Devnet4
Withdrawal enabled	🚫
Withdrawal without queue	🚫
Withdrawal with bounded validator count	🚫
Include blockValue in getPayload response	🚫

[djrtwo]

Re: 2 -- so even with the withdrawals functionality stubbed, the data structures are changed and thus must have agreement on this at a minimum.

Note: we have a spec release this friday with the final CL capella feature -- the historic accumulate revamp ethereum/consensus-specs#3165

Also note that re-enabling withdrawals functionality is to happen soon ™️ -- ethereum/consensus-specs#3181

My preference on how things play out this month:

• CL spec release -- v1.3.0-alpha.3 -- this week to include historic accumulators for Capella (essentially the mainnet release candidate)
• Any 4844 testnets pre-interop target v1.3.0-alpha.3 (final capella data structures but capella functionality stubbed)
• Capella testnets pre-interop and during interop target v1.3.0-alpha.3 (full capella functionality)
• 4844 testnets at interop keep stubbed Capella functionality and unstub in a release immediately after interop (first week of feb)

I think the last point is most contentious. I'll put it on the CL call to discuss this coming week, but I believe keeping the functionality unencumbered would be the cleanest given the timelines at hand.

[djrtwo]

(I won't be on call today)

re: ethereum/consensus-specs#3170

There was no opposition to the shift in spec on the CL call and all active spec maintainers I've discussed with agree that this is the appropriate place for the check.

I'd like to get this into the release at end of week.

[hwwhww]

Re: the historic accumulate revamp ethereum/consensus-specs#3165

If 4844 interop needs to disable it, it has to revert process_epoch like this: ethereum/consensus-specs@72096ee

Considering process_historical_summaries_update is just an 8-line function in Python... I want to check if 4844 implementers want it to be disabled like this in the next spec release? It might be easier to just include this change.

[timbeiko]

Closed in favour of #707