AllCoreDevs - Testing #101

gm

gm

gm gm

Dan,the BPO stuff should be discussed together with CLs btw

Reacted to "Dan,the BPO stuff sh..." with 💙

Reacted to "Dan,the BPO stuff should be discussed together with CLs btw" with 💙

📋 ACDT #101 agenda: https://github.com/ethereum/pm/issues/2271

🐻‍❄️🌐 Glamsterdam networks: Sepolia (forked Oct 6), devnet-8 (benchmarking), devnet-12, mainnet shadow forks https://dora.glamsterdam-devnet-8.ethpandaops.io https://dora.sepolia.ethpandaops.io https://glamsterdash.pk910.de

we are currently missing releases for erigon/geth/reth

🔀 Rename BPO test forks and base them on Amsterdam https://github.com/ethereum/execution-specs/pull/3597 https://github.com/ethereum/hive/pull/1611 BPO3 raises the blob schedule, BPO4 lowers it. Proposal: - Duplicate BPO2ToBPO3 as AmsterdamToBPOIncrease (tests both forks; drop BPO2ToBPO* after mainnet) - BPO3ToBPO4 -> BPOIncreaseToBPODecrease OK for clients, or keep testing BPO2ToBPO* until mainnet? No changes needed: Erigon, ethrex, Nethermind, Reth Client changes needed, PRs open: - Besu: https://github.com/besu-eth/besu/pull/11646 - Geth: https://github.com/ethereum/go-ethereum/pull/35975 - Nimbus-EL: https://github.com/status-im/nimbus-eth1/pull/5012

we added automatic BPO values being set on kurtosis based on seconds per slot. So the total blob throughput per second stays consistent with 15/21.

ah yes this is for Hegota

sorry

Reacted to "ah yes this is for..." with 👍

🏗️ Glamsterdam: separate builder and validator deposits at the Gloas fork https://github.com/ethereum/consensus-specs/pull/5736

Reacted to "sorry" with 💙

And other LSTs

And this is less than a complication. But more of an issue

sgtm

ok whatever, let's replay the pectra disaster

have fun

Reacted to "ok whatever, let's r..." with 😄

I would vote if we want this in, we should delay hoodi by a week at least, and have client releases out.

Replying to "ok whatever, let's r..." that's why we didnt change it for hoodi last minute

The holesky incident

yes the holesky incident

Reacted to "I would vote if we want this in, we should delay hoodi by a week at least, and have client releases out." with 👍🏼

Reacted to "I would vote if we..." with 👍🏼

yeah agreed that we have to delay if we’re gunna do this. and since it sounds like there’s a workaround I don’t think it’s worth the delay

I explictly don't care, it's too late

Sepolia was not a sample because there were no pending builders

So it does not matter

1 week sounds bad, you don’t want hoodi during devcon

it's too bad, I agree in principle that Lido has pointed out a real problem

but it's still too late

it was problem before 8282, but we could have fixed it as part of 8282

Yeah 8282 didn't really cause it

it was a missed opportunity though

Reacted to "it was a missed oppo..." with 👍

Reacted to "it was a missed oppo..." with 👍

then I am strongly against fixing it

Yeah its either this or that. We can’t make the change and keep the schedule. So either we want to fix this bug or keep the schedule.

"just one thing"

no no no

juts o

why is moving the deadline "not great"?

Replying to "why is moving the de..." devcon

Replying to "why is moving the de..." why would shipping in feb be bad?

Replying to "why is moving the de..." ship glammy together with hegota?

Replying to "why is moving the de..." It delays everything

Reacted to "ship glammy together with hegota?" with 😅

Replying to "why is moving the de..." Then it would delay everything else.

Reacted to "It delays everything" with 👍

Reacted to "Then it would delay everything else." with ☝️

Replying to "why is moving the de..." obviously i know that, why does that matter vs. the risk?

Reacted to "ship glammy together..." with 🚀

Reacted to "ship glammy togeth..." with 😅

Reacted to "ship glammy together..." with 🚀

Reacted to "ship glammy together with hegota?" with 🚢

Lol

