Ansgar Dietrichs:Some good… hello, everyone. Welcome to another All Core Devs execution, number 231. Today will be mostly about continued H-star headliner discussion, but before we get into that, we have a few other
Transcript
Ansgar Dietrichs:miscellaneous points, starting with Glams that are DevNets. First, I wanted to briefly ask about a update of the running DevNets. I think, Barnabas, you wanted to briefly say something?
Barnabas:Sure, so we currently have, 3 or 4 running the nets,
Barnabas:The current one is blob.net0, where we are testing, And the partial cloud stuff.
Barnabas:We have two clients onboarded, Lighthouse and Prysm. There are a few bugs here and there, some execution layer clients are failing to think to head. I will reach out to everyone that is affected.
Barnabas:Then we have, the big one, the blob devnet 2.
Barnabas:This is where we test the local level access list. We have onboarded Besu and Erigon, this week.
Barnabas:Besu has been, up to head since they've been, included, and Erigon, also failed to sink to head.
Barnabas:So we are still waiting on Erigon to…
Barnabas:be able to reach to the HUD.
Barnabas:I hope they can take a look, otherwise we're gonna be taking a look into that,
Barnabas:In the coming days.
Barnabas:We also have the NFT DevNet, 10.
Barnabas:Where we are testing 870.
Barnabas:It's a new P2P, protocol, that is, increasing the header size.
Barnabas:I think… And we have…
Barnabas:One more, the Pectra DevNet 3.
Barnabas:That just got relaunched, right now.
Barnabas:And, Perfect.net 3 also had an issue last week, where the whole chain just, halted, and we were unable to rescue it, so we are starting this table,
Barnabas:Over again, and, hopefully, we can actually succeed this time.
Barnabas:That's about it for visits.
Ansgar Dietrichs:Sounds good. And then, I think there was some discussion about…
Ansgar Dietrichs:DevNet3 scope still. I'm not sure if there's anything specific to discuss today. Do we have anyone on the call that would want to bring up any topics regarding DevNet 3 scope?
Barnabas:Right, so, Blob DevNet 3 is scheduled to launch next week, Wednesday, and,
Barnabas:So is actually ePBS at, zero.
Barnabas:So that's a huge… Improvement, and we have a spec sheet for more than 3.
Barnabas:Just to keep it relevant for executioner clients.
Barnabas:So the idea was that we are going to introduce, 7954, which is the increased maximum contract size.
Barnabas:We're going to optionally, include 870, and optionally include 871 as the networking changes, and
Barnabas:8037 as a state creation gas cost increase, and the idea was that instead of having a dynamic value, we would introduce a static value increase only.
Ansgar Dietrichs:I see, and that one is final already?
Ansgar Dietrichs:That's still being discussed.
Barnabas:So the 8037, was raised on the 3rd this, Monday, and yeah, the idea was that we still want to do an increase, but, the testing, of the dynamic increase is very, very heavy, so instead of, doing that, we…
Barnabas:Decided to go with the static value increase, and
Barnabas:And just go with that for now, so that we can hit the deadline of next week, Wednesday, for the launch.
Barnabas:With some, hardcore devices.
Ansgar Dietrichs:Yeah, that seems very reasonable.
Barnabas:Maybe someone from the East team can chime in a bit more, regarding whether they have, got to the values that they want to use.
Ansgar Dietrichs:Spencer?
spencer:Yeah, so,
spencer:The hard-coded value, I cannot remember off the top of my head, but, it's whatever the value is when you plug in, 100 million as the block gas limit.
spencer:I can quickly, add this to the chat later.
spencer:I think last, on All Core Devs Testing as well.
spencer:I mentioned that we'd try and get tests out for today, but yeah, I think…
spencer:I think we'll be able to manage that tomorrow now.
spencer:And yeah, kind of an update on the 8037 tests is,
spencer:Yeah, we'll have, like, 8037-specific tests, all of the non-static tests in our repo filled for 8037, and…
spencer:Around 60% of the, ethereum, tests.
spencer:I guess, just to summarize as well, the issue here was…
spencer:that all of the legacy tests written in YAML, the logic required to actually update them for 1837 is not really feasible in YAML, so it's, forced us to actually finally port all these files into Python.
spencer:So we have a PR up for that as well now, so,
spencer:although this has taken us longer than expected, we have got quite a good… good win out… win out of it. But yeah, just to summarize,
spencer:Yeah, I think we'll try and get a release out tomorrow.
spencer:And I'll, post the value in 2 seconds.
Ansgar Dietrichs:Sounds good. And with that somewhat reduced scope of the fixed values, do we now then have high confidence that we'll be able to get there and launch sometime next week, or is there still uncertainty on this, or…
spencer:I think… I think we'll be able to get a test release out by the end of tomorrow, so if,
spencer:I assume if clients are able to pass the test before Wednesday, then.
spencer:Should be okay.
Ansgar Dietrichs:Sounds good. So then, just the typical kind of uncertainty, of course, can always be that there's some last-minute holdups. Okay, awesome. This sounds great.
Ansgar Dietrichs:Any, any more DevNet-related comments?
Barnabas:That is it from me.
Barnabas:I think we can follow up on everything offline, if needed.
Ansgar Dietrichs:Sounds good. Then, next up, we had two other miscellaneous, items. First, Sina wanted to briefly talk about, error E, and the current status there. Sina?
Sina Mahmoodi:Hey y'all. Yeah, I wanted to give a quick status update on Era E.
Sina Mahmoodi:As you all know, it's the successor file format to error 1.
Sina Mahmoodi:It's… properly… Handles the transition epoch and post-merge history, so…
Sina Mahmoodi:In a sense, it will fully deprecate the error one format.
Sina Mahmoodi:As for major changes, it, like, post-merge, it will omit certain fields, like difficulty.
Sina Mahmoodi:There are also some structural changes, like…
Sina Mahmoodi:Entities in the file are grouped according to type instead of by block, which also necessitates a change in the index.
Sina Mahmoodi:As well as some encoding, differences, and…
Sina Mahmoodi:In the receipts, we also, omit the bloom field, which makes things more lightweight and simpler.
Sina Mahmoodi:At this point, the… GEF has a, implementation nerged in.
Sina Mahmoodi:I believe Nimbus and other mines have,
Sina Mahmoodi:PRs, I… I… I'm hazy on the details of how far they are.
Sina Mahmoodi:And… I've… I'm sharing now in the chat
Sina Mahmoodi:A link to, basically, an overview doc where you can find a link to the spec, to the implementations.
Sina Mahmoodi:as well as exported files for Mainnet and Sepolia. So this should help with clients who want to implement this. And, right, I mean, we feel that the spec is in a stable enough
Sina Mahmoodi:Place.
Sina Mahmoodi:Where we would really like for clients to take a closer look, start implementing it, and give feedback.
Sina Mahmoodi:I'm happy to answer any questions.
Sina Mahmoodi:In the chat or after.
Ansgar Dietrichs:Sounds good, thank you. Any synchronous questions? Anything important?
Ansgar Dietrichs:Otherwise…
Ansgar Dietrichs:we can move on. This is a really important effort, thank you. The next up on the agenda, we have, the topic of
Ansgar Dietrichs:transaction pool namespace standardization, I think, Mercy, it is that you wanted to give an update on this, or bring it up.
Mercy Boma Naps-Nkari:Yit.
Mercy Boma Naps-Nkari:Yeah, good afternoon. So, we've been reviewing some start PRs on JSNROP System.Course, and this is one of the PRs that we need,
Mercy Boma Naps-Nkari:core developers to look into. So, I had to open a new PRL, because this… the old one was, like, 2023, dating back then. So I would like to, get some input on this, although some clients have this already implemented. Things like,
Mercy Boma Naps-Nkari:the filtering methods, has to… I feel like it needs to go through an AIP method, so I need to understand the right pathway to move on with… especially moving on with the filtering methods, and also how to, like, any other alternative suggestion in this. And also, Bessel has, like, a different naming space, but with the same,
Mercy Boma Naps-Nkari:standard form, so I don't know if that could be also changed.
Ansgar Dietrichs:Yeah, Fabio?
Fabio Di Fabio:Hey, sorry, I have low voice today.
Fabio Di Fabio:So, I saw the proposal.
Fabio Di Fabio:I support them, and I think it's good to have a standardization in this part.
Fabio Di Fabio:And the… I think there is no issue for Besu to work
Fabio Di Fabio:And expose also this, standard API.
Fabio Di Fabio:There are a few comments I left on the PR.
Fabio Di Fabio:Also, please review them.
Mercy Boma Naps-Nkari:Yeah, I'll address that shortly.
Fabio Di Fabio:Thanks.
Ansgar Dietrichs:Sounds good, yeah, that seems like a general useful thing. Messi, is there anything you'd think we would need to discuss synchronously now, or is this just otherwise something where clients can comment?
Mercy Boma Naps-Nkari:Yeah, they can, comment on, the PR itself, and also for the new featuring methods on, transaction… TxPools and transaction and TxPool statistics, which is from the original proposal. So, I don't know if I'm supposed to, like,
Mercy Boma Naps-Nkari:upload an EIP proposal for that, or we can just, like, include them into this PR already.
Ansgar Dietrichs:Yeah, that's a good question. I think we can… that can be discussed in the PR. I wouldn't know out of the top of my head.
Ansgar Dietrichs:But yeah, awesome. I thought there was a raised hand, maybe briefly, Marius, but, yeah.
Marius van der Wijden:I just, I realized at some point that these methods are not super helpful anymore, because we have such a lot of transactions in the transaction pool, or some… some of these methods. Like, the methods that print all of the transactions.
Marius van der Wijden:not really… like, they just print out way too much stuff. So, I like the… there are some of these that only print out a…
Marius van der Wijden:a certain, Thought form…
Marius van der Wijden:Summary of what's in the transaction pool, and then there are some that just print out everything in the transaction pool.
Marius van der Wijden:Maybe, a method that is, like, filter the transaction pool for this transaction hash, or…
Marius van der Wijden:For all transactions from this address might be…
Marius van der Wijden:More interesting than just giving me all of the content of the transaction pool, and then the content is, like.
Marius van der Wijden:4,000 transactions.
Ansgar Dietrichs:Felix?
Felix (Geth):I think for us right now, it's just more about getting the… started with this API. If we want to have it changed, we can definitely iterate on the PR. This proposal is just more about getting any API standardized, because right now, it's not standardized at all, and it's still
Felix (Geth):This namespace is anyway more for debugging and testing.
Felix (Geth):And less for the production use. I don't think it really makes sense for any RPC provider, for example, to support this method, and apps aren't supposed to use it either. It's just for us to be able to check
Felix (Geth):certain properties in the DevNet and things like that. Or, if you are an advanced user, I don't know, but it doesn't really seem like a user-focused API.
Felix (Geth):And so for that reason, I would say just exporting the full content or exporting all the hashes is…
Felix (Geth):Kind of what we want.
Felix (Geth):Because it gives you a full snapshot of what's the transaction pool like right now, and then you can…
Felix (Geth):Figure out some other tooling on top, or…
Ansgar Dietrichs:Makes sense, yeah, then it sounds like maybe a discussion point there should be whether to just standardize the, kind of, this… this existing scope,
Ansgar Dietrichs:first, and then think about extensions later, or whether to maybe just take some more time and have a more up-to-date, useful kind of version to standardize, but yeah, I think this can… that concrete discussion can happen asynchronously. But sounds like overall people all agree that the standardization effort is useful.
Ansgar Dietrichs:Awesome. Then I think we can move on. The next section, and last section is the Hegota headquarta…
Ansgar Dietrichs:Headliner topic, before we go into the actual, client positions and, discussion, there was a update, specifically the, headliner proposal, EIP8105.
Ansgar Dietrichs:Which,
Ansgar Dietrichs:was the, what was the exact name? The, Universal Enshrined Encrypted Mempool. So we had, just to remind people, we had two separate encrypted mempool proposals this time around as headliner. One was this, the, the, the, the first one, the older one, basically, EIP8105, Universal Enshrined Encrypted Mempool, and then, relatively shortly before the deadline, we had a second one.
Ansgar Dietrichs:called, Lucid. And now, in particular, a couple days ago, the, champions of the, of the first one, 8105, had a comment, that they are basically withdrawing their EIP as a headliner proposal, and instead are basically endorsing, Lucid. So now we have one, combined, enshrined, sorry, encrypted mempool.
Ansgar Dietrichs:proposal, so that's an update there. I'm not sure if anyone from the 8105 team is on the call, would want to say a few words on this, or… otherwise, I guess it's…
Ansgar Dietrichs:Self-explanatory. Yannick?
Jannik Luhn:Yeah, I think you explained it very well. That's basically the situation. We threw it in favor of supporting Lucid, just to make the decision a bit easier for everyone else.
Ansgar Dietrichs:Sounds good. And there is the question shared which EIP is the Lucid one. I also looked into this, I couldn't, like, I think it's… there's maybe not yet a merged EIP? Is this… I don't know, is anyone from the Lucid team on the call can briefly talk about the EIP status of Lucid?
Justin Florentine (Besu):Yes, Anders just spoke to that in the chat, it's still in a draft stage, it's gonna be shared over the weekend.
Ansgar Dietrichs:Sounds good.
Ansgar Dietrichs:Awesome. Then with that, I think we can, move on to the actual, headliner discussion. So, last week we… oh, no, last call, two weeks ago,
Ansgar Dietrichs:asked for clients to basically think about what their positions would be on the individual headliners. Some of the clients
Ansgar Dietrichs:posted some official kind of document or statement of any form on the agenda. I wanted to go through those first. First up, I think we had Erigon with a brief comment. Is anyone from Erigon here to briefly summarize this?
Ansgar Dietrichs:Give some context.
andrew (erigon):Yeah, sure. So, can you hear me?
andrew (erigon):It's, basically… Yes, we can.
Ansgar Dietrichs:AU.
andrew (erigon):what, what, what I wrote is that we think, both account abstraction and encrypted mempos are
andrew (erigon):Well, very important, and it's crucial to prevent, front-running, but because, there is,
andrew (erigon):This extensive roadmap, the straw map, that affects, slot times, and,
andrew (erigon):how… how transactions are mapped into slots and things like that. It might be…
andrew (erigon):fine, okay, to delay Lucid until the iHeart walk, so that we have more time to… to, like, double-check that it agrees with everything else on the roadmap.
andrew (erigon):Yeah, basically that's it, but we would like to see both, of course, both the account abstraction and
andrew (erigon):the encrypted memo in Ethereum.
Ansgar Dietrichs:Sounds good. Then, next up, we had, a document from the Besu team. Anyone from BASU want to briefly summarize?
Daniel Lehrner (Besu):Yeah, I… I can do that. So…
Daniel Lehrner (Besu):The Besu team is in favor of having Lucid as the EL headliner.
Daniel Lehrner (Besu):We think it's an ideal candidate to go together with Fossil.
Daniel Lehrner (Besu):Specifically because without something like this, Fossil will only be useful for transactions that
Daniel Lehrner (Besu):Cannot… that don't have any math to be extracted, or that are not very time-sensitive.
Daniel Lehrner (Besu):So it might only benefit a small minority of users.
Daniel Lehrner (Besu):I like, for example, Fossil a lot, but most of my transactions I have to send to a private land pool, so none of my transactions are available
Daniel Lehrner (Besu):be picked up by… by… by an included.
Daniel Lehrner (Besu):That's why I think that we, the team in general, also likes the frame transactions, it's just if we have to prioritize between Lucid and the frame transactions, we prefer Lucid because it's an ongoing problem that has plagued Ethereum for many, many years.
Ansgar Dietrichs:Sounds good. Next up, we had, the guest team. Anyone from guest wants to briefly summarize?
lightclient:They… Yep, so… we posted our document. We feel that Frame Transactions is the best choice for
lightclient:the headliner for Hagota. We also think that it's a good… fit for…
lightclient:Fossil on the CL side. Fossil's going to give better inclusion guarantees to transactions in the protocol, and we feel that smart accounts also deserve to
lightclient:Take advantage of… The improved, those improved inclusion guarantees.
lightclient:the… For the other headliners, 7807SSZ.
lightclient:It's a nice change, I think.
lightclient:We feel it's just too invasive for the benefit to users right now.
lightclient:And we also believe that there's a lot of experimentation that can be done on the engine API without changing the consensus representation of the objects.
lightclient:So we would prefer to start there.
lightclient:And the Lucid encrypted mempool is also an interesting idea. We just don't think that it's matured enough yet.
lightclient:it… You know, encrypted mempools haven't really been deployed widely in blockchain systems yet.
lightclient:And the… The instances that have been deployed leak metadata, things like nonsense, gas limits, data sizes.
lightclient:And this is also an issue in Lucid.
lightclient:So we worry a bit about what type of information can be gleaned from that metadata. So, we would like to see more significant discussion around it, and prototyping of the project over the next 6 to 12 months, and consider,
lightclient:considered as a headliner in Istanbul, potentially.
lightclient:Yep, I think that's all for us.
Ansgar Dietrichs:Sounds good. And then, there was another comment by NMUCL, but maybe to first round of the,
Ansgar Dietrichs:the main production EL clients first. We did not have a official comment from… on the agenda from either Reth or Nethermind, but I have seen that there was active discussion, so I know those clients also have positions. Do we have anyone from Nethermind on the call that could briefly summarize the team position on this?
Łukasz Rozmej:Yes, I can summarize, so we didn't put out any official statement, because after discussions, we weren't completely convinced about, any of the APs.
Łukasz Rozmej:So, we do like, the privacy that Lucid brings, we do like the… especially the road to…
Łukasz Rozmej:Different signatures with the frame transactions, but both bring, in our opinion, such big complexity that we are not…
Łukasz Rozmej:really, at the current moment, confident to just support them.
Łukasz Rozmej:So…
Łukasz Rozmej:Yeah, we are still… we are open to be convinced yet, but we are not convinced at the moment that any of them is actually 100% correct way to go.
Łukasz Rozmej:Mostly due to the complexity of both, of both, of both.
Łukasz Rozmej:proposals. We are… we are afraid about the complexity creep.
Ansgar Dietrichs:Sounds good. And as Nixu was mentioning in chat, and then also Marius, actually, in his own personal opinion,
Ansgar Dietrichs:there is indeed also the option to just not choose an EL-specific headliner. We already, with Fossil, obviously have a main headliner, and it does touch the EL. So maybe then I would…
Ansgar Dietrichs:summarize the Nethermine position as a preference for no yellow headliner, although it does sound like you could be convinced still for any of the other headliners, maybe with some iteration or things like that.
Ansgar Dietrichs:Awesome, and then actually, from my understanding, from just reading the chat, was maybe that the Reth position could be similar, but do we have anyone from Reth on the call that could briefly speak to that?
Dragan Rakita:Yeah, I think I'm here. Yeah.
Dragan Rakita:From this list of AIPs, yeah, it's hard to choose anybody, anything to be a headliner.
Dragan Rakita:You can frame trisection.
Dragan Rakita:Feels, like, over-engineered for the…
Dragan Rakita:Solution that we basically could do as some simpler… Implementation.
Dragan Rakita:Encrypted pools, seems torely to add them.
Dragan Rakita:And S is the… yeah.
Dragan Rakita:There is not a lot of benefit, like, doing a lot amount of work.
Dragan Rakita:Not that great of the benefits.
Ansgar Dietrichs:Sounds good. So yeah, then it's a similar take on possibly considering having a new headliner.
Ansgar Dietrichs:Yeah, sounds good. Andrew?
andrew (erigon):Yeah, I'd like to address the point on complexity. Well, when I saw the straw map, I initially thought that it was a little bit too ambitious and too optimistic, but now I'm actually reconsidering, because… because of plot 4.6,
andrew (erigon):We've been having some internal discussions within the team, and…
andrew (erigon):And we've been impressed how well it can handle everyone's call base, and probably similar for Nethermind.
andrew (erigon):As well, and the rest. So, and it's, like, something like, well, not necessarily Claude, maybe Gemini, whatnot, but I think now we are getting really powerful tools to help us with, turning the, the… this ambitious roadmap into… into reality.
andrew (erigon):It can help us with,
andrew (erigon):implementation with, like, as, like, done with the spec writing, with, test writing, and so on. It's not a silver bullet, of course, but I think it can do a lot of,
andrew (erigon):Verification, and
andrew (erigon):kind of nitpicking job and things like that. It's really… it's really a big productivity boost, which…
andrew (erigon):improved significantly within the last, like, two months. So, yeah, I'm kind of not that worried about complexity. We have… we have now, we have some powers to tackle it.
Ansgar Dietrichs:Sounds good. Can we maybe briefly round up the, just going through the client positions before we go into discussion? But, but yeah, this is a comment well taken. Also, maybe, Andas, if you maybe have a more process-related comment, I think it's fine now, but otherwise, in terms of open discussion, I would briefly hold off.
Ansgar Dietrichs:But yeah, just so we can briefly finish, because there was also the Nimbus EL position, I can also link that. Do we have anyone from Nimbus on the call to briefly summarize that?
Dustin:Sure, yeah, so…
Dustin:I guess, perhaps unsurprisingly, we're in favor of moving towards SSZ, and, and in a couple of concrete ways. So, I think we…
Dustin:So…
Dustin:We actually think SSC can complement, two of the EIPs here, and so frame transactions, we are in favor of frame transactions, though, and frame transactions would be even better with SSC, and in particular.
Dustin:This is not a completely arbitrary point, as in, you know, anything can be better with SSC, but this is a point of, frame transactions highlight one of the costs of not transitioning to SSC in a timely way, because they are essentially adding, sort of, instant tech debt.
Dustin:From the outset.
Dustin:More transac… you know, another transaction type, more formats to parse, to code, and there will be multiple representations of these now.
Dustin:if…
Dustin:And we are obviously proposing approaches to avoid this, but even separately from 7807, incorporating that into frame transactions, we feel would be an improvement.
Dustin:Otherwise, as far as
Dustin:Frame transactions, we find, are… address a fair amount of… a wide range of problems relatively elegantly, as far as that goes, that are…
Dustin:Worth addressing, and in particular, a number of feature-proofing aspects.
Dustin:And finally, for encrypted mempools especially, I want to say, before the consolidation, before Lucid, sort of became the…
Dustin:the one, that was… I think we found it sort of un…
Dustin:unappealing, let's say, to have, and indicative of an immature EIP or a spec.
Dustin:ecosystem consensus, that there were two different, headliners, which were actually have somewhat, somewhat different approaches, and that suggested that there simply needed to be more time. So, encrypted mempools are nice, but I don't think they're quite ready yet for, for,
Dustin:For this fork.
Dustin:Yeah.
Dustin:What's up?
Ansgar Dietrichs:Sounds good. So then,
Ansgar Dietrichs:before we go into, yeah, open discussion, just in just one second, so basically, I think my summary of these positions would be that we have some, individual support for both Lucid and SSC,
Ansgar Dietrichs:But that the two primary positions that seem to be… have mentioned the most were either to do frame transactions, which I think had the most individual support.
Ansgar Dietrichs:or to consider just not having an EL-specific, headliner, which had a bit less support, but also considerable support, so it looks like it might be trending towards a decision between those two options. But yeah, again, that's what we'll…
Ansgar Dietrichs:we're here to discuss. In terms of process, just to mention, I think, timeline-wise, if we can get to consensus today, we can make a decision today. We don't have to. If it turns out that we actually, like, are split between two options in the end, we can also take two more weeks. By next call is when we would really want to lock in the decision at the latest. So, with that as context, I think we can open the discussion. Justin, you have your hand up?
Justin Florentine (Besu):I just would like to maybe ask us to… maybe you could take a discussion point, Asgard? I'm very curious as to Dustin's point, I think it's very interesting, and would love to discuss that later, like, what does it mean to have
Justin Florentine (Besu):two EIPs that do similar things in different ways propose as headliners. Is that a bug or a feature? Like, I could go either way on that. I think it's…
Justin Florentine (Besu):A very interesting point that's raised there, and I'd like to… us not to lose it, and maybe… maybe consider that as an example of, you know, maybe there's a process adjustment here. So, that's all.
Ansgar Dietrichs:Yeah, that makes sense. I would maybe keep that…
Ansgar Dietrichs:out of scope for today's call, like, the… the… what… I think… I think this is better for, like, once we have it logged in the headliner, we can talk about what went well, what went not so well, what can we improve for future headliner processes, but… but point well taken. Yeah, do we… do we have other…
Ansgar Dietrichs:comments, I see in chat people arguing that maybe it's a waste to not have a headliner,
Ansgar Dietrichs:There's other comments. Anyone wants to bring up something?
Marius van der Wijden:Yeah, I would counter that by… just by saying…
Marius van der Wijden:not choosing an EL headliner doesn't mean we cannot choose any ELPs. It just means…
Marius van der Wijden:like, I think there's a different difference in understanding what the headliner means, but for me personally, it means that this is the feature that we would consider delaying the fork over if it's not ready.
Marius van der Wijden:And I don't… necessarily see any of the features that we… that are proposed.
Marius van der Wijden:important enough and well thought out enough to be in that stage. So I would prefer not to have an EL headline, and then just do as many EL EAPs, other EL EAPs that we… that we can, and if we…
Marius van der Wijden:if we see that FOCIL is taking longer, we can add more. If possible is very fast, then we can pull out some of those, non-head learner AIPs again.
Ansgar Dietrichs:Makes sense. So in terms of… I'm mostly curious to what extent we feel like we are at least close enough to iterating towards a decision that it's worth trying to get there today.
Ansgar Dietrichs:Emm… Maybe first off, How do people feel about the non-favorite,
Ansgar Dietrichs:proposed solutions. So, again, we have… we had some support for Lucid, some support for SSC, but at least in the first round of, statements, it didn't seem like they would… they were close to, sufficient,
Ansgar Dietrichs:support. So the question is, for example, do we… are they a lot of people's secret second option, and they still have a good chance of convincing people? Is it maybe, already clear that we can make a decision today to not consider the mid-side lineup going forward?
Ansgar Dietrichs:Yeah, let's maybe start there, like, do clients have… Concrete takes on those two.
Ansgar Dietrichs:Anders?
Anders Elowsson:Yeah, could I just ask the GET team about this? All encryptum impulse we are aware of suffer from substantial metadata leakage, but we don't think that Lucid leaks metadata, so maybe they could clarify that.
lightclient:I mean, Lucid leaks, gas limit, gas price… This is metadata.
Anders Elowsson:How does it leak?
lightclient:I mean, is this not in the plain text of the transaction envelope?
Anders Elowsson:Yeah, but… but you don't, reveal which transact… which… which account you are,
Anders Elowsson:going to send from. So you just specify a gas estimate first.
lightclient:Yeah, but this is the metadata. I mean, that's what the definition of metadata is.
Anders Elowsson:I don't agree with that. I don't agree with the definition of neopurata.
lightclient:I mean, we don't need to get caught up in these details, I think, that…
lightclient:It was said nicely earlier, where there were two different proposals for encrypted mempools, both proposed at the last moment.
lightclient:This is not ready for Hakota.
lightclient:I think it could be ready for I-Star, but it was not picked as the headliner for any client except Besu.
lightclient:I don't see this.
Anders Elowsson:Yeah, I mean, it's perfectly…
lightclient:Proposed that's ready.
Anders Elowsson:Perfect.
Anders Elowsson:It's a perfectly valid position, I just wanted to specify that we do not leak metadata.
Anders Elowsson:And I don't agree with the, with, that… that we do.
Ansgar Dietrichs:feelings.
Felix (Geth):just to interject here, I think we have to solve this offline. So, this specific statement, we can figure it out, but I don't think we're gonna resolve it live right here. So, let's just open a thread in the Discord.
Felix (Geth):And… Discuss it there after the call.
Ansgar Dietrichs:Yeah, that specific issue, I agree.
Ansgar Dietrichs:So, okay, let me do it this way. I think both, the Besu team with support for Lucid had indicated that they, as a second op choice, would, also, appreciate frame transactions as a headliner, and Nimbus EL had also mentioned that they also, indeed also,
Ansgar Dietrichs:were otherwise in favor of frame transactions, so it sounds like both of those teams that supported a non-majority headliner candidate were at least, in principle, okay with an alternative headliner. Is this an accurate summary? Basically, are any of these teams… would any of these teams try to die on the hill of their specific proposal?
Daniel Lehrner (Besu):I think from Westside, we would not die on the hill, but at least I think we would need to talk in this new case between frame transaction and no headliner.
Daniel Lehrner (Besu):what we want to support, because we had at least one… one person on the team who also was… didn't want any headliner.
Daniel Lehrner (Besu):So I could not commit to frame transaction if it's between those two today, on the core. We will need to do this async.
Ansgar Dietrichs:Makes sense. Yeah, Andrew?
andrew (erigon):Yeah, I think no headliner would be… would be a waste.
andrew (erigon):So, like…
andrew (erigon):from our perspective, we are happy to do either the frame transactions for Lucid in Habitat. I think if we do Lucid, we're just, like, the only reservation is that we take time to double-check that
andrew (erigon):It agrees nicely with all the things on the straw map, and adjusts I diluted or the items on the straw map accordingly, but, like, no, like, things we can pull it off for Hagota.
andrew (erigon):Yeah, I just… I think no headliner is the least without options.
Ansgar Dietrichs:Felix?
Felix (Geth):I just wanted to give a quick comment that I think also there has been a lot of discussion in the comments here on the call about the frame transaction proposal, and it might make sense to just organize a breakout call. I don't really know how these…
Felix (Geth):How it works with the breakouts?
Felix (Geth):I mean…
Felix (Geth):But, like, just having a one-off breakout where we really figure out the details of the proposal, like, why we made certain choices, if, you know, people have
Felix (Geth):some… problems with it, I think that could really help.
Felix (Geth):because I'm still seeing a lot of confusion, like, people saying, oh yeah, can we do this, like, another way, or is this really what we should be doing now? And, like, this is…
Felix (Geth):Sweet.
Felix (Geth):it would just be good to, like, clarify once and for all, like, what is this proposal, why is this there, what are the alternatives, and so on. It's not so easy to…
Felix (Geth):To just do it all here on the call, and especially not in the comments.
Ansgar Dietrichs:Right so Barnabas in chat has the comment that he'd prefer to dive into it now. I…
Ansgar Dietrichs:personally think a breakout does make sense, especially if some teams say that they wouldn't feel comfortable committing to anything today either way, but yeah, of course, if the majority of people would want to just actually do a 45-minute frame transaction deep dive now, we could do that now.
Ansgar Dietrichs:Not sure how people feel about that.
Felix (Geth):Yeah, I just thought maybe we have other stuff on the agenda, like, usually we don't, like, do these deep dives on ACD, it's just more about the decision-making. We can totally do it, I mean, it's just a question of if this is what people want.
Ansgar Dietrichs:Right. We don't have anything further on the agenda other than this decision. I'm mostly just worried that not everyone on the technical side from each client that actually might be interested in this is on the call right now.
Ansgar Dietrichs:but,
Ansgar Dietrichs:Yeah, I mean, process-wise, it feels more clean to actually have a pre-announced breakout. I would just lean towards making that decision, but again, if many people here would actually want to do it now.
Ansgar Dietrichs:Happy to be overruled.
lightclient:I mean, I feel like we should just talk about frame transactions, since that seems to be a major sticking point for people.
lightclient:I'm not sure if it's the same questions or issues for every person, though.
Ansgar Dietrichs:Yeah, sure, I mean, Ben, I'm happy to give the floor to…
Ansgar Dietrichs:the frame transaction people to have a…
Ansgar Dietrichs:Kind of a bit of a deep dive session right now.
Ansgar Dietrichs:Sounds like people…
Marius van der Wijden:Sure.
Ansgar Dietrichs:Prefer this?
Marius van der Wijden:Should we just… should we just do the rest of the agenda?
Marius van der Wijden:Like…
Ansgar Dietrichs:But there is no rest of the agenda. The rest of the agenda was specifically that just, like, the headline
Ansgar Dietrichs:Last point of the agenda.
Marius van der Wijden:Yeah, maybe we can just ask, are there any topics that
Marius van der Wijden:Still need to be discussed before we dive deep into the last 45 minutes or something?
Marius van der Wijden:Frame transactions?
Ansgar Dietrichs:Right, so is there anything non-headliner related? Because in terms of, like, other thoughts around headliners, I think…
Ansgar Dietrichs:That then… it's the same category, but anything not non-headliner related that people would want to discuss today, otherwise.
Anders Elowsson:Is there any chance for me to say one thing before that discussion? I just wanted to talk about the options
Anders Elowsson:the… when we… when we say that no headliner, I think we should, maybe…
Anders Elowsson:talk a little bit about what that means, because there are certain, sort of, slightly big ELPs that we could do that…
Anders Elowsson:I feel also could be worthwhile, and I would just like to flag, before you go into the frame transaction discussion, about EIP7999. Because, just because I feel that,
Anders Elowsson:when we do… we are currently doing 8037, and it feels slightly brittle to me, the way… the way it is designed, because we're trying to predict, essentially, demand elasticity, instead of going, like, by measured demand.
Anders Elowsson:And the thing is that if these predictions turn out to be wrong, we will sort of impede scaling. And it has been worrying me for quite a long time, so I just wanted to flag that if we have more space and more time to do 7999 instead.
Anders Elowsson:then I think this would also be a worthwhile thing to do. So that was just what I wanted to say. And in this case, we would do a very small 7999, but we would do it with state as one of the…
Anders Elowsson:resources.
Ansgar Dietrichs:Yep, that's a reasonable comment. So, indeed, like, no headliner doesn't just mean… just…
Ansgar Dietrichs:kind of do nothing, wasted space, like, it could either enable a faster poke, or it could just give more room for… I don't know, ambitious non-headliner ERPs. That is correct.
Ansgar Dietrichs:Yeah, with that said, then I think we can go into frame transactions. I think I would timebox it to maybe-ish 30 minutes, so that at the end we can have a few more minutes to just talk about is, did this discussion get us to a point where we'd be ready to make a headline decision, or if not.
Ansgar Dietrichs:and basically just make sure we are aligned on next steps for our next call. So… but yeah, 30 minutes for… up to 30 minutes for frame transactions, if anyone from the frame transaction side wants to take the lead for that section of the call.
Ansgar Dietrichs:The flow would be yours.
lightclient:Yeah, I mean, I think it… Okay, go ahead, Felix.
Felix (Geth):Just wanted to quickly say that I can,
Felix (Geth):I mean, we are both here, Matt and I, I think we are the representatives of this EAP, so we are both happy to host it and answer the questions.
Felix (Geth):that come up.
Felix (Geth):So I would do it, like, more in a question-and-answer style way.
Felix (Geth):Like, personally, if people have specific points, we can go through these points.
Felix (Geth):Anyway, Matt, you also wanted to say something, so…
lightclient:Yeah, no, I was gonna say basically the same thing. I think we talked… we went over a pretty high level how frame transactions worked a couple calls ago.
lightclient:It's also similar to things that have existed for a few years, so I think that people kind of get it, and it would probably just be better to talk about the…
lightclient:The specific questions or concerns that people have.
lightclient:About the proposal.
lightclient:So, the clients who chose not to have frames as the headliner, What would convince you otherwise?
lightclient:Okay, people are shy to talk.
Felix (Geth):I think that's a pretty strange one to start off with, like, I mean, we're not really here to, like, you know.
Felix (Geth):I don't know, I would rather say… so we had specific points raised in the comments. If I scroll up a little bit, what I can see is that… so we had one concern, which is regarding the dev tooling.
Felix (Geth):So,
Felix (Geth):Dargan from Reth was saying, frame transactions become a nightmare for dev tooling. Feedback we got is that it's over-abstracted, and a simpler solution would be more powerful.
Felix (Geth):Later, he follows it up with, comment saying…
Felix (Geth):Full feedback, frame transactions introduce more account abstraction galaxy braining by delegating complexity into frames. Developers don't want to work with defining frames, reducing complexity in the sense that we don't need a bundler.
Felix (Geth):but then introduce toner complexity and dev code dueling layer, for example, in VM.
Felix (Geth):And, account abstraction flows are super difficult to reason about, specifically with this.
Felix (Geth):frames.
Felix (Geth):So, I think this is something… this is one of the points we could focus on. Wukash, do you have something to say?
Łukasz Rozmej:I would like to ask, what's the main, goal we want to achieve? Because,
Łukasz Rozmej:Frame transactions was also sold as going to different signature schemes, and it's also a transaction, so do we want to, like, hit two birds with one stone, or what do we want to achieve here? Or what's the main goal?
Felix (Geth):Yeah, this might be a good thing to, like, get into first. So, for me personally, I can answer it, like.
Felix (Geth):I think that… The immediate goal we have is to solve the transaction signature issue, let's call it that.
Felix (Geth):And so the issue that we see is just that
Felix (Geth):there is no way to originate an Ethereum transaction without creating an ECDSA signature right now.
Felix (Geth):So now you could say, well, let's just fix that specific thing, but it goes a little bit further than that, because even if we introduce another transaction type that just…
Felix (Geth):has another kind of signature on it, then we're kind of back to the same problem, because the protocol uses ECDSA signatures on the specific curve in other ways, so then we would have to address those as well, and then…
Felix (Geth):That doesn't even get into all the advanced use cases that people have.
Felix (Geth):So, we just feel like we have to put a good and general solution to this problem that is basically gonna last us for all time.
Felix (Geth):And so that just means for us that we just have to remove transaction signatures from the protocol completely, which is what this proposal does. So there is no more
Felix (Geth):And shrine signatures at all with frame transactions.
Łukasz Rozmej:Okay, so I was looking into some alternatives, similar to that, and there was this EAP79… Free, too.
Łukasz Rozmej:that kind of did that with, like, an envelope transaction that had the inner transaction in it, while having a different signature scheme. It wasn't…
Łukasz Rozmej:relatively simple solution to that, right? But it didn't give us all the account abstraction.
Łukasz Rozmej:Thing. So, just for this, I… for this particular problem, I would prefer this kind of solution. So the thing is, do we want to also solve, like, the general thing, which is…
Łukasz Rozmej:makes things really complex, maybe we do want, but makes it really complex, or do we just want that kind of thing, right? So that's the question for me.
Łukasz Rozmej:I mean, if you… Oh, this is what they have.
Felix (Geth):Sorry, Dragon, I think you really want to say something, so I guess we can just…
Felix (Geth):You can also take it away.
Felix (Geth):Is it related with this point, or your point from earlier, or…
Dragan Rakita:Yeah, I think Lukashi is basically…
Dragan Rakita:saying what I want to say. If we have… You don't need to have…
Dragan Rakita:multiple transaction types for every signature. You can have one transaction that has signature type.
Dragan Rakita:And some generic field that depends on that signature type.
Dragan Rakita:So this is, like, a lot simpler solution than introducing the frame that's going to ask EVM what's going on.
Dragan Rakita:And that kind of abstraction seems, like, overginated.
lightclient:Yeah, I can respond quickly to these comments.
lightclient:I think the tempo-style transaction types are kind of nice, because they are fairly simplistic in that sense.
lightclient:But I don't think that it…
lightclient:really solves the, like, long tail of things that we want to solve with frame transactions.
lightclient:yes, like, post-quantum is one of the most important things that Frame Transaction does, but there are other core goals that Frame Transactions is aiming to improve upon, and…
lightclient:the tempo-style transactions doesn't address the privacy issues that frame transaction can. So, concretely, today, if you want to withdraw from a privacy pool.
lightclient:You either need to have some EOA that exists with some Ether that you can submit your withdrawal transaction from.
lightclient:Which creates a chicken and egg problem, like, how do you get this Ether in this private way? If you could have done that, you probably wouldn't have used the privacy pool. Or, you have to use a centralized relayer, who then has some metadata on you about the privacy pool withdrawal.
lightclient:With the frame transaction, we have the ability to actually change the validation logic, and we could do the withdrawal before the gas for the transaction is approved.
lightclient:So these are things that just aren't possible with the tempo-style transactions.
lightclient:And I think that they are very important for Ethereum as a protocol, and they match our core tenets of having trustlessness, privacy, and, you know, generalizable abstractions, giving developers
lightclient:powerful tools to have permissionless innovation. And the prefix menu of crypto algorithms that has been proposed in a few different examples just doesn't give this flexibility.
Felix (Geth):So where do we stand with this now? Dano, I see you have your hand up. Do you want to respond to this directly, or raise a new point, or…
Danno Ferrin - Tectonic.xyz:I want to talk about post-quantum signature sizes, so we can finish this discussion, and then that's that point.
Felix (Geth):Yeah, yeah. So this is more like… so I would say that, like, the title for this particular discussion item is just, like, what is the purpose of frame transactions anyways? We are still discussing on that basic point.
Felix (Geth):And Matt kind of answered it, and I can also answer it in my way. For me, I feel like introducing transaction types to the protocol in the first place was kind of awkward, and I wish that if we introduce new transaction types, they have to be valuable to us, and
Felix (Geth):just adding more transaction types for every little feature that we try to add. For example, now, we're gonna add a transaction type that
Felix (Geth):I don't know, if we were to add a transaction type now that just specifically supports a different kind of signature, or, like, a parameterizable signature, or whatever.
Felix (Geth):That is just ultimately gonna lead to more pain and fractures of protocol, where we…
Felix (Geth):feel like with the frame transaction, we were able, for the first time, to actually clean up some tech depth regarding transaction types, and the…
Felix (Geth):frame transaction fundamentally is a lot simpler than other transactions. It has the frames, yes, but the overall amount of features in it is much reduced, and we don't really see, like.
Felix (Geth):Too many extensions that are gonna be required in the future for this type.
Felix (Geth):Specifically because a lot can be done with, frames and…
Felix (Geth):It just solves a lot of problems that other transaction types tried to solve before in a more specialized way.
Felix (Geth):Regarding the initial motivation, so the initial motivation for this is to add, post-quantum signatures quite soon, but we do want to combine it, and this is, like, going back to the point that Wukash raised in the beginning, it is very good for us
Felix (Geth):To combine this with
Felix (Geth):account abstraction, because we feel like it's also kind of an overdue feature, and the two go together really well with this transaction. So that's why we decided, indeed, to just put both of these things in the same proposal.
Felix (Geth):And we feel like, just, they can both be solved in the same fundamental way, and that makes us believe that this is a stronger proposal than trying to only solve the very specific issue of verifying the transaction origin signature in a different way. Like, it goes beyond that, in a way.
Felix (Geth):Anyway, so I see, Wukat, you have your hand up again.
Łukasz Rozmej:Yeah, so, I completely agree that how we did transaction types was wrong, because they are kind of resembling, object-oriented inheritance model, that one transaction kind of inherits from the other type, etc. And now, when we have multiple dimensions, we want to go with those transactions, they are… we kind of get stuck, so maybe…
Łukasz Rozmej:we should try to compose transaction types, right? So, for example, if we were redesigning, we could have
Łukasz Rozmej:1559 transactions, and compose that into blob transactions, and just adding blobs to it, right? Or something, and adding different signatures to it, etc. So maybe this is the way to go, in a way. So, those transactions will still have all the properties of the previous type, but we can just add new properties to it.
Łukasz Rozmej:And that kind of is… And this is.
Felix (Geth):I mean, I agree with this. Long time, it would be nice to have a more composable transaction type, but we feel like we kind of have that now with this
Felix (Geth):Because the… if you look at the basic envelope of the frame transaction, it is…
Felix (Geth):Basically, a fresh start. And, we can…
Felix (Geth):basically turn it into more things later. For example, the frames themselves are also extensible in some ways. We don't really plan to extend it too much now, but, like, if it becomes a necessity, we can also extend it.
Felix (Geth):So… I don't know, I don't think… like, like I said, I think a lot of the components of transactions that were introduced, like, for example, the access list.
Felix (Geth):it solved a specific problem, which we now feel is, like, solvable in a different way, so we didn't include it. It's same for the delegations. We feel like the delegations, they solve a specific problem, and if delegations are still supposed to be relevant later.
Felix (Geth):for example, for the EOA migration purposes, then we have to find another way to do it that isn't related with the transaction type.
Felix (Geth):So, yeah, I mean, this combinatorial thing that Dustin is also mentioning, we kind of don't want that anymore. So, we feel like with frame transaction, we do have a shot at reducing complexity there, which is very important for us. And, I mean, again, you have to see it in the wider picture. We're trying to introduce account abstraction, we're trying to solve post-quantum, but we also feel like we…
Felix (Geth):actually figured out a pretty nice encoding for transactions in general, so this… these are the views why we think this proposal is, like, pertinent now, especially compared to the other, more narrowly focused ones. So I think this answers now the question of, like, what we want to do with this in the first place, and I think we should move on to other questions.
Felix (Geth):Dano, you had… we have still… let me just summarize it quickly. Dano, you were saying something about the signature specifically. We can go there. This will be a kind of a focus thing, I guess.
Felix (Geth):We have still this comment about the dev tooling that we should address, and then now, Luis, you also have something? Do you have a comment that goes to the current discussion, or you want to bring a new point?
Luis Pinto | Besu:Yeah, yeah, it's still… it's about the general, the architecture of the frame transaction in general. I'm not convinced, but it's just playing as a devil's advocate, on this, apart from introducing more EVM complexity around, like, the message frames and stuff.
Luis Pinto | Besu:I wonder if there's not a security concern, like, more attack vectors in terms of…
Luis Pinto | Besu:Because now we are basically building a framework for how users do signatures, or transaction signing.
Luis Pinto | Besu:We are…
Luis Pinto | Besu:delegating that all to a smart contract, if I'm correct, and so anyone can create their own way of signing, a custom way of signing. I wonder, in terms of safety, like, because now wallets can pick the exact signature, so it's not, like.
Luis Pinto | Besu:trusted by core devs that you should pick this signature or that one. It's kind of…
Luis Pinto | Besu:all open, and anyone can create their own thing.
Luis Pinto | Besu:Yeah, I'm just raising this as a point. I'm not either convinced this is a problem, or…
Luis Pinto | Besu:or concern, but just, I think it's worth raising it.
Felix (Geth):Okay, I can very quickly address this. So, the way we see it is that, in some ways, I also felt the same way in the beginning, that it's a bit scary to introduce a primitive in the protocol that basically allows
Felix (Geth):full control over the signatures, but what you have to realize is that, in practice, a lot of Ethereum contracts have such logic, and we do trust them also. So it's not always just about the signature verification, there is…
Felix (Geth):Like, there… there are…
Felix (Geth):many places in the protocol where users now are subjected to a validation that is fully defined by the contract, and the only thing we're really changing here is that the transaction origin can be validated in a different way. And, I mean, it…
Felix (Geth):it's maybe along the same lines that you can see, like, would you personally trust putting your money into a specific wallet implementation? You always have to make that choice. There are conservative wallets, and there will be very simple ways to deploy accounts that
Felix (Geth):Don't have any of the advanced features, but literally just do the signature verification and that's it.
Felix (Geth):And they will be secure. I mean, we expect, at least I personally, I have to speak for myself here, I know that some of the authors on the frame transaction proposal don't think like this.
Felix (Geth):But for me, especially, I still think that, like, a good chunk of the signature verification is going to be handled by precompiles, simply because precompiles are easy to scale in terms of the compute, and they can also be incentivized. So…
Felix (Geth):It is something where… I feel very strongly that precompiles are there forever.
Felix (Geth):unlike some other people who see it as more like everything should be implemented in EVM opcodes, and the EVM should be fast enough to do this, both views, I think, are valid, but in terms of the safety, for example, of the cryptographic implementations, obviously, if you have a very simple contract that just forwards the call data in the verify frame directly into a precompile.
Felix (Geth):and just reports whether the verification was successful, then that is very safe and
Felix (Geth):We expect that most users will use a scheme like this.
Felix (Geth):instead of their account the way they have it now. But they can have the benefit then of, for example, migrating to a different encryption scheme later, and so on, because they might… they may be able to, for example, upgrade the verification that is deployed to their account.
Felix (Geth):Which is something that they cannot do now. If you create an account now by creating a public key, you cannot get off of that key.
Felix (Geth):Whereas in the new scheme, you can. And so we see that as a… actually, it's a…
Felix (Geth):It's a plus for the security.
Felix (Geth):Yeah, I hope that was helpful,
Felix (Geth):If not, we can discuss it further.
Felix (Geth):Luis, do you wanna… do you have a follow-up question, or is it… does it help you in your understanding, or…
Felix (Geth):No, no, that's… those are reasonable arguments, yes.
Luis Pinto | Besu:Yeah, well, you can look it either way, like, future upgrades as well make it easier, and don't need a hard fork and client consensus.
Luis Pinto | Besu:That's a good point.
Felix (Geth):Okay.
Felix (Geth):Very cool, so I think we resolved…
Felix (Geth):We still have Dano, and we have the DevTooling thing. I think, Dano, yours is gonna be…
Felix (Geth):Very specific, so let's just go with that one now. You've had your hand up for a long time also.
Danno Ferrin - Tectonic.xyz:Yeah, I'm concerned that there hasn't been enough thought, but it's the size of these signatures. Both quantum signatures, or generally speaking, going to be much larger. Best case scenario, half a kilobyte. More realistically, multiple kilobytes, and there's been illusion that we might need to do hashing signatures.
Danno Ferrin - Tectonic.xyz:And those are closer to 10 kilobytes per signature. So there's been talk from, on some EFers on Twitter that this is going to have to go towards signature aggregation.
Danno Ferrin - Tectonic.xyz:Which means we're gonna have to take the signature out of the transaction.
Danno Ferrin - Tectonic.xyz:So my comment on the current design is that putting the signature in the middle of the frame transaction means we're going to have to rewrite it, which is going to be very error-prone.
Danno Ferrin - Tectonic.xyz:The signature itself should be separated from the transaction body. It should be put in some other place that we can drop it. So either a separate table that follows afterwards, or the frame would reference a row in that table, or you're not going to like this.
Danno Ferrin - Tectonic.xyz:SSV is custom-built for this, to take one specific field, drop it out, and reference it by hash. So you take that signature, reference it by hash, and then you can have the,
Danno Ferrin - Tectonic.xyz:ZK proof for whatever aggregation you have, for those signatures, and you don't have to share that.
Danno Ferrin - Tectonic.xyz:So, blobs are not big enough for the signatures. These signatures, we're gonna hit giga gas just by data carriage alone.
Danno Ferrin - Tectonic.xyz:That's how big these are.
Felix (Geth):Okay, I can quickly go… I know, Matt, you also have your hand up, but I can also just very quickly, address a little bit of this. So,
Felix (Geth):We are aware of these signature sizes, and there has been stuff proposed. I just want to fundamentally state that I am not opposed to, for example, using SSC for the encoding. We are not married to the actual encoding of this, like, if SSC is the way to do it, and it gives us the benefit, I'm happy to do it. We just specced it the way we did it, because it's easier for us, we understand it better.
Felix (Geth):It was simpler to prototype.
Felix (Geth):There is no, we are not fundamentally attached to the ROP encoding of these transactions the way they are now.
Felix (Geth):So, that is still something we can fully debate.
Felix (Geth):That said, with the rewrites of the transaction, we have put, some effort into…
Felix (Geth):ensuring that, specifically, the verified frames of the transaction can… like, first of all, they are malleable, because they are not covered by the signature hash. Or, I mean, that's not true. The frame structure of the transaction is covered by the signature hash.
Felix (Geth):But the data content of the verify frames is not covered by the signature hash, because it is supposed to contain the signature. So this part can be alighted when it goes into the block.
Felix (Geth):And then what this will mean is that it is possible to publish a proof of the verification of these signatures at the end of the block.
Felix (Geth):Without losing too much information. And yes, it could be replaced by the hash of it for the sake of hashing the transaction and things like that. We are happy to, to work on these, on these things.
Danno Ferrin - Tectonic.xyz:Rewriting should be unnecessary. If you… rewriting should be unnecessary. If you structure the transaction right, you never have to rewrite sections of it when you change a signature.
Felix (Geth):Yeah, I mean, you don't have to… that's what I'm trying to say. I think what we are mostly talking about is just, like, there are different phases of the transaction, so one phase that we recognize is that when the transaction goes into a block, obviously we have an aggregation possibility, whereas when the user submits a transaction to the network, the transaction has to be somehow attached to the signature. And yeah, I mean, I understand it. We can structure it in a way that basically makes the… puts the…
Felix (Geth):Data at the end, or whatever, but it…
Felix (Geth):Doesn't really make too much of a difference, like.
Felix (Geth):for us right now. Anyway, this point, we will…
Felix (Geth):work on that, and I'm also happy to discuss it further with you offline, what is the perfect encoding for this, but we are aware of this. I just want to quickly give an alternative solution that was also proposed. There is,
Felix (Geth):a proposal from Vitalik for the future to, introduce an
Felix (Geth):operation in the EVM that basically gives you…
Felix (Geth):So, that would operate like a block-wide signature stack, so basically then what it would do is you'd
Felix (Geth):The block builder would come up with something that's a bit similar to, let's say, a block access list.
Felix (Geth):And, then the… each transaction would kind of basically index into that access list somehow, and just… you would… the transactions would… could be aggregated on… on that level. We are still in discussions, like, how to best present this option, but it is also something that has been discussed.
Felix (Geth):Anyway, I just want to mention that, yes, these concerns are very valid, and we are fully aware that introducing post-quantum signatures has a size issue, and it has to be addressed by the proposal. So, yeah.
Felix (Geth):That said, we did… we chose not to include this in this specific proposal, because we wanted it to be more about the generic,
Felix (Geth):Structure, and we'll see how this all…
Felix (Geth):Comes together, but definitely it is an important consideration.
lightclient:I just wanted to add two quick comments on, first, the rewriting aspect of the transaction. I don't really think that there is rewriting that needs to be done.
lightclient:You know, for the most part, like, the transaction as it's sent over the wire is how it looks at the block.
lightclient:the main two things that can be done is, you know, one is in the EIP, which is alighting the data in the frame transaction, so you can't introspect what the signature is from other transactions. This is what gives us the future ability to…
lightclient:Do some kind of signature aggregation there.
lightclient:We're open to different serialization schemes for this information. I don't think that that's particularly… that's, like, a particular sticking point for us. But the data is arbitrary, so we can choose to have some magic 4-byte field at the front of it, to denote that this is aggregatable format, whatever. So…
Danno Ferrin - Tectonic.xyz:If you're aggregating it, it's not how it goes over the wire, then. You're gonna… it's gonna have a different representation if you're taking a signature and not shipping the signature in the canonical block.
lightclient:Okay, I see, yeah, so you would remove it from the frame.
Danno Ferrin - Tectonic.xyz:Otherwise, what's the point of aggregation if we're.
lightclient:No, no, sorry, you'.
Danno Ferrin - Tectonic.xyz:you know, gigabyte blocks.
lightclient:Yeah, okay, sorry. You're right about this? We do… we would need to rewrite it in that case.
lightclient:But this is how we are already representing it, as the,
lightclient:This is the serialization scheme that we already represented in.
lightclient:So I think that it's not a major issue.
lightclient:And it's done by the block builder already.
lightclient:So, it's okay. We do this for blob transactions. The blob looks slightly different over the wire. We don't include the blob in the block.
lightclient:I think these are okay.
lightclient:the broader points I wanted to make about
lightclient:Why do this now, even if the signatures are large?
lightclient:Is… it's going to take a very long time for people to migrate to post-quantum crypto.
lightclient:And…
lightclient:Today, maybe the signature schemes are large, maybe the people who need post-quantum crypto are a smaller group. That's going to grow over time. It's going to take time for tooling to support it, it's going to take time for wallets to support it, it's going to take time for users to decide that they're ready to migrate to that. And the sooner that we can make this start.
lightclient:The better place we're gonna be in in 3 years, 5 years, you know, at whatever time period that we…
lightclient:realize that everybody needs to start migrating. I don't think that there is a good, feasible path to doing an all-at-once migration for users.
lightclient:Is this something that's kind of been talked in the past? You know, one day maybe the quantum canary goes off, and it's time to migrate all the accounts. I don't think there is a good mechanism to migrate all theory into concept plus quantum, so we need to start early, and we need to start educating people that they should look into this.
Felix (Geth):Yeah, notably, the proposal does not define a migration path. It gives people the option to create accounts which are not linked to an ECDSA key, but it does not give people the means to fully unlink their account from the ECDSA key.
Felix (Geth):We do see that as a separate step, but it could be as simple as an operation that installs a delegation and then gives you, like, throws away the key, basically.
Felix (Geth):So there is, like, you could somehow permanently delegate your account to some code, and not make it possible to create further delegations. These kinds of mechanisms have to be specified in a different EAB.
Felix (Geth):But we feel like once the way is there for people to actually create accounts that are not linked to any key, it is possible for us to introduce these kinds of mechanisms, but introducing them before is not possible.
Felix (Geth):Right, so we still want to discuss a bit about the dev tooling. Dragon, you had some comments, it seemed like you were reporting these comments from another discussion.
Felix (Geth):I'm less sure where they are coming from.
Dragan Rakita:Well, I'm still not convinced that we should do framed intersection.
Dragan Rakita:I know that we started this, like, discussion as, do you have questions about framed resection, but…
Dragan Rakita:I could, like, switch up that to basically ask why do we even want framed section.
Dragan Rakita:Because I'm not convinced that this is, like, solution that you want to include in Ethereum.
Dragan Rakita:So, maybe I'm just… I'm talking just in my, like, in my view, so…
Dragan Rakita:There are a lot of clients, a lot of developers.
Dragan Rakita:So, yeah.
Felix (Geth):Yeah, I mean, I understand that it's a lot, like, that's the thing, this proposal is kind of a lot, I understand that. I also, when I first saw this, I had kind of a similar reaction. I mean, I got introduced to this proposal idea by way of talking to Vitalik, and he basically presented,
Felix (Geth):Version of this, to me, and…
Felix (Geth):I was thinking, like, oh my god, this is nuts, like, we should never do this. But then at… over… over time, I actually really warmed up to it, and I think it does solve the problem in a very fundamental way. So, just want to highlight that.
Felix (Geth):it…
Felix (Geth):it's a very… it tries to address this issue at a very, very fundamental level. It goes a bit beyond just saying, yeah, we should add a new signature type on the transaction. It's not as simple as that, because it's kind of this combo solution that, like, solves a bunch of different issues of Ethereum at the same time.
Felix (Geth):I can fully understand that it can seem a bit overwhelming at first, so that's also why I wanted to have this discussion, to really address all these points, like, that people have, like, what's it gonna do to this? What's it gonna do to that? Like, what are the… why is it so…
Felix (Geth):Yeah, but… Why is this so weird?
Dragan Rakita:I think that's the main problem that I have with this.
Dragan Rakita:Is the main point for the frame intersection to, like, introduce new signature types?
Dragan Rakita:we have a simple solution that we should use. There's not a lot of signatures out there, and there is not a.
lightclient:It's not just to do one thing, though, like, we kind of said this…
lightclient:You know, it has a primary purpose, but there is a long tail of
lightclient:things that the frame transaction finally solves once and for all, and none of the other proposals address those. I don't think that we should do these, like, keyhole solutions for every single problem. We should come up with a general framework that's powerful.
Dragan Rakita:Now, my sub-question to that, what are… what are those additional problems that you want to solve with this generic solution?
lightclient:Yeah, so I mentioned one concrete one in the chat, but there's an issue with privacy protocols.
lightclient:So… privacy protocols.
lightclient:don't really have a good way around the fact that an EOA today needs to submit a transaction to withdraw the ETH. So that means either you need to somehow get anonymous ETH to withdraw, or you need to go through a centralized provider. So it adds better privacy for your users.
lightclient:It adds better trustlessness, because you don't have to rely on a centralized party. There's also the point that Frederick brought up, which is transaction assertions.
lightclient:So, frame transactions allow you to have multiple frames, and you can have more complicated
lightclient:validation logic around whether a transaction should be included or not. So you could actually add, at the end of the transaction, the approval frame to
lightclient:Pay for the gas and approve the overall transaction, only if certain assertions were met.
lightclient:So, again, like, this is just the stuff that we've, like, kind of come up with. There's a handful of other things. There will be more things that people come up with that we can't even imagine right now. That's the benefit of permissionless innovation.
Dragan Rakita:That's what I'm saying. Basically, what are the use cases that you want this generic solution to enable? If there is, like, 2, or maybe 3, or maybe 5,
Dragan Rakita:It doesn't need… you don't need a general framework for those.
lightclient:I mean, that's just what we disagree on.
Dragan Rakita:That's true.
lightclient:I mean, I think this is what Ethereum was built on, is providing generalized frameworks for people to innovate.
lightclient:And I don't agree that we should come up with a prefix menu of solutions for users.
Felix (Geth):There's also an argument from Vitalik, that I found personally very, very good. So,
Felix (Geth):there is always the question of, like, what should be the special cases in the protocol? And right now, we've kind of gotten in the habit of special casing everything, whereas this proposal is… it doesn't really have… like, there are no special cases, but you can do the use cases with it, and you can also do the future use cases with it.
Felix (Geth):Like, privacy protocols is kind of a big thing that's never really been possible before. Maybe a couple issues, like, couple, like, smaller-scale proposals have existed, but they would always come at the cost of creating
Felix (Geth):Yeah, like a special case in the protocol just for this one thing, and we wouldn't really be able to…
Felix (Geth):figure it out, like, in another way. And then now, for example, we're considering this problem of, adding signature flexibility on the transactions. Yeah, I mean, there's a specialized proposal for that, where we're creating a special case where, like, how do you sign this specific thing? But then again, it's like…
Felix (Geth):We're gonna come up with even more things, like, it's just gonna multiply the amount of special cases we have in the protocol, whereas with this thing, we have to…
Felix (Geth):the… the possibility of removing special cases, and we're really happy about that. So that's kind of where we're coming from with this.
Felix (Geth):I know, Anska, you wanted to probably remind us of the time, or I don't know…
Ansgar Dietrichs:Yeah, I mean, I was… I just want to just briefly interject, like, I think I initially wanted to have a bit more time, in case we still wanted to make a decision. It seems clear to me now that we are just not going to make a decision today, so then, in terms of, like, next steps, then it will be very simple, so then, yeah, if we want to have 2-3 more minutes to wrap up, then that's fine.
Felix (Geth):Yeah, I was kind of curious about this DevTooling comment. I still kind of wanted to get to that thing, like, you posted that initially, and I wanted to just highlight some things from that. I mean, I started by quoting this, and then we went into a whole other discussion, so if we just quickly go back to this… to this point. So, you wrote earlier that
Felix (Geth):I think this comment kind of also highlights maybe some of the misconception about this. So you're saying that, like, developers don't want to worry about defining the frames, so we don't really see it like that.
Felix (Geth):The fundamental thing that people will do is just…
Felix (Geth):The… or the fundamental thing that is…
Felix (Geth):how these transactions work is that you have to come up with your contract invocation payload the same way you have to come up with your contract invocation now. It is just more like a different way of encoding your signature.
Felix (Geth):and possibly your fee-paying logic into the transaction. So all of these, like, the way this…
Felix (Geth):thing works is maybe more like a… you can think of it as more like a data format for the transaction. And it's different from the previous data formats of transactions, because it does things in this, like, dynamic list type of way, but…
Felix (Geth):It is fundamentally just a different way to put your transaction in… to put your signature in.
Felix (Geth):You can have more advanced use cases with the frames, but these use cases are for special…
Felix (Geth):occasions. For example, you can do the native bundling with this. If bundling is a necessity for some use cases, you can
Felix (Geth):use it for that. Or you can have things like, conditions on your… on the transaction inclusion. These are also possible with this proposal, and you can encode them as frames.
Felix (Geth):It gives you some advantages to do it like that.
Felix (Geth):Yeah, I don't know. I don't think that fundamentally, like, the dev tooling has to change very much. It has to learn how to encode the transaction, but this is something that every transaction type so far has required.
Felix (Geth):So, there have always been updates to all the tooling for each new transaction type, because we expect people to submit their transaction in the…
Felix (Geth):binary format now, which means that, yeah, the libraries have to accommodate for the new type, so it's no different with this one. But we also do not expect libraries to give users, like.
Felix (Geth):complete
Felix (Geth):access to, like, structuring their transactions. It is in practice, or maybe they can, but it's not expected that users will have to think too much about the frame structure of their transactions. Most transactions are gonna be really simple. They're gonna have a verify frame that defines the signature, they're maybe gonna have a frame that
Felix (Geth):Delegates the gas payment, and then they're gonna have the main execute frame that just…
Felix (Geth):puts the payload to the contract. And we expect that for most people, this is gonna be how this is used. And then for the certain special use cases, for example, withdrawal from privacy protocols or other things, you may have additional frames or a slightly different structure, but it's more like an advanced thing.
Felix (Geth):So that's how we see it.
Ansgar Dietrichs:Okay, yeah, then this is a good stopping point for now. As I said just now, I think it seemed clear that we won't be in a position to make a decision today, just because I think we both have the rest team still maybe not convinced in general about prime transactions, and then we also had
Ansgar Dietrichs:For example, the Bezu team saying that they don't feel comfortable with committing today, but before having discussed more with the team.
Ansgar Dietrichs:It does seem like, even after this discussion, there's still open discussion points, and maybe instead of just making it very specific about frames, it does seem like there's maybe some discussion
Ansgar Dietrichs:need about, like, the general future approach to transaction, transaction generalization? Do we even want to do some general purpose account abstraction? Should… could we get away with more special purpose, just kind of, like, some, some more transaction?
Ansgar Dietrichs:extensions, it feels sensible to still schedule a breakout call, to just basically talk about
Ansgar Dietrichs:You know, the future of transactions, and isFrameTransactions what we want to do, and want to do now?
Ansgar Dietrichs:If that's… does that… does that seem sensible for the Prime Transaction Champions?
lightclient:Sounds good.
Ansgar Dietrichs:Okay, then I think we'll, async figure out an exact date and announce that for people to join. I also initially had the hope to maybe just, like, already reduce the number of headliner proposals, but I feel like it's just… there's not necessarily a point in it right now. Also, there was still enough residual support for Lucid that I don't want to just…
Ansgar Dietrichs:push this through now if there's no specific reason for it, so then I would say.
Ansgar Dietrichs:for the Lucid Champions, you know, the next two weeks would be your chance to basically make a difference in moving the… in convincing people that this should happen now. It seems like a lot of people in general like the idea, but most people feel like it's just premature and not necessarily maybe robust enough yet. Yeah, you have two weeks to…
Ansgar Dietrichs:Yeah, I mean, I don't know.
Ansgar Dietrichs:Sure, unless… Yep.
lightclient:Guys, Lucid's not going in the protocol for Hagota. Like, we can just make this decision right now.
Ansgar Dietrichs:Sure, I mean, we can also, yes, we can also reject the Lucid and SEC headliner proposals today, if people prefer.
Ansgar Dietrichs:Just not sure we'll have… Client consensus on this?
lightclient:I mean, only one client proposed Lucid as their headliner. That seems…
lightclient:Sufficient on its face to make a decision.
Ansgar Dietrichs:I think we had Erigon saying that if not Frame, they would strongly prefer doing something other than nothing, so they would basically prefer Lucid over nothing.
lightclient:But still 2 clients versus 3 clients.
Ansgar Dietrichs:Right, this is just why, you know, it doesn't seem like consensus.
lightclient:I think we should whittle away at our options.
lightclient:I feel extremely strongly about not doing Lucid. I think a lot of the guest team feels very strongly about this.
lightclient:I think other client teams also feel somewhat strongly about not doing Lucid.
lightclient:Like, we're just going to waste time if we continue talking about this.
Ansgar Dietrichs:Right. Yeah, that's why I initially wanted to timebox the frame transaction discussion more, to have more time for this, but, sure, then…
Ansgar Dietrichs:from the Besu and Erigon team's side, I… they…
Ansgar Dietrichs:Do… are these… are both of those teams open to rejecting Lucid for Edgestar today, or would you basically prefer to veto that decision and leave it up for two weeks from now?
Daniel Lehrner (Besu):I would prefer if we wait for two weeks. I don't think we waste a lot of time if we have one breakout car.
lightclient:Erigon?
andrew (erigon):Yes, so we'd also like to keep Lucid as an option as well.
Ansgar Dietrichs:Yeah, then, Matt, I think, we will stick with keeping it for now. I think the understanding is very clearly that
Ansgar Dietrichs:Unless people…
Ansgar Dietrichs:change their minds strongly, which of course could happen, but I think otherwise it will be more a backup candidate to discuss in case we end up deciding against prime transactions. I don't think it'll take up much room by default.
lightclient:What if I'm willing to die on the hill of not including Lucid transactions?
Ansgar Dietrichs:Then, 2 weeks from now would be your time to die.
Ansgar Dietrichs:Or to specifically, like, block Lucid.
nixo:Matt, you also have a conflict of interest here, I think that… It's…
nixo:It's good to… to keep considering it.
Felix (Geth):Yeah, I have to agree. Unfortunately, I think, I mean, as much as you can be against it, we have to give it a fair chance.
Ansgar Dietrichs:Okay, so no dying on hills today, then. So, yes.
Ansgar Dietrichs:We will not formally reject headliners today.
Ansgar Dietrichs:But the understanding is clear that in two weeks, we will make a decision.
Ansgar Dietrichs:And the clear two main frontrunners are, frame transactions or doing nothing, and we will have a breakout to specifically discuss frame transactions. If the Lucid people want to organize a breakout as well or something, that's of course possible. Just reach out to us.
Ansgar Dietrichs:Awesome. That's all for now, then. Thank you all very much, and talk to you in two weeks.
Potuz:Bye.
andrew (erigon):Thank you, bye-bye.
lightclient:See ya.
Chat Logs
00:02:13
Ansgar Dietrichs:link to agenda: https://github.com/ethereum/pm/issues/1931
00:02:56
Barnabas:https://dora.blob-devnet-0.ethpandaops.io/
00:03:22
Barnabas:https://dora.bal-devnet-2.ethpandaops.io
00:04:03
Barnabas:https://dora.nft-devnet-10.ethpandaops.io
00:04:24
Ansgar Dietrichs:Replying to "https://dora.nft-dev..."
good to see nfts living on in devnet form at least
00:04:27
Barnabas:https://dora.perf-devnet-3.ethpandaops.io
00:05:25
Barnabas:https://notes.ethereum.org/@ethpandaops/bal-devnet-3
00:06:38
Marius van der Wijden:Whats the hardcoded value? @spencer
00:07:50
Barnabas:Replying to "https://dora.nft-dev..."
gotta keep the memes alive
00:09:14
spencer:At a 100M block gas limit, cost_per_state_byte = 1174.
00:09:42
spencer:Replying to "At a 100M block ga..."
Lets add this to devnet-3 markdown.
00:11:15
Sina Mahmoodi:https://notes.ethereum.org/j65MUa-KTB-hZ2kDrijS9A
00:12:38
Barnabas:could you pls paste the pr?
00:12:55
Ansgar Dietrichs:the new pr: https://github.com/ethereum/execution-apis/pull/758
00:13:16
Mercy Boma Naps-Nkari:https://github.com/ethereum/execution-apis/pull/758
00:14:07
Felix (Geth):client devs, please leave a comment on the PR to indicate your support and/or any changes you wish to see
00:14:56
Mercy Boma Naps-Nkari:Thank you
00:16:08
Fabio Di Fabio:that was one of my comment
00:16:50
Fabio Di Fabio:we should have support for filtering
00:19:14
jochem-brouwer (Fairphone):Which eip is the Lucid one?
00:19:31
Anders Elowsson:The EIP is in draft stage, we will share over the weekend
00:19:49
jochem-brouwer (Fairphone):Replying to "The EIP is in draft ..."
Ok great! Thanks 😊
00:22:08
Ansgar Dietrichs:Erigon: https://github.com/ethereum/pm/issues/1931#issuecomment-3961108850
00:22:15
Ansgar Dietrichs:Besu: https://hackmd.io/@YwTR7izNSrCEQYKWdzdy_Q/Syutq86OZe
00:22:58
Barnabas:Geth: https://notes.ethereum.org/@lightclient/h-is-for-hardness
00:24:56
Anders Elowsson:Geth - Could you elaborate on this from the Headliner note with reference to LUCID:
“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?
00:25:05
andrew (erigon):Shutter is deployed on Gnosis Chain
00:25:19
Anders Elowsson:How does metadata leak?
00:25:27
Potuz:How does Lucid leak that? If anyone can send for others
00:25:53
Anders Elowsson:Replying to "How does Lucid leak ..."
It shouldn’t
00:26:10
Barnabas:Nethermind proposal: No EIPs for bogota 😂
00:26:12
nixo:“no headliner for the EL” is a valid option
00:26:21
Marius van der Wijden:Just to note: my personal opinion is to not choose an EL headliner for Glamsterdam. I think all proposed eips are not ready yet
00:26:28
Luis Pinto | Besu:There was another EIP alternative for new transaction signatures without Frame transactions
00:26:35
Barnabas:Replying to "Just to note: my per..."
glamsterdam?
00:26:45
Felix (Geth):Replying to "There was another ..."
we can go into that
00:26:46
Lumi | Offchain Labs:Replying to "There was another EI..."
Yeah it was by base
00:26:47
Marius van der Wijden:Replying to "Just to note: my per..."
Sorry H*
00:26:56
Felix (Geth):Replying to "There was another ..."
it would be good to settle this early on
00:27:51
Ansgar Dietrichs:I also hope I am here :-)
00:29:03
Dragan Rakita:Replying to "I also hope I am her..."
Didn’t know if Jen joined or not 🙂
00:29:12
Ansgar Dietrichs:Replying to "I also hope I am her..."
haha yes makes sense
00:30:15
Barnabas:since claude 4.6 😂
00:32:29 Ł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.
00:30:33
Felix (Geth):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.
00:30:38
Łukasz Rozmej:Replying to "Actually I have not-..."
Everyone should read this: https://x.com/yq_acc/status/2026678055092236438
00:30:46
Dragan Rakita:Replying to "since claude 4.6 😂"
amp is good
00:30:55
Ansgar Dietrichs:Nimbus EL: https://github.com/ethereum/pm/issues/1931#issuecomment-3966735519
00:33:41
Dragan Rakita: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.
00:34:17
Luis Pinto | Besu:Replying to "There was another EI..."
It does make EVMs more complex contrary to what is the long term goal with lean
00:34:17
lightclient:Doing nothing seems like a waste of 2026
00:34:19
Dragan Rakita: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.
00:34:26
CPerezz: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
00:34:37
Łukasz Rozmej: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.
00:34:39
Felix (Geth):Replying to "There was another ..."
I don't understand why it makes dev tooling complicated
00:34:42
Anders Elowsson:Replying to "Doing nothing seems ..."
It means doing more low-level EIPs like EIP-7999 for example though
00:34:57
CPerezz:Replying to "There was another EI..."
We are discussing improvements to the protocol. We can’t have it all
00:35:06
Anders Elowsson:Replying to "Doing nothing seems ..."
“Doing nothing” is essentially “ship more EIPs”
00:35:15
Dustin:Yeah it's not time-sensitive
00:35:18
Felix (Geth):Replying to "There was another ..."
I understand that it requires an initial investment from the wallet side to support it
00:35:20
Danno Ferrin - Tectonic.xyz: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
00:35:31
lightclient:Replying to "Doing nothing seems ..."
I don’t see them as equivalent
00:35:56
Danno Ferrin - Tectonic.xyz:Replying to "Doing nothing seems ..."
It’s more non-headliners vs a controvertial headliner
00:35:58
Luis Pinto | Besu: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
00:36:07
Justin Florentine (Besu):we would still ship whatever EIPs are ready when FOCIL ships
00:36:13
Felix (Geth):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.
00:36:22
Danno Ferrin - Tectonic.xyz:Replying to "Doing nothing seems ..."
We did it in Osaka, and that was well receieved.
00:36:33
Felix (Geth):Replying to "There was another ..."
@Luis Pinto | Besu let's discuss it in a separate call
00:36:44
Felix (Geth):Replying to "There was another ..."
I don't think we will reach a conclusion here in Zoom comments
00:37:25
lightclient:I think it is between Frame and “do nothing"
00:37:38
Julian Ma: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?
00:39:24
Potuz:How long before were the other proposals raised?
00:39:34
Dragan Rakita: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%.
00:40:07
Francesco: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
00:40:30
Francesco:Replying to "How long before were..."
Can we really say that we’d know what we’re getting into with encrypted mempools?
00:41:48
Dustin:For Nimbus, frame tx's are a fine fallback
00:41:57
Dragan Rakita:Replying to "There was another EI..."
Imo listing what frame tx does, and doing exactly this concrete implementation would give better results.
00:42:04
Anders Elowsson:Replying to "How long before were..."
Perfectly valid point. I just said we do not leak metadata 🙂
00:42:52
Barnabas:we still have 45 mins
00:42:58
Barnabas:lets just talk about it now?
00:43:04
Julian Ma:Replying to "There was another EI..."
Thanks @Dragan Rakita !
00:43:43
Francesco: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
00:43:57
Łukasz Rozmej:potentially same breakout/Q&A for LUCID?
00:44:11
Parithosh Jayanthi:If people who make the decisions are here, then we can assume qorum
00:44:13
lightclient:Replying to "potentially same bre..."
I don’t feel like there is enough interest in LUCID
00:44:22
Justin Florentine (Besu):Replying to "potentially same bre..."
wut
00:44:26
Marius van der Wijden:I think if there's nothing else, this is the most important thing to discuss
00:44:26
Parithosh Jayanthi:i.e if we were fine with making the decision with this crew, we can do the FRAME discussion with the same group
00:44:28
Stefan Starflinger:Replying to "potentially same bre…"
Wur
00:44:32
lightclient:Replying to "potentially same bre..."
Only 1 client
00:44:33
Stefan Starflinger:Replying to "potentially same bre…"
Wut*
00:44:36
Justin Florentine (Besu):Replying to "potentially same bre..."
i mean, not on this call right now, sure.
00:44:39
jochem-brouwer (Fairphone):I feel like we should do an in depth discussion an announced breakout call
00:44:41
Marius van der Wijden:Have discussion now, make decision next week
00:44:45
Dragan Rakita: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
00:45:13
lightclient:Replying to "potentially same bre..."
What clients aren’t on the call?
00:45:15
Łukasz Rozmej:Replying to "potentially same bre..."
Erigon mentioned LUCID
00:45:36
lightclient:But they chose Frame over LUCID
00:45:44
Łukasz Rozmej:Replying to "potentially same bre..."
we are also not opposed per se, just not convinced
00:46:02
jochem-brouwer (Fairphone):Ah ok then we should use time remaining to discuss now, missed that this was all of agenda
00:46:02
Justin Florentine (Besu):Replying to "potentially same bre..."
nobody is proposing spending the rest of the call on LUCID.
00:46:14
Łukasz Rozmej:Replying to "potentially same bre..."
yes but those two would robably closest to compeating for headliner, so why not?
00:46:30
Łukasz Rozmej:Replying to "potentially same bre..."
yep having breakout call
00:47:08
Danno Ferrin - Tectonic.xyz:No headliner does not mean nothing. It means there’s room for more smaller EIPs. Many of these can have outsized impact to effort.
00:47:27
Ansgar Dietrichs:right, so no headliner could enable:
faster fork
more non-headliner EIPs
00:47:33
Potuz: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
00:48:43
Justin Florentine (Besu):There is an Encrypted Mempool working group call next Wed. Happy to go over LUCID there.
00:49:39
Dragan Rakita:Replying to "Screenshot2026_02_26_154444.jpg"
I like this notion 😄
00:49:42
Marius van der Wijden:How much adoption do you expect to happen for frametxs? What are the problems with 7701 that this should fix?
00:49:54
Ansgar Dietrichs: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?
00:49:58
Barnabas:Replying to "Screenshot2026_02_26_154444.jpg"
@lightclient this is not how you sell me this pen 😂
00:50:08
Danno Ferrin - Tectonic.xyz:How “in the weeds” do we want to get with the questions?
00:50:13
Daniel Lehrner (Besu):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
00:50:14
lightclient:Replying to "Screenshot2026_02_26_154444.jpg"
I’m not a salesman guys I’m sorry
00:50:21
lightclient:Replying to "From Besu side I do ..."
Yeah that’s okay
00:50:28
lightclient:Replying to "From Besu side I do ..."
I don’t think we expect a decision
00:50:34
Ansgar Dietrichs:Replying to "From Besu side I do ..."
right, that was my thinking for prefering a breakout call
00:50:46
Ansgar Dietrichs:Replying to "From Besu side I do ..."
to allow such people not on the call today to ask questions as well
00:51:04
Dustin: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
00:51:26
Ansgar Dietrichs:it seems to me like it will likely be a decision between frame txs and no headliner, with an outside chance for LUCID still
00:53:09
Tamaghna Choudhuri: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
00:53:46
Dragan Rakita:Example of simpler solution: https://github.com/ethereum/EIPs/pull/11355 (Done it today)
00:54:46
Łukasz Rozmej: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
00:55:18
Luca Donno | L2BEAT:also this https://github.com/ethereum/EIPs/pull/11330
00:55:55
Ansgar Dietrichs: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.
00:56:00
Dragan Rakita:Replying to "also this https://gi..."
This is more for eip-7702 but point is there
00:56:35
Danno Ferrin - Tectonic.xyz: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?
00:56:48
Danno Ferrin - Tectonic.xyz:Replying to "The first line of 81..."
the motivation
00:57:47
Łukasz Rozmej:well if transaction types are composible then that's a different thing
00:58:39
Tamaghna Choudhuri: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) 🙂
00:59:22
Łukasz Rozmej:current transaction types are kind of built with OO inheritance model, maybe we should just abandon this model and go with composability?
01:00:08
Dragan Rakita:Replying to "well if transaction ..."
Sharing it here https://github.com/ethereum/EIPs/pull/11355
01:00:24
Dustin: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
01:00:28
Dustin:it bloats quickly
01:00:31
Ansgar Dietrichs: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
01:01:07
Ansgar Dietrichs: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
01:03:06
Danno Ferrin - Tectonic.xyz:My subject is signature size and long term how it’s going to be addressed
01:04:04
lightclient: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
01:05:19
Ahmad Bitar | Nethermind:Time to enshrine smart account implementation :p
01:06:21
Danno Ferrin - Tectonic.xyz:EVM opcodes cannot handle Post-Quantum Cryptography. No mattter what extensions are added. RISC-V is a better solution, precompiles are the best.
01:06:29
Łukasz Rozmej:Replying to "My subject is signat..."
based on https://x.com/yq_acc/status/2026250003577209173 signature sizes grow 51x to 3,3GB/slot(!)
01:07:07
Ansgar Dietrichs:you’d have up to 10 more mins
01:07:44
lightclient: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
01:08:26
Barnabas:blobs can store the signatures
01:08:32
Barnabas:nobody is using blobs anyways
01:08:41
Marius van der Wijden:Whoooo ssz mention 🙀
01:08:53
Justin Florentine (Besu):drink?
01:09:22
Danno Ferrin - Tectonic.xyz:And with a net-benificial use too!
01:10:15
Ansgar Dietrichs: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)
01:12:34
Daniel Lehrner (Besu):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
01:13:37
Ansgar Dietrichs:Replying to "one benefit of headl..."
agreed
01:13:49
Dragan Rakita:tbh, I am not convinced the frame tx is something that we should do
01:14:09
Danno Ferrin - Tectonic.xyz:Replying to "tbh, I am not convin..."
So is this a flat no from reth?
01:15:02
Danno Ferrin - Tectonic.xyz:The blob wire transaction is different from the block tx, this is the kind of severability we need to see in the frame transaction
01:15:37
lightclient:Replying to "The blob wire transa..."
Yep my mistake, you’re right about that
01:15:47
Danno Ferrin - Tectonic.xyz:Moscas Equation (X+Y>Z) - account migration is the X part. It’s a problem.
01:16:23
lightclient:Replying to "The blob wire transa..."
I think it is pretty easy to “remove” though since there isn’t introspection of it
01:16:38
Ansgar Dietrichs: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
01:16:56
lightclient:Replying to "I personally would b..."
We are serious
01:17:34
Ansgar Dietrichs:would be good if we could wrap up the segment
01:19:31
Fredrik:We can also add Transaction assertions to it
01:20:27
Greg K | Lido: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
01:21:08
Andy:PQ private transactions at the app layer will take much longer to get adoption and it'll be more expensive to build
01:21:14
Andy:Replying to "PQ private transac..."
There are +40 teams building private transfers at app leve;. Huge demand
01:21:25
Andy:Replying to "PQ private transac..."
But PQ and cost is very tricky
01:21:39
Marius van der Wijden:I think we should definitely look how this will/might be used by users
01:21:50
frangio:the goals have been clearly stated by vitalik in this document:
https://docs.fileverse.io/0xd961b83d3421bddec9d8966efabf13800617cfea/10#key=Z-XeQk6mE7uZX9Q2ZbqWkiniYi9IZ1oSbd_2vPFyt26S7Kf8gO_UHpLJ936--lp8
01:22:42
Barnabas:Replying to "I think we should de..."
can we get a breakout call with wallets?dapps on?
01:22:42
lightclient:Replying to "I think we should de..."
I think we have looked at it a lot
01:23:17
Barnabas: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
01:23:21
Andy:Replying to "I think we should ..."
how does success look like?
01:23:43
Barnabas:Replying to "I think we should de..."
having metamask/rabby/other big wallets support it on day 0
01:23:47
Derek Chiang: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
01:25:17
Marius van der Wijden:Can we get rid of old tx types with this at some point
01:25:17
lightclient: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
01:25:37
Barnabas:Replying to "As someone who has b..."
Derek, which company you work for?
01:25:39
frangio:wallet_sendCalls
01:25:41
Danno Ferrin - Tectonic.xyz:Replying to "Can we get rid of ol..."
Not if we don’t put authorizations in the frame tx
01:25:46
Derek Chiang:Replying to "As someone who has b..."
ZeroDev
01:25:52
Andy:Replying to "I think we should ..."
So 2/3 commitments from big wallets saying they'd implement this?
01:25:56
Andy:Replying to "I think we should ..."
Seems sensible and attainable
01:26:26
Łukasz Rozmej:Replying to "Can we get rid of ol..."
Maybe if we put the old tx's as data of the frame?
01:26:48
Felix (Geth):Replying to "Can we get rid of ..."
there are also solutions like the SETDELEGATE instruction
01:27:08
FLCL:Replying to "Can we get rid of ol..."
It implies no more new tx types?
01:27:10
Danno Ferrin - Tectonic.xyz: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.
01:27:50
Felix (Geth):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!
01:28:07
lightclient:Let’s make a decision now
01:28:13
lightclient:LUCID is not going in the protocol
01:28:39
lightclient:Let’s just focus on frame vs. doing nothing
01:28:55
Felix (Geth):Replying to "Can we get rid of ..."
@FLCL "no more new tx types" -- this is the dream :)
01:29:52
Dragan Rakita:Replying to "As someone who has b..."
Take is doing this natively is going to give better solution over complex general solution.
01:30:02
FLCL:How does frames + ssz sound
01:30:11
Greg K | Lido:On the other hand, keeping LUCID alive, will give incentives continue working on it and flush out details over the next 2 weeks
01:30:35
Felix (Geth):Replying to "As someone who has..."
do you have a link?
01:30:55
Justin Florentine (Besu):we'll keep on working on it regardless
01:31:01
Barnabas:lmao
01:31:14
Potuz:Don’t kill yourself Matt over this
01:31:30
Tamaghna Choudhuri:Replying to "How does frames + ss..."
Basically the nimbus stand summed up xd
01:31:33
Anders Elowsson:lol
01:31:36
felix (eest):Replying to "Don’t kill yourse..."
(in minecraft)
01:31:39
lightclient:2 more weeks I guess
01:31:50
Felix (Geth):Replying to "How does frames + ..."
I'm ok with it!
01:32:05
Greg K | Lido:Replying to "we'll keep on work..."
Yep, I meant also people providing feedback etc
Summary
24 highlights
· 3 action itemsExperimental
Summary
24 highlights · 3 action itemsExperimentalfork status and schedule
devnet updates
- blob-devnet-0 testing partial clouds; Lighthouse and Prism onboarded00:02:56
- bal-devnet-2 testing local access lists; eTrex syncing, Erigon issues remain00:03:16
- nft-devnet-10 testing EIP-870 P2P protocol with increased header sizes00:03:56
- perf-devnet-3 relaunched after chain halt; previous instance unrecoverable00:04:17
- bal-devnet-3 launches next Wednesday; scope includes EIP-7954, optional 870/87100:05:25
- EIP-8037 downscoped to static value increase only for devnet-300:06:29
- Static value: cost_per_state_byte = 1174 at 100M block gas limit00:07:50
- Test release target: end of tomorrow (Feb 27)00:08:12
headliner discussion
- EIP-8105 withdrawn; champions endorse Lucid as consolidated encrypted mempool proposal00:18:38
- Lucid EIP still in draft; will be shared over weekend00:19:31
- Erigon position: likes Lucid or Frame; no headliner okay to prioritize quick slots, etc.00:21:52
- Besu position: prefers Lucid; Frame acceptable as second choice00:22:15
- Geth position: Frame Transactions preferred; Lucid and SSZ not mature enough00:22:58
- Nethermind position: not convinced by complexity of either Frame or Lucid00:25:37
- Reth position: Frame over-engineered; SSZ has low benefit-to-work ratio00:27:41
- Nimbus EL position: prefers SSZ with Frame; Frame acceptable without SSZ00:30:49
- Main debate: Frame Transactions vs no EL headliner00:33:41
- Frame Transactions removes protocol signature requirements entirely00:49:58
- Frame TX enables privacy pools without centralized relayers01:03:09
- Lucid and SSZ remain under consideration pending two-week discussion period01:28:12