ACDC2026-10-01_188

AllCoreDevs - Consensus #188

2026-10-01 10 decisions 711 transcript lines

Transcript

Follow along

Pooja Ranjan
gm
Daniel Knopik
gm
Kalo | Obol
gm
Mega | Lambda
gm
Damian Rusinek
GM
Iván | ethrex
👋
potuz
gm
Satyajit
gm
wolovim
gm. correct, stream live
Dima Gusakov | Lido
Hello Ethereans
Ryan Berckmans
gm, I have dropped in as a community guest to speak briefly in support of including quick slots in hegota.
ethDreamer (Mark)
gm
Francesco Risitano (Tau)
gm
Tomer Ganor
gm
Barnabas
live stream on YT seems to be working indeed.
stokes
https://github.com/ethereum/pm/issues/2227
potuz
Holy crap is it ACDC again? I was convinced it was ACDE lol
Justin Traglia
Reacted to "Holy crap is it ACDC again? I was convinced it was ACDE lol" with 😅
Iván | ethrex
Reacted to "Holy crap is it ACDC..." with 😅
Dima Gusakov | Lido
Reacted to "Holy crap is it ACDC again? I was convinced it was ACDE lol" with 😅
wolovim
Reacted to "Holy crap is it ACDC again? I was convinced it was ACDE lol" with 🚂
Satyajit
Reacted to "Holy crap is it AC..." with 😅
Luca Donno | L2BEAT
Reacted to "Holy crap is it ACDC again? I was convinced it was ACDE lol" with 😅
Luca Donno | L2BEAT
Reacted to "Holy crap is it ACDC again? I was convinced it was ACDE lol" with 🚂
Kalo | Obol
Reacted to "Holy crap is it ACDC..." with 😅
potuz
CL side has been relatively stable
Iván | ethrex
Reacted to "CL side has been rel..." with 🔥
Justin Traglia
Reacted to "CL side has been relatively stable" with 🔥
Barnabas
🚢
Iván | ethrex
Reacted to "🚢" with 🚢
Miguel Tenorio
Reacted to "🚢" with 🚢
Kamil Salakhiev
Reacted to "🚢" with 🚢
Jun Song
Reacted to "🚢" with 🚢
Luca Donno | L2BEAT
Reacted to "🚢" with 🚢
potuz
Reacted to "🚢" with 🚢
Will Corcoran
Reacted to "🚢" with 🚢
Oisin Kyne
Reacted to "🚢" with 🚢
Barnabas
did we firm schedule hoodi already?
stokes
https://github.com/ethereum/pm/blob/master/processes/protocol-upgrade.md
marc | wolovim
Proposed 27th, pending sepolia outcomes
Justin Traglia
Reacted to "Proposed 27th, pending outcome" with 👍
nixo
Replying to "did we firm schedule..." picking on oct 8
Nico Flaig
Reacted to "🚢" with 🚢
Dima Gusakov | Lido
Are you brave enough to have Hoodi 1 week before DevCon?
Barnabas
Replying to "Are you brave enough..." yes
Justin Traglia
Reacted to "yes" with 👍
Enrico Del Fante
Reacted to "yes" with 😂
Dima Gusakov | Lido
Reacted to "yes" with 💪
Enrico Del Fante
Reacted to "yes" with 💪
Iván | ethrex
Reacted to "yes" with 💪
Daniel Knopik
Reacted to yes with "💪"
Daniel Knopik
Reacted to yes with "👍"
Iván | ethrex
Reacted to "yes" with 🚢
Luca Donno | L2BEAT
Reacted to "yes" with 🚢
Daniel Knopik
Reacted to yes with "🚢"
Enrico Del Fante
Reacted to "yes" with 🚢
Dima Gusakov | Lido
Replying to "Are you brave enough..." God bless you
Enrico Del Fante
Reacted to "God bless you" with ❤️
Csaba
Replying to "Are you brave enough..." Depends how long your flights are :-)
stokes
https://github.com/ethereum/pm/blob/master/processes/protocol-upgrade.md#incident-response-plan
Dima Gusakov | Lido
Reacted to "Depends how long your flights are :-)" with 😂
cayman
Reacted to "yes" with 🚢
Iván | ethrex
Reacted to "Depends how long you..." with 🫠
potuz
@Parithosh Jayanthi can we have a small (not large scale like before) non-finalizing devnet to test incident reponse? ( I want to test unfinalized checkpoint syncing for example). We can drop some Vals on devnet-8 if you think this works
Will Corcoran
hello
Justin Traglia
Reacted to "hello" with 👋
potuz
Reacted to "hello" with 👋
Pooja Ranjan
Reacted to "hello" with 👋
Satyajit
Reacted to "hello" with 👋
Barnabé Monnot
Reacted to "yes" with 💪
Fredrik
Reacted to "hello" with 👋
Barnabas
Replying to "@Parithosh Jayanthi ..." you just wanna test checkpoint syncing to a non finalized epoch?
Eugene Mamin
Reacted to "Proposed 27th, pending sepolia outcomes" with 👍
Parithosh Jayanthi
Replying to "@Parithosh Jayanthi ..." Yeah we can just reuse devnet-8 imo, or some reason o not just use local?
Barnabé Monnot
Reacted to "hello" with 👋
Parithosh Jayanthi
Reacted to "hello" with 👋
Eugene Mamin
Reacted to "yes" with 👍
Marius Van Der Wijden (M)
Reacted to hello with "👋"
Mario Vega
Reacted to "hello" with 👋
Eugene Mamin
Reacted to "yes" with 🚢
Eugene Mamin
Reacted to "yes" with 💪
Toni Wahrstätter
Replying to "@Parithosh Jayanthi ..." Thad'd be interesting for snap v2 testing too
soispoke
A réagi à "hello" avec 👋
Eugene Mamin
Reacted to "🚢" with 🚢
Parithosh Jayanthi
Bbusa + me would be devops coordinators
potuz
Replying to "@Parithosh Jayanthi ..." Local is a bit of a problem because of peering, devnet 8 or a smallish devnet would be perfect
Pooja Ranjan
Reacted to "Bbusa + me would be devops coordinators" with 👍
Parithosh Jayanthi
How long would you want non finality for?
Mario Vega
Reacted to "Bbusa + me would be devops coordinators" with 👍
Toni Wahrstätter
Replying to "@Parithosh Jayanthi ..." Devnet 8 is large though. I guess such could be smaller
Ameziane Hamlat
Reacted to "hello" with 👋
Toni Wahrstätter
Reacted to hello with "👋"
cayman
Reacted to "hello" with 👋
Dima Gusakov | Lido
Reacted to "hello" with 👋
nixo
https://github.com/ethereum/pm/blob/master/glamsterdam-mainnet-plan.md
Will Corcoran
Justin Traglia and Mario Vega - Testing Nikos - Security
Mario Vega
Reacted to "Justin Traglia and Mario Vega - Testing Nikos - Security" with 👍🏼
Barnabas
if you don’t pick someone by end of monday, I’ll be the one picking for you guys
potuz
Replying to "@Parithosh Jayanthi ..." Just a few epochs is good enough for me @Parithosh Jayanthi as long as I know before hand so that I prepare the images
Miguel Tenorio
Reacted to "Devnet 8 is large though. I guess such could be smaller" with ➕
Kalo | Obol
Reacted to "hello" with 👋
Justin Traglia
Replying to "Justin Traglia and M..." I’d like for Mario to be Primary & myself to be backup 🙂
Parithosh Jayanthi
Replying to "@Parithosh Jayanthi ..." Yeah, we just have like 3 devnets live + decoupled consensus gets one next week + sepolia shadow fork. So at some point we’re stretched thin and would rather reuse devnets 😄
Mario Vega
Reacted to "I’d like for Mario to be Primary & myself to be backup 🙂" with 👍🏼
potuz
Replying to "if you don’t pick so..." Please pick @nflaig for Prysm
Dima Gusakov | Lido
Reacted to "if you don’t pick someone by end of monday, I’ll be the one picking for you guys" with 😂
Dima Gusakov | Lido
Reacted to "Please pick @nflaig for Prysm" with 😂
Parithosh Jayanthi
Reacted to "Just a few epochs is good enough for me @Parithosh Jayanthi as long as I know before hand so that I prepare the images" with 👍
Nico Flaig
Reacted to "Please pick @nflaig ..." with 😂
marc | wolovim
Reacted to "Please pick @nflaig for Prysm" with 😂
Enrico Del Fante
Reacted to "Please pick @nflaig for Prysm" with 😂
Dustin
Reacted to "Please pick @nflai..." with 😂
NC
Reacted to "Please pick @nflaig ..." with 😂
Barnabas
Reacted to "Please pick @nflaig for Prysm" with 😂
Satyajit
Reacted to "Please pick @nflai..." with 😂
Nico Flaig
Replying to "if you don’t pick so..." hell no
cayman
Reacted to "Please pick @nflaig ..." with 😂
Greg K | Lido
Reacted to "Please pick @nflaig for Prysm" with 😂
Toni Wahrstätter
Those are then fully responsible for a smooth transition btw
Jun Song
Reacted to "Please pick @nflaig for Prysm" with 😂
Parithosh Jayanthi
Reacted to "Please pick @nflaig for Prysm" with 😂
nixo
Reacted to "if you don’t pick someone by end of monday, I’ll be the one picking for you guys" with 😂
nixo
Reacted to "Please pick @nflaig for Prysm" with 😂
Parithosh Jayanthi
Replying to "if you don’t pick so..." Lodekeeper for prysm?
Justin Traglia
Reacted to "Please pick @nflaig for Prysm" with 😂
nixo
Reacted to "Lodekeeper for prysm?" with 🤖
Justin Traglia
Reacted to "Lodekeeper for prysm?" with 🤖
Barnabas
Reacted to "Lodekeeper for prysm?" with 🤖
Mario Vega
Mario here, I can focus on assitance for test related issues, in the past we’ve helped to generate test cases on the fly for issues found to help clients get in sync as fast as possible
Oisin Kyne
Reacted to "Please pick @nflaig ..." with 😂
kingy
Reacted to "Lodekeeper for pry..." with 🤖
potuz
Replying to "@Parithosh Jayanthi ..." Yeah lets just coordinate to stop a bunch of nodes on devnet8
Parithosh Jayanthi
Reacted to "Yeah lets just coordinate to stop a bunch of nodes on devnet8" with 🫡
Enrico Del Fante
Replying to "if you don’t pick so..." Was about to say the same 😂
Iván | ethrex
Reacted to "Please pick @nflaig ..." with 😂
Justin Traglia
Reacted to "Mario here, I can focus on assitance for test related issues, in the past we’ve helped to generate test cases on the fly for issues found to help clients get in sync as fast as possible" with 👍
Will Corcoran
Reacted to "I’d like for Mario to be Primary & myself to be backup 🙂" with 👍🏼
Dima Gusakov | Lido
Reacted to "Lodekeeper for prysm?" with 🤖
Barnabas
wanna maybe share your screen with the forkcast page please?
Ryan Berckmans
Alex, I have an unexpectedly rescheduled Dr appointment that I have to go to now. Can I give a brief community statement
Dima Gusakov | Lido
Reacted to "wanna maybe share your screen with the forkcast page please?" with 💯
Justin Traglia
Reacted to "wanna maybe share your screen with the forkcast page please?" with ➕
Parithosh Jayanthi
Reacted to "wanna maybe share your screen with the forkcast page please?" with 💯
Luca Donno | L2BEAT
Reacted to "wanna maybe share your screen with the forkcast page please?" with 💯
Luca Donno | L2BEAT
Reacted to "wanna maybe share your screen with the forkcast page please?" with ➕
Oisin Kyne
Hey guys, just an FYI that the 2026 update to EIP-7716 has been merged, and that you may want to check it out if you've yet to hear one of my prior updates on how its been touched up. https://eips.ethereum.org/EIPS/eip-7716 I also made a calculator + faq site to get a better understanding of the EIP, it might be worth a look first rather than the tech spec. All feedback welcome, I hope people will be willing to squeeze this EIP into CFI as a ~B-tier in Hegota :) decentralisation is worth encouraging, and most people are at least weakly positive for the change as far as I can tell. Thanks! https://validatordowntime.obol.org/
Barnabas
when do you guys add a voice chip for lodekeeper ?
Enrico Del Fante
We can ask lodekeeper to join
potuz
If Lodeskeeper speaks here I’ll freak
nixo
wen lodekeeper talk on calls?
Trent Van Epps
Replying to "Alex, I have an unex..." Write it in the chat at least
Parithosh Jayanthi
Wen text to voice for lode keeper @Nico Flaig
Justin Traglia
Reacted to "We can ask lodekeeper to join" with 🙂
Greg K | Lido
Reacted to "We can ask lodekeeper to join" with 👍
Greg K | Lido
Reacted to "If Lodeskeeper speaks here I’ll freak" with 🌶️
Justin Traglia
Reacted to "If Lodeskeeper speaks here I’ll freak" with 😅
Dima Gusakov | Lido
Reacted to "If Lodeskeeper speaks here I’ll freak" with 🌶️
Daniel Knopik
Reacted to If Lodeskeeper speak... with "😅"
Parithosh Jayanthi
Reacted to "If Lodeskeeper speaks here I’ll freak" with 🌶️
Daniel Knopik
Reacted to If Lodeskeeper speak... with "🌶️"
Daniel Knopik
Reacted to If Lodeskeeper speak... with "💯"
cayman
Reacted to "If Lodeskeeper speak..." with 😅
kingy
Reacted to "wen lodekeeper tal..." with 🤖
Trent Van Epps
Zoom alex
Ben Edgington
Replying to "Wen text to voice for lode keeper @Nico Flaig" Lodespeaker
Iván | ethrex
Reacted to "wen lodekeeper talk ..." with 🤖
Trent Van Epps
❤️
Nico Flaig
Reacted to "wen lodekeeper talk ..." with 🤖
Nico Flaig
Reacted to "If Lodeskeeper speak..." with 🌶️
potuz
Reacted to "Lodespeaker" with 😃
Will Corcoran
Replying to "Zoom alex" Extreme close-up
Parithosh Jayanthi
Reacted to "Lodespeaker" with 😃
danceratopz
wen dark mode
stokes
https://ethereum-magicians.org/t/eip-8363-tapered-issuance-burn/29263/271
cayman
Reacted to "Lodespeaker" with 😃
Mario Vega
Reacted to "wen dark mode" with ➕
potuz
Replying to "Wen text to voice fo..." Nah please don’t, the first sentence along the lines of “the load bearing EIP for next fork is honestly…” we’ll be burning clients.
Enrico Del Fante
Reacted to "wen dark mode" with 💯
Marc
Reacted to "wen dark mode" with 💯
Trent Van Epps
I dont believe he’s on the call
Dima Gusakov | Lido
He’s in Korea apparently
Dima Gusakov | Lido
And it is night there
Jihoon
Reacted to "Lodespeaker" with 😃
danceratopz
Reacted to "wen lodekeeper talk ..." with 🤖
Greg K | Lido
Reacted to "He’s in Korea apparently" with ✈️
Eugene Mamin
Reacted to "He’s in Korea apparently" with ✈️
Ben Edgington
Reacted to "wen dark mode" with 💯
terence
That becomes an really easy change right
Justin Traglia
CFI it
Kevaundray Wedderburn
Reacted to "That becomes an really easy change right" with 👍
marc | wolovim
This forkcast view available here: https://forkcast.org/upgrade/hegota/client-priority/?quick=cl
Oisin Kyne
Reacted to "CFI it" with 👍🏽
danceratopz
Reacted to "CFI it" with 💙
Justin Traglia
Reacted to "That becomes an really easy change right" with 👍
cayman
Reacted to "CFI it" with 👍
kingy
Reacted to "CFI it" with 👍
Enrico Del Fante
Reacted to "CFI it" with 👍
Toni Wahrstätter
Reacted to CFI it with "👍"
danceratopz
Reacted to "CFI it" with 👍
Marc
Reacted to "CFI it" with 👍
Barnabas
Reacted to "CFI it" with 👍
Mario Vega
Reacted to "CFI it" with 🚢
Jun Song
Reacted to "CFI it" with 👍
Nico Flaig
Reacted to "CFI it" with 👍
Satyajit
Reacted to "CFI it" with 👍
Barnabas
do we also wanna disallow new 0x01 in a future fork btw ?
Tuyen
Reacted to "CFI it" with 👍
potuz
Can do now as well
potuz
🙂
Justin Traglia
Reacted to "do we also wanna disallow new 0x01 in a future fork btw ?" with 👎
Daniel Knopik
Reacted to do we also wanna dis... with "👀"
NC
Replying to "do we also wanna dis..." no? it has its purpose and advantage over 0x02
Barnabas
Replying to "do we also wanna dis..." would help consolidate the validator set
potuz
Does this really make sense?
Greg K | Lido
Replying to "do we also wanna disallow new 0x01 in a future fork btw ?" Need EIP-8148 first ;-)
terence
Did Gradine just DFI everything ?
cayman
re EIP-8411 Lodestar team opinion is DFI
potuz
The clients not weighing is because they didn’t write it before
Kamil Salakhiev
Replying to "re EIP-8411 Lodestar..." why?
Eugene Mamin
Reacted to "Need EIP-8148 first ;-)" with 💪
Will Corcoran
Replying to "Did Gradine just DFI..." yes
Luca | Vero
Replying to "Did Gradine just DFI..." more or less, they want to keep the scope minimal
Dustin
yeah, it was snuck in later
Kevaundray Wedderburn
Replying to "do we also wanna dis..." I guess theres a general question as to whether we desire one withdrawal credential type to be active at any given point in time
Dima Gusakov | Lido
Reacted to "Need EIP-8148 first ;-)" with 💪
cayman
Replying to "re EIP-8411 Lodestar..." it seems premature, want more mainnet data first and also want to keep the fork scope smaller
Dima Gusakov | Lido
Replying to "do we also wanna dis..." Jokes aside. With EIP-8148 it is easily doable
Kamil Salakhiev
Replying to "re EIP-8411 Lodestar..." lets talk in DM
Greg K | Lido
Reacted to "Did Gradine just DFI everything ?" with 🫠
cayman
Reacted to "lets talk in DM" with 👍
Dima Gusakov | Lido
Replying to "do we also wanna dis..." And I think this is the way moving forward. Only one validator type
potuz
Replying to "do we also wanna dis..." If 8148 does get in then we should at the same fork disable 0x01
Daniel Knopik
Reacted to Did Gradine just DFI... with "🫠"
Dima Gusakov | Lido
Reacted to "If 8148 does get in then we should at the same fork disable 0x01" with 💯
potuz
Replying to "do we also wanna dis..." Cause there’s no reason not to use 0x02 with 32ETH threshold
Dima Gusakov | Lido
Reacted to "Cause there’s no reason not to use 0x02 with 32ETH threshold" with 💯
Greg K | Lido
Reacted to "If 8148 does get in then we should at the same fork disable 0x01" with 👍
potuz
Replying to "re EIP-8411 Lodestar..." Do it here 🙂
Luca Donno | L2BEAT
Reacted to "Do it here 🙂" with ➕
Greg K | Lido
Reacted to "Jokes aside. With EIP-8148 it is easily doable" with 👍
kingy
Reacted to "Do it here 🙂" with 👍
Greg K | Lido
Reacted to "And I think this is the way moving forward. Only one validator type" with 👍
Dima Gusakov | Lido
Reacted to "Do it here 🙂" with 👍
cayman
Reacted to "Do it here 🙂" with 👍
Greg K | Lido
Reacted to "And I think this is the way moving forward. Only one validator type" with 💯
Barnabas
Reacted to "If 8148 does get in then we should at the same fork disable 0x01" with 👍
Dima Gusakov | Lido
Reacted to "If 8148 does get in then we should at the same fork disable 0x01" with 👍
Eugene Mamin
Reacted to "If 8148 does get in then we should at the same fork disable 0x01" with 👍
Justin Traglia
Reacted to "Do it here 🙂" with 👍
Eugene Mamin
Reacted to "If 8148 does get in then we should at the same fork disable 0x01" with 💯
Csaba
Replying to "re EIP-8411 Lodestar..." What you mean by more mainnet data exactly
Daniel Knopik
Replying to "re EIP-8411 Lodestar..." Or in the Networking call :)
terence
Replying to "re EIP-8411 Lodestar..." Or do it in discord somewhere we can reference later. This history will be hard to track back later on
Kevaundray Wedderburn
Reacted to "Or do it in discord somewhere we can reference later. This history will be hard to track back later on" with 👍
Satyajit
Reacted to "Or do it in discor..." with 👍
Eugene Mamin
Reacted to "Or do it in discord somewhere we can reference later. This history will be hard to track back later on" with 👍
Satyajit
Reacted to "What you mean by m..." with 👍
Justin Traglia
Reacted to "Or do it in discord somewhere we can reference later. This history will be hard to track back later on" with 👍
soispoke
A réagi à "Or do it in discor..." avec 👍
Csaba
Reacted to "Or do it in discord somewhere we can reference later. This history will be hard to track back later on" with 👍
cayman
Reacted to "Or do it in discord ..." with 👍
Dima Gusakov | Lido
Reacted to "do we also wanna disallow new 0x01 in a future fork btw ?" with 👀
Dima Gusakov | Lido
Reacted to "Did Gradine just DFI everything ?" with 🫠
Dima Gusakov | Lido
Replying to "Did Gradine just DFI..." Radical
Daniel Knopik
Reacted to Or do it in discord ... with "👍"
Dima Gusakov | Lido
Reacted to "Or do it in discord somewhere we can reference later. This history will be hard to track back later on" with 👍
Luca Donno | L2BEAT
Reacted to "Or do it in discord somewhere we can reference later. This history will be hard to track back later on" with 👍
potuz
Replying to "Did Gradine just DFI..." Ossification is good
Csaba
Under what Mgas/s did you validate the 10 seconds?
kingy
Reacted to "Or do it in discor..." with 👍
Dima Gusakov | Lido
Replying to "Did Gradine just DFI..." Only in some sense
Justin Traglia
Regarding quick slots, I’m one of the few that oppose it for Hegota. It will make accomplishing our other goals more difficult. We should wait until Ethereum is PQ-safe before doing this imo.
Luca Donno | L2BEAT
Reacted to "Ossification is good" with 🦴
Justin Traglia
Reacted to "Did Gradine just DFI everything ?" with 🫠
Greg K | Lido
Replying to "Regarding quick slots, I’m one of the few that oppose it for Hegota. It will make accomplishing our other goals more difficult. We should wait until Ethereum is PQ-safe before doing this imo." So wait until 2030?
Dima Gusakov | Lido
Reacted to "Regarding quick slots, I’m one of the few that oppose it for Hegota. It will make accomplishing our other goals more difficult. We should wait until Ethereum is PQ-safe before doing this imo." with 🤔
Dustin
Reacted to "Regarding quick sl..." with 👍
Dima Gusakov | Lido
Reacted to "So wait until 2030?" with 😂
ignacio
Reacted to "Regarding quick slots, I’m one of the few that oppose it for Hegota. It will make accomplishing our other goals more difficult. We should wait until Ethereum is PQ-safe before doing this imo." with 👍
Barnabé Monnot
slides https://docs.google.com/presentation/d/1e8oYeHZ-E4qKplWsL28xt3fpQTNehY_90ENwxh_29N0/edit?usp=sharing
NC
Reacted to "Regarding quick slot..." with 👍
Luca Donno | L2BEAT
Reacted to "Regarding quick slots, I’m one of the few that oppose it for Hegota. It will make accomplishing our other goals more difficult. We should wait until Ethereum is PQ-safe before doing this imo." with 👍
Ladislaus
Reacted to "Regarding quick slots, I’m one of the few that oppose it for Hegota. It will make accomplishing our other goals more difficult. We should wait until Ethereum is PQ-safe before doing this imo." with 👍
Francesco D'Amato
Replying to "Regarding quick slot..." Why would it make PQ-safety much more difficult? The explicit goal of the next fork is to run the available chain with a small committee
Parithosh Jayanthi
Reacted to "Or do it in discord somewhere we can reference later. This history will be hard to track back later on" with 👍
Parithosh Jayanthi
Reacted to "Did Gradine just DFI everything ?" with 🫠
Kamil Salakhiev
Replying to "re EIP-8411 Lodestar..." we will have a call, I’ll invite you all
Justin Traglia
Replying to "Regarding quick slot..." Less time to propagate messages, less time for signature aggregations.
Francesco D'Amato
Replying to "Regarding quick slot..." The committee does not need signature aggregation
Iván | ethrex
Reacted to "Regarding quick slot..." with 👍
Francesco D'Amato
The rest has nothing to do with slot time in decoupled consensus
Luca Donno | L2BEAT
Reacted to "we will have a call, I’ll invite you all" with 🫤
Yann Vonlanthen
Reacted to "The rest has nothing to do with slot time in decoupled consensus" with 👍
ignacio
Replying to "Regarding quick slots, I’m one of the few that oppose it for Hegota. It will make accomplishing our other goals more difficult. We should wait until Ethereum is PQ-safe before doing this imo." Wouldn't be safer to wait for DC actually happening?
Barnabas
Replying to "Regarding quick slot..." if we add shorter slots EIP, we can later then increase by a few hundred milliseconds later if we want to.
Francesco D'Amato
Replying to "Regarding quick slot..." 10s is hardly unsafe
potuz
Replying to "Regarding quick slot..." Yeah, but that’s the reason why I wanted this with DC and not before
Barnabas
Replying to "Regarding quick slot..." we could do independent slot time increase/reduction with just a CL fork.
Francesco D'Amato
Replying to "Regarding quick slot..." I can already see people making the argument that it’s a big change and should keep it minimal...
Barnabas
Replying to "Regarding quick slot..." similar to BPOs we could do slot time adjustment fork only
potuz
Reacted to "I can already see people making the argument that it’s a big change and should keep it minimal..." with 😃
NC
Replying to "Regarding quick slot..." please don’t do slot time schedule
Dustin
Reacted to "please don’t do s..." with 👍
cayman
Reacted to "please don’t do slot..." with 👍
Nico Flaig
Reacted to "please don’t do slot..." with 👍
Łukasz Rozmej
slot time reduction should be BPO fork, so we can do it whenever decoupled from feature fork, so it can come after Hegota
Ben Adams
Reacted to "slot time reduction should be BPO fork, so we can do it whenever decoupled from feature fork, so it can come after Hegota" with 💯
ignacio
Reacted to "slot time reduction should be BPO fork, so we can do it whenever decoupled from feature fork, so it can come after Hegota" with 💯
Marc
Reacted to "slot time reduction should be BPO fork, so we can do it whenever decoupled from feature fork, so it can come after Hegota" with 💯
Iván | ethrex
Reacted to "slot time reduction ..." with 💯
cayman
Is it possible to timebox the quick slots work? My worry is that the long tail of testing can become a drag on shipping the fork that might otherwise be more straightforward.
Barnabas
Reacted to "slot time reduction should be BPO fork, so we can do it whenever decoupled from feature fork, so it can come after Hegota" with 💯
Marius Van Der Wijden (M)
Reacted to Regarding quick slot... with "👍"
Preston Van Loon - Prysm (Offchain)
Reacted to "slot time reductio..." with 💯
Luca Donno | L2BEAT
Reacted to "slot time reduction should be BPO fork, so we can do it whenever decoupled from feature fork, so it can come after Hegota" with 💯
Dustin
Replying to "Is it possible to ..." It also has a 7549 feel for me
Dustin
Replying to "Is it possible to ..." Exactly along those lines
Toni Wahrstätter
There are constants that cannot just be linearly reduced though (e.g. attestation deadline)
Matthew Keil
Reacted to "please don’t do slot..." with 👍
cayman
Reacted to "slot time reduction ..." with 👎
terence
Replying to "Is it possible to ti..." if we time box quick slots.. then we should time box everything that’s ranked below then
Barnabas
Replying to "Regarding quick slot..." we had variable block time pre POS, whats the worry here?
Toni Wahrstätter
Replying to "slot time reduction ..." You can schedule them but my feeling is we'd need a lot more testing than we had for BPOs
Preston Van Loon - Prysm (Offchain)
The main hard part about quick slots is the spec plumbing to configure alternative slot times. Testing can be done in parallel to other work, after the plumbing is setup
Łukasz Rozmej
Replying to "slot time reduction should be BPO fork, so we can do it whenever decoupled from feature fork, so it can come after Hegota" design non-linear reduction?
Dustin
Replying to "Is it possible to ..." well, quick slots has a way of ramifying out that others don't
Daniel Knopik
Reacted to slot time reduction ... with "💯"
Dustin
Replying to "Is it possible to ..." (some might, but some are very contained)
Luca Donno | L2BEAT
Reacted to "design non-linear reduction?" with 👍
Parithosh Jayanthi
Reacted to "please don’t do slot time schedule" with 👍
potuz
But that’s a point: DC does not change slot mechanics, while in Hegota we’re shipping FOCIL which changes timings precisely
Toni Wahrstätter
Replying to "slot time reduction ..." You can do it, it's simple in-protocol but impacts the app layer
Ansgar Dietrichs
I think it is likely that if we don’t have quick slots in H*, we will not have it in I* (decoupled consensus is too big already), or J* (full focus on PQ), so then we are talking K* in 2029 at the earliest
Eugene Mamin
Reacted to "slot time reduction should be BPO fork, so we can do it whenever decoupled from feature fork, so it can come after Hegota" with 💯
Parithosh Jayanthi
Replying to "Regarding quick slot..." A lot of the PoS assumptions expect predictable slot times though
Parithosh Jayanthi
Replying to "Regarding quick slot..." But hey, I’m not a fork choice expert
Eugene Mamin
Reacted to "Ossification is good" with 🦴
Parithosh Jayanthi
Reacted to "I think it is likely that if we don’t have quick slots in H*, we will not have it in I* (decoupled consensus is too big already), or J* (full focus on PQ), so then we are talking K* in 2029 at the earliest" with 👍
terence
Replying to "Regarding quick slot..." Slot time affects smart contracts more
potuz
Replying to "Regarding quick slot..." Most of it has been already taken into account on the spec
Francesco D'Amato
What is the concrete concern on PQ?
Łukasz Rozmej
Replying to "slot time reduction should be BPO fork, so we can do it whenever decoupled from feature fork, so it can come after Hegota" we should be able to figure it out, there are networks running on 5s (gnosis)
potuz
Replying to "Regarding quick slot..." Sorry that was for Pari, not terence
Parithosh Jayanthi
Reacted to "Sorry that was for Pari, not terence" with 🫡
NC
Replying to "I think it is likely..." Living with 2 extra second per slot for ~2 years sounds fine?
Greg K | Lido
Replying to "But that’s a point: DC does not change slot mechanics, while in Hegota we’re shipping FOCIL which changes timings precisely" so would it be better to put it in I*? Coz most people say that DC makes shorter slots incompatible for I*..
Dustin
Reacted to "Living with 2 extr..." with 👍
Barnabé Monnot
Replying to "slot time reduction ..." I lean against BPO-like mechanics for slot time reductions fwiw, more work upfront and a lot of coordination needed with app layer
Francesco D'Amato
Replying to "I think it is likely..." It’s not 2 extra seconds, otherwise it wouldn’t be worth doing
Francesco D'Amato
Replying to "I think it is likely..." It’s 2 extra seconds now
Toni Wahrstätter
Reacted to I lean against BPO-l... with "👍"
Ansgar Dietrichs
we could also decide to CFI with the understanding we kick it out if it causes any delays (and then the work was still useful for inclusion e.g. in I*)
Yann Vonlanthen
Reacted to "But that’s a point: DC does not change slot mechanics, while in Hegota we’re shipping FOCIL which changes timings precisely" with 👍
Luca | Vero
Reacted to "I lean against BPO-like mechanics for slot time reductions fwiw, more work upfront and a lot of coordination needed with app layer" with 👍
Parithosh Jayanthi
Reacted to "we could also decide to CFI with the understanding we kick it out if it becomes a delay (and then the work was still useful for inclusion e.g. in I*)" with 🫡
Barnabas
Personally, I don't think we should kneecap the protocol today out of fear of what PQ might require later. If we skip improvements we can ship now because a future post-quantum design might struggle to keep up, we're not doing everything we can for Ethereum. We should keep PQ in mind and avoid shooting ourselves in the foot, but "might be harder later" shouldn't block real gains today. If PQ needs us to revisit something, we can deal with that when we get there. And we can always increase slot time later if its really needed.
terence
Reacted to "we could also decide to CFI with the understanding we kick it out if it causes any delays (and then the work was still useful for inclusion e.g. in I*)" with 🫡
Luca Donno | L2BEAT
Reacted to "Living with 2 extra second per slot for ~2 years sounds fine?" with 👍
Luca | Vero
Reacted to "please don’t do slot time schedule" with 👍
Dima Gusakov | Lido
Replying to "we could also decide..." Can we also do it for 8148 and 8205 pls? =)
kingy
Reacted to "Personally, I don'..." with 👍
terence
Reacted to "Personally, I don't think we should kneecap the protocol today out of fear of what PQ might require later. If we skip improvements we can ship now because a future post-quantum design might struggle to keep up, we're not doing everything we can for Ethereum. We should keep PQ in mind and avoid shooting ourselves in the foot, but "might be harder later" shouldn't block real gains today. If PQ needs us to revisit something, we can deal with that when we get there. And we can always increase slot time later if its really needed." with 👍
Marc
Reacted to "Personally, I don't think we should kneecap the protocol today out of fear of what PQ might require later. If we skip improvements we can ship now because a future post-quantum design might struggle to keep up, we're not doing everything we can for Ethereum. We should keep PQ in mind and avoid shooting ourselves in the foot, but "might be harder later" shouldn't block real gains today. If PQ needs us to revisit something, we can deal with that when we get there. And we can always increase slot time later if its really needed." with 👍
Justin Traglia
Replying to "I think it is likely..." So we’d push to lower the slot time again before PQ?
FLCL (Nethermind)
Add optional slot at 6th sec for the same proposer? (Allow to prove two blocks in parallel)
Parithosh Jayanthi
If PQ changes seem real, we could always increase the slot time in the future too right?
cayman
Replying to "Is it possible to ti..." well timeboxing, we can always leave the slot time at 12, but we've done some good by frontloading some of that testing?
ignacio
Replying to "If PQ changes seem real, we could always increase the slot time in the future too right?" This would cause UX pain going back and forth.
Francesco D'Amato
Replying to "I think it is likely..." Decoupled consensus makes it so that there is no signature aggregation in the critical path, so we very well might have the ability to do that
Parithosh Jayanthi
Replying to "If PQ changes seem r..." Well in a world where we want to periodically reduce slot times, we expect that UX pain to exist anyway
Francesco D'Amato
Replying to "I think it is likely..." Either way, we have to start somewhere or we’ll just be with 12s until 2030
Preston Van Loon - Prysm (Offchain)
Replying to "If PQ changes seem..." It is easily done, but yeah some pain to downstream tooling
ignacio
Replying to "If PQ changes seem real, we could always increase the slot time in the future too right?" But at least in same directin :)
Parithosh Jayanthi
Replying to "If PQ changes seem r..." Like we do 10s now, 6s later, 4s years after and so on
Barnabas
Replying to "If PQ changes seem r..." whats the UX pain? If we have an array of defined slot period, then its pretty ok?
Barnabas
Replying to "If PQ changes seem r..." ethereum pre pos was also pretty ok UX, and we had really variable block time
Greg K | Lido
Reacted to "Either way, we have to start somewhere or we’ll just be with 12s until 2030" with 👍
Justin Traglia
Replying to "I think it is likely..." Okay, I’m not very familiar with DC. But I know that messages will be larger with PQ signatures. Is that not an issue?
soispoke
Répondre à "If PQ changes seem..." the back and forth definitely doesn't feel good, in the end it means degrading UX from one fork to another
Toni Wahrstätter
Replying to "If PQ changes seem r..." Computing a timestamp from a slot number will never be the same..
Matthew Keil
Replying to "I think it is likely..." Yes it will be
Enrico Del Fante
On our side Paul worked on that and made a POC. His feedback was that it isn’t complicated.
ignacio
Reacted to "the back and forth definitely doesn't feel good, in the end it means degrading UX from one fork to another" with 👍
Francesco D'Amato
Replying to "I think it is likely..." It will be 512 messages per slot
Francesco D'Amato
Replying to "I think it is likely..." Everything else will just not be coupled with slots
Luca Donno | L2BEAT
Reacted to "the back and forth definitely doesn't feel good, in the end it means degrading UX from one fork to another" with 👍
Barnabas
Replying to "If PQ changes seem r..." computing a timestamp from a slot number is not a UX hurdle imo, we could include timestamp in the slot?
terence
Replying to "On our side Paul wor..." I think this is largely client dependent, some may be easy, some may have a harder time
Francesco D'Amato
Replying to "I think it is likely..." If we cannot handle 512 signatures, I don’t think we will switch to PQ anytime soon
Łukasz Rozmej
Reacted to "I lean against BPO-like mechanics for slot time reductions fwiw, more work upfront and a lot of coordination needed with app layer" with 😢
kingy
we have a rough implementation that we did to scope the difficulty. the actual work for us mechanically isn't hard, it will be the testing that takes time. Personally very in favour.
Greg K | Lido
Reacted to "It will be 512 messages per slot" with 👍
Toni Wahrstätter
Replying to "If PQ changes seem r..." What are other ux hurdles?
Łukasz Rozmej
Reacted to "we have a rough implementation that we did to scope the difficulty. the actual work for us mechanically isn't hard, it will be the testing that takes time. Personally very in favour." with 👍
terence
Reacted to "we have a rough implementation that we did to scope the difficulty. the actual work for us mechanically isn't hard, it will be the testing that takes time. Personally very in favour." with 👍
Daniel Knopik
Reacted to we have a rough impl... with "👍"
Łukasz Rozmej
Reacted to "I think it is likely that if we don’t have quick slots in H*, we will not have it in I* (decoupled consensus is too big already), or J* (full focus on PQ), so then we are talking K* in 2029 at the earliest" with 👍
Yann Vonlanthen
Replying to "I think it is likely..." Exactly, DC means we essentially only have another PTC in the critical path for slot time
Barnabas
Replying to "If PQ changes seem r..." expected time to finalization will become a bit more variable
soispoke
are there any immutable contracts that would be affected?
Ben Adams
Replying to "If PQ changes seem real, we could always increase the slot time in the future too right?" Is SLOTNUM opcode in contracts now anyway
Barnabas
Replying to "If PQ changes seem r..." doubt that it matters much to the end user tho
Barnabas
Reacted to "Is SLOTNUM opcode in contracts now anyway" with 👍
potuz
Why are people talking about PQ as an issue for quick slots? This seems to be completely orthogonal. I do see FOCIL as a biggest issue here though and I think is incorrect to think that testing this with decoupled consensus will be harder than with FOCIL
Christine Kim
Reacted to "Why are people talking about PQ as an issue for quick slots? This seems to be completely orthogonal. I do see FOCIL as a biggest issue here though and I think is incorrect to think that testing this with decoupled consensus will be harder than with FOCIL" with 👍
Enrico Del Fante
Reacted to "are there any immutable contracts that would be affected?" with ☠️
Francesco D'Amato
Reacted to "Why are people talking about PQ as an issue for quick slots? This seems to be completely orthogonal. I do see FOCIL as a biggest issue here though and I think is incorrect to think that testing this with decoupled consensus will be harder than with FOCIL" with 👍
Yann Vonlanthen
Reacted to "Why are people talking about PQ as an issue for quick slots? This seems to be completely orthogonal. I do see FOCIL as a biggest issue here though and I think is incorrect to think that testing this with decoupled consensus will be harder than with FOCIL" with 👍
Ansgar Dietrichs
practically, we could just make it a parameter, and then at interop next year we decide whether to actually pull the trigger on setting that parameter to anything other than 12s.
Marc
Reacted to "Why are people talking about PQ as an issue for quick slots? This seems to be completely orthogonal. I do see FOCIL as a biggest issue here though and I think is incorrect to think that testing this with decoupled consensus will be harder than with FOCIL" with 👍
Preston Van Loon - Prysm (Offchain)
Reacted to "Why are people tal..." with 👍
Barnabé Monnot
Replying to "are there any immuta..." will make sure to check properly, I was asking myself the same but need a better filter for “immutable”
ethDreamer (Mark)
SPO - slot param only
Ansgar Dietrichs
Replying to "practically, we coul..." by then we also know the specifics of decoupled consensus, and have 6 months more clarity on PQ
Greg K | Lido
Reacted to "If we cannot handle 512 signatures, I don’t think we will switch to PQ anytime soon" with 👍
terence
Replying to "Why are people talki..." Right and a bit of chicken and egg problem here. We have not done any testing with quick slots with FOCIL, only EPBS, and we need to do it
Preston Van Loon - Prysm (Offchain)
Replying to "Why are people tal..." Hearing a lot of all or nothing fear on PQ work. Claims that quick slots or something else stop or delay work on PQ
soispoke
A réagi à "will make sure to ..." avec 👍
potuz
Replying to "practically, we coul..." This is not easy at all. Issuance is touched, and a bunch of other STF changes. This really looks like a HF instead of a BPO.
Barnabé Monnot
Reacted to "we have a rough implementation that we did to scope the difficulty. the actual work for us mechanically isn't hard, it will be the testing that takes time. Personally very in favour." with 👍
Ben Adams
FFCR - Faster faster confirmation rule
Ansgar Dietrichs
Replying to "practically, we coul..." yes I don’t love the BPO idea, I was thinking we decide at interop whether to have it in H* or not, and if not then I* would be next realistic option
Daniel Knopik
Replying to "SPO - slot param onl..." BBPASP - both blob param and slot param
Justin Traglia
If decoupled consensus solves all of the concerns with PQ, I won’t oppose quick slots.
Fredrik
Replying to "practically, we coul..." If the technical implementation is not that complex for clients then this to me sounds more safe
Barnabé Monnot
Replying to "I think it is likely..." my own prediction market on “can we move slot time to 8s in I* if we did 10s in Hegotá” is at 60% personally
Daniel Knopik
Reacted to SPO - slot param onl... with "💯"
potuz
Replying to "If decoupled consens..." You mean won’t oppose it if it lands at or after DC?
soispoke
A réagi à "You mean won’t op..." avec ➕
Barnabas
@stokes the array I was talking about: https://github.com/ethereum/consensus-specs/blob/master/configs/mainnet.yaml#L246-L248
Barnabé Monnot
Replying to "If decoupled consens..." All architecture concerns for sure are solved. Concerns around shipping cadence are more subjective
stokes
Reacted to "@stokes the array I was talking about: https://github.com/ethereum/consensus-specs/blob/master/configs/mainnet.yaml#L246-L248" with 👍
kingy
Reacted to "BBPASP - both blob..." with 😂
Barnabé Monnot
Replying to "If decoupled consens..." (obviously I land that it’s worth doing)
terence
Which EIPs are those ?
ethDreamer (Mark)
Not sure I agree we shouldn’t do it because of anticipated pressure. There’s presumably pressure to do more blobs too. We still choose based on network capability
Justin Traglia
Replying to "If decoupled consens..." I mean that if we’re semi-confident that we’re going ship DC before PQ, I won’t oppose quick slots in Hegota.
Barnabas
Reacted to "Not sure I agree we shouldn’t do it because of anticipated pressure. There’s presumably pressure to do more blobs too. We still choose based on network capability" with 👍
terence
Reacted to "Not sure I agree we shouldn’t do it because of anticipated pressure. There’s presumably pressure to do more blobs too. We still choose based on network capability" with 👍
Daniel Knopik
Reacted to Not sure I agree we ... with "👍"
Francesco D'Amato
If we don’t do DC, we’ll have a hard time doing PQ with or without shorter slots I think? We’d have to handle 40k signatures per slot
Justin Traglia
And that DC mitigates concerns regarding message propagation & signature aggregations.
Dustin
For blobs? Actual blob usage is quite low right now
Francesco D'Amato
Replying to "If decoupled consens..." @Kevaundray Wedderburn can we even do that?
Dustin
So no, there's not much pressure on that
Greg K | Lido
Reacted to "If we don’t do DC, we’ll have a hard time doing PQ with or without shorter slots I think? We’d have to handle 40k signatures per slot" with 👍
potuz
Replying to "If decoupled consens..." There’s no PQ without DC unless I’m missing something? there’s no aggregation for PQ on the hot path
Dustin
The usual players who complain any time they have to pay more than 0 for their blobs, well, don't have to
Greg K | Lido
Reacted to "There’s no PQ without DC unless I’m missing something? there’s no aggregation for PQ on the hot path" with 👍
Trent Van Epps
Separate discussion, but there’s something to be said for latent demand that doesn’t fit in the current targets There are consumers of DA which do not use Ethereum today because it is not sufficiently scaled
cayman
Reacted to "The usual players wh..." with 🌶️
Łukasz Rozmej
so don't commit to 10s yet
cayman
Reacted to "The usual players wh..." with 😂
potuz
Reacted to "The usual players who complain any time they have to pay more than 0 for their blobs, well, don't have to" with 😂
Justin Traglia
Replying to "If decoupled consens..." Yep I get that. I just don’t know enough about DC apparently.
Greg K | Lido
Reacted to "so don't commit to 10s yet" with 👍
Daniel Knopik
Reacted to The usual players wh... with "🌶️"
terence
Should we try a breakout room for quick slots ?
Dustin
Replying to "So no, there's not..." Sure, just saying it's not easily comparable to the slot thing
Marc
Replying to "For blobs? Actual blob usage is quite low right now" could make the same argument about the gas limit though, we haven’t reduced it unsafely because of market pressure
Daniel Knopik
Reacted to The usual players wh... with "💯"
Greg K | Lido
We can also have EIP-8198 and keep 12s for Hegota, not?
ethDreamer (Mark)
Look we should make slots as short as we can. We should also support as many blobs as possible. But we’re limited by physics. And no amount of begging from outsiders changes that.. BPO/SPO forks just allow us to move quickly when the capacity is there
Francesco D'Amato
Replying to "If decoupled consens..." You’re not alone 😂 But yeah the gist is we want to have a committee only in the critical path, and do the “big validator set voting” for finality in a way that’s “decoupled” from slots
Satyajit
Reacted to "Personally, I don'..." with 👍
Justin Traglia
Reacted to "You’re not alone 😂 But yeah the gist is we want to have a committee only in the critical path, and do the “big validator set voting” for finality in a way that’s “decoupled” from slots" with 👍
lightclient
we’re changing the consensus protocol in a couple years, seems pretty obvious that we can’t decide the slot time before we actually implement that?
Francesco D'Amato
Replying to "If decoupled consens..." And besides faster finality, it’s quite useful to make it easier for PQ
Oisin Kyne
Reacted to "we’re changing the c..." with 👍🏽
potuz
Reacted to "we’re changing the consensus protocol in a couple years, seems pretty obvious that we can’t decide the slot time before we actually implement that?" with 👍
Trent Van Epps
That’s a poor frame, no one has problems paying for blobs. Our users deserve more thoughtfulness about resource scaling
cayman
Reacted to "we’re changing the c..." with 👍
NC
From a user’s perspective I think faster finality trumps shorter slot. But both can happen at the same time
Barnabas
we should timebox shorter slots
Łukasz Rozmej
I don't think zkVM's should keep the protocol and usability hostage, they (and guest programs) need to keep up or it is their problem
Will Corcoran
Replying to "we should timebox sh..." 10s?
Francesco D'Amato
Reacted to "That’s a poor frame. Our users deserve more thoughtfulness about resource scaling" with 👍
Daniel Knopik
Reacted to That’s a poor frame.... with "👍"
Parithosh Jayanthi
Reacted to "10s?" with 😂
Justin Traglia
Reacted to "10s?" with 😂
Łukasz Rozmej
Replying to "I don't think zkVM's should keep the protocol and usability hostage, they (and guest programs) need to keep up or it is their problem" and I am optimizing guest program as we speak, so talking from that perspective
Barnabas
Replying to "From a user’s perspe..." fcr for final finality?
Barnabas
Reacted to "10s?" with 😂
Luca Donno | L2BEAT
Reacted to "10s?" with 😂
terence
https://gist.github.com/terencechain/e1d3e8e7288e8c7ea5c2487c21d7d6f2
potuz
Reacted to "10s?" with 😂
Barnabas
Replying to "we should timebox sh..." every raised hand gets as many seconds as they propose for the shorter slots at most 12s
Csaba
Reacted to "10s?" with 😂
potuz
Reacted to "every raised hand gets as many seconds as they propose for the shorter slots at most 12s" with 😃
spencer
Reacted to "10s?" with 😂
kingy
what?
Kevaundray Wedderburn
Replying to "If decoupled consens..." @Francesco D'Amato For 40K signatures per slot, I think it would require us to have more powerful aggregators and potentially a directed network given the current bandwidth requirements
potuz
?
spencer
Reacted to "what?" with 😂
NC
Reacted to "what?" with 😂
potuz
Reacted to "what?" with 😂
Dima Gusakov | Lido
Reacted to "?" with 😂
Luca Donno | L2BEAT
Reacted to "what?" with 😂
soispoke
A réagi à "what?" avec 😂
Barnabas
how is this relevant ser?
Marius Van Der Wijden (M)
Reacted to ? with "😂"
Dustin
There's a reason that historically people haven't asked for fewer attestations or sync committtee duties or blocks. Those things the protocol pays adequately for. Blobs the protocol from the beginning assumed altruism + power of defaults to enforce
ethDreamer (Mark)
Man’s trying to buy a gaming rig
Nico Flaig
Reacted to "?" with 😂
Gary Schulte
Reacted to "?" with 😂
Dima Gusakov | Lido
Reacted to "Man’s trying to buy a gaming rig" with 😂
Barnabas
Reacted to "?" with 😂
Matthew Keil
Reacted to "what?" with 😂
Kalo | Obol
Not a financial advise
Marc
Reacted to "Man’s trying to buy a gaming rig" with 😂
Jun Song
Reacted to "?" with 😂
Francesco D'Amato
Replying to "If decoupled consens..." Ok for the purpose of this call I think it’s safe to say it’s not happening without DC
Mario Vega
Reacted to "Man’s trying to buy a gaming rig" with 😂
Barnabas
Reacted to "Man’s trying to buy a gaming rig" with 😂
Francesco Risitano (Tau)
Reacted to "Man’s trying to buy a gaming rig" with 😂
Oisin Kyne
Reacted to "If we don’t do DC, w..." with 👍
Gary Schulte
Reacted to "Man’s trying to buy a gaming rig" with 😂
Kalo | Obol
Reacted to "Man’s trying to buy ..." with 😂
Barnabas
Replying to "Man’s trying to buy ..." don’t we all?
kingy
Reacted to "Man’s trying to b..." with 😂
Oisin Kyne
Reacted to "And that DC mitigate..." with 👍🏽
Walter Himmelsbach
Hat auf "Man’s trying to b..." mit 😄 reagiert
Dima Gusakov | Lido
Reacted to "what?" with 😂
Parithosh Jayanthi
Reacted to "Man’s trying to buy a gaming rig" with 😂
ethDreamer (Mark)
Reacted to "don’t we all?" with 💯
Barnabé Monnot
we have S or A tiers from 3 teams. how are teams not pushing it?
potuz
Reacted to "Ok for the purpose of this call I think it’s safe to say it’s not happening without DC" with 👍
Barnabas
we doing the scoping now tho
kingy
Reacted to "?" with 😂
Ansgar Dietrichs
I am confused btw, I see 3 of 5 teams on S/A ranking for quick slots, but on the call now most core dev feedback is critical - does that mean these client team rankings were mistaken?
Dustin
Replying to "The usual players ..." There was an EIP specifically allowing for at least for self-builds for getting fewer blobs. This is not a coincidence
Oisin Kyne
Reacted to "Ok for the purpose o..." with 👍
terence
Ya to Saulius point, we should do that for all the EIPs below quick slots then
Christine Kim
seems the efforts to ship quick slots is way clearer right now than efforts needed to ship dc/pq
Parithosh Jayanthi
CFI isn’t agreeing to it now though
Parithosh Jayanthi
CFI means we can still decline to ship it later
Justin Traglia
Reacted to "CFI means we can still decline to ship it later" with 👍
Barnabas
Reacted to "CFI means we can still decline to ship it later" with 👍
Will Corcoran
Reacted to "CFI means we can still decline to ship it later" with 👍
felipe
Reacted to "CFI means we can s..." with 👍
Ben Adams
Reacted to "CFI means we can still decline to ship it later" with 👍
Oisin Kyne
Reacted to "CFI means we can sti..." with 👍
Dustin
Replying to "The usual players ..." So yes, it's not 100% literally true, but the protocol seems to have been paying less than it cost nodes to actually run blobs
Greg K | Lido
Reacted to "Ok for the purpose of this call I think it’s safe to say it’s not happening without DC" with 👍
Dustin
Replying to "The usual players ..." So yeah, if you want something more thoughtful than a short quip.
Dima Gusakov | Lido
My home node newer goes below 200ms
cayman
Avg case timing is not relevant? We need worst-case numbers?
Dima Gusakov | Lido
So it depends
potuz
Execution is kinda irrelevant for this, or mostly is. The bottlenecks are 1) Proving (which provers say 10s is fine) and 2) CL broadcasting. Which I do think it’s a big problem
Oisin Kyne
Reacted to "So yes, it's not 100..." with 👍🏽
Greg K | Lido
Reacted to "I don't think zkVM's should keep the protocol and usability hostage, they (and guest programs) need to keep up or it is their problem" with 👍
Oisin Kyne
Reacted to "My home node newer g..." with 🥲
Łukasz Rozmej
https://lab.ethpandaops.io/ethereum/execution/timings?range=6hours EL cpu time
Francesco D'Amato
Reacted to "CFI means we can still decline to ship it later" with 👍
Oisin Kyne
Reacted to "Execution is kinda i..." with 👀
Łukasz Rozmej
P95 is from 54ms for NEthermind to 204ms for Erigon
Barnabé Monnot
I am hearing everyone agreeing to the value of it, and if disagreeing to put in Hegotá, asking for more testing work. Can we CFI this today so we can schedule this work?
Daniel Knopik
Reacted to Execution is kinda i... with "👀"
Ben Adams
Reacted to "I am hearing everyone agreeing to the value of it, and if disagreeing to put in Hegotá, asking for more testing work. Can we CFI this today so we can schedule this work?" with 👍
Marc
Reacted to "I am hearing everyone agreeing to the value of it, and if disagreeing to put in Hegotá, asking for more testing work. Can we CFI this today so we can schedule this work?" with 👍
Mario Vega
Reacted to "Execution is kinda irrelevant for this, or mostly is. The bottlenecks are 1) Proving (which provers say 10s is fine) and 2) CL broadcasting. Which I do think it’s a big problem" with 👀
Nico Flaig
lodestar has a branch with shorter slots, it's quite trival from code perspective for us
terence
Reacted to "I am hearing everyone agreeing to the value of it, and if disagreeing to put in Hegotá, asking for more testing work. Can we CFI this today so we can schedule this work?" with 👍
Łukasz Rozmej
Reacted to "I am hearing everyone agreeing to the value of it, and if disagreeing to put in Hegotá, asking for more testing work. Can we CFI this today so we can schedule this work?" with 👍
Barnabas
Replying to "I am hearing everyon..." Pandas are pro CFI it today!
Barnabé Monnot
Reacted to "Pandas are pro CFI it today!" with ❤️
Christine Kim
Reacted to "I am hearing everyone agreeing to the value of it, and if disagreeing to put in Hegotá, asking for more testing work. Can we CFI this today so we can schedule this work?" with 👍
Ben Adams
Reacted to "Pandas are pro CFI it today!" with ❤️
terence
Reacted to "Pandas are pro CFI it today!" with 👍
terence
Reacted to "lodestar has a branch with shorter slots, it's quite trival from code perspective for us" with 👍
Jun Song
Reacted to "I am hearing everyone agreeing to the value of it, and if disagreeing to put in Hegotá, asking for more testing work. Can we CFI this today so we can schedule this work?" with 👍
Łukasz Rozmej
Replying to "I am hearing everyone agreeing to the value of it, and if disagreeing to put in Hegotá, asking for more testing work. Can we CFI this today so we can schedule this work?" Nethermind pro (not sure if our voice counts on CL though)
Barnabé Monnot
Reacted to "lodestar has a branch with shorter slots, it's quite trival from code perspective for us" with 🙏
Trent Van Epps
Reacted to "I am hearing everyone agreeing to the value of it, and if disagreeing to put in Hegotá, asking for more testing work. Can we CFI this today so we can schedule this work?" with 👍
Justin Traglia
Reacted to "lodestar has a branch with shorter slots, it's quite trival from code perspective for us" with 👍
Trent Van Epps
Reacted to "Pandas are pro CFI it today!" with ❤️
Trent Van Epps
Reacted to "Pandas are pro CFI it today!" with 👍
Łukasz Rozmej
Reacted to "lodestar has a branch with shorter slots, it's quite trival from code perspective for us" with 👍
Trent Van Epps
Reacted to "Nethermind pro (not sure if our voice counts on CL though)" with ❤️
Barnabas
Replying to "I am hearing everyon..." @Łukasz Rozmej just quickly make a cl client then it will count 😂
Barnabé Monnot
Reacted to "Nethermind pro (not sure if our voice counts on CL though)" with ❤️
Justin Traglia
Reacted to "I am hearing everyone agreeing to the value of it, and if disagreeing to put in Hegotá, asking for more testing work. Can we CFI this today so we can schedule this work?" with 👍
Barnabas
Reacted to "lodestar has a branch with shorter slots, it's quite trival from code perspective for us" with 👍
Josh Rudolf
Reacted to "I am hearing everyone agreeing to the value of it, and if disagreeing to put in Hegotá, asking for more testing work. Can we CFI this today so we can schedule this work?" with 👍
Trent Van Epps
Reacted to "lodestar has a branch with shorter slots, it's quite trival from code perspective for us" with 👍
Trent Van Epps
Reacted to "lodestar has a branch with shorter slots, it's quite trival from code perspective for us" with 🙏
Caspar Schwarz-Schilling
Reacted to "Pandas are pro CFI it today!" with ❤️
Caspar Schwarz-Schilling
Reacted to "Nethermind pro (not sure if our voice counts on CL though)" with ❤️
Nico Flaig
Reacted to "I am hearing everyon..." with 👍
Barnabas
Reacted to "Nethermind pro (not sure if our voice counts on CL though)" with ❤️
Parithosh Jayanthi
Reacted to "Nethermind pro (not sure if our voice counts on CL though)" with ❤️
Iván | ethrex
Mostly agree with Łukasz point of view from our side
Parithosh Jayanthi
Reacted to "Pandas are pro CFI it today!" with ❤️
Łukasz Rozmej
Replying to "I am hearing everyone agreeing to the value of it, and if disagreeing to put in Hegotá, asking for more testing work. Can we CFI this today so we can schedule this work?" @Barnabas is this quick enough for you: https://github.com/NethermindEth/nethermind/pull/13611 ?
Parithosh Jayanthi
Reacted to "Pandas are pro CFI it today!" with 👍
Francesco D'Amato
recapping: 3/5 clients have it S/A The PQ concern doesn’t seem to have legs, we need DC anyway for PQ and that removes the problem Everyone that has looked at implementation seems to say it’s not complex, so it shouldn’t delay much future work On what grounds would we not CFI it? We are not talking about SFI today
Barnabas
Reacted to "@Barnabas is this quick enough for you: https://github.com/NethermindEth/nethermind/pull/13611 ?" with 🎉
spencer
Replying to "https://lab.ethpan..." this is awesome
kingy
Reacted to "I am hearing every..." with 👍
soispoke
Répondre à "recapping: 3/5 cli..." SFI?
Barnabas
Reacted to "I am hearing everyone agreeing to the value of it, and if disagreeing to put in Hegotá, asking for more testing work. Can we CFI this today so we can schedule this work?" with 👍
Justin Traglia
Replying to "I am hearing everyon..." While I’m still a little concerned, I support CFI’ing it. Like Pari said, this isn’t a decision to include it in the upgrade.
Francesco D'Amato
Replying to "recapping: 3/5 clien..." *not talking
soispoke
A réagi à "*not talking" avec 👍
Ben Adams
Can share screen again 🙂
Ansgar Dietrichs
Reacted to "*not talking" with 👍
Caspar Schwarz-Schilling
Reacted to "recapping: 3/5 clients have it S/A The PQ concern doesn’t seem to have legs, we need DC anyway for PQ and that removes the problem Everyone that has looked at implementation seems to say it’s not complex, so it shouldn’t delay much future work On what grounds would we not CFI it? We are not talking about SFI today" with 👍
Iván | ethrex
Reacted to "Can share screen aga..." with 🙏
Łukasz Rozmej
Replying to "I am hearing everyone agreeing to the value of it, and if disagreeing to put in Hegotá, asking for more testing work. Can we CFI this today so we can schedule this work?" CFI is not SFI yet
Walter Himmelsbach
Hat auf "Can share screen a..." mit 🚬 reagiert
Justin Traglia
Reacted to "CFI is not SFI yet" with 👍
Barnabé Monnot
Reacted to "While I’m still a little concerned, I support CFI’ing it. Like Pari said, this isn’t a decision to include it in the upgrade." with 🙏
Barnabé Monnot
Reacted to "CFI is not SFI yet" with 👍
Parithosh Jayanthi
Reacted to "While I’m still a little concerned, I support CFI’ing it. Like Pari said, this isn’t a decision to include it in the upgrade." with 🙏
lightclient
seems pretty contentious
Gary Schulte
Reacted to "seems pretty contentious" with 👍
Barnabas
Reacted to "CFI is not SFI yet" with 👍
potuz
It seems that 3 clients were in favor but most people that spoke today are not
Parithosh Jayanthi
Reacted to "CFI is not SFI yet" with 👍
Enrico Del Fante
Reacted to "CFI is not SFI yet" with 👍
Gary Schulte
Replying to "seems pretty content..." some controversy on a ACDC call for a change
cayman
Reacted to "some controversy on ..." with 😂
lightclient
Reacted to "some controversy on a ACDC call for a change" with 😂
Łukasz Rozmej
Replying to "seems pretty contentious" finally
Ameziane Hamlat
Reacted to "some controversy on a ACDC call for a change" with 😂
Łukasz Rozmej
Replying to "seems pretty contentious" I was getting bored
Parithosh Jayanthi
Replying to "I am hearing everyon..." Gas benchmark style leaderboard for CLs anyone?
Oisin Kyne
Replying to "P95 is from 54ms for..." Block processing time as per our data mean, p10, 950, p90, p99 slot 0. 420ms, 190ms, 780ms, 1380ms slot 1-31. 220ms, 110ms, 190ms, 390ms, 770ms data set of 47 nodes from different operators over a month.
Greg K | Lido
Reacted to "It seems that 3 clients were in favor but most people that spoke today are not" with 🤯
soispoke
A réagi à "some controversy o..." avec 😂
Mario Vega
Reacted to "some controversy on a ACDC call for a change" with 😂
Luca Donno | L2BEAT
Reacted to "CFI is not SFI yet" with 👍
spencer
Reacted to "some controversy o..." with 😂
felipe
Reacted to "some controversy o..." with 😂
Trent Van Epps
Replying to "seems pretty content..." Contentiousness in isolation should never be a disqualifying factor in scoping decisions
Ansgar Dietrichs
Reacted to "some controversy on a ACDC call for a change" with 😂
Marc
Reacted to "some controversy on a ACDC call for a change" with 😂
Łukasz Rozmej
Replying to "P95 is from 54ms for NEthermind to 204ms for Erigon" You gotta pump those numbers up. Those are rookie numbers.
Parithosh Jayanthi
Reacted to "some controversy on a ACDC call for a change" with 😂
cayman
Replying to "P95 is from 54ms for..." is this for 200m gas?
Oisin Kyne
this is mainnet real data (so 60m?)
Łukasz Rozmej
Reacted to "Contentiousness in isolation should never be a disqualifying factor in scoping decisions" with 👍
Łukasz Rozmej
Reacted to "Gas benchmark style leaderboard for CLs anyone?" with 💯
Parithosh Jayanthi
Replying to "P95 is from 54ms for..." 200M gas would only happen post repricing, so you can’t extrapolate todays numbers at 60M to 200M
Barnabé Monnot
appreciate the CFI all, let’s do this 🙂
Łukasz Rozmej
Replying to "I am hearing everyone agreeing to the value of it, and if disagreeing to put in Hegotá, asking for more testing work. Can we CFI this today so we can schedule this work?" you need to measure to optimize
Caleb
Reacted to "appreciate the CFI..." with 🔥
Justin Traglia
Reacted to "appreciate the CFI all, let’s do this 🙂" with ❤️
Matthew Keil
Reacted to "I am hearing everyon..." with 👍
cayman
Reacted to "200M gas would only ..." with 👍
Barnabas
Reacted to "appreciate the CFI all, let’s do this 🙂" with ❤️
Barnabas
Reacted to "appreciate the CFI all, let’s do this 🙂" with 🚢
Marc
Reacted to "appreciate the CFI all, let’s do this 🙂" with 🚢
felipe
Reacted to "appreciate the CFI..." with ❤️
cayman
Reacted to "you need to measure ..." with 👍
Luca Donno | L2BEAT
Reacted to "some controversy on a ACDC call for a change" with 😂
Trent Van Epps
Reacted to "appreciate the CFI all, let’s do this 🙂" with 🔥
Trent Van Epps
Reacted to "appreciate the CFI all, let’s do this 🙂" with ❤️
Trent Van Epps
Reacted to "appreciate the CFI all, let’s do this 🙂" with 🚢
Łukasz Rozmej
Replying to "P95 is from 54ms for NEthermind to 204ms for Erigon" 200M will work on completely different path with BAL's, they are not comparable by todays standards and need new measurements
Will Corcoran
Reacted to "While I’m still a little concerned, I support CFI’ing it. Like Pari said, this isn’t a decision to include it in the upgrade." with 🙏
spencer
Reacted to "appreciate the CFI..." with ❤️
Oisin Kyne
Reacted to "200M will work on co..." with 👍🏽
Łukasz Rozmej
Replying to "P95 is from 54ms for NEthermind to 204ms for Erigon" My expectation is the latency on 200M will be comparable to 60M now, with higher CPU usage in that 50-200ms slot
cayman
Reacted to "My expectation is th..." with 👍
Łukasz Rozmej
Top up sync is cross cutting EIP, so EL's voice should also be considered
Nico Flaig
Replying to "https://lab.ethpanda..." talking about cpu time and wasted resources, wen are els ready with the ssz engine api? would be good before glamsterdam to have this
Barnabas
imo its useful engine API fix, but not a protocol improvement. Ship MISSING_STATE/getSyncStatus via execution-apis, and don't spend fork scope or deprecate devp2p eth sync on it yet.
Francesco Risitano (Tau)
Top-sync uses serial sync over the sync range. EL’s are much more efficient at sync.
cayman
Reacted to "talking about cpu ti..." with ❤️
Dustin
Replying to "Top-sync uses seri..." Yeah it's not intended to replace snap sync to a somewhat recent pivot in good conditions
Francesco Risitano (Tau)
Replying to "Top-sync uses serial..." What’s the worst case range?
ethDreamer (Mark)
Curious when you say 8379 reduces attack surface, are you talking about these block hash / version hash checks involved in optimistic sync? Or totally different attacks? https://github.com/ethereum/consensus-specs/blob/master/specs/electra/beacon-chain.md#modified-verify_and_notify_new_payload
cayman
We were in favor of this since it seemed like a minor engine API tweak / improvement? not mandating any behavioral change in clients?
kingy
Reacted to "I was getting bored" with 😂
—
Łukasz Rozmej: Those were my thoughts, maybe they are wrong? It moves execution block distribution into the engine API, couples the execution client's sync progress to the consensus client's implementation, and adds engine-API surface — a new method plus revised payload-status semantics — that every EL/CL pair has to agree on precisely. The duplication it removes is not a cost we feel, and the coupling could also hurt performance.
Dustin
Replying to "Curious when you s..." that's tied with if ELs stop doing duplicate gossip
Łukasz Rozmej
yes yes that's my point found the notes !
potuz
That was DFId already
potuz
Of course incorrectly
ethDreamer (Mark)
Replying to "Curious when you say..." Oh so different set of attacks? Because these checks are there for a weird attack where the CL doesn’t wait for the EL to verify every single block while syncing.. then you need to do these minimal checks or else you could construct a block that doesn’t validate and lies to each layer on the pieces that are checked
Barnabas
Reacted to "Of course incorrectly" with 😂
Toni Wahrstätter
+1 to francesco, top up sync feels less efficient than snap sync
Caleb
Reacted to "Of course incorrec..." with 😂
Barnabas
Replying to "+1 to francesco, top..." i don’t think its planning swap snapsync
potuz
Replying to "+1 to francesco, top..." This doesn’t replace snap sync
potuz
Replying to "+1 to francesco, top..." But it does couple CL + EL direct syncing after the snapshot
Toni Wahrstätter
Replying to "+1 to francesco, top..." There's a world where ELs don't need those payloads from the CL after being offline. EL only needs a trusted checkpoint from the CL
potuz
Replying to "+1 to francesco, top..." Yeah but people already DFId that
Barnabas
can’t this be done optionally?
Barnabas
like let any client implement this optionally?
Barnabas
which they could have done already?
cayman
Replying to "We were in favor of ..." like, the EIP exposes more information. that provides some flexibility / observability that can be ignored or used. If the EIP was named engine API syncing observability, maybe we wouldn't have the contention.
Marius Van Der Wijden (M)
Reacted to can’t this be done o... with "👍"
Barnabas
kinda having a hard time understanding why this is an EIP
Csaba
Replying to "can’t this be done o..." It is already proposed as optional as far as I see
potuz
Reacted to "It is already proposed as optional as far as I see" with 👍
Csaba
Replying to "can’t this be done o..." I mean the usage, not the implementation of the endpoint
Toni Wahrstätter
One can build an EL that doesn't need to request headers and bodies over devp2p. I'm not sure we need that
Łukasz Rozmej
Reacted to "One can build an EL that doesn't need to request headers and bodies over devp2p. I'm not sure we need that" with 👍
Dustin
Replying to "One can build an E..." well that's the resilience point I opened with
Dustin
Replying to "One can build an E..." what happened with holesky/pectra
potuz
+1 for Enrico, and the other approach is strictly better if we keep CL + EL separation
potuz
If we don’t then this seems better
Caleb
Reacted to "well that's the re..." with 👍
Dustin
Replying to "One can build an E..." highly forked network, which couldn't really sync because it needed CL and EL to simultaneously sync
Toni Wahrstätter
Replying to "One can build an EL ..." If it's a small change, which it seems to be, I'm fine but I wouldn't say it will change how we sync as it be a step back for ELs to not use devp2p for catching up /full sync
Łukasz Rozmej
Replying to "One can build an EL that doesn't need to request headers and bodies over devp2p. I'm not sure we need that" @Dustin if it is optional than sure I am kind of indifferent, IMO it is far from optimal, though won't be that useful? And probably not worth priritising.
Csaba
I think the power and resilience of implementation diversity is a bit undervalued in the end-game argument.
potuz
This was pretty contentious already in Svalbard, it won’t be solved in an ACDE meeting.
cayman
Reacted to "I think the power an..." with 👍
Marius Van Der Wijden (M)
Don't think we should spend more time on an optional proposal
Enrico Del Fante
Reacted to "Don't think we should spend more time on an optional proposal" with 👍
Enrico Del Fante
Reacted to "This was pretty contentious already in Svalbard, it won’t be solved in an ACDE meeting." with 👍
Barnabas
Reacted to "Don't think we should spend more time on an optional proposal" with 👍
ethDreamer (Mark)
Okay so.. far behind: EL gets STATE near the tip somehow (snap sync / BAL fast-forward) near the tip: CL has payloads CL feeds them to EL via Engine API steady state: normal newPayload flow
Toni Wahrstätter
With potuz eip we'd have dedup as of day one. With this we need some special ELs that don't exist(?) We'd need top up sync AND ssz to have CLs not needing to download payloads
Dustin
Replying to "Okay so.. far beh..." yeah
Łukasz Rozmej
Reacted to "Don't think we should spend more time on an optional proposal" with 👍
Francesco D'Amato
Can we go back to not having another Francesco in the call? 🤝
potuz
lol
Will Corcoran
Reacted to "Can we go back to not having another Francesco in the call? 🤝" with 🤣
Mario Vega
Reacted to "Can we go back to not having another Francesco in the call? 🤝" with 🤣
Barnabas
Reacted to "Can we go back to not having another Francesco in the call? 🤝" with 🤣
ethDreamer (Mark)
Replying to "Okay so.. far behin..." I’m not against this in principle, just need to figure out how much work this would be
Enrico Del Fante
Reacted to "Can we go back to not having another Francesco in the call? 🤝" with 🤣
ignacio
Replying to "Can we go back to not having another Francesco in the call? 🤝" Francescos are the smart guys :D
Łukasz Rozmej
Reacted to "Can we go back to not having another Francesco in the call? 🤝" with 🤣
Barnabas
Replying to "Can we go back to no..." thats why I choose to be Barnabas and not 2nd Barnabé
Francesco Risitano (Tau)
Reacted to "Can we go back to not having another Francesco in the call? 🤝" with 😆
Jihoon
Replying to "Can we go back to no..." deduplication
potuz
Reacted to "thats why I choose to be Barnabas and not 2nd Barnabé" with 😃
Łukasz Rozmej
Replying to "Can we go back to not having another Francesco in the call? 🤝" we can assing you numbers
Jun Song
Reacted to "thats why I choose to be Barnabas and not 2nd Barnabé" with 😃
Francesco Risitano (Tau)
Replying to "Can we go back to no..." Whooops I’m rebranding as Tau 🙂
cayman
Reacted to "Whooops I’m rebrandi..." with 😂
Greg K | Lido
Reacted to "Can we go back to not having another Francesco in the call? 🤝" with 🤣
Yann Vonlanthen
Reacted to "Can we go back to not having another Francesco in the call? 🤝" with 🤣
Łukasz Rozmej
Replying to "Can we go back to not having another Francesco in the call? 🤝" or UID
Csaba
Reacted to "thats why I choose to be Barnabas and not 2nd Barnabé" with 😃
Eugene Mamin
Reacted to "Whooops I’m rebranding as Tau 🙂" with 😂
Łukasz Rozmej
comparing to ACDE this ACDC fork planning is slow…..
potuz
Replying to "Can we go back to no..." Whooops I’m rebranding as Tau 🙂 You should have picked a particle discovered by Fermi instead 😁
Tuyen
Reacted to "Whooops I’m rebranding as Tau 🙂" with 😂
potuz
Reacted to "comparing to ACDE this ACDC fork planning is slow….." with 🤣
Iván | ethrex
Reacted to "comparing to ACDE th..." with 😅
Barnabas
Replying to "comparing to ACDE th..." we have less EIPs to chew through lol
Francesco Risitano (Tau)
Reacted to "Whooops I’m rebranding as Tau 🙂 You should have picked a particle discovered by Fermi instead 😁" with 😆
Barnabas
Replying to "comparing to ACDE th..." but agree, this should be timeboxed.
Łukasz Rozmej
Replying to "comparing to ACDE this ACDC fork planning is slow….." we will still finish faster
Will Corcoran
Replying to "comparing to ACDE th..." Scoping the fork delayed the fork 🫠
cayman
Reacted to "comparing to ACDE th..." with 😢
Barnabas
Reacted to "Scoping the fork delayed the fork 🫠" with 😂
Francesco Risitano (Tau)
Replying to "Can we go back to no..." I’m reserving those particle names for my children
Dima Gusakov | Lido
Reacted to "Scoping the fork delayed the fork 🫠" with 😂
Dima Gusakov | Lido
Replying to "comparing to ACDE th..." So true
danceratopz
Reacted to "comparing to ACDE th..." with 😅
ethDreamer (Mark)
If it’s just an engine api change, I vote we put it in. Speaking for myself, not lighthouse
Łukasz Rozmej
Replying to "comparing to ACDE this ACDC fork planning is slow….." ok I get the slot time reduction needed lot of discussion
Eugene Mamin
Reacted to "Scoping the fork delayed the fork 🫠" with 😂
Barnabas
Replying to "comparing to ACDE th..." Stokes gonna quick DFI all the remaining EIPs in the last 10 mins you will see we gonna finish in 10 mins 😂
Łukasz Rozmej
Replying to "comparing to ACDE this ACDC fork planning is slow….." that would be impressive :D
Daniel Knopik
Reacted to I think the power an... with "👍"
potuz
Kev has been insisting enough
Kevaundray Wedderburn
Reacted to "Kev has been insisting enough" with 😁
Łukasz Rozmej
Replying to "If it’s just an engine api change, I vote we put it in. Speaking for myself, not lighthouse" but if no-one will use it in practice then is it worth it?
Justin Traglia
I think we should defer
potuz
I think all CL clients (or most) have expressed a favorable opinion in the relevant R&D thread isn’t it?
Łukasz Rozmej
not sure if this will time box to 6 mins….
Luca Donno | L2BEAT
Reacted to "not sure if this will time box to 6 mins…." with 😁
Nico Flaig
Reacted to "I think all CL clien..." with 👍
cayman
Reacted to "I think all CL clien..." with 👍
Barnabas
we should defer this
Justin Traglia
Reacted to "I think all CL clients (or most) have expressed a favorable opinion in the relevant R&D thread isn’t it?" with 👍
Eugene Mamin
Reacted to "not sure if this will time box to 6 mins…." with 😁
Kevaundray Wedderburn
Reacted to "I think all CL clients (or most) have expressed a favorable opinion in the relevant R&D thread isn’t it?" with 👍
potuz
Reacted to "we should defer this" with 👍
Łukasz Rozmej
Reacted to "we should defer this" with 👍
potuz
Replying to "we should defer this" And DFI everything else, to be practical with time
Barnabas
Reacted to "And DFI everything else, to be practical with time" with 👍
Justin Traglia
Reacted to "And DFI everything else, to be practical with time" with 👍
Łukasz Rozmej
I have 2 points about it…. but you don't want it today
ignacio
Reacted to "I have 2 points about it…. but you don't want it today" with 😂
potuz
Does seem like the remaining ones are even harder to choose in 5’
Marius Van Der Wijden (M)
Replying to "If it’s just an engi..." Is it worth implementing it in 5+ clients at this point
stokes
Let’s get a primer on this today, and then we can wrap up
Barnabas
Could we exclude optional/informational EIPs from the primary scoping of a fork?
potuz
Reacted to "Could we exclude optional/informational EIPs from the primary scoping of a fork?" with ➕
Barnabas
It kinda feels like we are wasting a tons of time on optional things when we should be scoping the core protocol changes now.
Greg K | Lido
Replying to "Could we exclude optional/informational EIPs from the primary scoping of a fork?" I don't think it's informational, it's just not a hard fork
potuz
Why can’t we not discuss these things outside of the fork cadence
potuz
We have had meetings that were 20’
Greg K | Lido
Replying to "Could we exclude optional/informational EIPs from the primary scoping of a fork?" you need to change the beacon chain spec though
Iván | ethrex
We need this rather sooner than later
Iván | ethrex
It’s harmless to the fork and will help a lot in the zkEVM roadmap
potuz
Replying to "Could we exclude opt..." It’s not even a soft fork
Pablo Deymo | Lambda
Reacted to "We need this rather sooner than later" with ❤️
ethDreamer (Mark)
Replying to "If it’s just an engi..." My impression is that it’s not tough to implement a stronger status for where the EL is in its sync so the CL knows what’s worthwhile to pass it, but I need to look further. For me I would have deferred this decision rather than DFI
potuz
Replying to "We need this rather ..." Sure, but why does it need to be taken minutes that are bounded for scoping discussions in the couple of meetings that are allotted per year to do so?
Greg K | Lido
Replying to "It’s harmless to the fork and will help a lot in the zkEVM roadmap" harmless in what sense?
spencer
On the EL Specs side, if its CFI'd we can add all the zk fields (as optional) to all EL test fixture formats. EL clients with guest programs will have a better time consuming our releases, less branch/CI mess, will save time that will compound on zk development imo
Ansgar Dietrichs
some clients are anyway planning to support optional proofs, right? I am not sure it makes sense to mandate that all clients must support this by Hegota. We talked about not slowing things down earlier in the call, to keep moving towards PQ readiness. would rather allow clients to make the assessment for whether to implement support on their own
Manu
Reacted to "some clients are anyway planning to support optional proofs, right? I am not sure it makes sense to mandate that all clients must support this by Hegota. We talked about not slowing things down earlier in the call, to keep moving towards PQ readiness. would rather allow clients to make the assessment for whether to implement support on their own" with 👍
Barnabas
Reacted to "some clients are anyway planning to support optional proofs, right? I am not sure it makes sense to mandate that all clients must support this by Hegota. We talked about not slowing things down earlier in the call, to keep moving towards PQ readiness. would rather allow clients to make the assessment for whether to implement support on their own" with 👍
potuz
Replying to "some clients are any..." Prysm has a pretty advanced feature for this implemented
Ansgar Dietrichs
Replying to "some clients are any..." but I understand the desire to start creating a “canonical” standard. maybe we could just have it as ERC for now?
Łukasz Rozmej
So would this be informational EIP?
Manu
Replying to "some clients are any..." For information this EIP does not change neither the Beacon state nor the beacon block
Kevaundray Wedderburn
Replying to "some clients are any..." I think we can CFI and not mandate all clients to implement it
Manu
Reacted to "I think we can CFI and not mandate all clients to implement it" with 👍
spencer
Reacted to "I think we can CFI..." with ❤️
danceratopz
Reacted to "On the EL Specs side..." with ➕
Greg K | Lido
Replying to "Could we exclude optional/informational EIPs from the primary scoping of a fork?" but you need to update the clients to support it, so it's not informational, right?
potuz
Replying to "some clients are any..." Why is it even an EIP?
Ansgar Dietrichs
Replying to "some clients are any..." @Kevaundray Wedderburn that confuses me, that’s what ERCs are for
Kevaundray Wedderburn
Replying to "Could we exclude opt..." Would this include networking EIPs?
Manu
Reacted to "I don't think it's informational, it's just not a hard fork" with 👍
Daniel Knopik
Reacted to some clients are any... with "👍"
Parithosh Jayanthi
Reacted to "Kev has been insisting enough" with 😁
ignacio
Replying to "It’s harmless to the fork and will help a lot in the zkEVM roadmap" harmful in which sense?
cayman
Reacted to "My impression is tha..." with 👍
jochem-brouwer
Thanks all =) Happy forking!! :D
Iván | ethrex
Reacted to "harmful in which sen..." with ☝️
Gary Schulte
Reacted to "harmful in which sense?" with ☝️
ethDreamer (Mark)
Thanks guys!

