All Core Devs - Execution #229

Transcript

Pooja Ranjan: Real life.

Ansgar Dietrichs: Perfect. Then welcome, everyone, to All Core Devs 229. the first one after we have our… all of our main scoping decisions done, so this is nice, we can focus on other things now. We still have quite a packed agenda, actually, so let's just dive in. First, some housekeeping. Specifically, there are not one or two, but three different, breakout calls. That will all start within the next 2 weeks. that wanted to briefly announce that, that they're getting going, and the first one up is Antonio, who wanted to present the post-quantum transaction signature breakout call. Antonio, are you on the call?

Antonio Sanso: Yep, I'm here. Thanks, Asgar. I promise you, I don't steal a lot of time. Pretty quick, so, you've probably seen the announcement from Justin last week about this new post-quantum acceleration from Ethereum in general, and we have this post-quantum transaction signature breakout room, starting next week. We kick off with, February the 4th, 3 o'clock. The agenda, is already kind of ready, it's on the link. Everyone is welcome to join, I'm looking forward to starting this, and that's about it. Thanks a lot.

Ansgar Dietrichs: Perfect. Thank you, Antonio. The second breakout call, to be announced is the L1ZKVM breakout call. I think, Kev, if you're on the call, you wanted to briefly announce this?

Kevaundray Wedderburn: Yeah, yeah, so we have the call on February the 11th at 3pm UTC. It doesn't coincide with Antonio's, call. I can post a link in the chat, right now.

Ansgar Dietrichs: Sounds good. And then… The third one, I think, Maria, you wanted to announce a record call specifically around the Glamsterdam. Is that right?

Maria Silva: Right, so, we are kicking it off next week, so it will be a bi-weekly call on Wednesdays, 2 p.m. UTC, so the next one will be, February 4th. So it's, in the same slot as the block-level access list, but one week, one week off. And yeah, the focus will be just all implementation details and specifications for all the repricing CIPs for Amsterdam.

Ansgar Dietrichs: Sounds good. And just because there were so many, calls, announced, you know, just as a reminder, of course, these are all, like, specialist calls, so there's absolutely no need for everyone to feel the need to attend all of these. It's about if this touches something that you are directly involved with, then this is probably a call for you. Awesome. Then, up to the next agenda item, which is a few different Glamsterdam-related topics, mostly around DevNets and DevNet planning. First, I think we have, Stefan, who wanted to give an update on DevNet 2. Is that right, Stefan?

Stefan Starflinger: Yeah, sure, I'll give an update. I'll share the latest, DevNet 2 document in the chat. I updated some parts of the document. I'd like to highlight just some clarifications to EIPs. I added, like, a new emoji next to them. Specifically for 7708, there were some clarifications made during the development and, also the changes to 77… 7-8, where the receipt field was removed. If clients could take a look that they are aware of all those changes, I summarized them in the document. And we came to a launch date for DevNet 2 on the 4th of February, so next week. So, it would be great if all clients could be ready by then, and I trust that we will be able to, and I think clients have already made a lot of progress.

And also, another part on this, for this document is, client feature flags. There, I added a section where clients can enable and disable optimizations. This is already filled out with Besu feature flags, but it would be great if other clients could communicate the feature flags that they have, so that we can benchmarks. benchmark BAL against, not having BALs active in the DevNet, and then later on in, ShadowFarks as well. I think that's pretty much it.

Ansgar Dietrichs: Sounds good, thank you for the update. Are there any, comments, any other topics specifically related to DevNet 2, dial DevNet 2, that anyone wanted to bring up? Otherwise then, next up, and these… this is, the next two items are related more to DevNets going forward, but also specifically this one also directly for DevNet2, which is the… a block-level access list specific, client optimization. So, just as a reminder, block-level access list, obviously there's the base spec compliance, but then on top of this, there's four distinct, optimizations to actually make use of the new possibilities BALs enables. That's the parallel execution, the batch reading. Parallel state root calculation and the sync. And there was some desire to formalize to what extent, these optimizations are basically expected as part of the Glamsterdam scope.

and their relative priorityization, and so on. And first, I think Tony, I wanted to give a quick update on that side of things, specifically.

Toni Wahrstätter: Yeah, so from the pilot optimization side. things look quite good, I would say, so we now have GEF and Beso being ready, having all three what I would call the more mandatory optimizations implemented, which is parallel execution, the batch reading, and the parallel post-state root calculation. I think also NetherMind has all three optimizations ready, have to check in with them. So, from that perspective, we are ready to test and benchmark the whole thing. And we should also be ready to then have the first shadow forks against mainnet, or even BloatNet, in order to Test, how much we get from the state locations in the BAL, because this is still an open item that we needed the optimizations for, and we are now ready to actually find that out.

Ansgar Dietrichs: Sounds good, and yeah, you mentioned the state locations, because yeah, that's one of the two sides of BALS, and my understanding was also that also from the repricing side, kind of the… this kind of these batch read optimizations are actually relatively important. Maria, I think you wanted to say a few things about this?

Maria Silva: Yeah, so I just wanted to stress the importance of having a cohesive set of optimizations, and I think the batch reads are an important one, because For… for instance, for parallel execution, it's… Final. Easy to reason about what sort of Gains in terms of runtime we'll get, but for the batch reads, it's still a big unknown, and so for us to take that into consideration when we are doing the repricings, we really need to have the optimizations in place, so then we can benchmark them. And in terms of timeline, in order for us to have enough time to benchmark and test everything. ahead of Interop events, in April, I would say we need to have the core optimizations done by the end of February, so that we can start then

Benchmarking the operations we are repricing.

Ansgar Dietrichs: Right, and so basically, in a way, to synthesize this, both of Tony's and Maria's comments, is I think the proposal would basically be that we formalize the expectation that not just the BAL-based spec compliance, but also these, individual optimizations basically are part of the… official kind of fork, readiness expectation. With the nuance that I think the fourth one, which is the sync, I think is more up to the clients, if you, have the feeling that you need this in order to have efficient sync. and under higher throughput levels after the fork, then that's more up to the individual client, but the other three optimizations would basically be part of the official fork scope. And with the specific ask to prioritize the, the batch read one, first in that process. So, so the question would be, is that…

Is that okay with clients, or is there any objections? Maybe one of the optimizations that any client doesn't feel comfortable with being able to support in time for the fork, or can we basically make that decision? Andrew?

Andrew Ashikhmin: Sorry, I have a… Probably a stupid question. What is the sync optimization?

Ansgar Dietrichs: Yeah, that one, maybe I'm a little just too, imprecise. So this is primarily for… just for, I mean, I guess, sorry, Tommy, maybe you can give more precise context.

Toni Wahrstätter: Yeah. The sync optimization was basically using, the block lab access lists. for the healing phase in SnapSync. So this might not even apply to all of the clients, but it does for GAF, for example. And so it's one of those optimizations that you can use, but you don't need to use, because it's not something in the critical execution path.

Andrew Ashikhmin: Right, I see, thank you. Yeah, okay, so, in Aragon, we, we've been working on parallel execution and, like. Started to think about parallel state root calculation. But I don't think we have anything in the works in terms of batch reads. So basically, you are saying that we should prioritize batch reads.

