AllCoreDevs - Execution #231

gm

Gmgm

gm

gm

gm

link to agenda: https://github.com/ethereum/pm/issues/1931

https://dora.blob-devnet-0.ethpandaops.io/

https://dora.bal-devnet-2.ethpandaops.io

https://dora.nft-devnet-10.ethpandaops.io

Replying to "https://dora.nft-dev..." good to see nfts living on in devnet form at least

https://dora.perf-devnet-3.ethpandaops.io

Reacted to "good to see nfts liv..." with 😅

Reacted to "good to see nfts l..." with 😅

Reacted to "good to see nfts liv..." with 😅

Reacted to "good to see nfts liv..." with 😅

https://notes.ethereum.org/@ethpandaops/bal-devnet-3

Whats the hardcoded value? @spencer

Replying to "https://dora.nft-dev..." gotta keep the memes alive

At a 100M block gas limit, cost_per_state_byte = 1174.

Replying to "At a 100M block ga..." Lets add this to devnet-3 markdown.

https://notes.ethereum.org/j65MUa-KTB-hZ2kDrijS9A

could you pls paste the pr?

the new pr: https://github.com/ethereum/execution-apis/pull/758

https://github.com/ethereum/execution-apis/pull/758

client devs, please leave a comment on the PR to indicate your support and/or any changes you wish to see

Thank you

that was one of my comment

we should have support for filtering

Which eip is the Lucid one?

The EIP is in draft stage, we will share over the weekend

Reacted to "The EIP is in draft ..." with 👍🏻

Replying to "The EIP is in draft ..." Ok great! Thanks 😊

Erigon: https://github.com/ethereum/pm/issues/1931#issuecomment-3961108850

Besu: https://hackmd.io/@YwTR7izNSrCEQYKWdzdy_Q/Syutq86OZe

Reacted to "Ok great! Thanks 😊" with 👍

Geth: https://notes.ethereum.org/@lightclient/h-is-for-hardness

“All encrypted mempools we are aware of suffer from substantial metadata leakage like nonce, gas limit, etc. and this proposal is no different.” What kind of leakage are you referring to?

Shutter is deployed on Gnosis Chain

How does metadata leak?

How does Lucid leak that? If anyone can send for others

Replying to "How does Lucid leak ..." It shouldn’t

Nethermind proposal: No EIPs for bogota 😂

“no headliner for the EL” is a valid option

Reacted to "“no headliner for th..." with 👍

Reacted to "“no headliner for th..." with 👍

Just to note: my personal opinion is to not choose an EL headliner for Glamsterdam. I think all proposed eips are not ready yet

There was another EIP alternative for new transaction signatures without Frame transactions

Reacted to "“no headliner for th..." with 👍

Replying to "Just to note: my per..." glamsterdam?

Reacted to "Just to note: my per..." with ➕

Replying to "There was another ..." we can go into that

Replying to "There was another EI..." Yeah it was by base

Replying to "Just to note: my per..." Sorry H*

Reacted to "Just to note: my per..." with 👍🏽

Reacted to How does Lucid leak ... with "👍"

Replying to "There was another ..." it would be good to settle this early on

Reacted to "“no headliner for th..." with 👍

Reacted to It shouldn’t with "👍"

Reacted to "“no headliner for..." with 👍

Reacted to Shutter is deployed ... with "👍"

Reacted to Just to note: my per... with "➕"

Reacted to "Just to note: my per..." with ➕

I also hope I am here :-)

Reacted to "I also hope I am her..." with 😂

Reacted to "I also hope I am her..." with 😂

Replying to "I also hope I am her..." Didn’t know if Jen joined or not 🙂

Replying to "I also hope I am her..." haha yes makes sense

Reacted to "I also hope I am her..." with 😂

since claude 4.6 😂

Łukasz Rozmej: Actually I have not-so optimistic AI summary, as soon as I want to do something more exploratory AI fails on its face immediately. It works decent for smaller bugs ect.