Reacted to "Lol" with 😂

Reacted to "ship glammy together with hegota?" with 😅

But should holidays be an excuse for keeping bug?

Don’t you guys have a workaround

It’s better safe than sorry, so can’t really downplay the complexity even if it looks simple

We definitely 100% should not unscheduled Hoodi. This is ask is not worth that.

Reacted to "We definitely 100% should not unscheduled Hoodi. This is ask is not worth that." with 🙏

Reacted to "We definitely 100%..." with 🙏

How hard would be to make the fix before hoodi?

Replying to "But should holidays ..." Bah hum bug

Replying to "But should holidays ..." I agree with this, I don't mind fixing this, but I don't want to fix this AND keep the aggressive deadlines

yeah agree, "unscheduling" Hoodi absolutely 100% a nonstarter

Replying to "But should holidays ..." Depends on how bad the bug is and if there is a workaround

Reacted to "We definitely 100% should not unscheduled Hoodi. This is ask is not worth that." with 🙏

it's another great way to fork things

would we need to retests builder deposit cache?

Michael from Lighthouse also voiced on this

I am for it and have it implemented and analyzed but I want it for mainnet, not hoodi

Reacted to "ship glammy togeth..." with 🚀

Reacted to "ship glammy togeth..." with 🚢

Reacted to "ship glammy togeth..." with 😅

🐻‍❄️🚀 Hoodi Glamsterdam: Mon Oct 26, 17:42:48 UTC, epoch 132352, gas limit 200M at the fork https://github.com/eth-clients/hoodi/pull/31 https://github.com/ethereum/pm/pull/2263

Reacted to "🐻‍❄️🚀 Hoodi Glamsterdam: Mon Oct 26, 17:42:48 UTC, epoch 132352, gas limit 200M at the fork https://github.com/eth-clients/hoodi/pull/31 https://github.com/ethereum/pm/pull/2263" with 💪

🐻‍❄️🚢 Hoodi releases vs EF blog (checked 13:20 UTC): https://blog.ethereum.org/en/2026/10/16/glamsterdam-hoodi-announcement EL: - Besu 26.10.0: matches blog - Erigon: not in blog, v3.7.1 lacks Hoodi Glamsterdam (on main only) - ethrex v30.0.0: newer than blog (rc.2); Hoodi config verified - Geth: not in blog, Hoodi not scheduled yet (go-ethereum#35974 open) - Nethermind 2.2.0: matches blog - Nimbus-EL v0.4.3 (Oct 17): not in blog; Hoodi config verified - Reth: not in blog, no Hoodi Glamsterdam config on main yet CL: - Grandine 3.0.0-rc.1 (Oct 19, prerelease): matches blog - Lighthouse v8.3.0 (Oct 19): matches blog - Lodestar v1.50.0: matches blog - Nimbus v26.10.1: matches blog - Prysm v7.3.0: matches blog - Teku 26.10.1: matches blog

Replying to "would we need to ret..." yep would have to retest that similar to what we did on devnet-12

We’ll release today or latest tomorrow morning for Charon

Replying to "would we need to ret..." Yes, exactly

"- Nimbus-EL v0.4.3 (Oct 17): not in blog; Hoodi config verified" yeah I mean, we did a release which could be included in the blog if so inclined

that was the goal

Replying to "would we need to ret..." I think this would be a bit of a PITA ?

Replying to "would we need to ret..." So would need some sort of devnet with a fork transition

Replying to "would we need to ret..." Yes it would be

btw their is the dst stuff in europe (and possibly in other places); acdt is one hour earlier for me than today

Replying to "btw their is the d..." (next week monday)

Replying to "it was problem befor..." This is not entirely correct: this was NOT a problem when builders were validators, this only is a problem now because the oracle of a bad validator does not exist on the beacon state

Reacted to "btw their is the dst stuff in europe (and possibly in other places); acdt is one hour earlier for me than today" with 🔥

Reacted to "btw their is the dst stuff in europe (and possibly in other places); acdt is one hour earlier for me than today" with 🔥

