ACDE2026-03-12_232

AllCoreDevs - Execution #232

2026-03-12 3 decisions 662 transcript lines

Transcript

Follow along

Justin Traglia
Gm
dionysuz.eth
gm
lightclient
gm
spencer
lfgm
Justin Florentine (Besu)
lfhagoooooooota
Justin Traglia
Reacted to "lfgm" with 😄
spencer
Reacted to "lfhagoooooooota" with 🚀
Justin Traglia
Reacted to "lfhagoooooooota" with 🚀
Kevaundray Wedderburn
Reacted to "lfhagoooooooota" with 🚀
Ben Adams
Reacted to "lfhagoooooooota" with 🚀
Barnabas
g[frame]m
Josh Davis
Ben looks like a steampunk Seth Rogan
lightclient
lol
Will Corcoran
Replying to "Ben looks like a ste..." Looks like he is about to invite me on an amazing adventure
Barnabas
thats better 😂
felix (eest)
hey i was watching that
Justin Traglia
Reacted to "lol" with 😄
Ben Adams
Reacted to "Ben looks like a ste..." with 😂
Josh Davis
Reacted to "lol" with 😄
nixo
ahahahahah
wolovim
Reacted to "lol" with 😄
lightclient
standup session with V?
Ben Adams
Reacted to "Looks like he is abo..." with 👍
Louis
Reacted to "standup session with..." with 😂
Ansgar Dietrichs
Reacted to "hey i was watching t..." with 😂
FLCL
Depends on how prefetch is implemented probably
Toni Wahrstätter
Replying to "Depends on how prefe..." yeah and what matters are worst-cases not average cases.
spencer
JICYMI, new EELS release for bal-devnet-3 with the latest 8037 tests: https://github.com/ethereum/execution-spec-tests/releases/tag/bal@v5.4.0
Łukasz Rozmej
8037 is ☠️
felipe
Reacted to "Depends on how pre..." with 💯
Karim T. (matkt)
Replying to "Depends on how prefe..." And state size also
Ansgar Dietrichs
my understanding is that the read locations part of BALs is only for allowing deterministic prefetch, right? so we’d need to see it actually have (significant) benefits for the worst cases there to justify keeping it in the EIP?
felipe
Reacted to "yeah and what matt..." with 💯
FLCL
Any simple way to benchmark prefetch for an EL? Liek a pipeline or so?
Karim T. (matkt)
Replying to "Depends on how prefe..." If it is on top of devnet 2 state I think we will see less performance improvement than mainnet state
Dragan Rakita
Replying to "JICYMI, new EELS rel..." I think there is a bug here. Have reported in discord
Łukasz Rozmej
Reacted to "my understanding is ..." with 👍
Stefan Starflinger
Replying to "my understanding is ..." yeah
felipe
Reacted to "If it is on top of..." with 👍
FLCL
Replying to "Depends on how prefe..." We want to not wait prefetching state, but start execution in parallel and hope it will speed up
Łukasz Rozmej
Replying to "my understanding is ..." probably it is not worth it
Stefan Starflinger
Replying to "Any simple way to be..." what do you mean with pipline?
Karim T. (matkt)
Replying to "Depends on how prefe..." Yes the same in Besu we start without waiting for the prefetch
FLCL
So the testing happend for different optimizations right? But what if I have a new branch with more optimizations and want to test if it is more performant. Currently reruning some blocks from devnet locally, but it's very inconvinient
my side regarding 8037 etc
moving to a more “principled” approach to gas accounting would be high up my priority list for H*, but I worry that trying to change things for G* will block process a lot. better to just try to just ship things now with minimal changes
Stefan Starflinger
Replying to "Any simple way to be..." Felipe has been working on making it possible to run benchmarks with benchmarkoor
Dragan Rakita
Reacted to "from my side regardi..." with ➕
DanielVF | Monad
Reacted to "from my side regar..." with ➕
Stefan Starflinger
Replying to "Any simple way to be..." do you have testing_buildBlockV1 implemented?
Ansgar Dietrichs
Replying to "from my side regardi..." but obv I am missing the implementer perspective, maybe this is impractical
Greg K | Lido
Reacted to "from my side regar..." with 👍
FLCL
And no huge gains?
Łukasz Rozmej
Reacted to "We want to not wait ..." with 👍
Anders Elowsson
Replying to "from my side regardi..." Yeah so EIP-7999 would here be the principled solution, but EIP-8037 is still to our benefit today.
Karim T. (matkt)
Replying to "Depends on how prefe..." As I said I think the devnet 2 has a really small state so not sure we will see huge difference. Compared to only // transactions imo
jochem-brouwer
Antwoord verzenden naar "Any simple way to ..." We are setting up benchmarkoor to run (BAL) benchs against bloatnet (mainnet fork but then beefed up in state) which targets BAL branch in order to run it. So a re-run should then use the new image of that branch
Karim T. (matkt)
Replying to "Depends on how prefe..." But in mainnet or bloatnet I think we will see more better performance imo
Marius van der Wijden
Reacted to from my side regardi... with "➕"
Ansgar Dietrichs
Reacted to "8037 is ☠️" with 😱
DanielVF | Monad
Replying to "from my side regar..." I don't think EIP-8037 has immediate benefits beyond what a simple repricing would do.
Dragan Rakita
Replying to "from my side regardi..." EIP-8037 is really desirable for bigger blocks
Ben Adams
EIP-7999 as H* headliner?
raxhvl
Reacted to from my side regardi... with "➕"
Francesco
Reacted to "EIP-7999 as H* headl..." with 👍
Anders Elowsson
Replying to "EIP-7999 as H* headl..." Hehe late headliner. It will be proposed as a regular EIP
Łukasz Rozmej
8037 is very very complicated
jvn
Reacted to "8037 is very very ..." with 👍
spencer
Reacted to "8037 is very very ..." with 👍
lightclient
Reacted to "8037 is very very co..." with 👍
Guru
Reacted to "8037 is very very co..." with 👍
felix (eest)
Reacted to "8037 is very very ..." with 👍
Ben Adams
Reacted to "8037 is very very co..." with 👍
Łukasz Rozmej
and then we will complicate it even more in next forks
Mario Vega
Reacted to "8037 is very very co..." with 👍
Luis Pinto | Besu
Me likes coherent approach
Ansgar Dietrichs
we won’t be able to completely rework gas (including say blob gas) by Glamsterdam
Daniel Lehrner (Besu)
Reacted to "we won’t be able to ..." with 💯
Stefan Starflinger
Reacted to "8037 is very very co..." with 👍
Marius van der Wijden
I don't think that 8037 is actually that complex. There is a few things about the refund logic
Karim T. (matkt)
Reacted to "We are setting up be..." with 👍
Daniel Lehrner (Besu)
Reacted to "I don't think that 8..." with ➕
Stefan Starflinger
Reacted to "I don't think that 8..." with ➕
Dragan Rakita
Reacted to "I don't think that 8..." with ➕
Toni Wahrstätter
Reacted to "we won’t be able to ..." with 💯
felipe
Reacted to "We are setting up ..." with 👍
Dragan Rakita
EIP-8037 as a change is good, I would not change it at all imo.
felipe
Reacted to "8037 is very very ..." with 👍
Stefan Starflinger
Reacted to "EIP-8037 as a change..." with 👍
Ben Adams
Replying to "I don't think that 8..." Drop refunds? https://eips.ethereum.org/EIPS/eip-3298
spencer
Reacted to "EIP-8037 as a chan..." with 👍
Francesco
What is the alternative? We are not going to do 7999 in Glamsterdam. What is this simple solution?
Dragan Rakita
Replying to "I don't think that 8..." H*
felipe
Reacted to "EIP-8037 as a chan..." with 👍
FLCL
Replying to "Any simple way to be..." Just a draft of testing_buildBlockV1 for now looks like
FLCL
Reacted to "We are setting up be..." with 👍
CPerezz
Replying to "8037 is very very co..." The alternative is doing nothing then wrt. Multidimensional & state-size/growth? I mean, complexity only can’t be an argument. Complex and not useful sure, complex and underspecified sure. But complex only isn’t an argument enough powerful. Marius implemented it in 3 days passing 99% tests. Can’t be that impossibly complicated
FLCL
Reacted to "But in mainnet or bl..." with 👍
Stefan Starflinger
Replying to "Any simple way to be..." when merge?
Ameziane Hamlat
Reacted to "We are setting up be..." with 👍
Stefan Starflinger
Replying to "8037 is very very co..." make no mistakes
Toni Wahrstätter
Reacted to "We are setting up be..." with 👍
Łukasz Rozmej
what did we just changed?
Łukasz Rozmej
Reacted to "make no mistakes" with 👍
Daniel Lehrner (Besu)
Replying to "what did we just cha..." https://github.com/ethereum/execution-spec-tests/releases/tag/bal@v5.4.0
Marius van der Wijden
Replying to "8037 is very very co..." None of it was done with ai, I had an ai version but it was very ugly
Ansgar Dietrichs
if we think it’s at least possible we make larger changes here still, how do ppl feel about bal-devnet-3? still go ahead with 8037 as-is, or delay?
FLCL
Replying to "Any simple way to be..." 🤷‍♂️ Will ping back when merged or can say more
Łukasz Rozmej
Replying to "8037 is very very co..." Ethereum narrative: simplify protocol Ethereum reality: spaghetti? :(
jvn
Reacted to "Ethereum narrative..." with 🙃
spencer
Replying to "what did we just c..." Only EELS spec & test changes in the above release: https://github.com/ethereum/execution-specs/pull/2468
felix (eest)
https://github.com/ethsteel/pm/blob/main/complexity_assessments/EIPs/EIP-8037.md old take but u can see how much pain it is for us
CPerezz
Replying to "8037 is very very co..." Open for improvements. But saying it’s complex doesn’t help simplifying it. Nor gives any alternative solutions 🙁
Stefan Starflinger
I agree
Luis Pinto | Besu
Well I would argue the spaguetti is already there and right now gas cost does not only reflect client effort. Having a coherent solution just makes it leaner.
Maria Silva
I also agree with Spencer
Stefan Starflinger
We wanted to do this EIP early before the others exactly becuase it's not easy but worthwile
Dragan Rakita
Reacted to "We wanted to do this..." with ➕
Ansgar Dietrichs
Reacted to "We wanted to do this..." with 👍
lightclient
how will 8037 and 8038 affect contracts on mainnet?
CPerezz
Replying to "how will 8037 and 80..." I think Carl was running the analysis IIRC. He has all the data. @Carl Beekhuizen
CPerezz
Replying to "how will 8037 and 80..." (For 8037)
Maria Silva
Replying to "how will 8037 and 80..."
the ecosystem
https://x.com/EFprotocol/status/2031056150427242892
Maria Silva
Replying to "how will 8037 and 80..." Also, Carl is currently looking into 7904 and 2870
Maria Silva
Replying to "how will 8037 and 80..." We will do the analysis on 8037 and 8038 next
lightclient
Replying to "how will 8037 and 80..." im looking more for analysis to see what will break when the prices change, not people’s concern level
Maria Silva
Replying to "how will 8037 and 80..." Got it. That analysis is what Carl as been working on
Maria Silva
Replying to "how will 8037 and 80..." We will share when we have final results
Marius van der Wijden
Replying to "how will 8037 and 80..." We will also give grants for security reviews to see what breaks once the eip is in a more final form (hopefully starting in ~2weeks)
Marius van der Wijden
Epbs devnet 0 can be implemented in 1 hour
Marius van der Wijden
Replying to "Epbs devnet 0 can be..." *on EL!
Daniel Lehrner (Besu)
Replying to "Epbs devnet 0 can be..." Where can we see the spec changes needed for the devnet?
Barnabas
Replying to "Epbs devnet 0 can be..." https://notes.ethereum.org/@ethpandaops/epbs-devnet-0
Daniel Lehrner (Besu)
Reacted to "https://notes.ethere..." with 🙏
Barnabas
Replying to "Epbs devnet 0 can be..." For this devnet we are going to use: engine_forkchoiceUpdatedV3 engine_newPayloadV5 engine_getPayloadV5
Barnabas
Replying to "Epbs devnet 0 can be..." we need to be able to trigger amsterdam without activating bal which is the important bit
Łukasz Rozmej
we are open for engine API SSZ as non-consensus change
Ben Adams
Reacted to "we are open for engi..." with 👍
Marius van der Wijden
Reacted to we are open for engi... with "👍"
Lumi | Offchain Labs
Reacted to "we are open for engi..." with 👍
Iván | ethrex
Reacted to "we are open for engi..." with 👍
Luca Donno | L2BEAT
Reacted to "we are open for engi..." with 👍
Luis Pinto | Besu
Replying to "we are open for engi..." Are you fine with adding content-type from HTTP headers into the Ethereum protocol?
Łukasz Rozmej
Replying to "we are open for engi..." Although PR we got from Giulio needs to be compleatly reworked from ground up.
Stefan Starflinger
Reacted to "we are open for engi..." with 👍
Luis Pinto | Besu
Replying to "we are open for engi..." Or how would we do it in a non-consensus way?
Derek Chiang | ZeroDev
Felix posted a summary of the major updates to Frame Txns since the last discussion: https://github.com/ethereum/pm/issues/1955#issuecomment-4046894879
Marius van der Wijden
Replying to "we are open for engi..." We should use this as a shelling point to rework the engine api imho
Łukasz Rozmej
Replying to "we are open for engi..." Isn't it just a transport entry-point? Not sure if we are talking same thing
Barnabas
Replying to "we are open for engi..." https://github.com/ethereum/execution-apis/pull/764
Barnabas
Replying to "we are open for engi..." do you mean this?
FLCL
Reacted to "https://github.com/e..." with 👍
Łukasz Rozmej
Reacted to "https://github.com/e..." with 👍
Ben Adams
Replying to "we are open for engi..." Non-consenus as via discovery either engine capability and/or accept headers
Ben Adams
Reacted to "https://github.com/e..." with 👍
Barnabas
Replying to "we are open for engi..." negotiation could happen with json, but once negotiation is done, it would use ssz if CL and EL both support ssz, otherwise fall back to using json
Ben Adams
Reacted to "negotiation could ha..." with 👍
Luis Pinto | Besu
Replying to "we are open for engi..." >do you mean this? yup
nixo
https://github.com/ethereum/pm/issues/1955#issuecomment-4046894879
Łukasz Rozmej
Reacted to "negotiation could ha..." with 👍
FLCL
May be a separate rest endpint for metadata btw and don't touch capabilties (there rest of the spec is super cool)
Luis Pinto | Besu
I think I would prefer it through an exchange capabilities request instead of using HTTP headers
Lumi | Offchain Labs
Reacted to "Felix posted a summa..." with 👍
Ben Adams
Replying to "we are open for engi..." capabilities exchange has benefit of allowing different urls rather than having to generically parse payload first
Barnabas
Replying to "we are open for engi..." We can hash this out, this is just a detail question
Ben Adams
Reacted to "We can hash this out..." with 👍
Luis Pinto | Besu
Reacted to "We can hash this out..." with 👍
Barnabas
Replying to "we are open for engi..." the main question is whether people are willing to add ssz in their codebase. If the answer to that is a yes, then we should finalize the spec and lets get it merged
FLCL
Replying to "we are open for engi..." http headers are necessary if you mean Accept/Content-Type
Derek Chiang | ZeroDev
What was the reason for the change for Besu?
Lumi | Offchain Labs
Reacted to "What was the reason ..." with ➕
lightclient
IMO the complexity of frame tx is in the txpool, and we have the ability turn the knob of how much the txpool allows based on time available. so i guess i’m not sure what complexity you are worried about?
Ansgar Dietrichs
Reacted to "IMO the complexity o..." with 👍
Felix (Geth)
Reacted to "IMO the complexity..." with 👍
jvn
Reacted to "IMO the complexity..." with 👍
Parthasarathy Ramanujam
Reacted to "IMO the complexity o..." with 👍
Luca Donno | L2BEAT
Reacted to "IMO the complexity o..." with 👍
Orca 0x
Reacted to "IMO the complexity o..." with 👍
Iván | ethrex
Reacted to "IMO the complexity o..." with 👍
Fredrik
Reacted to "IMO the complexity o..." with 👍
Daniel Lehrner (Besu)
Replying to "What was the reason ..." No headliner was not a realistic option when you did a team internal pool the last time. Now that it is, that was preferred. Frame tx and LUCID where close 2nd options.
jvn
IMO When trying out a impl , abstracting mempool , maybe Frame Tx might not be as complicated as I thought
Barnabas
I think not handling frame tx as a headliner could lead to wasting huge amount of resources and not including afterall. Which is not an ideal outcome imo.
FLCL
Frames look a bit like a separate simplest language on top of contract. Might be one top frame with simplified rules.
Lumi | Offchain Labs
Reacted to "I think not handling..." with ➕
Trent
Wasn’t LUCID just rejected 5min ago?
lightclient
I think we can keep LUCID in mind with respect to frame tx design
Luis Pinto | Besu
Replying to "Wasn’t LUCID just re..." What he’s saying is that he wants to look at them both holistically
Ansgar Dietrichs
Reacted to "I think we can keep ..." with 👍
Marius van der Wijden
Replying to "Wasn’t LUCID just re..." Erigon can still work on it if they choose to
Barnabas
I’d prefer to keep our focuses on a single/few EIPs instead of working on mutliple headliner sized EIPs
Greg K | Lido
Reacted to "What he’s saying ..." with 👍
Fabio Di Fabio
Reacted to "What he’s saying is ..." with 👍
Stefan Starflinger
Reacted to "I’d prefer to keep o..." with 👍
FLCL
Reacted to "I think we can keep ..." with 👍
soispoke
Reacted to "I think we can keep ..." with 👍
Łukasz Rozmej
Replying to "IMO the complexity o..." that sounds a bit handwavy, I would like to have a proper mempool spec/consensus as it is a main unknown at the moment
lightclient
it seems like the main concern is that frame tx would delay the next fork? does it change people’s opinion knowing we could simply not allow frame tx in txpool and the implementation is very straightforward
Anders Elowsson
Replying to "it seems like the ma..." But we would like to eventually right?
Ansgar Dietrichs
so say a scenario of shipping frame txs as headliner, but with very limited txpool support at first. would that be worth it?
Dragan Rakita
Reth take is that it is over abstracted and simpler solution would be better in general.
spencer
Reacted to "I’d prefer to kee..." with 👍
Parithosh Jayanthi
TBF we have taken out headliners before
Łukasz Rozmej
It is always harder to remove
Parithosh Jayanthi
Reacted to "It is always harder ..." with 👍🏽
CPerezz
Replying to "Reth take is that it..." You refer to the PQ part? Or the entire thing?
Fredrik
It’s part of the process that we can take it out though, for example if we find security issues and such
DanielVF | Monad
Reacted to "Reth take is that ..." with ➕
Anders Elowsson
From a decision-theoretic perspective, we may have not gathered sufficient information to make a robust decision. The marginal cost of exploring non-headliner EIPs at this point is relatively low, meaning one option is to not take a decision but to start exploring non-headliners over the next month. So that we know what the competition is so to speak.
Danno Ferrin - Tectonic.xyz
It’s less damaging to the process to elevate a feature to headliner than to demote it.
Dragan Rakita
Reacted to "It’s less damaging t..." with ➕
soispoke
That rule of not being able to repropose as a non headliner is still puzzling to me
Marius van der Wijden
There are two competing definitions of headliner 😅
spencer
Footliner?
Maria Silva
Reacted to "That rule of not bei..." with 💯
Josh Davis
Reacted to "Footliner?" with 😂
Maria Silva
Reacted to "Footliner?" with 😂
Lumi | Offchain Labs
Reacted to "Footliner?" with 😂
Iván | ethrex
In ethrex we’ve made an early implementation of EIP-8141. We got it working in 1-2 days. You can take a look at it and see if it looks complex for you https://github.com/lambdaclass/ethrex/pull/6326. There’s some docs listing some gaps and the decisions we took
nixo
Reacted to "Footliner?" with 🦶
soispoke
Reacted to "Footliner?" with 🦶
lightclient
Reacted to "In ethrex we’ve made..." with 👍
Fredrik
Reacted to "In ethrex we’ve made..." with 👍
Greg K | Lido
Replying to "it seems like the ..." I think also people are not convinced of the effectivness of this EIP for the problem is supposed to solve
Shruti Gandhi
Reacted to "Footliner?" with 😂
Derek Chiang | ZeroDev
Reacted to "In ethrex we’ve made..." with 👍
Barnabas
Reacted to "In ethrex we’ve made..." with 👍
Chris H
Reacted to "Footliner?" with 🦶
lightclient
Replying to "it seems like the ma..." that’s not what i’m hearing?
lightclient
Replying to "it seems like the ma..." seems like people are just worried about ability to ship in a timely manner
Iván | ethrex
There’s also a web demo for the e2e with some examples https://demo.eip-8141.ethrex.xyz
Barnabas
I’d like to take the input of not only core devs to make a decision whether we want frame txs or not.
Greg K | Lido
Reacted to "Footliner?" with 😂
Iván | ethrex
Replying to "In ethrex we’ve made..." Using an ethrex dev node
Barnabas
Replying to "I’d like to take the..." we always say that we should listen to the community more, so lets give the floor to them, and hear them out.
Iván | ethrex
Replying to "In ethrex we’ve made..." The code still needs to be cleaned up a little bit, but it’s clear enough
lightclient
one important point to do native AA in H*, if we don’t then smart accounts won’t be able to take advantage of FOCIL
Greg K | Lido
Reacted to "I’d like to take ..." with 👍
jvn
Reacted to "I’d like to take ..." with 👍
Luis Pinto | Besu
Replying to "I’d like to take the..." TBF what I hear mostly about the community it’s to raise code size and nothing about frame txs
Barnabas
Replying to "I’d like to take the..." thats already happening in glammy tho
Luis Pinto | Besu
Replying to "I’d like to take the..." Not lifting the limit altogether, just pushing the bar a bit up
Łukasz Rozmej
I'm also afraid it will end up in YAGNI space and don't get hoped adoption, similar to 7702, due to complexity
CPerezz
Reacted to "I'm also afraid it w..." with 👍
Parthasarathy Ramanujam
Replying to "I’d like to take the..." @Luis Pinto | Besu There is demand for native AA amongst all wallet developers. 8141 seems to be the most popular candidate now. Especially, a poll conducted by @lightclient among wallet and AA developers.
Derek Chiang | ZeroDev
Reacted to "@Luis Pinto | Besu T..." with 👍
lightclient
Replying to "I'm also afraid it w..." this is why we’re adding the default account, it solves these problems for wallets and users that are more skittish
spencer
Reacted to "In ethrex we’ve m..." with 👍
Derek Chiang | ZeroDev
Reacted to "this is why we’re ad..." with 👍
FLCL
We can agree on frames as is not final design, pick at as headliner and improve it on the way. It a significant change that may need more time that usually
lightclient
Reacted to "We can agree frames ..." with 👍
Derek Chiang | ZeroDev
Reacted to "We can agree frames ..." with 👍
Parthasarathy Ramanujam
Replying to "I'm also afraid it w..." The only way, you can increase adoption is by deprecating EOAs. That will get “lazy” users to migrate to smart accounts.
Felix (Geth)
Reacted to "We can agree frame..." with 👍
Fredrik
Reacted to "We can agree frames ..." with 👍
felix (eest)
Reacted to "We can agree on fr..." with 👍
Lumi | Offchain Labs
Reacted to "We can agree on fram..." with 👍
Marius van der Wijden
Reacted to We can agree on fram... with "👍"
Łukasz Rozmej
Reacted to "We can agree on fram..." with 👎
Dragan Rakita
Reacted to "We can agree on fram..." with 👎
Dragan Rakita
Reacted to "I'm also afraid it w..." with 👍
Parthasarathy Ramanujam
Reacted to "We can agree on fram..." with 👍
Iván | ethrex
Reacted to "We can agree on fram..." with 👍
jvn
Reacted to "We can agree on fr..." with 👍
stokes
Reacted to "We can agree on fram..." with 👍
Dragan Rakita
Reacted to "I’d like to take the..." with 👍
frangio
Reacted to "We can agree on fr..." with 👍
Łukasz Rozmej
Frame transaction doesn't solve post quantum, it gives a potential to solve it later
DanielVF | Monad
PQ doesn't require frame transactions though
felipe
Reacted to "Footliner?" with 🦶
Dragan Rakita
Replying to "I’d like to take the..." From devtooling feedback that I shared last time, it is unnecessary complex and bad eip.
Dragan Rakita
Reacted to "PQ doesn't require f..." with 👍
Danno Ferrin - Tectonic.xyz
We need a PQC algo as a precompile
lightclient
hoping we have a PQ precompile as a non-headliner in H* 🙂
FLCL
PQ is not solved at all for now and can be solved purely in parallel by people with very different competency
Greg K | Lido
Reacted to "We need a PQC algo..." with 👍
Luis Pinto | Besu
Reacted to "We need a PQC algo a..." with 👍
lightclient
guys 7702 has 4 million ops per week
Barnabas
Reacted to "@Luis Pinto | Besu T..." with 👍
Parthasarathy Ramanujam
Reacted to "guys 7702 has 4 mill..." with 👍
Ansgar Dietrichs
7702 is very synergistic with native AA, because it allows EOAs to upgrade to smart accounts that can then use e.g. frame txs
CPerezz
Replying to "hoping we have a PQ ..." Can’t cheaper compute and bigger gas limits get us there already without precompiles?
soispoke
One thing to maybe keep in mind is that we’re also deciding very early (compared to last time) so in theory it gives more time to iterate on EIPs after the decision point
Felix (Geth)
Most definitely there will be iteration on the EIP
DanielVF | Monad
Reacted to "guys 7702 has 4 mi..." with 👍
Ansgar Dietrichs
Replying to "7702 is very synergi..." then we’d just at some point have to introduce a way to fully revoke the original ecdsa key
Marc
Reacted to "We can agree on fram…" with 👍
Parthasarathy Ramanujam
Adoption of 7702 or the lack of it, wasn’t due to the EIP, it was the reluctance of few wallets to support it and also due to a lot of false information spread about “alleged” vulnerabilities!
Trent
Reacted to "guys 7702 has 4 mill..." with 👍
Nico Consigny
FCLC for some reason I can't reply directly to
Luis Bezzenberger
Reacted to I think we can keep ... with "👍"
Nico Consigny
> PQ not solved at all
Luis Bezzenberger
Reacted to Erigon can still wor... with "👍"
Łukasz Rozmej
Replying to "Adoption of 7702 or ..." so won't they have similar issues with frame transactions?
lightclient
Replying to "Adoption of 7702 or ..." i think the default code will basically guarantee that frame tx has wide adoption
Parthasarathy Ramanujam
Replying to "Adoption of 7702 or ..." As I said earlier, unless EOA are specifically deprecated, you wont have users migrate. But the default code definitely help here.
Orca 0x
Reacted to "i think the default ..." with 👆
Parthasarathy Ramanujam
Reacted to "i think the default ..." with 👆
Łukasz Rozmej
Replying to "Adoption of 7702 or ..." @lightclient but then it is basically standard transaction?
Ahmad Bitar | Nethermind
My personal stance is to support frame as headliner for hegata
Barnabas
What do EL teams want to work on in the second half of this year, if they oppose all headliners?
lightclient
Replying to "Adoption of 7702 or ..." it is a standard tx, but it doesn’t make non standard accounts 2nd class
lightclient
Replying to "Adoption of 7702 or ..." which is important
Marc
Reacted to "My personal stance i…" with ➕
Barnabas
does ethrex count?
Francesco
Sorry but reth should clearly not be considered in this decision?
Iván | ethrex
+1 for ethrex
nixo
i think the idea here was clean up on a lot of non-headliners (based on comments from last ACDE)
Luca Donno | L2BEAT
Reacted to "Sorry but reth shoul..." with 👍
Dragan Rakita
Replying to "Sorry but reth shoul..." Why is that?
Francesco
Replying to "Sorry but reth shoul..." There’s a clear conflict of interest\
lightclient
Reacted to "Sorry but reth shoul..." with 👍
spencer
Reacted to "Why is that?" with 👍
Luca Donno | L2BEAT
Reacted to "There’s a clear conf..." with 👍
soispoke
Reacted to "Sorry but reth shoul..." with 👍
Trent
Reacted to "Sorry but reth shoul..." with 👍
Trent
Reacted to "There’s a clear conf..." with 👍
Francesco
Replying to "Sorry but reth shoul..." (I don’t care or have opinions about frame txs at all fwiw)
Ahmad Bitar | Nethermind
Reacted to Sorry but reth shoul... with "👍"
Barnabas
@Daniel Lehrner (Besu) its a chicken and egg
Parthasarathy Ramanujam
Reacted to "Sorry but reth shoul..." with 👍
Barnabas
you could make it the majority lol
Lumi | Offchain Labs
Reacted to "you could be the maj..." with 😂
Dragan Rakita
Replying to "Sorry but reth shoul..." This does not make sense, we still think what is better for eth protocol
Mega | Lambda
Reacted to "+1 for ethrex" with 👍
Francesco
Replying to "Sorry but reth shoul..." You can say that and we can choose to believe you, there’s still a glaring conflict of interest
Pablo Deymo | Lambda
Reacted to "+1 for ethrex" with 👍
Dragan Rakita
Replying to "Sorry but reth shoul..." Frame tx or not, it does not effect tempo at all.
Josh Davis
Reacted to "Sorry but reth shoul..." with 👍
jonny (geth)
Reacted to "you could make it th..." with 👍
Hsiao-Wei Wang
Reacted to "@Luis Pinto | Besu T..." with ❤️
Anders Elowsson
Replying to "What do EL teams wan..." 7999 😎
Giulio
Unreal chat
Daniel Lehrner (Besu)
Reacted to "you could make it th..." with 😂
Luca Donno | L2BEAT
Reacted to "You can say that and..." with 👍
Ansgar Dietrichs
Reacted to "Unreal chat" with 😂
FLCL
3h sound scary now, 2 days may be a lot 😂
Dragan Rakita
Replying to "Sorry but reth shoul..." We did a lot good for the protocol, this just feel a bad take.
Chris H
Reacted to "3h sound scary now, …" with 😂
Fredrik
Reacted to "My personal stance i..." with ➕
Francesco
Replying to "Sorry but reth shoul..." On a personal level, I believe you. But it is a conflict of interest, there’s a competing standard being proposed essentially...
lightclient
mempool rules: https://eips.ethereum.org/EIPS/eip-7562
lightclient
i wouldn’t say that “it isn’t defined” we just have to decide how much of 7562 we want in the core protocol
lightclient
it is very well thought through and thorough
Ansgar Dietrichs
I will keep the discussion open for however much longer there are things to discuss, but I would need either Besu, Nethermind, or reth to flip to frame tx headliner support to not then propose rejecting this headliner proposal at the end.
Iván | ethrex
Reacted to "Sorry but reth shoul..." with 👍
Marius van der Wijden
Replying to "Sorry but reth shoul..." I agree, Reth should be able to voice their opinion, even if they have a conflict of interest. I would hope that they won't die on the hill of not implementing it if it came to that though.
Marc
Replying to "I will keep the disc…" Nethermind team is split on this, personally I would be open to making headliner
Pablo Deymo | Lambda
Reacted to "Sorry but reth shoul..." with 👍
DanielVF | Monad
EIP-8141 spec metions rules "similar to" https://eips.ethereum.org/EIPS/eip-7562
Dragan Rakita
Replying to "Sorry but reth shoul..." If you believe me, you wouldn’t state it like that, it is really hurtful. The outcome we all want is what is best for etheream, proposing different approach does not make our vote invalid. It is just a bad take.
Ansgar Dietrichs
Reacted to "Nethermind team is s..." with 👍
Francesco
Replying to "Sorry but reth shoul..." It’s not personal, really
Lumi | Offchain Labs
Reacted to "Nethermind team is s..." with 👍
Mega | Lambda
Reacted to "Sorry but reth shoul..." with 👍
lightclient
Reacted to "Nethermind team is s..." with 👍
Francesco
Replying to "Sorry but reth shoul..." And one thing is expressing an opinion, a different thing is getting a “vote”. Seems very standard to not get a vote when there’s a clear conflict of interest?
Lumi | Offchain Labs
Replying to "I will keep the disc..." Where is Tomasz when we need him 😜
Alex Forshtat
Replying to "Sorry but reth shoul..." Just a question, why didn't Reth propose Tempo transactions for Hegota headliner?
soispoke
Replying to "i wouldn’t say that ..." I agree, the only thing to point out is that this was designed without FOCIL in mind which will impact some of the parameters (e.g., VERIFY gas)
Dragan Rakita
It is like saying drop everyone oppinion except geth
lightclient
some non-headliners may depend on frame tx, such as tx assertions. this is a very important upgrade to improve security of transacting on ethereum
lightclient
Replying to "some non-headliners ..." frame tx works very well for this because you can have a post-op frame to analyze the outcome of other frames
lightclient
Reacted to "I agree, the only th..." with 👍
Ahmad Bitar | Nethermind
Reacted to Nethermind team is s... with "👍"
Giulio
Replying to "Sorry but reth sho..." Claude, should Reth be included in decision-making? Make no mistakes.
Dragan Rakita
Replying to "Sorry but reth shoul..." @Francesco I don’t see the conflicts, as I said implementation of frame does not touch tempo. Modular approach of reth allows that.
Alex Forshtat
Reacted to Sorry but reth shoul... with "👍"
DanielVF | Monad
Replying to "some non-headliner..." Will need batch reverting frame ability for post-op frame checks, which I think you are planning on adding?
jvn
I think a year is actually plenty of time to revise the EIP if needed and implement it properly. The benefits could be significant - bringing native account abstraction and even leaving room for a post-quantum pathway. Considering that, Making it as a headliner might actually be worthwhile. IMO
FLCL
Maybe something can be done with tx gossip scores or so
lightclient
Replying to "some non-headliners ..." there are a few ways it could be implemented. i personally imagined it would be done by only approving payment at end of tx
Lumi | Offchain Labs
Reacted to "I think a year is ac..." with ➕
lightclient
Reacted to "I think a year is ac..." with 👍
lightclient
Reacted to "I think a year is ac..." with ➕
Shruti Gandhi
Reacted to "I think a year is ac..." with ➕
Fredrik
Replying to "some non-headliners ..." This is that it’s one of the most asked for features by end users as it basically protects users against drainers and other types of attacks, and is coming from many discussions with various parties during 1TS
Parthasarathy Ramanujam
Reacted to "I think a year is ac..." with ➕
Emma
I do not think it is fair to say we shouldn’t be considered in the decision making, when we are clearly supporting and working hard on Reth for Ethereum….
Iván | ethrex
Reacted to "I think a year is ac..." with ➕
Parthasarathy Ramanujam
Isn’t there a native tracer built (in geth) that validates a transactions against erc7562 rules?
Parthasarathy Ramanujam
Wouldn’t that help with most of the complexities associated to mempool validation?
lightclient
Replying to "Is there a native tr..." we would just run the evm in a specific mode
Parthasarathy Ramanujam
Replying to "Isn’t there a native..." I blame auto-correct. I was supposed to type “Isn’t”
Parthasarathy Ramanujam
Reacted to "we would just run th..." with 👍
Danno Ferrin - Tectonic.xyz
Replying to "Sorry but reth shoul..." So one of the arguments is “Frame beacuse no alternateives have been proposed” and then when reth proposes an alternative they get penalized?
Francesco
Replying to "Sorry but reth shoul..." I never said anything about decision making in general, this just happens to be a case when there’s a conflict of interest, in my opinion. You can disagree on that, fine, agree to disagree
Felix (Geth)
Just to clarify, Fredrik is talking about the ability to add arbitrary post-conditions to any transaction. Notably this feature is not related with the mempool at all.
soispoke
fwiw implementing encrypted mempools designs (e.g., LUCID) on top of frame txns is quite nice
Fredrik
Reacted to "Just to clarify, Fre..." with 👍
Enrico Del Fante (tbenr)
The security argument is very appealing
Nico Consigny
Nethermind team is splitted
nixo
if we settle on “no headliner” - can we also get a decision on whether or not it can come back as a non-headliner since that’s technically been against process since the headliner process was introduced? but seems reasonable that acd can overrule
Dragan Rakita
Replying to "Sorry but reth shoul..." We are sharing experience from something that we already have, so hope from here that synergy can be taken.
frangio
Reacted to "if we settle on “..." with 👍
Alex Forshtat
Replying to "Sorry but reth shoul..." @Danno Ferrin - Tectonic.xyz But Tempo transactions are not formally proposed for Hegota, are they?
Lumi | Offchain Labs
Reacted to "if we settle on “no ..." with 👍
Łukasz Rozmej
I personally don't know, I dont want to block it, but I still see the risk of adding it and then potentially removing as a headliner
Danno Ferrin - Tectonic.xyz
Replying to "Sorry but reth shoul..." This hiding behind process is not a good look.
Ahmad Bitar | Nethermind
Replying to "if we settle on “no ..." It frame cannot come back as a non headliner then i believe we should have it in
Barnabas
Can we wait another 2w in deciding? I’m usually not into delaying decisions but its really on the edge.
Danno Ferrin - Tectonic.xyz
Replying to "Sorry but reth shoul..." process should reflect consensus, not enforce it.
Dragan Rakita
Replying to "Sorry but reth shoul..." For example this is improvement ever tempo in terms in EIP: https://eips.ethereum.org/EIPS/eip-8175 that would be even better than tempo,
Derek Chiang | ZeroDev
What would need to change to change Besu/Nethermind/Reth’s minds?
Trent
Reacted to "Can we wait another ..." with 👍
Dragan Rakita
Echoing that we all want to improve protocol, and think what is best for it.
Felix (Geth)
can we promote it to headliner later?
lightclient
Reacted to "can we promote it to..." with 🔥
Ben Adams
Reacted to "can we promote it to..." with 🔥
Tamaghna Choudhuri
Reacted to "can we promote it to..." with 😆
Felix (Geth)
like what if it turns out really good
Dragan Rakita
Replying to "Sorry but reth shoul..." I will start referring this as composable tx. This is not a headliner as it is smaller scope
Luca Donno | L2BEAT
Reacted to "Can we wait another ..." with 👍
Dragan Rakita
Reacted to "I do not think it is..." with 👍
Lumi | Offchain Labs
Reacted to "can we promote it to..." with 😆
Alex Forshtat
Reacted to I will start referri... with "👍"
Ansgar Dietrichs
can we get a temperature check on delaying the decision? 👍 = delaying decision 👎 = make decision today
lightclient
does anyone want to absolutely block it if we accept as headliner?
soispoke
Reacted to "can we get a tempera..." with 👍
lightclient
maybe another way to frame the Q
Lumi | Offchain Labs
Reacted to "can we get a tempera..." with 👍
Ben Adams
Replying to "does anyone want to ..." I don't think we'd block
Barnabas
if majority of nethermind is for it, then thats the decider
Fredrik
I think the security improvement alone is really valuable. People are losing hundreds of millions of USD each year, and this together with transaction assertions could remove or at the very least significantly reduce that
Nicolas Consigny
Reacted to "I think the security..." with 👍
Parithosh Jayanthi
Also note that we have a lot of ZK related priorities the next few forks. If we don’t do frame txs now, I don’t imagine us getting another chance for a while.
lightclient
Reacted to "Also note that we ha..." with 👍
Lumi | Offchain Labs
Reacted to "Also note that we ha..." with 👍
Lumi | Offchain Labs
Reacted to "I think the security..." with 👍
Barnabas
Reacted to "I think the security..." with 👍
Felix (Geth)
we can work out some prototype rules within 2 weeks
Ameziane Hamlat
Reacted to "can we get a tempera..." with 👍
felipe
Reacted to "I think the securi..." with 👍
Barnabas
Reacted to "Also note that we ha..." with 👍
Mega | Lambda
Reacted to "maybe another way to..." with 😂
Luca Donno | L2BEAT
Reacted to "can we get a tempera..." with 👍
Guillaume
Replying to "Also note that we ha..." priorities change
Orca 0x
Reacted to "we can work out some..." with ❤️
Luca Donno | L2BEAT
Reacted to "we can work out some..." with ❤️
Łukasz Rozmej
Replying to "we can work out some..." make sense to me, to try
Orca 0x
Replying to "we can work out some..." rule clarity in 8141 itself is essential
Parthasarathy Ramanujam
Reacted to "we can work out some..." with ❤️
frangio
Reacted to "we can work out so..." with 👍
Łukasz Rozmej
Reacted to "we can work out some..." with ❤️
Parithosh Jayanthi
Reacted to "priorities change" with 😅
Łukasz Rozmej
Reacted to "we can work out some..." with 👍
nixo
i’m for delaying this decision - it seems a bit like support is broad but weak just because of a lack of familiarity / the newness of the EIP. i think it’s on the champions to shore up people’s opinions over the next two weeks
Emma
Replying to "Sorry but reth shoul..." I do not see where the conflict of interest lies…. We are here representing Reth for the Ethereum community. My thoughts are that frame txs introduce more account abstraction galaxy braining by delegating complexity into frames. Developers don't want to work with defining "frames". Reduces complexity in the sense that we don't need a "bundler" (which imo is like 5% of the problem of current AA landscape), but then introduces a ton of complexity on devtooling layer (both contracts and app devtools like viem), and makes account orchestration flows super difficult to reason about. Generally think accounts don’t need to be galaxy brained abstracted for 95% of real world users. We should enshrine native features for the 95%, and escape hatch to account abstractions for the 5%. This proposal is good for the 5% and migrating to PQ: https://github.com/ethereum/EIPs/pull/11330
felix (eest)
my main impression from the eth mag thread is that many people were sceptical at first but as the EIP got clarified they understood its value and now most support it
Guillaume
Replying to "Also note that we ha..." allocating 3+ years just to zk is a bad idea - so we'll need to make room for other stuff anyway.
nixo
Reacted to "priorities change" with 😅
Shruti Gandhi
Reacted to "Also note that we ha..." with 👍
nixo
Reacted to "priorities change" with 🌳
Parithosh Jayanthi
Reacted to "priorities change" with 🌳
Emma
Reacted to "I don't think we'd b..." with 👍
lightclient
what do people want to see in 2 weeks to sway opinion?
Derek Chiang | ZeroDev
Replying to "Sorry but reth shoul..." I think it’s unfair to discount Reth’s opinion because of perceived conflict of interests. That said, I’m also trusting that Reth will go along with the decision if the clear majority is for it
Barnabas
frame-devnet-0 😂
lightclient
Replying to "what do people want ..." we can definitely build a prototype and bring txpool rules into 8141 itself
Justin Traglia
Reacted to "Sorry but reth shoul..." with 👍
Nicolas Consigny
Replying to "what do people want ..." More txpool rules ?
Justin Traglia
Reacted to "There’s a clear conf..." with 👍
Nicolas Consigny
Replying to "what do people want ..." yes this would be good
Nicolas Consigny
Reacted to "we can definitely bu..." with 👍
Orca 0x
Reacted to "we can definitely bu..." with ❤️
Iván | ethrex
Let us know how we can help here, we’ll be glad to do it
Chris H
Reacted to "we can definitely bu…" with 👍
Nicolas Consigny
Reacted to "Let us know where we..." with 🙏
lightclient
Reacted to "Let us know where we..." with 👍
Luca Donno | L2BEAT
Reacted to "Let us know how we c..." with 🔥
Toni Wahrstätter
Reacted to "we can definitely bu..." with ❤️
Ben Adams
Reacted to "we can definitely bu..." with ❤️
Ben Adams
Reacted to "we can definitely bu..." with 👍
Barnabas
Reacted to "Let us know how we c..." with 🔥
Łukasz Rozmej
Replying to "what do people want ..." some base on realistic tx pool rules

Call summary

Targets

•March 19 - Repricing breakout to resolve EIP-8037/7928 alignment - 00:22:28
•March 26 - Final frame transactions headliner decision - 01:25:37

Decisions

•SSE/Pure ETH rejected as Hegotá headliner - 00:39:56
•Lucid rejected as Hegotá headliner - 00:40:56
•Frame transactions headliner decision delayed to March 26; requires Besu, Nethermind, or Reth support to proceed - 01:33:46

Highlights

Testing Progress:
- ·bal-devnet-2: Aragon syncing issues being fixed; benchmarking shows prefetch slower than expected - 00:07:30
- ·bal-devnet-3 blocked: most clients not ready for EIP-8037; test release 5.4.0 available - 00:09:36
- ·epbs-devnet-0: running 1 week, Lighthouse/Lone Star/Prism working; Teku/Nimbus joining; exits/builders not working - 00:33:05
Repricing Updates:
- ·Repricing breakout scheduled next Wednesday to address 8037 complexity and align with 7928 - 00:22:02
Headliner Selection:
- ·SSZ/Pure ETH rejected as Hegotá headliner; focus on out-of-protocol implementation - 00:39:28
- ·Lucid rejected as Hegotá headliner; can be reconsidered for I-Star - 00:40:56
- ·Frame transactions support: 2 clients favor (Geth, Aragon); 3 prefer no headliner (Nethermind split, Besu, Reth) - 00:48:54
- ·Post-quantum urgency highlighted: DAO migration timeline 2028-2029 requires native AA soon - 01:00:30
Critical Infrastructure:
- ·EIP-8037 concerns raised: gas accounting complexity across 7928, 7778, 8037, blob gas needs principled alignment - 00:10:47
- ·8037 implementation complexity: refund logic, state gas reservoir, testing gaps identified - 00:26:02
Fork Status And Schedule:
- ·Glamsterdam devnet progress: bal-devnet-2 running, devnet-3 delayed pending EIP-8037 resolution - 00:07:01
- ·SSZ experiments for engine API proposed as non-consensus change - 00:40:15
- ·Frame transactions headliner decision delayed 2 weeks; default is rejection without additional client support - 01:25:37

Action Items

•Maria Silva, Andrew Ashikhmin, all interested teams - Repricing breakout next Wednesday: address 8037/7928 alignment and mempool rule clarity - 00:22:28
•Felix, Geth team, ethrex - Frame transactions champions: develop prototype mempool rules, clarify 8141 txpool spec for 2-week review - 01:26:30

Key decisions

SSE/Pure ETH rejected as Hegotá headliner
headlinerRejected in favor of another headliner
Lucid rejected as Hegotá headliner
headlinerRejected in favor of another headliner
Frame transactions headliner decision delayed to March 26; requires Besu, Nethermind, or Reth support to proceed
headlinerDelayed due to lack of support from certain clients

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