AllCoreDevs - Execution #230

|2026-02-12| Agenda: #1921| canonical JSON

Transcript

Ansgar Dietrichs:Well, hello everyone. Welcome to All Core Devs 230.

Ansgar Dietrichs:I'll put the link to the agenda in…

Ansgar Dietrichs:chat. Yeah, we have two main topics today, really. One is the Glamsterdam DevNets, and then the other is, the Hegota headliners.

Ansgar Dietrichs:So, on the DevNets, first, we want to start with an update of the status of BAL DevNet 2, which went live, I think, last… yeah, sometime last week, right? And Stefan, I think, is on the call to give a quick update.

Stefan Starflinger:Yeah, sure.

Stefan Starflinger:So, it was a little bit, rough in the beginning. We had a few notes that were,

Stefan Starflinger:had some issues with the individual EIPs, but I think by now, we've managed to

Stefan Starflinger:iron out most of the issues with the clients. I would just like to remind all the clients to look at the Hive tests. We're still not passing all of the Hive tests, but it seems, from a consensus point of view, all the nodes are doing pretty well on the DevNet.

Stefan Starflinger:So, I can quickly also share the link.

Stefan Starflinger:To the definite.

Stefan Starflinger:here to the DORA Explorer.

Stefan Starflinger:And we've also started spamming transactions, so we're spamming right now EVM fuzz transactions that should catch most of the EVM-related EIP changes.

Stefan Starflinger:And we're spamming just Uniswap transactions to get some estate on there. And we've also been working on preparing, different, testing nodes with different configurations.

Stefan Starflinger:So I'm working on 3 configurations now for Geth and Besu. They have flags now to toggle on the and off the bell optimizations.

Stefan Starflinger:So there's, flags to, enable prefetching the state, so that in the beginning, you use the bar to then do all the state reads.

Stefan Starflinger:to see if that, has some improvements, and then there's, for the parallel execution, there's a flag as well. So I'm gonna set up three types of nodes, one without any optimizations.

Stefan Starflinger:One with optimizations, but without the prefetch, and one with optimizations and the prefetch enabled. And when other clients are ready, it would be great if they could give me an update.

Stefan Starflinger:On that, and if they have the flags as well, later on.

Stefan Starflinger:Yeah, I think that's pretty much it from the DevNet, decide.

Stefan Starflinger:Maybe someone else has something to add or wants to give an update.

Ansgar Dietrichs:Andrew.

Andrew Ashikhmin:So, about Erigon status, yeah, I have to apologize, we are still not fully ready on the Bell DevNet2 level, and there are a few reasons for that. So, well, I was on holiday last week, and another team member working on Bells was ill last week, and also.

Andrew Ashikhmin:We, based our bell code on, parallelized EVM, which still needs, some…

Andrew Ashikhmin:some finishing touches to be robust. So, yeah, we're working on it, so hopefully in a week or so, we'll be able to pass the tests and join the DevNet.

Ansgar Dietrichs:Sounds good.

Ansgar Dietrichs:Any other client devs, anyone else with any… Definitely two related comments?

Toni Wahrstätter:Maybe just as a quick heads up, we had a breakout call yesterday, and the two outcomes were that the JSN RPC will be slightly changed, I posted it into the Block Live Access List Discord today, and we introduced a max item limit, to the BAL, which is just a DOS measure.

Toni Wahrstätter:So yeah, clients, please look into that.

Ansgar Dietrichs:Sounds good. And I assume, Tony, just to confirm, I would assume that the… these changes would then be…

Ansgar Dietrichs:expected to go live on DevNet 3?

Toni Wahrstätter:Yeah, exactly.

Ansgar Dietrichs:Sounds good.

Ansgar Dietrichs:Any other DevNet 2… Comments?

Ansgar Dietrichs:Otherwise, then, on the next agenda point, one of the DevNet2, EIPs, EIP 8024, the swap and dupe and that one, there, I,

Ansgar Dietrichs:two changes to the spec that Francisco, the champion, AP champion, wanted to, briefly, discuss. Are you on the call?

frangio:Yep.

frangio:Yes, so the first change we've talked about before, and it was… we decided to postpone it until after DevNet 2.

frangio:Dragon was the main, the main one that wanted to see this change, but I feel, you know, I've argued already, I think we need to reject that. And I also heard from someone from the Solidity team similar concerns, the main one being,

frangio:the code size, impact of the exchange opcode, which would probably be used quite frequently. So we just need to make a final decision on that. The PR is still open.

frangio:But I don't think Dragon is here to comment,

frangio:The other one is a small simplification to the way the encoding is done. It just allows…

frangio:The decoding to be, you know, have one less branch.

frangio:I, I, I like this one, it's very simple.

frangio:So, yeah, just… Let me know what everyone thinks.

Ansgar Dietrichs:Sounds good. And is this something that we would need to have a synchronous decision on any of these today, or is that more like a heads up for people to come and, have a look asynchronously?

frangio:Yeah, I mean, I would have liked to decide on the first one now, but it's not really…

frangio:Critical, or doesn't really require synchronous decision.

Ansgar Dietrichs:Sounds good. Ben?

Ben Adams:Yeah, the first one, I mean, the… how it works now seems fine. I don't…

Ben Adams:I don't see that it… changing it to have the, prefix, gives anything.

Ben Adams:You know, gives a massive advantage.

Ansgar Dietrichs:Yeah, so sounds like we are leaning towards rejecting that one, but then, yeah, if the main person that was in favor of that isn't on the call today, maybe we… we can make the final decision asynchronously, but… yeah.

frangio:Oh, I see, Dragon, you just joined. Do you want to comment on… we're talking about Push, post-fix.

Dragan Rakita:Can you repeat that? Sorry.

frangio:We are talking about EIP 8024, yes.

Dragan Rakita:What do you feel about rejecting the…

frangio:the change.

Dragan Rakita:I have some small preference to having it with push, because it seems, like, more canonical.

Dragan Rakita:But I wouldn't mind going to original, original, original way. Either way, the top…

Dragan Rakita:Those opcodes are important, so anyway…

frangio:Okay, then I think I'll close this PR, it sounds like, generally.

frangio:You know, the only strong arguments are for rejecting that change.

Ansgar Dietrichs:Okay, sounds good. And then, yeah, I think clients should then have a look at the other one, the proposed small simplification. I think it would be good if we could have a decision in time so that whenever Definite 3 comes around, we have that updated version there.

Ansgar Dietrichs:Okay, thank you, Francesco. And then, next up was, a topic that Barnabas wanted to bring up, but then unfortunately couldn't make the call. I think maybe Stefan also can give some context, that is the…

Ansgar Dietrichs:Each simulate V1, support in… RPC support in clients.

Stefan Starflinger:Yeah, sure. So, in general, we want to bring the RPC to be more uniform across the clients, and there is, like, a compatibility effort, and it would be great if

Stefan Starflinger:clients could put some work into this for DevNet 3.

