All Core Devs - Execution #244

Transcript

Nixo: Okay, I think we can get started. Welcome to AllCoreDevs, Execution Number 244. Today is August 27th. Today, on the agenda, we have some Glamsterdam items, we have one miscellaneous item. And then we'll go through Hegota, and the, thought process behind that is that we will, go through some housekeeping items behind to go to timeline. some possible 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. AA conversation. Let's get started with Glamsterdam. Do we have a DevNet update? I think Barnabas was gonna do it today. Stefan couldn't be here.

Barnabas Busa: 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, they have very close to 100% participation.

Nixo: Great. Do we have… so there's gonna be a DevNet 9, a non… a non-finality DevNet, correct?

Barnabas Busa: 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.

Nixo: Okay, great. And how long do we expect that to run?

Barnabas Busa: A few days only. Probably, at most 4.

Nixo: Perfect. That is a good, impetus for us to go through, some… The… Toni? Do you have something to say on that?

Toni Wahrstätter: Yeah, I was wondering if we also want to launch devnet-10 directly, because I assume I should not test, things on devnet, 8, because this is a long-lived devnet, and at the same time, devnet 9 will be non-finality. So I'm wondering if we also need a devnet where we can actually Test some attacks.

Barnabas Busa: Like, Devs 9 is devnetly gonna be the place where you would want to test all your attacks. We don't need that Evilton.

Toni Wahrstätter: Definite 9, you said?

Barnabas Busa: Yeah.

Toni Wahrstätter: But devnet-9 is already, like, under a lot of stress with non-finality.

Barnabas Busa: Yeah, exactly. So, you might as well add more.

Toni Wahrstätter: Yeah, I'm not sure. I would actually try to test things that would cause non-finality and not, like, start with a broken devnet.

Barnabas Busa: I mean, the non-finality period could be, variable. I don't know if you can do a very, very long non-finality, with a thousand node network, so… what we can also do is, 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, Toni, 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 20-25,000, builder deposits, and sparkle in some invalid ones, for .NET9, and we're gonna be doing about, 3 or 4 million validators state, so it's gonna be about, 600-700 megabyte, Justice, said, So it's going to be very stressful for every client.

Nixo: Great. Thank you. Can you guys see my, my… Window right now.

Justin Florentine: Yep.

Barnabas Busa: We see it on the whole screen. the JS window.

Nixo: Okay, great. So this… this is a rough calendar. Obviously, this is gonna depend on how these DevNets go, but I just wanted to, like, highlight how.

Barnabas Busa: Can you zoom in, please?

Nixo: Yeah. How tight we are on… on timeline. So… these are, EL weeks, EL weeks, and basically, we're gonna come up to this, Security is… we're gonna… once… So, September 28th has been, floated as the, day that Sepolia forks for Glamsterdam, and Hoodi 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 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. firm 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… Lido 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 you're, aligning on a history expiry retention window item was, Brookly Amsterdam, Do you want to say anything about that?

Kevaundray Wedderburn: 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 CL 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. Erigon, I believe, says they'll look into it. Geth has agreed to it, but, would be good to get an update on where we are. Ethrex is looking into it. I believe there's an EIP, sorry, a PR up. And Reth says that they could have it in the next release.

And just to, clarify, like. Currently, 2TB nodes, 2TB nodes are sort of hidden up the limit. that roughly we're at, like, 1.5 to 1.8, so if we launch Amsterdam without expiring a lot of the history. They potentially will just not have enough storage left. Yeah, sorry, Nethermind also implemented it. The PR was linked in the PM issues. And yeah, if there's no contention with just modifying 4-4s, I'll just, create a PR to update it to have, 33,000 e-books.

Nixo: Great, and you have, confirmation from the other clients that they are also, working on that to be ready for Client Studio?

Kevaundray Wedderburn: I think Geth has agreed to it, but, I'm not sure when they were planning to do it, if anyone from Geth is on the call. It would be good to get an update.

Nixo: Do we have a Geth person on the call?

Kevaundray Wedderburn: I can follow up async as well,