🗄️ BAL retention: ELs keep BALs available via getPayloadBodiesBy*V2 for HISTORY_PRUNE_EPOCHS = 14,299 epochs https://github.com/ethereum/EIPs/pull/12347 https://github.com/ethereum/consensus-specs/pull/5680 https://github.com/ethereum/execution-specs/issues/3667

BAL retention period increase PR (to be merged): https://github.com/ethereum/EIPs/pull/12347

BAL retention today (EL), target 14,299 epochs: - Besu: 14,299 epochs default and minimum (merged) - https://github.com/besu-eth/besu/pull/11417 - Erigon: prunes at finality, regenerates on demand (~2 s); full mode ~8,192 epochs - https://github.com/erigontech/erigon/issues/24100 - ethrex: unknown - Geth: keeps BALs forever (none below the snap-sync pivot) - Nethermind: 14,299 epochs by default, capped at sync pivot (PR open) - https://github.com/NethermindEth/nethermind/pull/14609 - Nimbus-EL: 3,533 -> 14,299 epochs (PR open, waits on EIPs#12347) - https://github.com/status-im/nimbus-eth1/pull/4815 - Reth: in memory, 3,533 epochs, lost on restart - https://github.com/paradigmxyz/reth/issues/27293

Replying to "I am for it and have..." what if this is triggered on Hoodi?

Replying to "would we need to r..." yes please

Replying to "it was problem befor..." ok but that was way before 8282, we changed that in janurary

Replying to "it was problem befor..." yes, and absolutely everything that came after was because of that change. The people that had a state of mind with the previous spec did not spend the same amount of time vouching for the changes that this brought.

Dustin, get out of the Cavern you are right now so that we can hear you better

We have no pruning, yet. I have some work in progress in a PR

all el clients have an issue I opened a while ago as reminder

Replying to "Dustin, get out of t..." Tavern*

uh oh. dan has entered teh cavern

Reacted to "uh oh. dan has entered teh cavern" with 😅

It is done on besu side : https://github.com/besu-eth/besu/pull/11417

Reacted to "uh oh. dan has entered teh cavern" with 💀

Reacted to "uh oh. dan has entered teh cavern" with 💀

Reacted to "uh oh. dan has enter..." with 💀

Reacted to "uh oh. dan has entered teh cavern" with 💀

Reacted to "uh oh. dan has entered teh cavern" with 😅

Reacted to "uh oh. dan has ent..." with 💀

Reacted to "uh oh. dan has enter..." with 💀

Reacted to "uh oh. dan has entered teh cavern" with 😅

Reacted to "Tavern*" with 😂

Reacted to "uh oh. dan has enter..." with 💀

Reacted to "uh oh. dan has entered teh cavern" with 💀

Reacted to "uh oh. dan has entered teh cavern" with 😅

Reacted to "Tavern*" with 😂

Reacted to "Tavern*" with 😂

Reacted to "Tavern*" with 😂

Reacted to "uh oh. dan has ent..." with 💀

Replying to "it was problem befor..." Yeah you’re right Nico. This would have still been a problem pre-8282.

Reacted to "uh oh. dan has ent..." with 😅

Reacted to "uh oh. dan has enter..." with 😅

Replying to "uh oh. dan has enter..." @danceratopz we can’t hear you

Nethermind PR: https://github.com/NethermindEth/nethermind/pull/14609

Reacted to "uh oh. dan has enter..." with 💀

@Justin Traglia You are taking over?

Still no, dan

Yes this is an issue perhaps with Heze if it gets lowered

I was curious about this too

Replying to "uh oh. dan has ent..." it sounds like a signal/bandwidth issue, you sound like a 🤖

I'm so back.

Reacted to "I'm so back." with 🤣

Reacted to "I'm so back." with 🤣

Reacted to "I'm so back." with 🤣

We don’t dedup non finalized data as well

Reacted to "I'm so back." with 🤣

I am far from CL expert but should this constant not be a relation with validator count / WSP? (so not a constant)

Reacted to "I'm so back." with 🔥

Replying to "I'm so back." joined the tavern’s wifi?

Reacted to "I'm so back." with 🔥

