AllCoreDevs - Execution #229

|2026-01-29| Agenda: #1883| canonical JSON

Transcript

Ansgar Dietrichs:Perfect. Then welcome, everyone, to All Core Devs 229.

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

Ansgar Dietrichs:That will all start within the next 2 weeks.

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

Antonio Sanso:We kick off with, February the 4th, 3 o'clock. The agenda, is already kind of ready, it's on the link.

Antonio Sanso: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.

Kevaundray Wedderburn:I can post a link in the chat, right now.

Ansgar Dietrichs:Sounds good.

Ansgar Dietrichs:And then…

Ansgar Dietrichs:The third one, I think, Maria, you wanted to announce a record call specifically around the Glamsterdam.

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

Maria Silva: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,

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

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

Stefan Starflinger:Specifically for 7708, there were some clarifications made during the development and, also the changes to 77…

Stefan Starflinger: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.

Stefan Starflinger:And we came to a launch date for DevNet 2 on the 4th of February, so next week.

Stefan Starflinger: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.

Stefan Starflinger:And also, another part on this, for this document is, client feature flags.

Stefan Starflinger:There, I added a section where clients can enable and disable optimizations.

Stefan Starflinger: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.

Stefan Starflinger: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?

Ansgar Dietrichs:Otherwise then, next up, and these… this is, the next two items are related more to DevNets going forward, but also

Ansgar Dietrichs:specifically this one also directly for DevNet2, which is the…

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

Ansgar Dietrichs:four distinct, optimizations to actually make use of the new possibilities BALs enables. That's the parallel execution, the batch reading.

Ansgar Dietrichs:Parallel state root calculation and the sync.

Ansgar Dietrichs:And there was some desire to formalize to what extent, these optimizations are basically expected as part of the Glamsterdam scope.

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

Toni Wahrstätter:things look quite good, I would say, so we now have GEF and Beso being ready, having all three

Toni Wahrstätter:what I would call the more mandatory optimizations implemented, which is parallel execution, the batch reading, and the parallel post-state root calculation.

Toni Wahrstätter:I think also NetherMind has all three optimizations ready, have to check in with them.

Toni Wahrstätter:So, from that perspective, we are ready to test and benchmark the whole thing.

Toni Wahrstätter:And we should also be ready to then have the first

Toni Wahrstätter:shadow forks against mainnet, or even BloatNet, in order to

Toni Wahrstätter: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

Maria Silva:For… for instance, for parallel execution, it's… Final.

Maria Silva:Easy to reason about what sort of

Maria Silva: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.

Maria Silva:And in terms of timeline, in order for us to have enough time to benchmark and test everything.

Maria Silva: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

Maria Silva:Benchmarking the operations we are repricing.

Ansgar Dietrichs:Right, and so basically, in a way, to synthesize this,

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

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

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

Ansgar Dietrichs:And with the specific ask to prioritize the, the batch read one, first in that process. So, so the question would be, is that…

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

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

Toni Wahrstätter:for the healing phase in SnapSync. So this might not even apply to all of the clients, but it does for GAF, for example.

Toni Wahrstätter: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.

Andrew Ashikhmin:Started to think about parallel state root calculation.

Andrew Ashikhmin:But I don't think we have anything in the works in terms of

Andrew Ashikhmin: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.

Toni Wahrstätter:In the end, when it comes to the fork, I would assume that

Toni Wahrstätter:We don't even need to explicitly say which optimizations need to be implemented, but we can more, like, implicitly set the gas limit

Toni Wahrstätter:To a certain point, where…

Toni Wahrstätter:yeah, clients that we used for benchmarking are basically fine with it. And I assume we will just use all clients for benchmarking.

Toni Wahrstätter: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…

Maria Silva:If we… so, we need to understand how much

Maria Silva:State access, so reads and writes, perform in comparison to compute operations.

Maria Silva: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…

Maria Silva: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

Maria Silva: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

Toni Wahrstätter: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.

Toni Wahrstätter: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…

Maria Silva: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

Toni Wahrstätter:be able to keep up, I assume. So this is like an implicit… Assumption here.

Csaba:It's great.

Ansgar Dietrichs:And then… Can we… just to bring it back into the full group,

Ansgar Dietrichs:Sorry, Saba, you wanted to say something?

Csaba: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…

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

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

Ansgar Dietrichs:Do make sure that you

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

Jared Wasinger:that they are served over, DevP2P up until the week subjectivity point, so… I mean, is that…

Jared Wasinger:That's still the case here, right?

Jared Wasinger: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…

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

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

Ansgar Dietrichs:Yeah, to what extent that's necessary and possible for them.

Ansgar Dietrichs:Justin?

Justin Leroux | GridPlus:Yeah,

Justin Leroux | GridPlus: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 | GridPlus: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.

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

Ansgar Dietrichs:the, just briefly revisiting the question of CFI EIP priorities for future DevNets,

Ansgar Dietrichs:And, that is directly related to what we just talked about with BALs.

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

Ansgar Dietrichs:To continue making those,

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

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

Ansgar Dietrichs:It, at least from talking to people, it sounds like, actually, we would…

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

Ansgar Dietrichs:Specifically, EIP 8037 looked like, if anything, kind of a stretch goal for next inclusion, in an upcoming DevNet.

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

Ansgar Dietrichs:As a rough prioritization to have in mind, as we are

Ansgar Dietrichs:going into future DevNets, DevNet 3 at some point.

Ansgar Dietrichs:So does that generally sound reasonable? Basically, like, prioritizing, BAL,