Stefan Starflinger:So we want to, kind of…

Stefan Starflinger:demand this, to be, part of DevNet 3 to,

Stefan Starflinger:push this effort forward, and combine that, in a sense. I can also kind of then use that to talk about our recommendations for DevNet 3. So we would, want to have

Stefan Starflinger:the following, indefinite 3, so the state, creation gas cost increase, and the increased maximum contract size. We think that's, quite a lot, already, so we wanted to

Stefan Starflinger:Keep it as these two EIPs, and then the rest for DevNet 4 and beyond.

Stefan Starflinger:That's kind of, from our side.

Ansgar Dietrichs:Yeah, then maybe, before we go into the discussion on the three priorities, first, just on the ETH Simulator V1, was there any comments on that part? Just to sequence it?

Ansgar Dietrichs:Because otherwise, on, yeah, on DevNet 3, then, I also, I want, like, just wanted to briefly say that, there's been some discussions also that, that, that,

Ansgar Dietrichs:that I've heard different takes. The EF testing team, for example, requested to keep the EAP-related scope lean, because they are very busy already with assisting the repricing effort and preparing for these EAPs, but the EAPs themselves will not be ready for DevNet 3.

Ansgar Dietrichs:So, so the ask was to keep… keep the EIP side scope lean, and so I think, Stefan, the, the kind of the priorities that you.

Ansgar Dietrichs:Listed there,

Ansgar Dietrichs:I think roughly match, from what I've heard. Otherwise, also, I also put a small list together, I'll put it in…

Ansgar Dietrichs:chat… oh, it's not formatting particularly well. Okay, this is useless.

Ansgar Dietrichs:So, so, so, so basically, let me just, let me just briefly go through it. Yeah, so, so basically, like, on the, on the non-EIP front, I think the one big ask, it was the, the eSimulate V1, where I'm not sure if clients on here have a take on whether that's realistic to…

Ansgar Dietrichs:to… to get to standardized behavior by… by DevNet3, but… but that was… that was the ask from…

Ansgar Dietrichs:from the,

Ansgar Dietrichs:Pdop side, and then the big other topic is the bar optimizations, particularly the ones that are not related to sync, but to live block processing, so parallel execution, parallel state rule calculation, and batched state reads.

Ansgar Dietrichs:M…

Ansgar Dietrichs:the target would be to have those ready in all clients by DevNet 3, but if that's not possible, the broader point would be to just prioritize work on those over

Ansgar Dietrichs:further EIP inclusions, basically saying that, like, we should not get sidetracked by… by prioritizing further EIPs before those are ready, so… so that this would be the number one kind of priority for clients.

Ansgar Dietrichs:And then on the EIP side, yeah, the two EIPs that came up repeatedly, as definite 3 candidates are the state creation one, 8037, and the maximum contract size one at 7954, and I think that those were the two that you also just mentioned, Stefan, if I'm… I mean, I'll double-check and chat, but yeah, looks like that.

Stefan Starflinger:Exactly.

Ansgar Dietrichs:the same.

Ansgar Dietrichs:Exactly. The one thing I would want to mention is just that, in terms of, then, further priorities, often the data repricing, specifically, I mentioned is, like, the next in line, so that's the call data flow cost and the access list cost, and there were some suggestions about potentially considering that for DevNet 3 already. Again.

Ansgar Dietrichs:From the testing side, it seems like we really want to be cautious with scope, so I personally…

Ansgar Dietrichs:lean against that, but that has come up, whether the data reprising could already be part of .NET 3.

Ansgar Dietrichs:Yeah.

Ansgar Dietrichs:One last question, maybe, Tony put it in chat. Each70 has, for now, its own DevNet, that's actually our next agenda point, and my understanding is that it will not be ready in time to be merged with DevNet 3 as a single DevNet, so we would probably only merge those two DevNet efforts for DevNet 4.

Ansgar Dietrichs:But yeah, does that in general match people's,

Ansgar Dietrichs:priorities, people's takes on DevNet 3, and general prioritization work for the next weeks, or are there disagreements? Tony, you have your hand up?

Toni Wahrstätter:Yeah, I'm wondering what does this mean for the gas limit in definite free? Because it seems like if we don't do EV70 on definite free, and we also don't do the data repricings, the gas limit

Toni Wahrstätter:Might not be able to go upright.

Toni Wahrstätter:Because we're already running into the limits then. And this is even a difficult problem, because the limit is not like the payload limit, but more on the def P2P side. So I'm wondering if…

Toni Wahrstätter:not… Repricing coal data also means that we can't increase the gas limit over 70 or 80 million in

Toni Wahrstätter:Definitely.

Ben Adams:I mean, the cold… the cold air shouldn't affect anything.

Ben Adams:Interesting.

Toni Wahrstätter:All data affects the payload, yeah, this doesn't affect… I mean, it affects the FP2P, too, but what I… I think we are hitting the 10 megabit limit with receipts.

Ben Adams:Yeah.

Toni Wahrstätter:So this, yeah, you're right, yeah, the collateral repricing wouldn't affect it at all, it's only EV70. So I guess we are blocked by EV70 before we can actually increase the gas limit to something above 70-80 million?

Marius van der Wijden:Well, it kind of depends on the load of the network, right? Like…

Marius van der Wijden:If we just assume that no one is spamming these, these, big call it, transactions, sorry, big, big receipts transactions, we can just go beyond.

Marius van der Wijden:It's just, in the case that there's someone spamming these transactions.

Marius van der Wijden:It will mean that some notes cannot, snap-sync Too this definite anymore.

marek:So, in case of Nethermind, you can snap sync, but you will not sync receipts. So, there is no big damage, this is what Mario is saying, as long as…

marek:Major clients have this released.

Toni Wahrstätter:Yeah, I guess this is then fine. As Mario said, we should just be aware that we might not run all the tests we have against definite free, just because there might be tests that would already trigger that edge case.

Ansgar Dietrichs:Happy Lynx?

Felix (Geth):Just to give a quick comment, I think it's pretty unlikely to hit this edge case in practice unless you really try. So, if you just,

Felix (Geth):I don't think it has any limitations on the testing.

marek:Do you guys agree that good criteria will be, like, if, you know.

marek:clients have releases with this, new EF protocol.

marek:Then we are good to go.

marek:I mean, we are not blocked with gas limit, because of this receipt issue.

Felix (Geth):Yeah, I mean, I agree. Definitely, I agree. I think it's a… the risk of this is…

Felix (Geth):a bit overstated, and as long as we have… I mean, we know how to solve it, and we have worked out the details, so as far as I understand, this is now just a matter of releasing it, which…

Felix (Geth):Will happen quite soon.

Marius van der Wijden:Hey.

Marius van der Wijden:I wouldn't want to push mainnet beyond

Marius van der Wijden:This before a hard fork where we know that everyone has implemented it yet, though.

Marius van der Wijden:Because I think… That would set, like, a pretty weird precedent that we are knowingly, pushing beyond