Call summary

Targets

•Sepolia Glamsterdam upgrade — October 6, 2026 at 13:53 UTC - 00:08:22
•Hoodi upgrade — tentatively October 27, 2026 (pending Sepolia outcome) - 00:10:18

Decisions

•CFI for Hegota: EIP-8365 (deposit guard only; forced-exit split into separate future EIP) - 00:23:28
•CFI for Hegota: EIP-8198 (quick slots / slot time parameterization); actual 12→10s reduction requires further validation before SFI - 01:02:49
•DFI: EIP-8379 (Top Up Sync); engine API experimentation may continue outside fork cadence - 01:26:38

Highlights

Incident Response:
- ·Incident response plan live in PM repo; client teams must nominate coordinators by end of Monday or Barnabas will assign - 00:10:44
- ·Confirmed coordinators: Pari + Barnabas (DevOps), Mario Vega primary + Justin Traglia backup (Testing), Nikos (Security) - 00:13:10
Eip Proposals Hegota:
- ·EIP-8333 (line checkpoint with epoch boundary block) withdrawn by Lodestar; decoupling concerns - 00:19:09
- ·EIP-8363 (tapered issuance burn) withdrawn; champions pursuing broader community-driven process instead - 00:19:47
- ·EIP-8365: split into deposit guard (CFI'd) + standalone forced-exit EIP for future fork - 00:22:29
- ·Quick slots (EIP-8198): broad value acknowledged; PQ/testing concerns raised by Grandine, Nimbus; 3/5 CL teams S/A; CFI'd with caveat that 12→10s reduction still needs validation before SFI - 00:25:28
- ·EIP-8379 (Top Up Sync): limited support; DFI'd — engine API experimentation encouraged outside fork scope - 01:03:55
- ·EIP-8383 (Reduce CL block retention window): deferred to next ACDC; teams asked to review beforehand - 01:27:32
- ·EIP-8025 (optional execution proofs): not decided today; Nethermind raised gas-repricing security concern and zkVM committee-selection concern; discussion continues next call - 01:28:43
Fork Status And Schedule:
- ·Sepolia shadow fork launching within the hour; live 1-2 days pre-fork - 00:07:42
- ·Sepolia forks to Glamsterdam on October 6 at 13:53 UTC - 00:08:22
- ·Hoodi date tentatively October 27 (week before Devcon), pending Sepolia success; to be confirmed at ACDE next week - 00:09:31

Action Items

•All CL client teams - Nominate client team incident response coordinator via PR to PM repo before end of Monday - 00:14:01
•All CL client teams - Review EIP-8383 (Reduce CL block retention window) before next ACDC - 01:27:48

Key decisions

Sepolia forks to Glamsterdam on October 6 at 13:53 UTC
SFISepolia Glamsterdam upgrade date confirmed
Hoodi date tentatively October 27 (week before Devcon), pending Sepolia success
PFITentative date for Hoodi upgrade pending Sepolia outcome
Confirmed coordinators: Pari + Barnabas (DevOps), Mario Vega primary + Justin Traglia backup (Testing), Nikos (Security)
Incident response coordinators confirmed for DevOps, Testing, and Security
EIP-8333 (line checkpoint with epoch boundary block) withdrawn by Lodestar; decoupling concerns
UnknownWithdrawn by Lodestar due to decoupling concerns
EIP-8363 (tapered issuance burn) withdrawn; champions pursuing broader community-driven process instead
UnknownChampions pursuing broader community-driven process instead
CFI for Hegota: EIP-8365 (deposit guard only; forced-exit split into separate future EIP)
CFIEIP-8365 split into deposit guard (CFI'd) and a standalone forced-exit EIP for a future fork
CFI for Hegota: EIP-8198 (quick slots / slot time parameterization); actual 12→10s reduction requires further validation before SFI
CFICFI'd with the caveat that the slot time reduction requires further validation before being scheduled
DFI: EIP-8379 (Top Up Sync); engine API experimentation may continue outside fork cadence
DFIDeclined for inclusion; experimentation encouraged outside the fork scope
EIP-8383 (Reduce CL block retention window) deferred to next ACDC
Teams asked to review the proposal before the next meeting
EIP-8025 (optional execution proofs) discussion continues next call; Nethermind raised gas-repricing and zkVM concerns
Decision not reached; security and committee-selection concerns raised by Nethermind

EIPs discussed

EIP-8025 EIP-8198 EIP-8333 EIP-8363 EIP-8365 EIP-8379 EIP-8383

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.