Ansgar Dietrichs:optimizations, and then EIP8037, the state growth one.

Ansgar Dietrichs:Before… before any further EAP inclusions into future DevNets.

Stefan Starflinger:I think, generally, prioritization is very hard, and

Stefan Starflinger: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

Stefan Starflinger:That we follow for ACT.

Stefan Starflinger:in ACCDT for the DevNets.

Ansgar Dietrichs:Yeah, that makes sense. Daniel?

Daniel Lehrner (Besu):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.

Daniel Lehrner (Besu):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,

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

Ansgar Dietrichs:motivate fast-tracking that EIP for future dev nodes.

Ansgar Dietrichs:Sounds good. But yeah, then, I think we can…

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

Toni Wahrstätter:And…

Toni Wahrstätter: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.

Toni Wahrstätter: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.

Toni Wahrstätter: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.

Ansgar Dietrichs:That sounds reasonable.

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

Ansgar Dietrichs: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 | GridPlus:Thank you. Yeah, sorry about jumping in, I didn't really see quite where I was supposed to go with the agenda.

Justin Leroux | GridPlus: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…

Justin Leroux | GridPlus: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.

Justin Leroux | GridPlus:But outside of that, it's very simple, it's gonna basically flow through to most wallets, hardware, and software.

Justin Leroux | GridPlus:My only consideration there for users is being able to

Justin Leroux | GridPlus: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.

Justin Leroux | GridPlus: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…

Ansgar Dietrichs:Existing flows, tooling, all these, all these things.

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

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

Ansgar Dietrichs:Awesome. Thank you, Justin, then.

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

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

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

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

Ansgar Dietrichs:And, and these, they are listed in the, In the agenda?

Ansgar Dietrichs:And the first one is EAP7610.

Ansgar Dietrichs:Revert creation in case of non-empty storage.

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

Ansgar Dietrichs:Do we have anyone on the call that has looked into 7610,

Ansgar Dietrichs:And can give some context?

Marius van der Wijden:Hmm, I can…

Marius van der Wijden: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

Marius van der Wijden:Are we going to specify this? And it was already, included in the last hard fork, if I remember correctly, but we never…

Marius van der Wijden:Yeah. And then, around the fork…

Marius van der Wijden:proposal, times.

Marius van der Wijden:This was, discussed again, and, mainly from the Reth team, because they…

Marius van der Wijden:It requires them to do a… another disk lookup.

Marius van der Wijden:But… for us, it allows us to do certain optimizations with the database. So…

Marius van der Wijden:It's basically, like, yeah.

Marius van der Wijden:It is a clarification what would happen in a case that cannot really happen.

Marius van der Wijden:And, yeah, maybe Dragon can also…

Marius van der Wijden: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.

Dragan Rakita: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.

Dragan Rakita:I think it's not something that we'd want to add.

Dragan Rakita: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…

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

Ansgar Dietrichs:And basically, cause a hash collision, or a,

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

Dragan Rakita:5, 7 years ago, I'm not sure exactly.

Dragan Rakita:Basic accounts that has, zero, zero runs, no code, and had, or had, have some storage.

Dragan Rakita:So this is the… the EIP specifies how…

Dragan Rakita:If somebody wants to recreate that particular address as new.

Dragan Rakita: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…

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

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

Dragan Rakita:Basically, just use hard fork to remove this account.

Dragan Rakita:idea when this AIP was proposed was, hey, we will have workload trees in the future, and…

Dragan Rakita:With transition of with a new tree, we could remove accounts that basically have this case.

Dragan Rakita:Verkle was basically delayed, let's say it like that.

Dragan Rakita:So this is not the case. Either way.

Dragan Rakita: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.

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

Ansgar Dietrichs:Either way, but yeah, so,

Ansgar Dietrichs:I guess the question then still is, do we…

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

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

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

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

Guillaume:So, in my view, we should not include it, because there's no way to make it work in the future.

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

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

vitalik:And so they are able to create a collision, and then… They, basically create

vitalik:Asia contract, and then inside of,

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

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

Ansgar Dietrichs:Right. That makes sense. Dano?

Danno Ferrin - Tectonic.xyz: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

Danno Ferrin - Tectonic.xyz: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.

Ansgar Dietrichs:well, Vitalik, you were unmuted?

vitalik:Yeah, I guess I was thinking of, like.

vitalik:Like, what… is there a, yeah, kind of nicer, cleaner solution that, takes into account, like.

vitalik: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

vitalik: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…

vitalik: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,

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

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

Ansgar Dietrichs:clients would behave differently, which is of course not great. So I do understand the desire to standardize this behavior completely.

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

Ansgar Dietrichs:Concerns around… Kind of, principle forward.

Ansgar Dietrichs:Compatibility, what's the best way here to make progress? Do we have,

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

Ansgar Dietrichs:M…

Ansgar Dietrichs: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 - Tectonic.xyz:I verified this with the, existing execution spec tests, yes.

Ansgar Dietrichs:I see. I do think, I mean, yeah, from Dragon, maybe, how…

Ansgar Dietrichs:acceptable would it be for you all to, on the RET side, to specifically just say, just for…

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

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

Dragan Rakita:And not execute them.

Dragan Rakita:I think we are probably going to continue doing that. I will need to talk with team if they want to do that, because…

Dragan Rakita:Passing all 200% tests, maybe they want it or not.

Dragan Rakita:But in general, This becomes… yeah.

Dragan Rakita: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.

Ansgar Dietrichs:compliant. I think to me, including the AP, even if it's more symbolic, Act still would be this.

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

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

