ACDC2026-10-29_190

AllCoreDevs - Consensus #190

2026-10-29 5 decisions 784 transcript lines

Transcript

Follow along

Dima Gusakov | Lido
gm
Justin Traglia
Gm
Barnabas
I expect quiet some ppl to miss today’s call due to devcon. So maybe we can ship things fast today? 😂
NC
Replying to "I expect quiet some ..." We need devcon every week then
Dima Gusakov | Lido
Reacted to "We need devcon every week then" with 😂
Barnabas
Reacted to "We need devcon every week then" with 😂
stokes
https://github.com/ethereum/pm/issues/2276
stokes
https://github.com/ethereum/consensus-specs/pull/5774
stokes
https://github.com/ethereum/consensus-specs/pull/5776
Barnabas
Replying to "https://github.com/e..." where is 3% coming from?
Barnabas
Replying to "https://github.com/e..." finger in the air number?
Barnabas
Replying to "https://github.com/e..." this change feels pretty late :/
stokes
Replying to "https://github.com/e..." Its more or less an “off chain” change
stokes
Replying to "https://github.com/e..." AIUI just hardens the networking
NC
Replying to "https://github.com/e..." not consensus breaking fwiw
Barnabas
Replying to "https://github.com/e..." well what kind of bids we sending via p2p is not really off chain
Barnabas
Replying to "https://github.com/e..." but yeah not consensus breaking
Nico Flaig
Replying to "https://github.com/e..." we can tweak the numbers but you can roll this out even with gloas on mainnet
kingy
I like nico's but we haven't looked at it in detail yet at lighthouse
Enrico Del Fante
Not yet but 5776 seems the gwei
Nico Flaig
but nodes only forward bids that are compatible with their head view
Justin Traglia
Reacted to "but nodes only forward bids that are compatible with their head view" with 👍
Barnabas
maybe discuss on sunday?
Potuz
FWIW we will be most likely also be dropping bids from long forks
Potuz
Regardless what the spec says, we’ve already seen exploitable bugs because of this
Nico Flaig
Replying to "FWIW we will be most..." that's already in the spec, ie. you only forwards head compatible bids?
stokes
https://github.com/ethereum/consensus-specs/pull/5770
Potuz
Replying to "FWIW we will be most..." Yeah, we had a way of verifying bids not compatible with head, but dropped it in the end
Nico Flaig
lgtm
Potuz
We’re happy with it, I think Prysm was the last holdout on one of the checks
Toni Wahrstätter
it prevents invalid payloads from being broadcasted?
Toni Wahrstätter
how does the CL tell it's invalid?
Enrico Del Fante
We already implemented a PR the block hash check independently, seems like it is more complete
Potuz
It doesn’t Toni, it prevents some kind of invalid payloads, not all
Justin Traglia
Err it prevents execution payload envelopes that would fail on_execution_payload_envelope in fork choice from being gossiped.
Toni Wahrstätter
Replying to "It doesn’t Toni, it prevents some kind of invalid payloads, not all" I see yeah makes sense, thanks!
Toni Wahrstätter
Replying to "it prevents invalid payloads from being broadcasted?" I see, thanks!
Potuz
@Barnabas the Lido thing can be tested in Kurtosis
Potuz
Probably better
Potuz
KT than a devnet
Barnabas
kt first then a devnet
Iván | ethrex
Which implementations do you mean @Barnabas?
Potuz
Replying to "Which implementation..." It’s about deposit onboarding at the fork
Potuz
Replying to "Which implementation..." It’s just our changes
Iván | ethrex
Ah, okok, thanks
Barnabas
heze devnets
Barnabas
we haven’t started hegota devnets yet
NC
When can we make a decision to SFI the two smaller EIPs?
Iván | ethrex
Reacted to "we haven’t started hegota devnets yet" with 🚢
Potuz
I claim it should be a requirement 🙂
Potuz
And I am fine SFIing some of the small ones
Barnabas
https://eips.ethereum.org/EIPS/eip-8015 - SFI now
Potuz
Yeah that one should be SFId IMO
Manu
Reacted to "Yeah that one should be SFId IMO" with 👍
Iván | ethrex
Reacted to "Yeah that one should be SFId IMO" with 👍
Justin Traglia
Reacted to "Yeah that one should be SFId IMO" with 👍
Jun Song
Reacted to "https://eips.ethereum.org/EIPS/eip-8015 - SFI now" with 👍
Jun Song
Reacted to "Yeah that one should be SFId IMO" with 👍
Manu
Reacted to "https://eips.ethereum.org/EIPS/eip-8015 - SFI now" with 👍
Toni Wahrstätter
are those on devnets already?
Nico Flaig
Reacted to "Yeah that one should..." with 👍
Oisin Kyne
Reacted to "Yeah that one should..." with 👍
Enrico Del Fante
Reacted to "Yeah that one should be SFId IMO" with 👍
kingy
sfi 8015
Justin Traglia
Reacted to "sfi 8015" with 🚢
Nico Flaig
Reacted to "sfi 8015" with 🚢
Iván | ethrex
Reacted to "sfi 8015" with 🚢
kingy
Reacted to "Yeah that one shou..." with 👍
Barnabas
EIP-8365
Jun Song
Reacted to "sfi 8015" with 🚢
stokes
https://github.com/ethereum/pm/issues/2276#issuecomment-6497042865
Barnabas
https://github.com/ethereum/EIPs/pull/12513
Kevaundray Wedderburn
Replying to "EIP-8365" https://eips.ethereum.org/EIPS/eip-8365
Iván | ethrex
Reacted to "EIP-8365" with 🚢
Iván | ethrex
Reacted to "https://eips.ethereum.org/EIPS/eip-8365" with 🙏
Justin Traglia
& this one in consensus-specs: https://github.com/ethereum/consensus-specs/pull/5744
Barnabas
https://github.com/ethereum/EIPs/pull/12533
marc | wolovim
Current hegota CL scope: https://forkcast.org/upgrade/hegota/client-priority/?quick=cl
Justin Traglia
I’m slightly in favor of barnabas’ proposal. I agree that burning ETH here isn’t ideal.
Barnabas
Replying to "I’m slightly in favo..." esp for an operation that is currently a valid operation, and tools like ethdo still supports it
Luca Donno | L2BEAT
Reacted to "EIP-8365" with 🚢
Nico Flaig
just create an exited 0x00 validator?
Potuz
Replying to "just create an exite..." There may be an issue with sync committees and some edge case like this
NC
This has been brought up last ACDC and last ACDT and now, so I would love this to be settled next time we discuss
Justin Traglia
Reacted to "This has been brought up last ACDC and last ACDT and now, so I would love this to be settled next time we discuss" with 👍
Potuz
Replying to "just create an exite..." Need to make sure that it can’t be assigned duties
Barnabas
Reacted to "This has been brought up last ACDC and last ACDT and now, so I would love this to be settled next time we discuss" with 👍
Potuz
Replying to "just create an exite..." Regular Vals can be in sync committees even after exited
Potuz
I also lean towards simplicity of the spec here, we have at least 1 year to stress this
Nico Flaig
Replying to "just create an exite..." hmm no I don't think this can happen, the validator will never be active
NC
Reacted to "I also lean towards simplicity of the spec here, we have at least 1 year to stress this" with 👍
Kevaundray Wedderburn
Reacted to "I also lean towards simplicity of the spec here, we have at least 1 year to stress this" with 👍
Barnabas
Reacted to "sfi 8015" with 🚢
Nico Flaig
needs to be brought up to EL devs? from CL pov it's obvious it should work that way
Toni Wahrstätter
From the EL side, reopening the final payload and adding more transactions isn't super trivial as there are post-execution system calls (e.g. withdrawals) and those txs that we want to "append" would need to be appended against the state before processing withdrawals.
Toni Wahrstätter
EL clients will need to checkpoint the state before withdrawals - probably easily doable but it's not just "append them"
Tuyen Nguyen
Reacted to "I also lean towards simplicity of the spec here, we have at least 1 year to stress this" with 👍
Barnabas
name inspired from avg acd dev’s spirit animal? [Full message cannot be displayed on this version]
Dima Gusakov | Lido
Reacted to "name inspired from a..." with 😂
Mega | ethlambda
Reacted to "name inspired from a..." with 😂
Daniel Knopik
Reacted to "name inspired from..." with 😂
NC
Reacted to "name inspired from a..." with 🐟
Toni Wahrstätter
Replying to "name inspired from a..." I* mascot incoming
Iván | ethrex
Reacted to "I* mascot incoming" with 🚢
Mega | ethlambda
Reacted to "I* mascot incoming" with 🚢
Dima Gusakov | Lido
Reacted to "I* mascot incoming" with 🚢
NC
If we accept this EIP for heze, do we need a major update to the mechanism when DC comes?
Enrico Del Fante
Reacted to "name inspired from a..." with 🐟
bee's waggle dance
https://en.wikipedia.org/wiki/Waggle_dance
Justin Traglia
Reacted to "name inspired from a..." with 😂
Oisin Kyne
Reacted to "I* mascot incoming" with 🚢
Pablo Deymo | Lambda
Reacted to "I* mascot incoming" with 🚢
Justin Traglia
Reacted to "I* mascot incoming" with 🚢
Daniel Knopik
Reacted to "I* mascot incoming" with 🚢
Iván | ethrex
Reacted to "name inspired from a..." with 🐟
kingy
LH is in favour
Daniel Knopik
Reacted to "LH is in favour" with 👍
Enrico Del Fante
Worth moving forward
Barnabas
Reacted to "Worth moving forward" with 👍
Iván | ethrex
Reacted to "LH is in favour" with 👍
Iván | ethrex
Reacted to "Worth moving forward" with 👍
jxs
Reacted to "Worth moving forwa..." with 👍
jxs
Reacted to "Worth moving forwa..." with ❤️
Daniel Knopik
Reacted to "Worth moving forwa..." with 👍
Daniel Knopik
Reacted to "Worth moving forwa..." with ❤️
kingy
our main objection was gossipsub
Oisin Kyne
Reacted to "Worth moving forward" with 👍
Kalo | Obol
Reacted to "I* mascot incoming" with 🚢
NC
In general I prefer a simplier/smaller fork (personally)
Yann Vonlanthen
Reacted to "Worth moving forward" with 👍
Barnabas
thats not how scoping for a fork works tho
Barnabas
lol
Nico Flaig
doubtful it's a small change, how many loc is that in prysm?
Barnabas
we doing the scoping now and execute later
—
Ben Adams: Check later is CFI? DFI isn't revisted?
Potuz
I am also doubtful this is small, haven’t seen the code in Prysm
Sukun Tarachandani
Replying to "doubtful it's a smal..." About 700 in a single file. It doesn’t affect other parts of the codebase
Daniel Knopik
i think this would reasonably small in lighthouse fwiw
jxs
Reacted to "i think this would..." with 👍
Justin Traglia
Here’s the cl-specs PR btw: https://github.com/ethereum/consensus-specs/pull/5464
Daniel Knopik
Replying to "i think this would..." like ~500 loc, and as sukun said, networking only
Nico Flaig
Reacted to "like ~500 loc, and a..." with 👍
Nico Flaig
Reacted to "About 700 in a singl..." with 👍
Barnabas
CFI it
Iván | ethrex
Reacted to "CFI it" with 🚢
Kamil Salakhiev
Reacted to "CFI it" with 🚢
Daniel Knopik
Reacted to "CFI it" with 🚢
kingy
Reacted to "CFI it" with 🚢
Potuz
I think attestation bandwidth is probably the most important topic to tackle in the next few years to it’s good to start doing things about this
Sukun Tarachandani
Reacted to "I think attestation bandwidth is probably the most important topic to tackle in the next few years to it’s good to start doing things about this" with 👍
Yann Vonlanthen
Reacted to "I think attestation bandwidth is probably the most important topic to tackle in the next few years to it’s good to start doing things about this" with 👍
Daniel Knopik
Reacted to "I think attestatio..." with 👍
kingy
Reacted to "I think attestatio..." with 👍
Kevaundray Wedderburn
https://github.com/ethereum/execution-specs/issues/3667
Barnabas
its a single value change?
kingy
CFI imo
Nico Flaig
in favor, but we should revisit what exact value to pick
Justin Traglia
Reacted to "I think attestation bandwidth is probably the most important topic to tackle in the next few years to it’s good to start doing things about this" with 👍
Daniel Knopik
Reacted to "CFI imo" with 👍
Enrico Del Fante
Reacted to "CFI imo" with 👍
Povilas Liubauskas
Reacted to "CFI imo" with 👍
Justin Traglia
Reacted to "CFI imo" with 👍
Barnabas
Replying to "in favor, but we sho..." retention window must match eip number 😂
Nico Flaig
Reacted to "CFI imo" with 👍
Toni Wahrstätter
state-diff retention
Nico Flaig
Reacted to "retention window mus..." with 😂
Kevaundray Wedderburn
Replying to "state-diff retention" https://eips.ethereum.org/EIPS/eip-8252
Potuz
We are the last!
Potuz
Not Lido
Tomer Ganor
If that is true you should keep this
Oisin Kyne
is there a public thread/research/git on a PQ deposit contract design ongoing?
Kevaundray Wedderburn
I think its either the two step workflow or what we have today
Dima Gusakov | Lido
Reacted to "I think its either the two step workflow or what we have today" with 👍
Kevaundray Wedderburn
Replying to "I think its either t..." 8413
Dima Gusakov | Lido
So let’s have 8205 then
Enrico Del Fante
So maybe it worth detaching the front-running issue from PQ?
Pavel | MixBytes
This EIP definitely solves a long living problem, many protocols suffer from maintaining workarounds
Tomer Ganor
Reacted to "So let’s have 8205 then" with 👍
Enrico Del Fante
Reacted to "So let’s have 8205 then" with 👍
Tomer Ganor
Why not have this as well?
Kevaundray Wedderburn
Replying to "So maybe it worth de..." Yeah I think so
Pavel | MixBytes
Reacted to "So let’s have 8205 then" with 👍
Dima Gusakov | Lido
Reacted to "Yeah I think so" with 👍
Enrico Del Fante
We confirm the support
Tomer Ganor
If you ask who is against this and if no one is against just approve...
Dima Gusakov | Lido
Reacted to "If you ask who is against this and if no one is against just approve..." with ❤️
Barnabas
I’m against it
Barnabas
but I’m tired fighting it lol
Dima Gusakov | Lido
Replying to "I’m against it" You are not a client dev
Tomer Ganor
Reacted to "but I’m tired fighting it lol" with 😂
Dima Gusakov | Lido
Replying to "I’m against it" lol
Justin Traglia
Reacted to "but I’m tired fighting it lol" with 😂
Kamil Salakhiev
Reacted to "but I’m tired fighting it lol" with 😂
Nico Flaig
Reacted to "but I’m tired fighti..." with 😂
Dima Gusakov | Lido
Replying to "I’m against it" Sorry
Potuz
Replying to "I’m against it" That’s kinda irrelevant though
Justin Traglia
Replying to "I’m against it" His opinion still matters
Potuz
Replying to "I’m against it" Testing is a huge part of the process
Dima Gusakov | Lido
Replying to "I’m against it" I know
Dima Gusakov | Lido
Replying to "I’m against it" I’m kidding here
Potuz
Reacted to "I’m kidding here" with 👍
Justin Traglia
Can client teams speak up?
Ben Edgington
Replying to "I’m against it" Insert "Ameen you're not a coredev" clip
Nico Flaig
we should not solve problems that can be handled off chain in the protocol, that's just my 2ct
kingy
prysm teku support? we can cfi and see if complexity is worth it
Barnabas
Replying to "Can client teams spe..." I can start unmuting people at random otherwise
Luca Donno | L2BEAT
Reacted to "That’s kinda irrelevant though" with 👍
Justin Traglia
Reacted to "I can start unmuting people at random otherwise" with 😂
Dima Gusakov | Lido
Reacted to "prysm teku support? we can cfi and see if complexity is worth it" with 👍
Oisin Kyne
Reacted to "I can start unmuting..." with 😱
Luca Donno | L2BEAT
Reacted to "Insert "Ameen you're not a coredev" clip" with 😂
Enrico Del Fante
Replying to "we should not solve ..." But I believe this is a flaw in the protocol
Greg K
Reacted to "prysm teku support? we can cfi and see if complexity is worth it" with 👍
Dima Gusakov | Lido
Reacted to "But I believe this is a flaw in the protocol" with 💯
Daniel Knopik
Reacted to "we should not solv..." with 👍
Greg K
Reacted to "But I believe this is a flaw in the protocol" with 💯
kingy
yep based on complexity and app layer solutions existing but community support has been strong so we can look at it
Pavel | MixBytes
Reacted to "But I believe this is a flaw in the protocol" with 💯
Tomer Ganor
What we have to lose? I really dont understand
kingy
it's 2am and my kids are asleep man dont make me jump on
Justin Traglia
Reacted to "it's 2am and my kids are asleep man dont make me jump on" with 😂
Ladislaus
Reacted to "it's 2am and my kids are asleep man dont make me jump on" with 😂
Potuz
lol
Barnabas
Reacted to "it's 2am and my kids are asleep man dont make me jump on" with 😂
Kamil Salakhiev
Reacted to "it's 2am and my kids are asleep man dont make me jump on" with 😂
Kevaundray Wedderburn
Reacted to "it's 2am and my kids are asleep man dont make me jump on" with 😂
Pablo Deymo | Lambda
Reacted to "it's 2am and my kids are asleep man dont make me jump on" with 😂
Nico Flaig
Reacted to "it's 2am and my kids..." with 😂
Tuyen
Reacted to "it's 2am and my kids are asleep man dont make me jump on" with 😂
Toni Wahrstätter
Reacted to "it's 2am and my kids are asleep man dont make me jump on" with 😂
Dima Gusakov | Lido
Reacted to "it's 2am and my kids are asleep man dont make me jump on" with 😂
Barnabas
Replying to "it's 2am and my kids..." what’s your kid’s take on this proposal?
Kalo | Obol
Reacted to "it's 2am and my kids..." with 😂
Luca Donno | L2BEAT
Reacted to "it's 2am and my kids are asleep man dont make me jump on" with 😂
Ben Edgington
Reacted to "it's 2am and my kids are asleep man dont make me jump on" with 😂
Kalo | Obol
Reacted to "what’s your kid’s ta..." with 😂
Sukun Tarachandani
Reacted to "what’s your kid’s take on this proposal?" with 😂
kingy
Replying to "it's 2am and my ki..." she thinks solve it at pq
Yann Vonlanthen
Reacted to "it's 2am and my kids are asleep man dont make me jump on" with 😂
Mega | ethlambda
Reacted to "what’s your kid’s take on this proposal?" with 😂
Iván | ethrex
Reacted to "what’s your kid’s take on this proposal?" with 🚢
Iván | ethrex
Reacted to "she thinks solve it at pq" with 🚢
Iván | ethrex
Reacted to "she thinks solve it at pq" with ⚛️
Barnabas
Reacted to "she thinks solve it at pq" with 🚢
Kevaundray Wedderburn
We can solve it with the PQ change if people think its a requirement, I was mainly saying that the current PQ proposals don’t solve it
Iván | ethrex
+1 to Potuz
Pablo Deymo | Lambda
Reacted to "+1 to Potuz" with 👍
Daniel Knopik
Reacted to "+1 to Potuz" with 👍
Barnabas
Replying to "We can solve it with..." maybe Lido can go propose the changes for the PQ deposit flow?
Barnabas
Reacted to "+1 to Potuz" with 👍
Tomer Ganor
feels like pq will not solve this
Potuz
I think this is @Kevaundray Wedderburn just cause you guys are trying to reuse most of the current design
Dima Gusakov | Lido
Replying to "We can solve it with..." They are the same
Potuz
But anyway we can and SHOULD fix this with PQ
Greg K
Reacted to "But anyway we can and SHOULD fix this with PQ" with 👍
kingy
Reacted to "But anyway we can ..." with 👍
Tomer Ganor
Why not having this and then merge to pq
Nico Flaig
Reacted to "But anyway we can an..." with 👍
Potuz
Replying to "Why not having this ..." Because this will constrain the PQ design unnecessarily
Potuz
Replying to "Why not having this ..." You are saying “this is the way to fix this now and in the future"
Potuz
Replying to "Why not having this ..." And I think the solution should come with the PQ design so that it’s not constrained by this method of solving it
Tomer Ganor
Replying to "Why not having this ..." As a proposal?
Potuz
Replying to "Why not having this ..." no: as a mechanism
Tomer Ganor
Replying to "Why not having this ..." If pq solve this in a different way throw this
Tomer Ganor
Replying to "Why not having this ..." But lets have a base
Potuz
Replying to "Why not having this ..." That’s the point: this is not how forks work: we never throw away old code, or at least it’s a lot of work
Barnabas
Reacted to "Insert "Ameen you're not a coredev" clip" with 😂
Potuz
Replying to "Why not having this ..." This is why we don’t want to introduce something early if we are going to be forced to solve it anyway
Tomer Ganor
Replying to "Why not having this ..." This should have been solved 4 years ago
Tomer Ganor
Replying to "Why not having this ..." It is long over due
Barnabas
I agree that it should be solved PQ.
Barnabas
Its not urgent right now tho.
Greg K
Reacted to "I agree that it should be solved PQ." with 👍
Potuz
I’ve already said almost exactly what Greg is saying so no need to repeat 🙂
Iván | ethrex
Reacted to "I’ve already said almost exactly what Greg is saying so no need to repeat 🙂" with 👍
Greg K
Replying to "I’ve already said almost exactly what Greg is saying so no need to repeat 🙂" joined the call 1hr late due to time change :-)
Dima Gusakov | Lido
Reacted to "I’ve already said almost exactly what Greg is saying so no need to repeat 🙂" with ❤️
Greg K
Reacted to "I’ve already said almost exactly what Greg is saying so no need to repeat 🙂" with 👍
Potuz
More broadly: PQ designers should not be bound to the current design at all, if we can fix this, or any other issue, we should be happy to change the deposit flow anyway since the community will have to change at that time anyway
Justin Traglia
Reacted to "More broadly: PQ designers should not be bound to the current design at all, if we can fix this, or any other issue, we should be happy to change the deposit flow anyway since the community will have to change at that time anyway" with 👍
Iván | ethrex
Reacted to "More broadly: PQ designers should not be bound to the current design at all, if we can fix this, or any other issue, we should be happy to change the deposit flow anyway since the community will have to change at that time anyway" with 👍
Barnabas
we don’t need it 😂
Mega | ethlambda
Reacted to "More broadly: PQ designers should not be bound to the current design at all, if we can fix this, or any other issue, we should be happy to change the deposit flow anyway since the community will have to change at that time anyway" with 👍
Nico Flaig
Reacted to "More broadly: PQ des..." with 👍
Justin Traglia
Please be mindful of time, so devs have enough time to discuss it.
Kevaundray Wedderburn
Replying to "More broadly: PQ des..." I agree; one of the current designs look very different from today. It just wasn’t clear to me that this was something we wanted to solve vs just allowing the 1ETH pre deposit flow today
Kamil Salakhiev
Replying to "Please be mindful of..." and ideally get to some other EIPs
Daniel Knopik
is discussion for EIP-8411 delayed to next call? 😅
jxs
Reacted to "and ideally get to..." with 💯
Justin Traglia
Reacted to "and ideally get to some other EIPs" with 💯
Potuz
I’ll trust @Manu on this one that tells me he implemented it safely and easily… Seems that it doesn’t make the loop much worse (would like to see benches on this).
stokes
Replying to "is discussion for EI..." It will be after this
Potuz
Replying to "is discussion for EI..." It always is
Daniel Knopik
Reacted to "It will be after t..." with 🙏
Kamil Salakhiev
Reacted to "It will be after this" with 🙏
Oisin Kyne
Reacted to "More broadly: PQ des..." with 👍
Justin Traglia
Reacted to "It will be after this" with 🙏
Barnabas
I think everyone is familiar with the concepts, can we skip to the discussion pls
Barnabas
we only have 10 mins left
kingy
Reacted to "I think everyone i..." with 👍
Daniel Knopik
Reacted to "I think everyone i..." with 👍
Justin Traglia
Replying to "we only have 10 mins..." Yeah devs should already be familiar with the EIP too…
jxs
Reacted to "I think everyone i..." with 👍
jxs
Reacted to "I think everyone i..." with 💯
Jun Song
Reacted to "I think everyone is familiar with the concepts, can we skip to the discussion pls" with 👍
Justin Traglia
Reacted to "we only have 10 mins left" with ➕
Manu
https://github.com/OffchainLabs/prysm/pull/17338
saulius
Replying to "we doing the scoping..." we doing the scoping now and execute later Right, so you say scoping should be done without thinking about the scope of EIPs? I want at least one hardfork per year. This year we will have none.
Pavel | MixBytes
We have reviewed that EIP from security perspective and totally support it
Dima Gusakov | Lido
Reacted to "We have reviewed that EIP from security perspective and totally support it" with ❤️
Eugene Mamin
Reacted to "We have reviewed that EIP from security perspective and totally support it" with ❤️
Greg K
Reacted to "We have reviewed that EIP from security perspective and totally support it" with ❤️
Justin Traglia
Specs: https://github.com/ethereum/consensus-specs/tree/master/specs/_features/eip8148
Tomer Ganor
Im in favor of this
Potuz
Oh cmon people come up with crazy shit to not discuss 8411
Ben Edgington
Reacted to "Oh cmon people come up with crazy shit to not discuss 8411" with 😂
Enrico Del Fante
Reacted to "Oh cmon people come up with crazy shit to not discuss 8411" with 😂
Sukun Tarachandani
Reacted to "Oh cmon people come up with crazy shit to not discuss 8411" with 😂
Dima Gusakov | Lido
Reacted to "Oh cmon people come up with crazy shit to not discuss 8411" with 😂
Kamil Salakhiev
Reacted to "Oh cmon people come up with crazy shit to not discuss 8411" with 😂
Jun Song
Reacted to "Oh cmon people come up with crazy shit to not discuss 8411" with 😂
Justin Traglia
Reacted to "Oh cmon people come up with crazy shit to not discuss 8411" with 😂
kingy
we said dfi but would not block inclusion if the other clients are strongly in favour
Barnabas
Reacted to "Oh cmon people come up with crazy shit to not discuss 8411" with 😂
Daniel Knopik
Reacted to "Oh cmon people com..." with 😂
Mega | ethlambda
Reacted to "Oh cmon people come up with crazy shit to not discuss 8411" with 😂
Eugene Mamin
Reacted to "Oh cmon people come up with crazy shit to not discuss 8411" with 😂
Daniel Knopik
Reacted to "we said dfi but wo..." with 👍
Barnabas
Reacted to "we said dfi but would not block inclusion if the other clients are strongly in favour" with 👍
Dima Gusakov | Lido
Reacted to "we said dfi but would not block inclusion if the other clients are strongly in favour" with 👍
Pablo Deymo | Lambda
Reacted to "Oh cmon people come up with crazy shit to not discuss 8411" with 😂
Satyajit
Reacted to "Oh cmon people com..." with 😂
Enrico Del Fante
Reacted to "we said dfi but would not block inclusion if the other clients are strongly in favour" with 👍
Povilas Liubauskas
Reacted to "we said dfi but wo..." with 👍
jxs
Reacted to "we said dfi but wo..." with 👍
Barnabas
Replying to "Oh cmon people come ..." lets talk about vops before 8411
Barnabas
Replying to "Oh cmon people come ..." 😂
Luca Donno | L2BEAT
Reacted to "Oh cmon people come up with crazy shit to not discuss 8411" with 😂
Kalo | Obol
Reacted to "Oh cmon people come ..." with 😂
Greg K
Reacted to "we said dfi but would not block inclusion if the other clients are strongly in favour" with 👍
Daniel Knopik
cfi
Potuz
SFI
Barnabas
lol
jxs
Reacted to "SFI" with 💯
Daniel Knopik
Reacted to "SFI" with 💯
Iván | ethrex
Reacted to "SFI" with 🚢
Daniel Knopik
Reacted to "SFI" with 🚢
Enrico Del Fante
Reacted to "SFI" with 😂
Satyajit
Reacted to "SFI" with 🚢
Luca Donno | L2BEAT
Reacted to "SFI" with 😂
Csaba
Reacted to "Oh cmon people come up with crazy shit to not discuss 8411" with 😂
Barnabas
Replying to "SFI" Giphy [ID:brWyCLQQiKd3yiizg4] [Full message cannot be displayed on this version]
Mega | ethlambda
Reacted to "SFI" with 🚢
Yann Vonlanthen
Reacted to "Giphy [ID:brWyCLQQiKd3yiizg4]" with 😂
Csaba
Reacted to "Giphy [ID:brWyCLQQiKd3yiizg4]" with 😂
Csaba
Reacted to "SFI" with 🚢
Csaba
Reacted to "SFI" with 💯
Iván | ethrex
Reacted to "SFI" with 💯
Csaba
SFI it
Satyajit
Reacted to "SFI" with 💯
Yann Vonlanthen
Reacted to "SFI" with 🚢
Daniel Knopik
Reacted to "Replying to "SFI" ..." with 😂
Iván | ethrex
Reacted to "SFI it" with ➕
Potuz
Reacted to "SFI it" with 💯
Barnabas
that was quick
Barnabas
lets go
kingy
it's in kamil chill
Csaba
And we made it before 16:30 ?
marc | wolovim
tl;dr: CFI - EIP-8148: Custom sweep threshold for validators - EIP-8334: Bundled Attestation Propagation - EIP-8383: Reduce CL Block Retention Window - EIP-8411: Fast Execution Payload Broadcast DFI - EIP-8205: Withdrawal credentials preregistration
Iván | ethrex
Reacted to "tl;dr: CFI - EIP-8148: Custom sweep threshold for validators - EIP-8334: Bundled Attestation Propagation - EIP-8383: Reduce CL Block Retention Window - EIP-8411: Fast Execution Payload Broadcast DFI - EIP-8205: Withdrawal credentials preregistration" with 🚢
Enrico Del Fante
Reacted to "tl;dr: CFI - EIP-8148: Custom sweep threshold for validators - EIP-8334: Bundled Attestation Propagation - EIP-8383: Reduce CL Block Retention Window - EIP-8411: Fast Execution Payload Broadcast DFI - EIP-8205: Withdrawal credentials preregistration" with 🚢
Csaba
Reacted to "tl;dr: CFI - EIP-8148: Custom sweep threshold for validators - EIP-8334: Bundled Attestation Propagation - EIP-8383: Reduce CL Block Retention Window - EIP-8411: Fast Execution Payload Broadcast DFI - EIP-8205: Withdrawal credentials preregistration" with 🚢
Iván | ethrex
Reacted to "tl;dr: CFI - EIP-8148: Custom sweep threshold for validators - EIP-8334: Bundled Attestation Propagation - EIP-8383: Reduce CL Block Retention Window - EIP-8411: Fast Execution Payload Broadcast DFI - EIP-8205: Withdrawal credentials preregistration" with 🐐
Jun Song
Reacted to "tl;dr: CFI - EIP-8148: Custom sweep threshold for validators - EIP-8334: Bundled Attestation Propagation - EIP-8383: Reduce CL Block Retention Window - EIP-8411: Fast Execution Payload Broadcast DFI - EIP-8205: Withdrawal credentials preregistration" with 🚢
Barnabas
Thanks Stokes for everything ❤️
Justin Traglia
Reacted to "Thanks Stokes for everything ❤️" with ➕
Trent Van Epps
Thanks stokes 🐐
Potuz
Thanks Alex
Trent Van Epps
Welcome sir ben
Justin Traglia
Thanks stokes!
Yann Vonlanthen
Reacted to "Thanks Stokes for everything ❤️" with ➕
Justin Traglia
Reacted to "Welcome sir ben" with 😄
kingy
thanks stokes gl ben
Daniel Knopik
Reacted to "Thanks Stokes for ..." with ➕
Manu
Thanks Alex, Welcome Ben!!
Csaba
Thanks stokes!
Ben
-)
Kevaundray Wedderburn
Thank you for your service Stokes
Kamil Salakhiev
Thanks Alex!
Oisin Kyne
Thanks Stokes!
Toni Wahrstätter
Thanks stokes, and let's go, ben! <3
saulius
Thanks Alex!
Satyajit
Thanks Alex!
Barnabas
Ben, whats in the next devnet?
Mehdi Aouadi
Thanks stokes! Welcome Ben!
Luca Donno | L2BEAT
Reacted to "Ben, whats in the next devnet?" with 😂
Csaba
Reacted to "Ben, whats in the next devnet?" with 😂
Barnabé Monnot
ben edgington mentioned
Povilas Liubauskas
Reacted to "Ben, whats in the ..." with 😂
Yann Vonlanthen
Reacted to "ben edgington mentioned" with 😂
Manu
Reacted to "ben edgington mentioned" with 😂
Oisin Kyne
Reacted to "ben edgington mentio..." with 🎉
Jun Song
Reacted to "ben edgington mentioned" with 😂
kingy
Reacted to "202610290931345466..." with 😂
Luca Donno | L2BEAT
Reacted to "ben edgington mentioned" with 😂
Potuz
Reacted to "Ben, whats in the next devnet?" with 😂
Enrico Del Fante
Reacted to "20261029093134546616.jpg" with 😂
Luca Donno | L2BEAT
Reacted to "ben edgington mentioned" with 🎉
Barnabé Monnot
Reacted to "20261029093134546616.jpg" with 😂
Ben Edgington
Reacted to "ben edgington mentioned" with 😂
Oisin Kyne
Reacted to "Ben, whats in the ne..." with 😂
marc | wolovim
Reacted to "20261029093134546616.jpg" with 😂
Justin Traglia
Reacted to "ben edgington mentioned" with 😂
Justin Traglia
Reacted to "ben edgington mentioned" with 🎉
Mehdi Aouadi
Reacted to "Ben, whats in the next devnet?" with 😂
Mehdi Aouadi
Reacted to "ben edgington mentioned" with 😂
Potuz
Reacted to "ben edgington mentioned" with 😂
Enrico Del Fante
Reacted to "ben edgington mentioned" with 😂
Enrico Del Fante
Reacted to "ben edgington mentioned" with 🎉
Trent Van Epps
Reacted to "ben edgington mentioned" with 😂
Trent Van Epps
Reacted to "ben edgington mentioned" with 🎉
marc | wolovim
Reacted to "Ben, whats in the next devnet?" with 😂
Barnabas
Reacted to "ben edgington mentioned" with 😂