Toni Wahrstätter: I mean, we needed it at least for a few clients, because what is currently very important is finding out if we even need the state locations in the block access list, and for that, we need at least some data points of at least a few clients to determine, is it important or not. In the end, when it comes to the fork, I would assume that We don't even need to explicitly say which optimizations need to be implemented, but we can more, like, implicitly set the gas limit To a certain point, where… yeah, clients that we used for benchmarking are basically fine with it. And I assume we will just use all clients for benchmarking. So, in the end, all the clients, I assume clients will just have all the optimizations implemented.

Andrew Ashikhmin: Understood. Thank you.

Maria Silva: No, sorry, sorry, Tony, I think it's important to clarify something. So, I don't think that's true for the repricing side. So… If we… so, we need to understand how much State access, so reads and writes, perform in comparison to compute operations. In order for us to price them correctly. So if we don't assume any optimizations, then we'll be pricing state reads and writes much more expensive in relation to compute, and so then they will be… a bottleneck, right? Like, we could increase the block limit, but for those operations in specific, the throughput is much lower. So that's why it's important by end of February to have a base set of optimizations that we all agree will go in, so that then we can

Do the repricings, taking those into consideration, because otherwise, we'll be performing in a lower throughput than we could.

Toni Wahrstätter: Yeah, yeah, we're saying the same. So, I was referring to the baseline being all optimizations implemented, and not none of them. So, we just use GAF and BESO for now, because we know they have all the optimizations implemented already, so we don't even need to wait until end of month, because I think at least, from Besu' side, what I heard is that they are more than ready with their batch I.O, implementation. For GAF, we can double-check, with Jared. If they're ready too, but it looks like we… we have the optimizations ready for the benchmarking.

Maria Silva: Okay, but then… but then we need to agree that by end of… By the fork, all clients have those optimizations in place, because otherwise we'll be creating bottlenecks on those clients, right?

Toni Wahrstätter: Yeah, I mean, those clients will not be able to keep up with the chain, basically. If you… if we go to a gas limit where all optimized clients are fine with it, then a client that hasn't optimized won't just be able to keep up, I assume. So this is like an implicit… Assumption here.

Csaba Kiraly: It's great.

Ansgar Dietrichs: And then… Can we… just to bring it back into the full group, Sorry, Saba, you wanted to say something?

Csaba Kiraly: Yeah, I was saying it's still hardware and resource dependent, so it's… it's not that the client cannot keep up, it might need higher resources, so…

Toni Wahrstätter: Right, yeah.

Ansgar Dietrichs: Yeah, and… I think we can…

Toni Wahrstätter: that all optimizations are ready by the fork. I think that's a fair assumption.

Ansgar Dietrichs: Yes, I want to double-check with Andrew, from the Aragon point of view, do you feel comfortable, at least for now, moving forward with the understanding that by the fork, all optimizations should be ready, and then… During the process, of course, we can… we can always revisit the scope of the fork and possibly downscope, but is that at least a reasonable target?

Andrew Ashikhmin: Yeah, sounds good.

Ansgar Dietrichs: Okay, then I would say, for now, we just, just basically we clarify, the three main optimizations, basically expected to be part of the fork scope. We can revisit this if closer to the fork. Not all the clients are ready, but for now, this is the expected kind of scope. And then the sync optimization for those clients where that actually even is relevant for their specific approach to sync, is up to the individual client. Do make sure that you kind of, general, thinking about that question, because as the chain moves faster, of course, sync is a bit more challenging. Jared?

Jared Wasinger: Yeah, I… I just wanted to clarify something. So, whether or not individual clients make use of BALs for the sync, I think there is still the requirement that we… that they are served over, DevP2P up until the week subjectivity point, so… I mean, is that… That's still the case here, right? Like, when we're saying that this… yeah, okay.

Ansgar Dietrichs: Yeah, just to clarify, so basically, exactly, like, the idea is… I would say there's the… general BAL spec compliance, and now, of course, syncing is that the P2P side is a bit out of the specs, but either way, like, there, the expected behavior is you are able to serve them. And that's not optional. There you have to follow that behavior, and then the question is just for performance optimization specifically. And on that specific performance optimization point, whether you actually end up using BALs for any part of your sync, that is up to you, and you, like, clients just have to investigate, Yeah, to what extent that's necessary and possible for them. Justin?

Justin Leroux: Yeah, Oh, okay, you can hear me. I was just asked to weigh in from an implementer's perspective for presenting signing requests to users in terms of the dynamic pricing from 803.7, and I just wanted to weigh in and say that on that side, it's very straightforward.

Ansgar Dietrichs: Can we just wait with this until we get to 8037? Because I think this is the point. But, yeah, yeah, but we're not quite at the agenda point yet. But I'll call you.

Justin Leroux: Apologies, I wasn't sure where to interject with that. Thanks.

Ansgar Dietrichs: Yeah, no, it's a… yeah, there's no explicit agenda point, but this is ideal, so I'll… I'll call on you in a second. Awesome. But yeah, so then, the BAL-specific kind of questions, I think, are, for now, locked in. And then, yes, the next agenda point, is specifically, the, just briefly revisiting the question of CFI EIP priorities for future DevNets, And, that is directly related to what we just talked about with BALs. So, specifically, on ACDT, there was a discussion about how to scope future DevNets, and the idea, or the general consensus there was that, it makes sense just for keeping friction minimal, to make DevNet decisions. To continue making those, on ACDT, but ideally to have a bit more of a structured input from the ACDE side to give guidance to which ERPs to prioritize. For the future, we're now, like, preparing some sort of,

EIP, kind of, DevNet priorities ranking that we can discuss, say, on next ACDE in two weeks. But, just in the meantime, I just wanted to briefly, on this point, mention that, It, at least from talking to people, it sounds like, actually, we would… from the ACD side, recommend that specifically the BAL optimizations are maybe prioritized over adding future, ERPs into, say, a DevNet 3. And so that, like, extra ERPs should only be considered after, after those optimizations. And that possibly Specifically, EIP 8037 looked like, if anything, kind of a stretch goal for next inclusion, in an upcoming DevNet. Of course, that's not necessarily a consensus take, I just wanted to put this out there, if this generally sounds reasonable to people, as…

As a rough prioritization to have in mind, as we are going into future DevNets, DevNet 3 at some point. So does that generally sound reasonable? Basically, like, prioritizing, BAL, optimizations, and then EIP8037, the state growth one. Before… before any further EAP inclusions into future DevNets.

Stefan Starflinger: I think, generally, prioritization is very hard, and I think we're making pretty good progress on block-level access lists, and I'm not too worried about them at the moment, but in general, yeah, we should have a clear process That we follow for ACT. in ACCDT for the DevNets.

Ansgar Dietrichs: Yeah, that makes sense. Daniel?

Daniel Lehrner: Yeah, I would say if we want to do benchmarks, we should at least consider the smart contract size increase for the next DevNet, because this could change things. So maybe not 8037, but the smart contract has increased to test the new worst case.

