Title: All_Core_Devs___Consensus__ACDC___151__February_20
Category: Protocol_Calls___happenings

Author: system
Date: 2025-02-19T23:50:40.709Z

Consensus-layer Call 151
Agenda
Consensus-layer Call 151 · Issue #1280 · ethereum/pm · GitHub moderated by @ralexstokes


Agenda
prev: call 150
Meeting Date/Time: Thursday 2025/2/20 at 14:00 UTC
Meeting Duration: 1.5 hours
stream

Electra

devnet-6 open questions?

attestation aggregation under EIP-7549


testnet readiness


PeerDAS / Blob scaling

peerdas-devnet-4
Bump up Fulu blob count
Migration of proof computation to transaction sender, vs beacon node

Offloading Proof Computation from Beacon Nodes to Transaction Sender - HackMD


BPO forks


Research, spec, etc.

Max blobs and hardware requirements update


Open discussion/Closing remarks


Summary




All Core Devs - Consensus (ACDC) #151, February 20, 2025 Protocol Calls & happenings


    ACDC #151 summary 
Action Items 

Pectra Holesky fork at epoch 115968 (Feb. 24, 21:55 UTC)

Update any infrastructure and be prepared to monitor the hard fork!
Pectra Testnet Announcement | Ethereum Foundation Blog


Review attestation performance on the upcoming mainnet shadowfork and on Holesky (following discussion of EIP-7549 impact)
Last call for EIPs recommending minimum hardware requirements and the associated “max blobs” flag

Add EIP: Hardware and Bandwidth Recommendations for Validator…


Recording



youtube.com


- YouTube
Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.






Writeups

Ethereum All Core Developers Consensus Call #151 Writeup | Galaxy by @Christine_dkim

Additional info

Testnets:

Pectra-devnet-6
Ephemery testnet
Pectra Testnet Announcement | Ethereum Foundation Blog


Last call for Pectra Retrospective

Author: ralexstokes
Date: 2025-02-22T19:25:56.794Z

ACDC #151 summary
Action Items

Pectra Holesky fork at epoch 115968 (Feb. 24, 21:55 UTC)

Update any infrastructure and be prepared to monitor the hard fork!
Pectra Testnet Announcement | Ethereum Foundation Blog


Review attestation performance on the upcoming mainnet shadowfork and on Holesky (following discussion of EIP-7549 impact)
Last call for EIPs recommending minimum hardware requirements and the associated “max blobs” flag

Add EIP: Hardware and Bandwidth Recommendations for Validators and Full Nodes by kevaundray · Pull Request #9270 · ethereum/EIPs · GitHub
Add EIP: Max blob flag for local builders by kevaundray · Pull Request #9296 · ethereum/EIPs · GitHub



Summary

Pectra

devnet-6 is stable and looking good!
Still working on Pectra-compatible MEV builder

some final bugs with execution requests, investigation is ongoing


Pectra system contracts are live on Holesky, Sepolia, and Mainnet

Check the respective EIPs for system contract addresses


We discussed attestation aggregation algorithms clients use and updates required in Pectra following EIP-7549

Prysm found an issue with suboptimal packing
Teku suggested their approach by normalizing the new attestation type to the existing attestation type where clients have long-standing and battle-tested algorithms to handle




PeerDAS / blob scaling

peerdas-devnet-4 is underway; some notable issues:

ELs should be able to disable EOF so that PeerDAS can be tested in isolation
Migration of proof computation from the CL to the EL

Needs an update to the network wrapper for blob transactions
Spec update: Update EIP-7594: include cell proofs in network wrapper of blob txs by fradamt · Pull Request #9378 · ethereum/EIPs · GitHub
More info: Offloading Proof Computation from Beacon Nodes to Transaction Sender - HackMD
We discussed this change a bit on this call, but ultimately decided to move to next weeks’ ACDE for EL input.




Announcement of peerdas-devnet-5: https://peerdas-devnet-5.ethpandaops.io/
jimmygchen assembled a PeerDAS readiness checklist to know when we are in a place to move ahead with the PeerDAS feature in Fusaka; please take a look!

pm/Fusaka/peerdas-readiness.md at master · ethereum/pm · GitHub


Discussion around how to scale blob counts in Fusaka

The current spec parameter is much lower than the theoretical maximum.
We agreed to commit to pushing the development as far as we can while keeping networks stable.
We may desire to ship PeerDAS to mainnet at a lower blob count to derisk the new mechanism, but then will want some way to scale to the expected maximum (and ideally without a formal new hard fork, as this implies a lot of boilerplate in CL clients)
Mark brought up the proposal of BPO forks (Blob-Parameter-Only (BPO) forks) to navigate the rollout

For example: ship PeerDAS at half the theoretical max, and also have the infrastructure in clients to programmatically increase the blob count without a new named fork


Dankrad suggested a smart contract implementation maintained by client devs that would provide the blob parameters to scale up without a new hard fork. Another idea suggested is to put the blob parameters under control of validators like the gas limit today.
Keeping all of these options in mind, we agreed to see how PeerDAS R&D goes where we will wait for more data from PeerDAS devnet performance to see what the exact scaling strategy will be.




Updates on minimum hardware requirements

PR to set minimum hardware requirements: Add EIP: Hardware and Bandwidth Recommendations for Validators and Full Nodes by kevaundray · Pull Request #9270 · ethereum/EIPs · GitHub
PR to describe a “max blobs” flag for local block builders to customize their build process: Add EIP: Max blob flag for local builders by kevaundray · Pull Request #9296 · ethereum/EIPs · GitHub
We discussed the interplay between this “max blobs” flag and the getBlobs mechanism, where the flag could not apply if blobs are already present in the mempool (and can be fetched with getBlobs).
We also touched on the consideration of validator profitability in light of the suggested minimum hardware requirements

There was quite a bit of nuance here, so check the call for the full discussion.
As a summary, there are ideas around improving the economics of staking in the future which could change the sustainability of full nodes and/or validators. It is possible that these macro-level improvements could change the extent to which the protocol subsidizes hardware costs today and that would have direct impact to the minimum hardware requirements to participate rationally.
We agreed that we should not let staking economics artificially constrain hardware requirements (e.g. having low in-protocol rewards imply hardware specs that get in the way of scaling the L1), and that we will keep revisiting this question given all of the uncertainty around the future of staking.