Nixo: Okay, good. Sounds good, thank you. And we'll throw in your most selenous item, just so that we can dedicate the end of the call to frames. Do you want to talk about PQ readiness?

Kevaundray Wedderburn: 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 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 precompile, or a deposit transaction, or a deposit opcode. I was hoping to get some… Opinions, rough opinions on… What are people's thoughts on this?

Lightclient (Matt Garnett): Personally, I think I'm lightly in favor of an irregular state transition.

Kevaundray Wedderburn: Ben from… okay.

Ben Adams: I'd prefer not to set a precedent of changing a contract. It's fine. But, yeah, it opens the door to the idea that we can change contracts.

Justin Traglia: I mean, this would just be a special case, no.

Ben Adams: Yeah, but then… then the government might say, well, make a special case for us, too.

Justin Traglia: That's fair.

Kevaundray Wedderburn: 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 2 years, and then this new deposit contract will have a reversion in it. Ben?

Ben Adams: If… if we do something like, The binary tree, or, you know, a massive state. reorganization. I think it would be… More acceptable to do, an irregular state transition at that point, because we can I 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 other things, like… Burn everything in the deposit contracts.

Kevaundray Wedderburn: 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 EF that's inside of it? And,

Ben Adams: Yeah, because at that point, it's, it's happening as part of something that we can't easily reproduce. We're not… if that makes sense. Just… just in terms of… Precedent of how easy it is to change things.

Kevaundray Wedderburn: Right. And then, would you also be okay with, modifying the Beacon deposit contract to add the PQ functionality, or is it just burning…

Ben Adams: Oh, no, no, I… yeah, whatever. Because, I mean, at that point, we were rewriting everything, so…

Kevaundray Wedderburn: Okay, okay, I see. Alright, thanks. Does anyone else have any feedback on this at some point? Isn't that decent?

Nixo: 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 Ryujin. Eth… simulate B1 issues. I haven't had a chance to look at what that is, but Chase, are you on the call? Yeah.

Chase Wright: Yeah, I'm here. I mean, for the most part, like, this… so, Eat 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.

Nixo: Can they follow up async, or is that, something.

Chase Wright: Yeah, yeah, yeah, it sync's fine.

Nixo: Okay. There is another item, from Milanite, and this is a, modification that's being requested on 8037. Milanite, are you here?

Milos Costantini: Yeah. Yeah, can you hear me? Yep. Okay, cool. Yeah, this is because it has been removed, the gas refill for the self-destructor. Basically, I want 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 intents, routing, bridging, I mean, there are a lot of actual use cases. The service truck 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 a service truck, then you just blot the state. power from American, I don't think he joined, but… Help, creating the… Pr for this?

Which are linked. So… Yeah, if anyone has any question or comment, I'm happy to talk about it. To, to give some context, this basically for applications that, uses, These ephemeral contracts will mean an increase of 7 times per transaction, and on Ethereum, it's not sustainable, and we'll move this use case only on the year two.

Nixo: Maria?

Maria Silva: I just wanted to add a couple of comments. So, I think, Milos, you commented that we should add the rationale for why this is being removed to the EIP, and I devnetly agree with that, and I will… I'll add that. But to give maybe some context there, the rationale at the time was that, So, initially, we wanted to make 8037 track So the metering we're doing on 837 would be as accurate as possible, so you would only charge if you are 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 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 opcode 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 Glamsterdam. 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 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 add-up code, or… Even, like, 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 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 wouldn't expect it to be huge. And also, in terms of impact, I was looking at

a 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… What's it? Sorry, I should have the number already.

Milos Costantini: Yeah, yeah, it's more an emerging paradigm rather than… Like, it's not super common today, but more and more. Intent protocols are, something to you?

Maria Silva: Today, the usage is an average of roughly 100 1,500 accounts per day are created and self-destructed in the same transaction. And this accounts for roughly… so if we just account for the leaves, this would account for roughly 62 megabytes of state per year. So 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 the EIP to make the rationale clear, and I do agree that this should be a discussion we take into Hegota, like… and I think the right approach is not to change AC37, but it's actually to think a bit