Reacted to "joined the tavern..." with 😅

Reacted to "I'm so back." with 🤣

Reacted to "I'm so back." with 🔥

Reacted to "I'm so back." with 🤣

Reacted to "joined the tavern’s wifi?" with 😅

Reacted to "joined the tavern’s ..." with 😅

Replying to "I'm so back." you always need 2 x danceratopz for it to be a meeting

confirmed besu has the increase here: https://github.com/besu-eth/besu/pull/11417

Reacted to "you always need 2 x danceratopz for it to be a meeting" with 😂

Reacted to "you always need 2 x danceratopz for it to be a meeting" with 😂

btw aren’t BALs a bit redundant? We don’t need to have bals, it could be recalculated on the fly?

Shouldn’t the EL just not prune non-finalised payloads?

kev's eip in hegota to reduce to 8192?

Reacted to "kev's eip in hegota ..." with 👍

Reacted to "Tavern*" with 😂

Reacted to "kev's eip in hegot..." with 👆

Replying to "kev's eip in hegota to reduce to 8192?" yeah still a lot, no?

Reacted to "kev's eip in hegota ..." with 👍

Replying to "kev's eip in hegota to reduce to 8192?" but I see where it comes from and makes sense

Replying to "kev's eip in hegota ..." can happen though

Replying to "kev's eip in hegota ..." ehm to be discussed I guess, not sure what's a safe number

Reacted to "joined the tavern’s wifi?" with 😅

Reacted to "kev's eip in hegota to reduce to 8192?" with 👍

Reacted to "ok but that was way before 8282, we changed that in janurary" with 👍

Reacted to "kev's eip in hegota to reduce to 8192?" with 👍

Reacted to "Tavern*" with 😂

//eips.ethereum.org/EIPS/eip-8252

I think we should increase the penalty during non finality, so we can lower this number too

Replying to "yeah, this might be ..." yeah I think this is good

agree potuz but I don't think the forumla would be deterministic and needs to make some assumptions/ use a heuristic

Replying to "agree potuz but I do..." yeah I agree, it's a good heuristic in itself though

📜 Heads up: Suggested scoping process change Unmerged EIPs stay off call agendas; PFI'd EIPs with no client support default to DFI. Please review before ACDE #248. https://github.com/ethereum/pm/pull/2275

Reacted to "yeah I agree, it's a..." with 👍

//eips.ethereum.org/EIPS/eip-8252" it's the time it takes to restore finality if up to ~79% of stake goes offline

🧪 Hegota devnets: heze-devnet-1 (FOCIL) and bogota-devnet-1 (frames) https://dora.heze-devnet-1.ethpandaops.io https://dora.bogota-devnet-1.ethpandaops.io Frames breakout #7 tomorrow: https://github.com/ethereum/pm/issues/2272

⚙️ heze-devnet-2 alignment, to clarify on this call: slot duration, EL blob schedule, IL deadline (#5727) 1. CL slot duration: 12s via SLOT_DURATION_MS_HEZE? 2. EL blob schedule: 12/18 (EELS tests) or 14/21 (genesis generator)? 3. IL deadline: #5727 (9s) in via devnet config? https://notes.ethereum.org/@ethpandaops/heze-devnet-2 https://github.com/ethereum/consensus-specs/pull/5743 https://github.com/ethereum/consensus-specs/pull/5727 https://github.com/ethereum/execution-specs/releases/tag/tests-heze-devnet@v2.0.0

I have a comment to try to align blob params and it seems like we've changed shorter slots so let's align that too?

https://github.com/ethereum/execution-specs/pull/3703/changes#diff-113a250e2deeea5cc1c2d1d5ab072d0c126723e3290cffacdd7b001bab3efd41R18-R34 and ethrex has this too.

https://github.com/ethereum/consensus-specs/pull/5743

https://github.com/ethereum/consensus-specs/pull/5718

This sounds like a call to clarify what CFI really means

Reacted to "This sounds like a call to clarify what CFI really means" with 👍

Sorry, I’m back. My power went out for a minute. Bad timing.

Reacted to "This sounds like a..." with 👍

Reacted to "This sounds like a c..." with 👍

Reacted to "Sorry, I’m back. My ..." with 💙

how would you test 2 different EIPs that interact with each other?

this is ACD! With T at the end :)

