All Core Devs - Execution #233

Transcript

Ansgar Dietrichs: Hello, everyone can hear me?

David (dionysuz): Yes. I'm helping out with the stream, by the way, Ansgar, so just let me know whenever.

Ansgar Dietrichs: Perfect, yeah, let's just wait a couple more seconds, and then we can get going. Okay, let's go live.

David (dionysuz): Alright, we're live.

Ansgar Dietrichs: Perfect. Hello, Juan, welcome to… All Core Devs, 233. We're really getting quite high into these numbers. We have a couple of things today on the agenda, first about Glamsterdam, and then, about our… hopefully… well, not hopefully, about wrapping up the Hego to Headliner discussion. So, starting with Glamsterdam first, first general call for DevNet updates? Do we have… Any updates about the… Current ongoing debit efforts?

Stefan Starflinger: Yeah, sure, I can give a quick update. Just a quick update on DevNet 2, it's going pretty well. We had one issue with Erigon, where they were creating too many transactions, too many peer-to-peer connections. But otherwise, it's been going pretty well. And definite 3 efforts right now. I'm still doing a lot of testing. Most clients are very far along with the implementation, but there are still some rough edges that I'm ironing out and doing a lot of kurtosis testing at the moment. And it would be good if clients could also help with that effort. I'm still finding a lot of issues just with, same clients in the network, for PolyDevNet 3. And then I'll do, mixed networks, and once that runs decently stable, I will launch, DevNet 3, I hope.

Beginning next week.

Barnabas Busa: Can I also give an update on ePBS.net? it's not looking good, so withdrawals have, broken the DevNet, and, we have decided to basically, give it a few days and launch with DevNet 1, with the new PTSC changes that, we have agreed on on ACDE. Initially, I think Prysm will be the first one that will be ready, and then I'm planning to launch a network with only Prysm, and as the clients are, finishing their implementation, then I can start onboarding them.

Ansgar Dietrichs: Sounds good, and is there anything from the EL side that, people should pay attention to, specifically?

Barnabas Busa: For ePBS, no. Optionally, if you are bored, you can create an ePBS, the Net Zero branch for us, and we could onboard your EL client. And if you need some, explanation what you need to do to be onboarded, just reach out.

Ansgar Dietrichs: Sounds good. Any other DevNet-related updates? Chris, looks like you're unmuted, I'm not sure if that's on purpose or just accidental. Okay, then we can move on to the, next agenda item, which is, I think Maurice and Bhuta wanted to give an update on the… benchmarking progress so far. Are you two on the call? And… You wanna go out with that?

Marius van der Wijden: I'm here. Let me share my screen. I hope you guys can see my screen now. We can… Oh, yes. I want to talk to you about, Some repricing updates, we have this new tool called Benchmark Core, which is really, really cool. We have created a lot of benchmarks in the past. And, we have this tool to run them. On different client configurations, on, on different things. And, we can see… We can put in a threshold that we want to be able to run, and we can see which tests are run… are running below this threshold, and which tests are running above this threshold. If you remember from my last presentation on, I think 2 or 3 SEDs.

Our goal… the plan, or our plan right now is to Make sure that everything runs at… 60 megabits per second, which would be really, really cool. So by default, this tool is, is, put into, or, yeah, it, it, it, puts the threshold at 60 megabits per second. As you can see on this run, there are only 4 tests that would be less than 60 megabits per second. Most of them are Oh, hi. The benchmark core is available to… To people who ask, so if you want to get access to it. You can, if you are on an EL client team and want to get access to it, want to see your numbers, you can either ask me or…

Rafael, to add you to the… to it. We have, several, benchmarking suites. We have the compute tests, 47904. Those are around 5,000 tests. And we have the stateful tests, There are around 3,000 tests, and they, Yeah, cover all of the opcodes that interact with tests. Right now, we are reworking these tests on top of block access lists. We have some runs with block access lists already, and we have also… there's a mode in Benchmarkall where you can do the diff between two runs to see if they improved or… Yep, or not improved. And, what we can see is… Roughly 3X improvement, through, through DALS, on most compute tests. On the floor…

core CPU, so this is, yeah, roughly in line with what we've expected the gains from Balls to be. Now to the EIPs, EIP 8037, the state creation. Change is included in the Definite 3 spec. Our clients have implemented it, and we have a pretty comprehensive test suit, from execution spec tests. One problem that, that is… that came up is that the legacy tests Still need to be updated, they are being updated right now, but that's a bigger refactor, because… Some of them are in a format where it's not easy to update them, so they need to be ported into the Python format or something similar, and they need to be updated so that we can

Programmatically change, change them depending on The, the block gas limit. We have, EIP7976, the coal data flow increase, which increases the coal data gas flow to 6464. This allows us to raise the max gas per block from roughly 105 million gas to around 670 million gas, which would be really, really nice. We made some analysis, and roughly only 1.5% of transactions will be affected by this repricing, and there are no backward compatibility issues, because this is simply a transaction gas limit increase. They are already included in the execution spec tests. So, they can be very safely scheduled for the next definite. Eap7981 increased the access, list gas cost, yeah.

We use the access list size in the 7976 calculation, so what I just talked… bought previously, otherwise, these access lists could circumvent the floor pricing, and this would reduce the worst-case block size by 21%, with no impact on users. And we also feel that this can be safely scheduled for the next DevNet. Change is very, very small, But yeah, it will, it will get rid of the… this edge case where people just put a lot of call data or a lot of access lists. And… and bloat the block that way, which, yeah, helps us to scale. Then we have the 7904 compute repricings. These are very preliminary numbers, but as I said in the beginning, our goal is still to, to, arrive at, 60 megas,

baseline for all of the compute opcodes, and hopefully all of the state opcodes as well. And these are roughly the opcodes that we are looking at, regarding the repricings. Some of them… can be, might be… might be able… like, we might be able to just optimize it in certain implementations, like, for example, the catch-up, opcode is… in the second worst implementation, it's at 70 MHz, so it would pass, but in the BSU implementation, it's at 40. But there are certain things that are… Yeah, as you can see here, the point evaluation precompiled is basically at the same level in all clients, so there's not much we can… We can do to, Other than repricing. So, yeah, we are in contact with, with clients in order to see if they can improve

these up codes. Yes, EIP8038, The state access repricing. Unfortunately, we have, less data on state access than we have on, on compute repricings, because compute repricings are very easy to. easy to do. State accessory pricings are a bit harder, but those are roughly the operations that we would Reprise, and, yeah. So, the call, balance, self-destruct X opcodes. And why we want to reprice them? Basically, right now, you can… I think it's… at 100 million guess, you can load something like 8GB of data from disk or something with, with, some of these opcodes, and that's a big problem for for us, for increasing the gas limit, but it's also a big problem for CKEVMs. So, yeah, we would like to reprice them.

Yes, and then the gas repricing outreach, Bhutta has been working on that, so I would like to invite him to To give his slides.

Butta: Yes, can you hear me?

Marius van der Wijden: Yes.

Butta: Alright, so over the last two months, I've been reaching out to various stakeholders. I will post some links in the chat. So the first… the second one is the gas repricing.com website, where you can find various information. This is also the website that was sent to our stakeholders. And if you're curious what the questions were during the survey, you can also go through the survey, which is linked at the top on the website. But as of now, 21 people have been surveyed, out of which were 16 different teams, DeFi teams, wallets, Layer 2s, and so on. Yeah, if you go to the next slide, some others… I will keep it short, what the outcome was. We have posted a summary, an anonymized summary on Twitter of the outcome, if you're curious about the details, but…