Reacted to "since claude 4.6 😂" with 🔥

Reacted to "since claude 4.6 😂" with 🔥

Reacted to "since claude 4.6 �..." with 🔥

Reacted to "Actually I have no..." with 👍

Replying to "There was another ..." From Geth side, we feel very strongly that Frame Transactions are superior because it moves the problem completely to user space. We also want to bundle this with account abstraction because we see it overdue that users move to contract based wallets as first class citizens.

Replying to "Actually I have not-..." Everyone should read this: https://x.com/yq_acc/status/2026678055092236438

Replying to "since claude 4.6 😂" amp is good

Reacted to "Actually I have not-..." with 👍

Nimbus EL: https://github.com/ethereum/pm/issues/1931#issuecomment-3966735519

Reacted to Actually I have not-... with "👍"

Reacted to "Everyone should re..." with 👀

Reacted to "Actually I have no..." with 👍

Reacted to "since claude 4.6 😂" with 🔥

Reacted to "since claude 4.6 😂" with 🔥

Reacted to "Actually I have no..." with 🤔

Reacted to "since claude 4.6 �..." with 🔥

Reacted to "Everyone should re..." with 👀

Replying to "There was another EI..." Frame transaction becomes a nightmare for dev tooling. Feedback that we got is that is over abstracted and simpler solution would be a lot more powerful.

Reacted to "Frame transaction be..." with ➕

Reacted to "Frame transaction be..." with ➕

Replying to "There was another EI..." It does make EVMs more complex contrary to what is the long term goal with lean

Doing nothing seems like a waste of 2026

Replying to "There was another EI..." I have one proposal for “Amsterdam tx” the I vibe coded, and additionally something like tempo tx is good example.

Reacted to "Doing nothing seem..." with 👍

Reacted to "Doing nothing seems ..." with 👍

Replying to "There was another EI..." Dev tooling can now also profit from AI significantly no? Dev tooling can’t be a reason to not improve the protocol. It’s nonsense

Reacted to "Doing nothing seems ..." with 👍

Replying to "Actually I have not-..." Agent performance correlates almost perfectly with how much novel, non-public knowledge the project demands. ClawNews (CRUD) was effortless. ETH2030 (ZK primitives with barely any public documentation) required line-by-line guidance for anything beyond boilerplate.

Reacted to "Doing nothing seem..." with 👍

Replying to "There was another ..." I don't understand why it makes dev tooling complicated

Replying to "Doing nothing seems ..." It means doing more low-level EIPs like EIP-7999 for example though

Reacted to It means doing more ... with "👍"

Replying to "There was another EI..." We are discussing improvements to the protocol. We can’t have it all

Replying to "Doing nothing seems ..." “Doing nothing” is essentially “ship more EIPs”

Yeah it's not time-sensitive

Replying to "There was another ..." I understand that it requires an initial investment from the wallet side to support it

Replying to "There was another EI..." Frame tx sigs are not severable fro the data, see my crypto agility slides from PQTS #1. If we are going to aggregate sigs they shouldn’t be in-line

Replying to "Doing nothing seems ..." I don’t see them as equivalent

Replying to "Doing nothing seems ..." It’s more non-headliners vs a controvertial headliner

Replying to "There was another EI..." Do we really need to give signature abstraction power to users? When PQ comes don’t we just need a signature in the end? This might proliferate unsafe signature schemes

we would still ship whatever EIPs are ready when FOCIL ships

Replying to "There was another ..." They don't have to be attached to the tx. It is feasible to remove VERIFY frames from transactions when they go into the block.

Replying to "Doing nothing seems ..." We did it in Osaka, and that was well receieved.

Reacted to "we would still ship ..." with 👍

Replying to "There was another ..." @Luis Pinto | Besu let's discuss it in a separate call

Replying to "There was another ..." I don't think we will reach a conclusion here in Zoom comments

I think it is between Frame and “do nothing"