More deeply into how this should work. In the protocol, and then implement the right solution, not just the… Like a… how do you say, like a… a band-aid.

Milos Costantini: Right, I agree that selfish structure is deprecated. It's more like, I think, could do more harm than good, not including dairy fields. Because… we don't have an alternative, and I understand the gas cost will be much lower, but here we are talking about 10 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 the 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 a year, I understand that

And I agree that there should be an opcode for this. Though I would 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's… But yeah, this is my argument, I'm not… very familiar on the whole EIP flow.

Maria Silva: Yeah, maybe I just want to point a little thing. It's like, it's true that it's a 10 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 10 times, because the base fee will go down. So I really want to stress this, like, it's not… will not feel like a 10-time increase for the end user.

Milos Costantini: Yes, I understand this, but these female contracts are usually meant to be used As a single transaction, so we'll 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 200,000 gas. Overhead.

Nixo: Given that there aren't that many of these transactions today, and there is an EIP that was related, that was proposed for Hegota, is it problematic if we Take this offline to work on something for Hegota that would satisfy That… that would mitigate this issue?

Milos Costantini: I mean, for sure, Gotta needs to have, a proper EIP for this, and the brigade self-destruct. My argument is only for a glamps in them.

Nixo: Yeah, I think it is quite late in the process, and I assume, Maria, that this would, a change to this would require changes, in client code. And would set…

Maria Silva: Right.

Nixo: What's it?

Maria Silva: Yeah, it requires spec changes, client code changes, more testing, so yeah, I tend 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 a fork or Devs, so if there are any strong feelings that we should do it, I'd like to hear.

Nixo: Okay, why don't we call the, the related, opcode a PFI, a placeholder for a solution for this in Hegota. And… Milos, can you follow up with something that will, that will mitigate this for… for Hegota.

Milos Costantini: Yeah, I mean, Freda, there are already some EIP proposed, and it's… yeah. Probably one, two years ahead, so…

Nixo: 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?

Ansgar Dietrichs: Yeah, just to set the expectations, I think, one shouldn't just be like, yeah, Hegota, and then just move on and say, okay, let's think about this in 6 months. Like, these Hegota EIPs might be rejected and, or potentially, like, will need arguments for acceptance as of 2 weeks from now, so… basically, if this is something important, then this needs to be brought forward, decided, discussed in the next 2-4 weeks, otherwise it will not be in Hegota. So just flagging it, that we can't just be like, in 2 years, let's talk about it at a later time, like, if this is important, this needs to be important in 2 weeks, in four weeks.

Nixo: Good point, thank you. Okay. Yeah, if you could… you and Milos and Helkemin, aka ABC, and could work with, the 8037 authors, or the gas repricing, group. to work on a solution for this, and Hegota, yeah, I would get that in. In the next couple of weeks. Okay, let's move on to other things in Hegota. Is there anything else Glamsterdam-related? Great. So, for timeline client preferences, we're… 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 easy DFI, so that we can start, working on that, because we will then have 3 calls after that to do Hagota 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… I'm gonna… EIP champions, please show up to the following, 3 or 4 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 Helcomind, aka ABC123. 8360 was sort of already talked about. We have 7609 decreased base cost of T-load T-Store, and 8058 contract bytecode 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, Helcamine is on the call, or anyone wants to speak for these. If not, they will be dropped from PFI.

Ben Adams: For the contract code deduplication, that was where, sort of, set code from came from. So it achieves the same goal, but in a more general way.

Nixo: Okay. So that leaves $17609 decreased base cost of T load, T-Store. If no one speaks for them, then, All three of these will… will be dropped, and, with the caveat that one That, it will be a placeholder for whatever the solution is that, About the issue that we just talked about.

Maria Silva: Oops. just make sure we are saying that the temporary create EIP will not be false for Hegota. Is this correct?

Nixo: 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, 7609, and I guess 8058 is also related to that, But 7609 will be dropped. Okay. Next, Schult had a, presentation he wanted to give about, the Trustless Log and Transaction Index, and demo the proposed API. Schulte, are you on the call?