Reacted to "this is ACD! With T at the end :)" with 💯

Replying to "This sounds like a..." in eels we only merge to main branch on sfi, should it be the same for consesus specs?

Reacted to "this is ACD! With ..." with 💯

Reacted to "this is ACD! With ..." with 💯

Reacted to "this is ACD! With T at the end :)" with 💯

I agree with the argument in general, but just want to point out that technically it's not true that EIPs are merged only after getting SFI'd. From my undersrtanding, going through dev's review is the point.

Reacted to "I agree with the argument in general, but just want to point out that technically it's not true that EIPs are merged only after getting SFI'd. From my undersrtanding, going through dev's review is the point." with 👍

Reacted to "I agree with the argument in general, but just want to point out that technically it's not true that EIPs are merged only after getting SFI'd. From my undersrtanding, going through dev's review is the point." with 👍

Replying to "This sounds like a c..." I think so (no strong opinion), though it sounds like it makes testing EIP interactions a bit more difficult?

Reacted to "I agree with the argument in general, but just want to point out that technically it's not true that EIPs are merged only after getting SFI'd. From my undersrtanding, going through dev's review is the point." with 👍

Lets do blobs per second adjusted to current values

Replying to "This sounds like a c..." Yes I think this is mandatory cause merging in the main branch is more disruptive than what it helps on testing

Replying to "I agree with the arg..." But say EIP-8365 for example, the spec PR is merged only two hours after it’s opened and I doubt everyone had a chance to review.

Replying to "Sorry, I’m back. My ..." i know the feeling man

Reacted to "Sorry, I’m back. ..." with 💙

is this heze-devnet-2?

"next devnet"

ok

Reacted to "i know the feeling man" with 😂

ty

Replying to "I agree with the arg..." Yeah, that's on me. It should have not done in a rush.

yeah, I mean, to me the spec-release then devnet is ideal

Replying to "Sorry, I’m back. My ..." My neighbor is getting a home battery installed & I guess our power lines are connected somehow.

Reacted to "My neighbor is get..." with 💀

Reacted to "i know the feeling m..." with 😂

Reacted to "My neighbor is getti..." with 💀

Reacted to "yeah, I mean, to me ..." with 👍

THANK YOU

It's a issue downstream of us not having a clear CFI -> devnet process.

it's a slippery slope that ends up sponsoring an EIP based on sunk cost

For some it's just testing a feature, for others it's a step towards SFI

Reacted to "it's a slippery slope that ends up sponsoring an EIP based on sunk cost" with 👏

I don't think its been defined properly in EIP-7723 We should update it!

did we not have a broad consensus its CFI-ed?

Reacted to "I don't think its been defined properly in EIP-7723 We should update it!" with 👍

Consensus-specs has a features folder, I think we are talking about merging into heze folder on main?

Reacted to "I don't think its been defined properly in EIP-7723 We should update it!" with 👍

Replying to "For some it's just..." For me its testing a feature, but i understand the context

Replying to "Consensus-specs has ..." Yes.

CFI means that it gets implemented and tested on a devnet. SFI is shipping to mainnet.

Replying to "did we not have a br..." that was already a hard call bty Alex

Fwiw Justin Traglia does not even like Quick Slots, can we not be conspiratorial...

Reacted to "Fwiw Justin Traglia does not even like Quick Slots, can we not be conspiratorial..." with 👍

Reacted to "Fwiw Justin Traglia does not even like Quick Slots, can we not be conspiratorial..." with 👍

Replying to "it's a slippery slop..." definitely. Need to spend non-trivial effort to un-merge some EIPs from the spec if we want to dfi a cfi'ed eip

Reacted to "Fwiw Justin Traglia does not even like Quick Slots, can we not be conspiratorial..." with 👍

Reacted to "Fwiw Justin Tragli..." with 👍

Reacted to "Fwiw Justin Tragli..." with 👍