Marius van der Wijden:A certain gas limit where we know that some…

Marius van der Wijden:Part of the network is kind of…

Marius van der Wijden:Might, might have issues with it.

marek:Mmm… right.

marek:But it's only for new synced nodes, correct?

marek:So… I don't know. Maybe you're right, but I'm not sure if we should wait for hard fork here.

Felix (Geth):So it is not dependent on the fork. If… once this… the protocol update is released, and there's some uptake by the network, we are good to go.

Felix (Geth):And the update prevents, again, a corner case, Where if the…

Felix (Geth):If the gas limit is fully utilized to send these specific transactions, then it can cause the issue.

Felix (Geth):So… I think we are honestly fine.

Felix (Geth):But I also would say that it would be good to get some signal on the adoption of the protocol, so I think it is too early to say, let's push the gas limit of the network.

Felix (Geth):Until we have…

Felix (Geth):at least released this update, and we know that there is some uptake. It doesn't depend on the fork, it just depends on the update being adopted.

Ansgar Dietrichs:Right, so maybe one framing, it was supposed to be the next agenda, or, like, one, two agenda points down, but we can discuss it now as well, like, basically.

Ansgar Dietrichs:then do we want to have ETH70? It's currently not part of the glum stump scope, because again, yeah, it can be rolled out earlier, but there's usually… there's a benefit of having, like, an official kind of hard fork point where we can afterwards just

Ansgar Dietrichs:be certain that everyone on the network supports it, so…

Ansgar Dietrichs:One question would also be whether we would want to just have this be CFI'd as part of the, our Glamstar meta in the non-consensus-changing, part of… of the piece, just to… to…

Ansgar Dietrichs:to highlight that by Glamstam rollout, we expect the entire network to be on each70? Does that make sense, or do we expect the rollout to happen anyway before then, or how do people feel about, like, the rollout timing of each70?

Felix (Geth):I can speak about it as well, so the thing is that in… for Amsterdam, there is also

Felix (Geth):The plan to release the block-level access list, and this also has a networking component, and because of this, we definitely should

Felix (Geth):have it Ready by that time, because the, the, the network protocol follows, linear versioning, so we…

Felix (Geth):Cannot have, like…

Felix (Geth):some changes without some other changes, like, at some point, we should just basically… so E70 is now…

Felix (Geth):as far as I'm concerned, and as far as other clients are concerned, the next change we're going to make to the network protocol, and then after that, we're going to make the change that is related with the block-level access list, and that's going to be ETH71. And that one is already scheduled, also, for Amsterdam, so…

Felix (Geth):we just basically have to put it in Glamsterdam.

Ansgar Dietrichs:Sounds good. Then, just briefly, like, is there anyone who'd be opposed? I mean, it's a little bit… but I think, given that it was implicitly already part of Glamstam Scope, just to make this explicit and put ETH70 as CFI for the Glamstadam Meta EAP,

Ansgar Dietrichs:then, yeah, we'll do that. And then in terms of…

Toni Wahrstätter:I'm right, 70 and 71.

Ansgar Dietrichs:Yes, Felix just said it was already, but yeah, I'll double check. If each 71 is not yet part of the Glam Center meta, then indeed adding it there as well.

Felix (Geth):Is it a separate EAP, the E71?

Toni Wahrstätter:That I don't know. Yes, so yes, since, yeah, since a few days. So, previously I only did the specs, but Jochen was saying that this should actually be its own EIP, just for the process sake, so it's now also its own EIP, but basically everything that we had in the specs.

Felix (Geth):Now, that's good. I can say that here also maybe one more time. So, it is usually nice to have an EIP for the protocol changes, because the EIP is a chance to elaborate more on the reasoning for the change.

Felix (Geth):So, in this… inside of the spec, we have a changelog that details just the changes made to the spec.

Felix (Geth):But often the rationale for these changes is missing, because we cannot dump all of it in there. So it's more… better to have an EIP that explains

Felix (Geth):The rationale for these changes, and also gives more context, and possibly even some test cases, and then we can…

Felix (Geth):the actual spec update usually isn't all that big, so the EIP has more effort, and we always…

Felix (Geth):also link the EIPs from the changelog in the protocol, so there is actually the possibility then to dig further if this is…

Felix (Geth):this is required, and we have done this for all past protocol… network protocol changes, so I feel like it would be nice to keep this tradition going.

Ansgar Dietrichs:Yeah, sounds like people agree with this.

Ansgar Dietrichs:M…

Ansgar Dietrichs:then… can we briefly then come back to DevNet sequencing, and specifically under this aspect, so ETH70 and ETH71, given that my understanding is that ETH70 would not be ready to be combined with the main DevNet3 effort, like, obviously, this is to be confirmed, I mean, maybe this changed, I don't know if Marius can talk on this, but…

Ansgar Dietrichs:If that is the case, then I would assume that we could not… we would also have to have to wait with Ether71.

Ansgar Dietrichs:Until, until the 70 is ready? Or how does this, Felix, you mentioned this linear dependency.

Felix (Geth):I mean, mostly it's just also a matter of the implementations. If we now decide… if somehow we decide to make the block-level access lists

Felix (Geth):networking changes a part of the… of the DevNet, then it becomes really awkward in the implementations, because we have to somehow support, like, some version of ETH70, or whatever, ETH71, that has only the block-level access list, but not the other stuff, and so on. It's just a bit…

Felix (Geth):It's just, like, a conflict, basically.

Felix (Geth):I would say that… it…

Felix (Geth):when is… I didn't fully follow the process, but when is the deadline for the DevNet 3?

Stefan Starflinger:We haven't set a deadline yet, because Barnabas is the deadline guy, but,

Stefan Starflinger:Generally, like, we want every two weeks, so…

Stefan Starflinger:Probably in two weeks' time from now, around then would be good, if we could have a definite, but it really depends on

Stefan Starflinger:how complicated the EIP will be to implement.

Felix (Geth):Yeah, so we… we can maybe do a quick round of…

Felix (Geth):of readiness for the ETH70 change. This is the partial receipt list, so as far as I know, like, so in Geth, the change is ready, and so we are… we will probably be able to merge it within the next two weeks.

Felix (Geth):Oh yeah, there's also an ETH70 dev net, well, yeah, that… Nope.

Felix (Geth):Marius has the update, so Geth and Nethermind are working. Fabio, you also want to make a comment?

Fabio Di Fabio:Yeah, on the Besus side, the implementation is ready, I'm now… Trying to join the DevNet.

Fabio Di Fabio:And I think, next week… She'll be… Complete.

Felix (Geth):Okay.

Felix (Geth):So this then leaves… Erigon Wrath.

Felix (Geth):And ETHREX to… to update…

Dragan Rakita:From Redside, we have implementation for ATH70.

Dragan Rakita:I think Matt updated the docker image, but I need to check where it is exactly.

Dragan Rakita:But yeah, I think we have… we have that implemented.

Felix (Geth):Okay, good.