Ansgar Dietrichs:Issue to be resolved, yeah.

Ansgar Dietrichs:But then from now on, I think the idea is to try to resolve this asynchronously, and not on future ACDE time.

Ansgar Dietrichs:Okay.

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

Ansgar Dietrichs:max blob flag for local builders. So this is, I think, something that, in principle.

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

Ansgar Dietrichs:Or should this be stay out of the Fogg meta EIP?

Ansgar Dietrichs:Do people have opinions on that EAP in particular, and whether to include it in the

Ansgar Dietrichs:Hard fork meta EIP or not. Felix?

Felix (Geth):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.

Felix (Geth):It's, like, a different thing.

Ansgar Dietrichs:Sounds good. I'm also seeing a few thumbs up from different clients, in…

Ansgar Dietrichs: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 (Geth):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…

Ansgar Dietrichs:Before, see if I need.

Ansgar Dietrichs:Okay, then yes, let's DFI the CFP. So, 7872 is DFID,

Ansgar Dietrichs:But that does not mean that we don't…

Ansgar Dietrichs:want to support that behavior. It's just in terms of,

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

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

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

Ansgar Dietrichs:In scope for… for the fork. Justin?

Justin Florentine (Besu):Yeah, hi, I'm one of the authors.

Justin Florentine (Besu):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

Justin Florentine (Besu):more configuration richness, like per milestone EIP enables.

Justin Florentine (Besu):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.

Justin Florentine (Besu):So, thank you.

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

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

Ansgar Dietrichs:Hey, Felix?

Felix (Geth):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…

Felix (Geth):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.

Felix (Geth):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

Felix (Geth):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.

Felix (Geth):It's kind of a question if they should move there at some point, but it's like…

Felix (Geth):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

Felix (Geth):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…

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

Łukasz Rozmej:So, we will get there.

Łukasz Rozmej:Because I think this is very important for DevOps.

Łukasz Rozmej: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.

Ansgar Dietrichs:Makes sense. So, but in terms of the FOC, DFI on this one as well, then.

Ansgar Dietrichs:M…

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

Ansgar Dietrichs: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:Yeah. Let me just share the screen.

Csaba:Okay, yeah, so… so two of those, those things. So…

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

Csaba: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,

Csaba:Which is about the… the announcements that we have in the Manpool.

Csaba: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

Csaba:The execution and the scaling demand pool.

Csaba:The other one is specific to… to, RBF, so replace by fee.

Csaba:So we have a huge inefficiency when we are doing that for…

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

Csaba:I have a little bit more detail.

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

Csaba:And everything is fine until you can…

Csaba:Understand what are those, so you can actually get those transactions, and then you have the nonce, the, the senders, the fees.

Csaba:And then you can do something with it, but if you only have the hashes, you don't have nothing, basically.

Csaba:So, this leads to too many issues.

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

Csaba:It's also, preventing selectively fetching. Selectively fetching based on sources less, or selectively, fetching based on… based on fee priority.

Csaba:So the proposal here is to make the announcements, more… having more metadata.

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

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

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

Csaba:The other one is the 8094.

Csaba:So the problem that is targeted is that, when you are replacing a blob, blob transaction.

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

Csaba: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,

Csaba:Then you don't download the sidecar content.

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

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

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

Csaba:But we know…

Csaba:We have easy ways to reduce that, because we are not really… we are announcing to everyone, and that's a lot, so if…

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

Csaba:In the manpool. That's it, basically, to stay quick.

Łukasz Rozmej:If… I can take some comments on 8077.

Łukasz Rozmej: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.

Łukasz Rozmej:To add, nonses and, senders to the announcements.

Łukasz Rozmej: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.

Łukasz Rozmej:If, anything, other, has pressure.

Łukasz Rozmej:on the pool.

Łukasz Rozmej: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.

Łukasz Rozmej: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,

Łukasz Rozmej:Transaction data, of course, and blobs.

Łukasz Rozmej:So…

Łukasz Rozmej: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…

Łukasz Rozmej:almost all of the transaction fields into that, so that's why I kind of decided against it, not to complicate the…

Łukasz Rozmej:The process, the protocol here. So…

Łukasz Rozmej:I'm fine with that, but again, like, if your base fee is too low, or other fees, you still will…

Łukasz Rozmej:get…

Łukasz Rozmej: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.

Łukasz Rozmej:So… I don't really think that this is that crucial.

Csaba: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,

Csaba:the… the gaps… we also support gaps. The problem is that you cannot fill the gaps.

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

Csaba:Not to mention, you know, notes are heterogeneous, so not everyone can download everything. And the failed modes, in that sense, are not good.

Csaba:And then that is the advantage of having the source.

Csaba:I'm also less…

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

Csaba: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,

Csaba:Pulse of them, so we can work on the… on the bandwidth part of that, relatively easily.

Csaba:Yeah, but we can work on working out details.

Csaba:Differently.

Ansgar Dietrichs:Okay, now go.

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

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

Fabio Di Fabio:Yeah,

Fabio Di Fabio:I want to say that the other IP, replaced by fee for blobs, seems more relevant to reduce the bandwidth.

Fabio Di Fabio:About this one, I'm talking for Besu, of course. Also, in Besu, we don't have, any more issue with nonce gaps.

Fabio Di Fabio:Since the new layer transaction pool released 3 years ago.

Fabio Di Fabio:And I'm not sure about other clients if…

Fabio Di Fabio:All clients are now fine or not with non-SCAP.