Ansgar Dietrichs: Okay, yeah, that's actually a really reasonable point. And then I think, yeah, what best pro- best just to not keep this agenda point also somewhat concise, obviously, any decision on the next DevNet scope will be done on ACDT anyway, but then, yeah, like, this is a good prompt to look into the, the contract size related performance questions and whether that should, motivate fast-tracking that EIP for future dev nodes. Sounds good. But yeah, then, I think we can… Keep a chart here on ACD, Tony?

Toni Wahrstätter: Yeah, maybe a bit related to that. There was also this discussion if we should go to a higher gas limit for DEFNET2. And… Yeah, we don't… I guess we don't need to decide, about this today, but it would be great if clients can quickly go, check if everything would be fine if we go to, for example, to 150 million gas limit for definite 2. This would help us to test things even better, but of course, we don't want to run into any weird limits, for example, the 10MB RLP. Limit and stuff, so just to double check.

Ansgar Dietrichs: Sounds good, and again, that would not be a decision for today, it's just a prompt for people to look into this, so that decisions can be made in the future. That sounds reasonable. Yeah, and then going forward, we will find a way to formalize the question of, DevNet scoping process between ACDE and, well, ACDC and E and ACDT. But for now, I think it's a good place. Then I think now would be a good time to briefly interject. We just mentioned 37 anyway. Justin, if you wanted to briefly, talk about this?

Justin Leroux: Thank you. Yeah, sorry about jumping in, I didn't really see quite where I was supposed to go with the agenda. Yeah, basically, in terms of the implementation side and how we present this to users, we're still showing, the same single gas field, so… there's not really too much to do. I think one UX consideration that could be nice is that if we can, surface why the pricing is higher when there's state-heavy transactions. But outside of that, it's very simple, it's gonna basically flow through to most wallets, hardware, and software. My only consideration there for users is being able to Meet their expectations if they're using some sort of gas price estimating tool, and they might not see that their particular transaction may not align with something that is presenting an estimation for a simple transfer.

Makes sense. But otherwise, easy, yep.

Ansgar Dietrichs: Yeah, and just for, like, for going forward, I think there will be several more of these questions around the impact of repricings, on… Existing flows, tooling, all these, all these things. maybe, Maria, you are going to have these repricing breakout calls. Would that be a good place to also talk about these potential compatibility issues, or is this more an ACDT topic? Where to point people that have questions around these topics.

Maria Silva: Yeah, I think the breakout calls would be, a good place for that.

Ansgar Dietrichs: Sounds good. Awesome. Thank you, Justin, then. And, just to flag, by the way, because we just talked about the BAL optimizations, there's this discussion right now in chat around if we want to actually have at least the three of the four optimizations officially part of the Foggs scope, is there any way in which we want to express that in documentation? Yeah, I don't think we need to discuss this today, I mean, did the conversation chat makes a lot of sense, but I do think it's actually a really good prompt, and so I'll also, like, look into this from the process side, and see if there's a need and a good way to make that a bit more legible, process-wise.

Awesome. Then I think we can move to the next agenda item, which is… well, actually, there's more Glamsterdam scoping to be done, although, I mean, weren't we done with that? Yes, kind of, but there was 3 EIPs still that are not protocol-changing. that we basically postpone decisions on, because it's just not as important as the protocol-changing ones, but now is the time that we should also make decisions on those. And, and these, they are listed in the, In the agenda? And the first one is EAP7610. Revert creation in case of non-empty storage. I think this one was a bit of a confusing one, because it wasn't quite clear whether this is already the way the protocol works today or not, so whether this is actually a protocol change or not, whether this needs to even be part of the hard work or not. I'm not super in the loop on this,

Do we have anyone on the call that has looked into 7610, And can give some context?

Marius van der Wijden: Hmm, I can… I can give some context. So basically, we… we have already decided, or we had decided this for, the last hard fork, that, we're going to take, we're going to do this because Are we going to specify this? And it was already, included in the last hard fork, if I remember correctly, but we never… Yeah. And then, around the fork… proposal, times. This was, discussed again, and, mainly from the Reth team, because they… It requires them to do a… another disk lookup. But… for us, it allows us to do certain optimizations with the database. So…

It's basically, like, yeah. It is a clarification what would happen in a case that cannot really happen. And, yeah, maybe Dragon can also… Speak on this?

Ansgar Dietrichs: Yeah, before we go to Dragon, just briefly, Maris, then from your side, does that mean that for you, there would be value in having this be part of the official Forkscope this time around?

Marius van der Wijden: I… Would say so, yeah, because then we wouldn't have to have this conversation again.

Ansgar Dietrichs: Okay, makes sense. Drag on?

Dragan Rakita: I will continue where Mario stopped. Basically, this specifies an unrealistic scenario. Basically, you would need, quantum, basically, quantum computing to break this. So, adding additional checks and fetches for database for something that's not possible to trigger on the current minute, or not possible to trigger at least next 10 years. I think it's not something that we'd want to add. That's the main point here.

Ansgar Dietrichs: Makes sense. So I… just for my understanding, so basically there is, for historical reasons, there's 28… contracts that exist in that state today already? Is this… I'm… I'm not quite sure I understand, but, like, for the future, to create more such situations, you would have to… And basically, cause a hash collision, or a, Yeah, is this… is this… is this… I don't know, sorry, I'm probably a little out of the loop on this, but…

Dragan Rakita: This related to the accounts that, that were created before the State Clear EIP, like. 5, 7 years ago, I'm not sure exactly. Basic accounts that has, zero, zero runs, no code, and had, or had, have some storage. So this is the… the EIP specifies how… If somebody wants to recreate that particular address as new. a new account, new contract, what would happen? And this is not possible to happen without Quantum computers, basically.

Ansgar Dietrichs: And in terms of… performance, so… it's one thing to just special case these 28, right? That would be easy in terms of performance, but then for future places where this could happen, you basically… you would always have to check that anytime you actually deploy a contract, that the, storage root is basically the empty storage root, right? So you basically have to load the storage root, and otherwise you would not have to load the storage root. Is that the difference in terms of performance?

Dragan Rakita: A simpler solution would be just to remove those accounts. Basically, just use hard fork to remove this account. idea when this AIP was proposed was, hey, we will have workload trees in the future, and… With transition of with a new tree, we could remove accounts that basically have this case. Verkle was basically delayed, let's say it like that. So this is not the case. Either way. If the quantum computers come, we have a lot bigger problems than this. This would be, like, a simple solution to remove just all accounts.

Ansgar Dietrichs: Right. I think Vitalik in chat is saying that maybe it's not actually quantum, but it's because it would be a hash collision, right? So, like, you actually just… that's more classical compute that you'd have to brute force throughout the problem. Either way, but yeah, so, I guess the question then still is, do we… So then it sounds like this is not just a nominal ERP, but actually it does mean that you have to have the logic in the client that goes and looks at And it looks at the storage root, right? So the question is whether to include this or not. Kyung, you're here on tap for a while?

