ACDE2026-08-13_243

AllCoreDevs - Execution #243

2026-08-13 6 decisions 683 transcript lines

Transcript

Follow along

Stefan Starflinger
Hello
jochem-brouwer
gm
Justin Traglia
Gm
Pooja Ranjan
gm
nixo
gm!
Louis
gm
Lumi | Offchain Labs
Gm
spencer
Exciting call! :)
Lumi | Offchain Labs
Reacted to "Exciting call! :)" with 💯
danceratopz
Reacted to "Exciting call! :)" with 💯
nixo
https://forkcast.org/devnets/glamsterdam-devnet-8/
Miguel Tenorio
Faucet for devnet 8?
Barnabas
https://faucet.plataberget.ethpandaops.io
Parithosh Jayanthi
Blogpost will go live soon, waiting for a few things to settle down
Miguel Tenorio
Reacted to "https://faucet.plataberget.ethpandaops.io" with 👍
Derek Chiang
@nixo is the plan to discuss Frames/AA last after going over all the PFIs?
nixo
Replying to "@nixo is the plan to..." yep
Louis
you forget to thank yourself, Jochem
Trent Van Epps
Thank you everyone for grinding on this for so long!
Derek Chiang | Ethlabs
Reacted to "yep" with ❤️
nixo
Reacted to "you forget to thank yourself, Jochem" with 😁
Barnabas
Replying to "Screenshot2026_08_13_160600.jpg" oh I wasn’t on the list 😂
Lumi | Offchain Labs
Reacted to "oh I wasn’t on the list 😂" with 😂
nixo
Reacted to "oh I wasn’t on the list 😂" with 😂
Pooja Ranjan
Reacted to "oh I wasn’t on the list 😂" with 😂
Kevaundray Wedderburn
Reacted to "oh I wasn’t on the list 😂" with 😂
Mehdi Aouadi
Reacted to "oh I wasn’t on the list 😂" with 😂
wolovim
Reacted to "oh I wasn’t on the list 😂" with 😂
marek
Reacted to "oh I wasn’t on the l..." with 😂
Marius Van Der Wijden (M)
Reacted to Thank you everyone f... with "👍"
Ben Edgington
Reacted to "oh I wasn’t on the list 😂" with 😂
Justin Traglia
For builders that want to be onboarded at the fork, keep in mind the following note: *Note*: Builders may be onboarded at the fork by submitting a deposit to the validator deposit contract with a `BUILDER_WITHDRAWAL_PREFIX` withdrawal credential. This must be done late enough that the deposit is still pending at the fork, but early enough that the slot in which the deposit is added to the pending deposit queue is finalized so that the builder is considered active. Such a deposit signs over `DepositMessage` under `DOMAIN_DEPOSIT`, with withdrawal credentials of the form `BUILDER_WITHDRAWAL_PREFIX + b"\x00" * 11 + execution_address`.
Nico Flaig
Reacted to "oh I wasn’t on the l..." with 😂
Parithosh Jayanthi
Reacted to "oh I wasn’t on the list 😂" with 😂
draganrakita
Reacted to "oh I wasn’t on the list 😂" with 😂
Parithosh Jayanthi
Reacted to "Thank you everyone for grinding on this for so long!" with 👍
FLCL (Nethermind)
Reacted to "oh I wasn’t on the list 😂" with 😂
spencer
Reacted to "oh I wasn’t on th..." with 😂
Kevaundray Wedderburn
Great work! Is the 200M within a safe budget?
donnoh | L2BEAT
Reacted to "Thank you everyone for grinding on this for so long!" with 👍
Justin Traglia
Reacted to "oh I wasn’t on the list 😂" with 😂
spencer
Reacted to "you forget to than..." with 😁
jochem-brouwer
Antwoord verzenden naar "Great work! Is the..." Yes!
donnoh | L2BEAT
Reacted to "oh I wasn’t on the list 😂" with 😂
danceratopz
Reacted to "you forget to thank ..." with 😁
Lumi | Offchain Labs
Just to double check glamsterdam-devnet-8 is live?
Geet
Sorry abt that
danceratopz
Replying to "Great work! Is the 2..." ⛽
FLCL (Nethermind)
Reacted to "Just to double check glamsterdam-devnet-8 is live?" with 👍
Louis
Replying to "Great work! Is the 2..." My understanding is that the current anchor is 100MGas/s (?) So it should be within safe range
Lumi | Offchain Labs
Reacted to "Yes!" with 🔥
Barnabas
https://github.com/ethpandaops/glamsterdam-devnets/blob/master/network-configs/devnet-8/metadata/config.yaml#L235-L237
spencer
Replying to "Just to double che..." https://dora.glamsterdam-devnet-8.ethpandaops.io/
Marius Van Der Wijden (M)
Replying to "Great work! Is the 2..." 75mgas/s iirc
Marius Van Der Wijden (M)
Replying to "Great work! Is the 2..." (Thats where all clients are clearly safe, so there's enough margin of error)
Toni Wahrstätter
Even 300M would have a safety buffer. 200M seems overly conservative if we bench for 75 mgas/s
Lumi | Offchain Labs
Reacted to "https://dora.glamsterdam-devnet-8.ethpandaops.io/" with 🔥
Toni Wahrstätter
Also happy to push for 300M right after glam, but this requires some coordination ofc (ppl upgrading their nodes) - might be fine.
Nico Flaig
it's good if we pump the gas limit incrementally which this allows easily to do
Justin Traglia
Seems fine to me.
FLCL (Nethermind)
lfg
Justin Traglia
Replying to "it's good if we pump..." Yes, I agree with this too.
Nico Flaig
but this is 100% on CL side :D
Toni Wahrstätter
Shouldn't this be a CL decision?
terence
Prysm approved and merged it
Barnabas
Reacted to "Prysm approved and merged it" with 👍
Dustin
Once the schedule is in place, there practically won't be time to undo gas limit schedules while they're going
Mehdi Aouadi
Teku ready too, PR being reviewed
Nico Flaig
lodestar has it implemented and I approve if we incrementally pump the limit
Barnabas
Reacted to "Teku ready too, PR being reviewed" with 👍
Dustin
The safety aspect of incrementality is not real
Justin Traglia
Reacted to "The safety aspect of incrementality is not real" with 😅
Nico Flaig
Replying to "The safety aspect of..." so you rather yolo to 200M at the fork boundary?
Justin Traglia
Reacted to "so you rather yolo to 200M at the fork boundary?" with 😅
Barnabas
Reacted to "The safety aspect of incrementality is not real" with 😅
Barnabas
Reacted to "so you rather yolo to 200M at the fork boundary?" with 😅
Dustin
Replying to "The safety aspect ..." It's no worse
Barnabas
The good thing about this EIP is all optional
Barnabas
+20 is just a placeholder, it can be +2 weeks
Barnabas
or +2 months
Parithosh Jayanthi
Replying to "The safety aspect of..." What’s the fear? We’re doing way worse scenarios than are ever happening on mainnet as benchmarks, is the fear that the benchmarks are wrong?
Marius Van Der Wijden (M)
(I also don't think its necessary tbh. Seems like we are specifying something unnecessarily again)
Toni Wahrstätter
One safety aspect is that this gets validators to upgrade to the latest client versions. I see Dustin's point that going to 300M right away vs incrementally shouldn't change much since we hopefully know 300M is safe without figuring out on mainnet.
draganrakita
Was this EIP PFI-ed? (Joking)
Justin Traglia
Reacted to "Was this EIP PFI-ed? (Joking)" with 😄
Barnabas
Could we actually setup a rolling window of history expiry? All fork - 1 history should be dropped?
Nico Flaig
increasing blob limit gradually was helpful, we did some improvements before BPO2 due to performance regressions we only saw on mainnet even thouhg our data on hoodi showed it was all good
Nico Flaig
maybe blobs are different because they affect network propagation more than payloads
Simon (@siladu) | Besu
Besu only drops premerge blocks currently. Last time I heard a proposal for retention window it was 33024 epochs (5 months), which Besu team was fine with but there’s a small amount of work to do in the client.
donnoh | L2BEAT
Reacted to "Could we actually setup a rolling window of history expiry? All fork - 1 history should be dropped?" with 👍
lightclient
I think we want to do rolling expiry
Iván | ethrex
We are still reviewing it, but it will be something similar to what other clients do
lightclient
To the 5.5 month boundary discussed previously
Ben Adams
We should coordinate to same; or syncing history will be an issue if missing on peers and want more?
donnoh | L2BEAT
Reacted to "We should coordinate to same; or syncing history will be an issue if missing on peers and want more?" with 👍
lightclient
Reacted to "We should coordinate to same; or syncing history will be an issue if missing on peers and want more?" with 😮
Justin Florentine (Besu)
fork-1 seems like a fun standard
Simon (@siladu) | Besu
Can this be specced somewhere if agreement was already reached?
Ben Adams
Replying to "fork-1 seems like a fun standard" 3 month forks ;)
Parithosh Jayanthi
What is our history archival strategy? Or like what guarantees?
Daniel Lehrner (Besu)
fork-1 seems a bad fit, because we do not know how much time will be between forks. Could be 6 months, but could also be more than a year
Simon (@siladu) | Besu
Replying to "fork-1 seems a bad f..." Agree, better to have a predictable size/window
donnoh | L2BEAT
Reacted to "What is our history archival strategy? Or like what guarantees?" with ➕
spencer
Reacted to "Agree, better to h..." with 💯
spencer
Reacted to "What is our histor..." with ➕
Fabio Di Fabio
Reacted to "fork-1 seems a bad fit, because we do not know how much time will be between forks. Could be 6 months, but could also be more than a year" with 👍
Justin Florentine (Besu)
Replying to "fork-1 seems a bad f..." predictable by bytes or blocks?
donnoh | L2BEAT
Reacted to "fork-1 seems a bad fit, because we do not know how much time will be between forks. Could be 6 months, but could also be more than a year" with 👍
donnoh | L2BEAT
Reacted to "Agree, better to have a predictable size/window" with 💯
Dustin
Reacted to "fork-1 seems a bad..." with 👍
Dustin
Reacted to "Agree, better to h..." with 💯
Simon (@siladu) | Besu
Replying to "What is our history ..." Last I heard, at least EF was producing/serving era files…is that still the case?
Parithosh Jayanthi
Replying to "What is our history ..." We are right now and will likely continue
lightclient
SGTM
Francesco D'Amato
Reacted to "Agree, better to have a predictable size/window" with 👍
spencer
Reacted to "SGTM" with 🙏
Justin Traglia
Reacted to "SGTM" with ➕
Mario Vega
Reacted to "SGTM" with ➕
donnoh | L2BEAT
Replying to "What is our history archival strategy? Or like what guarantees?" i’d love to seed some torrents for this… i have many hdd tb free that i now use for movies i never even watch
Parithosh Jayanthi
Reacted to "i’d love to seed some torrents for this… i have many hdd tb free that i now use for movies i never even watch" with 👍
Simon (@siladu) | Besu
Replying to "fork-1 seems a bad f..." If we align with CL epoch requirement, it’ll be blocks
Parithosh Jayanthi
Replying to "What is our history ..." Should still be working 🙂 https://ethresear.ch/t/torrents-and-eip-4444/19788
Parithosh Jayanthi
Replying to "What is our history ..." Join the effort
donnoh | L2BEAT
Reacted to "Should still be working 🙂 https://ethresear.ch/t/torrents-and-eip-4444/19788" with 🔥
jochem-brouwer
I will PFI 7923
Greg K | Lido
Reacted to "Screenshot2026_08_..." with 😁
Guru
Reacted to "Screenshot2026_08_13_162505.jpg" with 😂
wolovim
Reacted to "Screenshot2026_08_13_162505.jpg" with ✅
spencer
Reacted to "Screenshot2026_08_..." with 😂
Akash | ECH
Reacted to "Screenshot2026_08_13_162505.jpg" with 😂
Parithosh Jayanthi
Reacted to "Screenshot2026_08_13_162505.jpg" with 😂
draganrakita
https://github.com/ethereum/pm/issues/2178
Miguel Tenorio
Reacted to "Screenshot2026_08_13_162505.jpg" with 😂
Simon (@siladu) | Besu
Reacted to "Screenshot2026_08_13_162505.jpg" with 😂
Mario Vega
Reacted to "Screenshot2026_08_13_162505.jpg" with 😂
Danno Ferrin
Reacted to "I will PFI 7923" with 🎉
nixo
EIP-7971: Hard Limits for Transient Storage EIP-8058: Contract Bytecode Deduplication Discount EIP-7609: Decrease base cost of TLOAD/TSTORE EIP-7973: Warm Account Write Metering EIP-8360: TCREATE Opcode
Nico Flaig
Reacted to "Barnabas has sent yo..." with 😂
lightclient
“17 eips to propose" [Full message cannot be displayed on this version]
Marius Van Der Wijden (M)
I don't think we should do any of them in h*
spencer
Reacted to "I don't think we s..." with 💯
Barnabas
Reacted to "I don't think we should do any of them in h*" with 💯
spencer
Reacted to "I don't think we s..." with 😂
lightclient
Reacted to "I don't think we should do any of them in h*" with 😂
Geet
Reacted to "I don't think we sho..." with 😂
jochem-brouwer (backup)
https://eips.ethereum.org/EIPS/eip-7923 https://eips.ethereum.org/EIPS/eip-3298 https://eips.ethereum.org/EIPS/eip-5920
Karim T. (matkt)
Reacted to "Screenshot2026_08_13_162505.jpg" with 😂
Simon (@siladu) | Besu
Reacted to "i’d love to seed some torrents for this… i have many hdd tb free that i now use for movies i never even watch" with 👍
Will Corcoran
Reacted to "I don't think we should do any of them in h*" with 💯
draganrakita
Replying to "I don't think we sho..." Maybe tload/tstore repricing. But I would do it differently.
Justin Traglia
Reacted to "“17 eips to propose"" with 😄
Parithosh Jayanthi
Reacted to "“17 eips to propose"" with 😄
Barnabas
Reacted to "“17 eips to propose"" with 😄
Justin Traglia
Reacted to "I don't think we should do any of them in h*" with 😂
Marius Van Der Wijden (M)
Reacted to Maybe tload/tstore r... with "👍"
Will Corcoran
Reacted to "Screenshot2026_08_13_162505.jpg" with ✅
Marius Van Der Wijden (M)
Replying to "https://eips.ethereu..." Isn't 3298 pretty outdated?
nixo
Replying to "I don't think we sho..." if you want to chat with Helkomine, the guy who proposed it, he proposed this one in time so it can be modified if you want to champion it. sounds like he's reticent to champion it
FLCL (Nethermind)
Doesn't it seem to everyone that pq is the most important?
Will Corcoran
Replying to "Doesn't it seem to e..." Are you in my DMs?
FLCL (Nethermind)
Reacted to "Are you in my DMs?" with 😂
lightclient
Reacted to "Doesn't it seem to everyone that pq is the most important?" with 😁
lightclient
Remove refunds seems nice
FLCL (Nethermind)
Replying to "Doesn't it seem to everyone that pq is the most important?" Imagine in case of such black swan only Ethereum will work
draganrakita
Reacted to "Are you in my DMs?" with 😂
donnoh | L2BEAT
Reacted to "Remove refunds seems nice" with 👍
Mario Vega
Reacted to "Are you in my DMs?" with 😂
Danno Ferrin
How many reference tests will this remove?
Stefan Starflinger
Reacted to "Remove refunds seems..." with 👍
Danno Ferrin
The #1 use case for 0->x->0 memory usage is better served by TSTORE/TLOAD, so I see the only possibly controvertial concern being pre-hegotá contracts
Mario Vega
Replying to "How many reference t..." Not many because we still have to test that clients do not apply refunds
donnoh | L2BEAT
Reacted to "Not many because we still have to test that clients do not apply refunds" with 😁
spencer
Reacted to "Not many because w..." with 😁
nixo
that one (5920) was proposed on acde 237, so it's good to go. i'd have to look who the champion was
lightclient
I think now that we have log events on eth transfer, PAY is a bit more acceptable
Mario Vega
Replying to "How many reference t..." How many tests it will avoid in future changes that’s a different question and it’s indeed a nice simplification to not have to test refunds on future forks IMO
Kevaundray Wedderburn
Are most compilers on board with supporting PAY?
Justin Florentine (Besu)
brilliant performance jochem
jochem-brouwer
Heeft gereageerd op "I think now that w..." met ❤️
lightclient
Reacted to "brilliant performance jochem" with ❤️
jochem-brouwer
Heeft gereageerd op "that one (5920) wa..." met 👍
spencer
Reacted to "brilliant performa..." with ❤️
donnoh | L2BEAT
Reacted to "brilliant performance jochem" with 💯
spencer
Reacted to "brilliant performa..." with 💯
Mario Vega
Reacted to "brilliant performance jochem" with ❤️
Mario Vega
Reacted to "brilliant performance jochem" with 💯
Justin Florentine (Besu)
he has set the bar for speed
nixo
Reacted to "brilliant performance jochem" with 💯
jochem-brouwer
Heeft gereageerd op "he has set the bar..." met 🚀
Guru
Reacted to "brilliant performanc..." with ❤️
Kevaundray Wedderburn
Replying to "Are most compilers o..." (Apart from viper), just wondering what the sentiment is there
Parithosh Jayanthi
Reacted to "he has set the bar for speed" with 🚀
Parithosh Jayanthi
Reacted to "brilliant performance jochem" with 💯
Stefan Starflinger
Reacted to "brilliant performanc..." with 💯
Stefan Starflinger
Reacted to "brilliant performanc..." with ❤️
Toni Wahrstätter
Reacted to "brilliant performa..." with ❤️
Toni Wahrstätter
Reacted to "brilliant performa..." with 💯
Justin Florentine (Besu)
Reacted to "I think now that we have log events on eth transfer, PAY is a bit more acceptable" with 🎉
draganrakita
Reacted to "brilliant performance jochem" with 💯
Toni Wahrstätter
Replying to "he has set the bar..." hold my beer
Marius Van Der Wijden (M)
Number?
Stefan Starflinger
link?
nixo
EIP-8358: Net Gas Metering for Account Changes
Stefan Starflinger
Reacted to "EIP-8358: Net Gas Me..." with 👍
Marius Van Der Wijden (M)
Reacted to EIP-8358: Net Gas Me... with "👍"
jochem-brouwer
EIP-8374 is your next one
draganrakita
https://github.com/ethereum/EIPs/pull/12058
draganrakita
https://github.com/ethereum/EIPs/pull/12128
nixo
EIP-8374: Persist Warm Access Sets Across Reverts
FLCL (Nethermind)
Replying to "Doesn't it seem to everyone that pq is the most important?" codex generate me a disturbing chart that confirms 10 to 500000 qubits jump will happen in 2 years
jochem-brouwer
Heeft gereageerd op "hold my beer" met 🍻
Geet
Reacted to "codex generate me a ..." with 😭
donnoh | L2BEAT
Reacted to "codex generate me a disturbing chart that confirms 10 to 500000 qubits jump will happen in 2 years" with 😭
Stefan Starflinger
Reacted to "codex generate me a ..." with 😭
Parithosh Jayanthi
Reacted to "codex generate me a disturbing chart that confirms 10 to 500000 qubits jump will happen in 2 years" with 😭
jochem-brouwer
Heeft gereageerd op "he has set the bar..." met 😁
Felix
this will be annoying to implement
jochem-brouwer
Heeft gereageerd op "brilliant performa..." met 😄
jochem-brouwer
Antwoord verzenden naar "The #1 use case fo..." Yes, good point. I also believe this is already accounted for by EIP-8037, you get the state gas creation refund :)
Trent Van Epps
Replying to "Doesn't it seem to e..." An upgrade every 7 months seems quite optimistic
cody
Reacted to "hold my beer" with 🍻
jochem-brouwer
Heeft gereageerd op "How many tests it ..." met ➕
jochem-brouwer
Heeft gereageerd op "Remove refunds see..." met 👍
nixo
EIP-8368: CPSB Recalibration for New Gas Limit
Will Corcoran
Replying to "Doesn't it seem to e..." Very much so.
Marius Van Der Wijden (M)
8368: good
Lumi | Offchain Labs
Reacted to "Are you in my DMs?" with 😂
Lumi | Offchain Labs
Reacted to "codex generate me a disturbing chart that confirms 10 to 500000 qubits jump will happen in 2 years" with 😭
spencer
Reacted to "8368: good" with 💯
Guru
Reacted to "8368: good" with 💯
Marius Van Der Wijden (M)
Replying to "8368: good" (Trying some subliminal tricks to get this in)
Lumi | Offchain Labs
Reacted to "(Trying some subliminal tricks to get this in)" with 😂
spencer
Reacted to "(Trying some subli..." with 😂
Geet
Reacted to "(Trying some sublimi..." with 😂
donnoh | L2BEAT
Reacted to "(Trying some subliminal tricks to get this in)" with 😂
Mario Vega
Reacted to "(Trying some subliminal tricks to get this in)" with 😂
nixo
EIP-8077: eth/XX - announce transactions with nonce EIP-8094: eth/vhash - Blob-Aware Mempool
Toni Wahrstätter
Reacted to "(Trying some subli..." with 😂
Marius Van Der Wijden (M)
Replying to "EIP-8077: eth/vhash ..." I like 8077 (the real one), don't know much about the other one
Marius Van Der Wijden (M)
Replying to "EIP-8077: eth/vhash ..." You have them mixed up @nixo
Parithosh Jayanthi
Reacted to "(Trying some subliminal tricks to get this in)" with 😂
Toni Wahrstätter
bullish announce txs nonce. It's not only the nonce but also the sender in the announcement, which is great. Will help with the frame mempool.
nixo
Reacted to "You have them mixed up @nixo " with 👍
Marius Van Der Wijden (M)
Reacted to bullish announce txs... with "👍"
Guru
Reacted to "bullish announce txs..." with 👍
soispoke
A réagi à "bullish announce t..." avec 👍
Barnabas
Replying to "EIP-8077: eth/XX - a..." whats the size limit of the nonces?
Barnabas
Replying to "EIP-8077: eth/XX - a..." can’t this be dosed with maxint-1 values?
soispoke
Répondre à "EIP-8077: eth/XX -..." bullish 8077 as well
Marius Van Der Wijden (M)
Replying to "EIP-8077: eth/XX - a..." U64
Toni Wahrstätter
including sender + nonce (incl 2d nonce) + fee makes sense
lightclient
Reacted to "An upgrade every 7 months seems quite optimistic" with 🤣
Marius Van Der Wijden (M)
Replying to "EIP-8077: eth/XX - a..." Canonical nonce limit
Łukasz Rozmej
Replying to "EIP-8077: eth/XX - announce transactions with nonce EIP-8094: eth/vhash - Blob-Aware Mempool" Few years ago I was debating announcing tx nonces and sender, but then I came to a conclusion it is not worth it… Now I need to remember my though process :D
soispoke
A réagi à "including sender +..." avec 👍
Francesco D'Amato
Reacted to "bullish announce txs nonce. It's not only the nonce but also the sender in the announcement, which is great. Will help with the frame mempool." with 👍
nixo
EIP-8355 Precompiles for ML-DSA verification
Danno Ferrin
https://docs.google.com/presentation/d/1N9GLJNsPYF1Q_yXWQJnOKo0bADSZT2mSIZ-1pu1I-Ks/edit?slide=id.g3f6d86c03a1_0_0#slide=id.g3f6d86c03a1_0_0
soispoke
Répondre à "EIP-8077: eth/XX -..." worth trying to think through it again with frames in mind imo cause DoS/mass invalidation attacks are a bit more tricky
Toni Wahrstätter
Replying to "EIP-8077: eth/XX -..." also, now you have to consider frame transactions and that announcing may play well with frame txs in the mempool.
Csaba
Replying to "EIP-8077: eth/XX - a..." @Barnabas can’t really DoS just by that. It’s like saying you can DoS by sending transaction. High nonce will not be pulled, will not be forwarded
Csaba
Replying to "EIP-8077: eth/XX - a..." @Łukasz Rozmej Happy to have nuanced discussions on this. It is indeed size dependent what makes sense (or what’s optimal). Maybe replacing all announcements with larger ones (adding more metadata) is not the optimal choice.
Ansgar Dietrichs
really low context comment, but the fact that there was a prior different EIP indicates to me that there is a non-trivial design space here? How would we make sure that the version we ship now is the optimal one?
Kevaundray Wedderburn
It’s not clear to me that we need three new precompiles for the different signature variants (with different security levels)
Felix
it is easy to support because the standard implementation support all these parameter sets
Kevaundray Wedderburn
Replying to "It’s not clear to me..." Do we want users to be choosing their security levels? Also (haven’t checked) but can we get some confidence that these precompiles will be used?
FLCL (Nethermind)
any way to prove an aggregated pq signature confirms all txs are signed well without keeping separate signatures?
Felix
I think that is a great idea, storing data alongside the delegation
nixo
EIP-8372: Normalized state gas limit
lightclient
Replying to "any way to prove an ..." Wdym separate signatures
Danno Ferrin
Replying to "I think that is a gr..." https://github.com/ethereum/EIPs/pull/12047
FLCL (Nethermind)
Replying to "any way to prove an aggregated pq signature confirms all txs are signed well without keeping separate signatures?" we hold tx signatures for validation right? can't we have and aggregated proof? so work is only done by proposer or so?
FLCL (Nethermind)
Replying to "any way to prove an aggregated pq signature confirms all txs are signed well without keeping separate signatures?" I guess I'm missing something basic
Francesco D'Amato
fyi: EIP-8368 is the one that just adjusts CPSB (cost per state byte), which we would do based on the gas limit increases
Kevaundray Wedderburn
Reacted to "fyi: EIP-8368 is the one that just adjusts CPSB (cost per state byte), which we would do based on the gas limit increases" with 👍
Danno Ferrin
Replying to "any way to prove an ..." EIP-8288 https://github.com/ethereum/EIPs/pull/11772 - but leansig only in this proposal.
lightclient
Replying to "any way to prove an ..." yeah it’s definitely possible but we are still working on the aggregation technique
lightclient
Replying to "any way to prove an ..." https://github.com/leanEthereum/leanVM this is the main focus candidate right now
Marius Van Der Wijden (M)
Replying to "fyi: EIP-8368 is the..." And this is an alternative for that right?
FLCL (Nethermind)
Reacted to "https://github.com/leanEthereum/leanVM this is the main focus candidate right now" with 👀
Francesco D'Amato
Replying to "fyi: EIP-8368 is the..." Yeah this does a little bit more of an adjustment
Francesco D'Amato
Replying to "fyi: EIP-8368 is the..." (Very small as well)
lightclient
Replying to "any way to prove an ..." Imo the critical piece is that the signature needs to “observable” by the protocol so the protocol can pluck it out to aggregate
jochem-brouwer
I see, thank you!
nixo
EIP-8375: eMBER, ePBS Mandatory Burn of Execution Rewards
lightclient
Fire name
jochem-brouwer
Love the name of this EIP
jochem-brouwer
Heeft gereageerd op "Fire name" met 🔥
nixo
Reacted to "Fire name" with 🔥
donnoh | L2BEAT
Reacted to "Fire name" with 🔥
wolovim
Reacted to "Fire name" with 🔥
Marc
Reacted to "Fire name" with 🔥
FLCL (Nethermind)
Replying to "any way to prove an aggregated pq signature confirms all txs are signed well without keeping separate signatures?" can signature be represented by some small commitment or so?
spencer
Reacted to "Fire name" with 🔥
FLCL (Nethermind)
Reacted to "EIP-8288 https://github.com/ethereum/EIPs/pull/11772 - but leansig only in this proposal." with 👀
Chris - Base
8355 plugs directly into eip 8130 @shemnon , happy to jam on that after! We're evaludating our initial PQ algo set for Base/OP as well
lightclient
I feel like we should see how ePBS ends up getting used in practice before building on top of it. I worry that even with glam, many builders will circumvent ePBS
Kevaundray Wedderburn
Reacted to "I feel like we should see how ePBS ends up getting used in practice before building on top of it. I worry that even with glam, many builders will circumvent ePBS" with 👍
terence
this will create a strong incentive for proposer to re create today’s self build path to use builder bids to avoid the burn. Builder cartel will form and only offer competitive bids if proposers agree to blind signing arrangements
Nico Flaig
Reacted to "this will create a s..." with 👍
Danno Ferrin
Replying to "It’s not clear to me..." Shipping multiple levels allows for mid-fork crypto agility, if there is a need to go to a stronger formulation. I’m leaving space for research like how classic McClease just got nerfed. So far the attacks have amounted to trimming off security bits, so going up to a stronger level addresses that in-place. For precompile use, I’ll point you to the many wallets attempting to use ML-DSA in 4337 but abandoning it due to gas costs.
Marius Van Der Wijden (M)
Replying to "this will create a s..." We only have 2 builders anyway, right? What prevents them from doing so with epbs?
donnoh | L2BEAT
Reacted to "I feel like we should see how ePBS ends up getting used in practice before building on top of it. I worry that even with glam, many builders will circumvent ePBS" with 👍
Francesco D'Amato
Replying to "this will create a s..." There’s no reason to do blind signing with epbs, it even supports “offchain payments”, but still without pretending to self build
Danno Ferrin
Replying to "8355 plugs directly ..." Because I’m only proposing a precompile, it should slot into any AA solution. That’s how AA is supposed to work right?
FLCL (Nethermind)
Replying to "any way to prove an aggregated pq signature confirms all txs are signed well without keeping separate signatures?" ty for the links! Let me reduce my ignorance
soispoke
A réagi à "this will create a..." avec 👍
Mario Vega
Reacted to "I feel like we should see how ePBS ends up getting used in practice before building on top of it. I worry that even with glam, many builders will circumvent ePBS" with 👍
Kevaundray Wedderburn
Replying to "It’s not clear to me..." On cryptographic agility, you mean if the 44 variant is broken, then users can shift to the 65 variant?
Daniil Ankushin | Nethermind
Reacted to "EIP-8288 https://github.com/ethereum/EIPs/pull/11772 - but leansig only in this proposal." with 👍
Francesco D'Amato
Fwiw lots of people have thought about various forms of mev burn over the years and never found any of it convincing enough. It looked more or less something like this
nixo
EIP-8219: Checked Arithmetic Opcodes
terence
Replying to "this will create a s..." Ya, incentive is low
lightclient
Replying to "any way to prove an ..." In frames, the sig is represented in the EVM just by 1) data it is over 2) who signed it 3) if it is valid
lightclient
Replying to "any way to prove an ..." So the data it is over is obv just a hash
soispoke
A réagi à "I feel like we sho..." avec 👍
Danno Ferrin
Replying to "It’s not clear to me..." If 44 drops down to security level 1 or off the leveling. Broken implies the whole algo is broken. so if 44 is weakend below the level 1 equivelants.
terence
Replying to "this will create a s..." If we use the ptc to enforce a min burn, wouldn’t that affect self build proposers whose chosen is not determined by the highest bid observed over p2p?
Ben Adams
Replying to "this will create a strong incentive for proposer to re create today’s self build path to use builder bids to avoid the burn. Builder cartel will form and only offer competitive bids if proposers agree to blind signing arrangements" self build would just be % of priority fees
Kevaundray Wedderburn
Replying to "It’s not clear to me..." I think in that case, existing contracts unless they upgrade would be at risk. So perhaps we should just choose a conservative variant, that most are using and has okay gas numbers if we decide to do this?
Ben Adams
Replying to "this will create a strong incentive for proposer to re create today’s self build path to use builder bids to avoid the burn. Builder cartel will form and only offer competitive bids if proposers agree to blind signing arrangements" Or could block block production
Marius Van Der Wijden (M)
Nothing > 4 > 1 imo
Kevaundray Wedderburn
Is there a note on why some compilers can’t elide some of these checks?
nixo
Replying to "Is there a note on w..." (elude)
jochem-brouwer
I would note from a development/user perspective (smart contract writer, or end-user using these contracts) this is an opcode what we also should have had since Frontier/Chainstart (like PAY)
FLCL (Nethermind)
Reacted to "So the data it is over is obv just a hash" with 👍
Kevaundray Wedderburn
Replying to "Is there a note on w..." Sorry micdao
Chris - Base
Not a client but can speak
Kevaundray Wedderburn
Replying to "Is there a note on w..." @@ritzdorf / Hubert Ritzdorf (EIP-8219) I was asking as to why users cannot write a + b and in some cases, the compiler does not emit safe_add because it can see that its safe to do without checks
Lumi | Offchain Labs
Replying to "Not a client but can..." +1 for Arbitrum
lightclient
Aug 25, eth o’clock we start the AA calls again
Guru
Reacted to "Aug 25, eth o’clock ..." with 👍
donnoh | L2BEAT
Reacted to "Aug 25, eth o’clock we start the AA calls again" with 🔥
Chris - Base
Reacted to "Aug 25, eth o’clo..." with 👍
Guru
Reacted to "Aug 25, eth o’clock ..." with 🔥
Toni Wahrstätter
We should think about promoting it to headliner + SFI'ing it soon. This gives the community the needed certainty.
Iván | ethrex
Reacted to "Aug 25, eth o’clock ..." with 🔥
soispoke
A réagi à "Aug 25, eth o’clo..." avec 🔥
nixo
Reacted to "Aug 25, eth o’clock we start the AA calls again" with 👍
Stefan Starflinger
Reacted to "Aug 25, eth o’clock ..." with 🔥
Parithosh Jayanthi
Reacted to "Aug 25, eth o’clock we start the AA calls again" with 🔥
nixo
Reacted to "Aug 25, eth o’clock we start the AA calls again" with 🔥
Shruti Gandhi
Reacted to "Aug 25, eth o’clock we start the AA calls again" with 🔥
soispoke
I think we should make Frames a headliner if people are confident about wanting to SFI it otherwise it's a bit of a lost opportunity to have Frames as a great theme for Hegota
donnoh | L2BEAT
Reacted to "We should think about promoting it to headliner + SFI'ing it soon. This gives the community the needed certainty." with 👍
Will Corcoran
Reacted to "We should think about promoting it to headliner + SFI'ing it soon. This gives the community the needed certainty." with 👍
Guru
Reacted to "We should think abou..." with 👍
spencer
Replying to "We should think ab..." Today :) ?
Iván | ethrex
Reacted to "Aug 25, eth o’clock ..." with 👍
Iván | ethrex
Reacted to "We should think abou..." with 👍
jochem-brouwer
Heeft gereageerd op "I think we should ..." met ➕
donnoh | L2BEAT
Reacted to "Today :) ?" with 🔥
Iván | ethrex
Reacted to "Today :) ?" with 🔥
Iván | ethrex
Reacted to "Today :) ?" with ☝️
jochem-brouwer
Heeft gereageerd op "We should think ab..." met 👍
Toni Wahrstätter
Reacted to "Today :) ?" with 🔥
Will Corcoran
Reacted to "Today :) ?" with 🔥
Derek Chiang
Reacted to "We should think about promoting it to headliner + SFI'ing it soon. This gives the community the needed certainty." with 👍
Will Corcoran
Reacted to "Today :) ?" with ☝️
donnoh | L2BEAT
Reacted to "I think we should make Frames a headliner if people are confident about wanting to SFI it otherwise it's a bit of a lost opportunity to have Frames as a great theme for Hegota" with ➕
Shruti Gandhi
Reacted to "Today :) ?" with 🔥
Derek Chiang
Reacted to "Aug 25, eth o’clock we start the AA calls again" with 👍
Derek Chiang
Reacted to "Aug 25, eth o’clock we start the AA calls again" with 🔥
Will Corcoran
Reacted to "I think we should make Frames a headliner if people are confident about wanting to SFI it otherwise it's a bit of a lost opportunity to have Frames as a great theme for Hegota" with ➕
lightclient
Reacted to "We should think about promoting it to headliner + SFI'ing it soon. This gives the community the needed certainty." with 👍
Marius Van Der Wijden (M)
Reacted to We should think abou... with "👍"
spencer
Reacted to "Aug 25, eth o’clo..." with 🔥
Parithosh Jayanthi
Reacted to "We should think about promoting it to headliner + SFI'ing it soon. This gives the community the needed certainty." with 👍
Barnabas
Reacted to "Aug 25, eth o’clock we start the AA calls again" with 🔥
Ansgar Dietrichs
we should be clear about decision sequencing, first decision should be “is frames specifically now locked in as specific AA variant” then when that’s locked in, we can separately discuss potential headliner status
lightclient
Reacted to "I think we should make Frames a headliner if people are confident about wanting to SFI it otherwise it's a bit of a lost opportunity to have Frames as a great theme for Hegota" with ➕
Iván | ethrex
Reacted to "I think we should ma..." with ➕
soispoke
A réagi à "We should think ab..." avec 👍
Danno Ferrin
One of the biggest wins for frames is that ethereum addresses are no longer tied to public keys, and hence algorithms. My take is any AA solution needs to have this address dissociation property, for PQ reasons.
soispoke
A réagi à "Today :) ?" avec 🔥
Toni Wahrstätter
Reacted to "Aug 25, eth o’clo..." with 🔥
wolovim
Replying to "Aug 25, eth o’clock ..." If you want to add to the agenda: https://github.com/ethereum/pm/issues/2191
Iván | ethrex
We still support frames
lightclient
Reacted to "We still support frames" with 🔥
Barnabas
Reacted to "We still support frames" with 🎉
donnoh | L2BEAT
Reacted to "We still support frames" with 🔥
Simon (@siladu) | Besu
Reacted to "We should think about promoting it to headliner + SFI'ing it soon. This gives the community the needed certainty." with 👍
soispoke
A réagi à "We still support f..." avec 🔥
Csaba
Reacted to "We still support frames" with 🎉
jochem-brouwer
Heeft gereageerd op "We still support f..." met 🔥
jochem-brouwer
Heeft gereageerd op "We still support f..." met 🎉
Toni Wahrstätter
Reacted to "We still support f..." with 🔥
jochem-brouwer
Heeft gereageerd op "Today :) ?" met 🔥
jochem-brouwer
Heeft gereageerd op "Today :) ?" met ☝️
lightclient
Ship it
soispoke
A réagi à "We still support f..." avec 🎉
Iván | ethrex
Reacted to "Ship it" with 🚢
lightclient
Reacted to "Ship it" with 🚢
donnoh | L2BEAT
Reacted to "Ship it" with 🚢
Kevaundray Wedderburn
Reacted to "Aug 25, eth o’clock we start the AA calls again" with 👍
Kevaundray Wedderburn
Reacted to "Aug 25, eth o’clock we start the AA calls again" with 🔥
Lumi | Offchain Labs
Is RETH for 8141?
Will Corcoran
Reacted to "Ship it" with 🚢
soispoke
A réagi à "Ship it" avec 🚢
Trent Van Epps
Designing for other chains has never been a primary consideration
jochem-brouwer
Heeft gereageerd op "Ship it" met 🚢
Stavros Vlachakis
Reacted to "We still support frames" with 🔥
Trent Van Epps
Replying to "Is RETH for 8141?" Nixo mentioned they aren’t taking a stance
soispoke
Répondre à "we should be clear..." is there any alternative that survived or is still in competing?
Justin Florentine (Besu)
Replying to "Designing for other ..." not for us, but it is for the wallets
Danno Ferrin
Most of the EVM ecosystem is downstream from EL clients, the burden for adopting ranges from automatic to low.
draganrakita
Replying to "Is RETH for 8141?" Happy to work on it, will leave other to make decision
donnoh | L2BEAT
Reacted to "Nixo mentioned they aren’t taking a stance" with 👍
Chris - Base
I am here to speak
Chris - Base
Sorry mic issue
Mislav Javor
+1 for Guarantor on my end!
lightclient
On arbitrum?
Danno Ferrin
“Selecting a proper algorith” - If you select only one PQ algo you’ve done it wrong.
Lumi | Offchain Labs
FYI MAX_VERIFY_GAS is not sufficient for DOS vector mitigation for PQ signatures for L2s, we don’t have the same aggregation service
Shruti Gandhi
Reacted to "FYI MAX_VERIFY_GAS is not sufficient for DOS vector mitigation for PQ for L2s, we don’t have the same aggregation service" with 👍
taek
Reacted to "FYI MAX_VERIFY_GAS is not sufficient for DOS vector mitigation for PQ signatures for L2s, we don’t have the same aggregation service" with 👍
Trent Van Epps
Replying to "Designing for other ..." This feels like an impossible bar to keep meeting if other non-mainnet EVM chains choose to diverge
lightclient
Reacted to "Designing for other chains has never been a primary consideration" with 👍
Derek Chiang | Ethlabs
@Chris - Base did you mean Base and OP will implement 8130? IIRC Arbitrum did not formally commit to either 8130 or 8141 right? Maybe @Lumi | Offchain Labs can confirm
taek
Reacted to "@Chris - Base did you mean Base and OP will implement 8130? IIRC Arbitrum did not formally commit to either 8130 or 8141 right? Maybe @Lumi | Offchain Labs can confirm" with 👍
Chris - Base
Oh did i say abritrum
donnoh | L2BEAT
Reacted to "Designing for other chains has never been a primary consideration" with 👍
Chris - Base
OP ** and Base
Cyrus
As of August 13, 2026, Ethernodes’ current crawl of 8,166 Ethereum execution-layer nodes shows: Geth: 42.93% Nethermind: 30.54% Reth: 15.12% Besu: 7.02% Erigon: 2.40% Ethrex: 0.60% Other/unknown: ~1.4%
Lumi | Offchain Labs
Replying to "@Chris - Base did yo..." We have not committed to either
donnoh | L2BEAT
Reacted to "This feels like an impossible bar to keep meeting if other non-mainnet EVM chains choose to diverge" with 👍
lightclient
Reacted to "Oh did i say abritrum" with 🤣
Chris - Base
My bad
Derek Chiang | Ethlabs
Reacted to "We have not committed to either" with 👍
Mario Alvarez (Offchain)
Replying to "FYI MAX_VERIFY_GAS..." We could set MAX_VERIFY_GAS low enough to avoid a DOS vector, but this might come at the cost of making it impossible to do anything interesting in the verification logic
Lumi | Offchain Labs
Reacted to "Oh did i say abritrum" with 🤣
Chris - Base
Reacted to "@Chris - Base did ..." with 👍
lightclient
It is a little weird to compare 8130 and 8141 when clients have reviewed them and are generally with 8141
donnoh | L2BEAT
Reacted to "Oh did i say abritrum" with 🤣
Stavros Vlachakis
Reacted to "It is a little weird to compare 8130 and 8141 when clients have reviewed them and are generally with 8141" with ❤️
Iván | ethrex
Reacted to "It is a little weird..." with ☝️
Toni Wahrstätter
Reacted to "It is a little wei..." with ☝️
Stavros Vlachakis
Reacted to "It is a little weird to compare 8130 and 8141 when clients have reviewed them and are generally with 8141" with ☝️
donnoh | L2BEAT
Reacted to "It is a little weird to compare 8130 and 8141 when clients have reviewed them and are generally with 8141" with ☝️
Mislav Javor
What's the core complaint as it's currently written?
Cyrus
Does install base size of the clients matter when considering stances? Geth + Nethermind is over 70%
donnoh | L2BEAT
Reacted to "What's the core complaint as it's currently written?" with ➕
Lumi | Offchain Labs
Replying to "It is a little weird..." What Tsahi said
Mario Vega
Reacted to "What's the core complaint as it's currently written?" with ☝🏼
soispoke
could we maybe a bit more specific about what would make it better?
lightclient
Ultimately I think we either do 8141 and make some modifications as needed or we don’t do AA
Derek Chiang | Ethlabs
Replying to "What's the core comp..." L2s are not confident that it will give them the TPS they need, with its current purely dynamic validation model
lightclient
There is really no chance to adjust course to do 8130 now IMO
lightclient
It’s a very very different paradigm
Marius Van Der Wijden (M)
Sounds like breakout rooms will continue until morale improves
lightclient
Reacted to "Sounds like breakout rooms will continue until morale improves" with 🤣
Lumi | Offchain Labs
Reacted to "Sounds like breakout rooms will continue until morale improves" with 🤣
jochem-brouwer
Heeft gereageerd op "Sounds like breako..." met 🤣
donnoh | L2BEAT
Reacted to "Sounds like breakout rooms will continue until morale improves" with 🤣
Mario Vega
Reacted to "Sounds like breakout rooms will continue until morale improves" with 🤣
taek
Reacted to "Sounds like breakout rooms will continue until morale improves" with 🤣
Iván | ethrex
Replying to "Sounds like breakout..." I mean if we only need client votes it’s kinda final
lightclient
L2s can only allow certain verification sequences with frames
lightclient
I don’t really understand the issue
donnoh | L2BEAT
Reacted to "L2s can only allow certain verification sequences with frames" with 👍
Chris - Base
Frames isnt SFI yet. 8130 can run very similar txns as frames as well
spencer
Reacted to "I mean if we only ..." with 💯
Iván | ethrex
Some of them have been playing around with it for a while
Mislav Javor
That's a valid complaint! The underwriting/guarantor model making sure all computation is paid for has been proposed though. I think there can be a breakout call where it's discussed more in-depth
Chris - Base
L1 - relaxed authenticator group including payment based stateful authenticators L2 - standard cryptographic set
donnoh | L2BEAT
Reacted to "There is really no chance to adjust course to do 8130 now IMO" with 👍
Lumi | Offchain Labs
Replying to "Sounds like breakout..." I don’t think only client votes in this case are the right method if it leads to large fragmentation
Guru
Reacted to "L2s can only allow c..." with 👍
Toni Wahrstätter
I'm not sure why MEV and frames are related, would be great to have that written down in more detail and what the exact incompatibility is. Seems like it's not technical?
donnoh | L2BEAT
Reacted to "I'm not sure why MEV and frames are related, would be great to have that written down in more detail and what the exact incompatibility is. Seems like it's not technical?" with 👍
lightclient
Frames specify the signatures outside execution so they can be immediately validated in parallel
donnoh | L2BEAT
Reacted to "Frames specify the signatures outside execution so they can be immediately validated in parallel" with 👍
Stavros Vlachakis
Reacted to "Frames specify the signatures outside execution so they can be immediately validated in parallel" with 👍
Iván | ethrex
Reacted to "Frames specify the s..." with 👍
Toni Wahrstätter
My feeling is like the goals are very aligned and maybe we just need to adapt frames slightly.
Derek Chiang | Ethlabs
There’s an ongoing workstream to add static (aka “pure function”) validation to Frames, such that sequencers can validate Frame transactions with native code and therefore pay a fixed validation cost, which would address the TPS / DoS concerns from L2s. That said I understand it’s hard for L2s to definitely say they support Frames without seeing that in the spec
lightclient
I think we can find a version of 8141 that everyone is happy with. But if we keep arguing about major design differences, I think we will end up burning out and not changing anything
Lumi | Offchain Labs
Reacted to "There’s an ongoing workstream to add static (aka “pure function”) validation to Frames, such that sequencers can validate Frame transactions with native code and therefore pay a fixed validation cost, which would address the TPS / DoS concerns from L2s. That said I understand that’s it’s hard for L2s to definitely say they support Frames without seeing that in the spec" with 🔥
Daniil Ankushin | Nethermind
I believe that 8131 can be built on top of / in parallel with 8141
Kevaundray Wedderburn
@Chris - Base do you have a tldr on how 8130 composes with the add-ons on 8141; recent roots, keyed nonces and tx assertions?
Mislav Javor
Can 8130 be implemented as a "subset" of 8141? Then they launch with both goals satisfied
donnoh | L2BEAT
Reacted to "I think we can find a version of 8141 that everyone is happy with. But if we keep arguing about major design differences, I think we will end up burning out and not changing everything" with 👍
soispoke
A réagi à "@Chris - Base do y..." avec 👍
donnoh | L2BEAT
Reacted to "@Chris - Base do you have a tldr on how 8130 composes with the add-ons on 8141; recent roots, keyed nonces and tx assertions?" with 👍
Lumi | Offchain Labs
Replying to "There’s an ongoing w..." Static validation would be great and solve our concern
Stavros Vlachakis
Reacted to "There’s an ongoing workstream to add static (aka “pure function”) validation to Frames, such that sequencers can validate Frame transactions with native code and therefore pay a fixed validation cost, which would address the TPS / DoS concerns from L2s. That said I understand it’s hard for L2s to definitely say they support Frames without seeing that in the spec" with 🔥
Simon (@siladu) | Besu
Replying to "As of August 13, 202..." How is this data collected? Historically, I thought ethernodes data was unreliable.
spencer
Reacted to "@Chris - Base do y..." with 👍
Derek Chiang | Ethlabs
Reacted to "Static validation would be great and solve our concern" with ❤️
lightclient
Reacted to "There’s an ongoing workstream to add static (aka “pure function”) validation to Frames, such that sequencers can validate Frame transactions with native code and therefore pay a fixed validation cost, which would address the TPS / DoS concerns from L2s. That said I understand it’s hard for L2s to definitely say they support Frames without seeing that in the spec" with 🔥
Guru
Reacted to "@Chris - Base do you..." with 👍
donnoh | L2BEAT
Replying to "@Chris - Base do you have a tldr on how 8130 composes with the add-ons on 8141; recent roots, keyed nonces and tx assertions?" also zkzkframes (8288)
Kevaundray Wedderburn
Reacted to "also zkzkframes (8288)" with 👍
Mario Vega
Reacted to "@Chris - Base do you have a tldr on how 8130 composes with the add-ons on 8141; recent roots, keyed nonces and tx assertions?" with 👍
Derek Chiang | Ethlabs
Replying to "There’s an ongoing w..." Can you whip tsahi/taek to get them working with me on this 😂
soispoke
A réagi à "also zkzkframes (8..." avec 👍
spencer
Reacted to "also zkzkframes (8..." with 👍
Lumi | Offchain Labs
Replying to "There’s an ongoing w..." Hahaha @taek @Tsahi Zidenberg are here
Derek Chiang | Ethlabs
Reacted to "Hahaha @taek @Tsahi Zidenberg are here" with ❤️
Chris - Base
8130 accounts can work with it, but no we cant get all the benefits of 8130 with 8141
Chris - Base
Reacted to "@Chris - Base do y..." with 👍
Barnabas
AA breakouts continue till decision is made
Chris - Base
We have zk agggregation yes, we do have a 2d nonce system as well (in addition to nonceless mode for no state growth)
Kevaundray Wedderburn
I guess we had two decisions: Potentially consolidating 8141 and 8130 Headliner of 8141
Toni Wahrstätter
SFI + headliner would be the default if nothing changes
lightclient
Reacted to "SFI + headliner would be the default if nothing changes" with 👍
Iván | ethrex
Reacted to "SFI + headliner woul..." with 👍
donnoh | L2BEAT
Reacted to "SFI + headliner would be the default if nothing changes" with 👍
Guru
Reacted to "SFI + headliner woul..." with 👍
taek
Replying to "There’s an ongoing w..." I do strongly back this approach We can come up with our own RIP that extends 8141 or block ARBITRARY signature scheme but we want to minimize the divergence if possible
jochem-brouwer
Thanks Ansgar, :+1: a lot to that point
Chris - Base
Mainnet end of sept*
Lumi | Offchain Labs
Reacted to "Mainnet end of sept*" with ➕
taek
Reacted to "I guess we had two decisions: Potentially consolidating 8141 and 8130 Headliner of 8141" with 👍
taek
Reacted to "SFI + headliner would be the default if nothing changes" with 👍
Will Corcoran
that’s why they call it rough consensus (everyone a little unhappy)
Derek Chiang | Ethlabs
I think it’s OK to SFI+headliner frames, considering it’s the only proposal designed with L1’s core goals of permissionless account deployment and privacy protocols in mind. But we should ALSO commit to working with L2s to update frames to address their concerns (in fact that effort is already in motion). Would love to incorporate L2 coauthorship into frames
nixo
Reacted to "that’s why they call it rough consensus (everyone a little unhappy)" with ➕
Kevaundray Wedderburn
Reacted to "I think it’s OK to SFI+headliner frames, considering it’s the only proposal designed with L1’s core goals of permissionless account deployment and privacy protocols in mind. But we should ALSO commit to working with L2s to update frames to address their concerns (in fact that effort is already in motion). Would love to incorporate L2 coauthorship into frames" with 👍
lightclient
Replying to "I think it’s OK to S..." More than happy to commit to this
donnoh | L2BEAT
Reacted to "I think it’s OK to SFI+headliner frames, considering it’s the only proposal designed with L1’s core goals of permissionless account deployment and privacy protocols in mind. But we should ALSO commit to working with L2s to update frames to address their concerns (in fact that effort is already in motion). Would love to incorporate L2 coauthorship into frames" with 👍
Iván | ethrex
Reacted to "I think it’s OK to S..." with 👍
FLCL (Nethermind)
Reacted to "I think it’s OK to SFI+headliner frames, considering it’s the only proposal designed with L1’s core goals of permissionless account deployment and privacy protocols in mind. But we should ALSO commit to working with L2s to update frames to address their concerns (in fact that effort is already in motion). Would love to incorporate L2 coauthorship into frames" with 👍
Csaba
Replying to "As of August 13, 202..." Different from the number I see
soispoke
A réagi à "I think it’s OK t..." avec 👍
Chris - Base
Reacted to "I think it’s OK t..." with 👍
taek
Reacted to "I think it’s OK to SFI+headliner frames, considering it’s the only proposal designed with L1’s core goals of permissionless account deployment and privacy protocols in mind. But we should ALSO commit to working with L2s to update frames to address their concerns (in fact that effort is already in motion). Would love to incorporate L2 coauthorship into frames" with 👍
Simon (@siladu) | Besu
Replying to "As of August 13, 202..." Using graffiti https://x.com/EthDreamer/status/2072435669054459987
taek
Reacted to "More than happy to commit to this" with ❤️
Kevaundray Wedderburn
Thanks!

