Akash Kshirsagar: Core Devs 233, we're really getting quite high into these numbers. ⁓ We have a couple of things today on the agenda, first about Glamstradam and then ⁓ about our, hopefully, well, not hopefully, about wrapping up the Hegotah headliner discussion. So starting with Glamstradam first, ⁓ first general call for DevNet updates. Do we have any updates about the current ongoing DevNet efforts? Yeah, sure. I can give a quick update. Just a quick update on DevNet too. It's going pretty well. ⁓ We had one issue with Etherex where they were creating too many transactions, too many peer-to-peer connections, but otherwise it's been going pretty well. And DevNet three 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 file.definite3. ⁓ And then I'll do mixed networks. And once that runs decently stable, I will launch ⁓ Definite3, I hope, beginning next week. I can also give an update on APPS DevNet. It's not looking good. So, the drivers have broken the DevNet and we have decided to basically give it a few days and launch with DevNet 1 with the new PTC changes that we have agreed on on SCDP. Initially, think Prism will be the first one that will be ready and then I'm planning to launch a network with only Prism. And as the clients are finishing their implementation, then I can start onboarding them. Sounds good. And is there anything from the EL side that people should pay attention to specifically? For EPBS optionally if you are bored you can create an EPBS.net branch for us and we could onboard your client. If you need some explanation what you need to do to be onboarded just reach out. 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 student item, is, I think Marius and Butta wanted to give an update on the benchmarking progress so far. Are you two on the call? And you want to go out with that? I'm here. Let me share my screen. I hope you guys can see my screen now. We can. 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 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 running below this threshold and which tests are running above this threshold. If you remember from my last presentation on, I think, two or three ACDS ago, the plan, or our plan right now is to make sure that everything runs at 60 megagas per second. which would be really, really cool. by default, this tool is put into, ⁓ it puts the threshold at 60 megahertz per second. As you can see on this run, there are only four tests that would be less than 60 megahertz per second. Most of them are higher. ⁓ Benchmark Core is available to people who ask. 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 it. ⁓ We have several benchmarking suites. We have the compute tests for 7.9.04. Those are around 5,000 tests. And we have the stateful tests. There are around 3,000 tests. they cover all of the outcodes 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 Benchmark Core where you can do the diff between two runs to see if they improved or ⁓ not improved. And what we can see is roughly 3x improvement ⁓ through dials ⁓ on most compute tests ⁓ on a four core CPU. So this is roughly in line with with what we've expected the gains from BALS to be. ⁓ Now to the EAPs. EAP 8037, the state creation ⁓ change is included in the definite three spec. ⁓ All clients have implemented it. And we have a pretty comprehensive test suite from execution spec tests. One problem 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 them depending on the block gas limit. We have EAP 7976, the cold data flow increase, which increases the cold data gas flow to 6464. This allows us to raise the max gas per block from roughly 155 million gas to around 670 million gas, which would be really, really nice. We made some analysis and roughly only 1.5 percent 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. ⁓ EAP 7981 increased the list gas cost. ⁓ Yeah, we used the excess list size in the 7976 calculation. So what I just talked about previously. Otherwise, these excess 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 step net. Change is very, very small. ⁓ But yeah, it will get rid of this edge case where people just put a lot of core data or a lot of access lists and blow the block that way, ⁓ which helps us to scale. Then we have the 7904 computer repricings. These are very preliminary numbers. But as I said in the beginning, our goal is still to ⁓ to arrive at a 60 mega gas 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, be like we might be able to just optimize it in certain implementations, like for example, the catcher code. opcode is in the second worst implementation, it's at 70 megahertz, so it would pass, but in the BISO 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 do other than repricing. Yeah, we are in contact with clients in order to see if they can improve these opcodes. ⁓ Yes, EIP 8038. The state access repricing. ⁓ Unfortunately, we have ⁓ less data on state access than we have on compute repricings, because compute repricings are very easy to ⁓ do. state access repricings are a bit harder. ⁓ But those are roughly the operations that we would reprice. yeah, so the core balance have to strike x opcodes. ⁓ And why we want to reprice them, basically right now you can, I think it's at 100 million gas, you can load something like eight gigabytes of data from disk or something with some of these opcodes. And that's a big problem 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. Buta has been working on that. So I would like to invite him to ⁓ give his slides. Yes. Can you hear me? Yes. All right, 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 gasrepricing.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, DFI teams, wallets, ⁓ layer 2s, and so on. And yeah, if you go to the next slide, 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. yeah, quick summary is that most of the entities were concerned about the complexity and not ⁓ about the increase itself. ⁓ And a few entities asked for toolings to be ready so they can test it out. Something also maybe 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 entities were served, but we also reached out to ⁓ toolings and other entities that were not directly ⁓ impacted so they can prepare accordingly. And so far, ⁓ no major red flags. Yeah, that's a quick summary from my side. Thank you, Putta. 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 spots and things like ephemeral contracts that can be changed very easily in order to use the new pricing. There were very few contracts, ⁓ none that we have seen where we saw 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 companies in order to get a better view ⁓ 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 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. you can, like 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 the GATS implementation should be repriced. ⁓ And you can see which of those this is, for example, the point event creation pre-compiler, so KCG. ⁓ And what you can also do is if you click on one of the tests, You can see, OK, this test ran at 40 megagas per second. All of the time was spent in execution. You can see the cache performance. We only had very few storage reads, like eight 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 the 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 run. And you can see the configuration of this run. So we used eight cores at 3.6 gigahertz. 60 gigabytes of memory. ⁓ But we limited the resources to four CPUs and 32 gigabytes of memory. So this is in line with this EIP we have about the ⁓ node configuration and all of the stuff that you want to modify maybe for your commerce. Yes, all of this has been built by ⁓ by Rafael and the Pendo Ops social to them. Yep, I think that's it. 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 EAP 8070 progress by Bosu. If you're on the call. Hi, I'm Bosu from GAT. I'd like to quickly talk about EAP 8070. So I posted a related link to the issue. So in summary, we got suffered this EAP's parsable pool and we would like to see this EAP gets SFI'd in the future. And by that, we mean that we'd like this to go through the similar process as other EAPs, like 870, getting into the devnet. We could also discuss this when we scope the next webnet, 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 client tips. So we implemented on nature prototype and also documented the complexity we've seen from guest side and some security considerations we've identified while prototyping this. So we would be interested to hear from other client teams what other client teams think about this. And also would like to answer some questions and help others to understand this AIP better. 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. Thank you. Yeah. And just to remind people, right. So basically, um, EAP 8070, we, it's one of those, um, non protocol change, uh, EAPs, but we did decide to CFI it. Uh, so it's on the meta EAP for Glamsteadam. Um, 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, um, basically treated in a similar way to the normal earpiece and also started introducing it to DevNet 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 Poso 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 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. so, so that, yeah, at the next DevNet scoping opportunity, ⁓ we can discuss this, I think. Perfect. ⁓ Then thank you very much, Poso. And then I think that concludes the Glam-Sedum topics. Is there anything else, any other Glam-Sedum related topic that people want to discuss before we move on to H-Star Headliner? Okay, then let's go. ⁓ Hey, go to a headliner selection. So just as a reminder, basically we wanted to make the 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 to, 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 fossils selected as a cross. layer, but mostly CL-heavy headliners. 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 the 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 ⁓ except 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, we will consider in the future, whether to potentially still include this ERP as a non-headliner and, or any other kind of section 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? I don't know if I can give a full summary. There's a lot of little topics that were discussed. I'm sure we can bring some of those up to whoever wants to mention. But I can quickly update what's happened in the past two weeks. I've said this on all Core Devs 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 outlines three different strategies for dealing with the frame transaction mempool. And we also updated the EAP to support strategy two, 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. I presented this also yesterday, and I think that there was still some questions and concerns about some of the exact details and machinery. 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 can talk a bit about what their idea is. 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 ERC-20 approval and then uses this approval in the next frame. But if for some reason the intended effect of the approval, like how the ERC-20, if that fails, how the ERC-20 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 bit 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. Thanks. 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's being expressed by the high-performance L2s such as BASE, as well as some other high-performance EVM chains, which is that the cost of validating transactions with frames is now obviously going from constant, right? know, 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-compires in the frame spec. that's essentially a account will be able to dedicate its validation to pre-compires, you know, which have... bondage validation cost. The exact mechanism is still to be worked out. And we are, in fact, working closely with the people who have expressed the concerns, such as Chris from Bayes, as well as Daniel from Monas, to figure out the mechanism. But actually, if you look at the support for EOAs in frames through the default code, the pre-compiler has already been supported in the default code, so at least for EOAs. we already have this great support for using pre-compires directly for validation, which gives it both guaranteed security as well as bonded validation cost. But as far as using pre-compires for validation for smart contract accounts, that's specific mechanism still being worked out. But it's the direction that we are heading towards because we want to make sure that firms work well, not just for L1s. but also for other high-performance EV engines. I can just add a small bit of input on that and wherever it's worth, like how Bass is thinking right now. where 8141 is right now, like I would say, you know, we're not supportive. 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, we still have issues with it. ⁓ And yeah, just for like, you know, more transparency, given, you know, our performance goals, like competition timelines, et cetera. 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 just wanted to kind of put this out there for, you know, transparency and how we're thinking right now. 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 frame transactions. One was from Holger from the Ethereum.js site about a frame transaction implementation. I'm not sure if Holger, if you're on the call and wanted to briefly give an update 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? ⁓ Okay. right. So, made this other proposal, ⁓ which is not really, I don't think it's... should be seen as a competitive frame transactions by the way. But I think it's kind of complimentary to some things that people are not with frame transactions, which is mostly the current state of from what I understand are verified frames. So I think I want to clear up some things first. Before I get into the API, 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 what the... 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 a concept of extensions, which is similar to frames, which, which, you it skipped, 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 yeah, so basically, and the difference is that instead of having verified frames, have ⁓ enshrined signature scheme, essentially, right? So you essentially remove the bad part. I mean, the bad part from the mempool perspective, and you're basically 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, as, as ⁓ 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. ⁓ don't need to like ⁓ speed run it for an outliner. 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 the words frame transactions, if anything, and it's not really a replacement. And you can anyways, I think just do frame transactions as they intend that 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. is in the EIP an example of a post quantum signature scheme. It's a post quantum, but basically it's ephemeral ACDSA. Just read it. like unless it basically makes it so in order to crack your public, you will 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 will 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. mean, you could probably ship something post-quantum too into this pretty easily, in 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 very five frames is that I don't really, I think at the end of the day, will still need to have crack compiles 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 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. ⁓ Yeah, I'd sort of summarize it differently. ⁓ Friend transactions does have a strong AI focus. And I'd say this is more ⁓ changing the four EOAs. So it's changing the transaction so that the signature is independent from the transaction blob. And you can change the scheme used to sign the transaction. So you could put a... use the R1 curve or the K curve that we already have as pre-compiles, or you could bring in post-quantum. And that would just work with the transaction. And then it makes the transaction blob itself composable rather than always adding new fields. So you say, I have blobs in this transaction. These are the extensions. So you'd say, 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. Julia? I also wanted to say that if with this another good side effect that you will never probably need any new transaction type and all you need defines just basically an extension for new new use cases in the future. So it's also going for it's also probably less practical complexity as a whole. And Daniel? 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, CADEX, separates it in RLP. And then there's another one that's 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. SSZ does this with partial proofs very elegantly and keeps all the hashes. And the CADEX proposal that I have separates out the separate RLP forks. And the signature form of the transactions are literally in the transactions, so there's no transactionary writing. So if the goal is just to separate it, there is, I think, more durable and forward-looking solutions. But I don't think we're going to just guide on scheme today. Really, we should be talking about frame transaction. but whether it should be the headliner or not. 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 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 obstruction scheme as a headliner. This is 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, they 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. And then in that scenario, we could then later on as part of the normal EAP process ⁓ in the next coming weeks and months basically figure out are we going to select any the search proposal to be a non-headliner for HSTAR 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. 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 relays 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 snark 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 a great feature because as said, this has been a headache for a while. So I think people should also consider that. While Julia's proposal is very nice in adding new signature types, the frame transaction proposal might be more generalizable. Felix? Yeah, I want to also say that I have a couple points. One point is that we 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 side, there is capacity to work on account abstraction. And the frame transaction proposal as it is now, it's 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 with 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 then working on it for the next 12 to 14 months to really figure out the shape of it. More to what the point of what Tony was saying, just these kinds of business and also maybe as a response to 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 to what 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 proof groups on chain. And we feel like this gives us a very comprehensive framework for introducing post-quartum signatures, not just for the transaction origin signature, but also for example, for signature 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 elliptical cryptography and how they can be migrated or chained. That includes things such as use of easy recovery 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 just something to consider as well. Anyways, I hope we can come to a good decision today. And that's it for me. Thank you. Patasarathy? Yeah, hi. Thanks for letting me speak. As a team who has been building wallets on Ethereum for seven years, I just wanted to. highlight that account abstraction or native account abstraction on Ethereum is long overdue and the community has debated and deliberated on several options and we think at least ⁓ I can speak as a community member that Flames transaction happens to be the most popular at least among the mafia group when a poll was run. ⁓ I would like to highlight a concern that if ⁓ frame transaction isn't chosen as a headliner. ⁓ 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, mean, as a team ⁓ of building on Ethereum that we would like the core developers to choose this as a headliner for a headhunter. Thank you. Thank you, Vitalik. Yes, thank you. So I wanted to just kind of give again a high level philosophical perspective on the thinking behind frame transactions. Basically, there's a doc that I published on the A.A. Mafia months ago and I know definitely 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 basically all of the use cases that we have figured out in essentially the last 12 years of abstraction research. But in general, right, the idea, the problem is that any substantial simpler proposal ⁓ is inevitably going to leave a lot of things out, right? So like, for example, any proposal that depends on a, inevitably, without multi-sig, it will inevitably, by default, leave out key changes. it will leave out multi-sig that makes and matches different signature schemes. It will by default leave out like post assertions like ⁓ what Fredrick mentioned in the chat will leave out sponsored transactions and it will leave out private account obstruction. so basically, inevitably any proposal that is sort of much simpler than ⁓ what frame transactions already is, one that is not going to be able to cover those use cases. And so essentially, this is the reason why frames is what it is. And so if you make an incompatible proposal that does not... that ⁓ doesn't very naturally extend into frames, which would probably basically just look like frames on what the frames are, then essentially three years from now, we're polluting the protocol that we need. 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, ⁓ can be expressed as a subset ⁓ of A141 and in a couple of cases, A141 plus a couple ⁓ of other ⁓ very small EIPs. ⁓ And so the core philosophy here is basically that actually, yes, we can make the mempool very restrictive. I personally think it's totally okay to have the mempool be something that if desired, example, even a is even more restrictive than the current proposal and even says, like, okay, we'll 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 even newer ideas that come and work on being able to support all of these more complex use cases. And the, And then the primary mempool always has an optionality to add in some support for more things or even just add in the universal mempool in its entirety at any point in the future without a hard fork. 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 though what we can do is we can say, we have a much more restrictive forward. ⁓ 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 actually 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 is a way to do frames that even makes it EVPM free ⁓ and that's all ⁓ part of the proposal. And then at the same time, ⁓ of these other things happen. So that's kind of the high level view for like why this design has been built the way it is and why I think it can satisfy both very conservative near-term use cases at a high level of efficiency and at the same time immediately open up space for adding features. So just to double check that I understand, it would 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. Then poolside implementation so that the actual implementation 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. Mm-hmm. Yes. Yeah, think that's a general reasonable argument. ⁓ Julio? Yeah, I just wanted to say that you can extend scheme to be like frames with an extension, especially with verify frames in the future. 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 simple extension. So you can... get there, still with schemed, it's not like it blocks 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. Right. Yes. I would just say like, just don't really see in what sense, you know, like frames are uncontrolled, right? Because like, you can have transactions that just are one verify frame followed by an execute frame. And it's equivalent, basically equivalent to a scheme that is verification specific, right? And so, you know, the argument I would make is based only allowing transactions of that type. functionality-wise, it's kind of equivalent. You can see the one-to-one correspondence from one thing to another thing. And effectively, you get schemes. Yeah, so maybe one way of presenting this question or the decision we have to make today is that 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. ⁓ so we could do something that's inspired by, know, similar to Julio is saying, but 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 cont abstraction and with post quantum, we will eventually have to tackle the verification flow anyway. So the question is basically the decision for frame 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, we don't do it this hard folk. We wait for another hard folk. And 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. Um, but yeah, so I think kind of like that is so indeed, don't think it really, I don't think basically like saying go doing something that's that's more like a 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 that we will have to at some point do. If that makes sense. Derek, if you end up Oh yeah, I think I just wanted to emphasize a specific point. I think most of the debates that are between frames and most other alternative proposals essentially just comes down to whether people believe that verification should be done through EVM code or should be essentially enshrined into the protocol, for example, through pre-compilers. So for example, if you look at skin transactions, If you look at the earlier EIPs, like the composable transactions or the, I think it's like 8.164, like the passkey transactions. They all believe that it's, I guess, dangerous or it would complicate the manpool to do the verification with EVM code, which is why they opt to do the validation through pre-compilers. But I just want to point out that actually we don't have the troops. So, firm transactions, as I mentioned in the beginning of the call, is the only proposal that gives you the options. 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 let the protocol handle the security. So, I just want to say that just from the perspective of like... giving people more options, right? know, I sort of think of Fram's as a superset of the other proposals, know, so to be, yeah, so I think like that's why I think Fram's aligns better with the broader Ethereum philosophy of like just, you know, you know, allowing permission, this innovation, giving people the options, you know, and, you so I think like Fram's is really the only proposal that satisfies the needs of both camps when it comes to how validation should be handled. Sounds good. continue discussion, just want to briefly take a moment. 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 their thinking is at. ⁓ Are they still basically undecided? Are they decided? Is it even an option still that we might select Tram Transactions as the headliner today? ⁓ 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. ⁓ So then I briefly call on the clients, like Geth, could you briefly give an update on your position? Yeah, so we want the freight trip to actually... Yeah, I guess this is not so surprising. Nevermind. ⁓ I think we have bigger doubts that we wouldn't call... definitely don't want to call it a headliner at the moment. And then I guess you want to add something from the other side. ⁓ he's unmuted. Sorry, I just like to add that we're happy to work on it separately, do a cortosis and firm it up more. Sounds good. So you're open to it, but prefer to not have it be headliner. Eric? ⁓ we, think we basically went from plan decided basically probably slight to no. Okay. It's like, no, but open to it still. Yeah. I guess we had divided. So, some of us are actually in favor of frame transactions, but I think, ⁓ Julia's, ⁓ proposal is also a good, ⁓ stone. So good, peace out. Yeah, we still also figure no headliner for Hagata and the team has concerns about complexity, basic frame transaction. We think it's too complex for what it delivers in the end. Okay, and... breath. Hey, uh, yeah, we are a no. Makes sense. And any of the newer EL side clients, so Nimbus EL or EtherX? ⁓ On the etherx side we are in favor of the EDP Okay. ⁓ Yeah. So it does sound like they're still, we're still leaning towards, no, I mean, we can go back into open discussion for a little bit. I, my impression is that actually maybe not so unlikely outcome would be to reject it today as headliner, but still work towards selection as non-headliner. It seems like a lot of clients are at the edge of being convinced. They just need more time. So it might actually be not so unrealistic outcome to just ship it in the end as a non-headliner, but ⁓ Yeah, for today's discussion, 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 make a decision. Amit, you have your hand up. Yeah, no thanks for that. great to hear everyone's opinion on this. So I think a lot of the arguments ⁓ that was presented for frame transactions have already been discussed and don't repeat those. But I just want to say generally, I think as an ecosystem, we have to push hard and through even though some things look a bit complex. ⁓ We've been doing account abstraction for long time. We've now been working a lot on orchestration. We're kind of firsthand 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 I don't think they're perfect. 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 use cases on the privacy side. also, ⁓ I think there's going to be a lot of innovation that will come from this. So yeah, think just something for the client teams to so reconsider, I think. And Nico. Yep, ⁓ I think it would be also good to hear some opinions from other altus. I see some people from ⁓ OP Labs, ⁓ from Arbitrum. ⁓ Mark from Optimism has been very supportive publicly of Primes. We'd be interested to hear Arbitrum's opinion too. ⁓ Most of the, like as Aftena 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 inputs in this process. 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 OPLabs. Would be good to have your opinions too. Yeah. So if any of the L2s want to raise their hands, feel free to join them. The queue, I want fast track you, think it makes sense. So just, just, just go one by one. So next step is Julia. Yeah, I just wanted to say that, ⁓ I mean, can probably, I mean, if you, I don't want to say this, but if you go for schemes, can do probably very five frames as their own thing, as another line in the gota, pretty probably in more controlled way and you could still ship them. And if you ship many things at same time, I think there are so many unknowns that people are not really. that we link to implement them. That's all. I think, I think it's just, yeah, that's what I wanted to say. You can still do it that way probably. ⁓ some good looming. 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 official stands 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. 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 or wallets 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 ZeroDev and Derek is helping. define the standard. that's what I can add from my side. Thank you. Josh? Yeah, thanks. I'll just echo something that, like Clint 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 multiple proposals on the table. ⁓ At this time, it's difficult to definitively say which one would be best long term. So I think my 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. So just process, mean, look, I'm just a coordinator, of course, ultimately I'm willing to facilitate any decision whatsoever. My understanding of 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 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. 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 that 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? ⁓ I don't think a theme would help because we're trying to put something firm into the ⁓ plan and we're saying, we'll put something vegan. It's not really, ⁓ yeah. And one of the issues with ⁓ friend transaction is it isn't firm. So we've rejected encrypted memples for not being fully designed ⁓ equally. ⁓ What I would prefer is if we CF-fied 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 hold the fork until it ships. And I don't think it's there for that at the moment. Yeah. I think sometimes this could be very reasonable. I'm not sure we would have to make that CFI decision today, but yeah, think in general, that's a reasonable proposal. just want to add something quickly just to respond to that. I think, yes, 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 EAPs 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 a bunch of different moving pieces. And I just want to push back a little bit. I think the frame transaction standard is quite solid and built on a lot of in-production ideas with 4.3.3.7. 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, 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 frame is going to be. OK. And Andrew? Yeah, I think we should be more ambitious. And if you look at the straw map, if we keep postponing doing hard things because they're hard, then we will never reach ⁓ even a half of the strong 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 also, 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 Hegotta. I also think if you look at the straw map, are actually there is a stream of work related to the mempools. There are encrypted mempools and that 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 mempools. So we just need to bite the bullet and accept that we do need to work on our mempools. And it will be like, yeah, it's a big chunk of work, but I think it has to be done. And Nixle? 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. 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 client. 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 a headliner or whether it's 8.141. 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 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 solution. The fact that there is even one solution as ambitious as this, included as a headliner, was perhaps the most hopeful news I've ever had in the eight 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 really seeing a monumental change for AI and we can challenge whether that is a good EIP, but not having this as a headliner, I think it's a problem. And Lumi, and then afterwards, I think because we only have 10 minutes left, yeah, we'll bring it in and have a discussion about the concrete decision. So Lumi. 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 up. that we should do, we are going to start seeing fragmentation between L2s regardless of which native AA approach we go to because every L2 team is prioritizing native AA 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 going to slip after ZKEVM and a bunch of really big projects. This needs to be a priority. We hear this every day from users, from enterprises. It may be more than all core devs. is the single most important user experience choice. Yeah. Thank you. And just as a quick personal comment, I was part of the group that brought ERP 2938, which is actually relatively similar to frame transactions, to Okodev's back in 2020. And back then, the decision was, ⁓ sorry, London is already getting quite full, and we are too close to the merge. So there's just no time. And ever since, 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 codefs prioritizing this topic for HSTAR in some form or another, either as 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 AP 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 and otherwise afterwards I'll start. talking about complete decisions. I'm OK with prioritizing it, but I'm just saying if we say AI is a headliner, the implication is that we do not ship H star until a solution is implemented. That would be the theme of what a headliner means. Yes, I think that is a good point. None of us? We do need user experience when though. I think we should be holding off each store for this. Right. So yeah, think, 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 Banabas 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 headliner, without 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 Beesu. I would assume as clients maybe closest to changing their minds. No, from Beesu we still prefer no headliner. I mean, we can have 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 and when we would ship. So I we can do this as EIPs, but I wouldn't do it as a headliner. OK, well, that already kind of answered the second question as well. let's first finish the discussion on frame transactions. NetherMind, assume you, did you change your mind on frame transactions? So I don't know what the rest of the team thinks, right? So we haven't time any to discuss. My personal opinion is not changed. I would like to experiment with it and proceed with it, but I wouldn't put it as a headliner. OK. Then I think in terms of decision for today, it seems that frame transaction 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 of the ERP itself. I think the ERP should still be considered, PFied. normally we DFied headliner ERPs if it's clear that they have no room. outside of the headliner status, but in this case, I think it makes no sense. So I think the decision would just be to decline 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'm open to saying we last minute select account obstruction more generally as a headliner for the EL for H-Star. It now already sounded like Bezu was very skeptical about the idea. Do we to briefly open this up, maybe have 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? I think death supports this. ⁓ Not the mind, do we have an opinion? I don't have an opinion. ⁓ Without specifying the AP, it's pretty vague. So I don't know what it means. I think that ⁓ maybe choosing a more choosing headliner effects is 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 schema thing from GUI-LU. ⁓ we can switch and decline this approach of friend transactions. I mean, maybe it's a good thing to ⁓ confirm its headliner just 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 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. Right. But so I feel strongly that it could be so, so Now in terms we need to make a decision today. Like I see a lot of support for the idea of a 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 quadrups 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 native A as a headliner theme. So I just don't think process wise we have a basis to select native A more generally as a headliner theme. So I I do think we should probably as all codecs more generally say that clearly we We signal the intention to prioritize native A 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 a headliner commitment level. anyone want to object? Felix? Did you want to say something Felix? Yeah, I was asking, so this is like a CMI plus or? No, it's nothing like this. Not like the but 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 AI and I hope we can do something in the hard fork. 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 zoom user that wants to say something. Sorry, I didn't hear my name and Antonio here. Sorry. Just a quick ⁓ comment. Since I understood that there is no strong support for prem transaction, it's okay. And it was like this alternate proposal today by Julio. I was wondering, is still the chance to have two more weeks to like, having people chew over these two alternatives. I don't know how late we are in process, but given there is like this... big uncertainty and topic is so important. I don't think that two more weeks will change too much about the headliner. If we can have two more weeks to have more people like discuss because I think like account abstraction is not account abstraction. It's really an important topic for the future of the protocol. So imagine if I map in two more weeks to take a final decision about headliner or not and not closing the discussion today. Just made sense. So given that we already made an exceptional decision to move the deadline by two 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, none of us. In previous OcoDevs, the PandaOps team has never really spoken up pro or con a specific EIP, whether we want to 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 OcoDevs and whether we have a decision or not. I would actually be ⁓ for frame transactions as a headliner. And maybe my opinion will actually balance it out and push it through to be an actual headliner. I'm not sure how the other pandas 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. I feel like you're part of the Okordev process as a whole. 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 on 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, Okordevs can always in exceptional circumstances revisit prior decisions. They never final until they ship to chain. 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 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. ⁓ I guess, 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. So yeah, don't know. I mean, maybe, yes, I would now restrict contributions to only clients just for the formal decisions here, Ben. Are we OK to accept that, in five to four or five months after we've explored it a bit more with an implementation, firmed up the specs that we could revisit it as it happens? That would be a full group decision. 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. Yeah, that's why I'm writing it. 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 ⁓ EL-wise, post-Glamsedam, the focus is, mind share-wise, on account 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 also means we're not specifically assigning, like frame transactions will remain peer-fied for now. until we make a specific other decision. Is that a reasonable compromise to leave the call out for now and end it? We're already five minutes over time. 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. You mean frame transaction specifically CFI? I feel like we have clients that specifically even oppose it as just in general to do at all in Ethereum. Do any clients oppose? Do you any clients who oppose making it CFI? I thought I saw most people saying CFI is okay. Can we just have that discussion in two weeks? don't think right now. don't, I mean, you know, we're five minutes. mean, can we just make the decision? think if you get, if you get an act from every single look, okay, Matt, this is your section. If you get an act from every single client at CFI. Yeah, we wouldn't object and ⁓ a precedent kind of a set this bottle. They're like early CFI. Yeah. Julio or Aragon? Fine. Let's find the CFI. Asu? Yeah, I think we'll find the CFI. Russ? Yeah, we won't block it. That's cool. Okay. then we see if I have frame transactions. Um, and by that, that's the last decision for today. Thank you everyone. Uh, this was a hard one, but, uh, I do think again, overall, uh, focus on account abstraction. 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, um, will have Nixo fill in for me in two weeks. ⁓ So Nixo will lead Orcodex in two weeks and I might still be able to be on the call for some portion of it, but yeah. Thank you Nixo for doing that. Awesome. See you all in two weeks. Bye.