Fabio Di Fabio:So, because, adding all those fields actually could… means that for simple transaction, we are…

Fabio Di Fabio:Basically, doubling the bandwidth, because If the transaction hasn't…

Fabio Di Fabio:a payload, you basically announce it, and then you need to request it again, so…

Fabio Di Fabio:At the moment, unless there are

Fabio Di Fabio:Clients are really struggling with non-gaps.

Fabio Di Fabio:maybe we need to understand which is the…

Fabio Di Fabio:The… the impact of this one in terms of… complexity and, also, increased bandwidth.

Fabio Di Fabio:So I will see the other more, important.

Fabio Di Fabio:To reduce the bandwidth on this one.

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

Csaba: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

Csaba:Bites are the problem.

Csaba:At least. This is my opinion.

Csaba:That we can… we can increase the size of the announcement and make less announcements, because we are overdoing on that currently.

Csaba:And gap… we also have gap management, it's, it's more the, the issue of of gaps

Csaba:When you are actually… then it's limited.

Ansgar Dietrichs:Okay.

Ansgar Dietrichs:Perfect. Any further questions, comments? I would want to timebox this reasonably.

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

Ansgar Dietrichs:Okay, well then, thank you very much, Shabba, and there were some questions about whether you could

Ansgar Dietrichs:share the slide link in chat, so in case that's shareable, then I think that would be much appreciated.

Ansgar Dietrichs:Awesome.

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

Ansgar Dietrichs:there was this quote, the quote was basically, proposals, headliner proposals for Heka must be submitted by February 4th.

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

Ansgar Dietrichs:But you still have time until February 4th to propose them, and then…

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

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

Jannik Luhn: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.

Jannik Luhn: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.

Jannik Luhn:Which is bad for decentralization and censorship resistance.

Jannik Luhn: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.

Jannik Luhn: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.

Jannik Luhn:It should work, for example, with both threshold encryption, or TEs, or whatever other, yeah, cryptographic solution people want to use.

Jannik Luhn:And the high-level overview over how it works is that we add a new role to the protocol called Key Providers.

Jannik Luhn:It's permissionless, anyone can register as one. And we had a new transaction type, encrypted transactions.

Jannik Luhn:And in this transaction, they reference… the user references one of the key providers that they trust.

Jannik Luhn: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.

Jannik Luhn:And then once the block is published, or the execution payload is published.

Jannik Luhn: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.

Jannik Luhn:And then the Payload Timeliness Committee that EPBS introduced, will attest to which keys have been published and which ones have not been published.

Jannik Luhn:And once the attestation is there, transactions can be decrypted and executed.

Jannik Luhn: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.

Jannik Luhn:Yep, that's… that's it, I think.

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

lightclient: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:I mean, are there quantum-resistant key systems that would be performant enough for this?

Jannik Luhn:Mmm…

Jannik Luhn: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.

Jannik Luhn: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.

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

Potuz:This would force those transactions to only be executed at the very last bit of the slot, and this…

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

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

Jannik Luhn: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…

Jannik Luhn: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:Wondering if there's any metadata of the transactions that are required to be in the clear?

lightclient:In previous examples of this, I feel like I've seen that, like, nonce or gas limit need to be available.

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

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

Ansgar Dietrichs:by Matt and Felix, or I think those two wanted to give a presentation.

Ansgar Dietrichs:Yes? Go ahead.

Felix (Geth):I can give the presentation.

Felix (Geth):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.

Felix (Geth):So, this EIP is a proposal that is in the line of proposals for account abstraction.

Felix (Geth):And, specifically, it has…

Felix (Geth):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.

Felix (Geth):And, there are other goals for account abstraction, and this transaction type also

Felix (Geth):can do those, but for us, it's, like, the primary purpose is this, like, key management topic.

Felix (Geth):the…

Felix (Geth):there is a lot of existing… there were a lot of previous EIPs regarded, related to account abstraction, one of them being the EIP7701.

Felix (Geth):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

Felix (Geth):team behind EIP7701, so it's kind of like, this is basically, like, the combination of all the ideas that various teams had.

Felix (Geth):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.

Felix (Geth):That said, there's also some new stuff, and then one of the new things is this frame list. So basically this, transaction type.

Felix (Geth):allows…

Felix (Geth):basically adds a list of multiple calls to the transaction, and then the calls run at different permission levels. We have three

Felix (Geth):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.

Felix (Geth):We have one that is… we have a specific execution mode that is…

Felix (Geth):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.

Felix (Geth):that executes as the sender. And these other two things, they don't… there's no equivalent for them right now. And,

Felix (Geth):this… Adding the frames has some implications. So, for example, also in the receipt, we have per frame

Felix (Geth):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.

Felix (Geth):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.

Felix (Geth):all of the frames of the transaction will also be executed sequentially. And the rule for executing it is specified

Felix (Geth):All the way down here. And, basically this…

Felix (Geth):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

Felix (Geth):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.

Felix (Geth):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.

Felix (Geth):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

Felix (Geth):Sponsor the fees of any transaction by adding

Felix (Geth):Like, can sponsor the… can another entity from the user can… Sponsor the transaction?

Felix (Geth):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.

Felix (Geth):They are not,

Felix (Geth):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

Felix (Geth):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

Felix (Geth):the macro operation of the EVM. And,

Felix (Geth):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,

Felix (Geth):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.

Felix (Geth):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.

Felix (Geth):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.

Felix (Geth):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

Felix (Geth):It's a big change to the state transition.

Felix (Geth):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

Felix (Geth):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.

Ansgar Dietrichs:Daniel?