Zsolt Felföldi: Yes, I am here. Okay, so, let me just, share my screen. Hmm? Okay, can you see my screen?

Nixo: Yes.

Zsolt Felföldi: Alright. Yeah, so, So, I just quickly wanted to show, like, some of the progress that happened with this Trustless Log Index project, well, because… I think it's, it's, already in pretty good shape, and, and yeah, like, claimed the rankings in two weeks and everything, and I have this not-so-hidden agenda to just encourage, every one of the clients to look at it, and, and maybe… Yeah, consider, ranking it as something preferred, so yeah, So, 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 8304,

which I already presented, like, 2 months ago. And and so, just to 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, an API is something that will 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 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 yeah, 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 AIP. It can serve, prove mechanical block hashes from the entire history. It can, prove the inclusion position of a transaction hash or an exclusion proof. If it's not canonical, which is a

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 I can even show you at the end some proofs, because I already set up a node which is… very low bandwidth, it's running on my home internet, so later I will probably just rent a 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 on 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, I will show the proofs 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… 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 the Beaconlight client, so the client can also specify the latest head it knows about, and then, yeah, it has to be recent, because we need the 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 you just want to look up something, some event that happened once in the entire history, then this proof can be, like, tens of kilobytes, so under 100K, maybe. 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 For most use cases, maybe the latest matches might be important, like, for a 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's specified so that the prover kernels can also limit the query if it's too much, and yeah. But the really… Interesting thing is the search patterns. So, the…

like, classical JSON RPC log query, also can spec… 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 has its JSON encoding, and yeah, so that's a 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 the wrapped Ether. book events, and, and there's, you can, you can construct, recursively construct, end or relationships, so you can basically do what, what the JSON RPC request can do.

And, there's a third interesting thing you 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 just… yeah. the design can do it, and maybe… so 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 offset thing just does, okay, it hears this pattern, but match this to the… to the log after the one. Yeah, so here's the pattern for this log, and here's the pattern for the next log, 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 these… these proofs actually look. So, I still need to work on, like, like, the exact specifications of how to 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 already prepared some test requests, like, here's test request 1, the first occurrence of the wrapped ITER contract address… yeah, let me just… Oh… 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 hmm… So this… so this is… this is, here, does 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 certain value, and also there's the… the limitation, like, like, one, One item, 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… we need the state root, yeah, so… so from the state root, we can look into… into the index contract, and, yeah, the rest is all this big…

like, MPT, to try notes 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 running on mainnet now, and this EIP doesn't work on mainnet yet, so… 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 some table roots in it.

So now, for testing purpose… Yo?

Nixo: It's been about 11 minutes, can, do you think that you'll be able to wrap this up in a couple of minutes?

Zsolt Felföldi: Oh, it's 11 minutes, sorry, I lost 3 of the time. Yeah, okay, I will just not go into the many details now, but, yeah, so thing is, thing is that we can use, use the, this, this, this in-protocol contract, or, and for Beacon 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 I want to show now, which is, That, that the rest is, like, for each table, that, there's, so this, this, this, this proof is for just one table, which covers 4 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 these type 2 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 is smaller than the Raptor 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 on the transaction hash proven, and this is the transaction hash. You can also just underneath the can look up 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 actually the replicator contract address, and this is the… so this proofs… these two entries prove that this is the first occurrence. And yeah, I 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 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 find it interesting, but have some doubts or questions, contact me. I really think this is a great project, and I think the results are…

mostly, maybe even a little bit better than I initially expected, so regarding proof sizes and speed and everything, and I really think that, since we already have to rethink how we use storage, and yeah, already I talked about this, so… 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 actually, with these, tables in… in the state, we can even just approve, previous logs on-chain, so I think… I think this is… this… this is also 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.

Nixo: Thank you all.

Zsolt Felföldi: about it more later. Thank you.

Nixo: Okay, Great, the last thing on the agenda, is there anything else on the agenda that hasn't been covered outside of AA?

Pooja Ranjan: 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 the next 2 minutes? before EA?

Nixo: Yeah, sure.