Replying to "There was another EI..." @Dragan Rakita could you elaborate a bit on the dev tooling point? Do you have some examples? What is the root cause that tempo tx wouldn’t lead to the same problems?

Reacted to I think it is betwee... with "👍"

Reacted to "we would still shi..." with 👍

How long before were the other proposals raised?

Replying to "There was another EI..." This is full feedback: Frame Transactions 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. Should enshrine native features for the 95% (a la. Tempo transactions), and escape hatch to account abstractions for the 5%.

Replying to "How long before were..." Frame txs was recent but fairly advanced versions of native AA have existed for a long time and have received a lot of thought

Reacted to "Frame txs was recent..." with 👍

Replying to "How long before were..." Can we really say that we’d know what we’re getting into with encrypted mempools?

Reacted to "Can we really say th..." with 👍

Reacted to "Frame txs was recent..." with 👍

For Nimbus, frame tx's are a fine fallback

Replying to "There was another EI..." Imo listing what frame tx does, and doing exactly this concrete implementation would give better results.

Replying to "How long before were..." Perfectly valid point. I just said we do not leak metadata 🙂

we still have 45 mins

Reacted to "we still have 45 min..." with 👍

lets just talk about it now?

Replying to "There was another EI..." Thanks @Dragan Rakita !

Reacted to we still have 45 min... with "👍"

Reacted to "we still have 45 min..." with 👍

Reacted to "lets just talk about..." with 👍

Reacted to "we still have 45 min..." with 👍

If people really want to do a headliner but neither of these two (not saying this is the case, but if it comes to that), let’s please not select something just for the sake of it? Would be better do either do nothing or reopen headliner proposals, not just choose something out of a list of two just because this is the process

Reacted to "If people really wan..." with 👍

potentially same breakout/Q&A for LUCID?

Reacted to "potentially same bre..." with 👍

Reacted to "If people really wan…" with 👍

If people who make the decisions are here, then we can assume qorum

Replying to "potentially same bre..." I don’t feel like there is enough interest in LUCID

Replying to "potentially same bre..." wut

I think if there's nothing else, this is the most important thing to discuss

i.e if we were fine with making the decision with this crew, we can do the FRAME discussion with the same group

Replying to "potentially same bre…" Wur

Replying to "potentially same bre..." Only 1 client

Replying to "potentially same bre…" Wut*

Replying to "potentially same bre..." i mean, not on this call right now, sure.

I feel like we should do an in depth discussion an announced breakout call

Have discussion now, make decision next week

Replying to "If people really wan..." If there is something new proposed that is aligned with zkVM roadmap would make it priority for inclusion over current EIPs

Reacted to "i.e if we were fine ..." with ➕

Reacted to "Have discussion now,..." with 👍

Reacted to "If people really wan..." with 👍

Replying to "potentially same bre..." What clients aren’t on the call?

Replying to "potentially same bre..." Erigon mentioned LUCID

Reacted to "If people really wan..." with 👍

But they chose Frame over LUCID

Reacted to "Screenshot2026_02_26_154444.jpg" with 🤣

Replying to "potentially same bre..." we are also not opposed per se, just not convinced

Reacted to "Screenshot2026_02_26_154444.jpg" with 🤣

Reacted to "Screenshot2026_02_26_154444.jpg" with 🤣

Reacted to "If people really wan..." with 👍

Reacted to "Screenshot2026_02_..." with 🤣

Reacted to "potentially same bre…" with 👍

Ah ok then we should use time remaining to discuss now, missed that this was all of agenda

Replying to "potentially same bre..." nobody is proposing spending the rest of the call on LUCID.

Reacted to "Have discussion now,..." with 👍

Reacted to "Screenshot2026_02_..." with 🤣

Reacted to "Screenshot2026_02_..." with 🤣

Replying to "potentially same bre..." yes but those two would robably closest to compeating for headliner, so why not?

Reacted to "Screenshot2026_02_..." with 🤣

Replying to "potentially same bre..." yep having breakout call