Yeah, quick summary is that most of the entities were concerned about the complexity, not about the increase itself. And a few entities asked for, toolings to be ready so they can test it out. Something also may be relevant for the DevOps team, the tool where people are able to simulate transactions was quite helpful to see whether that destroys something. Besides that, so 21 people… 21 entities were served, but we also reached out to, tool links and other entities that were not directly, impacted, so they can prepare accordingly. And so far, no major red flags. So, yeah, that's a quick summary from my side.

Marius van der Wijden: Thank you, Bhuta. And, yeah, I didn't really finish the slide, so there's a bullet point too much, but, For security reviews, we have created a framework to trace all transactions, in order to understand how these repricings would impact the transactions that are currently on the network. Around 6.8 million transactions will be affected by 7904. We are still, working on the analysis on this. Most of them are very likely, arbitrage boards, and, and, things like ephemeral contracts that can be changed very, very easily. In order to, in order to, yeah, to, to, to use the new pricing. There were very few contracts, yeah, none that we have seen where we saw, like, an immutable contract that breaks because of the repricings that cannot be updated, yet. So, yeah, we are still working on that.

Once the numbers are final, we will rerun this tracing analysis. And we will, invite external security reviews, from, from, from, companies, in order to get a, a better overview. Of the impact of these changes, and we will also provide some grants for that. Yes, and I want to quickly show you guys Benchmark Core. Because it's a very… it's just a very cool tool. you have to sign in with your GitHub, so if you're a core dev, you want to have access to it, again, you can either ask me or Raphael, and, you can, like, we have, we have different suits, and you can see some of them are on top of Mainnet, some of them are on top of BloatNet.

And you can see, how many tests are in each suit, and these are the compute suits, these are the stateful suits. And if you look here, and you can look into one of the test suits. You can see there are some, tests that are… Red, some tests that are yellow, and you can see, these tests for opcodes that should be… for the Geth implementation should be reprised. And you can see which of those, this is, for example, the point evaluation precompile, so KCG. And, what you can also do is if you… click on one of the tests, you can see, okay, this test ran at 40MP per second, all of the time was spent in execution.

You can see the cache performance. We only had, like. Very few, storage reads, like 8 storage reads, or 10 storage reads in total, but all of them were misses. And you can see the breakdown of the storage operations. And you can also see which requests were sent, and what the responses were. And What's also interesting is, up here you have, a log of the client where you can see the whole, the whole version, the whole, the whole run, and you can see the configuration of the, of, of, of, of this run, so we, used 8 cores, at 3.6GHz. 60gb of memory, and… but we limited the resources to 4 CPUs and 32GB of memory, so this is,

in line with, with this EIP we have about the… Node configuration, and yeah, all of the stuff that you… that you want to… to modify, maybe, for, for UCommerce. Yes, all of this has been built by, by Raphael and the PandaOps, so shout out to them. Yep, I think that's it.

Ansgar Dietrichs: Nice, thank you very much. Do we have questions, comments? Discussion about any of the content here presented? Otherwise, yeah, you know, you can also take to the chat. Thank you very much. And then we can move on to the next, agenda item. Which is, an update on EIP 8070 progress by BOSUL. If you're on the call.

Bosul Mun: Bye. I'm Basel from CAP. I'd… I'd like to quickly talk about EIP8070, Sparse Poppool. So, I posted a related link to the issue, I will stop. So, in summary, we, got suffered this… EIP's possible pool, and we would like to see this EIP get gets SFI'd in the future, and by that, we mean that, we'd like this to go through the similar process as other EIPs. Like, it's 70, like, getting into the DevNet. So, we could also discuss this when we scope the next DevNet, but…

from our perspective, this is a relatively huge change, especially if you're working on SNAP2, so we first wanted to raise this early and get feedback from other colleagues. So… We implemented a nature prototype, and also documented the complexity we've seen from From guest side, on some security considerations we've identified while prototyping this. So we'd be interested to hear from other client teams, how… what other client teams think about this, and also would like to answer, some questions and help others to understand this AIP better. So, feel free to share thoughts or questions here, or on the document, or we can also set up a call to discuss each other's implementations and shape how to implement this.

Ansgar Dietrichs: Thank you. Yeah, and just to remind people, right, so basically, EIP8070, we… it's one of those, non-protocol change EIPs, but we did decide to CFI it, so it's on the meta EIP for Glamstadam. And so, indeed, it's a really good prompt to ask, basically, how do we tie this into the general fork rollout? So the proposal here is basically to say that we should basically treat it in a similar way to the normal earpiece, and also start introducing it to DevNets, and, basically have it on a track towards SFI. I'm not sure if this is something that people want to discuss now, if there's comments on this. Otherwise, yes, as Brussel was saying, this question can also

be tackled once it's relevant on the DevNet planning side. Maybe just as a quick question, do we have, other clients, clients other than Geth, that already looked into this, have been… have been… Kind of. internally, Boom. Working on this? Yeah, if that's not the case, then I do think this is probably a good prompt for you all to maybe, at next convenience, have a look, and so, so that, yeah, at the next DevNet scoping opportunity.

we can discuss this, I think. Perfect. Then thank you very much, Postal. And then, I think that concludes the Glam Slam topics. Is there anything else, any other Glam Slam-related topic that people want to discuss before we move on to each the headliner? Okay, then let's go. Hey, go to headliner selection. So, just as a reminder, basically, we wanted to make that decision last week, but ended up, because it was very close to… the edge of this decision, that we decided to have one more two-week cycle for people to form a final opinion. Basically, the remaining decision to be made here is, on the EL side, do we want to have a separate headliner? We already have

fossil selected as a cross-layer, but mostly CL-heavy headliner, so the question is, on the EL, will we have, frame transactions, which is the last remaining, headliner candidate? Or will we go into the fog without a headliner? Before we go into this specific discussion, we have a few bullet points to start there, but I just want to remind us that, in principle, if we choose to, not, accept frame transactions as headliner. There is then still also the question of whether we would want to reject it outright, or we could still decide to say we will consider in the future whether to potentially still include this ERP as a non-headliner, and or any other kind of restriction ERPs. So just keep that

in the back of your head for this discussion. To start, we had another breakout about frame transactions, And the headliner process yesterday, do we have anyone on the call who was there yesterday and could give a summary?

Lightclient (Matt Garnett): I don't know if I can give a full summary. There's a lot of, like, little topics that were discussed. I'm sure we can bring some of those up, whoever wants to… mention, but I can quickly kind of update what's happened in the past two weeks. I've sort of said this on all Cardo's testing earlier this week, so I'll be pretty short, but… We spent time and formalized our thinking around the frame transaction mempool. That seemed like a pretty contentious point in the last call, and we wrote a document, which I just pasted in chat, that outlined three different strategies for dealing with the… Frame transaction, then pull? And we also updated the EAP to support Strategy 2, which we felt was a good balance between being relatively straightforward and safe, but also giving a very wide range of capabilities, that we're trying to deliver with the frame transaction.

So, we presented this also yesterday, and I think that there was still some… Questions and concerns about Some of the exact details and machinery. I know that Julio and Ben also have their own proposal now for something that's somewhat related to frame transaction. So if there's not any specific questions on this document, maybe they could talk a bit about what their idea is?

Felix Lange: Maybe just as a quick update from my side, we have also, after a bunch of back and forth internally, added native batching into the proposal, so it, works very naturally with the frames, and basically, just to give a comment on what this means. So, the proposal now includes a facility that allows users to, Mark? adjacent frames as reverting together. And, using this facility, it is possible to, for example, send a transaction that first creates an ERC20, approval, and then uses this approval in the next frame. But if, for some reason, the intended effect of the approval, like how the ERC20, if that fails, how the ERC20 is spent, if that fails, then the approval will also be reverted alongside this action.

And we believe this is a huge step up in the usability. People have been asking a lot about these, batching… Facilities, and there were also other proposals in the past to introduce this, and we are happy that it composes very naturally with the frame transaction, with just a single bet, which can optionally be set on the frame to enable this. So, I think this… for me personally, I'm very excited that we finally found an elegant solution for this problem, and just wanted to give a shout-out to this. Derek was very instrumental in Figuring out the detail for this.