Daniel Lehrner (Besu):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…

Daniel Lehrner (Besu):transaction signing is very, very low. So I think I checked before in one of these dashboards, and we only have, like, 5,000

Daniel Lehrner (Besu):Transaction… 7702 transactions per day.

Daniel Lehrner (Besu):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.

Daniel Lehrner (Besu):So, I'm not sure if that's…

Daniel Lehrner (Besu):The best way to spend our resources, or maybe delay this and do other things first.

Felix (Geth):Yeah, there's not much I can say about these concerns. This is, not, since it's not a technical concern.

Felix (Geth):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…

Felix (Geth):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.

Felix (Geth):And we kind of feel like.

Felix (Geth):Some bigger change is needed to really help people do… realize the… the things that they have to do.

Daniel Lehrner (Besu):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.

Daniel Lehrner (Besu):So, you know, to have some feedback, are they really willing to make…

Daniel Lehrner (Besu):To… to implement transactions, or… or not.

Daniel Lehrner (Besu):So this, this, this would be, you know, I mean, I understand it's not a technical concern, but it's more…

Daniel Lehrner (Besu):What's the highest priority?

Felix (Geth):It is our plan to communicate with the users of

Felix (Geth):You know, with the builders of, for example, wallets.

Felix (Geth):And other infrastructure to ensure that they can

Felix (Geth):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.

Felix (Geth):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 (Besu):Okay, thanks.

Felix (Geth):There was also concern about the mempool, I guess?

Felix (Geth):Rejecting answer.

Felix (Geth):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.

Felix (Geth):The key thing to note is that while the inside of a block

Felix (Geth):an arbitrary interaction can take place. For example, you could have transactions that do not contain a signature verifying frame. In some cases.

Felix (Geth):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.

Felix (Geth):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

Felix (Geth):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

Felix (Geth):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

Felix (Geth):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.

Felix (Geth):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.

Felix (Geth):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: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,

vitalik: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

vitalik:a verification frame and execution frames, so it satisfies,

vitalik: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,

vitalik: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,

vitalik:path, to make that FOCIL compatible without inter… without intermediaries, and so there's, a benefit in terms of,

vitalik:censorship resistance for privacy, so I think, yeah, like, the post, quantum aspect is, definitely the,

vitalik:aspect of, like, it's the reason why, account abstraction of some form is, ultimately.

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

Ansgar Dietrichs: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 (Nimbus):It's okay, it's okay, I can make it really quick. Essentially, like, can you see my screen?

Ansgar Dietrichs:Yes.

Etan (Nimbus):Okay, okay.

Etan (Nimbus):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.

Etan (Nimbus):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,

Etan (Nimbus):essentially focusing on what's urgent right now, like, it's mostly the engine API that needs…

Etan (Nimbus):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.

Etan (Nimbus):We have the problem with the hashes for the transactions and receipts. As a reminder, these are linear hashes today.

Etan (Nimbus):And transaction data includes call data, and

Etan (Nimbus):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.

Etan (Nimbus):So, getting this… this in here, just fits naturally. So, the question now is how big do we want to make it?

Etan (Nimbus):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,

Etan (Nimbus):That would allow, like,

Etan (Nimbus):the EL to pretend that it's full SSZ to the CL. The CL could,

Etan (Nimbus):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.

Etan (Nimbus):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…

Etan (Nimbus):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,

Etan (Nimbus):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…

Ansgar Dietrichs:Run over a bit.

Etan (Nimbus):I'm all for Binary Engine API and Binary ELRPC.

Etan (Nimbus):Yeah…

Etan (Nimbus):Definitely needs to be… Anna, that's for the previous one. Yeah, I mean…

Etan (Nimbus):We have synergy with the transaction EIPs, so…

Etan (Nimbus):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?

Ansgar Dietrichs:Okay, well then, we just managed to finish the scope of the call, perfect.

Ansgar Dietrichs:Thank you all very much, and I'll talk to you all in two weeks. Bye, everyone.

Marius van der Wijden:Bye-bye.

Chat Logs

Łukasz Rozmej:TooManyCallsException

Łukasz Rozmej:Replying to "TooManyCallsExceptio..." maybe better naming would be CallBufferOverflowException?

Antonio Sanso:https://github.com/ethereum/pm/issues/1889

Luis Pinto | Besu:@Maria Silva Will we be moving all the content from ACDT to this new breakout?

Kevaundray Wedderburn:PQ: https://github.com/ethereum/pm/issues/1889 L1-zkEVM : https://github.com/ethereum/pm/issues/1900

Stefan Starflinger:https://notes.ethereum.org/@ethpandaops/bal-devnet-2

Maria Silva:Replying to "@Maria Silva Will we..." The idea is to have a more focussed discussion for repricings that don’t fit in ACDT.

Jared Wasinger:We can use bal to replace the healing phase

Jared Wasinger:In snap sync

Ansgar Dietrichs:the different optimizations target different operations: state writes: parallel state root calculation state reads: batch reads compute: parallel execution so if we launch the fork without any of these supported, that specific type of operation would have to be more expensive

Jared Wasinger:Geth will have batch io by the time devnet 2 launches

Csaba:It’s still HW and bandwidth dependent. A client “not keeping up” under minimum resource requirements might still keep up with more resources.

Toni Wahrstätter:here's an updated table about the optimization readiness: https://discord.com/channels/595666850260713488/1364000387195076608/1466431329167216650

Toni Wahrstätter:This is CL sync though

Toni Wahrstätter:Until the WSP the CL will do the sync. Only after the WSP clients may fallback to snap sync and can then use the optimization