Replying to "Fwiw Justin Traglia ..." Right, I think its more that this needs to be clarified

Replying to "Fwiw Justin Traglia ..." we're not being conspiratorial, and I don't blame Justin, but the speed at which we are merging things in main branches is crazy

Replying to "Fwiw Justin Traglia ..." The whole point of this discussion is to stop this and be more transparent about what goes in the main branches

Replying to "Fwiw Justin Traglia ..." Not arguing with the broader point, just it can be said without implying that something improper has happened

ok, the point though is what whether it's CFI or SFI or .... then devnets need to interop

Replying to "did we not have a br..." There was not “broad” consensus

Replying to "Fwiw Justin Traglia ..." For previous upgrades, we did merge things into upgrade specs before they were SFI'd.

Replying to "Fwiw Justin Traglia ..." but something improper has happened!

that includes test vectors, kurtosis, etc

how do we target a specific commit for consensus spec for a devnet?

if we have x many open PRs?

Reacted to "For previous upgra..." with 👍

quick slots isn't even merged on the spec side

Reacted to "quick slots isn't even merged on the spec side" with 👍

Reacted to "quick slots isn't even merged on the spec side" with 👍

Reacted to "quick slots isn't even merged on the spec side" with 👍

Reacted to "quick slots isn't ..." with 👍

Reacted to "quick slots isn't ..." with 👍

Replying to "quick slots isn't ev..." I think there's parts of it in already, but Barnabas makes some fixes over Jihoon's merge

Reacted to "My neighbor is getti..." with 💀

Replying to "quick slots isn't ev..." Yeah it doesn’t need to go into the next devnet. I wanted it to be optional.

Replying to "quick slots isn't ev..." Jihoon’s PR is not merged

Replying to "quick slots isn't ev..." Quick Slots is not merged for the record.

Replying to "quick slots isn't ev..." Quick slots is not in the Heze specs.

Network Upgrade Inclusion stages; https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7723.md

Maria very patiently has her hand up, not sure how long now 😅

Reacted to "Maria very patiently has her hand up, not sure how long now 😅" with 😅

Replying to "quick slots isn't ev..." So what were we talking about so far?

Reacted to "Maria very patiently..." with 💙

Replying to "quick slots isn't ev..." Same, what’s the contention?

Replying to "quick slots isn't ev..." ah if Jihoon's PR is not merged then we should rebase Barnabas' on top of Jihoon's instead o opening it on Heze

Reacted to "Maria very patiently..." with 🙏

Reacted to "Maria very patiently has her hand up, not sure how long now 😅" with 💙

Replying to "quick slots isn't ev..." thats what I did

Replying to "quick slots isn't ev..." Partly based on just misunderstanding.

Replying to "quick slots isn't ev..." It should ideally not be merged and it feels like its being pushed through

I agree with Maria

Replying to "quick slots isn't ev..." https://github.com/jihoonsong/consensus-specs/pull/3

Replying to "quick slots isn't ev..." but he’s using a fork instead of a branch unfortunately

Replying to "quick slots isn't ev..." so its hard to find

Replying to "quick slots isn't ev..." If I were to push for either of those two PRs, I would ask for an explicit appropval by devs.

📦 Hegota devnet plan: hegota-devnet-0 before Mumbai? hegota-devnet-1 EL scope: EIP-8298, EIP-8131, EIP-8279, EIP-8253, EIP-4758 https://github.com/ethereum/pm/issues/2271#issuecomment-6265056113 https://github.com/ethereum/execution-specs/issues/3664

Replying to "quick slots isn't ev..." We don’t want to push things through without legitimacy, but also want to make progress ofc. I’m confused what’s the issue in the current situation

I think there were two conversations being had? CFI'd EIPs prob should be tested in a devnet but should not be merged to a trunk branch's main fork implementation in order to not sink cost into the main impl, which would be hard to rip back out.

bogota-devnet-1 is running also spamming frame transactions

Reacted to "bogota-devnet-1 is running also spamming frame transactions" with 🔥

Replying to "quick slots isn't ev..." Who is pushing things through, what are we even talking about 😅