Pooja Ranjan: Alright, so I quickly wanted to, talk about the open PRs with respect to Hagota, as well as Glamsterdam, shared the link in the chat. We must keep the Meta EAP 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 Meta EIP 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 Meta Epps, both 7773 and 8081, if you create a new PR, updating the Meta EP, 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 author gets a response and work accordingly. And if you find everything okay, please, straightforward the 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 Hagota PFI. I think it was for Helcomind, 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 editor's 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 responsibilities, and let's move these EIPs forward, so we have updated Meta EAP 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 Mehta EIP authors. If you approve these PRs or drop a note for not approving, I promise a Vada Pow party at DevCon Mumbai. So please take a look at it.

Nixo: 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 a conversation about, L2s implementing a, different… a different standard from, Frames, Frames was CFI'd as a placeholder for account abstraction, because there was broad consensus that account abstraction was important to SHIP and Hegota, just the specific implementation was, 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?

Derek Chiang: 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 standard, 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 A141 authors also had a call, to just, like, align on… to just align on things. So, currently, the A141 position is that, Basically, like, we are very… basically, we are heavy 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, you know, I think we are cautiously optimistic that it's possible to design a shared transaction type

That is both flexible and future-proof. like frames, you know, which meets the needs of the L1, but also, can… enable more… more opinionated systems, like A130 to be built on top of the transaction type. And we, of course, want to work with, you know, like, you know, 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, but also, of course, it will also block, you know, friends from getting SFI, right? You know, so for both of those reasons, we would want to timebox this, you know, this collaboration effort to maybe, like, the next two to two to four weeks.

You know, just to make sure that we don't block, you know, either the L1 or the L2s. Now, if this best outcome of having, like, a shared 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 UA account can work seamlessly across all chains today, right? So basically, in this case, there would be two transaction types, you know, so there would be the FRAM transactions, and there would be the A130 transactions. But the same account at the same address can still work across chains. It will just use A1… 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 really just, like, any toolings that are built around transactions, like, 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 tooling is, integrated with the two transaction types. So, yeah, you know, so that's, like, the second best outcome, if we cannot achieve the first best outcome. Yeah, so that's the, that's the overall update.

Nixo: Thank you, Derek. Does anybody else want to say anything about, We have another half hour on the call. It is… Great, we have… Some support from 8130 authors and 8141 authors. When is the next AA breakout?

Lightclient (Matt Garnett): I think right now it's scheduled every 2 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.

Chris Hunter: Weekly is fine, for, on our side.

Lightclient (Matt Garnett): 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. And 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.

Nixo: Great, and that was Tuesday, 14 UTC?

Lightclient (Matt Garnett): I think that's what it was. Yep.

Nixo: Great, so we will, aim for a final decision, on, moving AA to, headliner status or not, and what specific, EIP by the end of the Hegota, scoping deadline, so along with the other ones. So this will be moving forward until then, and then Hegota scoping should be done, by DEFCON. DEVCON is November 3rd.

Lightclient (Matt Garnett): I'm also happy to start digging into some of the questions here, if people have specific things they want to discuss.

Nixo: Okay, if not, we'll just give people their half an hour back, and plan on some weekly AA calls after this, and Ansgar?

Ansgar Dietrichs: Yeah, maybe then, because if there's no discussion on the actual merits of this, then maybe just as a general comment, also Carlos said it in chat, in terms of, like, timeline. I think you're right in the sense with… by DEFCON, that's, like, I think the latest on which… timeline on which 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 FOCIL and frames 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 active progress, I think it's worth paying that price, because I think again, 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 only as long as there's 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 they've got to make the decision.

Nixo: Yep. Kevi, you're welcome to ask the question synchronously, we have lots of time.

Kevaundray Wedderburn: Yeah, I'm just, mainly trying to figure out what are the hard blockers here for us to make a decision. Just concretely, because I was in the call, this week as well.

Nixo: To make a decision around what?

Kevaundray Wedderburn: Whether we modify 8141 in, like, specific ways before we can set it as a headliner. However, we… Oh, sorry, I'm just reading what… Yeah, I thought it was the keystore functionality that was the main thing. Chris is just replying asynchronously.

