All Core Devs - Execution #231

Transcript

Ansgar Dietrichs: Hello, hello, everyone, can you hear me?

Guillaume Ballet: Yup.

Ansgar Dietrichs: Perfect. Okay, would we be ready to go live?

Josh Davis: Yeah, Renny, when you are.

Ansgar Dietrichs: Sounds good? Then let's go live.

Josh Davis: You're alive. Take it away.

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 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 Busa: Sure, so we currently have, 3 or 4 running the nets, The current one is blob.net0, where we are testing, And the partial cloud stuff. 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. Then we have, the big one, the blob devnet 2. This is where we test the local level access list. We have onboarded Besu and Erigon, this week. Besu has been, up to head since they've been, included, and Erigon, also failed to sink to head. So we are still waiting on Erigon to… be able to reach to the HUD.

I hope they can take a look, otherwise we're gonna be taking a look into that, In the coming days. We also have the NFT DevNet, 10. Where we are testing 870. It's a new P2P, protocol, that is, increasing the header size. I think… And we have… One more, the Pectra DevNet 3. That just got relaunched, right now. 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, Over again, and, hopefully, we can actually succeed this time.

That's about it for visits.

Ansgar Dietrichs: Sounds good. And then, I think there was some discussion about… 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 Busa: Right, so, Blob DevNet 3 is scheduled to launch next week, Wednesday, and, So is actually ePBS at, zero. So that's a huge… Improvement, and we have a spec sheet for more than 3. Just to keep it relevant for executioner clients. So the idea was that we are going to introduce, 7954, which is the increased maximum contract size. We're going to optionally, include 870, and optionally include 871 as the networking changes, and 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? That's still being discussed.

Barnabas Busa: 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… Decided to go with the static value increase, and And just go with that for now, so that we can hit the deadline of next week, Wednesday, for the launch. With some, hardcore devices.

Ansgar Dietrichs: Yeah, that seems very reasonable.

Barnabas Busa: 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 Taylor-Brown: Yeah, so, 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. I can quickly, add this to the chat later. I think last, on All Core Devs Testing as well. I mentioned that we'd try and get tests out for today, but yeah, I think… I think we'll be able to manage that tomorrow now. And yeah, kind of an update on the 8037 tests is, Yeah, we'll have, like, 8037-specific tests, all of the non-static tests in our repo filled for 8037, and… Around 60% of the, ethereum, tests. I guess, just to summarize as well, the issue here was…

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. So we have a PR up for that as well now, so, 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, Yeah, I think we'll try and get a release out tomorrow. 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 Taylor-Brown: I think… I think we'll be able to get a test release out by the end of tomorrow, so if, I assume if clients are able to pass the test before Wednesday, then. 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. Any, any more DevNet-related comments?

Barnabas Busa: That is it from me. 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. As you all know, it's the successor file format to error 1. It's… properly… Handles the transition epoch and post-merge history, so… In a sense, it will fully deprecate the error one format. As for major changes, it, like, post-merge, it will omit certain fields, like difficulty. There are also some structural changes, like… Entities in the file are grouped according to type instead of by block, which also necessitates a change in the index. As well as some encoding, differences, and… In the receipts, we also, omit the bloom field, which makes things more lightweight and simpler.

At this point, the… GEF has a, implementation nerged in. I believe Nimbus and other mines have, PRs, I… I… I'm hazy on the details of how far they are. And… I've… I'm sharing now in the chat A link to, basically, an overview doc where you can find a link to the spec, to the implementations. 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 Place. Where we would really like for clients to take a closer look, start implementing it, and give feedback. I'm happy to answer any questions.

In the chat or after.

Ansgar Dietrichs: Sounds good, thank you. Any synchronous questions? Anything important? Otherwise… we can move on. This is a really important effort, thank you. The next up on the agenda, we have, the topic of 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. 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, 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, 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,

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. So, I saw the proposal. I support them, and I think it's good to have a standardization in this part. And the… I think there is no issue for Besu to work And expose also this, standard API. There are a few comments I left on the PR. 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, 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. 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. 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… a certain, Thought form… Summary of what's in the transaction pool, and then there are some that just print out everything in the transaction pool. Maybe, a method that is, like, filter the transaction pool for this transaction hash, or… For all transactions from this address might be… More interesting than just giving me all of the content of the transaction pool, and then the content is, like.

