ACDE2026-09-24_246

AllCoreDevs - Execution #246

2026-09-24 7 decisions 694 transcript lines

Transcript

Follow along

soispoke
gm
Pooja Ranjan
gm
lightclient
gm
Radek | solidity
Hi all
jochem-brouwer
gm
marc | wolovim
agenda: https://github.com/ethereum/pm/issues/2223 (If shared above, not visible to late joiners like me :))
stokes
just waiting on client releases
Marius Van Der Wijden (M)
Geth also found a bug on devnet8 related to catchup full sync. Tldr. Cachting up to the head will be faster soon
Łukasz Rozmej
Nethermind 2.0 released
Stefan Starflinger
Reacted to "Geth also found a bu..." with 🔥
marek
Reacted to "Nethermind 2.0 relea..." with 🚀
Justin Florentine
ETA tomorrow
Marius Van Der Wijden (M)
Geth released
marc | wolovim
Reacted to "Nethermind 2.0 released" with 🚀
emma (reth)
Reth release coming next week
emma (reth)
Probs monday
Iván | ethrex
Ethrex will release today/tomorrow
Toni Wahrstätter
Reacted to Nethermind 2.0 relea... with "🚀"
Toni Wahrstätter
Reacted to Geth also found a bu... with "🔥"
Luca Donno | L2BEAT
Reacted to "Nethermind 2.0 released" with 🚀
Justin Traglia
https://github.com/eth-clients/sepolia/pull/130
Luca Donno | L2BEAT
Reacted to "Geth also found a bug on devnet8 related to catchup full sync. Tldr. Cachting up to the head will be faster soon" with 🔥
Iván | ethrex
Replying to "Ethrex will release ..." We have a release candidate that we are testing
potuz
Is it safe given what Pawel triggered on devnet 8?
Toni Wahrstätter
200M seems reasonable
Milos | enso.build
Reacted to "200M seems reasona..." with 👍
Stefan Starflinger
Reacted to "200M seems reasonabl..." with 👍
Parithosh Jayanthi
Reacted to "200M seems reasonable" with 👍
Maria Silva
From the benchmarking results so far, the 200M is looking safe
Toni Wahrstätter
Replying to "Is it safe given wha..." Is this something we're missing benchmark tests for?
Iván | ethrex
Reacted to "200M seems reasonabl..." with 👍
Csaba
I don’t think it is a good idea to do it immedate
Luca Donno | L2BEAT
Reacted to "200M seems reasonable" with 👍
Csaba
It mixes signals
Nico Flaig
how is 200M safe if we see ex-ante reorgs on devnet-8?
Toni Wahrstätter
Valid payloads that take that long, or invalid ones?
Maria Silva
Was this the tstore thing?
Ben Adams
jumpdst attack
Radek | solidity
paweł cannot join today.
Iván | ethrex
Reacted to "paweł cannot join to..." with 👍
nixo
which clients are struggling? all?
Csaba
benchmarks have no actual network
Toni Wahrstätter
Seems like next step should be to write benchmark tests for it and then set the gas limit based on that.
Justin Florentine
did we find a floor under this attack?
Stefan Starflinger
https://github.com/ethereum/execution-specs/pull/3637
Stefan Starflinger
this is what hes been testing afaik
Stefan Starflinger
or was it this? https://github.com/ethereum/execution-specs/pull/3631
potuz
@Maria Silva here’s the link https://discord.com/channels/595666850260713488/1552294799401553963
potuz
The contract is posted there
Satyajit
Is there a benchmark repo ?
potuz
Is JUMPDEST and Pawel said that the benchmark has changed
Nico Flaig
geth took 9 seconds to execute a block on my server too
Parithosh Jayanthi
8core 32gb ram machines
potuz
https://github.com/ethereum/execution-specs/pull/3631
potuz
That’s the repo
Satyajit
Reacted to "That’s the repo" with 👍
Toni Wahrstätter
Overprovisioned but we run multiple nodes on thoses machines, even for multiple different devnets?
Marius Van Der Wijden (M)
Replying to "geth took 9 seconds ..." At the head?
Ansgar Dietrichs
I think we need to be really precise about whether this is an isolated client issue or imply our confidence in test coverage was wrong generally and we should halt fork rollout.
Toni Wahrstätter
Replying to "geth took 9 seconds ..." Valid payload or invalid?
Nico Flaig
Replying to "geth took 9 seconds ..." yes I shared the slots on discord here https://discord.com/channels/595666850260713488/1552294799401553963
Parithosh Jayanthi
Replying to "Overprovisioned but we run multiple nodes on thoses machines, even for multiple different devnets?" No no, its just for one network and it has el+cl and some tooling
Toni Wahrstätter
Reacted to No no, its just for ... with "👍"
Nico Flaig
Replying to "geth took 9 seconds ..." the block was valid, next proposer got reorged because couldn't process the block in time
potuz
It wen’t on every client and on different nodes @Ansgar Dietrichs my MacBook Pro is quite potent and also took over 8 seconds with geth
Stefan Starflinger
Reacted to "No no, its just for ..." with 👍
Radek | solidity
Reacted to "It wen’t on every cl..." with 🍿
Marius Van Der Wijden (M)
Maybe 64kb contracts aren't safe after all...
potuz
Reacted to "Maybe 64kb contracts aren't safe after all..." with 😃
Parithosh Jayanthi
Reacted to "Maybe 64kb contracts aren't safe after all..." with 😃
Csaba
Reacted to "Maybe 64kb contracts aren't safe after all..." with 😃
jochem-brouwer
its create initcode, this should have been fixed long ago by initcode pricing
Iván | ethrex
Reacted to "Maybe 64kb contracts..." with 😃
Radek | solidity
Reacted to "Maybe 64kb contracts..." with 🍿
Stefan Starflinger
Reacted to "Maybe 64kb contracts..." with 🍿
Toni Wahrstätter
Replying to "geth took 9 seconds ..." Did the next proposer try to build on empty?
Luis Pinto
Reacted to "Maybe 64kb contracts aren't safe after all..." with 🍿
jochem-brouwer
Antwoord verzenden naar "its create initcod..." this eip https://eips.ethereum.org/EIPS/eip-3860
Toni Wahrstätter
Replying to "geth took 9 seconds ..." Or what does the proposer do if the payload of the most recent slot isn't executedin time?
Nico Flaig
Replying to "geth took 9 seconds ..." yes but failed and ptc votes full, so next proposer would be reorged, but reth just blew up completely and couldn't produce a block in time
Toni Wahrstätter
Reacted to Maybe 64kb contracts... with "🍿"
Milos | enso.build
agree should be set at fork, given all the costs increases would be ideal to have at least the 200m bump
Maria Silva
https://ethresear.ch/t/from-60m-to-200m-simulating-glamsterdam-s-fee-market/25957
Łukasz Rozmej
we are looking into optimizing for this scenario
Milos | enso.build
it should come with the fork
jochem-brouwer
Didnt Barnabas have an EIP for this?
Ansgar Dietrichs
I thought Maria’s argument was specifically that it should happen right at the fork
Csaba
I also don’t think it is a good idea to do it at the fork, or close to it
potuz
Oh wow
Parithosh Jayanthi
Yeah with repricing if we don’t increase it then we wont be able to do some actions post fork until increase right?
Milos | enso.build
Reacted to "Yeah with repricin..." with 👍
Maria Silva
right
felipe
Reacted to "Yeah with repricin..." with 👍
Stefan Starflinger
but then state heavy transactions that previously worked will fail if we don't do it at the fork
Stefan Starflinger
Reacted to "Yeah with repricing ..." with 👍
potuz
Anyway even if we hit it at the fork it’ll take some time right?
Stefan Starflinger
what pari said
Toni Wahrstätter
When we say "at the fork", we mean "start bumping it". It's not like we'd circumvent the 1/1024 rule
Dragan Rakita
Lets have a test, send it to benchmarkoor and see what is going on.
jochem-brouwer
Antwoord verzenden naar "Didnt Barnabas hav..." https://eips.ethereum.org/EIPS/eip-8261
Parithosh Jayanthi
Also the gas wont go up immediately, it’ll only trend upward
Ansgar Dietrichs
I will say I am still quite confused about this issue - at the stated values, it should already be an issue on mainnet today? (lower gas limit, but also lower processing time)
Milos | enso.build
to add on this, defi apps that leverage smart wallets and stuff like this will be a huge cost increase, if doesnt come with the gas bump is quite a hit
potuz
Replying to "I will say I am stil..." No, the problem is specific to Gloas
Suyash Shandilya
Replying to "I will say I am stil..." ^^
potuz
Replying to "I will say I am stil..." If you send a payload today that takes long to execute you reorg yourself
Ameziane Hamlat
Replying to "I will say I am stil..." This is accelerated with 64 KiB contracts
Maria Silva
Isn’t that the goal of the mainnet fork testing?
Ameziane Hamlat
This shows a clear under pricing of the attack use case, as all clients are having issues in processing the block in time.
nixo
Reacted to "Isn’t that the goal of the mainnet fork testing?" with 💯
Toni Wahrstätter
Bumping the gas limit by 1/1024 is something we've done before and shouldn't complicate the fork transition at all.
Toni Wahrstätter
The question is more, is 200M safe
Justin Traglia
Reacted to "Isn’t that the goal of the mainnet fork testing?" with 💯
Ben Adams
Reacted to "Isn’t that the goal of the mainnet fork testing?" with 💯
jochem-brouwer
Is Pawel on the call? This attack what I see linked is initcode jumpdest analysis, which is already priced 2 gas/word since EIP-3860. Is this the attack we are talking about?
Maria Silva
Replying to "This shows a clear u..." I am trying to understand how this is different from the jumpiest analysis tests we already had
Marius Van Der Wijden (M)
Yes, break the testnets
Ansgar Dietrichs
Replying to "Yes, break the testn..." I mean ideally not
Ansgar Dietrichs
Replying to "Yes, break the testn..." but better than breaking mainnet
Milos | enso.build
yes
Francesco D'Amato
Replying to "Is Pawel on the call..." (It was said before that he can’t be on the call)
jochem-brouwer
Heeft gereageerd op "(It was said befor..." met 👍
Ansgar Dietrichs
I’d be in favor of that, yes
jochem-brouwer
Antwoord verzenden naar "Is Pawel on the ca..." ah ok thanks
Toni Wahrstätter
Replying to "Is Pawel on the call..." Couldn't make it
Ben Adams
yes
CPerezz
Replying to "The question is more..." We’ve proven it is right? We just need to see that this mantained through time doesn’t actually worsen. Which we can’t see from benchmarks alone
Ben Adams
Reacted to "Yes, break the testnets" with 👍
Justin Traglia
Thanks!
felipe
Reacted to "Yes, break the tes..." with 👍
Suyash Shandilya
Reacted to "Yes, break the testn..." with 👍
Toni Wahrstätter
Replying to "The question is more..." I'm talking about this new attack here
Justin Traglia
Reacted to "Yes, break the testnets" with 👍
lightclient
I think Toni is OOO
Pb
Replying to "Is Pawel on the call..." Yes, but I can't talk right now. 2 was too give it any price per byte back then.
potuz
Replying to "The question is more..." I don’t think this is proven Carlos, if there are blocks that take 9-12 seconds to execute then we definitely benched incorrectly
Francesco D'Amato
Replying to "I think Toni is OOO" He is all over the chat 🤔
soispoke
A réagi à "He is all over the..." avec 👍
lightclient
Replying to "I think Toni is OOO" <3
potuz
Replying to "I think Toni is OOO" lol
Satyajit
Reacted to "I don’t think thi..." with 👍
nixo
Reacted to "He is all over the chat 🤔" with 😂
Justin Traglia
Reacted to "He is all over the chat 🤔" with 👍
Iván | ethrex
Reacted to "He is all over the c..." with 😂
jochem-brouwer
Heeft gereageerd op "He is all over the..." met 😂
Satyajit
Reacted to "He is all over the..." with 😂
felipe
Reacted to "He is all over the..." with 😂
nixo
Reacted to "I think Toni is OOO" with 🏇
Suyash Shandilya
Reacted to "He is all over the c..." with 😂
Toni Wahrstätter
@Nico Flaig has context too
Luca Donno | L2BEAT
Reacted to "He is all over the chat 🤔" with 😂
Dragan Rakita
Jumpdest analysis attack is needed to see what is going on. Would not exclude last minute change to gas (for jumptable creation) or contract size to mitigate it.
Ameziane Hamlat
Reacted to "Jumpdest analysis attack is needed to see what is going on. Would not exclude last minute change to gas or contract size to mitigate it." with 👍
potuz
Replying to "This shows a clear u..." Pawel said that the pricing changes had made the attack cheaper
jochem-brouwer
Antwoord verzenden naar "Is Pawel on the ca..." ok interesting, so 2 is too low?
Kevaundray Wedderburn
I think all questions are: Should EL window equals CL window? Should BAL window equal CL window? Should we reduce the CL window according to 8061? If changed, should we reduce the EL window to match?
felipe
Reacted to "I think all questi..." with ❤️
Kevaundray Wedderburn
Replying to "I think all question..." I think for (1) we said yep
jochem-brouwer
Antwoord verzenden naar "Is Pawel on the ca..." in retrospect this should already be in benchmarks, but i feel it already was, because i recall you opened a kind of this test pr a while ago (atleast half a year 🤔)
Iván | ethrex
Reacted to "I think for (1) we s..." with 👍
potuz
@Maria Silva this is Pawel’s comment: This is jumpdest analysis attack. The old benchmark was wrong so I updated it. Amsterdam makes it actually a bit easier because you can pre-pay the CREATE cost.
Enrico Del Fante
Replying to "I think all question..." WRT equality: yes!
Dragan Rakita
Replying to "This shows a clear u..." State gas allows creation of more contracts, I guess this means jumpdest analysis is underpriced (Big assumption).
Ameziane Hamlat
Replying to "This shows a clear u..." I thought personally some were the same (the one affecting besu), and he added the worst case for clients having different algorithm (random_stop_jumpdest_push1 for nethermind)
cayman
Replying to "I think all question..." first three especially yes
Maria Silva
Reacted to "@Maria Silva this is Pawel’s comment: This is jumpdest analysis attack. The old benchmark was wrong so I updated it. Amsterdam makes it actually a bit easier because you can pre-pay the CREATE cost." with 👍
potuz
Replying to "This shows a clear u..." Oh this is the thread I was looking for: This is jumpdest analysis attack. The old benchmark was wrong so I updated it. Amsterdam makes it actually a bit easier because you can pre-pay the CREATE cost.
Toni Wahrstätter
It's 3533 epochs
Pb
Replying to "Is Pawel on the call..." You increased limit 3x and didn't benchmark. How did it matter what was 5 years ago?
cayman
Replying to "I think all question..." for some context, rationale for (1) CL devs want BAL retention to match CL block retention so we can dedupe payloads from the CL side
Nico Flaig
https://github.com/ethereum/EIPs/pull/12347#issuecomment-5800873241 for rationale why we need (2)
jochem-brouwer
Antwoord verzenden naar "Is Pawel on the ca..." fair point
Enrico Del Fante
So you suggest that on CL side the envelop might have bals as optional?
Toni Wahrstätter
Agree with lukasz. Would love to understand when CLs would need such old BALs? Is it only for CL archieve nodes?
cayman
(3) just seems like a bugfix (so we should do it)
Enrico Del Fante
Replying to "So you suggest that ..." When serving payloads over RPC
jochem-brouwer
Heeft gereageerd op "@Maria Silva this ..." met 👍
Toni Wahrstätter
Replying to "So you suggest that ..." Or can CLs send payloads with blinded BALs to peers and peers accept that
Toni Wahrstätter
Can CLs send payloads with blinded BALs to peers and peers accept that?
Łukasz Rozmej
you need to be able to sync without BAL
cayman
Replying to "Can CLs send payload..." would require some decent changes to p2p. new containers, etc
Iván | ethrex
Reacted to "you need to be able ..." with 👍
Enrico Del Fante
Replying to "So you suggest that ..." That would be more complicated IMO
jochem-brouwer
Antwoord verzenden naar "Is Pawel on the ca..." thanks for the pr, the way it was benchmarked is indeed not optimized for glamsterdam
Łukasz Rozmej
nuke and sync at the top?
felipe
Reacted to "you need to be abl..." with 👍
cayman
Replying to "nuke and sync at the..." thats not the current behavioral contract we have tho :(
Toni Wahrstätter
Being offline for >2 weeks might need a fall-back to snap (instead of full sync) if the BALs are then unavailable. Not sure that's good enough. The alternative is extending the BAL retention window at the cost of needing more disk space.
Łukasz Rozmej
we need to check how fast we sync without BAL's
potuz
Why is no-one mentioning that if the EL does not keep them then anyway the CL will need to keep them, what’s the point of duplicating them then?
Toni Wahrstätter
Replying to "Why is no-one mentio..." Can you just keep the blinded one?
Toni Wahrstätter
Replying to "Why is no-one mentio..." ELs should keep them, not CLs
Justin Florentine
Reacted to "ELs should keep them, not CLs" with ➕
felipe
Reacted to "ELs should keep th..." with ➕
Enrico Del Fante
Reacted to "ELs should keep them, not CLs" with ➕
Justin Florentine
so min 4 weeks of duplication?
Toni Wahrstätter
I'm happy with extending the BAL retention window. How long would it need to be? ~33k epochs?
Nico Flaig
for reference https://github.com/ethereum/EIPs/pull/12347 explains all of this
potuz
loool
Toni Wahrstätter
The specs are overly conservative here. This is a lot of data we keep for....what?
nixo
dad joke
Justin Florentine
Honorary Dad
potuz
He was waiting the whole call to say that
nixo
Reacted to "He was waiting the whole call to say that" with 😂
Toni Wahrstätter
Reacted to He was waiting the w... with "😂"
felipe
Reacted to "He was waiting the..." with 😂
Toni Wahrstätter
Reacted to Honorary Dad with "😂"
Radek | solidity
Reacted to "He was waiting the w..." with 😂
Iván | ethrex
Reacted to "He was waiting the w..." with 😂
Marc
Reacted to "He was waiting the whole call to say that" with 😂
cayman
Reacted to "He was waiting the w..." with 😂
Pablo Deymo | Lambda
Reacted to "He was waiting the whole call to say that" with 😂
Nico Flaig
EL retention just needs to be longer than CL, you are free to retain data for longer
cayman
Reacted to "for reference https:..." with 👍
Mega | Lambda
Reacted to "He was waiting the whole call to say that" with 😂
cayman
Replying to "for reference https:..." summary here?
potuz
Every day I say “I told you so”… we should not have DFId 8237 that would make all these questions mute cause then I don’t care how long you keep the payloads/bals
Justin Florentine
we need worst case storage expectation
Toni Wahrstätter
Reacted to Every day I say “I t... with "👍"
Francesco Risitano (Tau)
Replying to "Every day I say “I t..." +1
Kevaundray Wedderburn
I think its a CL question?
Toni Wahrstätter
I'd not rush reducing it. Better sometime after gloas
Jihoon
Replying to "I think its a CL que..." It might also affect EL, isn't it?
Karim Taam
Replying to "I'd not rush reducin..." Also for PBT migration I think we need a big enough retention period
Toni Wahrstätter
Yeah it would work with 2 weeks, from what I heard from maria and carlos but longer rentention might make thinga simpler yeah
marc | wolovim
Client rankings: https://forkcast.org/upgrade/hegota/client-priority/?quick=el
Kevaundray Wedderburn
Replying to "I'd not rush reducin..." I would probably want to know what the storage requirements will be, assuming 2TB nodes
Ansgar Dietrichs
would it make sense to have screen shared to look at the EIPs in question?
nixo
https://eips.ethereum.org/EIPS/eip-8304
nixo
Replying to "would it make sense ..." oh ya sorry
Radek | solidity
Solidity opinion on 7979 https://ethereum-magicians.org/t/eip-7979-call-and-return-opcodes-for-the-evm/24615/35
Karim Taam
Replying to "I'd not rush reducin..." So maybe keep it like that and after Glamsterdam fork we will have more info regarding the size need for BALs
Toni Wahrstätter
Replying to "I'd not rush reducin..." At 200M, and 300kib BALs, and 33k epochs, 310 mib of storage
Łukasz Rozmej
I am for 8304 and 7979
Radek | solidity
Reacted to "I am for 8304 and 79..." with 👍
Karim Taam
Reacted to "At 200M, and 300kib BALs, and 33k epochs, 310 mib of storage " with 👍
cayman
Reacted to "I would probably wan..." with 👍
Toni Wahrstätter
Replying to "I'd not rush reducin..." But keeping that many BALs around feels overly conservative. CLs should deal with blinded BALs (e.g. make them optional in the payload).
Justin Florentine
besu team wants to hear from compiler teams
nixo
Reacted to "besu team wants to hear from compiler teams" with 👍
Kevaundray Wedderburn
Replying to "I'd not rush reducin..." 310mib?
Kevaundray Wedderburn
Replying to "I'd not rush reducin..." I might be missing something
Toni Wahrstätter
Replying to "I'd not rush reducin..." 33k*32 slots *300kib
Jihoon
Replying to "I'd not rush reducin..." What if we halven that period? Should CLs still be able to handle blinded BALs?
Toni Wahrstätter
Replying to "I'd not rush reducin..." Halven the CL retention? If so, I feel like "yes"
Toni Wahrstätter
Replying to "I'd not rush reducin..." But I haven't yet understood when CL clients ever need a 33k old payload, and why this would need to have the BAL.
Łukasz Rozmej
IMO potential gas optimizations can be figured out during implementation/benchmarking
Toni Wahrstätter
Replying to "I'd not rush reducin..." Like 33k epoch old payloads - fine, but why does it need the BAL. Simplest solution might be making the BAL optional in the payload?
jochem-brouwer
Antwoord verzenden naar "IMO potential gas ..." its an engineering opportunity at compiler side
Toni Wahrstätter
Replying to "I'd not rush reducin..." @Enrico Del Fante @potuz
Kevaundray Wedderburn
Replying to "I'd not rush reducin..." Hmm I thought it would be gib not mib
Luis Pinto
I am for 7979
Jihoon
Reacted to "Hmm I thought it would be gib not mib" with 👍
Toni Wahrstätter
Replying to "I'd not rush reducin..." Confused thousand-separator in my calculator yeah. It's 300 gib
Kevaundray Wedderburn
Reacted to "Confused thousand-separator in my calculator yeah. It's 300 gib" with 👍
Dragan Rakita
Reacted to "I am for 7979" with 👍
jochem-brouwer
Heeft gereageerd op "I am for 7979" met 👍
Iván | ethrex
For us is still DFI, not so strong DFI, so if majority wants to go for it it’s fine
Łukasz Rozmej
Nethermind is also open for an A grade
Ben Adams
Reacted to "Nethermind is also open for an A grade" with 👍
cayman
Replying to "I'd not rush reducin..." I doubt other CL devs would want to adjust p2p at this stage of the fork development? @Toni Wahrstätter
Łukasz Rozmej
Ethrex?
Łukasz Rozmej
They DFI'ed
Ansgar Dietrichs
I don’t think it’s a super strong CFI candidate still
potuz
In the Glamsterdam section I forgot to mention this, perhaps not critical for Sepolia, but I think we need this for Hoodi: a way for CL clients to blacklist all the P2P builders if the operator wanted. @nixo this does not need to be mentioned in the call, just posting here that other CL devs are around.
Ben Adams
I do :)
Dragan Rakita
It looks good to include it
Ben Adams
Replying to "I don’t think it’s a super strong CFI candidate still" I do :) dev UX
Ben Adams
Reacted to "It looks good to include it" with 👍
lightclient
CFI just means we are considering seriously to include it
lightclient
7979 definitely seems CFI
Dragan Rakita
Reacted to "7979 definitely seems CFI" with ➕
Łukasz Rozmej
CCFI (considered for consider for inclusion) then
jochem-brouwer
Heeft gereageerd op "7979 definitely se..." met ➕
Radek | solidity
Reacted to "7979 definitely seem..." with ➕
lightclient
Reacted to "CCFI (considered for consider for inclusion) then" with 🤣
jochem-brouwer
CFI
Greg K | Lido
Reacted to "CCFI (considered for consider for inclusion) then" with 😀
Fabio Di Fabio
Reacted to "CCFI (considered for consider for inclusion) then" with 😄
Toni Wahrstätter
Replying to "I'd not rush reducin..." Yeah I can see that. In which scenarios are CL clients sending around such old payloads, @cayman ? And what would they do with the BAL? Just store it, or pass it to the EL?
Dragan Rakita
Reacted to "CCFI (considered for consider for inclusion) then" with 🤣
Fabio Di Fabio
Reacted to "CFI" with 👍
Suyash Shandilya
Reacted to "7979 definitely seem..." with ➕
Łukasz Rozmej
Reacted to "CFI" with 👍
Radek | solidity
Solidity is for CFIed it
Marc
Reacted to "7979 definitely seems CFI" with ➕
lightclient
Reacted to "Solidity is for CFIed it" with ❤️
jochem-brouwer
Antwoord verzenden naar "CCFI (considered f..." CCCFI :D
Łukasz Rozmej
CFI and move forward!
felipe
seems green to CFI
Pooja Ranjan
Reacted to "Solidity is for CFIed it" with ❤️
Fabio Di Fabio
Reacted to "Solidity is for CFIed it" with 👍
Ben Adams
Reacted to "Solidity is for CFIed it" with ❤️
Suyash Shandilya
Reacted to "CCFI (considered for..." with 🤣
Ben Adams
Reacted to "Solidity is for CFIed it" with 👍
jochem-brouwer
Heeft gereageerd op "Solidity is for CF..." met ❤️
Fabio Di Fabio
Reacted to "CFI and move forward!" with 👍
Ben Adams
Reacted to "CFI and move forward!" with 👍
jochem-brouwer
Heeft gereageerd op "CFI and move forwa..." met 👍
felipe
Reacted to "7979 definitely se..." with ➕
Toni Wahrstätter
Reacted to CCFI (considered for... with "🤣"
jochem-brouwer
Heeft gereageerd op "seems green to CFI" met 🔥
Łukasz Rozmej
CFI is not SFI
Suyash Shandilya
Reacted to "CFI and move forward..." with 👍
Fabio Di Fabio
Reacted to "seems green to CFI" with 🔥
Toni Wahrstätter
Reacted to CFI and move forward... with "👍"
Lea Na
Reacted to "seems green to CFI" with 🔥
Justin Florentine
CFI from besu
Toni Wahrstätter
Reacted to seems green to CFI with "🔥"
Fabio Di Fabio
Reacted to "CFI from besu" with 👍
Dragan Rakita
Reacted to "CFI and move forward!" with 👍
cayman
Replying to "I'd not rush reducin..." afaik the purpose for the big retention window is to support finalizing-network syncing for nodes that have been offline
potuz
Replying to "I'd not rush reducin..." But I haven't yet understood when CL clients ever need a 33k old payload, and why this would need to have the BAL. Because we can’t sync blocks without the payloads and we can’t serve the payloads without the BALs…
felipe
Reacted to "CFI" with 👍
felipe
Reacted to "CFI and move forwa..." with 👍
Toni Wahrstätter
No need to have eips to reserve names, imo.
cayman
Replying to "I'd not rush reducin..." So serving old payloads would happen when peering with nodes who have been offline and are trying to forward sync w/o restarting from a recent checkpoint.
lightclient
Was there a post somewhere with the support from different parties?
potuz
Replying to "I'd not rush reducin..." Of course if we had 8237 then we wouldn’t care at all about any of this.
Łukasz Rozmej
I don't care much except the number of 1-byte opcodes is quickly reducing
cayman
Reacted to "Of course if we had ..." with 😃
Stefan Starflinger
Reacted to "seems green to CFI" with 🔥
lightclient
Reacted to "I don't care much except the number of 1-byte opcodes is quickly reducing" with ❤️
lightclient
Be friendly with others <3
Iván | ethrex
We left it TBD, now we can do a C for it
Radek | solidity
Reacted to "Be friendly with oth..." with ❤️
emma (reth)
Reacted to "Be friendly with others <3" with ❤️
Dragan Rakita
Reacted to "Be friendly with others <3" with ❤️
Kevaundray Wedderburn
Reacted to "Be friendly with others <3" with ❤️
Toni Wahrstätter
Replying to "I'd not rush reducin..." But at 33k epochs you're outside the wsp and would need a checkpoint anyway?
Lea Na
Reacted to "Be friendly with o..." with ❤️
Luis Pinto
We could possibly extend L1 to multi-byte opcodes with a reserved opcode too
cayman
Replying to "I'd not rush reducin..." yes, this is why the 33k should be adjusted w 8061
Milos | enso.build
https://eips.ethereum.org/EIPS/eip-8360
lightclient
I don’t really understand what the point of TCREATE is TBH. Why is initcode not sufficient?
Marius Van Der Wijden (M)
I'm against tcreate for hegota. I think the idea is okay, but it creates a lot of new codepaths that need to be tested for very little gain
Iván | ethrex
Reacted to "I'm against tstore f..." with 👍
cayman
Replying to "I'd not rush reducin..." keeping 33k just seems like a bug / oversight imo
Ben Adams
Replying to "I don’t really understand what the point of TCREATE is TBH. Why is initcode not sufficient?" initcode leaves contract behind without additionally using selfdestruct?
Maria Silva
Replying to "I'm against tstore f..." Do you mean tcreate?
Luis Pinto
Replying to "I'm against tstore f..." You mean tcreate
nixo
Replying to "I'm against tstore f..." maybe stupid question but tstore is part of this?
Marius Van Der Wijden (M)
Replying to "I'm against tstore f..." Lol tcreate
Marius Van Der Wijden (M)
Replying to "I'm against tstore f..." No its not @nixo
Iván | ethrex
Replying to "I'm against tstore f..." I agree with Marius here
nixo
Reacted to "No its not @nixo" with 🙏
felipe
Reacted to "Lol tcreate" with 😄
Jihoon
Replying to "I'd not rush reducin..." 33k was the worst case of WSP before 8061. You can read more here: https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md?plain=1#L2432 Set in this PR: https://github.com/ethereum/consensus-specs/pull/2131
jochem-brouwer
sstore behaves as tstore in tcreate contract
jochem-brouwer
Antwoord verzenden naar "I'm against tstore..." whoops meant to reply that here: sstore behaves as tstore in tcreate contract
potuz
Replying to "I'd not rush reducin..." I think it’s fine to reduce this to the WSP as long as EL devs are happy to reduce it this much
potuz
Replying to "I'd not rush reducin..." The point is that we should reduce it to the max of the two layers
Milos | enso.build
Reacted to "sstore behaves as ..." with 👍
Kevaundray Wedderburn
Reacted to "The point is that we should reduce it to the max of the two layers" with 👍
potuz
Replying to "I'd not rush reducin..." On the CL we do not need anything beyond the WSP IMO
cayman
Reacted to "The point is that we..." with 👍
Luis Pinto
PAY like opcode isn’t covered either
Toni Wahrstätter
Reacted to 33k was the worst ca... with "🙏"
Toni Wahrstätter
Reacted to The point is that we... with "👍"
Helkomine
It can be banned if you want to keep things simple
Toni Wahrstätter
Replying to "I'd not rush reducin..." On the EL too. Starting fresh snap snyc is prpbably faster than re-exrcuting weeks of blocks.
Dragan Rakita
Gas cost is higher
Milos | enso.build
Reacted to "It can be banned i..." with 👍
Marius Van Der Wijden (M)
We should not spend time on these microdecisions for a few people to save a few wei
Luis Pinto
But the question about what you do in the interim between Glam - Heg is still relevant
CPerezz
Reacted to "I would probably wan..." with 👍
Iván | ethrex
Reacted to "We should not spend ..." with 👍
Milos | enso.build
It's not a few wei
Helkomine
Reacted to "It's not a few wei" with 👍
Milos | enso.build
and it's not a microdecision lol
Pablo Deymo | Lambda
Reacted to "We should not spend time on these microdecisions for a few people to save a few wei" with 💰
CPerezz
Reacted to "Of course if we had ..." with 😂
Helkomine
Reacted to "and it's not a mic..." with 👍
Toni Wahrstätter
Both are small changes and require us to be flexible. I'd even CFI them - cleaner
Ansgar Dietrichs
my only concern on state diff is that it is the kind of EIP with a lot of nuanced edge cases that only show up during implementation
lightclient
🚢
Ansgar Dietrichs
Replying to "my only concern on s..." but seems worth it
Toni Wahrstätter
Reacted to 🚢 with "🚀"
potuz
+1 assertions will make my heart not pump up when using the chain
Iván | ethrex
Reacted to "🚢" with 🚀
Iván | ethrex
Reacted to "🚢" with 🚢
Suyash Shandilya
Reacted to "🚢" with 🚢
Toni Wahrstätter
Replying to "+1 assertions will m..." A bit of pump isn't too bad
jochem-brouwer
Heeft gereageerd op "A bit of pump isn'..." met ⛽
potuz
Replying to "+1 assertions will m..." Agreed, my Belly is the worst it’s been in 20 years, need to go back to a healthier life
Toni Wahrstätter
Reacted to Agreed, my Belly is ... with "🙏"
lightclient
🚢
Iván | ethrex
Reacted to "🚢" with 🚢
soispoke
A réagi à "🚢" avec 🔥
felipe
Reacted to "A bit of pump isn'..." with ⛽
soispoke
A réagi à "🚢" avec 🚢
Marius Van Der Wijden (M)
Replying to "and it's not a micro..." In the great scheme of things this will not make or break ethereum. What will do that are the big features: Frames, Focil, PQ, ... everything else are distractions
Justin Florentine
CLEAN YOUR ROOM
Ben Adams
Reacted to "CLEAN YOUR ROOM" with 🔥
Milos | enso.build
Replying to "We should not spen..." I'd reccomend to dig a bit deeper
Helkomine
Replying to "my only concern on..." I previously wrote an EIP with a similar idea, but the approach there was for the parent frame to establish the scope of state changes for the child frame upfront
Kevaundray Wedderburn
Replying to "I'd not rush reducin..." One concern that did come up was the fact that folks want to use the large window in periods of non-finality. To me, I think we should not prune non-finalised blocks to decouple the two scenarios
Parithosh Jayanthi
Reacted to "A bit of pump isn't too bad" with ⛽
Dragan Rakita
This is one of those two gas EIPs
Parithosh Jayanthi
Reacted to "Agreed, my Belly is the worst it’s been in 20 years, need to go back to a healthier life" with 🙏
Parithosh Jayanthi
Reacted to "CLEAN YOUR ROOM" with 🔥
Lea Na
Reacted to "🚢" with 🚢
jochem-brouwer
this is the eip-7610 replacement
Justin Florentine
EAT YOUR VEGETABLES
cayman
Reacted to "One concern that did..." with 👍
jochem-brouwer
Heeft gereageerd op "CLEAN YOUR ROOM" met ➕
Ben Adams
Reacted to "EAT YOUR VEGETABLES" with 😅
Milos | enso.build
Replying to "and it's not a mic..." lol
Łukasz Rozmej
KILL REFUNDS!
Iván | ethrex
We are ok on doing it
jochem-brouwer
Heeft gereageerd op "EAT YOUR VEGETABLES" met 🥦
Stefan Starflinger
Reacted to "KILL REFUNDS!" with 👍
Iván | ethrex
Reacted to "EAT YOUR VEGETABLES" with 🥦
jochem-brouwer
Heeft gereageerd op "KILL REFUNDS!" met ⛽
Dragan Rakita
Reacted to "KILL REFUNDS!" with ⛽
lightclient
Reacted to "KILL REFUNDS!" with 👍
Ben Adams
Reacted to "KILL REFUNDS!" with 👍
Luis Pinto
Reacted to "KILL REFUNDS!" with ⚰️
Ben Adams
Reacted to "KILL REFUNDS!" with ⛽
Ben Adams
Reacted to "KILL REFUNDS!" with ⚰️
Milos | enso.build
Replying to "and it's not a mic..." sorry big brain
Iván | ethrex
Reacted to "KILL REFUNDS!" with 🔥
CPerezz
Reacted to "KILL REFUNDS!" with 👍
Ansgar Dietrichs
lol yes I was really worried when we only started with scoping halfway through the call and now we are just breezing through these
emma (reth)
Reacted to "KILL REFUNDS!" with ⛽
Łukasz Rozmej
Reacted to "lol yes I was really worried when we only started with scoping halfway through the call and now we are just breezing through these" with 👍
Suyash Shandilya
Reacted to "lol yes I was really..." with 👍
jochem-brouwer
Heeft gereageerd op "lol yes I was real..." met 🌊
Dragan Rakita
Reacted to "lol yes I was really worried when we only started with scoping halfway through the call and now we are just breezing through these" with 🌊
Helkomine
Replying to "and it's not a mic..." state left the chat lol
lightclient
Reacted to "lol yes I was really worried when we only started with scoping halfway through the call and now we are just breezing through these" with 🌊
emma (reth)
Reacted to "lol yes I was really worried when we only started with scoping halfway through the call and now we are just breezing through these" with 🌊
CPerezz
For SETCODEFROM. Here’s some help digesting it: https://cperezz.github.io/articles/setcodefrom-account-modes/
Milos | enso.build
Replying to "and it's not a mic..." there's actual people building actual product on ethereum, if you don't understand one of the most basic use cases and feature that ethereum offers is a skill issue
Ansgar Dietrichs
maybe if we wanted to we could talk about the other Toni data pricing EIP? because we just CFI’d the other
lightclient
SETCODEFROM is important
Ben Adams
Reacted to "SETCODEFROM is important" with 💯
Iván | ethrex
Reacted to "For SETCODEFROM. Her..." with 🙏
marc | wolovim
Sense-check this: CFI - EIP-3298: Remove storage-clear refund and refund cap - EIP-7668: Remove bloom filters - EIP-7906: Transaction Assertions via State Diff Opcode - EIP-7979: Call and Return Opcodes for the EVM - EIP-8131: Unified Transaction Content Floor - EIP-8163: Reserve `EXTENSION (0xae)` opcode - EIP-8250: Keyed Nonces for Frame Transactions - EIP-8253: Bump nonce of zero-nonce storage accounts - EIP-8272: Recent Roots for Frame Transactions - EIP-8368: CPSB Recalibration - EIP-8372: Normalized state gas limit Deferred - EIP-8360: TCREATE Opcode
Ansgar Dietrichs
Replying to "maybe if we wanted t..." I personally think we should CFI both
CPerezz
Reacted to "SETCODEFROM is impor..." with 💯
Christine Kim
Replying to "Sense-check this: CFI - EIP-3298: Remove storage-clear refund and refund cap - EIP-7668: Remove bloom filters - EIP-7906: Transaction Assertions via State Diff Opcode - EIP-7979: Call and Return Opcodes for the EVM - EIP-8131: Unified Transaction Content Floor - EIP-8163: Reserve `EXTENSION (0xae)` opcode - EIP-8250: Keyed Nonces for Frame Transactions - EIP-8253: Bump nonce of zero-nonce storage accounts - EIP-8272: Recent Roots for Frame Transactions Deferred - EIP-8360: TCREATE Opcode" https://docs.google.com/spreadsheets/d/1UVm9UurwCMWrtLAM7aKvMjdeMtZYSsm7ay8AMwo52AE/edit?usp=sharing
Toni Wahrstätter
Yeah the two data repricings should be done in a bundle
Francesco Risitano (Tau)
Could bloom filters be useful in a zkEVM + BiB + VOPS world to signal to a VOPS node which transactions / bals to fetch to maintain the tx pool. Similar arguments for a light client for a dap.
Toni Wahrstätter
The 2nd one is more complex, at least at first glance
Helkomine
Replying to "SETCODEFROM is imp..." no, 8058
Kevaundray Wedderburn
If we have time, it would be good to get a temp check on 8298 (SETCODEFROM) There was an async thread on this last week
Marius Van Der Wijden (M)
Replying to "and it's not a micro..." Lol no need to start name calling
CPerezz
Replying to "SETCODEFROM is impor..." 8058 is superset by SETCODEFROM
Łukasz Rozmej
Reacted to "If we have time, it would be good to get a temp check on 8298 (SETCODEFROM) There was an async thread on this last week" with 👍
CPerezz
Replying to "SETCODEFROM is impor..." And I’m the author lol So I guarantee this is the case
CPerezz
Reacted to "If we have time, it ..." with 👍
Kevaundray Wedderburn
Replying to "If we have time, it ..." Ah didn’t see lightclient’s message due to zoom ui
Ansgar Dietrichs
Replying to "SETCODEFROM is impor..." I’d personally appreciate 2 more weeks though, there is some nuance around best approach imo
Iván | ethrex
Reacted to "SETCODEFROM is impor..." with 💯
Nico
Did we also discuss 8151 already ?
CPerezz
https://cperezz.github.io/articles/setcodefrom-account-modes/
Milos | enso.build
Replying to "and it's not a mic..." dind't meant to
Nico
Reacted to If we have time, it ... with "👍"
Helkomine
Replying to "SETCODEFROM is imp..." However, Uniswap factory contracts do not qualify for this benefit.
CPerezz
Replying to "If we have time, it ..." Happy to chat with teams about SETCODEFROM. @Dragan Rakita specially since you marked as DFI
CPerezz
Replying to "Did we also discuss ..." It’s discussed in the link I sent too
Ansgar Dietrichs
I think SETCODEFROM is important in principle, but there are some use cases it doesn’t ideally support (e.g. deploying copies of existing contracts cheaply). I would appreciate 2 weeks to just explore whether there are any variants of it that would fulfil the same purpose but cover these other use cases more effectively. also fine to CFI today though and do this after
CPerezz
Replying to "Did we also discuss ..." I think SETCODEFROM can just superset it? But would be nice to get your take
nixo
Replying to "Did we also discuss ..." no, no discussion or decision on 8151 today
CPerezz
Replying to "I think SETCODEFROM ..." It does support the deployment after the latest PR
CPerezz
Replying to "I think SETCODEFROM ..." Since we allowed execution in Initcode
lightclient
Reacted to "Since we allowed execution in Initcode" with ❤️
Iván | ethrex
We’d like SETCODEFROM CFI’d
Ansgar Dietrichs
Replying to "I think SETCODEFROM ..." ah, right, sorry about that then
Ansgar Dietrichs
Replying to "I think SETCODEFROM ..." I guess point stands for me personally then, time to catch up, but if everyone else is up to date and can make decision today, fine to go ahead imo
Helkomine
Replying to "SETCODEFROM is imp..." What I mean is that it only allows new contracts to receive a discount, whereas existing ones do not.
Łukasz Rozmej
Reacted to "SETCODEFROM is important" with 💯
Helkomine
Replying to "KILL REFUNDS!" move to REFILL
CPerezz
Replying to "SETCODEFROM is impor..." Uniswap factory wouldn’t apply neither for 8058 then. AS byte code needs to be identical
Ansgar Dietrichs
Replying to "SETCODEFROM is impor..." we can also CFI to day and still explore whether we should switch to a different variant afterwards
Ben Adams
Replying to "SETCODEFROM is important" Yes is unfortunate doesn't apply to existing ones, would have to be new ones but cannot do it existing ones safely
Ansgar Dietrichs
sounds like we are ready to CFI today then
Iván | ethrex
Reacted to "sounds like we are r..." with 👍
Ben Adams
Reacted to "sounds like we are ready to CFI today then" with 👍
soispoke
A réagi à "sounds like we are..." avec 👍
Nico
Reacted to sounds like we are r... with "👍"
CPerezz
Reacted to "sounds like we are r..." with 👍
Marc
Reacted to "sounds like we are ready to CFI today then" with 👍
CPerezz
SHIP SETCODEFROM
Iván | ethrex
Reacted to "SHIP SETCODEFROM" with 🚢
jochem-brouwer
Heeft gereageerd op "SHIP SETCODEFROM" met 🌊
Ben Adams
Replying to "SETCODEFROM is important" but 99% of contracts are dupes
jochem-brouwer
Heeft gereageerd op "SHIP SETCODEFROM" met 🚢
Łukasz Rozmej
finally some beef on next ACDE with controversial EIPs, those last ones were too easy
potuz
What happened to EL devs? It used to be a lot of fighting and everything getting DFId… now you guys CFI like 20 EIPs in 30 minutes… we’ll have to take the lead in the CL side then
nixo
Reacted to "finally some beef on next ACDE with controversial EIPs, those last ones were too easy" with 😂
felipe
Reacted to "What happened to E..." with 😂
jochem-brouwer
Heeft gereageerd op "What happened to E..." met 😜
CPerezz
Please, if any team wants to learn more or has questions, ping me!! I’m happy to help
Suyash Shandilya
Reacted to "finally some beef on..." with 😂
nixo
Reacted to "What happened to EL devs? It used to be a lot of fighting and everything getting DFId… now you guys CFI like 20 EIPs in 30 minutes… we’ll have to take the lead in the CL side then" with 😂
Łukasz Rozmej
Replying to "What happened to EL devs? It used to be a lot of fighting and everything getting DFId… now you guys CFI like 20 EIPs in 30 minutes… we’ll have to take the lead in the CL side then" on next episode of ACDE....
soispoke
A réagi à "finally some beef ..." avec 😂
jochem-brouwer
Antwoord verzenden naar "What happened to E..." lets scope I* in 2 calls :P
Helkomine
Replying to "SETCODEFROM is imp..." I mean, the code for the sub-contracts it deploys is identical; EIP-8037 would drive this cost up massively without a discount—at the very least, versions 8058 and 8298 should be able to coexist.
nixo
Reacted to "lets scope I* in 2 calls :P" with 😅
felipe
Reacted to "Please, if any tea..." with ❤️
potuz
Reacted to "lets scope I* in 2 calls :P" with 😅
Suyash Shandilya
Reacted to "What happened to EL ..." with 😂
Nico
Reacted to Please, if any team ... with "❤️"
Nico
Reacted to SETCODEFROM is impor... with "💯"
jochem-brouwer
Heeft gereageerd op "Please, if any tea..." met ❤️
Justin Florentine
Replying to "What happened to EL ..." because if we don't fill the fork you will
jochem-brouwer
Heeft gereageerd op "What happened to E..." met 😂
Milos | enso.build
Reacted to "Please, if any tea..." with ❤️
Luis Pinto
Am I right in assuming then that Frames no longer solely control the account after you have done a SETCODEFROM?
Suyash Shandilya
Reacted to "because if we don't ..." with 😄
potuz
Replying to "What happened to EL ..." Let’s bring Peter back
Iván | ethrex
Reacted to "lets scope I* in 2 c..." with 🚢
Łukasz Rozmej
Replying to "What happened to EL devs? It used to be a lot of fighting and everything getting DFId… now you guys CFI like 20 EIPs in 30 minutes… we’ll have to take the lead in the CL side then" in the end we will still wait for CL's with implementation, so we can take more :P
CPerezz
Replying to "Am I right in assumi..." If you do SETCODEFROM, you have a smart account. At this point, code controls it
Toni Wahrstätter
Reacted to What happened to EL ... with "🎅"
potuz
Replying to "What happened to EL ..." touche
Marius Van Der Wijden (M)
Oh iirc the codehash - code db is different between geth nodes
Justin Florentine
Replying to "What happened to EL ..." there, i fillibustered, happy?
Łukasz Rozmej
Reacted to "Let’s bring Peter back" with 👍
CPerezz
Replying to "Am I right in assumi..." Frames are another thing that just allows you to still have ECDSA access for example
Marius Van Der Wijden (M)
Replying to "Oh iirc the codehash..." Depending on when they were synced
CPerezz
Replying to "Oh iirc the codehash..." Only the ones that full-sync vs. snapsync
Ansgar Dietrichs
anything specific we should discuss regarding how to prepare for the next call?
Nico
Replying to "Did we also discuss ..." Ah thanks
lightclient
woohoo!
Lea Na
Reacted to "because if we don'..." with 😄
Nico
Replying to "Did we also discuss ..." Looks interesting
lightclient
Nice job nixo
Iván | ethrex
Thanks!
lightclient
Nix!

Call summary

Targets

•Sepolia Glamsterdam fork — October 6, 2026 - 00:13:04
•Client releases for Sepolia fork — Monday September 29, 2026 - 00:13:25

Decisions

•200M gas limit signaled at Glamsterdam fork for Sepolia (not phased; starts trending up via 1/1024 voting post-fork) - 00:30:08
•CL block retention window reduction is not a hard fork change and not blocking Gloas; to be resolved async - 00:46:53
•DFI for Hegota: EIP-8304 (Trustless Log Index) - 00:49:54
•CFI for Hegota: EIP-7979 (Call and Return Opcodes for EVM) - 01:02:43
•CFI for Hegota: EIP-8163 (Reserve EXTENSION 0xae opcode) - 01:05:57
•EIP-8368 and EIP-8372 remain PFI pending mainnet Glamsterdam data (≥30 days post-fork) - 01:16:57
•CFI for Hegota: EIP-7906, EIP-8250, EIP-8272, EIP-7668, EIP-8253, EIP-3298, EIP-8131, and BAL byte floor EIP (bundled with EIP-8131) - 01:18:04

Highlights

Eip Proposals Hegota:
- ·EIP-8304 (Trustless Log Index): DFI for Hegota; author will continue work independently - 00:48:22
- ·EIP-7979 (Call and Return Opcodes for EVM): CFI — Solidity confirmed support, Nethermind/Besu/Nethermind upgraded ratings; ethrex soft DFI but non-blocking - 01:01:27
- ·EIP-8163 (Reserve EXTENSION 0xae opcode): CFI — low-cost no-op on L1; Arbitrum Nitro, Tron, Rootstock demand cited - 01:05:17
- ·EIP-8360 (TCREATE opcode): deferred — Glamsterdam removes gas refunds for ephemeral contracts; decision linked to self-destruct deprecation discussion - 01:09:43
- ·EIP-8368 and EIP-8372: remain PFI pending ≥30 days of mainnet Glamsterdam data before decision - 01:16:13
- ·CFI batch: EIP-7906 (State Diff Assertions), EIP-8250 (Keyed Nonces/Frames), EIP-8272 (Recent Roots/Frames), EIP-7668 (Remove Bloom Filters), EIP-8253 (Bump Zero-Nonce Storage Accounts), EIP-3298 (Remove Storage Refunds), EIP-8131 (Unified Tx Content Floor) - 01:18:04
- ·EIP-8131 (Unified Tx Content Floor) and BAL block access list byte floor EIP CFI'd as a bundle — pricing all payload bytes at floor requires both together - 01:25:47
- ·EIP-8298 (SETCODEFROM): strong CFI interest from most clients; Besu wants 2 more weeks; punted to next call - 01:28:23
Glamsterdam Gas Limit:
- ·JUMPDEST analysis attack via pre-deployed contract triggers valid blocks taking 8–13s to execute across all clients on glamsterdam-devnet-8 - 00:15:31
- ·Maria: state creation gas increase (EIP-8037) makes <150M gas limit dangerous — some txs require ~90M gas alone, risking base fee volatility - 00:21:00
- ·Ansgar: testnets should stress-test aggressively; being gentle on Sepolia risks mainnet surprises - 00:29:32
Fork Status And Schedule:
- ·Gloas fork transition tested successfully with Lido and Optimism; devnet torn down - 00:11:55
- ·Besu investigating performance issue on glamsterdam-devnet-8; improvements in progress - 00:12:41
- ·Sepolia fork confirmed October 6th; client releases due by Monday September 29th. Nethermind released, Geth released, Besu ETA tomorrow, Reth next week, ethrex today/tomorrow - 00:13:04
- ·200M gas limit at Glamsterdam fork approved for Sepolia; JUMPDEST attack causes 9–13s block execution times — reorg risk identified but deemed expensive/non-persistent - 00:30:08
Cl Block Retention Window:
- ·EIP-8061 changed exit/consolidation churn but block retention window wasn't updated; needs alignment. Related: EIP-8383 (Hegota PFI) would reduce it further - 00:31:53
- ·BAL retention window should equal CL block retention window; current CL window ~5 months (33k epochs), EIP-8061 would halve it to ~2 months (14k epochs) - 00:35:16
- ·Marius: too-short blob retention makes full sync impossible as sequential block execution exceeds slot time at higher gas limits - 00:38:32
- ·Potuz: if EL doesn't keep payloads/BALs, CL must — duplicating data; EL must keep at minimum what CL requires - 00:41:42

Action Items

•Kevaundray, Jihoon, or Toni - Open ETH R&D Discord thread to align on CL block retention window reduction and BAL window alignment; not blocking for Gloas - 00:45:30
•Milos, all EL client teams - EIP-8360 champion (Milos) to engage clients; clients to review before next call for decision alongside self-destruct deprecation - 01:10:44
•nixo - nixo to post list of remaining ~10 Hegota EIPs (incl. EIP-8298) to ExecutionDev and EthRD channels before next call - 01:36:38

Key decisions

200M gas limit signaled at Glamsterdam fork for Sepolia (not phased; starts trending up via 1/1024 voting post-fork)
Sets gas limit for Sepolia Glamsterdam fork
CL block retention window reduction is not a hard fork change and not blocking Gloas; to be resolved async
Retention window change handled off-chain
DFI for Hegota: EIP-8304 (Trustless Log Index)
Deferred implementation of Trustless Log Index
CFI for Hegota: EIP-7979 (Call and Return Opcodes for EVM)
Client feature implementation approved
CFI for Hegota: EIP-8163 (Reserve EXTENSION 0xae opcode)
Client feature implementation approved
EIP-8368 and EIP-8372 remain PFI pending mainnet Glamsterdam data (≥30 days post-fork)
Pending further information
CFI for Hegota: EIP-7906, EIP-8250, EIP-8272, EIP-7668, EIP-8253, EIP-3298, EIP-8131, and BAL byte floor EIP (bundled with EIP-8131)
Bundle of client feature implementations

EIPs discussed

EIP-3298 EIP-7668 EIP-7906 EIP-7979 EIP-8131 EIP-8163 EIP-8250 EIP-8253 EIP-8272 EIP-8304 EIP-8368 EIP-8372

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.