Chris Hunter: Sorry, so… is the question, you know, what is going on from base side or L2 side for… Like, what's our opinion of this, or…

Nixo: 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.

Chris Hunter: I think, like, 8141 as it is today, like, I think it ultimately comes down to, you know, 8141 was designed around the L1 goals, like, you know, and just to, 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 highlighting, like, in the same way, 8130 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 we're just trying to align, and like, you know. what is the right, shape of, like, frames? Like, the… I think what we agree on is, like, the idea of frames being an arbitrary ordering of, like, you know.

you know, default, 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… ultimately, like, the frame transaction type itself? just as we were discussing, you know, a simplified key store, potentially, for L1, and, you know, I'm not sure if they want to do that, it seems like not really, but maybe there's a simplified, frame model that L1 would, you know, layer on a couple of the things they want, even like, you know, the blob gas, et cetera, stuff like that.

I think that's kind of the initial, conversations that we'll have.

Kevaundray Wedderburn: And maybe just for me, because I'm not sort of in the loop, is it clear how we will make a decision here? I like… What is the process to not being stuck in limbo?

Chris Hunter: I think we both have, like, you know, timelines that we want to, move forward with, and, you know, like, I think… as was highlighted, like, it's probably, you know, gonna be, you know, are we making progress, week to week? The outcome of, different transports and… is, like, you know. A valid one, it's not the ideal one. But, it's not, like, the worst possible outcome. So, 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 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 devnetly discuss, and not necessarily change our timeline, but… Yeah.

Nixo: Alec?

Vitalik Buterin: Yeah, I mean, I saw that, a few people, wanted me to give, kind of my take on, like, 8141 and, 8130, 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 AI 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, you know, 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, each one of those dimensions, kind of independently, right? So, like, just to give,

my view on some of those… what some of those dimensions are, right? So… one of the topics that is brought up is kind of the keystore thing, right? And, to me, the keystore 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 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 he wants to do something that's sort of, like, both minimally disruptive and kind of ERC-like, then, like, the,

a contract approach makes much… 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, like, this is, like, a core 8130 feature, it's, potentially something that, like, 8141 could be, yeah. modified to handle, kind 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… the transaction type in,

is not just about 8141, 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, yeah, could be brought, quite a big, Quite a bit closer together, and, then, you know, like, if you do that, then the benefit, base… basically, is that, like, you know, 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 precompile then, like, one other second, like, kind of second-tier goal that we can try to go for is to basically, yeah.

design it, so that if some chains support 8141 and some chains support 8130, then wallets, that, are kind of designed for, like, one, can, still, like, act on, like, still function in the same way on the other chain by, basically using a 4337-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 there is a code path with opcodes, then if you want to access… use it on other chains, you basically just have to create a totally separate code. Whereas with precompiles, like, you can always, basically just make the… the same thing as, like, 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 precompile, and,

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 the difference chains, but I think, like, there is this spectrum, right, where 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 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 0 is, what, like, an account only works, like, either is an E141 account or is an E130 account, and, like, that's just it. And then Tier 1 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 4337-style smart contract wrapping layer, and then, you know, like, Tier 2 was 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 benefit better from, the mempool, would be, yeah. And that would be another example. Being able to benefit from fossil Invops and so on would be another. So…

Like, I think there's, the… there's value, in, 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… I just, agree on S14, sorry, 8141, and then even, keep, like, doing what… Doing more of those refinements, even after that, agreement. Especially once they just… start becoming these kind of, like, minor, like, big set of small changes, because, they're, like, this is the sort of thing where there's, So, like, it might take some amount of extra time, and, like, none of these things, like… really change the fundamental nature of the EIP, but, yeah.

Nixo: Thanks, Vitalik. The floor is open, if anybody wants. We still have 14 minutes.

Justin Florentine: 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 H-star and after. We are going to be… Working on that pretty quickly, we're gonna need to accelerate our hard fork schedule. So specifically, I'd love to hear thoughts on not only, you know, which ones give us different options, but 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.

Nixo: Vitalik, do you want to respond? And then we'll go to Tomas.