No headliner does not mean nothing. It means there’s room for more smaller EIPs. Many of these can have outsized impact to effort.

Reacted to "No headliner does no..." with 👍

right, so no headliner could enable: faster fork more non-headliner EIPs

Replying to "How long before were..." For the record, I also think encrypted mempools have under thought issues, just didn’t like the argument of “when they were proposed” to dismiss them. If anything it seems to me that what’s wrong is trying to choose H headliners too early IMO

There is an Encrypted Mempool working group call next Wed. Happy to go over LUCID there.

Reacted to "There is an Encrypte..." with 👍

Reacted to "There is an Encrypte..." with 👍

Reacted to "There is an Encrypte…" with 👍

Replying to "Screenshot2026_02_26_154444.jpg" I like this notion 😄

How much adoption do you expect to happen for frametxs? What are the problems with 7701 that this should fix?

Reacted to "Screenshot2026_02_26_154444.jpg" with 🤣

I personally would have a question about intention of frame txs. is this mostly for post-quantum? or is the idea to really move over the ecosystem to AA with this? what are the timeline expectations here?

Reacted to There is an Encrypte... with "🔥"

Replying to "Screenshot2026_02_26_154444.jpg" @lightclient this is not how you sell me this pen 😂

Reacted to "@lightclient this is..." with 😂

How “in the weeds” do we want to get with the questions?

From Besu side I do not think we can make a comittment today. Not everybody is on the call. We’ll definitely need a few days to decide between Frame Transactions and no headliner

Replying to "Screenshot2026_02_26_154444.jpg" I’m not a salesman guys I’m sorry

Reacted to "@lightclient this is..." with 😂

Replying to "From Besu side I do ..." Yeah that’s okay

Replying to "From Besu side I do ..." I don’t think we expect a decision

Replying to "From Besu side I do ..." right, that was my thinking for prefering a breakout call

Reacted to For the record, I al... with "👍"

Reacted to "right, that was my t..." with 👍

Reacted to "right, that was my t..." with 👍

Replying to "From Besu side I do ..." to allow such people not on the call today to ask questions as well

Replying to "I personally would..." One of the appealing parts for me personally is exactly that it's not entirely this single-purpose EIP which adds complexity for precisely one purpose, but strikes a reasonable design point regarding functionality vs complexity for several Ethereum roadmap goals at once

Reacted to "right, that was my..." with 👍

it seems to me like it will likely be a decision between frame txs and no headliner, with an outside chance for LUCID still

https://eips.ethereum.org/EIPS/eip-7932 Is another way to solve the signature problem while using ssz This design allows for all the ecc sigs with ml-dsa and nl-dsa or even hash based ones

Example of simpler solution: https://github.com/ethereum/EIPs/pull/11355 (Done it today)

Replying to "https://eips.ethereu..." It has previous version that doesn't depend on SSZ, it was removed in this PR: https://github.com/ethereum/EIPs/pull/10754

also this https://github.com/ethereum/EIPs/pull/11330

Reacted to "also this https://gi..." with ➕

having worked on AA myself as well (EIP-2938, was rejected by acd in 2020), it seems clear that frame txs are the correct general purpose approach to enshrined AA. my questions are just around timing, whether to ship in H-Star (open to it!) or later.

Replying to "also this https://gi..." This is more for eip-7702 but point is there

The first line of 8141 reads “This new transaction provides a native off-ramp from the elliptic curve based cryptographic system used to authenticate transactions today, to post-quantum (PQ) secure systems.” - based on what Matt is saying should it be moved off of the start?

Replying to "The first line of 81..." the motivation

well if transaction types are composible then that's a different thing

Reacted to "having worked on AA ..." with 👍

Replying to "https://eips.ethereu..." Yeah aware of that but im in favour of 7807 as the headliner so speaking on the tracks of that Just shows how much better debt removal can actually be done with 7807(6406) 🙂

Reacted to "For the record, I ..." with 👍

current transaction types are kind of built with OO inheritance model, maybe we should just abandon this model and go with composability?