Felix (Geth):So then, yeah…

Andrew Ashikhmin:On Erigon, we don't have an ETH70 implementation yet.

Andrew Ashikhmin:But unless we are switching off ETH69 in DevNet 3, it shouldn't be a blocker, should it?

Felix (Geth):No, it's not. It's just about the… like we were saying, it… this…

Felix (Geth):The issue that is fixed by ETH70 is a corner case in the sync, which only is active if you are syncing receipts from the network, which Erigon might not even be doing.

Felix (Geth):So…

Andrew Ashikhmin:Right.

Felix (Geth):Yeah, so in that case, it is not affected by this issue at all, and, I mean, you will have to implement it on the server side in the longer term, but it's not a blocker.

Felix (Geth):And, I mean, the main thing you have to realize is that if Erigon is to be participant in the block-level access lists protocol, which is also in ETH protocol, then this protocol version will be ETH71. And then by that time, we also expect you to serve the ETH70.

Andrew Ashikhmin:Yeah, sure.

Felix (Geth):So that's just… but I don't think we… yeah, I think for Eragon, it's… It's no big deal, so…

Felix (Geth):Yeah. Sounds like we are mostly aligned, and… It's fine to make this…

Felix (Geth):a partis- like, a part of the Definite 3.

Felix (Geth):Spec.

Ansgar Dietrichs:Okay, so you're saying E70 is part of DevNet 3 spec, but, you know…

Ansgar Dietrichs:Clients that don't support it yet can still participate in the DevNet.

Ansgar Dietrichs:Does that generally… Sound reasonable for people?

Ansgar Dietrichs:And if so… then for ETH71, just to confirm though, that would not yet be part of DevNet 3 scope, right?

Stefan Starflinger:How much work would…

Andrew Ashikhmin:To collaborate at the time.

Stefan Starflinger:I don't want to make a decision on that yet, I think.

Stefan Starflinger:on ETH71.

Ansgar Dietrichs:Okay, yeah, that's reasonable. So, basically, E71 TBD, makes sense.

Ansgar Dietrichs:Okay, then, just to kind of start to wrap up the agenda point on…

Ansgar Dietrichs:Definitely priorities, so,

Ansgar Dietrichs:Yeah, so basically, I think Nick's also posted a less terribly formatted version of the… of the priorities in chat a while ago,

Ansgar Dietrichs:As we talked about, the bioptimizations.

Ansgar Dietrichs:top priority in terms of client attention right now. And then beyond that,

Ansgar Dietrichs:EIPs 8037 and 7954 as the two main candidates for DevNet 3. Is that a good conclusion of this section? Did any clients have any?

Ansgar Dietrichs:Major objections, or otherwise comments, Ben?

Ben Adams:I mean, I'd be happy with more, but, it's down to the specs and… Testing, really.

Ben Adams:If they want less, that's fine.

Ansgar Dietrichs:Yeah, that really was an explicit ask this time around, so I personally prefer… we can always, like, last minute, or, like, when we get close to DevNet 3, we can still kind of decide to add things if the situation changes, but it seems like…

Ansgar Dietrichs:Right now, at least, we should plan towards just those two.

Ansgar Dietrichs:but actually we have Mario. Mario?

Mario Vega:Yeah, I think, I mean, it's, the only concern right now is the geyser pricing effort that we're currently doing in parallel. I think that that is taking a lot of our time, just to make sure that

Mario Vega:We can fill the tests with the different gas surprises. We are making a lot of refactoring in our testing framework, so that's basically the main bottleneck here. So that's the reason. I just wanted to explain the reasoning behind the ask, yeah.

Ben Adams:Are you making… I assume, that you're making them flexible so they can be iterated on easily?

Mario Vega:Exactly, so that's the goal. Basically, we want to make sure that you can just give the test repository a number, and then it should automatically, like, fill.

Mario Vega:the test cases with this gas repricing value, just to make easier for the gas repricing team to iterate easily over and over. Yeah, that's what we've been working on mainly. That's the reason why we asked for more, yeah, more, more…

Mario Vega:More free, than the tree, yeah.

Ansgar Dietrichs:Okay, sounds good. Any last… any further last comments on… on this section?

Ansgar Dietrichs:Okay, actually, that already then covered the next two agenda points as well. We can't… we'd already talked about the ETH70, ETH71. Maybe one last question there. There is this existing…

Ansgar Dietrichs:E70 DevNet, I think it's called NFT DevNet10. Marius, any updates from there, or, like, anything specific people should note from that DevNet?

Marius van der Wijden:Well, it… it has everything that you need to test ETH70, so when you sync it with a non-updated node, that should fail, when you snap sync. When you, snap sync with an updated node, that should fail, that should… sorry, that should work.

Marius van der Wijden:And so that's a good way of

Marius van der Wijden:making sure that everything works. We also have the Hive simulators, but I know that some people prefer to just quickly sync a network to make sure that they are

Marius van der Wijden:In compliance with the spec.

Marius van der Wijden:And, yeah, there are a few blocks that have more than 10 megabytes of transactions, of receipts.

Ansgar Dietrichs:Sounds good.

Ansgar Dietrichs:And then, yeah, next to GenderPoint, we already decided that we will have…

Ansgar Dietrichs:ETH70 and the newly separated out ETH71 as part of the…

Ansgar Dietrichs:Glamstadam CFI list, so we'll do that. Okay, with that, I think that would be all on Glamstadam. Do we have anything else Glamstadam-related to bring up today? Otherwise, we can move on to HSTAR headliners.

Ansgar Dietrichs:Okay, then, go to headliners. So, just to recap, the proposal window is now closed.

Ansgar Dietrichs:We have… let me count, 1, 2, 3, 4, 5? We have 5… no, we have 4. Sorry about that. We have 4 EL site,

Ansgar Dietrichs:proposed headliners. One of them is the frame transaction, proposal that we heard about last call. The SSE execution blocks is the second one. We have the… and then we have two separate, encrypted, mempool proposals. We already heard about the older one of the two, the earlier one, that's called Universal Entry Encrypted Mempool.

Ansgar Dietrichs:And today we will hear about the last one that was proposed, just before the deadline, which is called Lucid Encrypted Mempool.

Ansgar Dietrichs:So yeah, let's start by jumping right into that presentation, because the other three, we already heard presentations in the past, so this is the last one missing. I think we have Anders on the call to give the main presentation, but Justin wanted to say a few…

Ansgar Dietrichs:Context setting words first.

Justin Florentine (Besu):Thank you. Hello, everybody. Lucid.

Justin Florentine (Besu):So Lucid is another different approach to the problem of toxic MEV. We are working closely with the proposers of 8105, but the Lucid design takes a different approach that more directly leverages EPBS and Fossil.

Justin Florentine (Besu):So, you have probably heard people talking about a holy trinity of censorship resistance, and, you know, it goes like this. Lucid's built on these.

Justin Florentine (Besu):Epbs is providing us with the need for builders to bid on slots and delayed execution.