Call summary

Targets

•glamsterdam-devnet-8 (Platåberget): live as of Aug 13; Gloas fork Thursday ~7:50 AM UTC - 00:09:04
•AA breakout call: August 25, 14:00 UTC - 01:19:12
•Hegota EL client preference lists due: September 10, 2026 - 00:28:10

Decisions

•Gas repricing numbers final; no spec changes needed; 200M gas limit confirmed for Glamsterdam - 00:11:34
•EIP-8261 (in-client gas limit schedule) moves forward as optional CL config parameter - 00:20:18
•PFI for Hegota: EIP-7923 (Linear Memory Costing), EIP-3298 (Remove Refunds), EIP-5920 (PAY opcode), EIP-8358 (Net Gas Metering for Account Changes), EIP-8374 (Persist Warm Access Sets), EIP-8368 (CPSB Recalibration), EIP-8077 (announce txs with nonce), EIP-8094 (blob-aware mempool), EIP-8355 (ML-DSA precompile), EIP-8372 (Normalized State Gas Limit), EIP-8375 (eMBER), EIP-8219 (Checked Arithmetic Opcodes) - 01:17:19
•EIPs 7971, 8058, 7609, 7973, 8360 not PFI'd; nixo to contact helkomine for next ACDE opportunity, otherwise PRs closed - 00:30:37
•Native AA implementation decision (Frames/8141 vs 8130) deferred to AA breakout Aug 25 + ACDE Aug 27 - 01:34:59
•EL client preference lists for Hegota PFIs due by September 10th (ACDE #245) - 00:28:10

Highlights

Native Aa:
- ·Frames (EIP-8141) status: Geth, Nethermind, ethrex support; Besu not opposed; Reth no stance; Erigon supportive; strong pushback from Base/OP (EIP-8130) and Arbitrum on L2 DoS/TPS concerns - 01:17:19
- ·Offchain Labs: static/pure-function validation frames mode would resolve L2 DoS concern; static frames workstream already in progress per Derek (Ethlabs) - 01:23:04
- ·Decision deferred: AA breakout on Aug 25 (14:00 UTC) to compare 8141 vs 8130 and surface required modifications; ACDE #244 (Aug 27) to make final implementation decision - 01:34:59
History Expiry:
- ·History expiry needed for 2TB node operators at Hegota given 200M gas limit; no consensus on cutoff — Nethermind targets ~6 months, Erigon ~1 year, Geth fork-minus-100K blocks, Besu 5 months - 00:20:29
- ·Ben Adams: clients must coordinate on same expiry window or history syncing breaks; discussion deferred to ETH R&D history-expiry channel - 00:24:34
Eip Proposals Hegota:
- ·EIP-7923 (Linear Page-Based Memory Costing): replaces quadratic memory pricing; jochem championing; spec update + max-memory report in 2 weeks - 00:31:24
- ·EIP-3298 (Remove Refunds): proposal to remove storage-clearing refund only; EIP-7702 refund handling to be discussed async - 00:34:21
- ·EIP-5920 (PAY opcode): send ETH without executing foreign code; jochem will champion if no existing champion - 00:39:44
- ·EIP-8358 (Net Gas Metering for Account Changes) and EIP-8374 (Persist Warm Access Sets Across Reverts): both PFI'd by draganrakita; Danno flags 8374 implementation complexity - 00:42:17
- ·EIP-8368 (CPSB Recalibration): small constant adjustment to EIP-8037 needed when scaling gas limit toward 600M; Toni presenting on Maria's behalf - 00:47:49
- ·EIP-8355 (ML-DSA precompile): FIPS 204, all 3 security levels, compressed keys; widely supported in client languages by Hegota ship date - 00:53:43
- ·EIP-8372 (Normalized State Gas Limit): one-time fork-boundary calibration of state gas cost/limit to correct over/under-demand after Glamsterdam - 01:02:22
- ·EIP-8375 (eMBER, ePBS Mandatory Burn): burns % of execution rewards via priority fee floor + PBS observer floor; lightclient flags ePBS adoption uncertainty - 01:06:44
- ·EIP-8219 (Checked Arithmetic Opcodes): safe add/sub/mul/div opcodes reverting on overflow; reduces Solidity safe-math from ~79 gas to ~5 gas; alternative single-opcode+immediate proposed - 01:11:41
- ·EIPs 7971, 8058, 7609, 7973, 8360 (proposed by helkomine): no champion present; nixo to contact helkomine for next ACDE or PRs will be closed - 00:29:32
Fork Status And Schedule:
- ·glamsterdam-devnet-8 (Platåberget) launched; Gloas activates ~1 week out (Thursday 7:50 AM UTC) - 00:08:12
- ·Gas repricing numbers final: EIP-2780/8037/8038 specs unchanged; 200M gas limit confirmed safe for Glamsterdam (>3x current 60M) - 00:11:34
- ·EIP-8261 (in-client gas limit schedule via CL config): majority of CL clients approved; moves forward as optional parameter - 00:20:18

Action Items

•EL client teams via ETH R&D history-expiry channel - Converge on single history expiry window number and decide where to spec it - 00:26:09
•L2 teams (Base, Offchain Labs) and Frames authors - Bring concrete 8141 vs 8130 comparison and required-modification list to AA breakout Aug 25 - 01:34:59

Key decisions

Gas repricing numbers final; no spec changes needed; 200M gas limit confirmed for Glamsterdam
Included
EIP-8261 (in-client gas limit schedule) moves forward as optional CL config parameter
Included
PFI for Hegota: EIP-7923 (Linear Memory Costing), EIP-3298 (Remove Refunds), EIP-5920 (PAY opcode), EIP-8358 (Net Gas Metering for Account Changes), EIP-8374 (Persist Warm Access Sets), EIP-8368 (CPSB Recalibration), EIP-8077 (announce txs with nonce), EIP-8094 (blob-aware mempool), EIP-8355 (ML-DSA precompile), EIP-8372 (Normalized State Gas Limit), EIP-8375 (eMBER), EIP-8219 (Checked Arithmetic Opcodes)
PFI
EIPs 7971, 8058, 7609, 7973, 8360 not PFI'd; nixo to contact helkomine for next ACDE opportunity, otherwise PRs closed
DFI
Native AA implementation decision (Frames/8141 vs 8130) deferred to AA breakout Aug 25 + ACDE Aug 27
SFI
EL client preference lists for Hegota PFIs due by September 10th (ACDE #245)

EIPs discussed

EIP-3298 EIP-5920 EIP-7609 EIP-7923 EIP-7971 EIP-7973 EIP-8058 EIP-8077 EIP-8094 EIP-8130 EIP-8141 EIP-8219 EIP-8261 EIP-8355 EIP-8358 EIP-8360 EIP-8368 EIP-8372 EIP-8374 EIP-8375

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.

Contact dev@avarch.org

Loading Experience