Dustin:if specific optimizations will be effectively required, it would be better to document them explicitly

Toni Wahrstätter:BAL summary: no need to wait for benchmarking for repricing. Besu and Geth are ready, having all optimizations for the critical path (but have to double check with them if it's a benchmark-able version yet). cc @Maria Silva

Stefan Starflinger:Replying to "if specific optimiza..." Added tonis table to https://notes.ethereum.org/@ethpandaops/bal-devnet-2 #Client-BAL-features

Stefan Starflinger:What limits would we run into?

vitalik:with 60/60 calldata floor, 10m size limit does not trigger until 600m gas

jochem-brouwer:We need the new eth protocol if we go higher than something like 75 Mgas due to the receipt size

Csaba:Replying to "if specific optimiza..." It feels strange to me to mandate specific implementation details, instead of mandating performance requirements.

Toni Wahrstätter:There could be the 10 MiB RLP size limit (if we don't put the calldata repricing in too). But we can avoid hitting it by just not spamming big-calldata blocks

Marius van der Wijden:Replying to "We need the new et..." eth/70 will need to be shipped with a hf, to make sure all nodes are updated

jochem-brouwer:Antwoord verzenden naar "We need the new et..." Which EIP is this? For some reason I can't find it

Toni Wahrstätter:Replying to "if specific optimiza..." Agree with Csaba, they should be described as possible optimizations and we do the benchmarking on optimized clients but in the end, clients are free to optimize how they want and if you get to the same speed as other clients without parallism, fine :)

jochem-brouwer:Antwoord verzenden naar "We need the new et..." Nvm found it

Marius van der Wijden:Replying to "We need the new et..." https://eips.ethereum.org/EIPS/eip-7975 Its in the networking category

Francesco:Replying to "if specific optimiza..." Well, as long as you don’t do it by e.g. doing it optimistically instead of using the BAL, which won’t deal with the worst case

Francesco:Replying to "if specific optimiza..." Performance requirements have to be defined quite strictly

jochem-brouwer:Antwoord verzenden naar "We need the new et..." Yup, thanks :) I thought this was already proposed for Glamsterdam. Does it need to be shipped with a hf? Technically not right, eth/70 is somewhat opt-in, but mandatory once we raise gas limit above that 10 MB receipt threshold

vitalik:I don't like this because it makes "is empty" part of the de facto storage interface

vitalik:imo we should keep the storage interface ro a clean get(key), set(key, val)

Csaba:Replying to "if specific optimiza..." I agree, it should be strict. It should be on worst case, and on specific test cases. But “having implemented a vaguely defined technique” is I think worse in many ways.

vitalik:(I guess we also have a "next" operator for tree transitions but that's an exceptional case)

Łukasz Rozmej:famous last words ;)

vitalik:hmm I see, triggerable at 2**80 cost, quantum won't help much but classical compute growth would

vitalik:with tree transition emptiness becomes unverifiable

Danno Ferrin - Tectonic.xyz:Every other client has implemented this EIP

Csaba:Replying to "if specific optimiza..." I can have parallelism, yet a mutex that effectively makes it not work in parallel. To specify it well I’m afraid we would be going into so much language specific details, that we would loose some of the advantages of having all these implementations.

Danno Ferrin - Tectonic.xyz:2^80 is not terribly good securty as it is.

Etan (Nimbus):isn’t 20 bytes 2^160?

Dragan Rakita:Current difference for the clients is if they are passing steel test or not, this needs crafted test to trigger

Dragan Rakita:Reth didn’t implemented it for example

Danno Ferrin - Tectonic.xyz:Replying to "isn’t 20 bytes 2^160..." square root attack exist s classiclly. grover’s (quantum) is another square root

Danno Ferrin - Tectonic.xyz:Replying to "Reth didn’t implemen..." And reth is the only one

vitalik:Replying to "isn’t 20 bytes 2^..." grover needa cube root to find collision

jochem-brouwer:If we would rewrite ETH spec we would include this rule. The behavior is currently not specified, so we have undefined behavior. Which is not nice. We know if this situation is triggered we will get a chain split between reth and other clients.

vitalik:Replying to "isn’t 20 bytes 2^..." so, 2**53,multiplied by whatever the quantum overhead is (almost certainly crazy high at first)

Mario Vega:Replying to "Reth didn’t implemen..." @Danno Ferrin - Tectonic.xyz could you share the name of the test that triggered this pls? just if you have it on hand if not is ok

Dragan Rakita:Replying to "Reth didn’t implemen..." @Mario Vega I think @Jen have added description in hive for all tests that we skip. List should be somewhere there

Marius van der Wijden:We have it implemented in geth already. Also heavily in the dfi camp

Danno Ferrin - Tectonic.xyz:Replying to "Reth didn’t implemen..." https://github.com/ethereum/execution-spec-tests/blob/main/tests/paris/eip7610_create_collision/test_initcollision.py

Łukasz Rozmej:Replying to "We have it implement..." same in Nethermind

Danno Ferrin - Tectonic.xyz:It was actually part of the Paris tests if that commit is correct.

Marius van der Wijden:Replying to "We have it impleme..." 7 authors for a cli flag

Etan (Nimbus):Replying to "We have it implement..." “author” is just write access on the eip

Marius van der Wijden:Replying to "We have it impleme..." Sounds like airdrop farming to me 🤪

FLCL:Replying to "We have it implement..." Airdrops still exist?