Derek Chiang: Oh, thanks, you know, I think maybe another update I want to give… About the breakout from my perspective was that, I think we are also now working towards addressing another… primary concern that has been expressed by, the high-performance L2s, such as space, as well as, like, some other high-performance EVM chains, which is that, the cost of validating transactions, with firms is now obviously going from constant, right? You know, going from just a signature… going from just a signature check to running EVM code, right? So we are actually, trying to, Essentially have, like, first-class support for pre-compiliers. in the firm's spec, so that, essentially a account will be able to, delegate its validation to pre-compiliers, you know, which have bonded validation cost. The exact mechanism is still to be worked out, and we are, in fact, working closely with

you know, the people who have expressed their concerns, such as, you know, Chris from BASE, as well as, like, Daniel from Monas, to, figure out the mechanism. But I actually, like, actually, like, you know, if you look at, like, the, support for EOH in France, right, like, through the default codes. the pre-compires has already been supported in the default code, you know, so at least for EOS, we already have this, great support for using pre-compires directly for validation, you know, which gives it, both guaranteed security as well as, bonded validation cost, right? You know, so, but… As far as, you know, using pre-compires for valid… as far as using pre-compires for validation for smart contract accounts, that specific mechanism still being worked out, you know, but it is the direction that we are heading towards, you know, because we want to make sure that firms

will work well not just for L1s, but also for other high-performance EVM chains.

Chris Hunter: I can just add, like, a small bit of input, on that, and… for whatever it's worth, like, what… how Bass is thinking right now, like. give… where 8141 is right now, like, I would say, you know, we're not supportive, we are working It seems like it's progressing in the direction… a good direction that we Would be more supportive of, but in its current form, there's… we still have issues with it. And yeah, just for, like, you know, more transparency, given, you know, our performance goals, like, competition, timelines, etc. As it is right now, we do plan on shipping an alternative earlier. This doesn't, like, exclude us from, you know, supporting 8141 in the future, but I just wanted to kind of

Put this out there for, you know, transparency in how we're thinking right now.

Ansgar Dietrichs: Sounds good, that's helpful context. Yeah, then let's… before we go to the open discussion part, about the headliner, two more short agenda points were about friend transactions. One was… from Holger, from the Ethereum.js side about a frame transaction implementation. I'm not sure if, Holger, if you're on the call and wanted to briefly give an update here on the call, or if it was just For people to check out async. Otherwise, I'll just put the… Link in chat. Okay. And people can check that out. And then, as Matt already mentioned, Julio wanted to briefly talk about alternatives to frame transaction, Julio?

Giulio Rebuffo: Okay, so… right, so, So, right, so I… I made this… other proposal, which is not really a… I don't think it should be seen as a compatible for any transactions, by the way, but… I think it's kind of complementary to some things that people are happy with frame transactions, which is mostly the current state of, from what I understand, are verified frames. So, I… I think I want to clear up some things first. Before I get into the AP, I did some stuff on post-quantum. I'd like to keep them off the conversation for now, because there is a bit of contentions there, so I just like to keep them off, but basically. But, this new proposal that me and Ben did, the scheme transaction is, is that… is basically, a more minimal version of what, REF

suggested, last… in, two weeks ago. So, it basically have, have a concept of extensions, which is similar to frames, which, which, you know, it's kept… it's kept for now just abstract, so you can extend, like, the normal, you know, the normal transaction with the more stuff, more fields. In the future, and… and yeah, so basically… and… and the difference is that, instead of having very 5 frames, you have, enshrined signature scheme, essentially, right? So, you essentially remove the bad part… I mean, the bad part from a mempool perspective, and you replace it with something enshrined, which is probably safer to implement. Another thing that actually it allows is that, since it seems, at least to me, that, for example, as Bayes already said, that,

in the current state, frame transactions are not finished. You can probably build frame… verify frames on top of scheme transactions as an extension. Like, you can basically do it async. You don't need to, like, speedrun it for an outliner. So… So yeah, basically, that's the whole reason why I proposed this. Like, it's mostly because, it's mostly because it sounds to me like a safer path towards what… towards frame transactions, if anything, and it's not really a replacement. And you can anyways, async, just do frame transactions as, As they intended, just maybe… just with more calm and less stress on the deadline, and without dealing with the details immediately. Basically. Right. And also, yeah, there is also a note on post-quantum, too, that is super easy to do post-quantum with frame transactions. There is, in the EIP, an example of a post-quantum signature scheme. It's not post-quantum, but basically, it's ephemera ACDSA, just read it, it's like…

Unless… it basically makes it so, in order to to crack your public key, you would need to basically crack it in 12 seconds instead of just having it exposed forever, because it rotates the public keys all the time. It's basically what it does from Miracle Tree. I don't want to go into details, because it would take too much time, but just go read the AP if you're interested. And yeah, so this just… it also makes it super easy. I mean, we could probably ship something post-quantum, too, in Into this pretty easily, in my opinion. That's basically also the reason. I also think, personally, that, and this is just my personal opinion, is that… I guess my main problem with 5 frames is that

I don't really… I think at the end of the day, you will still need to have pre-compass for new authentication methods, so to me, it just sounds like kind of fake abstraction, basically, but that's pretty much only my opinion on that. So yeah, this is basically the proposal. It's just a frame… if anything, it should be seen as a framework For account abstraction, you can build on top of it. basically frame transactions, except verify frames, and then you can do verify frames async in a more targeted and controlled way, basically.

Ansgar Dietrichs: N?

Ben Adams: Yeah, I'd sort of summarize it differently. Friend transactions is very… does have a strong AA focus, and I'd say this is more… changing the four EOAs, so it's changing the transaction So that the… the signature is independent from the transaction blob. And you can change the scheme used to sign the transaction, so you could put a you could use the, R1 curve. Or the pay curve that… We already have us precompiles, or you could bring in, post quantum. And that would… that would just work with the transaction, and then the transac… and it makes the transaction blob itself composable, rather than always adding new fields to it. So you… you say, and… I have blobs in this transaction, so these are the extensions. So you'd say, oh, I have blobs in this transaction, I have 7702,

And it would upgrade 7702 to use Also, the, multiple schemes. And then, so from that, you could add frames as an extension. You could say, I have frames in this transaction.

Ansgar Dietrichs: Julian?

Giulio Rebuffo: I also wanted to say that, if… with this, another good side effect is that you will never probably need a new transaction type, and all you need to find is just, basically. an extension for new… for new use cases in the future. So it's also… going forward, it's also probably less protocol complexity as a whole.

Ansgar Dietrichs: And dental?

Danno Ferrin: So if the goal is to, separate the signature body from the transaction, there's two other EIPs with lower numbers that were submitted first. One of them, CADX separates it in RLP, and then there's another one that Search Budgensen has been working on longer with the PRF team that moves it, over to SSZ encoding. And if we're going to be moving the transaction out, we need to do it in a way Such that stripping out the signature and replacing it with a ZK format, or a reference, is going to be incredibly easy regardless of the content of the body. SSD does this with partial proofs very elegantly, and keeps all the hashes. And the CADX proposal that I have, separates it out into separate RLP forks, and the signature form of the transactions are literally in the transactions, so there's no transaction rewriting.

So, if the goal is just to separate it, there's, I think, more durable and forward-looking solutions, but I don't think we're going to decide on scheme today. Really, we should be talking about frame transaction, and whether it should be the headliner or not.

