Consensus-layer Call 150

[ralexstokes]

Consensus-layer Call 150

prev: call 149

Meeting Date/Time: Thursday 2025/2/6 at 14:00 UTC
Meeting Duration: 1.5 hours
stream

1. Electra
   • devnet-6
     • status/updates
     • confirm builder api testing
     • [EL] 7702 mempool progress
     • beacon-api: Consensus-layer Call 150 #1265 (comment)
   • testnet fork timing
     • candidates: Consensus-layer Call 150 #1265 (comment)
     • 30-day buffer? Consensus-layer Call 150 #1265 (comment)
2. PeerDAS / Blob scaling
   • devnet-4 status
   • blockers on devnet-5 ?
3. Research, spec, etc.
   • Hardware and bandwidth requirements: Add EIP: Hardware and Bandwidth Recommendations EIPs#9270
   • Fusaka PFI
     • Consensus-layer Call 150 #1265 (comment)
   • Pectra retrospective
4. Open discussion/Closing remarks
   • Pectra Bug Bounty Attackathon

[kevaundray]

I would like to discuss the hardware and bandwidth requirements, set out here: ethereum/EIPs#9270

[abcoathup]

Eth Magicians: https://ethereum-magicians.org/t/all-core-devs-consensus-acdc-150-february-6-2025/22703

[fredrik0x]

I would like to discuss/mention the upcoming Pectra Bug Bounty Attackathon

[smartprogrammer93]

I would like to point that i am proposing 7732 for fusaka
ethereum/EIPs#9291

[leeederek]

I would like to bring up, for discussion, the topic of giving the community at least 30 days between the last testnet fork and the mainnet fork. This would follow precedent set by the Cancun-Deneb upgrade in 2024 where we had ~35 days (Holeksy was forked on Feb 7, 2024 while mainnet was forked on March 13, 2024).

This is to allow L2s more time to test, audit, and implement relevant changes and also allow for any on-chain governance processes to complete on time for near-Day 1 support for Pectra.

I would love to hear from folks who believe that Pectra timelines should be different than what happened with Dencun - specifically the time between last testnet fork and the mainnet fork.

Thank you!

[timbeiko]

Here are some candidate timelines for us to discuss on the call tomorrow (thanks to https://slots.symphonious.net):

1. Client testnet releases out by Feb 10
   • Holesky slot: 3670016 (Wed, Feb 19 at 05:23:12 UTC)
   • Sepolia slot: 7061504 (Tue, Feb 25 at 08:20:48 UTC)
   • +30 day mainnet slot: 11354112 (Thu, Mar 27 at 11:02:47 UTC)
2. Client testnet releases out by Feb 13 (ACDE)
   • Holesky slot: 3710976 (Mon, Feb 24 at 21:55:12 UTC)
   • Sepolia slot: 7118848 (Wed, Mar 5 at 07:29:36 UTC)
   • +30 day mainnet slot: 11444224 (Tue, Apr 8 at 23:25:11 UTC)
3. Client testnet releases out by Feb 17
   • Holesky slot: 3727360 (Thu, Feb 27 at 04:32:00 UTC)
   • Sepolia slot: 7118848 (Wed, Mar 5 at 07:29:36 UTC)
   • +30 day mainnet slot: 11444224 (Tue, Apr 8 at 23:25:11 UTC)

Note that the "+30 day mainnet slots" are the earliest slots at a decent time that we could use if we followed @leeederek's suggestion. Of course, if we find issues during testnet rollout, this will be delayed.

[mcdee]

I may have already missed the discussion, but the ordering of the testnet upgrades seems backwards to me.

Sepolia is far more of an internal network, in that it has a permissioned (and small, and known) validator set. As such, it is a more controlled environment in which to carry out an upgrade. It would also give more time for everyone who needs to test smart contracts, as sepolia is the "execution" chain (as opposed to holesky, which is the "validator" chain.)

Given that the chance of a failure is higher with the first testnet upgrade than the second, it seems like sepolia is a better option to start with. If we start with holesky, and there are problems, there will be no chance for the vast majority of node operators to go through a clean update before the mainnet hard fork itself. So if holesky went second it would have more of a chance to be a clean update, and increase the wider comfort levels. Conversely, if holesky goes first and there are problems with the update, but these don't occur with sepolia when it goes second, it may not give much positive information given that the validators on sepolia are either client teams, the EF, or experienced node operators.

For dencun we upgraded goerli first, because it was already near enough end-of-life so it mattered far less if there was an issue. That reasoning doesn't apply here, so I would like to suggest we go sepolia then holesky to have the best chance of the widest number of node operators having a successful testnet update ahead of mainnet.

[rolfyone]

We'll be fine with option 1.

@mcdee the reasoning explained to me is there's a lot of app stuff on sepolia which would potentially be disrupted. I guess given there's tighter validator control on sepolia it'd be easy to pivot that quickly if we needed.

[philknows]

Lodestar can make Option 1 work.

@mcdee the reasoning explained to me is there's a lot of app stuff on sepolia which would potentially be disrupted. I guess given there's tighter validator control on sepolia it'd be easy to pivot that quickly if we needed.

I was told something similar. Sepolia should be as stable as possible for dapp developers. Though I can be easily convinced to go either way as I would think dapp devs would like a stable "preview" of Pectra sooner for development purposes.

[realbigsean]

Lighthouse would prefer option 2, it will be tough for us to get a release out by the 10th

[ralexstokes]

the rationale on holesky vs sepolia was that there are many validator features to test in pectra; and so going with holesky first (which is meant more for stakers, rather than apps/users) would allow time for this relative to doing the other order

we can discuss further on the call

[rolfyone]

Can we get a more final spec so that we can update the beacon-api references, or are we still needing more beta releases?