ACDE2026-10-22_248

AllCoreDevs - Execution #248

2026-10-22 6 decisions 659 transcript lines

Transcript

Follow along

Justin Traglia
Gm
lightclient
gm
Potuz
What did I miss, as soon as I got in the very first thing I hear is “everyone please be at their best behavior”.
Barnabas
Replying to "What did I miss, as ..." we are live streaming right away lol
Potuz
Did Barnabas start whipping people?
Luca Donno | L2BEAT
Reacted to "What did I miss, as soon as I got in the very first thing I hear is “everyone please be at their best behavior”." with 😂
Potuz
Reacted to "we are live streaming right away lol" with 🙏
Parithosh Jayanthi
Reacted to "What did I miss, as soon as I got in the very first thing I hear is “everyone please be at their best behavior”." with 😂
Parithosh Jayanthi
Reacted to "we are live streaming right away lol" with 🙏
Justin Traglia
Reacted to "What did I miss, as soon as I got in the very first thing I hear is “everyone please be at their best behavior”." with 😂
Barnabas
Replying to "Did Barnabas start w..." that never stops
Trent Van Epps
https://www.chainsecurity.com/blog/glamsterdam-gas/index.html
Maria Silva
Me too
Barnabas
yeah same
spencer
very quiet on the mic
stokes
Sounds muffled
Barnabas
maybe change input mic?
Barnabas
or connect from phone?
felipe
no sound
felipe
yeah connect from phone maybe
jochem-brouwer (Fairphone)
Buzz sound
felipe
much better
lightclient
this seems bad
Justin Florentine
Reacted to "this seems bad" with ➕
Enrico Del Fante
Reacted to "this seems bad" with ➕
Luis Pinto
Reacted to "this seems bad" with ➕
Helkomine
Đã phản ứng với "this seems bad" bằng 👍
Ansgar Dietrichs
right so to me there are two types of issues: issues as a general consequence of repricings - unavoidable if we ever want to scale Ethereum. the example given was such a case issues specific to Glamsterdam spec choices, in particular the altered refund behavior and the state gas reservoir mechanism but either way, it does seem like there was insufficient impact analysis, so at a minimum this could justify delaying the rollout to give time for proper analyiss
Justin Florentine
how many of the projects have test instances on sepolia?
Barnabas
Replying to "how many of the proj..." feels crazy to me that people don’t run on sepolia where they could be aware of this
Potuz
Thanks for the presentation!
Nico
Reacted to "this seems bad" with ➕
Ansgar Dietrichs
I think you cannot hear us now btw, Hubert
Toni Wahrstätter
The oog detection seems like the actual problem. Measuring gas before and after a call doesn't tell you the real cost anymore, because the reservoir pays for new state and gasleft() never sees it. Same for gasleft() can actually go up mid-call now.
Barnabas
how many of these contracts are immutable/non-upgradable? I think generally its acceptable that a L2 or defi project has to update their code if the protocol updates on a hard fork.
Ansgar Dietrichs
feel free to finish
Francesco D'Amato
We could hear you still
Helkomine
Trả lời "right so to me the..." Why not reduce the computational costs? I suspect that’s the main objective being pursued.
Ansgar Dietrichs
need to extend micdao to cover acd guests
Barnabas
Reacted to "need to extend micdao to cover acd guests" with 😂
jochem-brouwer
Heeft gereageerd op "need to extend mic..." met 😂
Christine Kim
Reacted to "need to extend micdao to cover acd guests" with 👍
Luca Donno | L2BEAT
Reacted to "how many of these contracts are immutable/non-upgradable? I think generally its acceptable that a L2 or defi project has to update their code if the protocol updates on a hard fork." with 😱
Ben Edgington
Reacted to "need to extend micdao to cover acd guests" with 😂
Luca Donno | L2BEAT
Reacted to "need to extend micdao to cover acd guests" with 😂
spencer
Reacted to "Thanks for the pre..." with 💙
Ansgar Dietrichs
let us know once you can hear us
Parithosh Jayanthi
Reacted to "need to extend micdao to cover acd guests" with 👍
Parithosh Jayanthi
Reacted to "need to extend micdao to cover acd guests" with 😂
Guru
Reacted to "need to extend micda..." with 😂
lightclient
it feels weird to be analyzing the problems and say “well this is technically a result of relying on fixed gas costs and we told you not to do it so now SOL!” when it is barely obvious to protocol devs that these examples are relying on fix gas assumptions
Toni Wahrstätter
Best way forward would be to get in touch with affected parties as soon as possible (great that chainsecurity did already with some), and double-check with them.
Justin Traglia
Reacted to "Thanks for the presentation!" with 💙
Hubert (ChainSecurity)
I can hear you now. sorry.
Justin Traglia
Reacted to "need to extend micdao to cover acd guests" with 😂
lightclient
Reacted to "need to extend micdao to cover acd guests" with 😂
Justin Traglia
Reacted to "Best way forward would be to get in touch with affected parties as soon as possible (great that chainsecurity did already with some), and double-check with them." with 👍
Nico
Reacted to "need to extend mic..." with 😂
Luca Donno | L2BEAT
Reacted to "Thanks for the presentation!" with 💯
Mario Vega
Reacted to "Best way forward would be to get in touch with affected parties as soon as possible (great that chainsecurity did already with some), and double-check with them." with 👍
Kevaundray Wedderburn
I think finding out the blast radius makes the most sense
felipe
Reacted to "Thanks for the pre..." with 💯
felipe
Reacted to "Thanks for the pre..." with 💙
spencer
Reacted to "I think finding ou..." with 💯
lightclient
Replying to "how many of the proj..." just running on sepolia wouldn’t allow you to be aware for all of these
lightclient
Replying to "how many of the proj..." many require malicious tx crafting
Luca Donno | L2BEAT
Reacted to "just running on sepolia wouldn’t allow you to be aware for all of these" with 👍
lightclient
Reacted to "I think finding out the blast radius makes the most sense" with 💯
Guru
Reacted to "many require malicio..." with 👍
Dustin
should this affect mainnet timing?
Potuz
Reacted to "many require malicious tx crafting" with 👍
Justin Florentine
Replying to "how many of the proj..." yes, for sure. i just wanna know if we have realistic opportunity to do that.
lightclient
Replying to "should this affect m..." i dont think we should schedule mainnet until we have an answer here
Mario Vega
Reacted to "i dont think we should schedule mainnet until we have an answer here" with 👍🏼
Łukasz Rozmej
Reacted to "i dont think we should schedule mainnet until we have an answer here" with 👍🏼
Chris Berry
Reacted to "i dont think we should schedule mainnet until we have an answer here" with 👍
Kevaundray Wedderburn
Reacted to "i dont think we should schedule mainnet until we have an answer here" with 👍🏼
Toni Wahrstätter
Replying to "should this affect mainnet timing?" not yet. I'd first understand the impact better.
Kevaundray Wedderburn
Reacted to "not yet. I'd first understand the impact better." with 👍
Iván | ethrex
Reacted to "not yet. I'd first understand the impact better." with 👍
Mario Vega
Reacted to "not yet. I'd first understand the impact better." with 👍
Łukasz Rozmej
Reacted to "not yet. I'd first understand the impact better." with 👍
Parithosh Jayanthi
Reacted to "i dont think we should schedule mainnet until we have an answer here" with 👍🏼
Parithosh Jayanthi
Reacted to "not yet. I'd first understand the impact better." with 👍
Luca Donno | L2BEAT
Reacted to "not yet. I'd first understand the impact better." with 👍
Justin Traglia
Reacted to "not yet. I'd first understand the impact better." with 👍
Barnabas
Reacted to "not yet. I'd first understand the impact better." with 👍
Luca Donno | L2BEAT
Reacted to "i dont think we should schedule mainnet until we have an answer here" with 👍
Łukasz Rozmej
Replying to "should this affect mainnet timing?" But we shouldn't plan mainnet yet then just to postpone it, we should postpone mainnet date decision
Guru
Reacted to "i dont think we shou..." with 👍🏼
lightclient
imo unless you hardcode the CALL gas, i feel like we shouldn’t be breaking production contracts
Luca Donno | L2BEAT
Reacted to "But we shouldn't plan mainnet yet then just to postpone it, we should postpone mainnet date decision" with 👍
Potuz
Replying to "should this affect m..." I tend to think with you Matt, but It’d be better to not decide absolutely anything during this call and at least delay discussions on the topic until next ACD, possibly ACDC. But yeah, understanding this better would take some time depending on the type and number of systems affected
Fredrik
Reacted to "i dont think we should schedule mainnet until we have an answer here" with 👍🏼
Fredrik
Reacted to "But we shouldn't plan mainnet yet then just to postpone it, we should postpone mainnet date decision" with 👍
Chris Berry
Replying to "should this affect m..." Decision shouldn’t be made until after Hoodi anyway. I think Barnabas was just doing a temp check today
Daniel Lehrner
What about Hoodi? Do we delay the hardfork?
lightclient
Replying to "What about Hoodi? Do..." good question
Justin Traglia
Replying to "What about Hoodi? Do..." It’s too late to delay Hoodi’s upgrade imo.
felipe
Reacted to "i dont think we sh..." with 👍🏼
Ansgar Dietrichs
basically, as a first statement, we should clearly commit to not picking a mainnet fork date before we have a thorough understanding of the impacts
spencer
Reacted to "It’s too late to ..." with 💯
Barnabas
Reacted to "It’s too late to delay Hoodi’s upgrade imo." with 💯
lightclient
Replying to "What about Hoodi? Do..." it’s not too late
pk910
Reacted to "It’s too late to del..." with 💯
Justin Florentine
Replying to "What about Hoodi? Do..." disagree. it'd be a useful control vs. sepolia
Potuz
Can we discuss Hoodi please as if something is triggered there it would be a nightmare to keep forks
lightclient
Reacted to "Can we discuss Hoodi please as if something is triggered there it would be a nightmare to keep forks" with 👍
Chris Berry
Reacted to "Can we discuss Hoodi please as if something is triggered there it would be a nightmare to keep forks" with 👍
Enrico Del Fante
Reacted to "Can we discuss Hoodi please as if something is triggered there it would be a nightmare to keep forks" with 👍
lightclient
Replying to "What about Hoodi? Do..." yeah i guess i didn’t consider that we can delay hoodi, but that seems pretty good to do right now
Toni Wahrstätter
delaying hoodi makes not much sense, no? If we changed the specs we'd have to fork testnets again anyway
Barnabas
Reacted to "delaying hoodi makes no much sense, no? If we changed the specs we'd have to fork testnets again anyway" with 👍
Francesco D'Amato
Replying to "Can we discuss Hoodi..." What do you mean by triggered there?
Christine Kim
Reacted to "delaying hoodi makes not much sense, no? If we changed the specs we'd have to fork testnets again anyway" with 👍
Francesco D'Amato
Replying to "Can we discuss Hoodi..." Consensus issues?
Potuz
Replying to "Can we discuss Hoodi..." If we do change the spec then we either ditch that network or add a new fork
Barnabas
we can always have a pre glammy devnet up
Potuz
Replying to "Can we discuss Hoodi..." If we delay the fork now we can do that without coordinating a new fork
Mario Vega
Reacted to "delaying hoodi makes not much sense, no? If we changed the specs we'd have to fork testnets again anyway" with 👍
Luca Donno | L2BEAT
Reacted to "delaying hoodi makes not much sense, no? If we changed the specs we'd have to fork testnets again anyway" with 👍
Barnabas
I don’t think there is a value in keeping hoodi pre glamsterdam
lightclient
Replying to "I don’t think there ..." i mean obviously there is
lightclient
Replying to "I don’t think there ..." if we have to make a spec change we would want there to be a network that will actually follow mainnet forks
Dustin
sepolia was already close to EOL, no?
pk910
Replying to "sepolia was already ..." we have extended it one more year. EOL end of 2027
Mehdi Aouadi
Reacted to "Can we discuss Hoodi please as if something is triggered there it would be a nightmare to keep forks" with 👍
Łukasz Rozmej
We can have glamsterdam v1 and Glamsterdam V2 hardforks for testers and only V2 on mainnet
Dustin
Reacted to "we have extended i..." with 👍
Parithosh Jayanthi
Reacted to "We can have glamsterdam v1 and Glamsterdam V2 hardforks for testers and only V2 on mainnet " with 👍
lightclient
Reacted to "sepolia was already close to EOL, no?" with 👍
stokes
Reacted to "We can have glamsterdam v1 and Glamsterdam V2 hardforks for testers and only V2 on mainnet " with 👍
Enrico Del Fante
And he is gone
pk910
Reacted to "We can have glamster..." with 👍
Ansgar Dietrichs
so as I see it there are two (independent) potential reasons to halt Hoodi fork for now: for analysis of these issues, having one testnet each on pre and post Glamsterdam specs to compare in case mitigation requires Glamsterdam spec changes, not having another testnet on an incompatible fork version
Maria Silva
How much time do you think we would need to do the more comprehensive analysis, @Hubert (ChainSecurity) ?
Justin Traglia
Reacted to "And he is gone" with 😂
stokes
Yeah I don’t think we will cancel hoodi in time, but we can do glam2 on each testnet
Mehdi Aouadi
Reacted to "And he is gone" with 😂
Louis
Reacted to "imo unless you hardcode the CALL gas, i feel like we shouldn’t be breaking production contracts" with 👍
Luca Donno | L2BEAT
Reacted to "How much time do you think we would need to do the more comprehensive analysis, @Hubert (ChainSecurity) ?" with ➕
Trent Van Epps
Reacted to "Yeah I don’t think we will cancel hoodi in time, but we can do glam2 on each testnet" with 👍
Chris Berry
Could we not revert to previous fusaka versions
Chris Berry
Replying to "Could we not revert ..." What potuz said
lightclient
do we not know ~66% of stake on hoodi?
Potuz
If this were on CL I would strongly oppose Lukasz option: maintaining GL v1 and v2 forever sounds horrible
lightclient
Reacted to "If this were on CL I would strongly oppose Lukasz option: maintaining GL v1 and v2 forever sounds horrible" with 👍
Gary Schulte
Reacted to "If this were on CL I would strongly oppose Lukasz option: maintaining GL v1 and v2 forever sounds horrible" with ➕
Justin Florentine
are there any reasons against that are not deadline related?
Chris Berry
Reacted to "If this were on CL I would strongly oppose Lukasz option: maintaining GL v1 and v2 forever sounds horrible" with 💯
Fabio Di Fabio
Reacted to "If this were on CL I would strongly oppose Lukasz option: maintaining GL v1 and v2 forever sounds horrible" with 👍
Fabio Di Fabio
Reacted to "If this were on CL I would strongly oppose Lukasz option: maintaining GL v1 and v2 forever sounds horrible" with ➕
Parithosh Jayanthi
Yeah I think pandaops alone is like 40% of the hoodi network
Justin Traglia
Reacted to "If this were on CL I would strongly oppose Lukasz option: maintaining GL v1 and v2 forever sounds horrible" with 👍
Fredrik
Reacted to "If this were on CL I would strongly oppose Lukasz option: maintaining GL v1 and v2 forever sounds horrible" with 👍
Daniel Lehrner
Reacted to "If this were on CL I would strongly oppose Lukasz option: maintaining GL v1 and v2 forever sounds horrible" with 💯
Barnabas
Reacted to "If this were on CL I would strongly oppose Lukasz option: maintaining GL v1 and v2 forever sounds horrible" with 👍
Helkomine
If there’s a glamsterdam V2 version, please provide a refill for SELFDESTRUCT; I need a temporary patch before Hegota.
danceratopz
Reacted to "How much time do you..." with ➕
Hubert (ChainSecurity)
Just to be clear: We are not saying there HAVE to be spec changes. We just think everyone should be aware. Also: reaching affected projects has been hard (we are stuck in the AI submission spam).
spencer
Replying to "If there’s a glam..." we are removing it in hegota no?
danceratopz
Reacted to "it’s not too late" with ➕
Fredrik
I would say that according to the upgrade process we should technically pause, but it’s a bit unclear to me how feasible it is: https://github.com/ethereum/pm/blob/master/processes/protocol-upgrade.md#eips "In the event that an included EIP has a significant issue that requires a change to the EIP, additional testing, a security assessment and an agreement on ACD must be done before the upgrade process continues.”
Kevaundray Wedderburn
Do we know who will be doing the more comprehensive analysis and how long it will take?
lightclient
Reacted to "Just to be clear: We are not saying there HAVE to be spec changes. We just think everyone should be aware. Also: reaching affected projects has been hard (we are stuck in the AI submission spam)." with 👍
Francesco D'Amato
I think not doing the Hoodi fork if feasible seems like a good choice. But just to understand, has anyone seen any indication that there should be spec changes? Because everything that I have looked at that points to no spec changes
Fredrik
Replying to "Do we know who will ..." We have reached out to a few parties
Luca Donno | L2BEAT
Reacted to "Just to be clear: We are not saying there HAVE to be spec changes. We just think everyone should be aware. Also: reaching affected projects has been hard (we are stuck in the AI submission spam)." with 👍
Ansgar Dietrichs
Replying to "I think not doing th..." right I agree on that, but I feel like today is not the day yet for that discussion
Luca Donno | L2BEAT
Reacted to "right I agree on that, but I feel like today is not the day yet for that discussion" with 👍
Ben Adams
Would the same issue have arisen if we dropped gas costs for opcodes?
Potuz
Replying to "I think not doing th..." Just the possibility of it, if it is any meaningful change, I think we should not risk Hoodi, redeploying such a testnet will be a pain
Nico
Reacted to "We have reached ou..." with 👍
lightclient
Replying to "Would the same issue..." i think some would have
stokes
Replying to "I think not doing th..." If we are trying to adjust hood on monday, we need to start making moves today
lightclient
Replying to "Would the same issue..." but some of the unexpected refunds i think could still be a problem
lightclient
Reacted to "If we are trying to adjust hood on monday, we need to start making moves today" with 👍
Potuz
Replying to "I think not doing th..." Yes, the discussion on Hoodi is urgent to have now, the rest can be talked with calm
Chris Berry
Reacted to "If we are trying to adjust hood on monday, we need to start making moves today" with 💯
Fredrik
Given that hoodi forks on the 26th the window is very close to being shut
Kevaundray Wedderburn
Reacted to "We have reached out to a few parties" with 👍
Ansgar Dietrichs
a cost of delaying Hoodi would be that a Dec mainnet fork would become unrealistic, right? but do we think that a Dec fork is still in the cards regardless? it seems like a full analysis here will take time, so if Dec is no longer realistic, we should try to stop the Hoodi fork imo
stokes
Reacted to "Given that hoodi forks on the 26th the window is very close to closing" with 👍
lightclient
Replying to "a cost of delaying H..." i think we should worry about breaking contracts on ethereum and not about timelines
Potuz
Replying to "a cost of delaying H..." Security trumps timeliness of the fork 100%
Ansgar Dietrichs
Replying to "a cost of delaying H..." right! that’s why I am saying, if Dec is out of the question, we might as well stop Hoodi
lightclient
Reacted to "Security trumps timeliness of the fork 100%" with 🔥
Fredrik
Reacted to "Security trumps timeliness of the fork 100%" with ➕
Kevaundray Wedderburn
Whats the bottleneck for the two to three weeks?
Guru
Reacted to "Security trumps time..." with ➕
Potuz
Reacted to "right! that’s why I am saying, if Dec is out of the question, we might as well stop Hoodi" with 👍
Luca Donno | L2BEAT
Reacted to "i think we should worry about breaking contracts on ethereum and not about timelines" with 👍
spencer
Reacted to "Security trumps ti..." with 🔥
spencer
Reacted to "Security trumps ti..." with ➕
Kevaundray Wedderburn
Replying to "Whats the bottleneck..." Sounds like outreach?
spencer
Reacted to "i think we should ..." with 👍
Enrico Del Fante
Reacted to "right! that’s why I am saying, if Dec is out of the question, we might as well stop Hoodi" with 👍
lightclient
in the past dedaub has done a very good job about codifying invariants like this and searching through all the existing contracts
Fredrik
What’s the likelihood of getting 66% to revert prior to the 26th? If pandaops is 40% then we’d need 26% more
Potuz
And I thought it would be the CL that would prevent ePBS from shipping 🤦‍♂️
Barnabas
Replying to "And I thought it wou..." CL only fork?
lightclient
Reacted to "And I thought it would be the CL that would prevent ePBS from shipping 🤦‍♂️" with 😆
spencer
Reacted to "And I thought it w..." with 😅
lightclient
Reacted to "CL only fork?" with 👀
lightclient
delay hoodi
Toni Wahrstätter
Replying to "And I thought it would be the CL that would prevent ePBS from shipping 🤦‍♂️" all downstream from trustless payments...
Fredrik
Replying to "in the past dedaub h..." agreed, we are in touch with them about this as well
Luca Donno | L2BEAT
Reacted to "CL only fork?" with 👀
Fredrik
Reacted to "in the past dedaub has done a very good job about codifying invariants like this and searching through all the existing contracts" with ➕
Barnabas
we can def roll back
stokes
Replying to "What’s the likelihoo..." AIUI higj
stokes
Replying to "What’s the likelihoo..." High
Ben Adams
Replying to "And I thought it would be the CL that would prevent ePBS from shipping 🤦‍♂️" Time to do extra changes in CL if delay
Kevaundray Wedderburn
Reacted to "What’s the likelihood of getting 66% to revert prior to the 26th? If pandaops is 40% then we’d need 26% more" with 👍
Fredrik
Reacted to "AIUI higj" with 👍
Parithosh Jayanthi
Replying to "What’s the likelihoo..." Yeah I think we can be relatively sure we get people to revert releases
Enrico Del Fante
Reacted to "all downstream from trustless payments..." with 😂
felipe
Reacted to "delay hoodi" with 👍
Chris Berry
We can rollback
Justin Traglia
Reacted to "And I thought it would be the CL that would prevent ePBS from shipping 🤦‍♂️" with 😅
Toni Wahrstätter
how long do we want to delay?
Justin Traglia
Reacted to "CL only fork?" with 👀
Justin Florentine
Replying to "And I thought it wou..." gas introspection remains undefeated as The Worst™
Toni Wahrstätter
Should we directly pick a new date?
Dustin
won't those releases still be out? what's the logistics on this?
lightclient
at least until we discuss ACDC next week
Oisin Kyne
blow up, no, but i do wonder if lido will have fun with it
Parithosh Jayanthi
Reacted to "Time to do extra changes in CL if delay" with 😂
Oisin Kyne
presume they don’t have a timelock upgrade on hoodi no answer from dima in the last 15 mins on it. be fine really i’d say 🙂
Fredrik
Agree on not setting a specific date until we have more info from the analysis etc.
Lean F | ethrex
If we delay hoodi what can be the expected date for mainnet then?
lightclient
Replying to "won't those releases..." roll back, re-release without hoodi time, or some clients have override flag
Barnabas
Replying to "If we delay hoodi wh..." TBD+ 1.5mo
Lean F | ethrex
Let’s suppose we delay this until after devcon
Lean F | ethrex
That will be 2027
Ansgar Dietrichs
I guess testing to revert an update is valuable in itself
Justin Florentine
so what about sepolia, has this been exploited there yet?
Chris Berry
Reacted to "I guess testing to revert an update is valuable in itself" with 👍
Barnabas
some of clients had DB updates, so it might be more difficult for some clients to roll back than others
Luca Donno | L2BEAT
Reacted to "I guess testing to revert an update is valuable in itself" with 👍
felipe
Reacted to "I guess testing to..." with 👍
Lean F | ethrex
Reacted to "I guess testing to revert an update is valuable in itself" with 👍
felipe
Reacted to "I guess testing to..." with 💯
Barnabas
Replying to "some of clients had ..." but we can always yeet the db and resync
Potuz
Prysm will have some issues with re-releasing some security patches or instructing main net and Hoodi users to use different versions… but I still prefer to delay Hoodi
Parithosh Jayanthi
Reacted to "I guess testing to revert an update is valuable in itself" with 💯
Dustin
I mean, it's not that e.g., Nimbus can't release something which undoes Hoodi fork, it's that some portion of users will run (as with other clients, CL and EL) the "Hoodi-ready" versions
Dustin
do we know what portion of users are likely to do this?
Kevaundray Wedderburn
Replying to "do we know what port..." I think the assumption is that those users won’t finalise, because 66% of the chain will have reverted
spencer
Reacted to "I guess testing to..." with 👍
Kevaundray Wedderburn
Im finding it hard to hear you @Dustin
Dustin
Replying to "Im finding it hard..." ah ok
Ansgar Dietrichs
do we have representatives from all CL clients on the call btw? but otherwise still seems clear decision
Dustin
Replying to "Im finding it hard..." anyway managed to convey what I wanted
stokes
Can’t we just say to use the most recent release before a client was ready for hoodi?
wolovim
Replying to "Im finding it hard t..." already bankrupted micdao
lightclient
so next touch point is ACDT, hopefully we can start discussing early results of findings on mainnet? we need to decide if this is something people can upgrade out of or if there is a change to the spec that can be made
Dima Gusakov | Lido
sup
Mega | ethlambda
Is this delay only to avoid user contracts being exploited on Hoodi? Or do we expect this exploit to affect consensus?
stokes
Replying to "sup" Any issue delaying hoodi that you can see?
Francesco D'Amato
Replying to "Is this delay only t..." To avoid the possibility of a later spec change that would diverge from what’s on hoodi
Barnabas
we shouldn’t set a new date until we know more
Fabio Di Fabio
Reacted to "we shouldn’t set a new date until we know more" with 👍
lightclient
Replying to "Is this delay only t..." the delay is to keep hoodi on fusaka in case we need to do a spec change so we can have a real testnet similar to mainnet to test the update on
lightclient
Reacted to "we shouldn’t set a new date until we know more" with 👍
stokes
Replying to "sup" We are considering doing so after some investigation into a potential security issue with smart contracts
Luca Donno | L2BEAT
Reacted to "we shouldn’t set a new date until we know more" with 👍
stokes
Reacted to "we shouldn’t set a new date until we know more" with 👍
Mega | ethlambda
Reacted to "the delay is to keep hoodi on fusaka in case we need to do a spec change so we can have a real testnet similar to mainnet to test the update on" with 👍
Dima Gusakov | Lido
What’s the background?
Mega | ethlambda
Reacted to "To avoid the possibility of a later spec change that would diverge from what’s on hoodi" with 👍
Dima Gusakov | Lido
Sorry just joined
Oisin Kyne
Replying to "What’s the backgroun..." has anyone the PR/diff of the spec that we want to change?
Dustin
Reacted to "we shouldn’t set ..." with 👍
Potuz
Reacted to "To avoid the possibility of a later spec change that would diverge from what’s on hoodi" with 👍
Dustin
Replying to "What’s the backgr..." no specific proposed change yet
lightclient
Replying to "What’s the backgroun..." a lot of it feels pretty core to 8037/8038 😅
Toni Wahrstätter
So, analysis + outreach (this and next week) and decide about hoodi next week (hopefully with things being clearer - otherwise the week after)
Barnabas
https://github.com/eth-clients/hoodi/pull/33
Mario Vega
Reacted to "So, analysis + outreach (this and next week) and decide about hoodi next week (hopefully with things being clearer - otherwise the week after)" with 👍
Barnabas
Replying to "https://github.com/e..." @Dustin
spencer
Reacted to "https://github.com..." with 🥲
lightclient
right now we’re talking about not doing glam on hoodi until a later date
Iván | ethrex
Reacted to "https://github.com/eth-clients/hoodi/pull/33" with 🥲
Dustin
Replying to "https://github.com..." ok lgtm
Maria Silva
Replying to "What’s the backgroun..." We haven’t yet found a non-upgradable contract that is vulnerable. If we do, then we need to understand why they are vulnerable and then figure out how to change the spec. At this point in time, there a various options for what could be breaking specifically
Enrico Del Fante
Replying to "https://github.com/e..." https://github.com/Consensys-Incorporated/teku/pull/11566 😢
Mehdi Aouadi
Reacted to "https://github.com/eth-clients/hoodi/pull/33" with 🥲
spencer
Reacted to "We haven’t yet fo..." with ➕
lightclient
un-🚢 it
Kamil Salakhiev
Reacted to "un-🚢 it" with 😃
Maria Silva
Reacted to "un-🚢 it" with 🥲
gary
已使用🥲回应"un-🚢 it"
Parithosh Jayanthi
Reacted to "un-🚢 it" with 🥲
Mario Vega
Reacted to "un-🚢 it" with 🥲
Kevaundray Wedderburn
Do you know what the total amount of stake is roughly?
Ansgar Dietrichs
Replying to "un-🚢 it" we should reconsider that entire decentralization thing, would be so much easier to just talk to devops
Enrico Del Fante
Reacted to "un-🚢 it" with 😢
Potuz
We need to figure out contracts on Hoodi that would break because of assuming the Gloas fork slot, although that’s presumably less urgent
Parithosh Jayanthi
https://dora.hoodi.ethpandaops.io/validators/activity
Chris Berry
Once there is a blogpost we can share from Vouch discord and help socialise.
Dima Gusakov | Lido
https://operators-hoodi.testnet.fi/
Dima Gusakov | Lido
Here is the info for Lido on Hoodi
Parithosh Jayanthi
On hoodi, pandaops + all client teams is ~73%
Oisin Kyne
Reacted to "On hoodi, pandaops +..." with 🎉
Potuz
Reacted to "On hoodi, pandaops + all client teams is ~73%" with ❤️
Parithosh Jayanthi
So we should be fine
Fredrik
Reacted to "On hoodi, pandaops + all client teams is ~73%" with 💯
Enrico Del Fante
Reacted to "On hoodi, pandaops + all client teams is ~73%" with 🎉
Mario Vega
Reacted to "On hoodi, pandaops + all client teams is ~73%" with ❤️
Guru
Reacted to "On hoodi, pandaops +..." with 🎉
Iván | ethrex
Reacted to "On hoodi, pandaops + all client teams is ~73%" with 🎉
Mario Vega
Reacted to "On hoodi, pandaops + all client teams is ~73%" with 🎉
stokes
ELs and CL clients
Kevaundray Wedderburn
Reacted to "ELs and CL clients" with 👍
stokes
I could see other things in the hoodi release that a client team could want out, in which case they would need to make a new release
stokes
And not just rollback to earlier version
Dima Gusakov | Lido
Would there be a list of versions to rollback to for each client?
Dima Gusakov | Lido
Reacted to "On hoodi, pandaops + all client teams is ~73%" with ❤️
Dima Gusakov | Lido
Reacted to "On hoodi, pandaops + all client teams is ~73%" with 💯
Dima Gusakov | Lido
Reacted to "On hoodi, pandaops + all client teams is ~73%" with 🎉
Dima Gusakov | Lido
Replying to "On hoodi, pandaops +..." Big boiz
Kevaundray Wedderburn
Replying to "And not just rollbac..." In terms of derisking, what about them making a release that reverts to Fusaka (which should be safe). Then another release with the new changes they want ontop of Fusaka that should be non-breaking ?
Łukasz Rozmej
Reacted to "I guess testing to revert an update is valuable in itself" with 👍
lightclient
should we discuss a bit what findings would cause us to change the spec?
Barnabas
Reacted to "Would there be a list of versions to rollback to for each client?" with 👍
Łukasz Rozmej
Reacted to "And I thought it would be the CL that would prevent ePBS from shipping 🤦‍♂️" with 😆
Łukasz Rozmej
Reacted to "And I thought it would be the CL that would prevent ePBS from shipping 🤦‍♂️" with 😅
Barnabas
Reacted to "should we discuss a bit what findings would cause us to change the spec?" with 👍
Mario Vega
Reacted to "should we discuss a bit what findings would cause us to change the spec?" with 👍
Csaba
Why recommend rollback?
Barnabas
at least my Monday evening is free again, thanks guys 😂
Potuz
Reacted to "at least my Monday evening is free again, thanks guys 😂" with 😂
Parithosh Jayanthi
Reacted to "at least my Monday evening is free again, thanks guys 😂" with 😂
Chris Berry
Reacted to "at least my Monday evening is free again, thanks guys 😂" with 😂
felipe
Reacted to "at least my Monday..." with 😂
Potuz
Replying to "at least my Monday e..." Work on changing the fork to be just ePBS
Barnabas
Replying to "at least my Monday e..." maybe we can do heze before glammy
Kevaundray Wedderburn
Replying to "should we discuss a ..." I guess a non-upgradeable contract that holds a lot of value that allows a malicious actor to exploit the contract in a way that causes it to lose a lot funds?
Iván | ethrex
Reacted to "maybe we can do heze before glammy" with 🤝
Ansgar Dietrichs
to be clear, that’s not my mindset at all, I don’t think it’s about assigning blame to app devs it’s just about making the assessment about which of the breaking patterns could be fixed without cancelling Glamsterdam (or the scaling within Glamsterdam) altogether
Lean F | ethrex
Reacted to "maybe we can do heze before glammy" with 🛳️
Iván | ethrex
Reacted to "maybe we can do heze before glammy" with 🛳️
felipe
Reacted to "to be clear, that..." with 💯
Toni Wahrstätter
I think most agree that if this breaks important functionality that isn't replaceable, we'd change the specs but right now it's too early to get concrete on this
Luis Pinto
I think it’s a learning exercise to engage more with the community earlier and insights on deployed user contracts
Potuz
@nflaig are your builder deposits already on Hoodi? Lol, delaying the fork we may see some 0xb0 validators on Hoodi!
spencer
Reacted to "I think most agree..." with ➕
Justin Florentine
this is a much more nuanced example of "don't hardcode gas assumptions" which i'm more reluctant to include in the things we expected.
lightclient
fwiw i would rather the execution layer not be very mutable 🙂
Dustin
Replying to "I think it’s a le..." what would that look like? this was all public months ago
Ansgar Dietrichs
Replying to "I think it’s a learn..." right that seems like one clear takeaway, it is a really bad outcome that we are only seeing this so late into the process
Dima Gusakov | Lido
Reacted to "at least my Monday evening is free again, thanks guys 😂" with 😂
Iván | ethrex
Will the Hoodi shadow fork be done anyways?
Dima Gusakov | Lido
Reacted to "maybe we can do heze before glammy" with 🛳️
Dima Gusakov | Lido
Replying to "at least my Monday e..." LMFAO
Barnabas
Replying to "Will the Hoodi shado..." its happening right now
Iván | ethrex
Reacted to "its happening right now" with 👀
Barnabas
Replying to "Will the Hoodi shado..." https://dora.glamsterdam-hsf-0.ethpandaops.io
Barnabas
Replying to "Will the Hoodi shado..." gloas is in 45 mins
Iván | ethrex
Replying to "Will the Hoodi shado..." Can’t we test these cases there?
Christine Kim
Replying to "I think it’s a learning exercise to engage more with the community earlier and insights on deployed user contracts" maybe a reason not to rush forks during the final public testnet upgrades phase since its the phase where the community finally gets involved and its not reasonable to ask all stakeholders to be involved at every stage of the upgrade process
lightclient
Replying to "Will the Hoodi shado..." what is there to test?
Barnabas
Replying to "Will the Hoodi shado..." sure, in the next 45 mins?
Barnabas
Replying to "Will the Hoodi shado..." 😂
Ansgar Dietrichs
So we will have to make two main decisions: first: will there be spec changes? second, afterwards: when do we fork mainnet?
lightclient
Replying to "Will the Hoodi shado..." we already have POCs of the exploits
Ansgar Dietrichs
Replying to "So we will have to m..." (not on the call today ofc)
Mario Vega
Reacted to "its happening right now" with 👀
Csaba
Replying to "Why recommend rollba..." I've joined late and maybe missed it, but I don't think a rollback recommendation is needed if clients can cut a release.
Luca Donno | L2BEAT
Reacted to "its happening right now" with 👀
Mega | ethlambda
Some clients will cut a new release unscheduling Hoodi instead
Mega | ethlambda
Replying to "Why recommend rollba..." It’s still TBD
Barnabas
everyone should cut new release imho
Barnabas
its cheap enough
Gary Schulte
Reacted to "everyone should cut new release imho" with ➕
Mario Vega
Reacted to "everyone should cut new release imho" with ➕
spencer
Reacted to "everyone should cu..." with ➕
Gary Schulte
Replying to "everyone should cut ..." yes, simplifies assumptions of “upgrades” for less engaged users and tooling
Justin Traglia
Reacted to "everyone should cut new release imho" with ➕
Potuz
Yeah I think that is the best option
Barnabas
merged https://github.com/eth-clients/hoodi/pull/33
Hubert (ChainSecurity)
Would be great if people and the blog post could spread the word about security issues. Certain issues will be very hard to find and projects will have an easier time to realize for themselves.
spencer
90 is the new 60! Yes please :)
Kevaundray Wedderburn
Reacted to "90 is the new 60! Yes please :)" with 🔥
Iván | ethrex
Reacted to "90 is the new 60! Yes please :)" with 🔥
Barnabas
https://github.com/ethereum/EIPs/pull/12552
Christine Kim
Reacted to "So we will have to make two main decisions: first: will there be spec changes? second, afterwards: when do we fork mainnet?" with 👍
Iván | ethrex
Reacted to "https://github.com/ethereum/EIPs/pull/12552" with ✅
Ansgar Dietrichs
https://gist.github.com/nixorokish/1f17a8527d18fcc8d10370c9c1b5583e
Christine Kim
Replying to "Would be great if people and the blog post could spread the word about security issues. Certain issues will be very hard to find and projects will have an easier time to realize for themselves." https://x.com/christine_dkim/status/2113286415807385927?s=20 , ill also highlight in my NL tonight!
spencer
Personally really like the order atm, I think for future process we could create this as we CFI EIPs
Mario Vega
Reacted to "Personally really like the order atm, I think for future process we could create this as we CFI EIPs" with 👍
Barnabas
I think CFI -> default ship it PFI -> default DFI it
Mario Vega
Reacted to "I think CFI -> default ship it PFI -> default DFI it" with 👍
Ansgar Dietrichs
Reacted to "I think CFI -> default ship it PFI -> default DFI it" with 👍
Parithosh Jayanthi
Reacted to "I think CFI -> default ship it PFI -> default DFI it" with 👍
Guru
Reacted to "I think CFI -> defa..." with 👍
Barnabas
Replying to "I think CFI -> defa..." for @lightclient I explicitly said it 😂
Daniil Ankushin | Nethermind
Reacted to "I think CFI -> default ship it PFI -> default DFI it" with 👍
Hubert (ChainSecurity)
Reacted to "https://x.com/chri..." with ❤️
soispoke
I agree "CFI because it's contentious" doesn't make sense
jochem-brouwer
I think it is something inbetween. CFI is considering it, so it means we agreed to test it. Testing an EIP on a devnet does not mean that it will get shipped, and should also not be used as argument, "it is being tested so it ships"
lightclient
i had always been under the assumption CFI is default do not ship
Potuz
Replying to "I think CFI -> defa..." I disagree strongly with that interpretation of CFI
Toni Wahrstätter
There should just never be a "weak" CFI
Ansgar Dietrichs
Replying to "Would be great if pe..." also Hubert I forgot to mention this again at the end of the segment: thank you very much to you and Chainsecurity for this work and bringing this to acd attention!
Luca Donno | L2BEAT
Reacted to "I disagree strongly with that interpretation of CFI" with 👍
Luca Donno | L2BEAT
Reacted to "i had always been under the assumption CFI is default do not ship" with 👍
spencer
7723 states this atm: "Considered for Inclusion signals that client developers intend to attempt to include the EIP in devnets." "Assuming it meets all the requirements for mainnet deployment it MAY be included in the network upgrade. This stage is similar to “concept ACK” in other open source projects, and is not sufficient to result in deployment to mainnet."
lightclient
should we have another stage? 😄
soispoke
A réagi à "There should just ..." avec 👍
Christine Kim
Reacted to "also Hubert I forgot to mention this again at the end of the segment: thank you very much to you and Chainsecurity for this work and bringing this to acd attention!" with 👏
spencer
Replying to "should we have ano..." TFI TFI!
wolovim
Replying to "I think CFI -> defa..." PFI -> CFI -> SCFI (seriously considered for inclusion) -> SFI (jk)
Barnabas
labor in 2026 is not the same as labor in 2024
spencer
Reacted to "should we have ano..." with 😅
lightclient
Replying to "should we have anoth..." what’s TFI?
Justin Florentine
Replying to "should we have anoth..." no we should stop abusing the existing definitions
Dustin
well this explains why so much random stuff gets CFI'd which turns out to be submarine jank
Nico
Reacted to "labor in 2026 is n..." with ➕
Iván | ethrex
Reacted to "PFI -> CFI -> SCFI (seriously considered for inclusion) -> SFI (jk)" with 🤝
Iván | ethrex
Reacted to "TFI TFI!" with 🤝
lightclient
Reacted to "labor in 2026 is not the same as labor in 2024" with ➕
Toni Wahrstätter
We could keep weak CFI's at PFI for longer instead of "CFI to explore more"
Justin Traglia
Semi-related. I consider the next (work-in-progress) upgrade specs to be a staging area for CFI’d features. Restricting us from merging EIPs into Heze specs will be annoying.
lightclient
Replying to "labor in 2026 is not..." whip.JPG hitting different
Justin Florentine
Replying to "labor in 2026 is not..." thats a meaningless distinction
Guru
I think we need a much higher barrier for CFI
soispoke
A réagi à "We could keep weak..." avec 👍
Justin Traglia
Reacted to "I think we need a much higher barrier for CFI" with 👍
lightclient
Reacted to "I think we need a much higher barrier for CFI" with 👍
soispoke
A réagi à "I think we need a ..." avec 👍
Luca Donno | L2BEAT
Reacted to "I think we need a much higher barrier for CFI" with 👍
Trent Van Epps
Reacted to "also Hubert I forgot to mention this again at the end of the segment: thank you very much to you and Chainsecurity for this work and bringing this to acd attention!" with 👏
spencer
Replying to "should we have ano..." testing for inclusion, I'd prefer we just clarify CFI better and increase the bar
spencer
Reacted to "labor in 2026 is n..." with ➕
spencer
Reacted to "whip.JPG hitting d..." with 😅
Trent Van Epps
Reacted to "I think CFI -> default ship it PFI -> default DFI it" with 👍
Francesco D'Amato
It’s ok for it to be a big decision, but then it can’t happen in 5 minutes at the end of a call like it sometimes does (one way or the other)
Toni Wahrstätter
Reacted to "I think we need a much higher barrier for CFI" with 👍
Ansgar Dietrichs
I agree it’s valuable to have shared understanding. my own take: “default” is weak / flexible enough: PFI = default no, but many obviously yes CFI = default yes, but should not slip to must yes SFI = we will ship this
Trent Van Epps
Reacted to "We could keep weak CFI's at PFI for longer instead of "CFI to explore more"" with 👍
Ansgar Dietrichs
Replying to "I agree it’s valuabl..." so CFI = the default flips, but it really is not a guarantee
Toni Wahrstätter
Replying to "I think we need a much higher barrier for CFI" consensus barrier though. Less requiring it to be run on a feature devnet or etc. My feeling is the problem are weak CFIs that end up being on a default-SFI lane
Justin Florentine
i'm all for accelerating but not by deleting entire segments of the process
Mario Vega
Reacted to "i'm all for accelerating but not by deleting entire segments of the process" with 👍
Ansgar Dietrichs
also, yes, my thinking is with AI this process will have to adjust, e.g. we will be able to do more prototyping / early testing even at PFI stage likely
lightclient
Replying to "I agree it’s valuabl..." i just don’t know how to have a serious conversation of CFI -> SFI with respect to “what should ethereum be doing"
Barnabas
Reacted to "I think we need a much higher barrier for CFI" with 👍
Justin Florentine
Replying to "also, yes, my thinki..." and it would be trivial for me to assert that AI adoption warrants ADDITIONAL phases instead of fewer.
Luis Pinto
Reacted to "and it would be trivial for me to assert that AI adoption warrants ADDITIONAL phases instead of fewer." with 💯
Csaba
From my pov, CFI should not mean all clients implement.
Luis Pinto
I think we got an example shown to us today that this is the case
Potuz
Replying to "From my pov, CFI sho..." The is the meaning of CFI
Potuz
Replying to "From my pov, CFI sho..." That was the reason it was created
Toni Wahrstätter
Hegota has been better than glam on that front already but still room to improve, esp clarifying PFI->CFI barriers
Barnabas
we might need an additional step for TFI testing for inclusion, which is targeting for the next devnet.
Justin Florentine
at least remove "considered" from the acronym if we're not going to have a decision point here
Justin Traglia
Reacted to "we might need an additional step for TFI testing for inclusion, which is targeting for the next devnet." with 👍
Ansgar Dietrichs
every change to ethereum is risk, but also value to users. e.g. scaling Ethereum might mean having to do some adjustments, but also 5x more people can benefit from Ethereum
Kevaundray Wedderburn
Replying to "we might need an add..." I actually think that in order to PFI something, there should be a prototype because once we CFI an EIP, then all clients/specs/testing will now need to expend resources
Barnabé Monnot
abstracting from the labels, there’s two decisions to make no? should all clients implement X? should it ship to mainnet? are there more decision points in the lifecycle of a proposal?
Justin Traglia
Reacted to "I actually think that in order to PFI something, there should be a prototype because once we CFI an EIP, then all clients/specs/testing will now need to expend resources" with 👍
Justin Traglia
Replying to "we might need an add..." Yes, either of those would be helpful.
Toni Wahrstätter
Replying to "we might need an additional step for TFI testing for inclusion, which is targeting for the next devnet." prototype shouldn't matter. it's too easy. I'd require broad consensus
Barnabas
Replying to "we might need an add..." define broad consensus
Toni Wahrstätter
Replying to "we might need an additional step for TFI testing for inclusion, which is targeting for the next devnet." prototype is one prompt away
lightclient
we kinda have this at the PFI -> CFI decision point fwiw
Luca Donno | L2BEAT
Reacted to "I actually think that in order to PFI something, there should be a prototype because once we CFI an EIP, then all clients/specs/testing will now need to expend resources" with 👍
Barnabas
Replying to "we might need an add..." we have 4cl and 3EL clients implemented shorter slots with heze, I would personally consider this as broad consensus, but others still don’t’ think so
Luca Donno | L2BEAT
Reacted to "prototype is one prompt away" with 👍
Guru
Reacted to "prototype is one pro..." with 👍
Toni Wahrstätter
Replying to "we might need an additional step for TFI testing for inclusion, which is targeting for the next devnet." no concerns by multiple client teams. We CFI'd such eips in hegota and propably shouldn't have
Christine Kim
Reacted to "we kinda have this at the PFI -> CFI decision point fwiw" with 👍
Guru
Reacted to "we kinda have this a..." with 👍
Toni Wahrstätter
Replying to "we might need an additional step for TFI testing for inclusion, which is targeting for the next devnet." implementing is is not consensus. What we discuss on ACD matters here. Implementing can also mean following others to not fall behind
Justin Florentine
since they are both headliners, combining them early is warranted; we're not planning on shipping without them both
Barnabas
I’m happy either way. I’d be interested to hear what EL devs that have implemented both focil and frames have in mind
Mario Vega
Reacted to "I’m happy either way. I’d be interested to hear what EL devs that have implemented both focil and frames have in mind" with 👍
lightclient
do ppl think we can have combined devnet by next week?
Justin Florentine
Replying to "do ppl think we can ..." dicey
Barnabas
Replying to "I’m happy either way..." I also wanna have a disagreement with shorter slots before we merge the devnets, but I’m confident we can get to a resolution about it on acdt
lightclient
from geth side, we could probably do it but it would be a bit of stretch
Mario Vega
Reacted to "from geth side, we could probably do it but it would be a bit of stretch" with 👍
Justin Florentine
Replying to "do ppl think we can ..." we're still getting focil into main, which is where we are combining
Justin Florentine
Reacted to "from geth side, we could probably do it but it would be a bit of stretch" with ➕
Ansgar Dietrichs
we could also go with bogota-devnet-2 for now, but already lock in that the next one will be merged
Mario Vega
Reacted to "we could also go with bogota-devnet-2 for now, but already lock in that the next one will be merged" with 👍
soispoke
A réagi à "we could also go w..." avec 👍
Toni Wahrstätter
having a devnet and talking about interactions is not exclusive
Toni Wahrstätter
let's do both
spencer
imo if we can have a combined devnet soon then lets prio that, otherwise on EL then bogota devnet 2
spencer
adding both would be too much on eels pre mumbai
Christine Kim
whats the point of the combined devnet if the interaction between the SFI'd eips wont be tested?
Ansgar Dietrichs
Replying to "imo if we can have a..." soon as in pre devcon?
Toni Wahrstätter
since focil is very much cross-layer, going to a combined devnet asap makes sense
Toni Wahrstätter
The interaction is only a small part of the FOCIL EL surface
soispoke
I think more attention on interactions is important, but I don't think a 1-2 weeks diff is that bad
Barnabas
I think we should ship what we can pre devcon
Jihoon
Do we know how to implement the interaction exactly?
Barnabas
if we can’t ship hegota devnet 0 with 3 clietns we should ship bogota-devnet-2
Jihoon
Cuz the proposed design is not mature enough AFAIK.
soispoke
if some people feel like they wouldn't make it by next week we can commit to a merged next one
Toni Wahrstätter
Replying to "Do we know how to implement the interaction exactly?" can we just not trigger interactions?
Jihoon
Replying to "Do we know how to im..." Then it's doable as I said.
Toni Wahrstätter
like, no frame txs in ILs, idk, more thinking out loud
Kevaundray Wedderburn
I think the complexity of an EIP should be factored into the decision to CFI it (ie before having all clients implement it). I don’t think its true that a prototype is one prompt away in general. See 8025 for example.
Jihoon
Reacted to "like, no frame txs in ILs, idk, more thinking out loud" with 👍
lightclient
are people okay with adding max_fee to bogota-devnet-2 ? https://github.com/ethereum/EIPs/pull/12414
Daniil Ankushin | Nethermind
Reacted to "are people okay with adding max_fee to bogota-devnet-2 ? https://github.com/ethereum/EIPs/pull/12414" with 👍
Potuz
Replying to "we might need an add..." then all clients/specs/testing will now need to expend resources This statement is almost all correct, but the point is that “all” is false, this is really my main grudge: CFI does not mean that all need to act on it, it explicitly was created to not mean this
spencer
also going overtime should we discuss what eips to add to bogota devnet 2?
lightclient
Reacted to "also going overtime should we discuss what eips to add bogota devnet 2?" with 👍
Daniil Ankushin | Nethermind
Reacted to "also going overtime should we discuss what eips to add bogota devnet 2?" with 👍
spencer
Reacted to "are people okay wi..." with 👍
lightclient
Replying to "also going overtime ..." SETCODEFROM and 8151 would be good from my POV
jochem-brouwer
eip-8253
Mario Vega
Reacted to "also going overtime should we discuss what eips to add to bogota devnet 2?" with 👍
Iván | ethrex
We did have a list cc @spencer do you have it still?
spencer
- EIP-8253: Bump nonce of zero-nonce storage accounts - EIP-4758: Deactivate SELFDESTRUCT - EIP-8298: SETCODEFROM Code Reuse Instruction - EIP-8151: Account Code Restricted ecRecover
Iván | ethrex
Reacted to "- EIP-8253: Bump nonce of zero-nonce storage accounts - EIP-4758: Deactivate SELFDESTRUCT - EIP-8298: SETCODEFROM Code Reuse Instruction EIP-8151: Account Code Restricted ecRecover" with 🙏
Daniil Ankushin | Nethermind
Reacted to "- EIP-8253: Bump nonce of zero-nonce storage accounts - EIP-4758: Deactivate SELFDESTRUCT - EIP-8298: SETCODEFROM Code Reuse Instruction EIP-8151: Account Code Restricted ecRecover" with 🙏
Daniil Ankushin | Nethermind
Reacted to "- EIP-8253: Bump nonce of zero-nonce storage accounts - EIP-4758: Deactivate SELFDESTRUCT - EIP-8298: SETCODEFROM Code Reuse Instruction EIP-8151: Account Code Restricted ecRecover" with 👍
Kevaundray Wedderburn
Replying to "we might need an add..." I think we should then clarify the CFI -> SFI process, because if only Prysm for example implements a CFId EIP, then its not clear to me how all other clients will be able to make an informed decision to SFI it
soispoke
Répondre à "- EIP-8253: Bump n..." not an EIP but would be great to test MATCHA and remove the 1 txn per sender limit of EIP-8141 to test multiple concurrent txns using EIP-8250
Iván | ethrex
Oh yeah, there was MATCHA too, +1 to that
Marc
Reacted to "- EIP-8253: Bump nonce of zero-nonce storage accounts - EIP-4758: Deactivate SELFDESTRUCT - EIP-8298: SETCODEFROM Code Reuse Instruction - EIP-8151: Account Code Restricted ecRecover" with 👍
Daniil Ankushin | Nethermind
Replying to "are people okay with..." sig lengths, 7906 w/o TXDIFF?
Toni Wahrstätter
Replying to "- EIP-8253: Bump nonce of zero-nonce storage accounts - EIP-4758: Deactivate SELFDESTRUCT - EIP-8298: SETCODEFROM Code Reuse Instruction - EIP-8151: Account Code Restricted ecRecover" yeah, the data metering/repricing might be fine to be delayed here
Marc
Reacted to "are people okay with adding max_fee to bogota-devnet-2 ? https://github.com/ethereum/EIPs/pull/12414" with 👍
Daniil Ankushin | Nethermind
Reacted to "Oh yeah, there was MATCHA too, +1 to that" with 👍
Daniil Ankushin | Nethermind
Reacted to "not an EIP but would be great to test MATCHA and remove the 1 txn per sender limit of EIP-8141 to test multiple concurrent txns using EIP-8250" with 👍
soispoke
FOCIL also has interactions with Frame add on EIPs like 8250 and 8272
Guru
Reacted to "FOCIL also has inter..." with 👍
danceratopz
Reacted to "- EIP-8253: Bump non..." with 🙏
Iván | ethrex
Sorry, what was the question again?
Barnabas
Replying to "Sorry, what was the ..." - EIP-8253: Bump nonce of zero-nonce storage accounts - EIP-4758: Deactivate SELFDESTRUCT - EIP-8298: SETCODEFROM Code Reuse Instruction - EIP-8151: Account Code Restricted ecRecover
Iván | ethrex
Replying to "Sorry, what was the ..." Yes 🚢
Barnabas
if we can get ethrex, geth, nethermind on we should ship it
Iván | ethrex
Reacted to "if we can get ethrex, geth, nethermind on we should ship it" with 🚢
Barnabas
we shouldn’t wait for the slowest client imo
Iván | ethrex
Replying to "if we can get ethrex..." 🫡
Barnabas
they can always be onboarded later
Daniil Ankushin | Nethermind
nethermind, geth, ethrex?
Barnabas
I feel like next ACD I’ll have to propose to make ACD calls 120min long from 90min 😂
spencer
Reacted to "I feel like next A..." with 😅
Toni Wahrstätter
Reacted to "I feel like next ACD I’ll have to propose to make ACD calls 120min long from 90min 😂" with 😅
lightclient
Reacted to "I feel like next ACD I’ll have to propose to make ACD calls 120min long from 90min 😂" with 😅
jochem-brouwer
Heeft gereageerd op "I feel like next A..." met 😂
Daniil Ankushin | Nethermind
Reacted to "I feel like next ACD I’ll have to propose to make ACD calls 120min long from 90min 😂" with 😅
lightclient
Replying to "I feel like next ACD..." we’re shipping so hard
Barnabas
Replying to "I feel like next ACD..." inflation hitting hard
Iván | ethrex
Reacted to "nethermind, geth, ethrex?" with 🤝
Daniil Ankushin | Nethermind
Reacted to "inflation hitting hard" with 😂
Pablo Deymo | Lambda
Reacted to "nethermind, geth, ethrex?" with 🤝
spencer
sgtm! also sorry for pushing but we I think can
jochem-brouwer
btw maybe good for all, in europe we have the dst thing, so my meetings are an hour earlier next week FYI
spencer
lol
Barnabas
@lightclient 🚢 stop heavy breathing 😂
Justin Florentine
this is not something we should be proud of, check your egos boys
stokes
Yeah cancel Devcon week
Barnabas
I won’t be able to make it to devcon, happy to meet with those that are staying home lol
lightclient
Replying to "@lightclient 🚢 stop..." im at altitude
lightclient
Replying to "@lightclient 🚢 stop..." air is thin
lightclient
Reacted to "I won’t be able to make it to devcon, happy to meet with those that are staying home lol" with 🚢
Mario Vega
Reacted to "Yeah cancel Devcon week" with 👍
jochem-brouwer
bye all :)
Barnabas
Reacted to "air is thin" with 😂

