All Core Devs - Execution #232

Transcript

Justin Florentine: Let's go, Ethernets, let's go!

Ansgar Dietrichs: Hello, hello, everyone.

Vitalik Buterin: Oh.

dionysuz.eth: Hello?

Ansgar Dietrichs: My understanding is, David, that today you are in charge of the streaming process, is that right?

dionysuz.eth: Yes, that's right.

Ansgar Dietrichs: Perfect. Let's give it a little bit, just to… Have a few more people trickle in, and then… I'll let you know in a second.

dionysuz.eth: Okay, sounds good.

Ansgar Dietrichs: This is an interesting camera on angle, Vitalik, what are we looking at here?

Vitalik Buterin: That is the ceiling. Interesting. Well, I was, there we go.

Ansgar Dietrichs: Yes, yes, yes, you're okay. I was just curious.

Vitalik Buterin: Well, you know, people always ask me what's up.

Ansgar Dietrichs: App only. Okay. David, I think if, we'd be ready.

dionysuz.eth: Okay, cool, we're live.

Ansgar Dietrichs: Awesome. Welcome everyone to All Core Devs Call 232. Today, we have a few topics, around the ongoing preparation for Glamsterdam, and then looking forward to Hegota and the headline selection there. Let's start with, Glamsterdam. DevNet updates, I think, Stefan, you could give us some updates on BAL DevNet 2 and 3?

Stefan Starflinger: Yes, can you hear me? So…

Ansgar Dietrichs: Yes.

Stefan Starflinger: for BAL DevNet 2, it's been going pretty well. I think only Erigon is left to, get ready and start proposing some blocks, but they've been doing some work on fixing some syncing issues, and they should be ready soon, proposing blocks on DevNet 2. We've also got further with the efforts to get some benchmarking ready on DevNet 2, and any benchmarking effort has been done against BAL DevNet 2 so far. We've started dedicated nodes so that we can compare three different approaches. There is the all optimizations of BAL, then there is sequential, which is no optimizations of BAL, but still with any optimizations that the clients have, inherently. And then there is no, prefetch, so with BAR, there's the concept of prefetching.

the state through the block-level access list before executing in parallel, and we wanted to see in the block-level access list if reading all the state in the beginning, is actually a speedup or not. And there we see a little bit of mixed results, but it's just the average case, so we haven't been testing the worst case yet. So, so far we see that without prefetch, it's currently faster than with it. That's for, DevNet 2, unless there is anything else for DevNet 2. If not, I would, move on. To, DevNet 3. So I've been testing a lot, on kurtosis, and it, seems… that most clients are not ready yet for, especially, 8.37. There are still some, issues that clients are resolving, and a recent test release was made by Spencer5.4.

And it would be good if all clients could test and see that they are passing as many tests as possible. Yeah, and I think that's pretty much, the status for DevNet 3. We haven't started it yet. And there's a point from Marius, so I would pass on. Fuck.

Ansgar Dietrichs: Sounds good, Marius.

Stefan Starflinger: Or no, it wasn't Marius, it was, Iber, no, someone, someone else has.

Ansgar Dietrichs: Yes.

Stefan Starflinger: Sorry.

Ansgar Dietrichs: Right, right. Exactly. No, no worries. I saw this. So, basically, I think there is some concerns around, EIP8037. I'd heard this already, that clients in general were saying that it's a bit more complex than initially. a thought, for context, of course, you know, we do need a… an approach to state growth, if we do not end up addressing state growth at all in Amsterdam, we can't make use of all of the scaling benefits in the fork, so in some ways, it's kind of without alternative, but of course, the specific version of it is with alternative, and so… their concerns whether the current shape of 8037 really is the thing we should or can do. Andrew, do you want to give a bit of an overview of your concerns, your team's concerns?

Andrew Ashikhmin: Yes, sure. So, as I wrote, now we have, like. for 4 flavors of gas, so 4844 introduces blob gas, then 7928, introduces this, like, state gas accounting versus non-state gas accounting. 7778 introduces blob… block accounting versus user refund accounting. And the 8037 introduces state versus regular gas, and each of the… all of those changes in isolation, they make sense, but if you look at all of them together, like, they end up in a horrible mess, because they are not aligned with each other. So, if, like, if we are, keeping 8037 or something similar in Glamsterdam, then I think we should take a step back and… And make…

make the gas changes coherent on the protocol level. So, say, how I see it, if you look at… if you look at, at Bells, 3928, they say, okay, you have a gas validation before state access, and, like, pre-states, like, pre-state validation and post-state validation, right? And then, 8037 talks about state versus regular gas. I think that we should just bite the bullet and do it coherently and say, okay, now gas is three-dimensional, the dimensions are blob gas, state gas, and computational gas. When, like, 7928 and, 8037 talk about state gas, they should talk about exactly the same state gas, right? So we should refactor both… both 7928 and 8037, like, to use exactly the same thing, the state gas.

And, then we should also, like, we should either drop, 77, 78, Or make it, like, maybe we should drop refunds entirely, rethink 7778, or just double-check that if we introduce this more or less coherent three-dimensional gas, that 7778, is still… is still fine. Because if we don't do that, if we just add all the… all those kind of independent hacks all together, then we end up In a… in a horrible mess, like… like we are now, with a gazillion of corner cases, things are incoherent, illogical, all kind of… you need to… To think about… just very hard or impossible to think logically about what gas is now. In Ethereum. So, if we don't do this coherent.

Approach, then we'll end up with a lot of technical data.

Ansgar Dietrichs: Yeah, we have a few, people with hands up. Mario?

Maria Silva: So I… I just, I just wanted to speak a little bit to the more principled approach. So I… the way I see it is… I think we've been using GAS for two different uses so far, in DVM. So, on one hand, we use Gaz for transaction pricing, so to decide how much a user should pay for things. But we are also using it to control resource abuses through the… through the block limit. So we want to make sure that execution doesn't take more than a certain amount of seconds, and that state doesn't grow at more than a certain rate. And because we are using the same thing for these two things, we end up in a non-optimized approach. So, I think one…

principal… way that we should look at it is these are two different things, and so when we talk about transaction gas use, this is an inherently different thing from the block limit and block metering, so we should probably even have, like, these two different concepts. We have transaction gas use, and we have block metering, block gas metering. So this is… and I think some of the confusion around 1837, is that now we are actually needing to make these specific On what do we mean by the gas used in a block, and what we mean by the gas used in the transaction. So this is, like, the axis number one. Like, these two things need to be separate. The… the other axis is on the resources side, and I think the long-term

principal approach is as, as was said, which is, like, we need to separate the resources if we want to have a better control over them. And I think the… the end goal for that would be something like 7999, where we are actually… have, like, a separate fee market for For… for each resource. And I think 8037 is compatible With 7999, and it's already implementing a lot of the things that we would need to then have 7999. And so… the way I see it, I think it's, like, 8037 is a step in the direction of the ends principled approach. So that's, that's, that's how I see it, and it's also a needed thing we need now if we want to continue to scale without having, state grow at the, at the, unmanageable rate.

Ansgar Dietrichs: Felix?

Felix Lange: Yeah, thank you. I just wanted to quickly give the feedback from the implementer point of view. I was recently also debugging something related with this EAP, and the primary issue that we see right now is things like, for example, how is the reverse being handled? Like, how is the gas correctly Attributed back to parent frames in these scenarios, and it took us a long time to figure out the correct semantics. And I'm pretty sure that there's more cases like this, so it really has… it seems the bug potential of this EAP is very high. Doesn't mean the idea of it is bad, it's just, I think, what Andrew is also kind of trying to say here is that

