Execution Layer Meeting 197

[timbeiko]

Meeting Info

• Sep 26, 2024, 14:00-15:30 UTC
• Stream: https://youtube.com/live/PWhn8KdgCl8
• Zoom: shared on #allcoredevs Discord channel shortly before the call
• Ethereum Protocol Calls Calendar subscription

Agenda

• Pectra Implementation updates:
  • devnet-3
  • big queue test
  • BLS MSM benchmarks (context)
  • engine: Make execution requests a sidecar, take 2 execution-apis#591
  • devnet-4
    • Update EIP-6110: change request to flat encoding EIPs#8856
    • Update EIP-7702: Do not allow authorization nonce equal to 2**64 - 1 EIPs#8905
    • Update EIP-7702: add several clarifications to align spec with tests EIPs#8906
  • Pectra Contract audit RFP
• Pectra scope (strongly recommend watching ACDC#142 for context)
  • Fork split
    • @ralexstokes original proposal
    • Erigon thoughts
    • Prysm thoughts
    • Lodestar thoughts
    • @jflo thoughts
    • Nethermind thoughts
    • @vbuterin thoughts
    • @timbeiko proposal
  • EIPs
    • EIP-7762

[mkalinin]

I’d like to quickly announce the following proposal:

• engine: Make execution requests a sidecar, take 2 execution-apis#591

[parithosh]

I'd like to bring up devnet-4 planning, there's a compiled list of PRs and open issues listed here: https://notes.ethereum.org/@ethpandaops/pectra-devnet-4

additionally, i'd want to mention this analysis from @pk910 https://notes.ethereum.org/@ethpandaops/pectra-big-queue-test

[MaxResnick]

I'd like to discuss EIP 7762 since we didn't get to it 2 weeks ago due to discussions of the fork split.

[philknows]

We’ve released our thoughts on the Pectra fork split here: https://blog.chainsafe.io/lodestars-pectra-split-vision-update/

[chfast]

Please apply "agreed" spec updates for requests: https://github.com/ethereum/EIPs/pulls?q=is%3Apr+is%3Aopen+flat.

[chfast]

Review 7702 spec updates:

• Update EIP-7702: Do not allow authorization nonce equal to 2**64 - 1 EIPs#8905
• Update EIP-7702: add several clarifications to align spec with tests EIPs#8906

[jflo]

I'd like to discuss governance and The Interminable Ambition of Scheduling™. There have been a number of suggested improvements in the last few meetings, and I'd like to collect and present them for discussion and more serious consideration. Should only need 5 mins.

Longer form: https://hackmd.io/@RoboCopsGoneMad/SypEYjzRR

[MarekM25]

Nethermind view about forks:

We are slightly in favor of splitting the fork, but we are also fine with shipping it as one large fork. If the fork is split, we’d prefer no further additions to the scope of PectraB and for it to remain fixed. If all teams believe we can finish the development and testing in Q1 and begin shipping testnets in early Q2, it would be better to ship it as a single fork. While this seems feasible on our side, it's particularly difficult for us to assess the readiness of PeerDAS.

By splitting the fork, we mean:
PectraA (pectra-devnet-3 scope): EIP-2537, EIP-2935, EIP-6110, EIP-7002, EIP-7251, EIP-7549, EIP-7685, EIP-7702.
PectraB: EOF, EIP-7623, RIP-7212, EIP-7762 (Currently being discussed internally), EIP-7742, plus PeerDAS and any additional CL-specific EIPs the CL teams decide to include.

[vbuterin]

I think we should revisit adding EIP-7623 and a small blob count increase (eg. target 3 -> 4, max 6 -> 8) for PectraA.

The basic argument is that blob space is currently ~75% full, and I think the ecosystem is sleeping on the fact that it's uncomfortably close to a ceiling: the fees seem to be reliably near-zero, but there's undoubtedly multiple layer 2s that have considered moving to blobs and decided not to, because they themselves would clog the market if they come in. The L2 blob market is fundamentally different in this regard, in that there is a relatively small number of "buyers", each of which takes up a large share of the market. I particularly worry that the nature of the market, with seeming permanent 1-gwei basefee, is causing many people to underestimate the urgency of this. We cannot afford to let momentum slip on moving more layer 2s over to using blobs.

EIP-7623 is crucial for this, because it ensures that the worst-case size of a block massively decreases. Today, the worst-case size of a block is ~2.7 MB, with EIP-7623 it drops to ~1 MB. Meanwhile, an increase to the target by 1 only increases the worst-case size by 2 blobs (~0.25 MB). Thus, if we add both, we get a Pareto improvement, both net-reducing worst-case block size, and adding capacity.

[onbjerg]

As stated elsewhere, Reth supports @ralexstokes's initial proposal on the split, and we'd like to freeze the spec for both sides of the split.

[jwasinger]

The PR to increase the cost of EIP2537 MSM precompiles by 2x is here: ethereum/EIPs#8910

[akashkshirsagar31]

Podcast (audio only) - https://open.spotify.com/episode/1yymo1b1vaC8FjPeANsofl?si=egFz386dSSeJB2HS6t1a1Q

[jessepollak]

I shared this on Twitter, but I'll also just voice this here: I strongly support @vbuterin's proposal to increase blob count, combined with EIP-7623. Reduces worst-case block size and adds needed capacity for fast growing L2s. the growth is exponential!

As discussed on ACDE and other calls, the Base team is actively contributing to both client changes, simulation, and monitoring to unlock this — and we're ready to do more. If folks see opportunities for us to dive deeper, please let me, @roberto-bayardo, or @0x00101010 know.

[timbeiko]

Closed in favor of #1163

[ryanberckmans]

Before we add more blobs, imo we must develop a rigorous definition of staking bandwidth requirements to help maximize credible neutrality, especially so we know where the validators can and can’t migrate should a disaster warrant such a migration.

https://ethresear.ch/t/wheres-the-home-staking-bandwidth-research/20507

https://x.com/ryanberckmans/status/1839663502035747119