Reacted to "current transaction ..." with 👍

Replying to "well if transaction ..." Sharing it here https://github.com/ethereum/EIPs/pull/11355

One issue is current transaction types become combinatorial: characteristic A has 2 options (say, present or not present) and characteristic B has 3 options. then that's 6 tx types with current schema

it bloats quickly

Replying to "From Besu side I do ..." it might still be a good idea to have a breakout call, assuming we don’t reach a decision today

Reacted to "it might still be a ..." with 👍

Replying to "From Besu side I do ..." might also be valuable to bring Vitalik on for that, my understanding is he was very actively involved in frame tx design

Reacted to "it might still be a ..." with 👍

My subject is signature size and long term how it’s going to be addressed

Reacted to "My subject is signat..." with 👍

We are working with the clear signing standard and if accepted, frame tx will be incorporated into it. Also this is no different than EIP-7702 allowing wallet developers to choose the smart account for users. Clear signing: https://eips.ethereum.org/EIPS/eip-7730

Reacted to "We are working with ..." with 👍

Time to enshrine smart account implementation :p

EVM opcodes cannot handle Post-Quantum Cryptography. No mattter what extensions are added. RISC-V is a better solution, precompiles are the best.

Replying to "My subject is signat..." based on https://x.com/yq_acc/status/2026250003577209173 signature sizes grow 51x to 3,3GB/slot(!)

you’d have up to 10 more mins

Replying to "My subject is signat..." This is why frame tx elides the data for VERIFY frames -> in the future we want to be able to aggregate signatures in protocol so that only a single witness for all txs is required

blobs can store the signatures

nobody is using blobs anyways

Whoooo ssz mention 🙀

Reacted to "nobody is using blob..." with 😅

Reacted to "nobody is using blob..." with 😅

drink?

add 🔥

Reacted to "drink?" with 🏋️

Reacted to "drink?" with 😂

Reacted to "drink?" with 😂

And with a net-benificial use too!

Reacted to "drink?" with 🏋️

Reacted to "Whoooo ssz mention ..." with 🔥

Reacted to "drink?" with 😂

Reacted to "drink?" with 😂

one benefit of headliners of course is that they are selected early, so there is significant room for spec iteration (like we did with ePBS and BALs)

Reacted to "one benefit of headl..." with 👍

Reacted to "one benefit of hea..." with 👍

Reacted to "drink?" with 😂

Reacted to "drink?" with 🏋

Reacted to "drink?" with 🏋️

Reacted to "one benefit of hea..." with 👍

Replying to "one benefit of headl..." The down side is that we not really know to what we commit to. EIPs can become much more complex than initially assumed

Reacted to "The down side is t..." with 👍

Reacted to "The down side is tha..." with 👍

Reacted to "The down side is t..." with 👍

Replying to "one benefit of headl..." agreed

tbh, I am not convinced the frame tx is something that we should do

Replying to "tbh, I am not convin..." So is this a flat no from reth?

The blob wire transaction is different from the block tx, this is the kind of severability we need to see in the frame transaction

Replying to "The blob wire transa..." Yep my mistake, you’re right about that

Moscas Equation (X+Y>Z) - account migration is the X part. It’s a problem.

Replying to "The blob wire transa..." I think it is pretty easy to “remove” though since there isn’t introspection of it

I personally would be more happy to embrace frame txs if we also were serious about moving the ecosystem over to AA for real. not just use it as pq insurance. let’s make sure we have good standards for sponsored txs, batched txs, etc, all on top of AA. and then actually get all the dapps and all the wallets to add support for these, and on an attractive timeline, not “years”. with that ambition, it would be my clear headliner favorite. as pq insurance only, a bit meh

Replying to "I personally would b..." We are serious

Reacted to "I personally would b..." with 👍

would be good if we could wrap up the segment

Reacted to "I personally would..." with 👍

We can also add Transaction assertions to it

Reacted to We can also add Tran... with "👍"