4,000 transactions.

Ansgar Dietrichs: Felix?

Felix Lange: 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 This namespace is anyway more for debugging and testing. 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 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.

And so for that reason, I would say just exporting the full content or exporting all the hashes is… Kind of what we want. Because it gives you a full snapshot of what's the transaction pool like right now, and then you can… 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, 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. Awesome. Then I think we can move on. The next section, and last section is the Hegota headquarta… Headliner topic, before we go into the actual, client positions and, discussion, there was a update, specifically the, headliner proposal, EIP8105. Which, 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.

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. 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… 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: 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. 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, asked for clients to basically think about what their positions would be on the individual headliners. Some of the clients 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? Give some context.

andrew (erigon): Yeah, sure. So, can you hear me? 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 Well, very important, and it's crucial to prevent, front-running, but because, there is, This extensive roadmap, the straw map, that affects, slot times, and, how… how transactions are mapped into slots and things like that. It might be… 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. Yeah, basically that's it, but we would like to see both, of course, both the account abstraction and 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: Yeah, I… I can do that. So… The Besu team is in favor of having Lucid as the EL headliner. We think it's an ideal candidate to go together with Fossil. Specifically because without something like this, Fossil will only be useful for transactions that Cannot… that don't have any math to be extracted, or that are not very time-sensitive. So it might only benefit a small minority of users. 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 be picked up by… by… by an included. 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 (Matt Garnett): They… Yep, so… we posted our document. We feel that Frame Transactions is the best choice for the headliner for Hagota. We also think that it's a good… fit for… 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 Take advantage of… The improved, those improved inclusion guarantees. the… For the other headliners, 7807SSZ. It's a nice change, I think. We feel it's just too invasive for the benefit to users right now. 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.

So we would prefer to start there. And the Lucid encrypted mempool is also an interesting idea. We just don't think that it's matured enough yet. it… You know, encrypted mempools haven't really been deployed widely in blockchain systems yet. And the… The instances that have been deployed leak metadata, things like nonsense, gas limits, data sizes. And this is also an issue in Lucid. 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, considered as a headliner in Istanbul, potentially. 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, 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. So, we do like, the privacy that Lucid brings, we do like the… especially the road to… Different signatures with the frame transactions, but both bring, in our opinion, such big complexity that we are not… really, at the current moment, confident to just support them. So… 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. Mostly due to the complexity of both, of both, of both.

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, 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… 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. 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. From this list of AIPs, yeah, it's hard to choose anybody, anything to be a headliner. You can frame trisection. Feels, like, over-engineered for the… Solution that we basically could do as some simpler… Implementation. Encrypted pools, seems torely to add them. And S is the… yeah. There is not a lot of benefit, like, doing a lot amount of work. 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. 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, We've been having some internal discussions within the team, and… And we've been impressed how well it can handle everyone's call base, and probably similar for Nethermind. 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. It can help us with, 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,

Verification, and kind of nitpicking job and things like that. It's really… it's really a big productivity boost, which… 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. 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 Brody: Sure, yeah, so… I guess, perhaps unsurprisingly, we're in favor of moving towards SSZ, and, and in a couple of concrete ways. So, I think we… So… 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. 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. From the outset. More transac… you know, another transaction type, more formats to parse, to code, and there will be multiple representations of these now.

if… 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. Otherwise, as far as Frame transactions, we find, are… address a fair amount of… a wide range of problems relatively elegantly, as far as that goes, that are… Worth addressing, and in particular, a number of feature-proofing aspects. And finally, for encrypted mempools especially, I want to say, before the consolidation, before Lucid, sort of became the… the one, that was… I think we found it sort of un… unappealing, let's say, to have, and indicative of an immature EIP or a spec.

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, For this fork. Yeah. What's up?

Ansgar Dietrichs: Sounds good. So then, 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, 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. 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… 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: 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 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… 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… 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… comments, I see in chat people arguing that maybe it's a waste to not have a headliner, There's other comments. Anyone wants to bring up something?

Marius van der Wijden: Yeah, I would counter that by… just by saying… not choosing an EL headliner doesn't mean we cannot choose any ELPs. It just means… 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. And I don't… necessarily see any of the features that we… that are proposed. 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… 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. Emm… Maybe first off, How do people feel about the non-favorite, 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, 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?