It just intuitively feels like something that is super easy to get wrong. And… Yeah, I just really wanted to voice it that, like, from an implementer perspective, it's… it is… it's kind of complicated.

Ansgar Dietrichs: Andrew.

Andrew Ashikhmin: Yeah, so… so I think it's… yeah, right, right now we are reaching this level of complexity that we need the principal approach now, so I'm very uncomfortable with, implementing and shipping, 8037 without a principal approach, so… It either has to be refactored with a principled approach, and that principled approach should be also applied to 3928, 7778, and also blob gas should be consistent with the principled approach. Or we should not ship it at all. Otherwise, yeah, if we just, yeah, ship it without a principled approach, it will be very bug-prone, or error-prone.

Ansgar Dietrichs: And Dragon?

Dragan Rakita: I think the state gas is very much needed if you want any bigger blocks. It is complex change because it touches the gas, and everything that touches gas is very sensitive. There's a lot of edge cases there. I do think that there was a moving target regarding this AIP. There was a lot of cases that would not cover the example of how to return or revert to the halt. The reservoir was something that we, like, talked to weeks ago. And… The tests are currently… Needs to be polished a little bit, because they are just made now. So, I think… it's a little bit chaotic, because it's not… we are just coming to the place where the AIP is polished.

So, in my opinion, we should… Add it, we should bind the bullet and just implement it. It will get better.

Ansgar Dietrichs: Yeah, I mean, from my side, I wrote some of this in chat, I think a full rework of, Gas. and basically trying to move towards a principled, integrated approach to gas in all ways, I think is, to me at least, infeasible for Glamsterdam, just because I think this is something that already in the background people have been thinking about. It's just a really, kind of. Complex thing to get right. Mmm… that leaves us, I think, with the question of specifically on, this kind of state creation side, do we… can we either A make some adjustments to 8037 that make it easier to implement, or maybe just Bigger changes, in principle, that, that, that really kind of reduce complexity on this topic in particular.

I… have… personally have a hard time seeing us making that… final decision today, just because I think it was a kind of very short-term, short notice raised concern, and it's a consequential decision. So I'd rather than, say, schedule a breakout call for something like next week to really dive in on that call than make decisions. Hmm… I do wonder if we were to say today that we need changes, where that would leave us with regards to BAL DevNet 3, whether we would say we would still go ahead with 8037 as is, just to get it out the door, and then maybe have some more… insights on how it behaves, or whether to then hold off the DevNet, until we've decided what to do about it.

I don't know if people have thoughts on this question. Also, Maria?

Maria Silva: was just… I was just going to… to add that we do have a repricing, breakout, next Wednesday, so I think that could be a good opportunity. Andrew, if you could, to dive deep into, in your opinion, what changes could be made to make it, work better with the other EIPs. I think, like, doing the full, principled approach might not be possible, because that would mean, like. adding all the resources we want, thinking about what about the ZKVM, so I don't think we'll do, like, the full, full thing, but… trying to make it less prone to edge cases and errors. I think it's… it's, it's, it's, it's a good aim, and so I'm… I'll be happy to have…

In-depth discussion on this.

Ansgar Dietrichs: Ben?

Ben Adams: There's a question… a lot of the… Some of the complication comes from, like, tracking refunds and things, and… We could go back to the… question, do we just drop refunds? Is it… is the benefit that they bring More… more valuable than the complexity they're causing.

Dragan Rakita: So…

Marius van der Wijden: I think the problem that, why refunds are a bit complicated with this is because we are, the current rule is that we are tracking… that we are refunding the state gas to this… to, to the state gas reservoir. If we would just refund the gas as… or if we had the same logic for the state gas as for normal gas. Then, it would be significantly easier to implement. The… The logic behind… Refunding to the state gas reservoir is that, hey, you didn't use up the state gas, because you are not changing anything. So, you are… you are being refunded that gas. But if we just say, hey, the state gas is handled, the same way that the regular gas is handled, then we can pretty significantly simplify things. But I…

I also don't think it is that complicated. like, the first implementation I had of it was pretty complicated, but, I've been refactoring it, and The only thing that is… That was pretty ugly about it was the thing that we just changed. With, with the recent BAL release. Otherwise, it is pretty straightforward, to be honest. When you are in this… when you are, like, yeah, when you are thinking about this, it's not that complex, to be honest.

Ben Adams: Yeah, I mean… refunds altogether, so we have the… The one that tracks how much, Has been used in the block versus how much You know, there's the separation of, Here's the refunded gas in the transaction, but here's how much resource the block has actually used. less the refund. So… if we… so there was, like, EIP… 3298, where it was, like, get rid of 3 funds altogether. So the question is, the refund incentive, is it that strong that people are deleting space? Or, or… Is it enough?

Dragan Rakita: m-maybee… I have some clarification here. In REV implementation, we don't touch a refund at all. The refilling of the state gas of reservoir with the state gas that's not used is, like, a different variable. So, dropping refunds doesn't, like… touch the refunds. In general, the constants around that is not touching the state gas, or… Or, reservoir at all. So it's like, Totally separate. In that part, it's like, it became very simple. propagand reservoir and coming back from the subcoals, it's simple logic. The problem that I had mostly is about merging that inside, Before execution and after execution per section. So I don't think the dropping… Refunds is going to solve anything around that.

Ansgar Dietrichs: Right. I do think, yeah. Again, it seems unlikely to me that we will be able to make a decision today, but… It seems like an important topic, because if, indeed, the feeling is that also, say, for example, from the testing side, I mean, maybe, do we have someone from the testing side who could briefly, like, maybe Mario or someone who could briefly speak up on what the latest feeling is around testing complexity of AD37 in particular?

Mario Vega: I think Spencer has more context, but I can give the overview. Well, at least my feeling, is that it does break a lot of tests. I think it's very complex in the testing side, but only because I mean, primarily because the static tests are not ready for this kind of changes, but we are in the process of converting this. The problem is that this is 10 years of… of tests, so it's not easy. And we've been meaning to do this for a long time, and I think 8037 is, like, pushing us to just get it done. Spencer, do you have other… Comments?

Spencer Taylor-Brown: Yeah, it is tricky, and I mean, where the tests are right now, like… At least in the most… yeah, in the most recent release, we don't have all the… All the tests from the previous, previous works. In the most recent release? For about DevNet Free, we specifically chose to simplify some of the or simplify… simplify a part of EIP8037 by essentially hard-coding the cost per state byte. So it's already loosely simplified for this devnet, and My feeling… maybe other clients can speak up here, but my feeling is that we should just go ahead with, DevNet Free as is. and then kind of gauge from there if there's a lot more edge cases that pop up.

And yeah, for DevNet4, we will have a lot better coverage, and even more, I guess, specific edge cases for… 88037.

Mario Vega: One thing is that, we have not, successfully filled all the tasks, so that's something that we have to take into account. I wouldn't feel confident, or, about signing off this EIP into… into the fork if we are not passing all the tests. But we can process progress about this. I do feel that we have to make sure that none of the tests break, or worse than breaking is that they pass without verifying what they correctly did verify before. So, yeah, I think it's gonna take a lot of work. from us, but if we… if this is a change that we need, I mean, it's just… it's something that we have to do.