Ansgar Dietrichs: Yeah, so maybe let me briefly jump in there, because yeah, I agree with what you said there about the decision for today, and just to clarify, so… M… the way I see the decision tree here is that there's no real, option here to even talk about nominating any other variant of a transaction generalization or account abstraction scheme as a headliner. That is just process-wise. Not just process-wise, but also just maturity of these proposals-wise, just not the stage that they're in, and that's not an option. So, I think, basically, the options that we have today are either we are selecting frame transactions as the headline, and of course, that could still mean, I think usually headline champions have quite a bit of leeway to change the nature of the proposal, especially early on into the process. So, for example, there could still be.

significant modifications as part of external feedback into this proposal, but either way, it would still be, in principle, frame transactions selected as the headliner. If we go down and choose no headliner, which would be the only other option available for today. Then in that scenario, we could then later on, as part of the normal EIP process, Or in the next coming weeks and months, basically figure out, are we going to select any The such proposal to be a non-headliner for, H star, that could be frame transactions, that could be any other variant or option, but then that discussion would not be for a decision today. That would… the decision today is exclusively about the headliner status. I hope that

clarifies that, and Tony, you had your hand up for a while?

Toni Wahrstätter: Yeah, thank you. Maybe just to add one more data point to the discussion, because we are very much focused on the different… enabling new types of signatures, but one very interesting data point is That frame transactions is very much generalizable, so you can run arbitrary code in the verify frame, and this also allows a quite cool use case for privacy tools. So, for example, for me as a user of privacy tools, it's always a headache to use relayers that eventually submit your transactions, because otherwise you would lose your privacy. And for the… with using the verify frame, you can basically have the smart verification done within the verify frame. without exposing the sponsor of the transaction to being drained, or anything. And this allows you to then submit withdrawals from a privacy pool without requiring a relayer.

And for users of privacy protocols, this is… this is a great feature, because, as said, this is a… this has been a headache for a while. So, I think people should also consider that. While Julio's proposal is very nice in adding new signature types, the frame transaction proposal might be more generalizable.

Ansgar Dietrichs: Helix?

Felix Lange: Yeah, I wanna also say that I have a couple points. One point is that he… Consider the frame transaction proposal to not be final, and we did not go into this process with the expectation of delivering a final proposal on this day of the decision of the headliner. Rather, we just want to propose this as a direction of work, and we feel like, on the execution layer side. There is capacity to work on account abstraction, and the frame transaction proposal as it is now, is kind of our best shot at account abstraction that enables many different things that we've gone over previously. But, we are also still open to changing it, or… Simplifying the proposal, if clients find it too risky, basically.

Tying it down a bit more in terms of the freedom. So… To that regard, I would just say that This becoming the headliner doesn't mean we have to ship exactly what is proposed, but it's just the start of the Working on it for the next 12 to 14 months to really figure out the shape of it. Yeah. more to what the point of what Tony was saying, also just, these kinds of… this is… and also maybe as a response to the Julia's proposal, The, frame transactions. are not only concerned with enabling signature schemes, but they are more generally concerned with enabling things such as key rotation and post-quantum signatures and all kinds of other things for the accounts themselves.

So, it's, like, in some ways, a more general proposal that goes beyond just abstracting over the transaction signature. Like, there are many other ways to, like, for example, Tony said, Tony now presented an example where if you want to withdraw from a privacy pool, you're not really going to submit a transaction that has this, like. in this, like, classic way, but it works a bit differently. The frames can capture this interaction while a… Regular transaction cannot. And then finally, more toward the point of Or should I say, Julio's proposal. The other thing that we always have to do is that when it comes to enabling the flexibility of signatures, and especially post-quantum signatures, it is not just about enabling

the transaction origin signature, but also more generally, the frame transactions allow the user to break their on-chain computation into what we would call verifications and state-modifying operations. And by enabling this decomposition of the EVM computation, the verification parts when they are broken out of the regular EVM flow, can then be aggregated using CK proofs on-chain. And we feel like this gives us a very comprehensive framework for introducing post-quantum signatures, not just for the transaction origin signature, but also, for example, for signatures which are to be verified by a contract. And, we feel that it's just a bit narrow-minded to only look at the transaction, say, yeah, we have to convert the transaction signature to PQ, and then we're done, because the road to PQ is much longer than that.

And we have to consider all the use cases of elliptic curve cryptography and how they can be migrated on-chain, and that includes things such as use of EasyRecover and contracts, having alternatives to that that are actually workable, even though the signatures are large, and so on. And we feel like with the frame transaction, we actually do have a framework for doing that. So, it's… it's… Just something to consider as well. Anyways, I hope we can come to a good decision today, and, you know, that's it for me.

Ansgar Dietrichs: Thank you. Patasarati?

Parthasarathy Ramanujam: Yeah, hi. Thanks for letting me speak. I mean, I'm, as a team who's been building wallets on Ethereum for 7 years, I just wanted to highlight that, account abstraction or native account abstraction on Ethereum is long overdue. And, we've, the community has debated and deliberated on several options, and we think at least, I can speak as a community member that, Flint's transaction happens to be the most popular, at least among the AA mafia group, when a poll was run. I would like to highlight a concern that if, frame transaction isn't chosen as a headliner. There may be, I mean, the worry is that we may never implement native account abstraction in the near future. So, it is necessary, at least, I mean, as a team.

building on Ethereum that we would, like the core developers to choose this as a headliner core headquarter. Thank you.

Ansgar Dietrichs: Thank you. Vitalik?

Vitalik Buterin: Yes, thank you. So, I, wanted to, just, kind of give, again, a, kind of high-level philosophical perspective on the, the thinking behind, frame transactions, right? Basically, you know, there's, There's a doc that I published on the AA Mafia months ago, and I, you know, would definitely appreciate if someone digs it up that kind of goes step-by-step and shows how it's the most natural thing that, satisfies, my… Basically, yeah, all of the use cases that we've, figured out in, essentially, the last 12 years of accounting. abstraction research, but in general, right, the, yeah, idea, the… The problem is that any… substantially released.

Simpler proposal is… inevitably going to leave a lot of things out, right? So, like, for example, any proposal that depends on a, will inevitably leave out multisig, it will inevitably, by default, leave out key changes. It will leave out multisig that mix and matches, different signature schemes. It will, by default, leave out, like, post assertions, like, what Frederick mentioned in the chat, will leave out sponsored transactions, and, it will, leave out private account abstraction. And so, basically, yeah, inevitably, any proposal that is sort of much simpler than, what FrameTransactions already is, is, so… one that is not going to be able to cover those use cases, right? And so, essentially, yeah. like, this, this is the, yeah, the reason why frames is…

what it is, right? And so, the… if you make an incompatible proposal that, does not, that I, doesn't sort of very naturally extend into into frames, which would probably basically just look like frames on what the frames are, then essentially three years from now, it polluting the protocol that we need, right? And, also. The other important point here is, that, all of the… from what I can tell, all of these simpler proposals can be implemented, like, can be expressed as a subset of, 8141, and in a couple of cases, 8141 plus a couple of, of other small, very small EIPs. Right? And so, the, like, the core philosophy here is basically that, like, actually, yes, you know, we can make the mempool very restrictive. We, I, like, I personally think it's totally okay to have the mempool be something that, like, if desired, for example.

only, like, even goes even more restrictive than, the, yeah, than the current proposal, and even says, like, okay, like, we do just, K1, R1, and a post-quantum scheme, and, support sponsored transactions, for example. And then… But then, the key thing that we get is basically that other people that all core devs never has to care about or hear from ever again have their own corner to, work on an alternative mempool, and, like, basically, yeah, start with 7562, or potentially start with, even, like. even newer ideas that come, and, work on being able to support all of these more complex use cases. And the, mempool, and then the pri… the prime… always has an optionality to add in