Call summary

Targets

•bogota-devnet-2 launch — week of October 27, 2026 - 01:37:39
•Next ACDE — ~November 19, 2026 (4 weeks out) - 01:46:51

Decisions

•Hoodi Glamsterdam hard fork canceled indefinitely; no new date set - 00:50:33
•Mainnet Glamsterdam fork date decision deferred until full impact analysis complete - 00:47:53
•ACDT extended from 60 to 90 minutes going forward - 01:13:58
•bogota-devnet-2 scoped to EIP-8253, EIP-4758, EIP-8298, EIP-8151; launching next week with Nethermind, Geth, ethrex - 01:37:39
•First merged EL+CL devnet (hegota-devnet-0) targets post-DevCon; FOCIL/frames interaction discussions to begin at DevCon - 01:38:11
•ACDE canceled in 2 weeks (DevCon week); next ACDE in 4 weeks - 01:46:51

Highlights

Hegota Devnet:
- ·bogota-devnet-2 (EL-only) to launch next week with Nethermind, Geth, ethrex; scope: EIP-8253, EIP-4758, EIP-8298 (SETCODEFROM), EIP-8151 - 01:37:39
- ·First post-DevCon devnet will be merged hegota-devnet-0 (EL+CL); FOCIL/frames interaction to be discussed in-person at DevCon - 01:38:11
- ·max_fee PR (EIPs/pull/12414) to be merged into bogota-devnet-2 after call if no objections raised - 01:38:40
Hegota Process:
- ·ACDT extended to 90 minutes going forward - 01:14:03
- ·Nixo's CFI priority ordering list adopted as working V1; living document, not binding - 01:17:25
- ·CFI vs SFI semantics debated: consensus that CFI ≠ guaranteed ship; desire to raise CFI bar and have explicit 'should Ethereum do this' discussion before SFI - 01:19:49
Glamsterdam Security:
- ·ChainSecurity found EIP-8037/8038 repricing allows previously-invalid txs to exploit contracts: gas refund recovery post-revert enables balance updates without ETH transfer - 00:14:11
- ·13 major DeFi projects identified as vulnerable; responsible disclosure ongoing; some unresponsive via bug bounty channels; search was not exhaustive - 00:22:45
- ·Key broken assumptions: gasleft() can now increase mid-call, OOG detection patterns bypassable, 1/64 retained gas now larger under higher costs - 00:21:12
- ·Three response tiers identified: (1) on-schedule mainnet if mitigated in time, (2) delayed mainnet same spec, (3) Glamsterdam spec changes — all contingent on full impact analysis - 00:28:02
Fork Status And Schedule:
- ·Hoodi hard fork canceled indefinitely; no new date set; EthPandaOps + client teams represent ~73% of Hoodi stake, rollback deemed feasible - 00:50:33
- ·Mainnet date implicitly on hold; December 2026 fork now very unlikely; 2027 expected - 00:47:53
- ·Blog post to go out immediately listing pre-Glamsterdam client versions; updated as new rollback releases ship; all clients encouraged to cut new releases - 00:59:09