Yeah, let's maybe start there, like, do clients have… Concrete takes on those two. 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 (Matt Garnett): I mean, Lucid leaks, gas limit, gas price… This is metadata.

Anders Elowsson: How does it leak?

Lightclient (Matt Garnett): 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, going to send from. So you just specify a gas estimate first.

Lightclient (Matt Garnett): 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 (Matt Garnett): I mean, we don't need to get caught up in these details, I think, that… It was said nicely earlier, where there were two different proposals for encrypted mempools, both proposed at the last moment. This is not ready for Hakota. I think it could be ready for I-Star, but it was not picked as the headliner for any client except Besu. I don't see this.

Anders Elowsson: Yeah, I mean, it's perfectly…

Lightclient (Matt Garnett): Proposed that's ready.

Anders Elowsson: Perfect. It's a perfectly valid position, I just wanted to specify that we do not leak metadata. And I don't agree with the, with, that… that we do.

Ansgar Dietrichs: feelings.

Felix Lange: 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. And… Discuss it there after the call.

Ansgar Dietrichs: Yeah, that specific issue, I agree. 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, 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: 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. what we want to support, because we had at least one… one person on the team who also was… didn't want any headliner. 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. So, like… 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 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. Yeah, I just… I think no headliner is the least without options.

Ansgar Dietrichs: Felix?

Felix Lange: 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… How it works with the breakouts? I mean… 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 some… problems with it, I think that could really help. 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…

Sweet. 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… 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… 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. Not sure how people feel about that.

Felix Lange: 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. but, 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. Happy to be overruled.

Lightclient (Matt Garnett): I mean, I feel like we should just talk about frame transactions, since that seems to be a major sticking point for people. 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… the frame transaction people to have a… Kind of a bit of a deep dive session right now. 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? Like…

Ansgar Dietrichs: But there is no rest of the agenda. The rest of the agenda was specifically that just, like, the headline Last point of the agenda.

Marius van der Wijden: Yeah, maybe we can just ask, are there any topics that Still need to be discussed before we dive deep into the last 45 minutes or something? Frame transactions?

Ansgar Dietrichs: Right, so is there anything non-headliner related? Because in terms of, like, other thoughts around headliners, I think… 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 the… when we… when we say that no headliner, I think we should, maybe… talk a little bit about what that means, because there are certain, sort of, slightly big ELPs that we could do that… 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, 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.

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. 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… resources.

Ansgar Dietrichs: Yep, that's a reasonable comment. So, indeed, like, no headliner doesn't just mean… just… 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. 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. 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.

The flow would be yours.

Lightclient (Matt Garnett): Yeah, I mean, I think it… Okay, go ahead, Felix.

Felix Lange: Just wanted to quickly say that I can, 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. that come up. So I would do it, like, more in a question-and-answer style way. Like, personally, if people have specific points, we can go through these points. Anyway, Matt, you also wanted to say something, so…

Lightclient (Matt Garnett): 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. 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… The specific questions or concerns that people have. About the proposal. So, the clients who chose not to have frames as the headliner, What would convince you otherwise?

Okay, people are shy to talk.

Felix Lange: I think that's a pretty strange one to start off with, like, I mean, we're not really here to, like, you know. 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. So, 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. Later, he follows it up with, comment saying… 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.

but then introduce toner complexity and dev code dueling layer, for example, in VM. And, account abstraction flows are super difficult to reason about, specifically with this. frames. 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, 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 Lange: Yeah, this might be a good thing to, like, get into first. So, for me personally, I can answer it, like. I think that… The immediate goal we have is to solve the transaction signature issue, let's call it that. And so the issue that we see is just that there is no way to originate an Ethereum transaction without creating an ECDSA signature right now. 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… 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…

That doesn't even get into all the advanced use cases that people have. 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. 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 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. 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… relatively simple solution to that, right? But it didn't give us all the account abstraction. 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… 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.

I mean, if you… Oh, this is what they have.

Felix Lange: Sorry, Dragon, I think you really want to say something, so I guess we can just… You can also take it away. Is it related with this point, or your point from earlier, or…

Dragan Rakita: Yeah, I think Lukashi is basically… saying what I want to say. If we have… You don't need to have… multiple transaction types for every signature. You can have one transaction that has signature type. And some generic field that depends on that signature type. So this is, like, a lot simpler solution than introducing the frame that's going to ask EVM what's going on. And that kind of abstraction seems, like, overginated.

