Execution Layer Meeting 244 [2026-08-27] | ACDE 244

Akash Kshirsagar: welcome to Alcore Dev's execution number two forty-four. Today is August twenty-seventh. today on the agenda we have some clamstron items. or we have one miscellaneous miscellaneous item, and then we'll go through Hagoda and the thought process behind that is that we will go through some housekeeping items behind Hagoda timeline. some possible p PFIs that were were done by the deadline but weren't presented on the last one. And then if we have time we will dedicate some some time to the frames conversation. The a c AA conversation. Let's get started with Glamsterdam. Do we have a DevNet update? I think Barnabas was going to do it today. Stefan couldn't be here. Yeah so A very boring update. we've been trying to break the chain. And here and there we were managed to get a few payloads missing, but all of those were due to unupdated client releases basically. So what we are waiting for right now is everybody to merge all the fixes into their trunk branches and that we can roll out their trunk branches on the devnet and then we can keep fuzzing away. Currently we are still spamming the network. We have an average of about 10 blobs and 100, 150 transactions each slot. And we have very close to 100% participation. Great. Do we have so there's gonna be a DevNet 9 and non a non-finality DevNet, correct? Yeah. So DevNet 9 is going to be our non-finality DevNet. and we're gonna be launching that as soon as all the clients have their trunk branches ready. Okay, great. and how long do we expect that to run? A few days only, and probably at most four. Perfect. that is a good impetus for us to go through some the Tony, do you have something to say on that? Yeah, I was wondering if we also wanna launch DeafNet ten directly because I assume I should not test things on Defnet eight because this is long lived DefNet and at the same time DefNet nine will be non-finality. So I'm wondering if we also need a DeafNet where we can actually test some attacks. Like DevNet 9 is definitely gonna be the place where you would want to test all your attacks. We don't need a DevNet then. Definite nine, you said? Yeah. But but Definite 9 is already like under a lot of stress with non finality. Yeah, exactly. So you might as well add more. Yeah, I'm not sure. I would actually try to test things that would cause non finality and not like start with a broken deaf net. I mean the nonfinality period could be variable. I don't know if we can do a very, very long non-finality with a thousand node network. So what we can also do is b because people have asked us to do a nice fork transition and at least one day on Fulu, what we would do is we would have one day on Fulu. That would be all around 100% participation. We would go through the fork transition. And then right after that, Tony, you can start with whatever you want and see if you can take the network offline. And if you cannot, then we would start the non finality. And then we can try to recover after a day of non finality, for example. Okay. And we can also do about twenty, twenty-five thousand builder deposits and sparkle in some invalid ones for DevNet nine. And we're gonna be doing about three or four million validator state. So it's gonna be about six, seven hundred megabyte Genesis state. So it's gonna be very stressful for every client. Great. Thank you. can you guys see my my window right now? Yeah. We see all the whole screen, the just window. Okay, great. so this this is a rough calendar. Obviously, this is gonna depend on how these dev nets go. but I just wanted to like highlight how Can you zoom in, please? yeah. how tight we are on on timeline. so these are EL weeks, C L weeks, and basically we're gonna come up to this security is we're gonna once so September twenty-eighth has been floated as the day that Cepolia forks for Glamsterdam and hoodie forks for Glamsterdam that's not confirmed. if anybody has any opposition to that, that is what was proposed on ACDC last week and it will be confirmed on ACDC next next week. So wait for that confirmation for Septon September 28th, but assuming that's correct, we have about a 30-day security window for the security audits and then a 30-day window for L2s, DAOs to get ready for the fork from announcement. And that brings us to the very end of November. And so if we're going to fork by the beginning of December, this is the approximate approximate timeline. does anybody have any questions or comments about that? Great. Okay. if Lyle wants to bring that to the next ACDC, I think that can that conversation can happen there. but that's the approximate timeline that we're looking at right now. let's go back. Okay. Kev, do you want I assume that your aligning on a history expiry retention window item was for Glamsterdam. do you wanna say anything about that? yeah, sure. So this is a follow-up from the last ACDE. I reached out to some of the clients to see where we are at. And so all clients as far as I know are okay with aligning on the C L block retention window. I would propose that we change four fours to document this instead of having a new EIP or just having it in the client code. In terms of readiness, Nimbus has already implemented it. Eregon, I believe, says they'll look into it. GAF has agreed to it, but would be good to get an update on where we are. FREX is looking into it. I believe there's an EIP sorry, a PR up. and ref says that they could have it in the next release. and just clarify, like currently two terabyte nodes, two terabyte nodes are sort of hidden up the limit. That roughly we're at like one point five to one point eight. so if we launch Amsterdam without expiring a lot of the history, they potentially will just not have enough storage left. yeah, sorry, never mind also implemented it. the PR was linked in the PM issues. and yeah, if there's no contention with just modifying four fours, I'll just create a PR to update it to have thirty-three thousand epochs. Great. And you have confirmation from the other clients that they are also working on that to be ready for clients to do? I think GAF has agreed to it, but I'm not sure when they were planning to do it. If anyone from GAF is on the call, it it would be good to get an update. Do we have a GEF person on the call? I can follow up async as well. great. Sounds good. Thank you. and we'll throw in your miscellaneous item just so that we can dedicate the end of the call to frames. do you want to talk about PQ readiness? yeah, sure. So another item is the deposit contract, or it's actually a bunch of contracts that currently are BLS specific. and we're looking at how do we update these contracts for a PQ. there have been a couple high-level strategies to supporting this new PQ functionality. One of them is we deploy a new deposit contract, one of them is we modify the old deposit contract using an irregular state transition function to add the new function for PQ. another is potentially having a pre-compile. or a deposit transaction or deposit opcode. I was hoping to get some opinions, rough opinions on what are people's thoughts on this. Personally, I think I'm lightly in favor of a regul an irregular state transition. Ben I'd prefer not to set a precedent of changing a contract. it's fine. But yeah, it it opens the door to the idea that we can change contracts. I mean this would just be a special case, no. Yeah, but then then the government might say, Well, make a special case for us too. That's fair. and I guess another point there or maybe a sub point is that some people have opted, have suggested to have an irregular state transition just for adding reverts to the old beacon deposit contract. because people will likely lose their funds if it's not added and we have a PQ switch. the alternative there is to deploy a contract that does support BLS currently. And then have everyone switch let's say give them two years and then this new deposit contract will have a reversion in it. Ben? if if we do something like the binary tree or you know a massive state reorganization, I I think it would be more acceptable to do an irregular state transition at that point, because we can we can argue it's it's not a I mean, we're doing a massive irregular state transition at that point. If that makes sense. And then we could do s other things like burn everything in the deposit contracts. Yeah, so you're saying that if we do the PBT or the binary tree migration, you'd be okay with also modifying the beacon deposit contract to burn the ETH that's inside of it. And yeah. Yeah, because at that point it's it's happening as part of something that we can't easily reproduce. We're not if if that makes sense. just just in terms of precedent of how easy it is to change things. Right. And then would you also be okay with modifying the beacon deposit contract to add the PQ functionality or is it just burning no no I yeah whatever. Because I mean at at that point we're rewriting everything. So yeah. Okay. Okay. I see. Right, thanks. does anyone else have any feedback on this at some point? Isn't that decent? Great. and I realized that I forgot I I missed two items that were added to Glamsterdam agenda the hour before the call. So one of them is from Mystic Ryusian ETH simulate B one issues. I haven't had a chance to look at what that is, but Chase, are you on the call? Yeah. Yeah, I'm here. I mean for the most part, like this so ETH simulate. Is not hasn't been like updated to the specs for what it should do for simulated blocks. So all of the clients kind of disagree on what to do and what to include. So yeah, I just need some people to take a look and comment and come to a decision about what should and shouldn't be in the simulated blocks. Can they follow up async or is that something? Yeah, yeah, yeah. Okay. there is another item from Milanite and this is a modification that's being requested on AD thirty-seven. Milanite, are you here? Yeah. Yeah. Can you hear me? Yep. Okay, cool. Yeah, this is because it has been removed the gas refill for the self-destruct. basically I wanted to discuss the point. Where basically I mean, as long as we still have self-destruct and we don't have an alternative for ephemeral contracts, which are very useful for intense routing, bridging. I mean, there are a lot of actual use cases, the self-destruct should basically refill the gas cost. It also kind of created an opposite incentive while you're not You're not really incentivized to use self-struct, then you just blot the slate. Pavel from Ericon, I don't think he joined, but he helped creating the PR for this, which I linked. So yeah, if anyone has any question or comment, I'm be happy to talk about it. To to give some context, this basically for applications that uses dysephemeral contracts will mean an increase of seven time for transaction and on Ethereum is not sustainable and will move this use case only on the year two. Maria. I I just wanted to add a couple of comments. So I I I think Miles, you you you commented that we should add the rationale for why this is being removed to the EIP and I definitely agree with that and I will I'll add that. but to to to give maybe some context there, the rationale at the time was that so initially we wanted to make eighty thirty seven tracks so the metering we were doing on eight thirty seven to be as accurate as possible. So You would only charge if you were actually using state. And initially that design included doing the refill for self-destruct because of course those accounts will not be using state. but then we end went up back we end up going back into that decision, and that came mostly after spec implementation and during testing, because we felt that it was adding too much complexity for the use case itself. and that it would be going against a general direction that we are going the protocol which is slowly deprecating self-destruct and giving another alternative. so I agree that the better alternative is having like a specific like these ephemeral accounts, like a specific COP code that you can already say you are creating just for that transaction. And I think this is the right direction, but it's not something we have in Glamsteram. And and yeah so the the decision was both for simplicity in testing and protocol but also because we felt it was going against the general direction that self-destruct was going into. I think another point to note is even though I I I'm I I can see the argument of things becoming more expensive, but I would like to also note that we do expect so things will become expensive in relation to other things. So it's true that now self-destruct will be more expensive in relation to things like the ad op code or even like state state access, right? But overall it shouldn't be that much expensive because what will happen is we are raising the gas limit significantly and so base fees will go down significantly as well. and so I I don't expect the end fee for the user to be that much more expensive in relation to today. so but it will be expensive in relative terms. So if you look at gas use, it will Seem like it's becoming more expensive, but in real terms, I I wouldn't expect it to be huge. And also in terms of impact, I was looking at the last month of data, if I'm not mistaken. And let me see, I think the usage is let me just get the numbers right. It's Sorry, and I should have the number already ready. Yeah, yeah, but it's more an emerging paradigm rather than like it's not super common today, but more and more intent protocols are starting to use today the usage is an average of roughly one hundred one thousand five hundred accounts per day are created and self destructed in the same transaction, and these accounts for roughly so if we just account for the leaves, this was the count for roughly sixty-two megabytes of state per year. So I I I would argue like the impact today is small. So I I don't feel like this is a good enough argument for changing the fork such in such a last minute. However, what I do agree is we need to update EIP to make the rationale clearer. And I do agree that this should be a discussion we take into Egota. Like and I I think the right approach is not to change eighty thirty seven, but is actually to think a bit more deeply into how this should work in the protocol and then implement the right solution, not just a like a how do you say like a appendage. Right. I I agree that self-destruction is deprecated. It is more like I think could do more harm than good, not including the refuse, because we we don't have an alternative. And I understand the gas costs will be much lower lower. But here we're talking about ten times more or less more for every single transaction. And I absolutely agree that there are not that many right now, but it's an emerging paradigm. That protocols are starting to use for signerless addresses. And also as a paradigm that this is only possible on blockchain because you can encode in the address itself the intent. So it's kind of making this way less effective on Ethereum. It will be for an year. I understand that, and I agree that there should be an opcode for this, though I will argue that it could be. While we don't have that, we should still support this this pattern because it's a legit pattern and yeah it's it's really overpriced and it But yeah, this is my argument. I'm I'm not very familiar on the whole EIP flow. Yeah, maybe I just want to point a little thing. It's like it's true that it's a ten times in gas cost. And again, like in relative terms, it will seem expensive, but in real terms, so in the end fee that the user pays won't be ten times because the base fee will go down. so I I I I really want to stress this. Like it's not will not feel like a ten time increase for the end user. yes, I I understand this, but this ephemeral contracts are usually meant to be used as as a single transaction, so will be per each single transaction. So overall and also in gas spikes, I still believe can reach a couple of dollars. We're talking about approximately two hundred thousand gas overhead. Given that there aren't that many of these transactions today and there is an EIP that was related that was proposed for Hagoda, is it problematic if we take this offline to work on something for Hagoda that would satisfy that that would mitigate this issue? Hm, I mean for sure a gotha needs to have a proper EP for this and the break it self destruct. My argument is only for Gramps. Yeah. I think it is quite late in the process and I assume Maria that this would a a change to this would require changes in client code and would set right would set yeah. Yeah, it would require spec changes, call client code changes, more testing. so so yeah, I I I I tend to to say that the in my mind I don't think the impact justifies the additional work and potential fork delays, but at the end of the day this is up for core dev, so if there are any strong feelings that we should do it, I would I would like to hear. Okay. why don't we call the the related opcode PFI a placeholder for a solution for this in Hagoda? and Milosh, can you follow up with something that will that will mitigate this for for Hagoda? Yeah, I mean for Agata there are already some UIP proposed and it's yeah probably one two years ahead ahead. So let's hope it's not that long. let's let's hope it's less than a year. I expect I expect it will be. Ansgar. Yeah, just to to set the expectations, I think one shouldn't just be like, yeah, he gota then just move on and say, Okay, let's think about this in six months. Like These Hagota EIPs might be re rejected andor potentially like will need arguments for acceptance as as of two weeks from now. So basically, if this is something important, then this needs to be brought forward, decided, discussed in the next two, four weeks. Otherwise, it will not be in Higota. So just flagging it that we can't just be like, in two years, let's talk about it at at a letter time. Like if this is important, this needs to be important in two weeks, in four weeks. Yep. Good point. Thank you. Okay. yeah, if you could you if you and Milos and Helcomine AKA A B C and could work with the eighty thirty seven author authors or the gas repricing group to work on a solution for this in Hagoda, yeah, I would get that in in the next couple of weeks. Okay, let's move on to other things in Hagoda. There is there anything else Glamsterdam related? Great. So for timeline client preferences, I am asking clients to have their preferences by the next ACDE. Ideally, please send them to me and Ansgar 24 hours before the call. That way we can make that a productive call by looking at these client preferences and seeing what is not on any of these lists or what is a DFI. What is an ease easy DFI so that we can start working on that? Because we will then have three calls after that to do Hagoda scoping, and we have a lot of EIPs to get through. so on the September 10th call, so EL clients, please submit your client preferences to the facilitators by September 9th, so the day before the next ACDE. and EIP auth I'm gonna EIP champions, please show up to the following three or four calls for scoping. if there is a possibility that if you do not show up to the call, your EIP could be rejected if you are not there to speak for it. Great. we have I guess two PFIs that were put forward by Helkamine, aka ABC 123. 8360 was sort of already talked about. we have 7609 decreased base cost of tea loads tea store and 8058 contract bytecode de duplication discount. These were proposed by the deadline, but they have not been spoken for, and this was their last opportunity. to speak for these EIPs, to get them into PFI if Halcomine is on the call or anyone wants to speak for these. If not, they will be dropped from PFI. for the contract code de duplication, that was where sort of set code from came from. So it achieves the same goal but in a in a more general way. Okay. So that leaves one seventy six nine decrease base cost of T load T store. If no one speaks for them and all three of these will will be dropped and with caveat that one that it will be a placeholder for whatever the solution is that A about the issue that we just talked about. So just make sure we are saying that the temporary create EIP will not be pulse for a gota. Is this correct? So that that one because the because there's been conversation and people are and somebody came to talk about it, that could be a placeholder for whatever solution that can go forward. just these other ones, seventy-six nine and I guess eighty fifty-eight is also related to that. But seventy six nine will be dropped. next, Schult had a presentation he wanted to give about the trustless log and transaction index and demo the proposed API. Shult, are you on the call? Yes, I am here. Okay, so let me just share my screen. Okay. Can you see my screen? Yes. All right. Yeah, so So I just quickly wanted to show like some of the progress that happened with this trusted log index project. well because I think it's it's already in pretty good shape and and yeah like client rankings in two weeks and everything and I have this not so hidden agenda to just encourage every one of their clients to look at it and and and maybe yeah consider ranking it as something preferred so yeah so i i have this page in my own github repo the tli the trustless log index page which i just recently updated so this is Yeah, so the core of this is EIP A304, which I already presented like two months ago. And and so just a recap, this is this is this is a different design than 7745 was, which was very complex, but this is much cleaner and also a lot more efficient, actually. And now what I want to show is that so all of this thing really makes sense if we also have an API for it. And yeah, I mean I just have some some some draft specifications and this can be so obviously and and API is something that will be probably be discussed by many people before standardized, but I just want to show how I imagine this. And yeah so I had this draft for quite a while already and and and this is This is this trustless execution layer API spec, which I will not spend a lot of time with now. so the the important thing is that besides the kind of standard things, so you have so it is the format is very similar to to the beacon API and and it's it's a REST API and nice and has JSON and binary encoding and and everything. But the important thing is that besides the regular things like serving headers and blocks and receipts, which is just classic stuff. It also does multiple things based on this AI EIP. It can serve prove canonical block hashes from the entire history. It can prove the inclusion proposition of a transaction hash or an exclusion proof if if it's not canonical, which is mostly impossible now. If you don't have your own indexer, of course. yeah, and the most interesting and complex thing that it does, and what I want to show now is the logs endpoint, which does the efficient log queries. And yeah, let me just open the log query specs. So I have a different page for this. So and and and and I can even show you at the end some proofs because I I already set up a node which is very low bandwidth. It's running running on my home internet. So later up I will probably just rent the machine, but now I can just use it for the demo. So this is how a log index query would look like. and yeah, just let me just really quickly go through what it does and why it does it. So one of the important things is that because it it has proofs and this EIP. So this EIP works I don't want to go again into the details, but it has this index contract which which is a system contract that stores the root hashes of these binary tree hashed tables, index tables that I yeah, well I will show the proofs how and how they work and why. They work, but the important thing is that that they are anchored in the state. And so so any query needs to specify a reference head, which is a recent block, and it can be the actual head of the prover, or because this endpoint will probably also be used by light clients who might follow the chain with some delay, like with the beacon light clients. So the the the client can also specify the reference the latest head it knows about and then yeah it has to be recent because we need state to prove the contents of the index contract. So the so the point of this is to prove the these these index tables that are the data structures generated by this EIP and yeah and and also also this this yeah because Because log queries can be very complex. Sometimes they are really cheap. If if you just want to look up something, some event that happened once in the entire history, then this proof can be like like tens of kilobytes, so under 100K, maybe, or or maybe a few hundred if it's a little bit more complex. But so they can be cheap, but also it's easy to come up with a really expensive query. So there needs to be some limitation, and so this is This is these are limit latest or limit oldest parameters. The client can specify the maximum number of results it wants to request, and it can be the well, the name suggests it can be either the latest or the oldest results. I think mostly the more for most use cases, maybe the latest matches might be important. Like for wallet, probably if there are like billions of results for something that then maybe maybe the latest ones are more more important. But anyways, so this can be used for for like this is as a paginated request, like like like doing multiple queries. But anyway, so this is this is just just protection against system overload and and they it specifies so that the prover can also limit the query if it's too much and yeah. But the really interesting thing is the search patterns. So The classical JSON RPC log query also can speci can just specify multiple alternative addresses and multiple alternatives for each topic index. But this so this this this API can do even a little bit more. I mean it it pretty much maps to the actual capabilities of this this design. So so it's it's it has its the JSON encoding and yeah so that the really really simple case when you just want to like look up a simple address. So that's encoded like this field address value, this is the wrapped ether contract address and this will look for all the occurrences of of the wrapped ether con log events. And and and there's you can you can construct recursively construct and or relationships. So you can basically do what what the JSON RPC request can do. And there's a third third interesting thing it can do, and so this is something that I'm not sure if there are many use cases for it right now, but it really doesn't cost a lot to have it. Actually it's it's just Yeah, the design can do it. And maybe so my my idea is that if we make logs more usable, then maybe new applications will use them in more ways. And this can be interesting. So it's also possible to have patterns across multiple logs of the same transaction. So you can this this offset thing just does okay. It here's this pattern, but mesh this to the to the log after the one. We are so so here's the pattern for this log and here's the pattern for the next log and and yeah, match both of them and give the results where both of them are matching or some of them are like so you can also use these these and ors after that. So yeah, I think I think this is this is this is this is a nice setup and yeah let me just quickly show how this this proofs actually look. So I I still need to work on like the exact specifications of how to very generate and verify the proofs. But yeah, I couldn't present them on this call anyway. So let me just see. Here's here I I I already prepared some test requests. Like here's test request one. the first occurrence of the wrapped ether contract address. Yeah, let me just what? No, this is not what I wanted. No, this is what I want. Okay. Yeah. Let me just switch it to pretty print and so this so this is this is here There's the query also in the response. So the pattern is really simple, just what I showed before. So just just one like comparison of address field to a s a certain value, and also there's the the limitation, like like one one item and the and and the oldest one, looking for the oldest one, and how the proof looks is well, yeah. So it has the the reference header, it has the entire header because it has to be it it it it we we need the state root yeah so we so for from the state route we can look into into the index contract and yeah the rest is all these big like mpt to try nodes here so these these are proving these are these are proving the get operations some get operations of the index contract so they are proving the the table root hashes and yeah the interesting thing another interesting thing about the sorry the the contract is that yeah here here it's also listed that this is the these are this is this is the index contract that that the prover uses and this index contract obviously because i'm I'm running on mainnet now and and this eip doesn't work on that yet. So but but this is actually a nice thing about this design that we can use multiple index contracts right now I'm using a dummy contract that I installed and I manually put the the table some table routes in it. So now for testing purpose yeah? it's been about eleven minutes. Ken do you think that you'll be able to wrap this up in a couple of minutes? it's eleven minutes, sorry. Yeah. Yeah, okay. I will just not go to the many details now, but yeah. So thing is thing is that if we can use use the this this this in protocol contract or and for bigot tables, the Snarkified table proof contracts and and and and yeah I but but also also this this is this is actually this is the last thing that that I want to show now which is that But the rest is like for each table that there's so this this this this proof is for the just one table which covers four million blocks and and and and here this is basically there's no match for this this item in this in this region. And the way it's proven is that here this type two entries from the table, yeah. You can look at it in the EIP what this actually means, but the point is that. These are two adjacent entries in the table, and this one is is this entry smaller than the RapTater contract address, and this one is bigger, so and these these are adjacent. So yeah, this is the multi-proof hashes. So this this is an exclusion proof. There are no matches in this part, and Well, actually, no, this is the exclusion proof. Sorry. And this is the inclusion proof. Yeah. because here there's also a block hash and the transaction hash proven. And this is the transaction hash, you can also just on it scan, you can look up the the the actual result, but yeah, I'm not gonna do that now. And and in this case, we are looking for the first occurrence, and this is these are also just two adjacent entries, and this one is smaller than what we are looking for. And this one is or actually the rep-ither contract address. And this is the so this proves these two entries prove that this is the first occurrence. And yeah, I'm don't think I have more time to spend on this, but yeah, for on the on this page, you can just write. I have just more some more complex examples where like matching also like topics and and and and and matching like consecutive log events and and so there are a few examples and and yeah please take a look at it please if you are find it interesting but have some doubts or questions contact me i really think this this this is a great project and i i i think the results are mostly maybe even a little bit better than I initially expected. So regarding proof sizes and and speed and everything. And I really think that since we also already have to rethink how we use storage and yeah already I talked about this. So we we are considering like new types of state or new types of storage. And I think with this infrastructure, maybe contracts can start experimenting with using logs more to represent their state and and and and actually with these tables in in the state we can even just prove previous logs on chain so i think i think this is this this is also good good good for for cross chain communication so yeah I would really like to have this EIP in Hagota. I think it's realistic and yeah. Please check it out and yeah. Thank you. Okay. great. The last thing on the agenda, is there anything else on the agenda that hasn't been covered outside of AA? Actually, there was one thing that I wanted to bring it up. It's not added on the agenda just yet. Do you want me to go over that in next two minutes before AA? yeah, sure. All right. So I quickly wanted to talk about the open PRs with respect to Hagota as well as Glam Saddam. Shared the link in the chat. we must keep the metaEP up to date because that is the canonical source of upgrade information for the community. And in the list, you can notice that there are many PRs which are waiting on MetaEP author's approval, and there are some conflicts. So I wanted to share some notes for related parties. So, first of all, for the author of MetaEps, both 7773 and 8081, if you create a new PR updating the MetaEP, that automatically gets merged, but that creates the conflict for Any other open PR which are still waiting for your review. So if you want to create that or merge it, please take a look at other open PRs and leave a comment on all related PRs. If there is something missing that you would want the author of the PR should address, please drop a note so the author gets a response and work accordingly. And if you find everything okay, please. straightforward PFI related PRs add your approval so it can be moved forward. In today's call there was a mention of some EIPs which may be dropped from Hegota PFI. I think it was for Helcomine and the reason was also stated. For such PRs which I can see in the list if after this call a comment is added explaining that This is not considered for PFI anymore, so it can be closed. It will be easier for EIP editors and team to close that PR right away. And for authors, I understand that some of your PRs are looking at conflict. Please take a look at it and resolve the conflict, and that will help us figure out with CI failures which you are seeing right now. There are also a couple of places where editors review. Or approval is required. I have marked them accordingly. The goal here is to make this process smoother and let everyone know of their roles and responsibility and let's move these EIPs forward so we have updated MetaE for the community. If there is any problem or anyone is stuck because of tooling or CI or don't know what to do, please reach out to us and my Offer to it's an offer from my end to Meta Ape authors. If you approve these PRs or drop a note for not approving, I promise a vadapau party at Dave Conn Mumbai. So please take a look at it. Thank you, Pooja. I somewhat agree with Barnabas. It might be it might be more productive in the future if we just DM the the blocking authors. It might be faster. And okay, anything else that hasn't been covered? Otherwise we will move on to frames. Okay. so just an update. The last ACDE there was conversation about L2s implementing a different a different standard from frames. frames was CFI's as a placeholder for account abstraction because there was broad consensus that account abstraction was important to ship in Hagoda, just the specific implementation was up up was under debate. there was an AA call this week. There will be ongoing AA calls. and there has been productive conversation between the 8141 authors and the 8130 authors. I think Derek said that he could give an update Derek, do you want to give an update? hey, sure. yeah, so basically like since Wednesday yesterday, we have set up a communication channel between the A130 and the A141 authors. and we all spent like a large chunk of yesterday trying to jam on just to see if we can find a way to either arrive at a shared standards or at the very least find you know to ensure that there is interoperability between the two standards, right? and then as of this morning, the A one four one authors also had a call to just like align on to just align on things. So currently the A one four one position is that basically like we are very basic basically we are happy to work towards two possible outcomes, right? So one outcome that is the best for the ecosystem is to have a shared transaction type. Right. You know, basically we believe that w you know we we we I think we are cautiously optimistic that it's possible to design a shelled transaction type that's is both f flexible and future proof, like frames, you know, which meets the needs of the L one, but also can enable more more opinionated system like A one through zero to be built on top of the transaction type. and we of course want to work with you know like You A14 of course wants to work with A130 on this transaction type. you know, and we know that, you know, to build like a new transaction type will block base and other L2s from going live with A130 as is, which is why, you know, you know, but also of course it will also block you know FREMS from getting SF from getting SFI, right? You know, so for both of those reasons, we will want to time box this you know, this collaboration effort to maybe like the next two two to two to four weeks. you know just just to make sure sure that we don't block you know either the L the L1 or the L2s. now if this best outcome of having like a shell transaction type is not achievable then there's also like a second outcome that we're also very happy to work towards with A130, which is to ensure that at the very least A130 account can work seamlessly across L1 and L2s the same way that a EOA account can work seamlessly across all chains today, right? So basically in this case there will be two transaction types. You know, so there will be the frame transactions and there will be the A130 transactions. But the same account at the same address can still work across chains. it will just use A1 the the the A130 transactions on, you know, any chains that implement A130 and A141, the frame transaction type on any chain that implements A141. Right. So this is the second best outcome because You know, it means that like all the wallets, right? Like all the like block explorers, debuggers, paymasters, or or really just like any toolings that build that that are built around transactions, like inc including SDKs like VM, they will all have to support two transaction types, right? You know, so that's like not really ideal. but at least from the user's perspective, they will have the same accounts at the same address working across chains, right? Like assuming that the underlying toolings integrated with the two transaction types. So yeah, you know, so that's like the second best outcome. if we cannot achieve the f the first best outcome. Yeah. So that's the that's all the over update. Thank you, Derek. Does anybody else want to say anything about about AA? We have another half hour on the call. It is Great, we have some support from eighty one thirty authors and eighty one forty one authors. when is the next AA breakout? I think right now it's scheduled every two weeks, so that means we'll have next week off and the week after we'll be back on. but we are open to doing it weekly for the next month or so, whatever it takes to like kind of get this in a place that people are happy with. Not sure if weekly is too much cadence for people. I'm indifferent, both work for me. Weekly is fine, for on our side. Okay, I mean I think unless any clients who've been contributing a lot to frames feel weekly is too much, then we should just plan on weekly probably same time. We'll just do that for the next month or month and a half and hopefully at that point we'll be able to drop to the bi weekly cadence. Right. And that was Tuesday fourteen UTC? I think that's what it was. Great. so we will aim for final decision on Moving AA to headliner status or not, and what specific EIP by the end of the Hagoda scoping deadline. So along with the other ones. so this will be moving forward until then, and then Hagoda scoping should be done by DEF CON. DevCon is November third. Also happy to start digging into some of the questions here if people have specific things they wanna discuss. Okay. If not, we'll just give people their half an hour back and put on some weekly A. calls after this and Answer. Yeah, maybe then because i if there's no no discussion on the on the actual merits of this, then maybe just as a as a general comment also ca Carlos said it in in chat in terms of like c timeline. I think you're right in the sense with with with by DEF GON that's like I think the the latest on which t timeline on which we we have to have a decision. And if it takes until then I think it's fine to take that time. I would say just because there's real cost here associated with waiting, because obviously there's There were considerations around maybe if we end up making frames, for example, if we go with frames and we make it a headliner, we might want to have kind of shared dev nets with fossil and frames as as fast as possible, these kind of things. all of this, of course, will now for now have to go forward in a more kind of preliminary way because of this ongoing work. As long as there's still active convergence and there's act active progress, I think it's worth paying that price because I think again the pr the the the the potential upside here of keeping the EVM ecosystem from fracturing, I think is very high. So I think it is worth paying that price, but it only only as long as there is real progress. So if already two weeks from now, for example, we feel like there is no longer any progress from the two sides, or four weeks from now or whatever, I think we should then try to basically make the decision sooner. If we need to wait all the way until the end of the scoping window and there's really a lot of progress, sure, we can do that. But I just wanted to say that we should keep in mind that The default should not be to just wait until until they've got to make the decision. Kev, you're welcome to ask the question synchronously. We have lots of time. Yeah, I'm just mainly trying to figure out what are the hard blockers here for us to make a decision. just concretely, 'cause I was in the call this week as well. to make a decision around what? whether we modify eight one four one in like specific ways before we can set it as a headliner, or whether we sorry, I'm just reading what Yeah, I thought it was the key store functionality that was the main thing. Chris is just replying asynchronously. sorry, so is the question, you know, what what is going on from base side or L2 side for like what's our opinion of this or I think the question is why not just call 8141 the headliner if there is an understanding that it can be modified in a way that satisfies the the needs of the L2 ecosystem. I think like eight one four one as it is today. like I think it's ultimately comes down to, you know, 8141 was designed around the L1 goals. Like, you know, and just like there is things in 8141 that we don't want. And I know that, you know, and that's okay. But I'm just just highly in like in the same way eight one three zero is designed for how we want to operate, right? And moving to the frame model does you know cost stuff for us. So this is where where we're just trying to align and like you know what what is the right shape of like frames get like the the I think what we agree on is like the idea of frames being an arbitrary ordering of like you know you know default a verify or an execution frame is more general than 8130. 8130 is like interact with the key store validate and execute. And that's like the only ordering there. so like having a general ordering is fine. I think there's other pieces of 8141 that we don't necessarily want. And that's just kind of I think what you know initial discussions will be, which is just how do we make the ultimate like the frame transaction type itself, just as we're discussing have you know a a simplified key store potentially for L one and you know, I'm not sure if if they want to do that. It seems like not really, but maybe there's a simplified frame model that L one would you know later on a couple of the things they want, even like, you know, the blob gas, et cetera, stuff like that. But I think that's kind of the initial conversations that we'll have. a and maybe just for me because I'm not sort of in the loop, is it clear how we will make a decision here? Like what is the process to not being stuck in limbo? I think we both have like, you know, timelines that we we want to move forward with. And you know, like I I think as was highlighted, like it's probably you know, gonna be, you know, are we making progress week to week? the the outcome of different transports and is is like, you know, a valid one. It's not the ideal one, but It's not like the the worst possible outcome. so I I think we, you know, we just have to both come to the table and just see, you know, where we can align. I don't I don't think we have like, you know, more details than that right now. so yeah, basis timeline there just says, you know, right now we're scheduled to launch 8130 end of September. obviously we need to kind of pause for discussion, but we can also, you know, basically pull 8130 out of our fork pretty late just to highlight that. So like you know, we can definitely discuss And and and not necessarily change our timeline. but yeah. Alec. yeah. I mean I saw that a few people wanted me to give kind of my take on like eighty one forty one and eighty one thirty and like what are the kind of practical opportunities to bridge the gap between the two. I mean I feel like I mean one of the impressions I have gotten is that the two proposals are coming kind of significantly closer together. and it's gotten to the point where I think it's much more productive to kind of not think about these as like two completely different towers that could be built, but as like points in a in a design space that has a lot of dimensions. And we can think about each one of those dem each one of those dimensions kind of independently, right? so like just to give my view on some of those d what what some of those dimensions are, right? So one of the topics that is brought up is sort of the key store thing, right? And to me the key store thing has a couple of different components, right? So one of them, for example, is like, do you do it inside of a contract or do you do it in the account header? And like I believe that it's kind of technically superior to do it in a in a in a header basically because you only need to access one Merkle branch instead of two. And so it's just significantly more efficient. But then, you know, obviously if you want to do something that's sort of like minimum both minimally disruptive and kind of ERC like, then like the contract approach makes much more makes much more sense from that perspective, right? But you know, like if like for example there's alignment on doing more in the header in the header making sense. And that's like something that can be done. another one is this question of you know like do we try to split up parts of the account code that do authenticating from parts of the account code that do things that are not related to authenticating, right? And I mean like this is like a Core ED one thirty feature. it's potentially something that Like eighty one forty one could be modified to handle and of if desired as well. a third one is the transaction type, right? so even if like nothing else changes to these EIPs, like I think the transaction type in is not just about eighty one forty one, it's this kind of broader rethink that basically says we have one master type for a transaction that defines the set of actions it takes and the set of dependencies that it has. and that's something where like the two could be brought could be brought quite a bit quite a bit closer together. and then you know like if you do that then the ben then the benefit base basically is that like in implementation ease for wallets is Of course, going to be a big one. another kind of fourth axis is basically that if like there are certain things where if you move them out of opcodes and like you move move it into a pre compile, then like one other second like kind of second tier goal that we can try to go for is to basically design it so that if some chains support eight one four one and some chains support eight one thirty, then wallets that are kind of designed for like one can still like act like still function in the same way on the other chain by basically using a four through three seven style smart contract like wrapping layer. And like actually yeah doing things through precompiles instead of through opcodes is one of those things that enables that because like opcodes are not something that you can try Like basically if if there is a code path with opcodes if you want to access use it on other chains you'd basically just have to create a totally separate code. whereas with precompiles, like you can always may basically just make the the same thing as like you you basically like write the canonical contract in you know Solidity or Verity or whatever else. and then on some chains it can be a pre compile and on a on other chains it's not, right? So there's this kind of collection of you know like different axes that we can talk about. I mean my personal opinion is that like I don't think we should, you know, do or die, tether ourselves to making like getting to having the exact same EIP across a different chains. But I think like there is this spectrum, right, where the c the the further we move on the spectrum, the more it looks like most of it is like the is the same EIP and then there are some some differences and there are some different difference choices in parameterization. And the mo the further you go in that direction, like that has benefits for wallets. and it also has benefits for transaction senders themselves because like it's essentially it's sort of like tier zero is what like an account only works w like either is an E one forty one account or is an ED one thirty account and like that's just it. And then tier one is if you're an account of one type, then like you can still run on chains that use the other thing with like a four three three seven style smart contract wrapping layer. And then you know, like tier two is basically you get like you start benefiting from more kind of native conveniences, right? So transaction type would be one example, like being able to be being able to benefit better from the mempool would be an would be another example, being able to benefit from fossil envelops and so on would be another. so like I think there's the there's value in big figuring out at least a couple improvements on on the margin in that sense. Though I mean I would even say just like procedurally it could be yeah like it's very reasonable to like just agree on on S one four sorry, eight one four one and then even keep like doing doing more of those refinements even after that agreement. especially once they just start becoming these kind of like minor, like big big set of small changes 'cause they're like this is the sort of thing where there's certainly it might take some amount of a of extra time and like none of these things like really change the fundamental nature of the EIP. but yeah. Thanks, Vitalik. The floor is open if anybody wants. We still have fourteen minutes. I have a item that we could maybe weigh in on. I'd love to hear both the 8130 and 8141 takes on which one gets us faster to post-quantum adoption. it seems to me that that's probably an area of focus in iStar and after. we are going to be working on that pretty quickly. we're gonna need to accelerate our hard work schedule. so specifically I I'd I'd love to hear your thoughts on not only, you know, which which ones give us different options, but it which ones allow us to deploy them faster. And if that's a stupid question, I'm happy to move on to something else. I'm not married to it. Vitalik, do you want to respond? And then we'll go to Tama. Sure. I mean, I can actually answer this from kind of both the 8141 side and a kind of different side that's like kind of connected to 8141 and kind of kind of separate. so af with the after H star in 8141, assuming the gas limits are like on the verification frames allowed in the public VAMP wall are sufficiently high. then you will be able to use Sphinx minus as the yes as the signature scheme. And Sphinx Minus does not require any precompiles because it's hash based and almost all of the work is a hash and we already have the precompile for the hash. and like there's this weird trade-off space between like basically lower gas cost on chain to verify means more time to compute in hardware wallets, and then there's this kind of in progress idea of like a f a pure function signature that would have a higher gas limit and we'd be able to afford the higher gas limit because the fact that it's a pure function means like you literally never have to recompute it and like you could even val verify it at at mempool time. so there's like a very strong pure H star approach to that whole thing. And then There is an iStar approach to this, which is basically that there's this EIP that I mean I wrote this was the one for like post quantum signature and Stark mempool aggregation. And the goal of this is basically that like users would be able to add both like hash based signatures and starks. to their transactions. and then you would actually have this like basically the exact same recursive Stark gadget that you have in lean that that we have for lean consensus with like a few small changes. And then you'd be doing the aggregation all the way in the mempool. And so the only thing that would get into the block is basically just one single Stark. so The path so so if you the the main like really nice thing that that provides is like the way that it would integrate into eight one four one is basically that you would have like a signature type that's essentially just an attestation that says that in the in the blocks master recursive Stark, this particular kind of set of public inputs exists. and the gas cost would be massively lower. basically like the same essentially the same as what we have for you for EC Recover potentially. Like on chain it would cost nothing. The only cost is in the public is in the public mempool. and the and in particular that would be really nice for privacy protocols as well because the status quo is that Post want them to go up to ten million gas. so that so like that's the the longer term vision for how we get to sort of climb back down from having to spend a hundred some a hundred thousand something gas per s per signature. So those are kind of the two like the two tracks and they fit into eight one four one very naturally. Hi. Yeah, I this is not really a response for Justin. It's more like something that was pending from the previous discussion. I just wanted to say that at least from the etherex opinion, it's not generally a great idea to make a separate group without notifying the client teams working on something like account abstractions. I would try to refrain from repeating this in the future, especially if this is going to be presented in the meeting as the outcome of a meeting. I think that we had an official meeting for this, which was the breakout room. and I'm a little bit surprised that the result from that discussion was not the one included in this meeting, but instead what was the take as the result of the collaboration between the teams was something that was made private afterwards. so I I will proceed with at least my take on the breakout room. Everyone is free to do so afterwards. Like if if everyone else wants to say, Hey, no, that's not how I view the results of the breakout rooms, then I can say whatever. but at least from my point of view, and just speaking about the Etherex position on this, I think that Netherman was kind of aligned on this, not sure about Geth, but we can talk that. but at least from Etherex, we consider that we are giving support to AD one forty one mostly because we don't want to enshrine at the wrong level. We consider that the ABM is more akin to hardware, more akin to building a CPU. than building an application level thing. And we feel that AT141 provides the building blocks without enshrining a particular way of doing things. And we are we believe that AT130 is more opinionated and enshrining something very particular. this doesn't mean that the discussion ends here, but that's our position for now. And I think that that's the same position that we showed and talked about in the meeting in the breakout room. So we can continue the discussion and thank thanks guys for including me in in the other group as well. I think that we should definitely move this kind of discussion to some more standard place like S R and D or something like that. But if not, at least let's let's still talk about what happens in the breakout room w without excluding that information. Okay, great. Thanks. Yeah, let's try to keep conversations in ETHRD when possible. and when they are in private DMs, please post updates. They are appreciated by everybody involved. Stavros. Yeah, hello guys. on another mind side, we are also basically it looks like after all these discussions and all these arguments, it looks like it's clear for everybody. even for L2s that eighty one forty one and frames actually are a better let's say mechanism for the future of Ethereum and for scaling it and for providing tooling and functionality. So I'm wondering why we are not deciding on this and obviously be completely open for further feedback and improvements. on top of this decision moving on with eighty one forty one, w what is blood from it? I think the possibility is that there is there could be another EIP written that converges on a on a solution between them, which means the EIP number might change and the spec may significantly change. am I understanding that correctly? I'm not sure. I mean we can just change. eighty one forty one. I mean an EIP can come also after eighty one forty one is decided. I'm I'm not sure what this means. Does it meaningfully impact w what is the outcome that that is that people are hoping for by moving this from CFI to SFI? I guess the outcome is that they keep working, they plan their work on the client teams on something that's decided. Right now there's a lot of work done On something that still remains on the air for some unknown reason. Unless there is a reason and I'm missing it. I mean Do we have any concerns that if it moves to SFI that the ecosystem will start planning on the specific implementation that is as it is written right now? I mean, I'm not I'm not talking about this specific implementation. Obviously the IP is there and we can make adjustments and improvements for the best of Ethereum. we we are always hearing feedback and we are always adapting it. I'm not saying that if we approve it and we SFI it, nothing is gonna change and everything is written in stone, obviously. How do other clients feel? Etherex says SFI, Geth says F SFI, Nethermind says SFI. I know Chris had to jump off the call. Are there any other L two representatives that would feel comfortable with this? I would love to hear any opposition, any support from any anybody. Bahu? Are you guys here? Yep, we're here. We're for eighty one forty one. Okay. Aragon? Anybody from Aragon or Ruth? I'm from Aragorn, but I haven't looked into the EAPs in detail, so I I I don't have a view. Okay. I think if there's if there's very strong support to move it to SFI, I don't think it makes much of a difference if the AA implementation is going to change. we can move it to SFI if there's a strong feeling to do that, as long as the the caveat is there that it may change, the EIP number may change, the implementation may s significantly change. Yeah, I mean the changes on the EP can happen, of course. It's just PRs and discussions, that's fine. But we need to to move on. There is already a lot of work done by F Rex, by Nethermind, on frames, there are also DevNets already spawned up. and we need to keep on working. Okay, does anybody want to voice any opposition? Otherwise we will move forward with this because there is strong support from clients on scar. Yeah, the only thing is, I think I said in chat, like obviously like then it seems like clients want to make the decision today, we'll make the decision today. the one thing I would just say for the record basically is that we then should all agree that the SFI decision should not be in the coming weeks. an argument whatsoever for unwillingness to make spec changes, right? So there should be no one saying, but now it's already SFI'd, work has already continued at higher rate at on top of that specific spec. So now we feel like it's no longer appropriate to make radical spec changes. obviously we might for other reasons not want to do radical spec changes, but the point is that the SFI status should not in any way influence continued inter iteration of the spec coming out of this collaboration process. So as long as we all agree on that. I think there's nothing that's that should block this decision. Yeah, I I totally agree to be honest. And I think it's even better because when something is decided and agreed, also L2s would know what is gonna happen. And they could also prepare themselves and improve it also. I mean, right now even L2s don't know how to proceed, don't know what to do, right? They don't know what we what L one is gonna do. Okay. Then we will move ahead with SFIing frames and continue with frame updates from the AA updates from the AA breakouts and working with L2s and the rest of the ecosystem to make sure that all of these concerns are addressed and that we will ship AA in the next fork. Great. Thanks a lot. All right. Thank you guys.