Justin Florentine (Besu):The FOCIL provides us with the ability to force transactions

Justin Florentine (Besu):To be included regardless of builder preferences.

Justin Florentine (Besu):And so, the third piece of the puzzle that we're adding on to that is…

Justin Florentine (Besu):Transactions that are encrypted until the point of inclusion.

Justin Florentine (Besu):This makes Ethereum function like a normal trading platform, but trustlessly.

Justin Florentine (Besu):And so, you know, Lucid is really providing a limited network consensus on transaction ordering. We are encrypting the mempool, but the root of the offering is…

Justin Florentine (Besu):An agreed, shared, but limited transaction sequencing.

Justin Florentine (Besu):This design specifically targets toxic MEV, so just the front-running and the sandwiching. So, thank you for humoring me. The table is now set, Anders.

Justin Florentine (Besu):You're up.

Anders Elowsson:Oh, yeah, I can continue here, if you hear me. Let me try to share my screen.

Anders Elowsson:Yeah, do you see the screen here?

Justin Florentine (Besu):Yeah, that's.

Anders Elowsson:Does the work.

Anders Elowsson:I can't see if anyone says anything, but hopefully it works, yeah.

Justin Florentine (Besu):Yep, we can see you great.

Anders Elowsson:Yeah, I agree, okay. Yeah, so, essentially, yeah, so the way I would frame it is that,

Anders Elowsson:Trustlessness is a core property of decentralized blockchains, and it seems important that we try to facilitate it in the blockbuilding process.

Anders Elowsson:And so Lucid uses an open design that supports many different approaches, for example, self-decryption or public key encryption in various setups, because only the outer wrapper of the encryption envelope is standardized.

Anders Elowsson:And so eventually, the decryptor will use a one-time small symmetric key that allows anyone to decrypt the transaction, as well as a top-of-block fee used for ordering these transactions.

Anders Elowsson:And to the encryption envelope, we attach a ticket that, besides regular payment fields, also includes this address of the entity that released the key, as well as a fee for that.

Anders Elowsson:We also bind with a reveal commitment the plain text transaction to the ticket, as well as bind the encrypted transaction to the ticket with a ciphertext hash.

Anders Elowsson:Now, builders are going to make bids for the right to build the next block, and in these bids, they include a commitment to this sealed transaction, that is the hash of it.

Anders Elowsson:That, besides other fields, go into the become block.

Anders Elowsson:And to facilitate censorship resistance for these transactions that may induce MEB, we should also reasonably allow these includeers to also include these seal transactions in their inclusion lists.

Anders Elowsson:And once these commitments go into the beacon block, and attesters have attests to the beacon block, it becomes possible for the decryptors to release the keys.

Anders Elowsson:At the same time, the builder can release the payload.

Anders Elowsson:And inside this payload, we add these tickets, as well as the descriptions from the previous slot that goes in top of block, based on how much they pay for it.

Anders Elowsson:And the PTC then votes on the timeliness both for the tickets, as well as the timeliness for the payload.

Anders Elowsson:Once the transactions are decrypted.

Anders Elowsson:The builder can build the bar and include this transaction's top of block in the next slot.

Anders Elowsson:And that is the core of the design.

Ansgar Dietrichs:Thank you.

Ansgar Dietrichs:Are there questions or comments regarding the presentation?

Ansgar Dietrichs:Felix?

Felix (Geth):Would you consider this to be more an execution layout proposal, or…

Felix (Geth):It seems to be more like a…

Felix (Geth):I mean, it's a bit like a cross-layer… Thing, right?

Anders Elowsson:There are cross-layer properties, yes. There are some, some for the concess layer as well, but it's mainly… it's intended as an

Anders Elowsson:EL proposal, but it's, there is cross-label properties, yeah.

Ansgar Dietrichs:End room?

Andrew Ashikhmin:So, how would you compare pros and cons of the Lucid approach with 8105?

Anders Elowsson:Yeah, I can, the difference, the core, the core main difference is that we just released, a small,

Anders Elowsson:symmetric key for decrypting the transactions, and do that off protocol, whereas 8105 does things inside the protocol for the decryption.

Anders Elowsson:Then there are differences as well. We do… we attach in the BCOM block this commitment to the… to the… the transactions to be decrypted.

Anders Elowsson:And by doing so, we allow, more time, and we ensure that if there's, like, if the payload is kind of late, or something like that, there's still…

Anders Elowsson:The possibility for the decryptors to release their keys in a way that they can be ensured that they can do so without having the payload, for example, be…

Anders Elowsson:worked out, because we have this mechanism, it's in the research post that someone may, perhaps, can link. We have this mechanism in section 4.5 that details what happens in the case that, that,

Anders Elowsson:That we need to insert these decrypted transactions in the next block instead, if there is a fork.

Anders Elowsson:But this is… this is more of a detail that I suppose you could change a… I don't know if you could change it, but maybe you could change A to 105 to do that also, and the same thing goes for the bald, and…

Anders Elowsson:that you could change 8105, perhaps, to do the execution of these decrypted transactions in the next book. I'm not sure exactly how the mechanisms would be changed, but… but it's possible that it would be possible to do that, I don't know.

Justin Florentine (Besu):Okay, there's a couple of questions in the chat here, Anders, one of which is, what encryption scheme?

Anders Elowsson:Yeah, so the decryptor can be… the decryptor can be any entity. It can be the person that also made the transaction. They can assign their own execution address as the decryptor address. And by doing so, we do it trustlessly.

Anders Elowsson:But they can also assign some other entity. They can assign a threshold committee, for example, to decrypt the transactions, which may then run a sequencer that takes all these threshold bits and

Anders Elowsson:produces the finer symmetric key that it releases. Or they may, for example, have a MEB share node as the decryptor entity. So it's an open design. You can use various entities as the decryptor, but they do not need to be registered.

Anders Elowsson:And about the incentives, there was a question, yeah, so we have this ability to pay a fee, and so the decryptor would simply specify, oh, if you want to use my services, you have to pay this specific fee, and of course, the

Anders Elowsson:The entities… the sender will then specify that field.

Ansgar Dietrichs:And, Matt had some comments? Maybe, Matt, do you want to just speak up briefly about the encryption side?

lightclient:Yeah, I mean, I'm just not as sure about this idea of having,

lightclient:arbitrary address that is defined to do the encryption or to do the decryption?

lightclient:Like, what is the efficiency of these things? You know, even with elliptic curve, how good is our… like, how much gas is it gonna cost to decrypt the transaction? And then, what does that look like in post-quantum schemes?

Justin Florentine (Besu):Andrews, if you're speaking, you're on mute.

Anders Elowsson:Yeah, so you can see the comment by Gottfried there as a response to Matt, but maybe it's better that Gottfried talks about this, because he is the expert on this matter.

Gottfried Herold:I mean, not really a big expert, it's just that the… I mean, as far as I understand the design, I mean, the in-protocol part of this