Ansgar Dietrichs: Yeah, sounds good, thank you, that adds good context, I think. Yeah, I agree, I think, with the general take that it would be very desirable if we could go ahead with DevNet 3, BAL DevNet 3, as is, including AD37 in its current form, if that's at all feasible for clients, just because even if we then still want to consider making changes, I think it would be really good to just also see, in practice, how does it work, you know, in the end. And then I would still also like the idea of, say, next week's repricing breakout, we specifically focus on the question of kind of 8037 and complexity there, and is there anything we can do? What would be potential alternatives in terms of trying to find ways to simplify? Is this already the best we can do here?

Yeah, so to really have people join next week, if… on that topic. Does that, for now, seem like a reasonable approach? And then we basically see, after next week, basically, whether we just stick with it, even, and just accept the complexity, or whether there are things we can do? It feels like that's the best way forward. Do we have, yeah. How do people feel about that? I guess Erigon, for example, would you all be, able to, basically support BileDevNet 3, in its current form.

Andrew Ashikhmin: Yeah, we are working on it, so yeah, we'll try to make it work. It sounds… Yeah, like a reasonable interim approach, but I think we should, at least a line 79, 28, and 8037 in Glamsterdam.

Ansgar Dietrichs: Yeah, makes sense, and I think that's… The type of.

Marius van der Wijden: Yeah.

Ansgar Dietrichs: Next week, Maris?

Marius van der Wijden: I totally agree with that. I also think those are… those are two AIPs that both change the way, receipts work, and, I think they are, yeah, they are specified very differently, and so we should, we should definitely, yeah, make them.

Ansgar Dietrichs: Sounds good. Mmm… then I think for now. That's probably a good place to leave it at and move on. Is there any, like, any last comments, anything anyone would definitely still want to bring up on this topic for today? Otherwise, before we get into Hegota headliner discussion, which is the main topic for today, I just very briefly wanted to ask Barnabas if there's any update regarding EPBS DevNet Zero. That's obviously mostly a CLSAT topic, but I think it's good to just… Make sure we have visibility on from the EL side as well.

Barnabas Busa: Yeah, sure. So, we have a stable-ish .NET, .NET Zero launched last week, Wednesday, and we've been going on for a whole week. We have a few clients that are working. We have Lighthouse, Lone Star, and Prism working fine. Taku and Nimbus are working hard to, get up to head. We have Checkpoint Z working now as well. We have… withdrawals working and deposits working. We currently do not have exits working, but it's something that clients are looking into getting fixed. As well as exiting, 0.03, builders, that is not yet working. We are expecting to have a new consensus pack released by the end of this week, and we are going to either launch the 1 next week, Wednesday, or a week after that.

That will be based on top of the latest, sales factual release.

Ansgar Dietrichs: Sounds good. Any EL-side topics, questions anyone has around this DevNet?

Barnabas Busa: We currently only have, GAF as the EL. Ideally, we could have at least one more EL, just in case there's something, wrong with Geth. I'm not saying that there will be, but, Ideally, we would have at least two.

Ansgar Dietrichs: Do we have any other EL clients actively working towards… like… short-term… sorry, EP-based DevNet Zero readiness, and if so, how close are we there?

Barnabas Busa: I'm not aware of anyone working on it. I think all the teams are very busy. So, it's, like, not urgent, but if anyone has a bit of downtime, then, Let me know, and I can point you to the… Yeah, it's fairly easy to do. I was going to use it.

Ansgar Dietrichs: Sounds good. So, open invite if anyone is bored from all the state questions and thinks this is trivial and wants a challenge. Sounds like a very small challenge, but, from the outside, but yeah, do reach out to Barnabas, maybe see if you… if you can join the DevNet, that sounds fun. Okay. Perfect, thank you, Barnabas. Then, next up, we do have the Hagota headliner selection. Just as a quick reminder, we kind of, Already had a discussion, last call. The plan is to make a decision today. We basically have the different options that we had, where The frontrunner, candidates, so to say, were either to do the frame transaction headliner proposal, or possibly some clients would have the preference of maybe

just not having an Yale-specific headliner, just, focus on FOCIL as the kind of cross-layer headliner for that fork, and then have smaller features, or just lower priority features, otherwise. On the EL side, but there were also still the, candidates of, Lucid, the encrypted mempool proposal, and, the SSE, pure ETH, proposal. Yeah, I would maybe want to start, because it seemed to me, like, last time we were basically saying that both of those, MSSE and also Lucid only had outside chances, and… I just wanted to check in on this first. My understanding was, for example, from the encrypted mempool side, that many people in general are very open to this, but, were feeling that this is one hard fog too early, and

that we should probably just revisit this for I-Star, and I think I heard from some of the champions as well that they are, kind of starting to at least be very open to this, lean in that direction. I don't know, Andas, are you on the call, for example? I think I heard you mention something in that regard.

Anders Elowsson: Yeah, I can just say that, yeah, I mean, if there's no general support for it, we are, of course, open for… sort of, recognizing that we can sort of try… try for iStore if there's, if people think that we should not do it for Hegota, so it's… Yeah, I would say, generally, we would still like to put it up there for discussion, but yeah, we are definitely open for thinking that maybe it's suitable for iStore.

Ansgar Dietrichs: Sounds good. Yeah, and of course, my feeling is that clients haven't really changed their take on this over the last two weeks, but… Of course, if that… if that is… different, then we can discuss it now. I was just thinking we should maybe, at the beginning of this discussion section, just make the decisions around SSE or Lucid as headliners, most likely just reject them as headliner candidates, so we have a simplified design space, and then we can just talk about frame transactions versus no headliner. Yeah, do we have anyone here with opinions on either of those two headliners, SSE or, Lucid, would, yeah, maybe potentially want to argue against rejecting them now, or, of course, just confirm this decision. Ben?

Ben Adams: Just on SS… SSE, there's been, like, a recent movement to do a forum or some SSE, sort of, that's not… Walk-related. So I think that might change the topology on that as well. There doesn't need to be. Coordinated, necessarily, through consensus.

Ansgar Dietrichs: Yeah, Daniel?

Daniel Lehrner: Yeah, so, from Besto's side, we had Lucid as the favorite the last time. But, now the team changed, actually, to no headliners figured, so… From our side, it also would not be Lucid.

Ansgar Dietrichs: Makes sense. And yeah, just to confirm, I think people are overall quite positive about both of those, SSE and Lucid for the future of Ethereum. It's just, yeah, maybe… not the right form as an Hegota headliner. That's at least the feeling that I got from conversations. So then, yeah, like, I would just… I mean, let's not do this as a batch decision, people do usually dislike this, so just let's do them one by one. I would propose to just… reject SSE as headline-up proposal for Hegota? And again, that does not mean that we are not considering doing this either out of protocol, in protocol, otherwise, but just not as… not selecting it as a headliner, basically.

Anyone who wants to speak up against that decision? Okay, so then we will not do, the SSE as a headliner in Hegota. And then same proposal for, Lucid, basically saying, to officially reject it as a headliner candidate. Anyone who wants to speak up against that decision? Okay, so then we also, yeah, brilliant. reject Lucid as headliner for Hegota. And then that indeed leaves us with the decision. We can either accept frame transactions, or we can say we just do not have a separate headliner. I know that there has been quite a bit of discussion. Unfortunately, I was not able to join the breakout call last week.

Yes, do we… do we have anyone who could briefly summarize the discussion from the breakout? And otherwise, yeah, any clients with updated positions on… on this topic? Felix?