Vitalik Buterin: Sure, I mean, I could 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, after H-star in 8141, assuming the, gas limits are like, on the verification, frames allowed in the public mempool are sufficiently high, then, you will be able to use Sphinx Minus as the, 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 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'll literally never have to recompute it, and, like, you could even 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, H-star approach, to this, which is, basically that there's this, EIP that's, 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 we have for lean spec, 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 main, like, really nice thing that that provides is, like, the way that it would integrate into, 8141 is basically that you would have, like, a, signature type that's, essentially just an attestation that says that in the, in the block's master recursive stark, this particular kind of set of public inputs exists, and, the gas cost would be massively lower, and basically, like, the same… essentially the same as what we have 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-quantum may go up to 10 million gas, so… That… so, like, that's, the longer-term vision for how we get to sort of climb back down from, having to spend some… 100,000-something gas per, per signature. So, those are kind of the two Like, the two tracks, and they, fit into 8141, very naturally.

Nixo: Tomas.

Tomás Arjovsky: 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 Ethrex 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 will 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 will proceed with at least my take on the breakout room. Everyone is free to do so afterwards. Like, 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 ethrex position on this, I think that Nethermind was kind of aligned on this, not sure about GetH, but… We can talk about that. But at least from Ethrex, we consider that we are giving support to 8141, mostly because we don't want to enshrine at the wrong level. We consider that the EVM is more akin to hardware, more akin to building a CPU than building an application-level thing.

And we feel that 8141 provides the building blocks without enshrining a particular way of doing things, and we are… we believe that 8130 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 thanks guys for including me in the other group as well. I think that we should devnetly move this kind of discussion to some more standard place, like SR&D or something like that. But if not, at least let's… let's still talk about what happens in the breakout room.

Without excluding that information.

Nixo: Okay, great, thanks. Yeah, let's, try to keep, conversations in ETH R&D when possible, and when they are in private DMs, Please post updates. They are appreciated by everybody involved. Stavros?

Stavros Vlachakis: Yeah, hello guys, on Nethermind 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 81, 41, in 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 8141. What is blocking it?

Nixo: 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 in the spec, may significantly change. Am I understanding that correctly?

Stavros Vlachakis: I'm not sure, I mean, we can just change 8141, I mean, an EIP can come also after 8141 is decided. I'm not sure what this means.

Nixo: Does it meaningfully impact what is the outcome that, that is, that people are hoping for by moving this from CFI to SFI?

Stavros Vlachakis: 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 readon and I'm missing it, I mean…

Nixo: 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.

Stavros Vlachakis: I mean, I'm not… I'm not talking about this specific implementation. Obviously, the EIP 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.

Nixo: How do other clients feel? Ethrex says SFI, Geh says SFI. Another one says SFI. I know Chris had to jump off the call. Are there any other L2 representatives that would feel… Comfortable with this? I would love to hear… Any opposition, any support from any… anybody? Besu? Are you guys here?

Justin Florentine: Yep, we're here. We're 48141.

Nixo: Okay. Erigon? Anybody from Erigon or Reth?

Andrew Ashikhmin: I'm from Erigon, but I haven't looked into the EIPs in detail, so I don't have a view.

Nixo: 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 caveat is there that it may change, the EIP number may change, the implementation may… significantly change.

Stavros Vlachakis: Yeah, I mean, the changes on the EIP can happen, of course, just PRs and discussions, that's fine, but we need to… to move on. There is already a lot of work done by Ethrex, by Nethermind on Frames, there are also DevNets already spawned up, and we need to keep on working.

Nixo: Okay, does anybody want to voice any opposition? Otherwise, we will move forward with this, because there is strong support from clients. Ansgar?

Ansgar Dietrichs: 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 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 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.

Stavros Vlachakis: Yeah, 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 Juan is gonna do.

Nixo: Okay. Then, we will move ahead with SFI 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.

Stavros Vlachakis: Great. Thanks a lot.

Nixo: Alright, thank you guys.

Potuz: Goodbye.

Stavros Vlachakis: Megas.

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