Gottfried Herold:is a, it's a symmetric cipher, so, I mean, symmetric ciphers are not really vulnerable to quantum computers to start with. Of course, the other part, sort of how the,

Gottfried Herold:The other part, but that is sort of modular in the design, is, of course, needs to be a post-quantum secure public key scheme, but that is actually out of protocol.

Gottfried Herold:So…

lightclient:So, how much gas does it cost to do the decryption?

lightclient:Of a standard transaction.

lightclient:Using standard symmetric cryptography.

Ansgar Dietrichs:Or maybe to translate this to… It's very cheap, I would say.

Anders Elowsson:Yeah, like, how effective…

Ansgar Dietrichs:So go ahead, Enes.

Ansgar Dietrichs:But yeah, I assume, basically, yeah, is this, like, Gottfried, is this basically what Matt is saying? Kind of, like, somewhat similar to thinking about having an AES precompile, like, something that's basically, like, a…

Ansgar Dietrichs:Symmetric.

Gottfried Herold:Yeah, something like that, I presume. You wouldn't… I mean, if you… I mean, technically, I'm not sure whether it sort of would need to be a precompile inside the EVM, but yes, I mean, probably AAS, or… I mean, you could also use ChaCha 2020, or whatever you… whatever you use. Probably AES is a good choice, but yeah, you would… you would… you might want to have an AS pre-compile.

Gottfried Herold:Presumably.

Ansgar Dietrichs:Yeah, yeah, no, it's obvious that that proposal itself would not include the pre-compile, but, like, it's kind of equivalent, in a sense, right? Like, it's something that,

Ansgar Dietrichs:Would basically be part of the protocol, even if not exposed to them.

Ansgar Dietrichs:Okay.

Ansgar Dietrichs:Makes sense. Mark, is your comment on this point, or is that, on a different point?

Marc:It's more of a different question.

Marc:But it's about… yeah, I'm not sure about the handling of, if someone withholds the keys.

Marc:Because, I mean, there's an attack you could do where, say, like, you send loads of, different transactions, and then you get to decide whether you want to release the keys or not, which might give you some kind of option to frontrun. So, I mean, you'd potentially waste the gas, but…

Marc:Yeah, have you guys kind of looked into whether that could be profitable, if there's any way to stop that?

Anders Elowsson:Yeah, so this is discussed… all these problems are discussed in Section 5 of the research post, and it's true that we may foresee that some will use that. In this case, we could attach a small fee.

Anders Elowsson:for a failure to release. And there's various ways to do that. But,

Anders Elowsson:Yeah, so essentially, if someone hasn't linked the research post, let me try to…

Anders Elowsson:Find it to link it, but… but yeah, it's discussed here, but yeah.

Justin Florentine (Besu):It's been linked in the chat, Andrews.

Ansgar Dietrichs:Okay, any further questions or comments, on this?

Ansgar Dietrichs:Proposal specifically? The presentation, or otherwise?

Ansgar Dietrichs:Yeah, then I think there's going to be a bit more back and forth in the chat, but otherwise, yeah, thank you, Justin and Anders.

Justin Florentine (Besu):One thing I'd like to add real quick is that we will be setting up a working group for this. It'll start meeting next Wednesday at 1300… I'm sorry, 1500 UTC. Feel free to reach out to me or anybody else if you're interested. Thanks. Also, there is a…

Justin Florentine (Besu):channel in Discord, Encrypted Mempools, so feel free to also discuss there.

Ansgar Dietrichs:Perfect. Thank you. Yeah, so then with that, the only two

Ansgar Dietrichs:remaining sections in this… on the Hakota headliners. One would be… so just to kind of recap the timeline, now that the proposals are closed, the idea is that we are going to discuss headliners, and then, ideally make a decision on,

Ansgar Dietrichs:on the EL side situation on Headliners over the next one or two calls.

Ansgar Dietrichs:And, yeah, so in terms of process for that, one, I just want to mention,

Ansgar Dietrichs:if anyone here is interested in, well, specifically Fossil, as a CL headliner that has some EL implications, that decision will likely be made on ACDC next week, so do join that call if you're interested in that decision.

Ansgar Dietrichs:And then in terms of the EL set headliners, to repeat one more time, we have frame transactions, we have SSC execution blocks, and then we have the two

Ansgar Dietrichs:Different, encrypted mempool proposals.

Ansgar Dietrichs:And then, of course, just to mention it, of course, we also have the choice to potentially just say, on the EL side, we will not have a separate headliner, right? Like, this is… it's not, like, the headliner process in that sense is flexible. I think we have this convention that we would not have more than one headliner per layer, but if we are deciding to, say, instead focus on just Fossil, that would also be an option. So basically, in that way, we have five different options here that we can choose from.

Ansgar Dietrichs:the four proposals, or no headliner. And my proposal here was to have clients

Ansgar Dietrichs:Have a brief… write up a brief position on…

Ansgar Dietrichs:what their preferences here would be, and maybe just order the 5 in, basically, ideally including explicitly the no headline option, just for completeness. Just put them into a loose order, maybe add some comments of why, and have that done in the next two weeks, so we can have a more informed

Ansgar Dietrichs:Discussion and, and maybe already decision in two weeks.

Ansgar Dietrichs:Is that something clients would be okay with doing?

Ansgar Dietrichs:I see a thumbs up.

Ansgar Dietrichs:Then if no one protests, then yeah, that would be…

Ansgar Dietrichs:the ask then to… to just kind of… again, it doesn't have to be something big, just, just so we have from all the clients, like, an overview of where they're at. So then next week, hopefully, next, next call in two weeks, we can hopefully really go into it. For today, we already know in the discussion and, you know, decision, like.

Ansgar Dietrichs:forming part of the headliner process, so if there is already discussion that people would want to have today, or just comments, or just…

Ansgar Dietrichs:thoughts people had in the build-up to this, anything we already would want to bring up today, that's totally fine. I think the main part of the discussion then would be in two weeks, once we have the client positions and clients have had time to think about this a bit more. But yeah, I would just now open it up as the last section of the call

Ansgar Dietrichs:for open discussion, and I do think, actually, there was an agenda comment from Matt regarding frame transactions. Matt, are you on the call? Would you want to briefly say something?

lightclient:I can give a quick update,

lightclient:We made a small change to how Approve works last week, based on some

lightclient:discussion that happened on the Youth Magician's thread. Originally, Approve was going to kind of extend the space of, status codes between call frames, so today of success or not success, 0 or 1.

lightclient:We were thinking of extending that.

lightclient:To include the approve related statuses, and found

lightclient:Through the discussion that, actually, we want existing accounts who have deployed, as smart accounts.

lightclient:via proxies, or, you know, maybe other means to be able to use Approve, and if we have the status code propagate upward, like, in this manner, it's not… it's not possible to reuse the proxy contract.