Danno Ferrin - Tectonic.xyz:Replying to "Reth didn’t implemen..." So if 7610 is formally pulled we will need new tests.

Jen:Replying to "Reth didn’t implemen..." For reference: I added a TLDR to describe the problem statement in our hive test failures https://github.com/paradigmxyz/reth/blob/70bfdafd26905a19beb22bc1db7012494919fa22/.github/scripts/hive/expected_failures.yaml#L46

Luis Pinto | Besu:Same case as the RPC standardization

Danno Ferrin - Tectonic.xyz:This specific test is the storage collision - https://github.com/ethereum/execution-spec-tests/blob/main/tests/paris/eip7610_create_collision/test_initcollision.py#L102

Felix (Geth):omg this slide design...

felipe:Replying to "Reth didn’t imple..." Just putting the current link to it here, since execution-spec-tests is no more :) https://github.com/ethereum/execution-specs/blob/590bc9f045baacca112ef56e4fe0769eed8b76d3/tests/paris/eip7610_create_collision/test_initcollision.py#L117

Łukasz Rozmej:maybe we should go 1 by 1 with discussion?

Kevaundray Wedderburn:Replying to "We have it implement..." Sorry was having some issues — I think its okay to DFI if most clients have it implemented — it was meant to be implemented pre-Fusaka so this was meant to be a forcing function for it

nixo:can we get the presentation link? :)

FLCL:Replying to "We have it implement..." (actually want to say big thanks to everyone who helps via protocol guild / via airdrops, it really helps to make debugging of state root mismatches way less stressful, we will win together)

Łukasz Rozmej:Can you show the slide with the bandwith?

Felix (Geth):I think we all support gaps somehow but it's not great how they are handled.

Łukasz Rozmej:share slides please!

lightclient:What key system does this use?

vitalik:sounds like it's abstracted, any key system is allowed?

Justin Florentine (Besu):Replying to "What key system does..." it is an abstraction, so it is flexible.

vitalik:so this makes the key provider a last looker, which makes them MEV-bearing

Łukasz Rozmej:So for historical sync/archive node/sync from p2p you need to download block and keys? So Keys would need to be storred and included in ERA formmats?

Csaba:My slides on EIP-8077 and EIP-8094 https://drive.google.com/file/d/1qbYfroCds8_DCpVfzM1qm2HKjYLDntu9/view?usp=sharing

vitalik:technically even the "decryption" metaphor is a suggestion

vitalik:the key providera could just do hash preimage reveal

vitalik:which further underlines that this is an mev bearing last looker role and will get *boosted :D

lightclient:Does this leak tx meta data?

lightclient:Replying to "Does this leak tx me..." Nonce, gas limit, etc

Anders Elowsson:Three things to discuss: Not compatible with BALs Key providers may not know whether payload becomes canonical at time of propagating keys. Game theory of trust graph.

Etan (Nimbus):who pays if the tx ends up failing due to not enough balance / skipped nonce etc?

Ansgar Dietrichs:to make it through all 3 headliner proposals, I will timebox each to 10min, so ~2min left for this one

Potuz:Replying to "Three things to disc..." 4. Key presence being part of consensus or not

DA | Flashbots:Replying to "Three things to disc..." First thought, trust graph seems to have much stronger network effects than OFAs

Łukasz Rozmej:Replying to "who pays if the tx e..." I think this is the same as for normal txs

Anders Elowsson:I have been working on a generalisation of sealed transactions for a while that indeed delays the execution to the next slot. Sharing a draft here that might be interesting. Not fully ready to publish yet: https://notes.ethereum.org/@anderselowsson/LUCID-v7

DA | Flashbots:Is this just for mev bearing transactions? Execution quality will be hard to compete with gains from backrunning in OFAs

Potuz:doesn't leaking the tx gas payer lose a lot of the applications for encrypted txs?

Justin Florentine (Besu):Replying to "Does this leak tx me..." new tx type has a sub-envelope that has added metadata, yes.

Potuz:Replying to "Does this leak tx me..." Ah my question fits better here > doesn't leaking the tx gas payer lose a lot of the applications for encrypted txs?

Anders Elowsson:Replying to "Does this leak tx me..." In LUCID linked above it is hidden

Jannik Luhn:For more on EIP-8105, we’re hosting a discussion session next week, Tuesday, ACDE time: https://meet.google.com/ccw-dwbm-mai

lightclient:https://eips.ethereum.org/EIPS/eip-8141

Anders Elowsson:Replying to "Does this leak tx me..." Sender of sealed transaction and revealed transaction can differ

Justin Florentine (Besu):Replying to "Is this just for mev..." yes, backrunning isn't really addressed.

Potuz:Replying to "Does this leak tx me..." the same can be applied here it seems

Chris Haug:Replying to "For more on EIP-8105..." is there a cal event for it?

Anders Elowsson:Replying to "Does this leak tx me..." Yeah

Jannik Luhn:Replying to "which further underl..." yes, I would expect builders selling this slot to backrunners

jochem-brouwer:Antwoord verzenden naar "For more on EIP-81..." Could you add a protocol calendar item for this?

jochem-brouwer:Antwoord verzenden naar "For more on EIP-81..." To do so, open an issue in https://github.com/ethereum/pm/issues

DA | Flashbots:Replying to "which further underl..." fwiw bottom of the block is a bit less important for backrunning these days; since OFAs have grown and now it just happens directly behind transactions in most cases

Marius van der Wijden:Damn, doesn't sound easy

Ansgar Dietrichs:I think we won’t have a choice but to ship some version of native AA eventually for pq readiness. So to me the main question here is “is this the right variant” and “is it the right time”

