All Core Devs - Consensus (ACDC) call #135, June 13 2024

Working Groups
,
1

Agenda

Consensus-layer Call 135 · Issue #1069 · ethereum/pm · GitHub

Moderator: @ralexstokes

Summary

ACDC 135 summary by @ralexstokes:

We began with some announcements:

Then discussed Electra devnet-1 from the CL side:

  • Agreed to merge this PR into the devnet-1 specs, which refactors the attestation layout following EIP-7549 and has implications for the SSZ merkelization of this type
  • Client teams agreed to target v1.5.0-alpha.3 of the consensus specs for devnet-1 . Be on the look out for release soon™!
  • Wrapped this segment with some rough timelines on devnet-1 readiness, most clients seemed to think a couple weeks after the specs release is all that would be needed to get an implementation ready, which means we can keep Pectra moving along :tada:

And then moved to PeerDAS work:

  • Started by calling out this PR to move PeerDAS to formal inclusion in Pectra to reflect client intent, even if PeerDAS is developed separately from the “core” Pectra set.
  • Next discussed how to proceed on PeerDAS development given that we want to work in parallel to the other Pectra work; PeerDAS implementer’s agreed on the PeerDAS breakout call #1 to implement PeerDAS on top of Deneb for the time being, to minimize thrash with Pectra changes as the core EIP set is still in the process of stabilizing. The intent is to rebase PeerDAS on top of the Pectra changes once it is clearer that the other Pectra EIPs have stabilized, ideally over the next few Pectra devnets.

We then turned to raising the blob count in Pectra:

  • The intent is to raise the blob count to provide an increase in Ethereum’s data throughput in the upcoming hard fork.
  • However, there are a few complications:
    • Preliminary analysis shows turbulence at the current blob count.
    • PeerDAS handles blob data differently than today’s EIP-4844 mechanism, which unlocks further scale but makes it hard to compare the blob count today to a blob count under Pectra.
  • In light of these facts, there are a variety of opinions on how to raise the blob count in Pectra; including: increasing the blob count even without PeerDAS, increasing the blob count with PeerDAS, or simply deploying PeerDAS and leaving the blob count alone. Analysis of the future Pectra devnets should give us more confidence in the right approach — check the call for the full nuance here.
  • We also covered a proposal to uncouple the blob count, which currently is set independently on the EL and CL (yet has to match); there is an initial PR here that has the CL drive the blob count but discussion on the call raised a few more questions to do this safely. We also discussed how to handle the change in the blob base fee when the blob count changes. In short, expect some possible changes in how blob accounting is carried out in Pectra.

We concluded with a great update on the SSZ-ification of the protocol (expect to see a devnet by the next CL call), and a call-out to determine the name of the “F-star” for the next CL fork to accompany Osaka on the EL.

From Eth R&D Discord

Recording

Transcript

[To be added]

Additional info

Notes by @Christine_dkim: Ethereum All Core Developers Consensus Call #135 Writeup | Galaxy
F-star name discussion: F-star name for Consensus Layer upgrade after Electra