Felix Lange: Yeah, I can definitely summarize. I have also four people to… if you are interested, I have posted a longer comment to the ACDPM issue that summarizes, basically. everything that we have done on the EAP in the last couple weeks, just so… I mean, ever since it was proposed initially, we have made some updates to it, and we've done a lot of research to, like, see, you know, like, we've heard some criticism from various actors. I've just been researching how this can be addressed, or, like, what is, like, the wanted feature set from this EAP, from the wider community. So, this is definitely an ongoing process, but some interesting changes have already happened. And, with regard to the breakout call, I'm very,

happy to say that this was also integrated into the forecast website, so I have actually also put the link to it in my comment. And, on the breakout call, mostly it was just yeah, addressing people's questions. So there were just a lot of questions of what is the purpose of this EIP, why do account abstraction, what is the connection of account abstraction with post-quantum? We went a little bit, again, into these discussions of how can post-quantum signatures be achieved within the block. It has some… there are some technical nuances that still have to be solved around this area. And then, yeah, like I said, I mean, after the breakout call, it became clear that really what's necessary for us as the next step is just to engage way more with the wallet developer community, to… to just hear

what they really want out of this. Like, when native account abstraction comes to the mainnet, what do they want to see? And, I can just give a very high-level comment here that In addition to… this being… a change that would obviously affect the mainnet. What everyone is also seeing this as is, like, a chance to generally resolve some user experience issues across the wider network of Ethereum-compatible chains. So it is becoming kind of important that once native account abstraction makes it in the mainnet, that it kind of makes it in the same way on the L2s, because this will enable people to use their account on all of these chains in the same way. And, yeah, facing this wider landscape of having this

making this, like, work in the multi-chain context, we… yeah, like I said, we started making some changes and started considering all these upgrade paths and, like, stuff that people already have done in the past. For example. we now have… are considering an upgrade path for the existing smart accounts, which are using EIC437, and which people are already using on some of these chains, things like that. Anyway, I highly recommend to read my comment to see all the updates, and, yeah, that's it.

Ansgar Dietrichs: Sounds good, thank you. Before we go into the open discussion, and I think, you know, I see Italik is also on the call, who's, I think, one of them. well, co-creators of the EIP, but I just briefly wanted to make sure that we have the latest, picture of where clients' positions are right now. So, for example, I think on the last call, there was a comment from Bisu that in… in the absence of Lucid, they would actually prefer doing frame transactions over nothing, but now it sounded like maybe Besu is actually… would rather be in favor of, No headliner? Is this… is this correct? Just to double check?

Daniel Lehrner: Yeah, yeah, yeah, that's correct.

Ansgar Dietrichs: Sounds… yeah, okay, makes sense. And then, I think otherwise, I had, Nethermind and Wrath on the side… written down as on the side of… preferring no headliner over frame transactions, and Erigon and Geth on the side of… the other way around, preferring frame transactions over nothing? Is this still accurate? Ben?

Ben Adams: Yeah, so, no headliner, but we wouldn't want to say… for end trans… no, to… for end transactions, we just don't want to put it on the headliner priority, where… We can't ship the fork if it's not ready. But we'd like it to come in as one of the regular EIPs. So we did… what we did in the previous work was we said. Or if it came in as the headliner and was rejected, it's obviously a big thing. So it shouldn't come in as a regular EIP. We don't think that's the case with frame transactions, and, so we'd like that to… Lucas can probably…

Łukasz Rozmej: Yeah, so if I can say something, we would potentially think about working on it, and prototyping it, and working on the spec, but we… We are not sure about it yet, so we don't want it as a headliner in that way, so potentially it's… we're not sure if we should commit to it, right? In this way.

Ansgar Dietrichs: Makes sense, Dragon?

Dragan Rakita: From red side, yeah, we have for the no headliners for Hegota. For… we don't support frame as such as it is to introduce additional abstraction layer that we don't need, and something like tempo intersection as the blueprint for the new intersection could be a lot better. It could give us a lot more benefits from… and smaller risk from anything. Frame.tx, in general, introduced a very big lift for TX pool and how DDoS protection is done and handled. It doesn't, explain how the things are going to be done, but it reduces additional abstraction that allows those things. So, directly permitting those end things that we need in some, like, specific or straightforward way, I think it's going to be a lot more beneficial.

Ansgar Dietrichs: Makes sense. And I think there's a comment by Matt, on the Manpool side question, specifically. But, but yeah. Okay, sounds, sounds good. So then I think we have a picture. So right now we have, 3 clients more leaning towards no headliner, and 2 clients leaning to… or, supporting frame transactions, which would… you know, given that I think that doing nothing is always the default, right now, tilt the decision more towards not doing frame transactions as a headliner, and then we could revisit it as an ERP still for the fork. But I do think client opinions on these topics overall are still uncertain enough from what I felt, that it seems reasonable to have a discussion here and see if actually people

Still, in a position to change their mind on this. So yeah, I think, we… this is the main, kind of, agenda point for today, so I think we have, basically the rest of the call, if we need it, if we want it, for this discussion. With that, do we have… people, again.

Mark Holt: Can I just give you a little bit of extra feedback from an Erigon perspective?

Ansgar Dietrichs: Yes.

Mark Holt: Because I think we're… we're sort of… we were… we're more certain about, Lucid now than we were, I think, the last time we discussed this, basically because the proposal's firmer, so… I think what… what we want to do, probably from a development perspective, is work on… lucid and… frames. As a… as a kind of thing that we will coordinate together to get into the codebase. Now, I think that's probably because we're in a position where, because we worked on account abstraction before, we've already got, effectively, frame support in the codebase. And one of the things that… I think we want to get resolved is Lucid has this composite proposal. In it, as well, as frames.

And… We don't think it makes sense to have, like, two composite transaction types. Effectively. So it seems like there needs to be some coordination there. But we basically want to work on both… we think it makes sense to work on both of those things in the, kind of, Hegatar timeframe.

Ansgar Dietrichs: Makes sense. And it… at least it, yeah, it does seem like… I don't… yeah, if we wanted to do Lucid… I personally think it's unlikely we'll end up doing it as a non-headliner still for aged already, but, yeah, definitely one should think they're.

Mark Holt: Yeah, yeah, so I think we're kind of, sort of, less… we're more neutral on the headliner thing, right? Because… It seems like it makes sense from a development point of view, but it seems quite risky, and it's one of those things that if we try to do too much, we might end up not delivering anything. Essentially. So… While it makes sense to co-develop it, it doesn't necessarily make sense to us to co-deliver it. If that makes sense.

Ansgar Dietrichs: Yeah, that makes sense. And then that would still, at least in principle, be an argument that could still favor having, frame transactions as a headline and H star, and then already, like, in the development process for it, make sure that it is forward compatible with Lucid or a Lucid variant that we would then bring in ice down.

Mark Holt: Yeah, because what we don't want to do, yeah, is do frame transactions, and then revisit them for the exact next fork, because we're putting Lucid in.

Ansgar Dietrichs: Yeah, that makes sense. But yeah, again, I agree, I think what you're saying, basically, it's not about shipping them together, it's not about shipping Lucid in H.S. still, it's just saying, like, if we were to select frame transactions to go first, we should make sure that it's already co-developed so that we can make sure that it's seamlessly forward compatible with the later Lucid change.

Mark Holt: Yeah, yeah, that's a good summary.

Ansgar Dietrichs: Sounds good. Yeah, then, in general, thoughts, kind of, I do know that there's a few people on here that have… that are actually very strongly in favor of frame transactions. I think now would be a good opportunity to speak up, to make the case, see if we can… Still convince the skeptical clients. Anyone who wants to. Sweet.