Reacted to "I personally would..." with 👍

I guess the "what problem are we solving" should be written precisely in the EIP. And then convince people that this is indeed a problem. Having core devs wondering "what problem are we solving?" shows the EIP is not ready for headliner inclusion imho

Reacted to "I guess the "what pr..." with ➕

PQ private transactions at the app layer will take much longer to get adoption and it'll be more expensive to build

Replying to "PQ private transac..." There are +40 teams building private transfers at app leve;. Huge demand

Replying to "PQ private transac..." But PQ and cost is very tricky

Reacted to "I guess the "what pr..." with 👍

Reacted to "PQ private transacti..." with 👍

I think we should definitely look how this will/might be used by users

Reacted to "I think we should de..." with ➕

the goals have been clearly stated by vitalik in this document: https://docs.fileverse.io/0xd961b83d3421bddec9d8966efabf13800617cfea/10#key=Z-XeQk6mE7uZX9Q2ZbqWkiniYi9IZ1oSbd_2vPFyt26S7Kf8gO_UHpLJ936--lp8

Reacted to "I think we should de..." with ➕

Reacted to I think we should de... with "➕"

Reacted to "I think we should de..." with ➕

Reacted to "I think we should de..." with ➕

Reacted to "I think we should de..." with ➕

Replying to "I think we should de..." can we get a breakout call with wallets?dapps on?

Replying to "I think we should de..." I think we have looked at it a lot

Reacted to I think we have look... with "👍"

Replying to "I think we should de..." feels like without wallet devs being on a call with you saying that they would actually implement this would feel like another 7702 deadend

Replying to "I think we should ..." how does success look like?

Replying to "I think we should de..." having metamask/rabby/other big wallets support it on day 0

As someone who has been building/selling ERC-4337 commercial solutions, gas sponsorship, transaction batching, and permissions (session keys) have been the biggest use cases of AA, way more than “new signature types.” So AA standards that only add new signature types but don’t enable these other benefits are not worth considering, IMO

Reacted to "As someone who has..." with 👍

Reacted to As someone who has b... with "👍"

Reacted to having metamask/rabb... with "👍"

Reacted to "having metamask/ra..." with 👍

Reacted to "As someone who has b..." with 👍

Can we get rid of old tx types with this at some point

Replying to "I think we should de..." I don’t think day 0 support is always realistic. More wallets continue to support everyday. I see rainbow wallet is finally supporting 7702. This stuff takes time because every company has different priorities. The mainnet priorities don’t always match up with this. Many wallets already support smart accounts now thanks to 7702, so supporting 8141 is not a major lift at all

Replying to "As someone who has b..." Derek, which company you work for?

Reacted to "Can we get rid of ..." with 🔥

wallet_sendCalls

Replying to "Can we get rid of ol..." Not if we don’t put authorizations in the frame tx

Replying to "As someone who has b..." ZeroDev

Replying to "I think we should ..." So 2/3 commitments from big wallets saying they'd implement this?

Replying to "I think we should ..." Seems sensible and attainable

Reacted to "the goals have bee..." with 👍

Replying to "Can we get rid of ol..." Maybe if we put the old tx's as data of the frame?

Reacted to "having metamask/rabb..." with 👍

Replying to "Can we get rid of ..." there are also solutions like the SETDELEGATE instruction

Reacted to "So 2/3 commitments f..." with 👍

Reacted to "As someone who has b..." with 👍

Reacted to "Can we get rid of ol..." with 🔥

Reacted to "As someone who has..." with 👍

Replying to "Can we get rid of ol..." It implies no more new tx types?

Reacted to "As someone who has b..." with 👍

Replying to "Can we get rid of ol..." SETDELEGATE doesn’t bind to user address, it’s the contract address. But perhaps a precompile to do it.

Reacted to "ZeroDev" with ❤️

Replying to "Can we get rid of ..." we definitely think it should be done a VM operation instead of as a field on the transaction!

Let’s make a decision now