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": https://github.com/ethereum/consensus-specs/pull/3918
     • https://github.com/ethereum/consensus-specs/pull/3818 if there are updates
     • temperature check these in relation to PectrA: https://github.com/ethereum/consensus-specs/pull/3900, https://github.com/ethereum/consensus-specs/pull/3787
     • any further comments on the updates to the requests handling?
       • https://github.com/ethereum/execution-apis/pull/577
     • assuming PectrA, outstanding updates?
       • https://github.com/ethereum/execution-apis/pull/586
       • https://github.com/ethereum/execution-apis/pull/587
       • remote-signing-api
       • beacon-apis, https://github.com/ethereum/beacon-APIs/pull/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:

• https://github.com/ethereum/execution-apis/pull/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