Lightclient (Matt Garnett): Yeah, I can respond quickly to these comments. I think the tempo-style transaction types are kind of nice, because they are fairly simplistic in that sense. But I don't think that it… really solves the, like, long tail of things that we want to solve with frame transactions. 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… 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. You either need to have some EOA that exists with some Ether that you can submit your withdrawal transaction from.

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. 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. So these are things that just aren't possible with the tempo-style transactions. 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

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 Lange: 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: I want to talk about post-quantum signature sizes, so we can finish this discussion, and then that's that point.

Felix Lange: 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. 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 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 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.

That is just ultimately gonna lead to more pain and fractures of protocol, where we… 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… 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. Too many extensions that are gonna be required in the future for this type. Specifically because a lot can be done with, frames and… It just solves a lot of problems that other transaction types tried to solve before in a more specialized way. 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

To combine this with 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. 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. 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… we should try to compose transaction types, right? So, for example, if we were redesigning, we could have 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.

And that kind of is… And this is.

Felix Lange: 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 Because the… if you look at the basic envelope of the frame transaction, it is… Basically, a fresh start. And, we can… 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. 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.

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. 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. 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…

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. 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. 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: 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. I wonder if there's not a security concern, like, more attack vectors in terms of… Because now we are basically building a framework for how users do signatures, or transaction signing. We are… 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. trusted by core devs that you should pick this signature or that one. It's kind of…

all open, and anyone can create their own thing. Yeah, I'm just raising this as a point. I'm not either convinced this is a problem, or… or concern, but just, I think it's worth raising it.

Felix Lange: 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 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… Like, there… there are… 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…

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 Don't have any of the advanced features, but literally just do the signature verification and that's it. 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. 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…

It is something where… I feel very strongly that precompiles are there forever. 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. and just reports whether the verification was successful, then that is very safe and We expect that most users will use a scheme like this. 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.

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. Whereas in the new scheme, you can. And so we see that as a… actually, it's a… It's a plus for the security. Yeah, I hope that was helpful, If not, we can discuss it further. Luis, do you wanna… do you have a follow-up question, or is it… does it help you in your understanding, or… No, no, that's… those are reasonable arguments, yes.

Luis Pinto: 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. That's a good point.

Felix Lange: Okay. Very cool, so I think we resolved… We still have Dano, and we have the DevTooling thing. I think, Dano, yours is gonna be… Very specific, so let's just go with that one now. You've had your hand up for a long time also.

Danno Ferrin: 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. 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. Which means we're gonna have to take the signature out of the transaction. 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.

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. 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, ZK proof for whatever aggregation you have, for those signatures, and you don't have to share that. So, blobs are not big enough for the signatures. These signatures, we're gonna hit giga gas just by data carriage alone. That's how big these are.

Felix Lange: 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, 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. It was simpler to prototype. There is no, we are not fundamentally attached to the ROP encoding of these transactions the way they are now.

So, that is still something we can fully debate. That said, with the rewrites of the transaction, we have put, some effort into… 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. 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. 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.

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: 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 Lange: 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… Data at the end, or whatever, but it… Doesn't really make too much of a difference, like. for us right now. Anyway, this point, we will… 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,

a proposal from Vitalik for the future to, introduce an operation in the EVM that basically gives you… So, that would operate like a block-wide signature stack, so basically then what it would do is you'd The block builder would come up with something that's a bit similar to, let's say, a block access list. 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. 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.

That said, we did… we chose not to include this in this specific proposal, because we wanted it to be more about the generic, Structure, and we'll see how this all… Comes together, but definitely it is an important consideration.

Lightclient (Matt Garnett): 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. You know, for the most part, like, the transaction as it's sent over the wire is how it looks at the block. 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… Do some kind of signature aggregation there. 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: 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 (Matt Garnett): Okay, I see, yeah, so you would remove it from the frame.

Danno Ferrin: Otherwise, what's the point of aggregation if we're.

Lightclient (Matt Garnett): No, no, sorry, you'.

Danno Ferrin: you know, gigabyte blocks.