Lightclient (Matt Garnett): Kinda seems that the main concern is that frame transactions are gonna delay the next fork. That's what I'm understanding, at least from NetherMind. But I'm wondering if it changes people's opinions, knowing that we can Choose how complicated to make the transaction pool. That's one thing. The other thing is that… you know, we still have quite a long time before this fork is going to go live. We're already talking about maybe large changes to Glamsterdam? So we're looking at, like, you know, at least one year out before this feature would even go live. Yeah, Ben.

Ben Adams: I… I would… I would go further than just saying the latest work in that we're… we've… Positive towards friend transactions, but we're not 100% convinced, so… we've… Prefer the optionality to say, okay. Maybe this… this doesn't work at some point in the future. Whereas putting it as headliner would suggest That is the fork, if you know what I mean. It's not.

Lightclient (Matt Garnett): I mean, yeah. If we say it's headliner, but we reserve the right to remove it later, if we realize it's not gonna work, is that… You know, sufficient to… accepted as a headliner. Like, we don't have to tie our hands behind our back with processes and rules if it's gonna lead to, like, worse outcomes for Ethereum.

Ben Adams: Yeah, but it would be weird messaging to put something as a headliner and then… Think about it later.

Lightclient (Matt Garnett): I mean, what you're proposing is also not possible with the process either. Like, if we don't accept it as a headliner, now, because it's been proposed as a headliner, then we couldn't accept it as a non-headliner until I-Star. I don't know if this is what you're proposing, or if you're proposing that we consider it as a non-headliner an Hegota.

Ben Adams: As a non-headliner in Hegota.

Lightclient (Matt Garnett): Right, so I would just say, like, if we're going to, like, change the process, we might as well just accept it as a headliner now, with the assumption that we could decide later that we are not going to be able to deliver this, or that there's not enough agreement on what the shape of the thing needs to be. Because if we say it's not a headliner, now we have to wait several more weeks for the non-headliners to come around.

Lumi | Offchain Labs: That's kind of the definition of a headliner, is we delay our upgrade, so why would we call it a headliner if we won't delay the upgrade? Might as well just not have it as a headline.

Felix Lange: I'm gonna speak up now, so I think the, this has been feedback that I also got from talking to client developers individually, that it just somehow seems like for this… I think the concept of the headliner was introduced So that clients could all commit to a singular goal, which has to be achieved by the fork. And if this… this basically kind of defines it as being this thing that the fork will be delayed over, and that will not be pulled from the fork. So it seems that we cannot currently gather this kind of support for EIP8141. If everyone was agreeing on it, or the absolute majority of the clients would be agreeing on it right now, that this is the single most important thing we have to achieve within the Hegota fork, then we wouldn't have such trouble deciding on it.

So, this is kind of where this hesitation is coming from, to say, yeah, maybe we should downgrade it to a non-headliner and whatever. I personally am not super attached to the exact process here. for me, personally, I feel like it's a good moment in time to introduce native account abstraction. It has been sitting there on the side for a good number of years. With people exploring different ideas to bring it there, and we feel that with EIP8141, we have it's probably our best shot at it yet, especially regarding the mempool compatibility. Like, if you look at the previous account abstraction proposals, the mempool was always the issue, so this time, we are really making sure that

at least some of the native account abstraction flows can be handled by the public mempool, whereas with previous proposals, it was always clear from the start that, yeah, even if we have native account abstraction, there will just not be a mempool as we know it for these transactions. So I feel like it is… Better than what was proposed before for this particular topic. And so, yeah, I've… I mean, given that there is no other good candidate for the headliner on the EL, that is, like, another reason for me to say, yeah, I mean, this… It's like, we might as well do this one. I mean, it is a bit larger change than tweaking gas prices or trying to…

I don't know, add some convenience features to the protocol. Like, it is a pretty fundamental change to the protocol in many ways, and so that's… for me, this is more important as the headliner. It just has, like, it gives a big upgrade to the chain in some ways.

Vitalik Buterin: One, one thing I, wanted to also, highlight again is, that, there's a lot of, synergies between FOCIL and native account abstraction, and, like, those two EIPs are actually, quite, quite naturally complementary, basically, because, what, what FOCIL, does is. It creates very strong, rapid inclusion guarantees. For transactions, and native account abstraction greatly increases the set of things That, can be directly done as, as transactions. And so, if you have, those two things together, then it basically means that, very large sets of applications and, including transactions from smart contract wallets, and potentially including

Things that, transactions that pay fees and other assets, also including privacy protocols, will… Bie, will be able to be inter, intermediary-free across the full stack, meaning they'll be able to no longer need intermediary choke points, both at the, layer of getting included into a transaction, and at the layer of needing to go through a block builder if block builders become… much more dominant, and so I think, And this is, also a case, for, base, treating the two, almost as a very interrelated unit to some degree.

Ansgar Dietrichs: Makes sense. Dragon, if you want to?

Dragan Rakita: I would say that there is uncertainty or unclarity about exactly is the frame, the accent… listening from the Nethermine, Erigon, and basically all the clients. They need more time to evaluate what is needed, because they are uncertainty, this is the solution that we want to include or not. I think that should be a good enough reason to not include it as the headliner. for the… Frame.tx, in general, basically our stance is it's too complex, and those things, basically protocols that you want to include to enable all the things that you want to, it should be natively supported. Because if it's natively supported without that SEQTVM obstruction that FrameTX now has. It becomes a lot easier to use, it becomes more straightforward, it becomes a lot, yeah, better.

So… Yeah, I think that's my stance here.

Ansgar Dietrichs: And Nico, you're unmuted? Did you want to say something?

Nicolas Consigny: Yeah, sorry, I couldn't raise my hand. One thing that I wanted to add is, on the timeline, timeline question, even if we headline or not, even if we ship, frame transaction in Hegota. It's gonna be a tight timing for DAOs to upgrade their contract to post-quantum-resistant transaction. So, we are looking at in the best scenario, one year to ship, the EIP. Then on top of that, you need to account for a very messy, DAO voting decision, which will take a few months. You need to add to that some audits for the… For the verification schemes. So this brings us to 2028 and 2029, or even… a bit later with, potential delays. So yeah, I just wanted to remind that, in this context, it's… it's a bit…

Gamblish to go for something that is not, post-quantum. And, even… even if we take the French transaction and we manage to do everything, it's gonna be a… a race, to, like, ship this, in a, in a safe time frame, so by 2029. So yeah, I just wanted to, to highlight the urgency here. Because, yeah. we have to account for DAOs, and we have to account for wallets, so yeah, it's… it's gonna take some time to do all this. Sweet. Yeah, I just… yeah, one comment I see in the chat, it's, it doesn't solve post-quantum directly, but it's… it does enable native, solidity verifiers. to be the main account. So yes, in a sense, even if it's expensive, it does solve, post-quantum, yeah.

Ansgar Dietrichs: Any, mug you want to say something?

Mark Holt: I was just gonna… is that an argument for or against making it a headline?

Nicolas Consigny: It's foreign, it's, for, Yeah, it's for making it evident by committing to it.

Mark Holt: Yeah.

Nicolas Consigny: Basically, if we eat it, it's gonna be very complicated. And we will be gambling with the PQ timelines, which we really don't want to be doing.

Mark Holt: Yeah, I think if we need to reach consensus, we also maybe need to… Because it seems like, from a RET perspective, your concern is, is this the right AA proposal? I mean, I think the other thing that we need to think about is what happened with 7702, which… it's kind of… it was a less-than-perfect solution on the basis of, let's get it in. And let's get adoption. And actually, if you look at the history of that, adoption has still been quite slow, although it was put into the protocol. quite a long time ago. So that kind of, I think, speaks to what you're saying. It's saying we need to make the change sooner, because the adoption process after that is going to be pretty slow anyway.