Some, support for more things, or even just… At the end of the… yeah, in June. the universal mount ball in its entirety at any point in the future without a hard fork, right? And so, like, the core idea, basically, is that the, in protocol, aspect of this, or the in-protocol part of this, is a part that's quite small in terms of spec lines of code, right? The bulk of the… the great bulk of the complexity is in… So, what we can do is we can say, well, we have a much more restrictive forward. The… basically, there is a free market, and all of this continued development of better rule sets can happen on the outside. Things like working on, supporting privacy protocols and enabling privacy protocols to be intermediary-free, which is, like, a personal passion for mine, because, like, the intermediaries

of actual… existing privacy protocols are just a thing that always breaks for me. So, basically, you support both, right? And, you can support all of these, use… simpler use cases in a way that, is, very simple, very low on gas, and where there's, a way to do frames that even makes it easy EM Freedom, and that's all part of the proposal, and then at the same time. all of these other things happen. So, that's kind of the high-level view for, like, why, yeah, this design has been… builds the way it is, and why I think it can, satisfy both, kind of, very conservative near-term use cases at a high level of. Efficiency, and at the same time, immediately, yeah, open up space for adding…

Ansgar Dietrichs: So, just Vitalik, just to double-check that I understand, basically, would it be fair to summarize your point as saying that, basically, you would argue we should still do frame transactions, but you'd be very open to being very, very pragmatic about the short-term mempool site implementation, so that the actual Limitation complexity is low, and people can still get what they basically would want with all these other paths out of it in the short term.

Vitalik Buterin: Yes.

Ansgar Dietrichs: Sounds good. Yeah, I think that's, in general a reasonable argument. Julio?

Giulio Rebuffo: Yeah, I just wanted to say that you can extend scheme to be, like, frames with an extension, but especially with verify frames in the future, it's just that it just allows you not to, maybe you cannot do everything in one go, basically, but yeah, that's pretty much it. I mean, it's not really only the signature scheme, you can abstract that as well with just simply an extension. So… You can get there, still with schemed. It's not like it locks you away from frame transactions. Actually, you can basically implement it on top of it, just in a more controlled way, at least regarding verification frames.

Ansgar Dietrichs: Right.

Vitalik Buterin: I guess I would just say, like, I just don't really just see in what sense, you know, like, frames are kind of uncontrolled, right? Because, like, you can have transactions that just are one verify frame followed by an execute frame, and it's equivalent. Basically. clear. Equivalent to a scheme that is… verification-specific, right? And so, you know, the argument I would make is based only, allowing transaction, transactions of that type. And, like, functionality-wise, it's, kind of equivalent, like, you can, you can see the one-to-one correspondence from one thing to another thing, and, like, effectively your GET schemes.

Ansgar Dietrichs: Yeah, so maybe one way of presenting this question, or, like, the decision we have to make today, is that you can… you can think of, like, we want to make transactions more general, and you can basically think of it as the element of it that's the… generalizing the execution flow and execution logic, and then it's about generalizing the verification flow. And so we could do something that's inspired by, you know, some of what Julius is saying, by just basically trying to make the execution flow more general now. But keeping the verification flow as is, but the point is that with native con abstraction and with post-quantum, we will eventually have to tackle the verification flow anyway, so the question is basically, the decision for Prime Transaction as headliner today would mean that we will tackle

also generalizing the verification flow, at least from the in-protocol side, already in HSTAR. And then we can restrict it down from the mempool, keeping it simple there. The alternative would be to basically say, no, we don't do this hard fork, we wait for another hard fork. I do think people have brought up in the past that, like, future hardcore folks might be more cramped on the EL side, so it might actually not be so easy to find another opportunity to then tackle this part, and we will have a somewhat of a time pressure because of post-quantum. But yeah, so I think kind of like that is. So indeed, I don't think, Julie, I don't think, basically, like, saying… doing something that's more like your proposal, I don't think it would prevent us from, in the future, going into the direction of frames.

But I don't think it would yet give us the core that we will have to at some point do. If that makes sense. Derek, if you end up?

Derek Chiang: Oh, yeah, you know, I think I just wanted to, I guess, emphasize, like, a specific point. You know, I think… I think, like, most of the debates that, I guess, between firms and, like, some alternative, you know, and most other alternative proposals, essentially just comes down to whether people believe that verification should be done through EVM code. all should be essentially enshrined into the protocol, for example, through precompiles, right? You know, so for example, if you look at skin transactions, if you look at, like, the earlier EIPs, like the composable transactions, or the… the, I think it's, like, 8164, like, the passkey, transactions. You know, they, they, you know, so, you know, they, they, they, they all believe that, it's, I guess, like, dangerous, or, like, you know, it would complicate the manpool to do the verification with, EVM code, right?

You know, so, you know, which is why they opt to do the validation through precompiliers. So, but I just want to point out that, like, actually, we don't have the troops, right? You know, so firm transactions. as I mentioned in the beginning of the call, it's the only proposal that gives you the options, right? You know, so, you have the full option to fall back to EVM code validation if you choose to. But it also has first-class supports for using pre-compires to handle the validation, if you prefer to have to let the protocol handle the security, right? So I just wanted to say that, like, just from the perspective of, like. giving people more options, right? You know, you know, I sort of, you know, I sort of think of firms as superset of

the other proposals, you know, so, so, so to be… yeah, yeah, so, so, so I think, like, that's why I think firms aligns better with. the broader Ethereum, philosophy of, like, just, you know, being, you know, allowing permissionless innovation, giving people their options, you know, and, you know, so, so I think my firm is, it's really, like, really the only proposal that satisfies the needs of. Both camps, when it comes to how validation should be handled.

Ansgar Dietrichs: Sounds good. Before we, Amit, before we continue the discussion, I just wanted to briefly, take a moment, like, we are now one hour already into the call, we need to make the decision today. Maybe now would be a good time to just briefly check in with clients to hear… where the thinking is at? Are they still basically undecided? Are they decided? Is… is it even an option still that we might select frame transactions as the headliner today? I'd briefly make… want to make the rounds with clients, and then we can come keep… we can go back to open discussion. If that's okay with you, Ahmed. So then I'd briefly, yeah, call on the clients, like, Geth, could you briefly give an update on your position?

Felix Lange: Yeah, so we want the frame transaction.

Ansgar Dietrichs: Yeah, I guess this is not so surprising. Never mind.

Łukasz Rozmej: I think we… have… Bigger dubs that we wouldn't call… definitely don't want to call it a headliner at the moment.

Ansgar Dietrichs: Ben, I guess you wanted to add something from that other mindset? He's still muted.

Ben Adams: Oh, sorry. I'd just like to add that we're, happy to work on it. Separately, do a kurtosis, and, you know, firm up. Permidopmo.

Ansgar Dietrichs: Sounds good, so you're open to it, but prefer to not have it be a headliner. Aragon?

Giulio Rebuffo: We… I think we basically went from plant-sided, basically. Probably is like to know.

Ansgar Dietrichs: Okay. It's like, no, but open to it still?

Andrew Ashikhmin: Yeah, I guess we are divided, so some of us are actually in favor of framed transactions, but I think Julio's proposal is also a good stepping stone.

Ansgar Dietrichs: Sound good, peso?

Daniel Lehrner: Yeah, we, we still also figure, no headliner for Hagota. And the team has concerns about, complexity, basically, of a firm transaction. We think it's too complex. For… for what it delivers in the end.

Ansgar Dietrichs: Okay, and, breath?

emma (reth): Hey, yeah, we are unknown.

Ansgar Dietrichs: Makes sense. And any of, the newer EL-side clients, so Nimbus, EL, or Erigon?

Iván | ethrex: On the Athrex side, we are in favor of the EAP.