Guillaume Ballet: Yeah, so, sorry, I'm in the street, so I hope the sound is good. If you end up with a unified tree, vertical or not, binary, whatever, the storage root makes no sense, like, it's not a concept that will exist anymore, so you will not be able to enforce this. So yeah, this thing can only happen if you have a hash collision, but that's not a tree problem, that's an address scheme problem. And, if you, like, there will be a moment, or there might be a moment, where, this will not be enforceable anyway, because the state root no longer exists. So, in my view, we should not include it, because there's no way to make it work in the future.

Vitalik Buterin: Yeah, I was, yeah, I just, wanted to follow on, because I made that comment that, like, I, intuitively dislike anything that moves the, sort of API of storage away from just having a get operator and a set operator and nothing else. One example of, like, a weird exceptional case I can come up with is, let's say someone does have 2 to the 80 compute. And so they are able to create a collision, and then… They, basically create Asia contract, and then inside of, that contract, they set some slots, and then possibly, yeah, like, inside of that creation, it does a re-entry thing, and then it tries to create it again. And, like, basically, yeah, not only do you have to look at the root, but also potentially the caching logic inside of a client would have to have an isEmpty operator, and so, like.

The number of special cases potentially blows up quite a bit.

Ansgar Dietrichs: Right. That makes sense. Dano?

Danno Ferrin: So, I think a couple of things we also need to point out is that this was integrated into, last April into the reference test that all clients pass, and Every other client, did change code to make it work, so everyone else has this implemented and working as is. So if we were to pull this out, then, 4 clients would have to go and change code to pass tests again.

Ansgar Dietrichs: Let's see. well, Vitalik, you were unmuted?

Vitalik Buterin: Yeah, I guess I was thinking of, like. Like, what… is there a, yeah, kind of nicer, cleaner solution that, takes into account, like. like, basically doesn't, involve needing an isEmpty operator, and that, makes, like, is future-proof even against address collisions. And the best thing that I can come up with is, like, somehow, as soon as a creation operation begins. You create the account object, and then if the account object gets created, then, like, no other create can happen, and that's, irreversible. So that's kind of… But, I mean, I guess, like, if we create… if we, yeah, implement this style, we can always go switch to something like that in the future, and, like, stick it in as, part of,

A binary tree or something else as well.

Ansgar Dietrichs: Right, that makes sense. Dana, do you still have your own up, or up again? Okay. Yeah, so then, to me, it seems like, basically, this is, for now, more a theoretical scenario that, in the very long run, could become not theoretical, but as of today, basically, client behavior diverges, so if this were to, you know, for some magical reason happen on mainnet. clients would behave differently, which is of course not great. So I do understand the desire to standardize this behavior completely. It does seem not trivial how to do it, though. I mean, I understand the short-term temptation to just do what the majority of clients already does, but then I also understand the… Concerns around… Kind of, principle forward.

Compatibility, what's the best way here to make progress? Do we have, We can, of course, also just say we don't standardize for another hard fork, and just expect nothing bad will happen, or we can take some more time to look into how to standardize this behavior. M… let's put it this way. So my understanding is right is the only client that currently does not follow what the other clients do. Is this right? Just to confirm?

Danno Ferrin: I verified this with the, existing execution spec tests, yes.

Ansgar Dietrichs: I see. I do think, I mean, yeah, from Dragon, maybe, how… acceptable would it be for you all to, on the RET side, to specifically just say, just for… simplicity to for now, have standardized client behavior to go with what the other clients are already doing, make this the official formal behavior, and then revisit and find a more proper, kind of, long-term solution for this at a later time? Or is this, would you be strongly opposed to this because of the… The extra effort on the Reth side.

Dragan Rakita: I don't think it's even not about effort, it's like implementing something that we know that's not going to happen. We were fine a year ago to just skip those tests. And not execute them. I think we are probably going to continue doing that. I will need to talk with team if they want to do that, because… Passing all 200% tests, maybe they want it or not. But in general, This becomes… yeah. You know, like, we are secure, not passing those tests.

Ansgar Dietrichs: Makes sense. Yeah, but then, in terms of just the EIP… for the EIP process, I feel uncomfortable including an EIP. I understand even if it's a theoretical EAP, but, like, as long as we already know not all clients will be. compliant. I think to me, including the AP, even if it's more symbolic, Act still would be this. we all agree that this is now canonical behavior, which I think we should only do if it's actually canonical behavior by everyone. So, as long as, from the Reth side, there's still an objection, then I feel like, for now, we can't include the EIP in the fork. But then I will, for now, just keep it in CFI. Again, even if it stays in CFI all the way until the fork, and we just don't have it in the fork, that's fine. But I'll keep it in CFI for now, just to indicate that they're still an open…

Issue to be resolved, yeah. But then from now on, I think the idea is to try to resolve this asynchronously, and not on future ACDE time. Okay. then, the… this one was the most, like, theoretically kind of complex one, just because of this weird space it's in. The other two should be a bit more straightforward, so the other two, the next EAP here is EAP7872. max blob flag for local builders. So this is, I think, something that, in principle. everyone agrees is a useful thing. The question is just, is this something… it's obviously not a protocol change, is this something that would be worth, including in, the official hard fork meta-EIP to indicate that we expect all clients to support this by the time of the fork?

Or should this be stay out of the Fogg meta EIP? Do people have opinions on that EAP in particular, and whether to include it in the Hard fork meta EIP or not. Felix?

Felix Lange: So, I have the opinion that the client flags should not be specified in the EIPs. It's useful to agree on the flags, and there's nothing wrong with the flag, but just putting it in, like, it doesn't make any sense for me. The EIPs are for the protocol, they are not for the command line interface of the clients. It's, like, a different thing.

Ansgar Dietrichs: Sounds good. I'm also seeing a few thumbs up from different clients, in… Yeah, on Zoom. So then, I guess the default would be to just not have it be part of the meta EIP. Is there anyone who's strongly opposed? Anyone who wants to make an argument that this should be part of the meta scope? I mean, I guess not… but Felix, do you want to say something?

Felix Lange: Oh, no, I put my hand up again. I actually think we should, DFI it.

Ansgar Dietrichs: Yeah, no, that's the idea. I'm just basically saying, is there… like, of course, we would make a decision today, so the question is, is there anyone who's, like, strongly opposed to DFI and would want to, like, make an argument for… Before, see if I need. Okay, then yes, let's DFI the CFP. So, 7872 is DFID, But that does not mean that we don't… want to support that behavior. It's just in terms of, it's not going to be part of the fork meta AIP, because it's out of scope for what a fork meta AIP should cover. Okay, DFI. And then the last one is the EIP7949, which is the Genesis file format. Same situation there, I think, if I understand correctly. Basically, question is just, is this something that should be specified as part of the fork meta or not?

Question here again is, do people feel similarly that this might also be out of scope, or do people think that this one might be useful to have as part of In scope for… for the fork. Justin?

Justin Florentine: Yeah, hi, I'm one of the authors. I think it's reasonable to say that it's not in scope. One thing I do want to point out, though, is that, we have no standardization for chain genesis right now, and we do have standardization for things that kind of depend on ChainGenesis, right? So, like, BPOs, the ETHConfig specs that we're trying to put together. So it's a weird kind of gap that we run into here. I think in the future, we want to add more configuration richness, like per milestone EIP enables. And we don't really have a spec to do that. So, you know, it's a simple point, it's, you know, not a sexy feature, doesn't need any coordination, et cetera, et cetera. It's just a little bit of tech debt, and it has a little bit of an impact on other features.