lightclient:So we've changed the behavior a bit, so now approve, as long as it's called successfully during the execution of a verify frame, in the context of the sender or the payer, that gets tracked in, like, a transaction context variable. The, you know, generally this is all the same, validity requirements of when you can call approve and how it works is the same, just changing it a bit how the

lightclient:propagation happens.

lightclient:So that was the main spec change that happened.

lightclient:I was also going to share this pull request I've been working on, started implementing the frame transaction in the execution specs.

lightclient:And have started working on the tests in execution spec tests.

lightclient:So, still work to be done, obviously, on cutting all the corner cases, and…

lightclient:fitting it into the execution specs architecture a bit better. Right now, it's…

lightclient:It is a little hard in some places to weave it very nicely in, because this transaction type… the, you know, gas limit is not the same as the gas limits are in other transactions. Like, you have to sum

lightclient:the gases of the frames. So there's a few things to iron out. But overall, like, I think it's starting to come together, if you want to take a look at it, to get an idea of, like, what is the complexity of this, if any execution clients are interested in trying to start implementing frame transactions.

lightclient:We are starting to have some test fixtures available for you. So yeah, that's pretty much everything on frame transactions. Happy to answer any questions as well.

Ansgar Dietrichs:Felix?

Felix (Geth):Yeah, I also want to give the quick update that, it is planned to further refine the TX Param opcode family to…

Felix (Geth):Basically, to clean it up, so because we… we…

Felix (Geth):we just… basically, the variant of the TX Param that is in the EIP right now, it works, but it's a bit over-designed for the purpose of it, because this… the opcodes used to have more options available, which made it necessary to have both the…

Felix (Geth):txparam Load and TXparam Copy, but now…

Felix (Geth):pretty much all the data except for the frame call data is below 32 bytes, so we don't really need the TXparam copy anymore. And I think this will be solved eventually by just changing the opcode so that we have a dedicated way of loading frame call data, like frame…

Felix (Geth):Call Data Copy, or something.

Felix (Geth):And then for the remaining ones, we will basically just have TXperm load.

Felix (Geth):Mostly what I want to say is there will be some changes to the opcodes, but the opcodes themselves are not the main thing in this EIP, and they are just a necessity in order for the actors on-chain to properly validate the transaction.

Felix (Geth):And so, I think it's still fine if we take a bit more time to refine what exactly these opcodes look like. The current ones who do work, they are just not the best design.

Ansgar Dietrichs:Sounds good. Any comments on that particular, or just otherwise, contributions to the…

Ansgar Dietrichs:Open discussion section? Anything anyone would want to talk about today?

Felix (Geth):It's a good question with the mediates. We don't see it for… as with the mediates. This is not, this is not a goal. I can answer that right away. So, the…

Felix (Geth):The access to the transaction context.

Felix (Geth):We don't see it as something that has to be absolutely maximally efficient, so it is fine to use the push and take via the stack.

Felix (Geth):The location that is to be accessed.

Ansgar Dietrichs:Sounds good. So, sounds like there's no other comments for today, which kind of makes sense. Again, the main discussion I think we'll have, in two weeks, and then see whether that is quick and we can already make a decision, or otherwise, I think there's definitely also room to…

Ansgar Dietrichs:Have an extra call, like, physically, then they make decisions in 4 weeks.

Ansgar Dietrichs:But either way, yeah, looking forward to that, and then that's all for today. Thank you all, and talk to you all in two weeks.

Marius van der Wijden:Bye.

Fredrik:Bye.

Chat Logs

Justin Florentine (Besu):if we keep putting memeable forknames, yes

Ansgar Dietrichs:https://github.com/ethereum/pm/issues/1921

Stefan Starflinger:https://dora.bal-devnet-2.ethpandaops.io/

Stefan Starflinger:https://github.com/ethpandaops/bal-devnets/pull/29 examples for the flags besu and geth have

Ansgar Dietrichs:the two EIP-8024 changes discussed: https://github.com/ethereum/EIPs/pull/11094#issuecomment-3769076517 https://github.com/ethereum/EIPs/pull/11306

Stefan Starflinger:https://hive.ethpandaops.io/#/group/generic?suites=rpc-compat e.g eth_simulateV1 fail example: https://hive.ethpandaops.io/#/test/generic/1768973576-78237392b0c263f38d2ab3465fd9ac5c?testnumber=133

Stefan Starflinger:——— devnet-3 BAL OPTIMIZATIONS (parallel exec, parallel state loading, parallel state root calc) 8037 State Creation Gas Cost Increase 7954 Increase Maximum Contract Size

Toni Wahrstätter:Replying to "——— devnet-3 BAL OP..." What about eth/70? We wanted to increase the higher gas limit and without the data repricing we may run into limits.

Ansgar Dietrichs:- non EIP priorities - BAL optimizations - parallel execution - parallel state root calculation - batched state reads - `eth_simulateV1` RPC support - EIP priorities - devnet-3 - EIP-8037: State Creation Gas Cost Increase - EIP-7954: Increase Maximum Contract Size - devnet-4+ - data repricings - EIP-7976: Increase Calldata Floor Cost - EIP-7981: Increase Access List Cost - other repricings - EIP-2780: Reduce intrinsic transaction gas - EIP-7904: General Repricing - EIP-8038: State-access gas cost increase - EIP-7975: eth/70 - partial block receipt lists - EIP-8070: Sparse Blobpool - EIP-7997: Deterministic Factory Predeploy

Stefan Starflinger:Replying to "——— devnet-3 BAL OP..." Thats on a separate devnet, right?

Toni Wahrstätter:Replying to "——— devnet-3 BAL OP..." So eth/70, 7976 and 7981

Karim T. (matkt):Eth/71 for devnet 3 ? https://github.com/ethereum/EIPs/pull/11307

nixo:Replying to "- non EIP priorities..." non EIP priorities: BAL optimizations - parallel exec - parallel state root calculation - batched state reads EIP priorities devnet-3 - 8037 State Creation Gas Cost Increase - 7954 Increase Maximum Contract Size ——— devnet-4 & beyond data repricings - 7976 Increase Calldata Floor Cost - 7981 Increase Access List Cost - 2780 Reduce intrinsic transaction gas - 7904 General Repricing - 8038 State-access gas cost increase - 7975: eth/70 - partial block receipt lists - 8070 Sparse Blobpool - 7997 Deterministic Factory Predeploy

Stefan Starflinger:Replying to "Eth/71 for devnet 3 ..." Thats a good point, I think it would be great if we can include this

nixo:Replying to "- non EIP priorities..." 7778 missing

FLCL:Average receipts rlp is like 200KB on mainnet

Justin Florentine (Besu):Replying to "Average receipts rlp..." do you have examples of worst cases or 95/99 percentiles?

Karim T. (matkt):Replying to "Eth/71 for devnet 3 ..." BAL item cap https://github.com/ethereum/EIPs/pull/11234 not sure when we want to have it as it will depend if we want to add read into BAL @Toni Wahrstätter