And if we don't… if we delay it by another year, it's another year of delay, fundamentally.

Nicolas Consigny: Yeah, exactly. And just, we also need to take into account that it's just not only wallets, it's also DAOs. Like, if you were a quantum attacker, what you would attack right now is the governance contract from Aave, and you would… You would, you know, redeploy the… the… you would update the Aave contract and run everything. You would not target, like, random wallets. So the main, targets are, big governance contracts and stuff, and they take a lot of time to move. So, yeah. We need to account for that, too.

Ansgar Dietrichs: Thank you, derek, you fanned up?

Derek Chiang: Yeah, I think I just wanted to say that I think, you know, since a lot of people are comparing 702 with frames, I just want to say that I think it's slightly misleading to, use the fact that maybe 7702 has lower adoption than some might have hoped, you know, even though, like Matt said in the comments, it still has decent adoption. But I think it's slightly misleading to use that as sort of, like, proof that, like, maybe A141 will have similarly low adoption, because the thing about 702 is that it's not actually native AA in any real sense, right? Like, 702 is simply a mechanism to allow EOAs to upgrade to smart contracts. To, you know, to upgrade to smart accounts. But it doesn't actually, like, allow the, smart accounts to originate transactions, for example, which is a core goal of NativeAA. It doesn't give the,

the, you know, the accounts the ability to have their guests natively sponsored, for example, right? You know, so if you look at how the wallets have actually used 7712, for example, MetaMask, right, you know, they're using 7712, but… they cannot actually give their users the ability to have their guests sponsored without relying on application-level relayers, such as ERC437 bundlers, right? You know, whereas firm transactions is actually a full-fledged AA proposal. that natively introduces the capability of, you know, things like guest sponsorship, transaction batching. So I think, like, you know, firm transactions.

Mark Holt: Yeah, so…

Derek Chiang: With the latest updates.

Mark Holt: Yeah, I was actually… I was actually making the opposite point. Basically, I think we should do frame transactions and not do another, let's do something simpler.

Derek Chiang: Oh, awesome. Amazing. Yeah, I think, yeah, I think some people in the comments seem to be suggesting otherwise, you know, but yes, thanks for clarifying.

Mark Holt: Yeah, I'm just saying, because I originally bought it up, but my reason for bringing it up was to use it as an example of, there's where we did something which wasn't the full solution. Now, actually, I think it's quite good, because I think the frame solution is a lot better than the original AA one, because it's had time to It's had time to get developed, but it feels to me like this is the time that we should do it. Basically. And not… and not have another conversation and come up with a kind of compromise.

Ansgar Dietrichs: Right. Yeah. I mean, I would… I think… I… yeah, I personally… you know, like frame transactions, I'm not sure how I feel about the headliner situation, but luckily, this is not my decision to make. I will just say, in terms of purely process, I, you know, right now, seemingly, I only see two clients that would prefer this headliner. With Geth and Erigon, I think if there was a third client, so if any of, say, Neithermind, Beisu, or Reth would change their minds. I think we… we would be in a place where we could at least reasonably consider whether we would still want to go ahead with Headliner status. I think as long as it's only two clients, I think the default decision here will be…

To, or would be, would be, of course, there's still time, but would be to reject it as headliner and then reconsider it as a non-headliner, Yeah, so I'm just wondering, out of the three clients that are currently against it, it seems like Ref is pretty locked in on being skeptical, I think also with some background there with the tempo developments. Yeah, I was wondering, basically, like, maybe specifically a question towards Nethermind and Besu. Do you two… do the two clients think that they are pretty much locked in on the decision of preferring no headliner for today, or are either of you two still kind of, like, considering, open to arguments? Yeah, what's the situation there?

Daniel?

Daniel Lehrner: Yeah, from… so from Best's side, we had, like, a ranking, and no headliner was basically the first one. And frame transaction and Lucid was a close second, but still, if the majority of the other clients is no headliner. Then our decision, still stays like this, so… There is for us. I don't think there's a reason to change that.

Ansgar Dietrichs: And from the nethermine side…

Łukasz Rozmej: I don't know, I don't… my personal standard didn't change, I don't know if other people.

Ansgar Dietrichs: Right. Yeah, I personally… Don't… yeah, sorry, Matt, you seem to be unmuted?

Lightclient (Matt Garnett): I was just gonna say, I feel like we're still focusing on… the ability to deliver the change, but I don't really understand why We're not accounting for the fact that we can… tune how much we're going to deliver with the frame transaction substantially. Like, this isn't like most changes where you have to implement every single thing. in the EIP to put on the mainnet, because the consensus changes for the framed transactions are really relatively small. Like, Etherrex said they implemented it in just a couple days. the transaction pool is where things get more complicated. Like, if we're going to submit, you know, if we're going to support the, you know, paymaster sponsoring. Then this is going to be a much larger change than if we added frame transactions to the consensus object.

Which would allow them to, use frame transactions, begin the adoption of frame transactions, and then let clients, after the fork, continue working on the transaction pool changes without being blocked on a fork.

Łukasz Rozmej: So, to some extent, I… well, I actually quite agree, but I read the situation differently. I read it like, okay, we specified the easier part, and the harder part is left unspecified, but please commit to it, right? So, that's how I read the room.

Lightclient (Matt Garnett): I mean, have you… have you read the ERC about how the transaction pool will work?

Łukasz Rozmej: Boom. there is a special specified ERC, not the EIP.

Lightclient (Matt Garnett): Well, I mean, it's…

Felix Lange: And we can explain this. So, the thing is that the EIP8141 was developed from EIP7001. And this EIP was itself developed from ERC43C7, so all of these proposals are coming, basically, from the same family of proposals related to account abstraction. And, as part of the ERC4337, the Ethereum Foundation account abstraction team has developed a set of rules for their mempool, which Can be applied. to analyze if a, basically any account, any contract interaction is somehow safe for the mempool. I have to, preface this, though, to say that the mempool that was implemented for ERC4337 is quite resource intensive, so I would not like to use it as the best possible example of it, but let me still go into detail a bit more to explain how this works. So.

basically, For the account abstraction. to be viable in the mempool, there are two strategies. One of them is basically acknowledging that the full generality that account extraction allows basically requires a very complicated mempool, and this is what this ERC represents. It basically gives you a full set of rules where if you implement that, you can judge any transaction to see if it… once it matches these rules, it is safe to include in the mempool. But you do also have to trace the execution steps of the transaction to validate these rules. So basically, these are rules like, if this opcode is followed by this opcode with this parameter, then the transaction is invalid, basically. So, it is good to have this rule set, and I think it's quite an achievement that they got very far with it, because it allows to build a general mempool for all account abstraction transactions.

At the same time, this is not the mempool that we would want to see included in, like, the full nodes, and I don't think it's very likely that this will ever happen. What we will be doing instead is, basically, with the frame transaction, the idea is that we, we… develop the frame transaction specifically so that the protocol implementation has an insight into what the user is trying to achieve with their transaction by inspecting the frame structure. And also. In some ways, it… basically, it allows to implement more strict mempool policies that only allow a subset of transactions to be accepted into the public mempool as we know it today. And in practice, this is how I think the mempool will work with EIP8141. For the node implementations, we will come up with a guidance document that explains, like, a minimal set of rules that allow some useful subset of transactions to be submitted to the public mempool.