Lightclient (Matt Garnett): Yeah, okay, sorry. You're right about this? We do… we would need to rewrite it in that case. But this is how we are already representing it, as the, This is the serialization scheme that we already represented in. So I think that it's not a major issue. And it's done by the block builder already. 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. I think these are okay. the broader points I wanted to make about Why do this now, even if the signatures are large? Is… it's going to take a very long time for people to migrate to post-quantum crypto.

And… 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. The better place we're gonna be in in 3 years, 5 years, you know, at whatever time period that we… 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. 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 Lange: 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. 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. 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. 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.

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. I'm less sure where they are coming from.

Dragan Rakita: Well, I'm still not convinced that we should do framed intersection. I know that we started this, like, discussion as, do you have questions about framed resection, but… I could, like, switch up that to basically ask why do we even want framed section. Because I'm not convinced that this is, like, solution that you want to include in Ethereum. So, maybe I'm just… I'm talking just in my, like, in my view, so… There are a lot of clients, a lot of developers. So, yeah.

Felix Lange: 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, Version of this, to me, and… 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. it… 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.

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… Yeah, but… Why is this so weird?

Dragan Rakita: I think that's the main problem that I have with this. Is the main point for the frame intersection to, like, introduce new signature types? we have a simple solution that we should use. There's not a lot of signatures out there, and there is not a.

Lightclient (Matt Garnett): It's not just to do one thing, though, like, we kind of said this… You know, it has a primary purpose, but there is a long tail of 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 (Matt Garnett): Yeah, so I mentioned one concrete one in the chat, but there's an issue with privacy protocols. So… privacy protocols. 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. 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. So, frame transactions allow you to have multiple frames, and you can have more complicated 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

Pay for the gas and approve the overall transaction, only if certain assertions were met. 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, It doesn't need… you don't need a general framework for those.

Lightclient (Matt Garnett): I mean, that's just what we disagree on.

Dragan Rakita: That's true.

Lightclient (Matt Garnett): I mean, I think this is what Ethereum was built on, is providing generalized frameworks for people to innovate. And I don't agree that we should come up with a prefix menu of solutions for users.

Felix Lange: There's also an argument from Vitalik, that I found personally very, very good. So, 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. 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 Yeah, like a special case in the protocol just for this one thing, and we wouldn't really be able to…

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… 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… 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. 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 Lange: 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 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. The fundamental thing that people will do is just… The… or the fundamental thing that is…

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. and possibly your fee-paying logic into the transaction. So all of these, like, the way this… 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… It is fundamentally just a different way to put your transaction in… to put your signature in. You can have more advanced use cases with the frames, but these use cases are for special…

occasions. For example, you can do the native bundling with this. If bundling is a necessity for some use cases, you can 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. It gives you some advantages to do it like that. 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. 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…

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. complete 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 Delegates the gas payment, and then they're gonna have the main execute frame that just… 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.

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 For example, the Bezu team saying that they don't feel comfortable with committing today, but before having discussed more with the team. 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 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?

extensions, it feels sensible to still schedule a breakout call, to just basically talk about You know, the future of transactions, and isFrameTransactions what we want to do, and want to do now? If that's… does that… does that seem sensible for the Prime Transaction Champions?

Lightclient (Matt Garnett): 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… push this through now if there's no specific reason for it, so then I would say. 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…

Yeah, I mean, I don't know. Sure, unless… Yep.

Lightclient (Matt Garnett): 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. Just not sure we'll have… Client consensus on this?

Lightclient (Matt Garnett): I mean, only one client proposed Lucid as their headliner. That seems… 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 (Matt Garnett): But still 2 clients versus 3 clients.

Ansgar Dietrichs: Right, this is just why, you know, it doesn't seem like consensus.

Lightclient (Matt Garnett): I think we should whittle away at our options. I feel extremely strongly about not doing Lucid. I think a lot of the guest team feels very strongly about this. I think other client teams also feel somewhat strongly about not doing Lucid. 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… from the Besu and Erigon team's side, I… they… 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: 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 (Matt Garnett): 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 Unless people… 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 (Matt Garnett): 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. Or to specifically, like, block Lucid.

Nixo: Matt, you also have a conflict of interest here, I think that… It's… It's good to… to keep considering it.

Felix Lange: 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. We will not formally reject headliners today. But the understanding is clear that in two weeks, we will make a decision. 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. 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 (Matt Garnett): See ya.

Transcript adapted from ethereum/pm, CC BY-SA 3.0.