Ansgar Dietrichs: Okay, yeah, so it does sound like… they're still… we're still leaning towards NOA. I mean, we can go back into open discussion for a little bit. I… my impression is that, actually, maybe a not-so-unlikely outcome would be to reject it today as headliner, but still work towards selection as non-headliner. Seems like a lot of clients are at the edge of being convinced they just need more time. So it might actually be a not-so-unrealistic outcome to just ship it in the end as a non-headliner, but, yeah, for today's discussion, I think we should, yeah. For now, just deal with the question of… Do we want to select it as a headliner or no? Right now, we don't have enough client support to select it, so we can have another round of comments, and then see if we're ready to, like, make a decision.

Ahmed, you have your hand up?

Ahmed Al-Balaghi: Yeah, no, thanks for that. It's great to, to hear everyone's opinion on this. So, I think a lot of the arguments, that was presented, sort of, full frame transactions, already been sort of discussed, and don't want to repeat those, but I just want to say generally, like, I think as an ecosystem, we kind of have to, you know, push hard and through, even though some things look a bit complex. I mean, You know, the… like, we've been doing a counter strategy for a long time. We've now been working a lot on orchestration, and we're kind of seeing… first-hand from the ecosystem, like, what they want, you know, they want things, you know, from the EOAs, they want things, you know, directly where the users come from, and so I think if we…

were to delay this, it would set Ethereum back quite a lot, and I don't think all of us are in this, Yeah, we're not… I don't think we're incentivized for this to sort of see this happen, so I think we're… all wanting Ethereum to win, and for that to happen, we really need the UX to be way better. We need, native AA, because otherwise the current solutions that exist are just… You know, I don't think they're… they're perfect, you know, not many projects want to use AA, you know, in the way they are right now. Yeah, I just think, you know, as an ecosystem, we have to push hard and push through, to be honest.

Because there's so many, so many awesome things that we could do on the UX level from frame transactions. We already have a couple of ideas, we're already experimenting on them as well, and there's so many, like, use cases on the privacy side, and also, yeah, I think there's going to be a lot of innovation that will come from this. So, yeah, I think… Just something for the, client teams to sort of reconsider, I think.

Ansgar Dietrichs: And Nico?

Nicolas Consigny: Yep, I think it would be also good to hear some opinions from other L2s. I see some people from OP Labs From Arbitrum. Mark from Optimism has been very supportive publicly of Primes. I would be interested to hear Arbitrum's opinion, too. Most of the, like, as Ahmed just said, most of the AA builders want to see things, moving in the direction of native AA. We've been looking at it for a while, so yeah, it would be super interesting to take everyone's input in this process, and so, like, if I can give the mic to some of the L2s that didn't speak yet. I think Lumi was here, and probably other people from Obi Labs. Would be good to have your opinions, too.

Ansgar Dietrichs: Yeah, so if any of the L2s want to raise their hands, feel free to join the… the queue, I won't fast-track you, I think it makes sense, though, just, just go one by one. So, next up is Julio.

Giulio Rebuffo: Yeah, I just… I just wanted… I just wanted to say that, But yeah, I mean, you can… you can probab… I mean, if you… and I don't want to… to say the same, but if you go for… but if you go for scheme, you can do probably very 5 frames as their own thing, as another liner in Nagota. Pretty… probably in a more controlled way, and you could still ship them. And, you know, if you ship many things at the same time, I think there are so many unknowns that people are not really that willing to implement them, that's all. Like, I think… I think it's just… yeah. That's what I wanted to say. You can still do it that way, probably.

Ansgar Dietrichs: Sinclot, Lumi?

Lumi | Offchain Labs: So, we have a little bit of mixed feelings, In a way, frame transactions seems like it's a really good solution for L1. One of the things that we're concerned about… we tried to form an official stance for this call, but we couldn't get to it. There are some concerns that we have, which is we're really targeting very, very low block times and very high throughput transactions, so… we could choose certain, you know, quote-unquote transaction types that would be allowed, but then the concern around there is if every L2 supports different transaction types, that creates fragmentation in the ecosystem. For wallets for… for applications, so… We don't have a official stance on this, we have a little bit of mixed feelings, but some of the directions that 8141 has been going in are definitely promising. And obviously, for off-chain labs, we have zero dev, and Derek is helping define the standard, so…

That's what I can add from my side.

Ansgar Dietrichs: Thank you, and Josh?

Josh | OP Labs: Yeah, thanks. I think, just… I'll just echo something that, LightClain mentioned in the chat. Which I think is a promising compromise here. I think we're in a similar position to many folks on this call, like. native AA is, something that's definitely, promising and something that we'd like to see, but obviously there are multiple proposals on the table, and at this time, it's difficult to definitively say which one would be best long-term. So I think White Client's proposal for maybe a compromise here of saying that account abstraction as a feature is the headliner, but the details are worked out over time. To me, that sounds like a promising option. I'm curious to hear what client teams think about that.

Ansgar Dietrichs: So, just process, I mean, look, I'm just a coordinator, of course, ultimately, I'm willing to facilitate any decision whatsoever. I… my understanding of the process would be that basically, I think there might have been an option to select something that's more like a theme as headliner, not a specific proposal, but that would have still had to go through the flow, have been proposed in time, all these kind of things. that did not happen. I think it would be reasonable to say, for example, select frame transactions with the specific Expression of, from the, from the… proposal champions from Matt and Felix to be flexible and possibly swap out the specifics of the proposal for a different version if the majority of people were to do that, so I think

That part, I think, would be fine, but I think completely switching over to a different headliner that has not been in the pipeline, I personally think is… just too late into the process, given that it's literally the call now that we want to make that decision. Of course, if everyone wants… strongly wants to go with that direction, I'm happy to be overruled here. But it doesn't feel like it's in the scope of what we should be able to do, process-wise. Ben?

Ben Adams: I don't… I don't think a theme would help, because… We're… we're trying to put something firm into the… the plan, and we're saying, oh, we'll put something vague in. It's not… it's not really… Yeah, and one of the issues with, friend transaction is that isn't firm, so we've, like, rejected encrypted mempools for not… being fully designed. Equally. But… so I… what I would prefer is if we CFI'd it as a regular EIP, then explored it through implementation, firmed up the design that way, rather than as a headliner. Because the headliner is more, this is what we are shipping in the fork, we halt the fork until it ships, and I don't think Where I don't think it's… At the moment.

Ansgar Dietrichs: Yeah, I think something like this could be very reasonable. I'm not sure we would have to make that CFI decision today, but, yeah, I think, in general, that's a reasonable proposal.

Lightclient (Matt Garnett): I just want to add something quickly, just to respond to that. Like, I think, yes, you know, frame transaction is continuing to evolve and change, but I do want to point out that AA is a little bit different than some of the other protocol-level EIPs that we might see, or we might say aren't firm. because there are so many different parties that are affected by AA, it's extremely difficult to ever reach a point where It is in a very firm state. Because there's always new people coming, new wallets, new chains, Coming with different needs. And there's not really, like, a perfect solution. We saw this with 3074 and 7702, you see this with 4337. Like, AA is a very hard problem to solve, and it's about finding the best compromise across, like, a bunch of different moving pieces.

And I just want to, like, push back a little bit, like, I think the frame transaction standard is quite solid, and built on a lot of you know, in-production ideas with 4337. So, it's not like it's coming from nowhere. We're just trying to find the perfect solution to fit all of the different needs of the people and the protocols. And so, yes, like, these things will continue to change over time. I don't really expect that we'll ever reach a point where everyone is totally happy with how Framed is going to be.

Ansgar Dietrichs: Okay, and Andrew?

Andrew Ashikhmin: Yeah, I think, we should be… more ambitious, and if you look at this draw map, if we, like, if we keep, postponing doing hard things because they're hard, then we will never reach even a half of the straw map, so I think we should be more ambitious and do the hard things, not because they're easy, but because they're hard, but they are also that they'll bring Ethereum forward. So, I personally am in favor of frame transactions, and I think if… I'm also happy to have account abstraction as a general theme for Higata. I also think, if you look at the straw map, there are Actually, there is a stream of work related to mempools. There are encrypted mempools, and I think that encrypted mempools are crucial for Ethereum maturity if you want to, like, to prevent front running, and we need to prevent front running, like, for