Call summary

Targets

•Consensus-specs release — October 30, 2026 - 00:19:45
•Glamsterdam devnet with Lido PR — estimated November 16–20, 2026 - 00:19:17

Decisions

•SFI for Hegota: EIP-8015 (beacon state cleanup) - 00:37:48
•EIP-8365 decision deferred two weeks; to be discussed at DevCon and resolved next call - 00:34:21
•CFI for Hegota: EIP-8334 (Bundled Attestation Propagation), EIP-8383 (Reduce CL Block Retention Window), EIP-8148 (Custom sweep threshold), EIP-8411 (Fast Execution Payload Broadcast) - 00:55:06
•DFI: EIP-8205 (deposit front-running fix); problem acknowledged, fix committed to PQ deposit contract redesign - 01:15:09
•Ben Edgington named lead ACDC moderator, Will Kokorin as deputy, effective next call (two weeks) - 01:32:43

Highlights

Hegota Scoping:
- ·Proposed Hegota sequencing: launch with FOCIL + PeerDAS first, add smaller EIPs next, merge quick slots later in parallel - 00:21:10
- ·EIP-8015 (beacon state cleanup) SFI'd unanimously; already merged into Hegota spec and tested on devnet - 00:37:35
- ·CFI: EIP-8334 (Bundled Attestation Propagation) — simulation shows ~50% bandwidth reduction for home nodes under decoupled consensus load; purely networking change - 00:55:06
- ·CFI: EIP-8383 (Reduce CL Block Retention Window) — single config value change aligning blob/history retention windows; Lighthouse and Lodestar in favor - 00:59:31
- ·DFI: EIP-8205 (Withdrawal credentials preregistration / deposit front-running fix) — consensus to solve definitively with PQ deposit contract redesign instead - 01:15:09
- ·CFI: EIP-8148 (Custom sweep threshold for validators) — enables 32–2048 ETH range with configurable threshold; proof of concept in Prysm + DORA; Lido funding audit - 01:16:15
- ·CFI: EIP-8411 (Fast Execution Payload Broadcast) — chunked payload propagation via gossip-sub; simulation shows 3× propagation improvement; Potuz suggested SFI immediately - 01:27:56
Organizational:
- ·Alex Stokes stepping down as ACDC moderator; Ben Edgington takes over as lead moderator, Will Kokorin as deputy, starting in two weeks - 01:32:43
Eip 8365 Hegota:
- ·EIP-8365 (remove 0x00 validator deposits): split between burning ETH (simpler) vs. Barnabas' proposal to re-queue balance as 0x01 deposit to avoid burn; deferred two weeks - 00:24:40
Glamsterdam Rollout:
- ·Consensus-specs release planned tomorrow (Oct 30); Lido PR is consensus-breaking and requires explicit devnet testing; devnet launch estimated Nov 16–20 at earliest - 00:18:38
Focil El Clarification:
- ·FOCIL Engine API ambiguity: some ELs rebuild payload entirely on inclusion list update at 6s, causing missed blocks; CL expects append-only; needs EL input — to be raised at next ACDE - 00:38:24
Glamsterdam Bid Gossip:
- ·Two competing PRs for execution payload bid gossip: PR5774 (Potuz/Justin, proposer accepts any bid) vs PR5776 (Nico, 3% minimum increment with DOS protection) - 00:06:15
- ·Potuz opposes PR5776: prefers leaving gossip filtering to client implementations to avoid over-specifying; Prysm likely won't enforce it - 00:11:07
- ·PR5770: adds missing fork-choice checks to Gloas execution payload gossip validation; LGTM from Prysm/Teku; needs a few more client sign-offs before merge - 00:16:14