So, thank you.

Ansgar Dietrichs: Right, and just to clarify, of course, we could also decide to standardize.

Justin Florentine: around this EAP without having it be part of the Glamsterdam Meta EIP, right? 100%. 100%.

Ansgar Dietrichs: Hey, Felix?

Felix Lange: Yeah, from my perspective, I don't think there's any problem with us, for example, creating the spec inside of the execution specs repository, as long as we can agree among the clients that this is something which we all want to, be bound to. So… I don't know if this is weird or not, but there's basically… I mean, yeah, when it comes to changing the protocol, the implications are very wide. But when it just comes to changing things like the client configuration, we can also just make, like, a note in the specs repository that this is the format that we all want to use, and it doesn't have to concern the whole governance process, but we can still have specs that we all follow. It's the same with the P2P specs in some ways, like, we maintain the P2P specs outside of execution specs.

It's kind of a question if they should move there at some point, but it's like… we… I mean, we publish EIPs that say, yeah, we want to make these changes to the PDP protocol, but they are often treated outside of the hard fork process. But, I mean, in the end, it's just, like, something that we agree with each other. It's not something that concerns the wider Ethereum community.

Ansgar Dietrichs: Right, so then what I'm hearing is basically, similarly, that we would maybe lean towards deifying it for the hard folks specifically, but still… would then go ahead with clients standardizing, or at least considering standardizing around the behavior as specified in the EIP. Is this… does this sound reasonable for people?

Łukasz Rozmej: Yes, I think Nethermind is the only one that doesn't support the requested, requested layouts. I think Alexei, FLCL, currently have a PR for that, I need to check it out. So, we will get there. Because I think this is very important for DevOps. Just on the ice.

Ansgar Dietrichs: Sounds good. So then, for the fork Meta ERP, we make the DFI decision, but it sounds like people will still work towards having unified client support around the standard. Makes sense. So, but in terms of the FOC, DFI on this one as well, then. M… Awesome! So that, that was all on the, kind of, scoping, non-protocol EIP scoping side. We have two last sections. One is a quick. mention quick presentation by Chaba on two… two more of these, non-protocol change EAPs, regard… on the networking side, and then afterwards, we will go into, HSTAR headliners. Chaba?

Csaba Kiraly: Yeah. Let me just share the screen. Okay, yeah, so… so two of those, those things. So… We are having different changes in mempool and blobpool, and they are kind of related, obviously, and some of them are touching only in blobpool, some of them are more mempool. So, I was putting here in perspective the EIP8070, everyone knows, there's a sparce blob pool, and I'm having two others here. One is the EIP8077, Which is about the… the announcements that we have in the Manpool. It's about the information, adding more metadata to that, so that then we can… we can do things better, more intelligent fetching choices, especially as we are scaling now the mempool, scaling now The execution and the scaling demand pool.

The other one is specific to… to, RBF, so replace by fee. So we have a huge inefficiency when we are doing that for… blobs in the way we are doing it now, and it's about that. So, the basic idea is to not redistribute, the blob content when we are just replacing and changing just the fee parameters. I have a little bit more detail. So, this is the 8077. So the… the issue that it's trying to address is that, when you have a node, which is in the mempool, it's kind of living in this… this cloud of… of transaction hashes. And everything is fine until you can… Understand what are those, so you can actually get those transactions, and then you have the nonce, the, the senders, the fees.

And then you can do something with it, but if you only have the hashes, you don't have nothing, basically. So, this leads to too many issues. If you are in another gym where you have nonce gaps, for example, you cannot fill those, because you can only randomly tie hashes and then hope to get the, to fill the gaps. It's also, preventing selectively fetching. Selectively fetching based on sources less, or selectively, fetching based on… based on fee priority. So the proposal here is to make the announcements, more… having more metadata. So, two values, one is just adding the sender and the nonce. That already allows to… to manage better the… the gaps and… and have the source-based filtering and, and all those things.

There is the valid end where we are adding also fee information to this, and then you can do your validation, and be selective based on that. A little protocol change in the sense of the semantics, but you can build intelligence on top of that, and that's the main thing. The other one is the 8094. So the problem that is targeted is that, when you are replacing a blob, blob transaction. You are basically asking the network to resend the whole transaction, and you don't have any way to not do it with the current protocol. So the proposal is to change the protocol so that, if only the place is changing, then we can actually send this information. Then you can realize that the, the actual blob sidecar content is the same, and then,

Then you don't download the sidecar content. I'm not going into the protocol details, but these are the two topics, basically. The first one seems easier, the second one is more intertwined with the spasma pool and related ideas, so I'm focusing on the first one. Started adding some measurements on, kind of, how many times these things are happening. Left is the… is the late… related to the… to the later, presented EIP. The light side is to the, 8077. also, kind of, I did start measuring how much would be the effect, and starting to implement it. So the, what you see here is that we… we already have quite an amount of announcement suffix, like, 30% of the traffic, is announcements.

But we know… We have easy ways to reduce that, because we are not really… we are announcing to everyone, and that's a lot, so if… Here we are adding more data to the announcements, maybe doubling the size of the announcements, or maybe tripping the size, but we can… we also know how to use that, because we don't have to send these announcements to everyone from everywhere, basically, so we can mitigate that effect and have this intelligence. In the manpool. That's it, basically, to stay quick.

Łukasz Rozmej: If… I can take some comments on 8077. So, I was, a few years ago, like, 2 or 3 years ago, when we are doing, like, a big overhaul of our transaction pool, and with some other stuff, I was wondering, I was thinking if, to propose exactly this. To add, nonses and, senders to the announcements. We decided, even maybe more time ago, we decided not to, and build our transaction pool to support non-gaps. So basically, we can take non-gaps, but we will drop them, relatively quickly. If, anything, other, has pressure. on the pool. And my… my logic was that we should potentially… because we would have to announce not only that, to make it actually complete, but also things like, max fee, max fee per gas, blah blah blah, all those gas prices, everything.

because all of this actually makes… is needed for decision to something to keep in the pool or not to keep in the pool, and to download something or not to download something. So, announce… so, basically, you would have to announce almost everything except, Transaction data, of course, and blobs. So… That was my… that was my conclusion, that to actually make this complete, to make this really, useful and complete, we have to kind of have… almost all of the transaction fields into that, so that's why I kind of decided against it, not to complicate the… The process, the protocol here. So… I'm fine with that, but again, like, if your base fee is too low, or other fees, you still will…

get… transaction announcements, you will download those transactions, and then you will decide, oh, they are actually worse than what I have in the pool, so this traffic is… you can consider it wasted at the moment. So… I don't really think that this is that crucial.

Csaba Kiraly: That's why I have the fees in optional, because I have these depths about that, because there's quite some metadata there. But even the source and the nonsense itself is allowing you to do useful things. So, the… the gaps… we also support gaps. The problem is that you cannot fill the gaps. The gap filling is really based on the assumption that you have the capacity to download everything, and that will not be true in the future, if we really are serious about scaling. Not to mention, you know, notes are heterogeneous, so not everyone can download everything. And the failed modes, in that sense, are not good. And then that is the advantage of having the source.