Like, any serious corporate use. then we need something like encrypted memposts. So, we just need to bite the bullet and accept that we do need to work on our mempulse. And it will be, like, yeah, it's a big chunk of work. But I think it has to be done.

Ansgar Dietrichs: And Nixon?

Nixo: Just on process, I'm unopinionated whether this is going to be a headliner or a non-headliner, But I just want to say that we shouldn't lose the forest for the trees here. We don't need to be a slave to process. The process that was proposed last year as the headliner process was more to be descriptive and helpful and clarify to outsiders what this process was. I think that if we have a quorum on ACD, which is the point of ACD, We can decide to do something like put a general idea in place of a specific proposal, if that specific proposal is willing to cede to the general idea and make compromises with other proposals to get the best possible proposal.

Ansgar Dietrichs: Yeah, I don't think that's entirely unreasonable, although I do think with… if you want to basically make exceptional decisions like that, then I think at least it needs to be a unanimous decision amongst clients. I don't think we can make this, have the same threshold for decision as a normal process decision, so if all the clients indeed were to agree with that approach, I think that's a reasonable thing to do.

Pedro: I think sometimes we're trying to decide whether the AA is the headliner, or whether it's an 8141. I think the biggest challenge with all AA solutions in the past has been that We cannot find an ideal solution, therefore we never have one. And this kind of just puts more and more pressure into the AA teams to have to do everything themselves. Like, frame transactions is not perfect, but there will never be a perfect AA solution. The fact that there is even one AA solution as ambitious as this. included as a headliner was perhaps the most hopeful news I've ever had in the 8 years of history that I participated in Ethereum. And I would be very, disappointed to see this downgraded into something that is not a firm decision, because we can continue to improve

you've seen the improvements that happened just the last two weeks for the EIP, with the EOA support, mempool policies, atomic batching. like, we're… we're really seeing a monumental change for AA, and we can challenge whether that is a good EIP, but not having this as a headliner, I think it's a problem.

Ansgar Dietrichs: And, Lumi, and then afterwards, I think, because we'll only have 10 minutes left, yeah, we'll bring it in and have a discussion about the concrete decision. Salute me?

Lumi | Offchain Labs: I would just echo what you said in the comments of, what we can do is reject it as a headline or frame transactions, but we should commit to all core devs prioritizing AA work. Like, AA is probably, arguably, the single most important user-facing upgrade that we should do. we are gonna start seeing fragmentation between L2s, regardless of which native AA approach we go to, because every L2 team is prioritizing native AAA and user experience, so… we really should work on it now, and I'm personally worried that if we don't work on it now, it's gonna slip after ZKEVM and a bunch of really big projects. Like, this needs to be a priority. Like, we hear this every day from users, from enterprises, maybe more than all core devs, like, this is the single most important user experience choice.

Ansgar Dietrichs: Yeah, thank you. And just as a quick personal comment, I was part of the group that brought EIP 2938, which is actually relatively similar to frame transactions, to Occo Devs back in 2020, and back then it was the… the decision was, oh, sorry, London. is already getting quite full, and we are too close to the merge, so there's just no time. And ever since, I think account obstruction has always been just barely beyond the horizon of important enough to prioritize it. I personally would enjoy and appreciate seeing all code devs prioritizing this topic for HDAR in some form or another, either as a… with a specific headliner, or with a general headliner, or just without a headliner, but with a commitment that we will prioritize the topic in the general EAP section.

I feel like it's… the time has come, and we do see a lot of user interest and demand here. Ben, if you want to have a quick comment, then otherwise, afterwards, I'll start talking about concrete decisions.

Ben Adams: I'm okay with prioritizing it, but I'm just saying, if… if we say AI is the headliner, the implication is that we do not ship HDAR until A solution is implemented. That's the… that would be the theme of what a headliner means.

Ansgar Dietrichs: Yes, I think that is a good…

Barnabas Busa: window.

Ansgar Dietrichs: None of us?

Barnabas Busa: We do need a user experience win, though. I think we should be, holding off each store for this.

Ansgar Dietrichs: Right. So yeah, I think… I mean, Ben, I think the comment is valid, so I don't think we should make this decision lightly, but I do think, you know, as Barnabas is saying, it might just be worth saying, yes, this is a commitment, we will take out… we will take the time that's necessary, and we will have this as a priority. Knowing that this is a cost we're paying here, it's not free, but it's worth it, basically. So then… I think the two decisions, basically, that I think then we make in sequence here is, one, we can still talk about do we want to just accept frame transactions as is, as a headline-up, with, of course, option to still adjust the proposal down the road. If we decide to reject it, then I think the follow-on question is, do we want to officially

prioritize just account abstraction as a general theme, as the EL headliner for the fork. Yeah, so let's start with the question of, do we want to did clients… hearing all of this over the last few minutes, did clients change their minds? Is there enough of a momentum for frame transactions specifically? I guess, question to, mostly to… Nethermind and, peso? I would assume his clients may be closest to changing their minds?

Daniel Lehrner: No, from Besto, we still prefer no headliner. I mean, we can… Half-frame transaction maybe later, but… I would not like to commit to, like, a blank check saying AA as a headliner. Because I don't even know what this means, and how, when we would ship. So, I mean, we can do this… as EIPs, but I would not do it as a headline.

Ansgar Dietrichs: Okay, well, that already kind of answered the second question as well, but, like, let's first… yeah, let's first… finish the discussion on… on frame transactions. Nethermite, I assume you… like, did you change your mind on… on frame transactions?

Łukasz Rozmej: So, I don't know what the rest of the team thinks, right? So, we haven't time any to discuss. My personal opinion has not changed. I would like to experiment with it and proceed with it, but I wouldn't put it as a headliner.

Ansgar Dietrichs: Okay. Then, I think, in terms of decision for today, it seems that frame transactions specifically just does not have enough support among clients to be selected as a headliner, so then I propose it is… rejected without changing the status of the ERP itself. I think the ERP should still be considered, PFI'd. Normally, we DFID headline ERPs if it's clear that they have no room outside of the headline status, but in this case, I think it makes no sense, so I think the decision would just be to Declined the headline status for the specific ERP. Is there any last? Protest against that decision? Okay, then I think that decision is made, and then the question is still, I… I'm open to saying we, last minute, select

account abstraction more generally as a headliner for the EL for H-star. It now already sounded like Besu was very skeptical about the idea. I do want to briefly open this up, maybe have a discussion just among client teams, because we only have a few minutes. Do we have other client team opinions on this approach, selecting account abstraction as a headliner?

Lightclient (Matt Garnett): I think death supports this.

Ansgar Dietrichs: Never mind, do we have an opinion?

Łukasz Rozmej: I don't have an opinion, like, without specifying the AP, it's pretty vague, so I don't know what it means.

Alexey Osipov: I think it's, Maybe choosing or not choosing headliner affects only one thing is, kind of motivation. To, commit and implement this, but if we find, that it is not a good approach, and other Strategies are better, like, let's keep… schema thing from Guido. We can switch and decline the… this approach of rent transactions. I mean… Maybe it's a good thing to… Confirm its, headliner just to, to make it, Like… To make people more motivated, to be more focused. Because… Like, reality, after all, will resolve whether we will use them or not.

We need more testing, it's a very complicated thing, we need to play with it, and we will do it initially, but it will be headliner or not. So, not a big deal.