Jannik Luhn:Replying to "Three things to disc..." 1: BALs could be generated by the next builder, but yes, there’s a brief time in which they are not available 2: yes, but key providers could listen to attestation and only release when they see enough of them. Also, via the key vlaidation function, they can make keys only valid for a single slot, in order to prevent replaying the (now decrypted) transaction

Jannik Luhn:Replying to "who pays if the tx e..." The fee is paid as part of the envelope execution. If the encrypted part fails, there’s no refund.

frangio:how does this look in the mempool?

Potuz:I love the fact that this EL headliner doesn't touch the CL :)

FLCL:Does it need blobs?

Felix (Geth):Replying to "Does it need blobs?" yes

Felix (Geth):Replying to "Does it need blobs?" because it is a replacement for all tx

Ansgar Dietrichs:Replying to "I think we won’t hav..." my intuition is on “is it the right time” - yes. on “is this the right variant” - I don’t have an opinion yet

Anders Elowsson:Replying to "Three things to disc..." Without BALs, these transactions cannot be executed under parallelisation guarantees correct? I agree with second point, but then the transactor would have to leak what they want to do in the future, which is still not ideal.

Ansgar Dietrichs:I think the comparison to 7702 is less relevant, more relevant is 4337

lightclient:Also 7702 has much more than 5k txs per day. Weekly successful user op is in the 1m range

Jannik Luhn:Replying to "doesn't leaking the ..." I don’t think this is an issue for frontrunning protection which is the main goal, only for censorship resistance. And for these cases, the gas payer does not have to be the same address as the payload signer, so there can be relayers or some other misdirection

Ansgar Dietrichs:Replying to "Also 7702 has much m..." maybe difference is in delegation txs vs then usage of these delegations?

lightclient:Replying to "Also 7702 has much m..." Could be

CPerezz:PQ-readiness + Privacy through AA are 2 things that significantly improve ethereum over any other financial infra existing today. Not even banks are PQ-ready. And this would be a huge differentiator. It definitely looks like a must-ship together with FOCIL

lightclient:Replying to "Also 7702 has much m..." Main net numbers here: https://www.bundlebear.com/eip7702-overview/ethereum

Jannik Luhn:Replying to "Does this leak tx me..." yes, the envelope signer and the payload signer can be different

Daniel Lehrner (Besu):I checked this dashboard for 7702: https://dune.com/wintermute_research/eip7702

Jannik Luhn:Replying to "For more on EIP-8105..." will do

Jannik Luhn:Replying to "which further underl..." interesting!

Potuz:will this EIP make the one for encrypted mempools more powerful to allow for arbitrary signing?

Jannik Luhn:Replying to "which further underl..." One aspect that makes it a bit more complicated is some time passes between the block building and last possible key revelation, so external markets might have moved

Ansgar Dietrichs:if we want to do this, it definitely needs to be headliner imo. not just because of implementation complexity, but also because it would require a big concentrated push on ecosystem education and adoption

Marius van der Wijden:Replying to "I checked this das..." I love the breakdown, 70% crime

Mario Havel:Replying to "if we want to do t..." Makes sense to me as headliner to promote security and UX

marissa:Replying to "if we want to do thi…" Yes it’s worth talking about what the plan is on the ecosystem education and adoption side.

Marius van der Wijden:I am all for binary engine api and binary el rpc (somehting we have been looking into already)

Kevaundray Wedderburn:I’m in favour of this, especially replacing the engine API with SSZ

FLCL::lfg:

Pooja Ranjan:No mic needed, Please also note that there are a few Fusaka-related EIPs that are still awaiting author responses, as listed here: https://github.com/ethereum/pm/issues/1883#issuecomment-3817808224 Requesting the authors to review and close the pending items at the earliest, so we can close Fusaka's open items. Thank you.

lightclient:Replying to "I checked this dashb..." I’m honestly not sure how the numbers are so far apart

Summary

11 highlights · 3 decisions · 3 action itemsExperimental

fork status and schedule

DevNet 2 launching February 4th with updated clarifications00:03:37
Headliner proposals due February 4th; presentations follow on subsequent calls00:38:15

client updates

Geth and Besu ready with all three BAL optimizations00:06:35
Batch read optimizations needed by end of February for repricing00:12:45

testing progress

DevNet 2 document updated with EIP clarifications and feature flags00:03:45
Considering 150M gas limit for DevNet 2 testing00:22:20

repricing updates

Batch reads crucial for repricing; benchmarking needed to determine gains00:07:54
Core optimizations required by end February for April Interop events00:08:58

organizational

Post-quantum breakout call starts February 4th at 3pm UTC00:01:33
L1-zkEVM breakout call scheduled February 11th at 3pm UTC00:01:49
Glamsterdam repricing breakout bi-weekly Wednesdays 2pm UTC starting February 4th00:02:22

Decisions

EIP-7610 moved to CFI; implementation divergence unresolved00:34:55
EIP-7872 moved to DFI; out of fork scope00:41:09
EIP-7949 moved to DFI; clients to standardize independently00:45:20

Action Items

Client teams: Fill out client BAL optimization feature flags in DevNet document00:04:17
Client teams: Check limits for potential 150M gas DevNet 2 increase00:21:47
Ansgar: Investigate documenting BAL optimizations as fork scope expectations00:25:17

Targets

February 4th - DevNet 2 launch00:03:45
End of February - BAL optimizations deadline for benchmarking00:08:58
February 4th - Headliner proposal submission deadline00:38:15