But then, there will also be third-party mempools which implement different rules or more complicated rules. And anyway, the goal of EIP8141 is Primarily just to allow these, like, arbitrary transactions with any kind of, like, approval interaction to be included in a block. Because this means that, ultimately, it is up to the block-building community to figure out, like, how, like, all of these flows can be optimally supported. And, for example, in the L2, world, where most L2s use a sequencer. They actually have the capability to introspect transactions in a better way, so they can have different policies than, for example, a public Ethereum mainnet full node can have. And so this is the other reason why we do not specify all the rules directly in EIP8141, because there is just no one set of rules that works for everyone. It is, like, a nuanced thing.

Okay, sorry, it was kind of a long text, but I hope you guys…

Łukasz Rozmej: Yeah, yeah, I understand it. So, My question is, should we… should we, make it a headliner, which we want, without polishing those rules for, public Ethereum mainnet mempool? And… We won't…

Felix Lange: DevNetly. I mean, we have created some examples already in the ERP that show you, for example, the frame structure of certain transactions. For example, if you just want to transfer, like, if you just want to do a simple balance transfer, it is actually more involved with a frame transaction than it is with, for example, a simple 1559 transaction, because you will have. So, we have created some frame structures there that can show you, okay. approximately what this can look like. And also, obviously, it depends a lot on, for example, which signature verification scheme is in use, and how much. We have been stressing this point quite often, that there is also this ability to set the validation gas, because if you think about the mempool, how it works right now.

the mempool basically performs a signature validation on every transaction. In most clients, this is cached somehow, but basically, one time, when the transaction is received new, it has to verify the signature of this transaction to make sure that the sender is correctly identified. And so, yeah, this doesn't really change, but, like, in the 8141, Obviously, it says the sender address is directly a part of the transaction, but it's not proven, so in order to prove it, you have to spend some amount of gas to determine that. In the public mempool, we will assume that every node will have some amount of validation gas, which it is willing to expend to perform this check. And we think that the

this will become quite an important thing. We have not fully finished our experiments for this either, like, we are still working towards, like, figuring out what are gonna be these limits, what are gonna be these rules. Like, this is for us also a big part of the work that lies ahead in the coming year, and this is also why Fundamentally, the guest team is working so much on these changes, because we feel like we have a good understanding of the public mempool. And this is kind of why we took over this account abstraction thing, because we feel like, yeah, the mempool is kind of the primary challenge here. And, yeah, I mean, we don't have all the answers right now, definitely. It's a bit unfortunate, but…

We have to propose the headliner a year before the You know, fork, so we have to just… there will.

Łukasz Rozmej: Okay, exactly, I agree, so that's why we proposed to make it a non-headliner EIP and go this path, because of these uncertainties. That was exactly our point.

Felix Lange: Okay, well, I mean, there's no… I can't really argue with that, I'm just… I mean, anyway, I'm pretty happy that you… you understand my points and, like, why we, Chose to work on it. Ben, you also have your hand up, or is it resolved?

Ben Adams: Yeah, I was just gonna say, so… Potentially, ultimately, you'd be in a situation where to accept transactions, you'd have to be invoking the EVM. On the… in the transaction pool. To decide whether it's a valid transaction.

Felix Lange: Yeah, I mean, that's kind of a part of it, yeah. But then there's a question, like, what can the EVM do, and like, what do you allow the EVM to do in this environment? Like, it is definitely a new environment for the EVM. Like, the EVM has not run in the transaction pool before, so in this case, we are treating the EVM as more like, yeah, like an arbitrary function, basically.

Mark Holt: Yeah, I think it's fair to say you have to… you have to introspect the EVM instructions in the, in the… in the transaction. you don't need to necessarily… I think part of the crafting of the, of the rules was so that for certain of them, you don't need to execute, you can just inspect.

Felix Lange: There are various ways to do it. There is, for example, also the possibility of allow listing certain contracts, because they are known to be safe. So, for example, if you know that a certain, like, a certain account contract has a specific semantics, you can just model these semantics in native code, and then apply this model in your transaction pool, then you don't have to run the EVM. or there are various other ideas that can basically save you some of these more expensive evaluations. So it is kind of an open area, but we feel like, fundamentally, the goal of the frame transaction is to make it actually possible to do this, because we will, over time, I already foresee it, be adding more and more things

to this transaction to allow the protocol to kind of introspect ahead of time what is, like, the validation intent of this transaction. And we already kind of have it now with the verify frames, so it's pretty clear to the transaction pool, for example. This is the reason why verify frames exist in this proposal, so that the mempool can see, okay, the verification is in this exact call. and this call has this much gas, so it can right away say, yeah, I mean, it's trying to use way too much gas for the verification, I'm not even going to start executing that, for example. So, it's not like you have to run the EVM to the full extent for every single transaction, you only have to run it, like, when it seems like it's gonna have any chance at actually validating, for example.

Anyways, it's going really deep now, but I feel like these discussions are valuable, because this proposal seems to be heavily misunderstood sometimes.

Lightclient (Matt Garnett): It might also be worth mentioning this… Oh yeah, I was gonna… say Frederick's point, but Frederick, you can say it.

Fredrik Svantes: Yeah, yeah, I just want to say that there is, this, There's other aspect of it as well, which is revolving around end-user security, and one of the things that we are… that we've seen and heard a lot from end users is that They are losing quite a bit of funds through various types of hacks, scams, and drainers, and other means, and… One thing that can solve this is, or at least one part of solving this kind of problem that end users are facing, which in some ways is driving people away from using blockchain technology, because they… once they lose all their funds through a scam, they're not super happy to continue transacting. So, one of the things that we can do is to implement something like transaction assertions, which will allow people to

Basically, or wallets to provide certain assertions, that needs to be true for the transaction to go through and otherwise revert. So if a user believes that they will receive token X, and the transaction is actually doing something else, then the transaction would revert, and they would not end up losing their funds. And this is something that framed transactions could solve pretty nicely from the looks of it, which is… why I am personally pretty excited about it, and I think it will have A very big positive impact on the user ecosystem.

Lightclient (Matt Garnett): I feel like if we don't make frame transactions the headliner here, it's gonna be harder to build things like this on top of it, because we don't want to accept You know, multiple non-headliners that are dependent on each other. Then we create, like, a large risk profile for, you know, one of them not shipping, causing A cascading failure of the fork.

Ansgar Dietrichs: Okay, so we are 10 minutes before the end of the call. I do think I want to at least actually try to make a decision today, so just another check. How are people feeling? I did see in chat that, say, on the Netherland team, maybe there's just… Kind of… different opinions, but it did seem like the team overall was Still pointing more. Towards no headliner. Mmm… yeah, it just… it seems hard. You know, I think… I mean, obviously, we could just not make a decision, but I don't see how… what would improve by two weeks from now that would make… allow us to then make a decision, and the cost of, of course, delaying these types of decisions is high, so I'm very hesitant to, like, to pay that cost, unless there's a specific reason why we would think that

That there will be significant resolution within those two weeks. And otherwise, it just feels very hard to… Except a headliner with such significant, client skepticism, so I think that the clear default decision here would be to just not accept it as a headliner. I just don't really see… M… Yeah, how… what else, again, like, just process-wise, I don't…

Lightclient (Matt Garnett): are in favor of adding as a headliner, and then even Lucas is saying now he doesn't know for certain and doesn't want to block it. Like, there is risk in changing Ethereum, there always is, but, like, part of… Having the governance decisions now, early, means that we can Try to minimize that risk a lot by iterating on this, rather than continuing to spend time figuring out what we're gonna even do with the fork.