I'm also less… convinced about the fees. I see the advantages, but that is the implementation factor of… I mean, that is the factor of having more metadata there. fees, we, we can do things. We can quantize the fees, for example, so to complex it. So, there are options to complex, there are, options to not have all the announcements like this, only, Pulse of them, so we can work on the… on the bandwidth part of that, relatively easily. Yeah, but we can work on working out details. Differently.

Ansgar Dietrichs: Okay, now go.

Csaba Kiraly: I already have an answer if you're calling on people.

Ansgar Dietrichs: Yeah, I mean, either way. Yeah, Fabio?

Fabio Di Fabio: Yeah, I want to say that the other IP, replaced by fee for blobs, seems more relevant to reduce the bandwidth. About this one, I'm talking for Besu, of course. Also, in Besu, we don't have, any more issue with nonce gaps. Since the new layer transaction pool released 3 years ago. And I'm not sure about other clients if… All clients are now fine or not with non-SCAP. So, because, adding all those fields actually could… means that for simple transaction, we are… Basically, doubling the bandwidth, because If the transaction hasn't… a payload, you basically announce it, and then you need to request it again, so…

At the moment, unless there are Clients are really struggling with non-gaps. maybe we need to understand which is the… The… the impact of this one in terms of… complexity and, also, increased bandwidth. So I will see the other more, important. To reduce the bandwidth on this one.

Csaba Kiraly: Yeah, on the bandwidths, as I said, part of our bandwidth is simply… so there's the pushing of the transactions, and then there is the announcement. And we are announcing, basically, to everyone, so that's lots of traffic there. We could… we could easily reduce that without compromising, robustness, if we think the ad did Bites are the problem. At least. This is my opinion. That we can… we can increase the size of the announcement and make less announcements, because we are overdoing on that currently. And gap… we also have gap management, it's, it's more the, the issue of of gaps When you are actually… then it's limited.

Ansgar Dietrichs: Okay. Perfect. Any further questions, comments? I would want to timebox this reasonably. And reasonably soon, move over to the next topic, but if there's, like, one more comment or question, we would have time for that. Okay, well then, thank you very much, Shabba, and there were some questions about whether you could share the slide link in chat, so in case that's shareable, then I think that would be much appreciated. Awesome. Then, on to the next, and last agenda point, which is the, H star Hegota headliner proposals, and, just to clarify, because there were some questions around this, in the communication, I think it was on the Ethereum Foundation blog or something, there was this quote, the quote was basically, proposals, headliner proposals for Heka must be submitted by February 4th.

It must be presented at an archives call. To clarify, the deadline specifically applies to the written submission of a headliner proposal, not to the presentation. So, the idea is that as they are proposed, they can then be presented on the next ACDC or ACDE call, depending on where they are, better fit. But you still have time until February 4th to propose them, and then… That means that any EL-side headliners that will be proposed until then can be presented, say, in two weeks on autographs. That said, we have a few that are already proposed and are ready to be presented today. I think we have three on the agenda. And yes, I would want to start with the first one, which is the Universal Enshrined Encrypted Mempool proposal, and I think we have Yannick, who wanted to briefly present this.

Jannik Luhn: Yes, me, thank you. So, yeah, the goal of EIP 8105 is to, as the name suggests, to add encrypted transactions to the protocol in order to prevent front-running and sandwiching attacks. Many users already protect themselves by using private RPCs and trusted builders, which I think proves that there's user demand, but the way this happens, we think, is problematic because it relies on trusted parties. Which is bad for decentralization and censorship resistance. So, we came up with EIP8105 to fix this at the protocol level. We set ourselves some design constraints. In particular, we do not want to have any impact on regular transactions, which is typically a problem for encrypted mempool designs. We don't want to increase latency or have, like, liveness issues.

For regular transactions, and we want to have it neutral and future-proof. In particular, we want to… don't want to favor any cryptographic mechanism. It should work, for example, with both threshold encryption, or TEs, or whatever other, yeah, cryptographic solution people want to use. And the high-level overview over how it works is that we add a new role to the protocol called Key Providers. It's permissionless, anyone can register as one. And we had a new transaction type, encrypted transactions. And in this transaction, they reference… the user references one of the key providers that they trust. And then builders can include these encrypted transactions as normal. They only have to put them at the end of the block. So the block is split into two parts. First, the plain text transactions, and then the encrypted transactions.

And then once the block is published, or the execution payload is published. And then the payload timeliness Committee… oh, sorry, then the key providers will release the decryption keys, for those transactions that, that they see in the block. And then the Payload Timeliness Committee that EPBS introduced, will attest to which keys have been published and which ones have not been published. And once the attestation is there, transactions can be decrypted and executed. Yeah, so that's basically it. We're proposing this, as… ideally as a co-headliner for Hecota, next to, FOCIL, because we think this fits very well into a theme of improving credibility, neutrality, and censorship resistance of Ethereum. Yep, that's… that's it, I think.

Ansgar Dietrichs: Thank you. Do we have any specific concrete questions, comments on this directly?

Lightclient (Matt Garnett): I'm wondering, like, what key system this will use on mainnet?

Jannik Luhn: So we would not prescribe any particular cryptographic scheme. Basically, when you register as a key provider, you also specify a decryption function in a smart contract, and this will then be used to, first to verify decryption keys so they are the correct keys, and then to do the decryption.

Lightclient (Matt Garnett): I mean, are there quantum-resistant key systems that would be performant enough for this?

Jannik Luhn: Mmm… I'm… I'm not an expert on this. I could imagine that for many schemes, it would make sense to add particular EIPs, to add these as a precompile. Yeah, I'm not sure, maybe some of them can be implemented in the EVM.

Ansgar Dietrichs: And Potuz.

Potuz: Yeah, I just want to comment that, instead of, like, making it part of consensus for the same slot. and pushing this on the PTC that we're expecting it to be quite much later than what the PTC expects the payload to be available. This would force those transactions to only be executed at the very last bit of the slot, and this… like, loses all of the pipelining benefits that we have of this delayed execution. So I would suggest that you think about, like, forcing these transactions to be top of the next block. And the consensus over this is already enforced by PTC in the previous block. This doesn't change the ordering at all, and it allows you to actually have the full slot to execute them.

Jannik Luhn: Yeah, it's interesting, and I think… I'm not sure if it makes conceptually a difference at all. The only thing I think that's important is that the context under which the transactions are executed, for example, the timestamp or whatever, still has to be the previous block, so that the build of the next block cannot influence the execution path of the previous transactions. Yeah, the time in which they can, like, if they belong to the previous block or to the next block is, I think, kind of arbitrary.

Ansgar Dietrichs: And, Lucas?

Łukasz Rozmej: So, the keys, which are not the part of the block body, will now be a historical thing that would need to be stored, for example, on… for archive notes, ERA files, etc, right?