Action Items

•EF / client teams - Publish blog post immediately announcing Hoodi fork cancellation; list rollback client versions; update as new releases ship - 00:59:09
•All EL and CL client teams - All client teams cut new releases unscheduling Hoodi fork - 01:00:53
•Fredrik / Francesco / Toni / Perry and security researchers - Present impact analysis findings and analysis timeline at ACDT next week - 01:01:31

Key decisions

Hoodi Glamsterdam hard fork canceled indefinitely; no new date set
UnknownFork cancelled with no rescheduled date
Mainnet Glamsterdam fork date decision deferred until full impact analysis complete
CFIFork date on hold pending impact analysis
ACDT extended from 60 to 90 minutes going forward
bogota-devnet-2 scoped to EIP-8253, EIP-4758, EIP-8298, EIP-8151; launching next week with Nethermind, Geth, ethrex
bogota-devnet-2Scope defined and launch scheduled for week of Oct 27 2026
First merged EL+CL devnet (hegota-devnet-0) targets post-DevCon; FOCIL/frames interaction discussions to begin at DevCon
hegota-devnet-0Post‑DevCon devnet planned, with FOCIL/frames discussion at DevCon
ACDE canceled in 2 weeks (DevCon week); next ACDE in 4 weeks
Schedule adjustment for upcoming ACDE meetings

EIPs discussed

EIP-4758 EIP-8151 EIP-8253 EIP-8298

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.