Ansgar Dietrichs: Okay, but, I mean, so right now, I don't think, unless, again, over the next 5 minutes. there's still more change. I don't think we're in a position to accept frame transactions as headliners, just because right now there's two clients in favor, and then a little bit of openness, but uncertainty from some of the other clients. That's not enough of a basis. I do think we could say we wait two more weeks if people think, like Barnabas was proposing it in chat, for example. we, yeah, because it is really on the edge, I'm open to that. I would want to get the feeling that at least the majority of clients would prefer delaying that decision. Then I think we can do that.

Yeah. But then again, like, I think the understanding for next… for two weeks from now would be that, yeah, the default would be to not accept it as a headliner, so things would have to tilt more in the direction of headliner support, for it to make a difference. Ben?

Ben Adams: I'd just like to… pull out what Pelix said in… in chat. I think that's interesting. Maybe promoting it to Headliner later?

Ansgar Dietrichs: Well, we don't really have a process for that. I am… But personally, I'm always leaning on the side of, like, some flexibility with processes. This seems like it would be bending the process. quite a bit, which I don't… I definitely don't feel like… prepared to say that that's going to be possible today. I mean, obviously, we could see, we could, you know, discuss this, and see, maybe over the next two weeks, decide whether that's something we would be willing to do.

Ben Adams: But yeah, I feel like…

Ansgar Dietrichs: I feel like it's a bit tricky to just impromptu make such big changes to processes.

Ben Adams: Well, I mean, it's… it's the no headliner gambling.

Ansgar Dietrichs: What's that?

Ben Adams: Well, then, if we don't have a headliner, then… It may not be a situation covered by process.

Ansgar Dietrichs: Sure, yeah, Avat?

Ahmad Bitar: Yep, can you hear me?

Ansgar Dietrichs: Yes.

Ahmad Bitar: Yeah, so I wanted to just… Like, surface that… The Netherland team is split among this, some think that it shouldn't be a headliner, but Some of us think that we like it as a headliner, just to, be clear about that. I also noticed or heard similar, feedback from Bezo, but I might be wrong. And we both… we know that death and wrath are… no, no, sorry, Geth and, A3X are supporting, so… doesn't it seem like most consensus is saying they support it as a headliner, or am I understanding this incorrectly?

Mark Holt: I think you guys would need to have to get off the fence. I think is what the situation is. I mean, I guess the question is, what would it take to persuade you that it's a good idea? Maybe that's the question that we should ask. That's the only way that'll take the process forward. Because presumably there's some, some… definable reason why it shouldn't be for people who are saying no. Maybe we need to understand what those issues are and address them.

Łukasz Rozmej: So for me, definitely, you know, some kind of rules on… That are acceptable by everyone, like the consensus on the rules around the transaction pool that is, on the one hand, not dossable and works in a reasonable way, on the other hand, has reasonable, usability, which I'm not, you know… I'm… I have… I'm not sure if it's easy to achieve. Both.

Mark Holt: So does that just require… because the EFAA guys have spent quite a lot of time on that. Have you… have you looked at what they've proposed?

Łukasz Rozmej: Oh, well, not completely, and, Felix says they already kind of have a bit different idea for the frame transactions.

Felix Lange: Yeah, I just wanted to quickly highlight again that, like, there is two different things here. So, we're talking about this rule set, which is also cited within EIP8141, and this rule set is giving this basically, we are citing this rule set because we feel like it is a very comprehensive way of analyzing the behavior of the frame transaction. I don't think we are going to apply all of this rule set in every client, it's just not possible. We have to come up with, like, a simpler ruleset And… this is still being worked on right now. I mean, one of the key things is that we do not actually have, like, the account implementations, like, fully worked out. That's a whole other thing, because the account implementations are technically something that can

is arbitrary in this proposal, right? At the same time, maybe one thing I can also highlight is that recently there was this default account added into the EIP, and the default account definitely is kind of a bigger change, so it means that, like, all of the existing EOAs get some features added, like gas sponsoring and native batching and things like that, possibly even the ability to do different types of signatures. Like, there's a lot of things in the EIP now that were added all at once with this default account. This is also still something being worked on, but then the thing is that, like. Once this is in, then it's, like, the question, like, these, like, public mempool rules definitely should permit using the default account.

And then there'd be, like. The thing is that we are proposing this EIP now with some ideas, and we have pretty good ideas about, like, the space of it, but the absolute details, like, there is still some things that are being worked on. We're not presenting a fully finished design that has, like, every little corner worked out. that's just not how the process works. We have to provide the EAP early on. So that it can be worked on during the fork cycle. We cannot just, like, finish everything and then present it. that's… that's… it doesn't work like that with other EAPs either, like, the… no… most EAPs get proposed, and then do… when… once it comes to…

Time to actually implement it, then all the changes come. So that's also how I see it with this one. I mean, we have a pretty good idea how this can all work, but… It still requires the work.

Ansgar Dietrichs: Okay, so, with 2 minutes left, then it does sound like, while I'm usually always… like, I don't like delaying decisions, I'm sometimes guilty of it, but it feels like, in chat also, it seemed like there wasn't really anyone pushing for a decision today, and several people Suggesting that we should decide, we should wait for two more weeks, just given that it seems to be so on edge. M… Yeah, so then, I do think the right decision here is to say we make the final decision on whether to have frame transactions as headliner or not. Two weeks from now. By that time, we then also will have some more information on, we can see if there's anything else process-wise that would be an option or anything.

M… default outcome, again, I think, would be to not select it as a headliner, so, you know, just… people should have that as a mindset, but… but I… yeah, I think we are not far away from enough client support to change that. Yeah, so… and then, I think it's on the frame transaction champions to maybe set up some, some sort of… You know, one more breakout call or something like this between now and then to finish.

Mark Holt: Yeah, which it seems like needs to focus on the usability in the mempool, or the ability to build something in the mempool, at least a minimum. That's actually practical. Because that seems to be where the… where the questions are. So maybe that's what the breakout should address.

Ansgar Dietrichs: It seems reasonable for the sterleys to be a big focus. Mmm… And yeah, Matt also asked in chat, and then I think, let me put it this way, I think ideally anyone who has some specific questions or concerns or thought that they would want addressed. do reach out to the champions. Also, ideally, we have an agenda item. issue open where people can comment questions, topics they want to have addressed in advance. Let's try to make the most out of this so we can make an informed decision, because I feel like we should not end up having this be a coin flip. I think, ideally, by two weeks from now, we have a clear clear decision where everyone is behind, and we can actually… I think that's best for Ethereum. Usually, coin flips are not great. So let's try to get there in two weeks. And then one last comment there, I think also,

In terms of non-headliners, there's the question already, at the moment we log in the headliner decisions, we can open up the proposing window for non-headliner EIPs, and then we will communicate, kind of, specific deadlines there around by when do non-headliners have to be proposed. Yeah, at a later point, either 2 weeks from now or 4 weeks from now, we'll communicate, the specific deadlines there. So, look out for this, but basically, you can, you can prepare, like, you can prepare to drop your non-headliner proposals, starting, starting next call, basically. Okay, With that, we're also running up on time, we had a few more agenda items on the agenda, but I think I'll just bump them to…

Two weeks from now. And… leave it at that. Awesome. Thank you, everyone. And talk to you all in two weeks.

Lightclient (Matt Garnett): Thanks.

Marius van der Wijden: Thank you, bye.

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