Jannik Luhn: Yes, that's… they are needed for execution, so they, and they are kind of… I don't know, like, I'm not a client developer, and to me, it seems like it's a bit of a split between the consensus layer and the execution layer, but in some sense, they have to be collected by the consensus layer and then passed on to the execution layer, and then executed as part of the block, or become part of the block in some sense.

Ansgar Dietrichs: Sounds good. We would have time for one more question or comment, anyone?

Lightclient (Matt Garnett): Wondering if there's any metadata of the transactions that are required to be in the clear? In previous examples of this, I feel like I've seen that, like, nonce or gas limit need to be available. Is that true?

Jannik Luhn: Yeah, it's basically the same. The encrypted transaction consists of the encrypted payload, but also a plain text envelope, and that handles the, in particular, the fee payment for the encrypted transaction.

Ansgar Dietrichs: Okay, perfect. Thank you so much. I think that was a good kind of intro for people that didn't yet have context on this. And then, of course, you can… everyone can go find the proposal and follow up there. And keep the discussion alive. For today, I would then move on to the second presentation, because… so we can get through all three. So thank you, Yannick. And then next up will be, frame transactions, proposed by Matt and Felix, or I think those two wanted to give a presentation. Yes? Go ahead.

Felix Lange: I can give the presentation. I mean, there isn't really too much to present, per se. We didn't make the slides, so we… but I can still… I mean, we can look at the EIP together, and I can quickly give an overview by just showing the parts of it. So, this EIP is a proposal that is in the line of proposals for account abstraction. And, specifically, it has… For us, it's mostly about abstracting the transaction signature away to a system where the user account itself verifies the validity of the transaction, and more specifically, the account itself verifies whether the transaction was sent by itself. And, there are other goals for account abstraction, and this transaction type also

can do those, but for us, it's, like, the primary purpose is this, like, key management topic. the… there is a lot of existing… there were a lot of previous EIPs regarded, related to account abstraction, one of them being the EIP7701. this is, in some ways, an evolution of the EIP7701, and it… the… also, the ideas in this EIP, 8141, were co-developed with… together with the team behind EIP7701, so it's kind of like, this is basically, like, the combination of all the ideas that various teams had. so we feel like this is… we feel pretty good about this proposal, because a lot of these ideas that were previously already tested in ERC437 and during the EIP7701 development and so on, so there's, like, a lot, a lot, a lot of research behind it.

That said, there's also some new stuff, and then one of the new things is this frame list. So basically this, transaction type. allows… basically adds a list of multiple calls to the transaction, and then the calls run at different permission levels. We have three modes of execution, we call it here, but they… you can think of them as, like, both a permission level, but also basically configuring the EVM environment a bit differently for each mode. So we have one… this is like the unauthenticated mode, where the call happens from the entry point address. We have one that is… we have a specific execution mode that is… executes like a static call, and this one is for the purpose of verifying the transaction signature, among other things. And then we have the sender mode, which basically executes as the actual transaction sender, so this is more like the authenticated mode that all the transactions execute in right now. So basically, if you think about current transactions, they have a single call frame.

that executes as the sender. And these other two things, they don't… there's no equivalent for them right now. And, this… Adding the frames has some implications. So, for example, also in the receipt, we have per frame receipts, which is useful, among other things, for native batching, so it kind of has this, like… basically, it adds another layer of calls into the main loop of executing Ethereum. right now, when you're executing a block, you will execute in a loop all the transactions within it, and in the future, you will actually even execute these transactions in parallel. So with this proposal. all of the frames of the transaction will also be executed sequentially. And the rule for executing it is specified

All the way down here. And, basically this… Rule gives… is designed in such a way to make sure that before anything is executed as the sender of the transaction, the transaction first has to confirm that The transaction is authentic, and in another step, or in the same step, it has to confirm that the fees for the transaction were paid. And, the fee payment is also decoupled from the sender, which is another goal of account abstraction, and it's also a goal that is specifically for the smart accounts and the wallets. to be able to sponsor the transactions of their users. So, the users can pay for their own fees like they do now, but it is not required, and another entity can

Sponsor the fees of any transaction by adding Like, can sponsor the… can another entity from the user can… Sponsor the transaction? But the user has to opt into using that entity also, so it's not like any transaction can be sponsored, but it requires cooperation between the user and the sponsor. Finally, we have some new opcodes that facilitate this. I don't want to go into the detail of it, but it's just something, an area where I also suspect more changes will be made over time. They are not, The main one we have is… the one that actually changes the semantics the most is the approve opcode, which is basically another way to return. So this is, like, this is an opcode that terminates execution, and unlike return, it terminates it with a status code that is beyond the usual 0 and 1 status. So at the moment, returning from an EVM call has a success or failure state, and with this new opcode, there are 3 more

states that a call can end in, and so this is, like, a change in EVM semantics. In the other opcodes are just environment access opcodes that do not have any impact on the the macro operation of the EVM. And, Yeah, there's a lot more things to say about the EAP, but these are more like the detailed things. I just want to highlight that at the end of the EAP, we have a list of examples that kind of show the frame structure for common use cases that people have associated with account abstraction, and also use cases that are present today. So we have things such as a contract call in example 1, an ETH transfer, which has to be done in a… as a contract call with this scheme as well, because there's no native value transfer facility.

There is an account deployment, which is kind of an also critical step, because when people use smart accounts, they have to have code on-chain before they can send transactions, so the scheme has to deal with that. And then finally, we have an example for the fee sponsoring. And, here we also have some tables that basically aim to show that the overall size of these transactions, even though they operate in a completely different way from now. if you would use ECDSA signatures, like now, the overall size of the transaction is only, like, 30 bytes more, or something, or 20-something bytes more. So, we feel pretty comfortable with this design, and we are happy to defend it, and we propose it as the headliner, because we feel that

It's a big change to the state transition. And it's also kind of, for us, the most important one, because of the readiness for the post-quantum world, and I mean, we kind of feel like we have to get started with the off-ramp from ECDSA, and in order to do that, we need a comprehensive system that can deal with Whatever signature algorithms we want to use. And so, yeah, this is our… Approach to doing that.

Ansgar Dietrichs: Sounds good. We will have a few minutes for questions, comments. Daniel?

Daniel Lehrner: Yeah, so my… my concerns about this are not so much technical, but we have seen with 7702 that the option for the smart wallets, or for any changes in how we do… transaction signing is very, very low. So I think I checked before in one of these dashboards, and we only have, like, 5,000 Transaction… 7702 transactions per day. I'm a bit worried that we would do this as a headliner, as a preparation for post-quantum, but afterwards it's not really used. So, I'm not sure if that's… The best way to spend our resources, or maybe delay this and do other things first.

Felix Lange: Yeah, there's not much I can say about these concerns. This is, not, since it's not a technical concern. for me, it's quite clear that, like, account abstraction has been one of these projects that has been ongoing for many years that people always wanted to realize, and we also see that the existing mechanisms that were proposed for in this direction, they are not adequate to capture what users really want to do. For example, even now, with the EIP7702, it is kind of a… I mean, it is certainly a way to convert an existing account into an account with code, but it does not much more to help with the advanced use cases that people have, and also it is not quantum secure. So in some ways, there is not too much… I mean, it helps you with some things, but it doesn't help you go all the way.