Ansgar Dietrichs: Right. But, so… I… feel strongly that we could be so… in terms, we need to make a decision today. Like, I see a lot of support for the idea of 94A as a headliner in chat. However, so far, the process is that headliners and these types of decisions are ultimately client decisions, and that community input, while I personally find it very valuable, I know that many quad apps do find it very valuable, but it is, has the role of informing client decisions, given that we are considering just deviating from process here by selecting something that was not in discussion until today. I would really only do this if there was very strong client support. We have several clients

opposed to, or skeptical to NativeA as a headliner theme, so I just don't think, process-wise, we have a basis to select NativeA more generally as a headliner theme. So I would… I do think we should probably, as Orcher devs more generally say, that clearly we signal the intention to prioritize NativeA as a theme. But that is separate from headliner status, so it's not a headliner commitment, but we just selected… we just… we just commit to prioritizing that exploration and trying to fast track any AP, but it does not come with the headliner. commitment level. Does anyone want to…

Felix Lange: So it's like this…

Ansgar Dietrichs: Jake? Felix? Did you want to say something, Felix?

Felix Lange: Yeah, I was asking, so this is like a CFI+, or…

Ansgar Dietrichs: No, it's nothing, like, there's no… like, my point is that there's no decision today, no official… no official decision in any form. Like, the decisions are to reject the headliner, and so we will just not have an EL headliner. Again, I'm very sympathetic myself to the enthusiasm towards Native A, and I hope we can do something in the heartfork, I just don't see a basis for a decision here, other than what I just said. Again, if people want to speak up, we have a Zoom user that wants to say something.

Zoom user: Sorry, I didn't share my name. Antonio here. Sorry, Antonio. Just about, like, a quick comment, you know, since, like, I understood, like, that there is no strong support for a print transaction, this is okay, and it was, like, this alternate proposal today by Julio. I was wondering if there is still the chance to… have two more weeks to, like, so making… having people chew over these two alternatives. I don't know how late we are in the process. But given there is, like, this big uncertainty, and the topic is so important, I don't think that two more weeks will change too much. But the headliner, if we can have two more weeks to have more people, like, discuss.

Because I think, like, a kind of abstraction is… not the kind of abstraction is really an important topic for… for the future of the protocol, so it might justify, in my opinion, two more weeks to take a final decision about headline or not, and not closing the discussion today. Just my two sense.

Ansgar Dietrichs: So, given that we already made an exceptional decision to move the deadline by 2 weeks, and that enough was not enough to actually come to a different decision, I think at some point it is also not respectful towards the clients' teams that, do Want to oppose this, to keep just not acknowledging their decision here. So I… yeah, I don't think… delaying, again, two weeks is a reasonable option, unfortunately. Banavas?

Barnabas Busa: So, in previous workload devs, the Pandops team has never really spoken up, pro or con, a specific EIP, whether we want it in or not. our voices usually try to be as neutral as possible, and I'm not really speaking on behalf of all the Pandas, but, from my personal point of view, if we are also considered to be, part of the all core devs, and whether we have a decision or not, I would actually be for frame transactions as a headliner. And, maybe my opinion, we'll actually balance it out and push it through to be an actual headliner. I'm not sure how the other panelists feel, I can ask their opinion as well, and Because I know that you're looking for a majority of clients. I know that we don't consider it to be a client, but

So I feel like we are, part of the Occord Devs process as a whole.

Ansgar Dietrichs: But… Yeah, thank you for this. So, I mean, look, I do acknowledge that there clearly is a lot of, disagreements around this topic, so I think the best path forward here, and we are also at time, so I think my proposal is as follows. We kind of already just now said we made the decision to reject frame transactions as a headline. And of course, all code apps can always, in exceptional circumstances, revisit prior decisions. They're never final until they ship to chain, so if in two weeks, for some reason, we want to revisit the decision and undo it and change it, that is fine. Same thing with selecting a more general theme. I think the decision today is to not select a more general theme either, and given that we decided today was the deadline day for this decision, that would normally mean

This is done, and two weeks from now, there's not going to be an opportunity anymore to select the headliner. If, asynchronously, between now and two weeks from now, people come to a stronger shared understanding that this situation is exceptional enough to require an amendment to normal processes, and we should go in a different direction, I'm totally fine with that, and I think we should listen to that. M… I… yes, but I don't think today, synchronously on this call, we have a basis for any other decision. Does that seem reasonable? Again, I think it's totally fine if we want to decide to make exceptional process amendments, but I don't think we can do this live on the call now.

so… Yeah, I don't… No… I mean, maybe, yes, I would now restrict… contributions to only clients, just to… just for the formal decisions here. Ben?

Ben Adams: Are we okay to accept that, say, in 5 to… You know, 4 or 5 months after we've explored it a bit more. with an implementation, firmed up the specs, that we could revisit it as I had both.

Ansgar Dietrichs: That would be up for group decision. I… that would require some more meaningful adjustment to a process, but I'm not sure why we could not do that, but we would then have to be intentional about it.

Ben Adams: Yeah, that's why I'm raising it.

Ansgar Dietrichs: Sure. I mean, I do think it does seem like, even though there's a lot of disagreement here on, like, the specific status and process and all these things, it seems like there's overall agreement that Account obstruction is something that is important, that needs attention. I do think it will receive that attention now. Everyone here wants to work on a resolution, so that's good. That, I think, is the kind of informal takeaway from today's call. EL-wise, post-Glamsadam, the focus is, mindshare-wise, on a card abstraction, and then we will have to revisit at a later time what that specifically means, whether that just means selecting a non-headliner EIP, that would be the default path here. Or do we want to exceptionally make a different decision down the road? We can do that, but we will consider this carefully, and not just make a snap decision now.

Is that… and that does… that also means we're not specifically assigning, like. frame transactions will remain PFI'd for now, until we make a specific other decision. Does that sound as a reason… is that a reasonable compromise to leave the call at for now, and end it? We're already 5 minutes over time.

Lightclient (Matt Garnett): I feel like we should at least have it as CFI. I don't know if any clients would be against making that decision now.

Ansgar Dietrichs: You mean frame transactions specifically, CFI? I feel like we have clients that specifically even opposed it as, just in general, to do at all in Ethereum.

Barnabas Busa: Too many clients, so…

Lightclient (Matt Garnett): pose… Yeah, any clients oppose making it CFI? I thought I saw most people saying CFI is okay.

Ansgar Dietrichs: Can we just have that discussion in two weeks? I don't think. Quite now. We don't… I mean, you know, we're 5 minutes over, but we didn't have time to…

Lightclient (Matt Garnett): I think.

Ansgar Dietrichs: If you get an act from every single… Look, okay, Matt, this is your section. If you get an act from every single client, it's CFI'd.

Lightclient (Matt Garnett): Another mine?

Ben Adams: Yeah, we wouldn't object in a precedent kind of a setless fossil. They're, like, early CFI, so…

Lightclient (Matt Garnett): Yep. Julio? Or Aragon?

Giulio Rebuffo: Fine. That's fine to cheer fight.

Lightclient (Matt Garnett): Hey, Sue?

Daniel Lehrner: Yeah, I think they're fine with CFO.

Lightclient (Matt Garnett): Russ?

emma (reth): Yeah, we won't block it. That's cool.

Ansgar Dietrichs: Okay?

Lightclient (Matt Garnett): Ship it?

Ansgar Dietrichs: Then we… CFI frame transactions. And by that, that's the last decision for today. Thank you, everyone. This was a hard one, but I do think, again, overall, focus on account abstraction, I think it's… it's about time, so… Yeah. Thank you, everyone, and talk to you in two weeks. Oh, one last notice, just for my side, I will have Nixu fill in for me in two weeks, so Nixu will lead our good lives in two weeks, and I might still be able to be on the call for some portion of it, but, yeah. Thank you, Nixa, for… for doing that. Awesome. See y'all in two weeks. Bye.

Marius van der Wijden: Confused.

Alex Stokes: Goodbye.

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