Ahmad Bitar | Nethermind:Replying to "Eth/71 for devnet 3 ..." Are clients expected to store the access list to serve it? Unless you're an archive node, you will not be able to serve this for historical blocks

marek:agree with @Felix (Geth)

FLCL:let me collect, will post later in el networking

Ahmad Bitar | Nethermind:Replying to "Eth/71 for devnet 3 ..." I wouldnt include BAL in p2p tbh. By default clients will not be able to serve it

Karim T. (matkt):Replying to "Eth/71 for devnet 3 ..." We should keep them during a Weak Subjectivity Period

Karim T. (matkt):And after we can prune them, so clients will be able to serve recent BALs

Ahmad Bitar | Nethermind:Replying to "Eth/71 for devnet 3 ..." But thats a short time, syncing clients will not really need them to catch up to the tip

Fabio Di Fabio:Make sense to add eth/70 to Glamsterdam

Karim T. (matkt):Replying to "Eth/71 for devnet 3 ..." 113056 it is enough for healing optimization during snap sync, or enabled // during backward sync if you node turned off during some days

Andrew Ashikhmin:What’s the eth/71 EIP?

Ansgar Dietrichs:we are overloading the term “protocol” here :-)

Toni Wahrstätter:Replying to "What’s the eth/71 EI..." https://github.com/ethereum/EIPs/pull/11307

Justin Florentine (Besu):perfect

Ansgar Dietrichs:every blockchain needs a deadline guy

Justin Florentine (Besu):Barnabus "deadline" Busa

Marius van der Wijden:We have an eth/70 devnet: https://dora.nft-devnet-10.ethpandaops.io/ which can be used for testing

Marius van der Wijden:Replying to "We have an eth/70 ..." Geth and Nethermind are working

FLCL:Replying to "We have an eth/70 de..." Works in nethermind, we are adding more tests and constraints

Stefan Starflinger:what about besu? eth/70

Fabio Di Fabio:Replying to "what about besu? eth..." implemented, and testing right now

Stefan Starflinger:makes sense

Dragan Rakita:Replying to "We have an eth/70 de..." Reth branch matt/make-eth70-default and image should be at ghcr.io/paradigmxyz/reth:8399bafdbe36d9660a1752800534cf8a7cb4e6c6

Ansgar Dietrichs:I was curious whether Justin would remain video on during Anders’ presentation :-)

Marc:is there anything to prevent key providers withholding keys?

Justin Florentine (Besu):much like FOCIL

soispoke:Replying to "much like FOCIL" FOCIL is a lot more on CL (but yes also cross layer)

Justin Florentine (Besu):yes, if you withold your key you still pay full gas, and your transaction is skipped

Justin Florentine (Besu):https://ethresear.ch/t/lucid-encrypted-mempool-with-distributed-payload-propagation/24042

lightclient:what encryption scheme?

Tomás Arjovsky | Lambda | Ethrex:Who are the decrypters? What are their incentives? Is there any in-protocol mechanism to prevent them from decrypting the transactions earlier for the builders?

lightclient:we don’t have any efficient PQ encryption schemes in the protocol though

Gottfried Herold:Replying to "we don’t have any ef..." Note that the in-protocol part here is just using the released decryption key, which is a symmetric key, so PQ is not a big issue here.

Danno Ferrin - Tectonic.xyz:Replying to "we don’t have any ef..." AES? That’s quantum-safe

lightclient:so we’d need AES precompile essentially?

Francesco:Isn’t the decryption offchain?

lightclient:but the code to decrypt is on chain?

Gottfried Herold:Replying to "Isn’t the decryption..." This uses a KEM - DEM framework, so the envelope includes an (pk encrypted) symmetric key. The decryption of that is off-chain. Using the then-revealed symmetric key is onchain, IIUC.

lightclient:have encrypted mempools like this been deployed successfully out of protocol?

Potuz:Replying to "but the code to decr..." No, decryption is Offchain, you need to just check that the commitment from the open plaintext agrees to with the committed ticket.

Justin Florentine (Besu):Replying to "have encrypted mempo..." does Shutter network count?

Danno Ferrin - Tectonic.xyz:Replying to "Isn’t the decryption..." Keep Kems offchain, they generally are as impacted as assymetric algos (EC, RSA) and have the same key size / sig size issues when going to PQ for KEM. so off-chain KEM is best.

Justin Florentine (Besu):Replying to "have encrypted mempo..." otherwise, "like this" i would say is no, because lucid depends on focil/ePBS

Anders Elowsson:Replying to "Isn’t the decryption..." Benedikt Wagner has outlined one specification for this off-chain part included in Appendix C: https://ethresear.ch/t/lucid-encrypted-mempool-with-distributed-payload-propagation/24042#p-58297-appendix-c-kemdem-hybrid-encryption-51

lightclient:https://github.com/lightclient/execution-specs/pull/1

frangio:would you use immediates for TXPARAM or is stack ok?

James He:feedback for whoever is coordinating the YouTube stream for the call, the steam makes it only look like there’s 9 people on the call , not sure what changed but it’s like a zoomed in view.

Summary

15 highlights · 3 decisions · 1 action itemsExperimental

fork status and schedule

Hegotá headliner proposal window closed; decision expected in 2 weeks00:36:19
ETH/70 and ETH/71 added to Glamsterdam CFI scope00:23:31

devnet updates

bal-devnet-2 live; most consensus issues resolved, Hive tests pending00:02:56
BAL optimization flags ready: prefetch and parallel execution toggles00:04:10
Aragon delayed ~1 week; parallelized EVM work needs completion00:05:25
BAL JSON-RPC changes and max item limit DOS protection added00:06:23
nft-devnet-10 (ETH/70) available for testing with Geth/Nethermind/Besu/Reth00:27:33

eip changes

EIP-8024: Rejected push-postfix encoding; branchless normalization under review00:08:08
DevNet-3 scope: EIP-8037 (state creation cost) + EIP-7954 (contract size)00:31:52
BAL optimizations top priority; data repricing deferred to DevNet-4+00:31:52

headliner proposals

4 EL headliner candidates: frame txs, SSE blocks, 2 encrypted mempools00:36:27
Lucid encrypted mempool: leverages ePBS+FOCIL, symmetric key release off-protocol00:37:25
Frame transactions: Approve propagation redesigned for proxy compatibility00:55:57

testing progress

Gas repricing testing framework refactored for flexible iteration00:40:50

organizational

eth_simulateV1 RPC compatibility requested for DevNet-300:11:54

Decisions

EIP-8024 push-postfix encoding change rejected00:09:12
EIP-7975, EIP-8159 moved to CFI for Glamsterdam00:23:46
EIP-7975 included in bal-devnet-3; clients without support can still participate00:31:10

Action Items

All EL client teams: Client teams: Publish ordered headliner preferences (including no-headliner option)00:54:14

Targets

~February 26th - bal-devnet-3 launch (2 weeks from call)00:27:02
February 26th - Client headliner preferences due00:52:22
February 19th - ACDC call for FOCIL headliner decision00:52:20