Consensus-layer Call 142

[ralexstokes]

Consensus-layer Call 142

prev: call 141

Meeting Date/Time: Thursday 2024/9/19 at 14:00 UTC
Meeting Duration: 1.5 hours
stream

1. Electra
   • devnet-3
   • Pectra scope -- PectrA, PectrB
     • starting point: https://hackmd.io/@ralexstokes/rJVuKtlpR
     • EIP-7688 (SSZ CL updates) in PectrA?
     • Possible blob adjustment assuming PectrA from the hackmd doc (presentation scheduled below)
   • Refactor "switch to compounding validator": eip7251: Switch to compounding when consolidating with source==target consensus-specs#3918
   • eip6110: Queue deposit requests and apply them during epoch processing consensus-specs#3818 if there are updates
   • temperature check these in relation to PectrA: Separate type for unaggregated network attestations consensus-specs#3900, Separate type for onchain attestation aggregates consensus-specs#3787
   • any further comments on the updates to the requests handling?
     • engine: unified list of opaque requests  execution-apis#577
   • assuming PectrA, outstanding updates?
     • engine: Remove engine_getPayloadBodiesBy{Hash|Range}V2 execution-apis#586
     • engine: extract execution requests from payload execution-apis#587
     • remote-signing-api
     • beacon-apis, Add Electra block and state objects from CL spec beacon-APIs#469
     • mev builder pipeline
2. PeerDAS / Blob scaling
   • devnet/implementation updates?
   • Blob count discussion for PectrA/PectrB, link to one proposal from francis.li
3. Research, spec, etc.
4. Open discussion/Closing remarks

[etan-status]

I'd like to check on EIP-7688: Forward compatible consensus data structures once more, for inclusion into PectrA.

• Pectra's EL triggered operations EIPs extend BeaconState so that fields get re-indexed w.r.t. Merkleization, leading to extra maintenance work for Rocket Pool, light clients (including Portal), and EIP-4788 based smart contracts despite none of the semantics of accessed fields having changed.
• Adopting EIP-7688 involves similar maintenance work for the same client applications and smart contracts. However, it comes with a promise that future maintenance work is only required if the semantics of actually accessed fields change.
• The maintenance work needs to be performed for Pectra anyway. Combining EIP-7688 with Pectra ensures that it only has to be done once.
• A majority of client teams has experimented with EIP-7688; there is a working devnet at https://stabilitynow.box with Lighthouse, Lodestar, Nimbus, and Teku implementations.

If there are still other SSZ EIPs on some lists, I'd like to remove other EL-related SSZ EIPs from the Pectra scope. I'm proposing to include only EIP-7688 into Pectra, based on the opportunistic timing where it can be introduced without triggering extra maintenance work for client application developers (which outnumber core developers).

[mkalinin]

I’d like to announce the following update:

• engine: Remove engine_getPayloadBodiesBy{Hash|Range}V2 execution-apis#586

[mkalinin]

Electra adds three queues to the beacon state that are dequeued at epoch processing (pending_deposits, pending_partial_withdrawals, pending_consolidations). Should we be concerned by potential performance degradation of the epoch processing on the mainnet?

[yperbasis]

Erigon's perspective on Pectra split: https://hackmd.io/@somnergy/rJYyPoK6C

[akashkshirsagar31]

Podcast (audio only) - https://open.spotify.com/episode/03qjWkr22SWCiwCydSv4EH?si=_C_u45zKTDyTDvBCaUpo_g

[abcoathup]

Call summary in https://ethereum-magicians.org/t/all-core-devs-consensus-acdc-142-september-19-2024/21086