And we kind of feel like. Some bigger change is needed to really help people do… realize the… the things that they have to do.

Daniel Lehrner: Yeah, I think it would just be, maybe, important, you know, to talk with wallets and so, because one, I think, issues with 7702 is that, that Rabby, for example, is not supporting it yet. So, you know, to have some feedback, are they really willing to make… To… to implement transactions, or… or not. So this, this, this would be, you know, I mean, I understand it's not a technical concern, but it's more… What's the highest priority?

Felix Lange: It is our plan to communicate with the users of You know, with the builders of, for example, wallets. And other infrastructure to ensure that they can find a good upgrade path, but ultimately, I think everyone has to face the question of upgrading their cryptography into something that is quantum secure, or at least something, you know, that is more practical for them. So, we feel like we just have to provide the means first, and then we have to work with everyone to build out their infrastructure, because there's almost no incentive to build another infrastructure for keys when the protocol doesn't support it and doesn't look like it will ever support it.

Daniel Lehrner: Okay, thanks.

Felix Lange: There was also concern about the mempool, I guess? Rejecting answer. So, Frangio asked the question, how does it look in the mempool? And for this, I want to highlight that, this proposal has a section in the bottom that goes a bit into detail about this. We expand… we intend to expand this a lot more. The key thing to note is that while the inside of a block an arbitrary interaction can take place. For example, you could have transactions that do not contain a signature verifying frame. In some cases. This can actually be fine, but for the purposes of the mempool, we will validate the transaction to conform to a specific known frame structure, and this includes having a gas limit on the signature verification.

And, ensuring that there's only a single verifying frame, and ensuring that this verifying frame does, in fact, cover the fees of the transaction, as well as basically having a valid signature. So there's… we… in the public mempool, these transactions will be much more limited than their feature set might allow. However, we see it as an advantage that for a specific application, custom mempools can be built that validate the transaction according to more specific rules, whereas if you just want to make a general verification of transactions, you have to really limit what the transaction can do inside of its verification phase. But once these limits are applied, one key thing to realize is that using the EVM to verify the signature isn't different from calling the ECDSA verification in the native code, it's just a different way, it's just a different signature algorithm in the end.

This… you can see it this way if the environment that verifies the signature is sufficiently limited, and we do intend to place these limits in order to make this compatible with the mempool. But it's also an explicit design goal for this proposal to be compatible with the public mempool as much as possible.

Ansgar Dietrichs: Yeah, just a timebox, I think, Vitalik, you were unmuted, so if you have one more comment, and then afterwards we have to move on.

Vitalik Buterin: Yeah, I think I also just wanted to add that, like, from a, use cases perspective, this, does, like, basically satisfy, everything that, at least I've been pushing for, like, the, entire list of, of goals of, account abstraction, including, you know, the original ones, and including various things that have been, bolted onto the topic over the years. And, and I think it's particularly nice how, like, this design has very few special purpose features from these things. They just, fall out naturally from the, ability to have multiple a verification frame and execution frames, so it satisfies, the natural stuff, like, different signature algorithms, including, passkey friendliness, now that we also have the, SIG P256R1 precompile, it, satisfies post-quantum SIGs, it satisfies native multisig, it also,

I think also worth highlighting, there's this nice synergy with, FOCIL, where, privacy protocols, and, also even, transactions paid with, Paymasters can be, sent through it, and, there's a, path, to make that FOCIL compatible without inter… without intermediaries, and so there's, a benefit in terms of, censorship resistance for privacy, so I think, yeah, like, the post, quantum aspect is, definitely the, aspect of, like, it's the reason why, account abstraction of some form is, ultimately. indispensable, but, like, the generality of this, thing is also very powerful for a whole set of, other goals from, like, basically every, camp of the account abstraction community as well.

Ansgar Dietrichs: Sounds good. Then, I think we really need to move on now to the last Hegota proposal. I'm sorry that we ended up running over a bit. Ethan wanted to talk about SSZ execution blocks. Ethan, you only have a few minutes. Of course, you can take… you can go a little bit over, but some people might have to drop off. If you felt comfortable with that time, we could, of course, also push by 2 weeks, but feel free to go ahead now if you're comfortable with that time.

Etan Kissling: It's okay, it's okay, I can make it really quick. Essentially, like, can you see my screen?

Ansgar Dietrichs: Yes.

Etan Kissling: Okay, okay. So, this is just, like, a follow-up on the Pureth that was discussed for the headliner for Glamsterdam. Back then, it was way too big. Like, this was, like, the scope. But what happened is, like, that the individual pieces got proposed independently, and now we got, like, the ETH transfer logs on the EL and the progressive SSZ types on the CL as, like, a partial, scope. And at the same time, we also have this breakout call from Schulte every second Tuesday about the log index and so on. The goal is still the same, to be able to build a wallet without relying on trusted third parties. So now, the idea is to reduce the scope,

essentially focusing on what's urgent right now, like, it's mostly the engine API that needs… rethink, because we are starting to get latency issues there because of the data format conversion, like converting from SSZ to JSON to RLP, especially at higher blob counts, and also, like. We have the problem with the hashes for the transactions and receipts. As a reminder, these are linear hashes today. And transaction data includes call data, and The receipt contains the log data, and it's all just a single linear hash. That's a problem for payload chunking, if we want to move the payload into the blobs, for example. So, getting this… this in here, just fits naturally. So, the question now is how big do we want to make it?

So, the bare minimum would be, like, just the binary engine API, the transactions try, the receipts try, and the SSZ block hash for the block payload. That would allow, That would allow, like, the EL to pretend that it's full SSZ to the CL. The CL could, just get all these benefits, but also at the same time, we have these new transaction types, both of these proposals, and I think it makes sense to just combine, combine it in a way so that whatever we add now, like, if it's the framed transactions. Or the encrypted transactions just builds on top of SSZ, so that we get these binary trees, so that we can fetch partial transaction data, so that we have…

on-chain commitments to the contract address, to the sender address, and so on. So yeah, that's the idea, like, how big do we want to make it? Right now, I propose it as a headliner, just because of the synergies with the new transaction type, but, yeah, if it, doesn't… like, if we want to stay with RLP MPTs and, like, convert, to avoid, database networking revamps, then we can also reduce it again for this fork.

Ansgar Dietrichs: Sounds good, thank you very much. Of course, some people might have to drop off now, but if there's, like, one or two questions, we could… Run over a bit.

Etan Kissling: I'm all for Binary Engine API and Binary ELRPC. Yeah… Definitely needs to be… Anna, that's for the previous one. Yeah, I mean… We have synergy with the transaction EIPs, so… like, the only thing is, if we want to do it, then we should probably start to put those transaction EIPs on top of SSZ rather than RLP. Should be a rather small change.

Ansgar Dietrichs: Sounds good. Any… any more questions or comments? Okay, well then, we just managed to finish the scope of the call, perfect. Thank you all very much, and I'll talk to you all in two weeks. Bye, everyone.

Marius van der Wijden: Bye-bye.

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