Action Items

•CL client teams - Client teams review PR5774 vs PR5776 and weigh in on bid gossip approach within a few days - 00:14:37
•Barnabas / CL teams - Bring FOCIL payload rebuild ambiguity to next ACDE for EL team input - 00:39:56
•PQ research / EF - PQ deposit contract designers must explicitly address deposit front-running; core devs confirm this is a requirement - 01:10:03

Key decisions

SFI for Hegota: EIP-8015 (beacon state cleanup)
SFIUnanimously SFI'd; already merged into Hegota spec and tested on devnet.
EIP-8365 decision deferred two weeks; to be discussed at DevCon and resolved next call
Split between burning ETH vs. re-queueing balance as 0x01 deposit to avoid burn.
CFI for Hegota: EIP-8334 (Bundled Attestation Propagation), EIP-8383 (Reduce CL Block Retention Window), EIP-8148 (Custom sweep threshold), EIP-8411 (Fast Execution Payload Broadcast)
CFIEIPs added to Hegota scope for further evaluation and simulation.
DFI: EIP-8205 (deposit front-running fix); problem acknowledged, fix committed to PQ deposit contract redesign
DFIConsensus to solve definitively with PQ deposit contract redesign instead of this specific EIP.
Ben Edgington named lead ACDC moderator, Will Kokorin as deputy, effective next call (two weeks)
Alex Stokes stepping down as ACDC moderator.

EIPs discussed

EIP-8015 EIP-8148 EIP-8205 EIP-8334 EIP-8365 EIP-8383 EIP-8411

Links

AI Disclaimer: Some content or metadata on EIPsInsight may be AI-inferred or automatically compiled. If you find any discrepancy, please contact us at dev@avarch.org.