Replying to "quick slots isn't ev..." > thats what I did barnabasbusa wants to merge 14 commits into ethereum:master from barnabasbusa:bbusa/eip8198-heze I saw this right before coming to the meeting

do we want shorter slots in heze devnet 2 ?

Replying to "I think there were..." the cost is kind of sunk anyway

Replying to "do we want shorter s..." No

Replying to "quick slots isn't ev..." Is it into the features folder?

Replying to "do we want shorter s..." so we just want beta 4 ?

Yes, just beta.4

Replying to "quick slots isn't ev..." Don’t have context, but there is a features folder which is possibly where Barnabas was merging that change into on main, and not in the heze folder on main

Replying to "do we want shorter s..." devnet 2 without shorter slot is very slim improvement of devnet 1

Replying to "quick slots isn't ev..." No, its merging into heze folder which is the issue

Replying to "quick slots isn't ev..." Ah

https://ethereumfoundation.zoom.us/j/89441658268?pwd=yjqf4TheEb1R7ZSuesCdOAy5tdyVk7.1

discv5 defaults per client https://discord.com/channels/595666850260713488/1413582163747803247/1557274198349586507

- Besu: discv4 only in 26.9.0; discv4+discv5 since besu#11344 (in 26.10.0?) - https://github.com/besu-eth/besu/pull/11344 - Erigon: discv5 (discv4 behind a switch) - ethrex: discv4 + discv5 - Geth: discv4 + discv5 - Nethermind: discv4 + discv5 - Nimbus-EL: discv5 only - Reth: discv4 + discv5

- Besu: discv4 only in 26.9.0; discv4+discv5 since besu#11344 (in 26.10.0?) - https://github.com/besu-eth/besu/pull/11344 - Erigon: discv5 (discv4 behind a switch) - ethrex: discv4 + discv5 - Geth: discv4 + discv5 - Nethermind: discv4 + discv5 - Nimbus-EL: discv5 only - Reth: discv4 + discv5" with ✅

Reacted to "No, its merging in..." with 👍

- Besu: discv4 only in 26.9.0; discv4+discv5 since besu#11344 (in 26.10.0?) - https://github.com/besu-eth/besu/pull/11344 - Erigon: discv5 (discv4 behind a switch) - ethrex: discv4 + discv5 - Geth: discv4 + discv5 - Nethermind: discv4 + discv5 - Nimbus-EL: discv5 only - Reth: discv4 + discv5" with ✅

Replying to "📡 discv5 defaults p..." Yes, for besu : discv4+discv5 since besu 26.10.0

Reacted to "Yes, for besu : disc..." with 💙

- Besu: discv4 only in 26.9.0; discv4+discv5 since besu#11344 (in 26.10.0?) - https://github.com/besu-eth/besu/pull/11344 - Erigon: discv5 (discv4 behind a switch) - ethrex: discv4 + discv5 - Geth: discv4 + discv5 - Nethermind: discv4 + discv5 - Nimbus-EL: discv5 only - Reth: discv4 + discv5" with ✅

🐳 Heads up: EELS hive simulators as prebuilt images (about to merge) Hive pulls an image per test release instead of building: simulator build 100+ s -> seconds. Pick a release with --sim.buildarg tag=<tag> (v21.0.1, latest, nightly, <name>-devnet-<n>). Core: https://github.com/ethereum/execution-specs/pull/3572 then https://github.com/ethereum/hive/pull/1609 Client CI PRs (spencer-tb), please review: - Erigon: https://github.com/erigontech/erigon/pull/25061 - ethrex: https://github.com/lambdaclass/ethrex/pull/7432 - Nethermind: https://github.com/NethermindEth/nethermind/pull/14898 - Reth: https://github.com/paradigmxyz/reth/pull/28021 Besu, Geth, Nimbus-EL: switch hive runs to --sim.buildarg tag=<tag> (works now).

@emma (reth) , please check https://hive.ethpandaops.io/#/group/generic?suites=discv5 You seem to have few failed tests still

To be fair, I was adding new tests a few weeks ago, so maybe it is that