All Core Devs - Execution #238

Transcript

Ansgar Dietrichs: Okay, then let's go live.

Josh Davis: Alright, you're alive.

Ansgar Dietrichs: Perfect! Hello, everyone. Welcome back to All Core Devs Execution number 238. Today, I'll be The call coordinator again, Nixon and I are by now co-leads, and so we will, take turns, although not on a particularly regular pattern, just, whatever makes sense at any given call. Today, I put the agenda in chat. We have two main topics. One will be Glamsterdam Devnets, and the other one will be Hegota EAP proposals. On Glamsterdam, I think the main DevNet to talk about will be Glamsterdam DevNet 5, but before we get there, maybe let's just… I just want to briefly ask, is there anything… Still from the bal-devnet 7 that we should discuss? Is there anything to bring up from there?

VIN?

Ben Adams: Not, not for bal-devnet at 7, but it'd be nice in the next, If we do another bal-devnet, do you have the… Target gas in it also, so there isn't a difference. between the Amsterdam and the Yeah, outside.

Ansgar Dietrichs: Makes sense. Yeah, I was going to… I think, to me, that was, a topic forward-looking for Glamsterdam devnet 6. I think my understanding is to… that we're maybe trying to integrate the DevNets anyway, and that BAL DevNet 7 would maybe be the last BAL-specific DevNet, but Yeah, point taken for now, let's get back to this once we discuss that question at the end. Mmm… Okay, then let's, for now, go to Glamsterdam devnet 5, Do we have a status on… On that definite.

Barnabas Busa: Yeah, so, Glamsterdam development 4, basically died last week, so we ended up finishing up the CL spec, and, hopefully now we will have a Glamsterdam, comes from Devon 5. We just had Genesis about an hour ago. And, we will be hitting, the fork in 2 hours. We have the Dura page online. Here, and, yeah, just keep an eye on it. We have 2 ELs and, 4 CLs right now. And we're planning to onboard, Teku as well, right after the fork. Or maybe tomorrow.

Ansgar Dietrichs: Sounds good. Thank you. Is there anything, any action items, or anything else for clients following along with the DevNet?

Barnabas Busa: It would be also good if we had other ER clients take a look at the engine API changes, and then we can also onboard them as well.

Ansgar Dietrichs: Sounds good. Anything else regarding this just-launched DevNet 5, Samsung DevNet 5? Otherwise, I think we can briefly touch on… I think Barnabis also mentioned it in chapters now already, basically the definite plans going forward. My understanding is that maybe with Glamsterdam Definite 6, we would… try to have that be a unified DevNet already? Is this… I'm not sure how much there's to discuss now on the call, maybe just so people are aware of… first of all, is this indeed… am I correct that this is the intention? Would be to have DevNet… Gamsa and DevNet6 be the point at which we integrate the DevNets? Or is that still in flux?

Barnabas Busa: Well, the point is that, Glamsterdam devnet 5 is based on top of, Paul.net 7. And, any new ELE IPs, that we would be wanting to push for. I would just want to push that into the Glamsterdam track, otherwise we're gonna have two very conflicting branches. And, it might be causing some headache, for the ER teams.

Ansgar Dietrichs: Okay, that makes sense, sounds good. So basically, the idea would be that now, as of Glamsterdam devnet 5, that becomes the unified Basically branch, and so we will not… Have a bowel definite.

Barnabas Busa: At least that would be my suggestion. I know that some client teams would like to have, Paul Dagnate with some new EIPs.

Ansgar Dietrichs: Makes sense. And is that something to just flag now, or do we need to have that discussion now, or is that best suited for offline or on ACDT next week?

Barnabas Busa: I think it would be good to agree on this now.

Ansgar Dietrichs: Okay, then, yeah, let's see. Is there anyone who is opposed to that approach, who'd like to keep the bal-devnet separate for now? Right, so we would, keep BAL DevNet 7 around, we would just not… Created by 118, basically, would be the idea. Well, so far I've seen 100% Parry in favor, is there any… any client teams with any opinion in either direction, or just… otherwise, we just can just follow the… The recommendation here? Okay, then I would say, we just make that decision, and there will not be a separate BAL DevNet 8, at least, that's the intention as of now. Of course, things can change, but…

The intention would be that BAL DevNet 7 is the last BAL-specific DevNet, and everything further on the EL side will be on top of the main Glamsterdam DevNets. Okay. Awesome. Dan, anything else? Any other topic? Anything else? DevNet-related that we should discuss now, before we move over to the… Higota section?

Barnabas Busa: Well, there's definitely some open EIP questions for definite 6 scope, such as what Tony just mentioned, the deterministic factory, deterministic, deployer. There's an EIP for that, And whether we want to include it in the next one or not.

Ben Adams: Wouldn't we include that with all the other… Yo. Changes?

Barnabas Busa: Yeah, I mean, we should probably go through that list now, and See which one we want in, and which one we don't.

Ansgar Dietrichs: Yeah, sounds good. Do we have, like, a candidate list we could take a look at? And what's the timing for BAL… for, sorry, Glamsterdam devnet 6? Like, at what… when do we… would we expect to launch that? Assuming BAL Demonet 5, of course? Peace. Decently stable.

Barnabas Busa: it's all up to the client, on the decisions which one… which EIPs we're gonna include, and When it will be ready.

Ansgar Dietrichs: Okay, makes sense, yeah. Then.

Barnabas Busa: Preferably in 2 weeks, not more than that.

Ansgar Dietrichs: Makes sense. Yeah, I'm a little, because of the, you know, the integration of the DevNets and overall, I'm a little out of the loop on which specific EIPs need decisions for DevNet6?

Barnabas Busa: There's a… I just linked it, the issue, the execution specs issue, 2019-15. And then, there's the list, that Spencer put together.

Ben Adams: So, so I think there's two issues. One… I don't… we should really discuss at this stage, I think they're all quite small, what we want to hold back, rather than What we want to include. And… but the other caveat is we need benchmarking numbers, for some of the EIPs to know what their Finalized numbers are. Or at least. semi-finalized numbers for the W. So it's not… it's not just implementation time, but for instance, like, you know, 8038? And… 2780. They… they need finalized numbers from the benchmarking.

Barnabas Busa: Do we need the finalized numbers, or could we just have a good enough estimate to…

Ben Adams: Yeah, we can…

Barnabas Busa: And then have the finalized numbers for, like, the bit 7.

Ben Adams: We just need some, we don't need finalized, finalized, we just need some numbers.

Ansgar Dietrichs: Tony, do you have your hand up for that topic?

Toni Wahrstätter: Yeah, so, assuming we have the finalized numbers for the repricing EIPs. My feeling is there's only the deterministic factory left, right? There is only 7997. Am I forgetting any EAP now that we have also CFI'd?

Ben Adams: Well, I mean… All the, all the ones, so… The ones changing all the numbers are also not in, so… It's not there, just the factory. I assume we include everything that we've…

Toni Wahrstätter: No, I mean, ignoring the repricing EEIPs now, because for them, I just assume we get to the final numbers, and then we SFI them. More like which other actual features that is not just repricing is still open.

Barnabas Busa: Is that a distracted one?

Toni Wahrstätter: Right, it feels it's those two. The self-destruct and the pre… The deterministic factor.

Andrew Ashikhmin: There is also a 2780 reduced intrinsic transaction gas.

Toni Wahrstätter: Right, but I count that as repricing. Basically, 8038 and $27.80, Those are waiting for the final numbers, and as soon as we get the final numbers, we can basically SFI them. If everything looks good, of course. And for the others, it's still, like, I would call them. I mean, the self-destruct is more a security thing, but the factory is a feature. Both are very small, so I would just lean towards including them in DefNet 6.

Ben Adams: And also all the EIP updates.

Ansgar Dietrichs: Yeah, it looks to me like in terms of new EIPs, we have two repricing EIPs, two feature EIPs, the self-destruct and the… deterministic factory pre-deploy one, and two out-of-protocol EIPs, right? The sparse block pool… oh, I forgot, maybe I'm wrong, I'm not 100% sure about this. My thinking was it was, Networking only, and, and the… revert creation for non-empty storage, which, if I remember correctly, is also just a pure I don't know, they… Formal decision only. thing. Is that, is that right? Is it basically, like, two repricing, two features, and two out-of-protocol ones? is basically… okay, that starts over. So, on the repricing, we already flagged, the main decisions are… well, the main questions are around the readiness of the benchmarking. On the two features, which basically, is anyone opposed against including both of them? So, like, that's the…

Self-Destruct 1 and the deterministic factory pre-deploy. Is anyone opposed to having both of those in DevNet6? Okay, then it seems like they can go ahead in Definite 6. And then, regarding these… the other two, like the AT70, the sparse blood pool, and… 7610, the revert, creation for non-empty storage. Is there any, any considerations? about… they're listed for inclusion in the DevNet, Yeah, any considerations around those two, come here?

Kamil Salakhiev: Yes, around the sparse blow post, so, it's an EL change. They basically… We have Geth, which is close to be ready to ship this feature. Also, NetherMind and E3X are actually working on that, but the problem is that we do not have CL support to kind of enable, sparse blog posts and in DevNets, so as… when it's ready on CL side as well, I think, yeah, we can get prepared and schedule that for the upcoming DevNets.

Barnabas Busa: I would actually push this feature into, possibly Hegota, as we still like the, optional blobs on the CR side. And that is a huge lift. There's a lot less re-implementation that needs to be done, and only Lighthouse and Prysm has done that. But it's all optional, so we can treat it as an optional EIP. So once the EL and CL both supports it, then… then we're just gonna enable it. We don't need to have a fork for this.

Ansgar Dietrichs: Sounds good. So there isn't really any DevNet decision to be made here for this? Hippie.

Kamil Salakhiev: On my view, it would be great to, once we have CL support, to maybe schedule that first for the Blob DevNets. Yeah, once it's stable there, we can consider also for cluster job, I don't know, it's not like a consensus change, yeah, it's just if… Notes… oh, the clients, they signal that it's ready, we can… Start considering scheduling that. Yeah, it's a question, like, whether for Amsterdam, they've met or for Hegota. Ideally for Amsterdam, but yeah, depends on the readiness.

Ansgar Dietrichs: Okay, makes sense. So then, yeah. So, in terms of actual inclusion decision for DevNet 6, it's kind of then out of scope. Because, because it's optional anyway, so then… we have the two, kind of, feature EPs, where it seems like everyone agreed we would want to include them. So, where does that leave us with the two repricing EIPs? Did we say we will definitely have, kind of, preliminary numbers and would want to include them on that basis, or do we… or is this still an open decision question? Okay, Tony's saying, let's just basically not make the decision on the repricing ones today, but basically just say they are meant to go in as soon as the numbers are there, so if the numbers come in time to make it into DevNet6, they go into DevNet 6. If not, then basically they wait.

Cannabis?

Barnabas Busa: Are these literally a one-line change for most ES to change these values? Because if they are, like, one-line change, maybe we already have a good enough estimate of what values would make sense, use those, so that we change the repricing values to that, and then do benchmarking on them as well. So that we can actually include the EIPs in the new DevNet, and do the actual, change and repricing. Yeah, I'm not sure if it's gonna be the correct final, final value, but at least the IPs will be implemented, and the change will take place. And yeah, Pari mentioned that it would be nice to see what tooling breaks. As we saw with AD37, there was a ton.

So I would actually try to push for all the EIP changes in .6, if possible.

Ansgar Dietrichs: Okay, I mean, it seems reasonable to me to basically say, like, they don't even have to be, like, high-quality, kind of. penciled-in values, like, as long as they basically just give us the testing surface to test having those changes, and then the real numbers can come later, and… As long as they're roughly, like, pointing in the right direction, the numbers. Yeah, I mean, I can't… I'm not in the loop enough to say whether that's possible. It seems like that should be possible, but Maybe we can… for now, just have that as the intention for Debnet 6, and then… check in with the benchmarking effort, and maybe on next week's ACDT, if that makes sense? Just confirm that.

Okay, I see some thumbs up, so… But yeah, so then let's say the intention is to have some preliminary version of 8038 and 2780 as well, in Glamsterdam, DevNet 6. Okay, and then, is there any decisions we need to make on the ERP updates? I see there's 3 EIPs with updates listed as well. Anywhere there's a decision to be made, or would we just include all the updates in the DevNet?

Barnabas Busa: Sorry, what did we decide on the self-destruct one? 8246.

Ansgar Dietrichs: I had asked, yeah, I had asked whether 8246 and, 7997, whether on those two anyone was opposed to including them, and there was no one, so, so I, by default, would just include them, but… if there was… if I maybe just didn't mention it clearly enough. So, is there… is there anyone who was opposed to including 8246, the self-destruct, Burn removal, or… 7997? the deterministic factor pre-deploy? Is there anyone opposed to including both of those in clump system defined 6? Okay, then it does seem like we just go ahead and include them?

So that means we include 4 new EIPs. The two repricing EIPs, 8038 and 2780, and then the two feature EIPs. 8246 and 7997, and then my understanding was that the other two listed there do not require a definite decision. Okay. So then, if that's my understanding, then the question, again, like, there is also the… for the EIPs that we already had in the prior DevNets, three EIPs have changes. My default assumption would be that all changes will just be in DevNet 6, but if there's any… any change that maybe has some reason for why that might not be the right decision? I don't have the context on this, so just… just asking.

Okay, then I assume then we'll also have all the changes listed there, the ERP changes as well, included in the DevNet. And yeah, Barnabas, the one last one that I was unsure about from the ones that you listed is 7610, because again, my understanding is that doesn't actually change any behavior on mainnet, it's more a formal change, if I remember the discussion correctly that we had in the past. So I'm not quite sure if that needs a formal inclusion decision.

Jochem Brouwer: Yeah, I can maybe chime in on this one. I don't see Gary on the call from GEF, but he could shine some more light on this. I would not want to move this EIP to any other position yet, but you are right, this is not a… it's currently a no-op, it's more a decision, like, should we include this in the spec? But I don't want to have that discussion now, because I want Gary on the call for that.

Ansgar Dietrichs: Sounds good. So then, I don't see a need to include this in… specifically in Glam Center.net 6. I think we can just… Postpone that. Okay, sounds good, and it does seem that otherwise, Barnabas, your comment looks correct to me. Yes, then I think that's all regarding planning for Glamstadump.net 6. Any last… DevNet-related topic anyone wanted to bring up before we move to Hegota? Okay, then let's go to Hegota. We have, 7 different EIPs across 4 different people that wanted to bring them up. So let's just go through them, one by one. Tony, you were first, you had two EIPs you wanted to bring up?

Toni Wahrstätter: Yes, let me quickly try to fair my screen. Let's see if that works. Okay, I guess it doesn't work, right? You just see a black screen?

Ansgar Dietrichs: Oh, does it work? No, only black.

Toni Wahrstätter: Interesting. Can you see my screen?

Felix Lange: Yeah, Miles is there.

Toni Wahrstätter: Oh, interesting. Okay.

Ansgar Dietrichs: Can, yeah, do we have anyone else? Just, spontaneously share their screen?

Josh Davis: If you give me a link.

Toni Wahrstätter: my link? Yes, I posted the link in the chat.

Jochem Brouwer: Shall I share my screen?

Toni Wahrstätter: I think Josh is going.

Ansgar Dietrichs: do very much.

Toni Wahrstätter: Awesome, thank you very much, Tosh. I will just tell you, when to switch to the next slide. So yeah, those are two repricing EEIPs for Hegota. Both are targeting to make the worst-case block size smaller. And just to give you a sense of where we are with Glamsterdam, so with 200 million gas, we will get to, like, 4.5 megabyte big blocks. This sounds quite a lot, but, for example, we were quite close to that already pre-Pectra, for example. And the nice thing is, with Glamstadom, we get much more time for propagation, thanks to EPBS. So, And increasing block size is not that scary anymore, as it was before, but still, we need to somehow keep the worst-case block size in check, such that we don't end up in a situation where big blocks basically don't propagate anymore over the network. And those two EEIPs, basically.

8131 and 8279. They, get us to a point where we decrease the worst-case block size by 32%. And the nice thing is we get to a worst-case block size formula that is basically block gas limit divided by 64. And 64 is the gas per byte cost that we introduce with Glamsterdam. Great, let's go to the next slide. So, what is the problem today? Today, we have, the floor call data pricing, or the floor data pricing, and this means with Glamsterdam, you can use 75% of the gas available for execution, and for example. do a lot of S loads, and you use 25% of the call data for, data. To increase the block size through call data.

And those 24, those 25% is already giving you the worst-case block size, because you're not hitting the floor in this scenario. You're still paying the 16 gas per pipe instead of the 64, and this allows you to basically shuffle Execution on the other hand, and this execution can then, in the end, contribute to the block becoming even bigger. And the block club accesses is just one of those things that… You execute something, and suddenly the block becomes bigger. But there are other, other, components in the block we have that have a similar, like. Phenomenon. For example, 7702 offs, and also blob hashes. Both contribute to the block size, and both are not priced, For that data at all.

In Glamsterdam, we already price access lists, so this is already quite nice, because now the block size decreases already, and the first EAP I had there, 8131, would basically also do the same for 7702 offs, and also for blob hashes. And the second ERP would then apply the same to the block level access list, which is a little bit more involved. But I will get to that in two slides. Let's move on. Perfect. So this is very simple. What we do with 8131 is essentially the last two lines here. We also account for the authorizations, and we also account for the blob version hashes. And this is all the data that the user has access to.

And by doing the CAP, we basically have all the data priced with the same price, at least at the floor. So here you can see with the 64, for example. And this means we then end up with, Call data, blob version hashes, only those, few bytes. Authorizations. And as well as the access list, all priced with the same, cost. Let's move on to the second EAP. Which prices the ball, and this is a little bit more complicated, because, of course, in order to know that something will increase the block size, you have to execute. And this, in turn, means you have to start… so the previous ERP was basically… was only, like, intrinsic gas. Very simple.

But this one is more complex, because you only discover what is about to be put onto the block lover access list during execution. So let's start from the beginning here. We know what triggers something to be put into the bulk, and this is, for example, a call to a cold address, or S loading a cold storage slot. Importantly, it's always cold, right? Because as soon as we do a warm. SLoad, we know it's already in the ball. And the same applies to SSTOR, Create, self-destruct, and so on. All those opcodes, we know them. and how much they put into the ball. For example, a call opcode puts a 20 byte address into the ball, whereas, for example, a create deploy puts the length of the code into the ball.

And what we would now need to do is, during execution, we would first determine the floor costs, just using the intrinsic gas. This is like we do it today. And then during execution, we would introduce a new out-of-gas failure, and this would be raised if the floor gas used would go above the transaction gas used. So the interesting part here is. Each opcode, for example, for an S load, you would now also pay for 20 bytes of data cost, at least at the floor. So this is important. The normal cost of that S-load, as it is $2,100 as of today, wouldn't change. It would only change if you have a transaction that hits the floor, the data floor.

Just like we have it today. But now, this Sload also contributes 20 bytes to the floor cost. And by doing so, we get to this very nice picture where you end up with all the data in the block being priced the same, at least on the worst-case size. And for average transaction, this also means we don't really have to touch them. So, for example, we could even not apply any data pricing on a regular S-load at all, only for those transactions That actually hit the floor. So this is… this strikes a quite nice balance between, reducing the worst-case block size, also accounting for bul, and at the same time, not impacting the maturity of users.

And yeah, we can go to the final slide I have there, it's… Yeah, we can even skip that one. I already mentioned that the formula is not block gas limit divided by 64, which is very nice, because today it's very complicated to actually calculate the worst-case block size. And here we can see the impact of those two EIPs combined. So the first one that deals with the intrinsic gas would increase the cost, so the gas used for 3.29% of the transactions, but importantly, most of them are already paying the floor cost today, because we have 7623, we will do 7976, so most of them already pay the floor cost. For them, it's just a… Constant increase.

And, of course, a few more users that might suddenly pay the floor costs because they use blobs. For example, you can see here that most, 4844 transactions they would be affected, but only, like, negligible. And also, 7702 authorization would be affected, because they actually come with quite a lot of data that is not priced in. So yeah, the TLDR is quite a massive 40% block size reduction, and only a few more percentages are affected. And in the end, it's like cleaning up everything around data pricing. And one final thing. Those two EEIPs don't even need to determine what the final price the gas cost for a byte of data is that we want to have. It's more… they set up the stage to have everything priced fairly. Basically, every byte of data that a user puts into a block is priced fairly across

Everything we have. And the same applies to the block level access list. Awesome, that's all I have, thank you.

Ansgar Dietrichs: Awesome. Thank you very much, Tony, and thank you, Josh. Ben, you have a comment?

Ben Adams: Yeah, so at the moment, we've… we've put in the block size cap, which is like a… sort of an emergency backstop, as it were. And so is the goal of this to bring back in the economics, in terms of Enforcing that cap, rather than Hitting the cap, and it just distorting the market. Fantastic.

Toni Wahrstätter: Yeah, yeah, it's an interesting one, because today we have the cap at 8MB, and then 2MB for the CL, so 10 megabytes. And today, we are far away from hitting that cap at 60 million. Like, the worst case block size I just mentioned was 1.5MB compressed. Of course. And we are quite far away from hitting that. And, of course, uncompromised, we get closer to that. And I would argue it's… we should try to stay away from hitting that cap, because it just makes building less efficient. Fortunately, with the transaction gas limit, things became nicer. But still, I would… I would… I would just keep this, 8MB limit, and… Potentially just try to stay away from hitting it, and keep it as a security mechanism.

Ansgar Dietrichs: Sounds good. Any other comments now? Questions? Yeah, okay, that… thank you, Tony. Next up, we have Greg, who wanted to also talk about two EIPs, 7979 and 8173. craig?

Greg Colvin: Good morning, can people hear me?

Ansgar Dietrichs: Yes, we can hear you.

Greg Colvin: Okay. I'm fighting a bit of a cough, so I hope I'm audible. One of the IPs is just informational, because the motivation section on 7979 was just way too big. I've made one substantial change to 7979 that's worth discussing. Which is, rather than have the client need to implement the validation algorithm, I'm thinking to do what I noticed the researchers are starting to do, which is to move that algorithm on-chain. So that a client, can simply take the output of the init code and run it through the algorithm that's already on-chain. So a client does not need, to write that validation code. There's a…

a canonical version on-chain that people can use. Man, the only reason to write your own is if… For some reason, calling. Calling that is harder, or you've got performance issues, or something like that. But in general, clients don't need to do that, so the implementation can become very simple. So that's the main substantive change that I wanted to point out. dumb. To see if that could cause problems, I'm not aware of. Because it's been a long time since I've worked on client internals.

Ansgar Dietrichs: Yeah, I'm not sure if we've had clients already that have already had time to look into this, or now hearing it live, have an immediate opinion on it.

Greg Colvin: So everyone at least understand what I'm proposing to do. Fair enough.

Ansgar Dietrichs: It seemed to make sense to me.

Greg Colvin: Okay.

Ansgar Dietrichs: I'm not sure, maybe they have questions? I could imagine people maybe just need time to… To have a look.

Greg Colvin: Yeah. And it's actually… Could be a pretty general mechanism. That… Pretty much anyone could take a header, drop in the address, validation code, and the client could run it and not really care at all. What the validation algorithm is. Which means that, Compiler teams and, static analysis teams, could decide on a particular algorithm they want to use, and they no longer have to, bother the core devs about it at all. And that makes sense to me, because in industry, object formats aren't really the problem of the compiler. Yeah, those are… those are pretty much up to the linker.

income. And… The other issue… Which is too much to discuss right now, but I wanted to make sure it's on the table now, rather than the day before we ship. Like last time, which is there are no code sections here. Subroutines are not, a contiguous section of code. The validation starts at the beginning of the program, it traces the entire control flow of the program, and it simply doesn't have any reason to care how the bytes are laid out syntactically. And people seem to object to that strongly, and EOF, worked hard to maintain separate sections.

The problem being that certain optimizations really required the possibility to jump out of one section, one function, into another. So they had to introduce special… special purpose op codes for that. And I'd much prefer that… that compilers can simply do those optimizations without the… without the instruction set just getting in their way. And so that's something that's there and will need to be discussed. And again, if it's truly a showstopper for someone, I want to stop the show now. Rather than after people have done a lot of work, and the community is… has raised a lot of expectations that this is coming. So… I just wanted to point that out. We can discuss it some now, or it can just be there, and please bring it up.

On the magicians, if it's an issue you care about. Because jumping in and out of subroutines was, a huge issue. And at the time, I was not able to explain, why for machine code. That was just not an issue the way it is for higher-level languages. So… Those are the two things, that I wanted to point out in the specification, that are gonna be open issues. And issues that could… could resurface very late in the process, and possibly cause a huge storm on Twitter. And, for some reason, we seem to care about huge swarms on Twitter.

Or shitter, as I call it these days. So, that's that.

Ansgar Dietrichs: Sounds good. I think you also said, In the agenda comment that you think it might make sense to… to have a breakout call scheduled to follow up, because obviously, like, some of the implications here are, like, a bit nuanced, and would be good for people to have time to look into it. Is that, A, I assume that's still your intention, and then B, the question to me, in my mind, is mostly just around timing, when to plant something like this, so that people are maybe not too distracted with Glamsterdam work, but yeah, I'd be curious. About your thoughts on having a break?

Greg Colvin: Yeah. Definitely we want to do that. Josh has been helping me with that. it seemed like the schedule was running a little slower than I thought, and, personally, it got slowed down because we had a death in the family. So, yeah, I'd like to do that soon. I'm not clear on when it has to happen. so far as… as leaving enough time. After it for everything we have to do.

Ansgar Dietrichs: Sounds good, yeah. My condolences, with the family. And…

Greg Colvin: For a long time.

Ansgar Dietrichs: Yeah, regarding the breakout call, I think, yes, then it's good if you're already in touch, I would, yeah, I personally would maybe recommend yeah, being intentional with the timing, I think we haven't yet even decided on a date for the… for the end of the proposal windows of new EEIPs for… Hegota, and then once that is done, there will be the time period for decision making. Obviously, you don't want to be too late in that window, because then there's not enough time to then iterate on the results and have that be part of the decision-making basis, but if it's too early, also people might be distracted, so finding the right timing, but I think Josh and the protocol support team can

can help you, kind of, figure out what the optimal timing there is. Okay. Okay?

Greg Colvin: Okay. At my end, I think the spec is pretty close to completely solid. The main issue is just convincing the editors to merge it. It can take them a month to merge even the smallest change. So I'm… I'm down to pointing people at blobs, but hopefully at some point, there'll be a solid draft, that'll be easier to review and easier for the community to review. So… That'll be one… one blocker on the breakout, is to… is to get a draft actually merged and published. If so. I don't see any big problem undoing. Just picking an appropriate time, place. Okay, thanks very much, and if these are things you care about, please, please do think about them, and bring them up on the magician's list, or bring them up with me personally.

Oh, my co-author… on the validation algorithm and the ZK implementation, passed late last year, so I no longer have anyone to help me on that. So, that's also something that's gonna need, need review on the lists, or even need a co-author if somebody is really motivated. This is one reason I've been pushing on it, because I'm… I'm losing co-authors.

Ansgar Dietrichs: Yeah, well, my condolences there as well, then. Hopefully we can… Reverse that trend and have your number of quarters go back up again. M… Okay. But then, I think that's… we have good next steps with you, kind of, merging that, Yeah, that draft, and, then us finding, finding a good date for breakout.

Greg Colvin: Okay. Okay. Thank you very much.

Ansgar Dietrichs: Thank you. Mmm… And then we can… move to the next one, that's a single EIP, by, Mohamed. That's EIP8222. Are you on the call?

Mo Jahanara: Yes, hello. It's going to be a very quick, sharing… Our intention is mostly to just gather more feedback and, like, to sanity check the core ideas. The EIP is, far from, you know, being ready to merge. There is a… Meditation, topic for it, so you can… Chime in there? But, yeah, but… I'll tell you more about it in a bit, and I would love to hear your feedbacks. Give me a second. Don't know how to do this, but… Sorry, I have to leave and join. Somebody else please, do it for me so I don't have to do that? Pierre, could you please open the docs, or, like, if somebody…

Pierre: Sure, same.

Mo Jahanara: Thank you. Awesome. Thank you, please.

Ansgar Dietrichs: See the screen.

Mo Jahanara: Yes. So this is an AIP co-authored by Pierre and I. It's called lineness staking. The motivation is, Ethereum doesn't offer any privacy at base layer, so we want to solve that. That's a key motivation. There are application layer privacy tools, but none of them offer meaningful, plausible deniability, meaning that when you interact with them, it's obvious you're seeking privacy. They're not post-quantum, they're small privacy pools, and of an extractive, opinionated, and so on and so forth. Next slide, please. So, yeah, and also validators are backed one of Ethereum, but there is no privacy protection for them. Meaning that when they move, funds from execution layer to the consensus layer, and, like, deposit into Beacon Chain. They revealed that, okay, I'm going to run this validator identity.

And you can link it with my iChain, Unchain identity, and maybe potentially extract more information about me. And it's important to note that there is, like, network-level anonymity, and it's a mature, well-studied topic, like, you use MixedNet and, and your routing, and so on and so forth, but for the problem of linking your unchained identity to the consensus… You know, not… there isn't much discussions? And the side effect, or potentially the cherry on the top, is that users who want privacy but don't want to run validators may benefit from this, you know, introduction of privacy for validators. Next slide, please. And in a nutshell, that's, like, the big thing, is we want to introduce a base layer privacy pool, and

Route the staking flows through it, so that this privacy pool is big from day one. And could offer a plausible deniability, because, like, it may… using it looks like you're using test-taking flow, you're going to operate a mode, and so on. So, just a simple diagram. Today, when you deposit into the Beacon deposit contract, you reveal that, okay, this is my it, this is my validator key, and this is where I'm going to withdraw to. So… These are all linked. The idea is you deposit in a new version of the Beacon deposit contract. That, doesn't take all this information from you directly, but take them as a hiding commitment, as the hash. And then you can reveal the content later and claim it. And you could use frame transactions, relayers, and so on and so forth to do it without doing it directly from your main account, or the same account that made the deposit.

So we call this a two-phase deposit. And so far, what we described in this slide doesn't need any changes in the consensus slave. Next, yes, thank you. so what… what this achieves is, it breaks the link between the validator identity and the… Depositing site, and the withdrawal site, but it doesn't break the link between the validator, you know, public key, validator identity and consensus layer, and withdrawal credential. So, the address that gets the funds? Ultimately, the withdrawal credential doesn't… doesn't have, like, a broken link. So we call this, like, one-sided plausible deniability, and I explained a bit more why that's the case. I see a question, but I respond after I finish, there is a few more slides.

The next part of the idea is that applying the same thinking to the withdrawals. basically, we introduce a new… we could introduce a new, withdrawal credential type, say, Type 3 or Type 4. I see there is a Type 3 already in some active EIPs, so that doesn't matter. Don't confuse them. So there's a new, withdrawal credential type. That's basically a commitment to a recipient address rather than an address. So, if you choose that type of withdrawal credential, instead of receiving the funds when you withdraw or when a withdrawal happens for you. Directly, you receive a commitment in a contract, that you can then go and claim by revealing the, you know. The… the… the address inside the… Commitment you made.

So, if you go to the next slide, Pierre, I can deliver the punchline. So the punchline is, you could make, you know, pending deposit. In a private beacon deposit contract, and without going through all the validator queue, withdrawal queue, deposit queue, stuff like that, you could directly nullify this and take it to the withdrawal pool. But the funds that come out of the withdrawal pool look like… or are mixed with the funds that, you know. been withdrawn, from the second, consensus? Layer staking. So they offer you a lot of privacy, because there's a ton of activity. And, we already have a POC using LeanVM for the circuits. So if you're… I'm sure all of you are familiar, but LeanVM is basically an effort to create a post-quantum,

VM that could be across… could be used across Ethereum, like, including verifying signatures in consensus and so on and so forth, but broadly for other things as well. So we implemented these things in LeanVM, and although LeanVM is experimental and not very optimized and so on and so forth, it runs very fast, and works great. And, there are plans, to, implement this in REST. Had tips to Anton, and, others in the privacy transaction, private transaction engineering team in EF. And that's it. So, I already see one question. So the question is, why do we do this at the Beacon contract level? Rather than… any application thing. So I guess one… One big thing is you get plausible deniability in this design, or at least we claim that you get plausible deniability by forcing a lot of legitimate protocol flows into the same, you know.

Fool, right? So, if we want to achieve that with the application level thing, we need to force, you know, stakers to go there. which sounds, not very achievable. Like, I understand we could implement this protocol primitive as a contract or as an application, and then make it a protocol rule that everybody should pass through that, the withdrawals and deposits?

Potuz: Oh, no, no, what I mean is, why can't you just use any privacy pool at all? Just use any privacy pool that people are using for anything else, like Tornado Cash, or whatever it is.

Mo Jahanara: I see your point, yeah. Then you don't get this plausible deniability. Like, say I use Turn of the cash today. And my address is immediately flagged as somebody who's seeking privacy. But… and the reason is, like, legitimate flows, or quote-unquote legitimate flows, don't do that, usually. But if it's a protocol rule that everybody has to do that, then I could just simply claim I'm participating in a quote-unquote legitimate protocol activity, I'm not actively seeking privacy. So that's the key idea. as I said, like, the EIP in a nutshell is to introduce a privacy pool, or pick a privacy pool. and force the staking flows to go through that. And the staking flows are big, obviously, and that gives you plausible deniability, so on and so forth.

I understand it's a sensitive topic, and the reason we are bringing this up here. It's to just gather this kind of feedback, so… Yeah, please let me know.

Ansgar Dietrichs: Potuz, do you have your hand up again?

Potuz: Yeah, so if I understand correctly, an application of this could be, if we phrase the IP in a completely different setup, setting, would be, we want to enshrine a privacy pool that is guaranteed to have a lot of traffic. Therefore, let's have a privacy pool in which every staker is forced to send money there, so that at least we know that this privacy pool is going to have a lot of liquidity. So in that sense, it was just forced to have a privacy pool on L1 that is forced to have a lot of liquidity. If that's the… If that's the EIP, at least you would have some sense to me.

Mo Jahanara: That's… that's the intention, yes.

Ansgar Dietrichs: Tony?

Toni Wahrstätter: Yeah, to me, I'm not sure if… Like, the uses of privacies and the people staking, if this is, like, set that harmonizes very well, because, for example, you have, like, 32 ETH requirements for staking. Which is, like, you won't provide privacy to a lot of users there. And also, like, staking has no predictable churn. It's not like your anonymity set, which is rather big, Is actually that helpful? Yeah, I'm not sure about this EAP. To me, it feels like, simply withdrawing and then using a privacy protocol would give you very similar guarantees about privacy. And we won't need to enshrine anything.

Mo Jahanara: I can quickly respond to the… To the point Tony has. So, I agree that the churn is not predictable, or, like, fluctuates a lot, but the churn is indeed a lot higher than the churn you get on the typical price equals, at least 10x on the worst days. And often, like, 100x more. And again, the reason it's different from, like, using a privacy application layer is, like, this notion of the power of defaults, or, like, what's the legitimate action. Like, that if you ignore the plausible deniability part. This doesn't make any sense. You are all right. But the idea is to achieve something like the wormhole EIP that, like, can't be achieved without compromising on bit security, but we want to achieve that with, like, without compromising on bit security.

So, instead of picking, like, Transferring funds to a random address, which looks like a legitimate action. We picked, like, another legitimate protocol primitive, which could be, like, a bad idea. That's the intention.

Ansgar Dietrichs: Peter?

Peter Miller: Yes, you said that a core part of the IP was having two… Compel people who are staking to go through the privacy pool. I don't understand how you can do that, because without… because currently there are a bunch of existing mechanisms. And we can't disable those existing mechanisms, because we'll break everything, we'll break… All of the existing, like, staking pools. And if we keep the mechanism, there's nothing to stop users from just using the old ways of doing it, and no one putting anything into this pool. So how do we compel people to use the pool? without… Also, breaking all current staking infrastructure.

Mo Jahanara: Very good point. Indeed, like, you need to, at some point at least, disable the old flow to make sure that this goal is achieved.

Barnabas Busa: You cannot.

Mo Jahanara: Like, never, never?

Barnabas Busa: Annually, never, never, yeah. I mean, it's like disabling an opcode. like, we've been trying to get rid of Seth Destruct for, what, 6 years now? And… There's still, like, one random guy that's using it, and… That's why it still hasn't been removed. So, like, removing… The functionality is… is not… It's not easy.

Mo Jahanara: I see.

Potuz: I think this is very easy. We can just force every validator to be 0.04, and then the contract is disabled for 004 validators. So, it should be easy to make this kind of changes in particular. It should not affect existing validators, but it would affect every newcoming validator. But, again, this is… this should be analyzed in the form of, we want to enshrine a pool and then force every validator to deposit in that pool, which seems kind of crazy at this stage on L1.

Ansgar Dietrichs: Right. Yeah, I mean, it seems to me like, there's… a lot of questions, a lot of skepticism around this for now, but I think it's good to have. At the presentation. have this as a proposal on the table. One question that I saw was the clarification of, is this something that you are considering proposing and pushing for for a Hegota, the Hegota folk in particular, or was this more just a initial bringing up the topic initially to basically have that conversation longer term?

Mo Jahanara: Yeah, I mean, it's very unlikely that this could be part of Hegota. Sorry if that was a mandatory, like, requirement for sharing, but the reason it's unlikely is LeanVM, or an alternative proof system, is required to be mature and well audited, and it's very unlikely that would be the case for Hegota. And, like, we require to enshrine a proof system for this, for sure.

Ansgar Dietrichs: Makes sense. Yeah, no, I just wanted to double-check. I think it was purely on me, I miscategorized it, but that's fine. There's no… strict requirement to only propose a good idea, but I think it's still good for everyone to be… to have that clarified. Yeah, then I think for now, it's probably… we've, kind of given this a general overview, I'm sure there will be continued lively discussion on this, but for the call, it's probably good to end the discussion on this ERP here. Thank you for the presentation, and then we'll move on to the last two EIPs that, Matt wanted to bring up, lightclient wanted to bring up, EIP7851 and 8151. Are you on the call?

Lightclient (Matt Garnett): Yep. Thanks, Ansgar. Yeah, so I'm presenting a couple EIPs. I've been working a little bit with the authors Colin and Nico on. They kind of, like, fit into this broader suite of account abstraction, and… completing the migration of EOAs to smart accounts? So today, with 7702, we kind of give EOAs the ability to you know, act like they're a smart account. But we don't really give them the ability to disable their EOA key. And so, this combination of 7851 and 8151 sort of allow users to fully deprecate their EOA key and focus on You know, whatever security they entry in their smart account. So, I can quickly say what both of these EEIPs do.

7851 is the code-controlled EOA delegation. Basically, the idea here is that we allow the user account to make their 7702 delegation permanent. So, they do this via an opcode, so once you have delegated to a 7702 account and you're using the account, you can then call this opcode with the target of, you know, the target delegation that you want to make permanent for your account, and it will change your delegation so that it's not a 7702 delegation, which is EF01. And it becomes an EF02 delegation. And so now we can treat this differently. We can, not allow it to originate transactions, for instance. We can also disallow future delegation changes via 7702 at that point.

So once that opcode is called, it becomes a permanent fixture of the account's code. So that gives us the ability to disable 7702 and transaction origination for the account. That's, you know, a lot of the, you know, use of the EOA key still. Then we still have the problem of how to deal with EC Recover, and that's what EAP8151 handles. It's the, deactivation-aware update for EC Recover. So now, when the user, or when the protocol does an EC recover. What it will do is it will take the recovered address, and it will just check the code for that address, and it will determine if that code is a 7851, permanent delegation. And if it's a permanent delegation, then it will disallow

you know, positive, successful return of EC Recover, which in turn disallows the user from using their EOA key, or some other actor to use that EOA key, to, you know, take funds from the account via things like Permits, Permit 2, any kind of, like, on-chain mechanism that relies only on You know, EC… EC Recover Signatures. So… that's kind of the idea with these two contracts, or sorry, these two EEIPs. Ultimately, we just want to make it so that there is a clear path for users to delegate, you know, permanently delegate, and totally disable their key. To me, it makes sense to start looking at this for Hegota. Some users are wanting to, you know, begin migrating to post-quantum accounts?

whatever that, you know, exact scheme ends up being. And so, the sooner that we can start supporting this, the sooner that applications can begin building the tooling, and the wallets can begin supporting this type of migration. Ben?

Ben Adams: Yeah, I have, rather than moving from a 7702 to a… EF… 01. Have you considered using a… Set. A set code from… Opcode, which is… would be more general. Because, so rather than moving to another proxy, you just change your code. And then, naturally, the transaction pool rejects Transactions initiating from a source that has codes that just 13. And then you could use it for some… something like… 8058, which is… duplicating, you know, like, if you're deploying an LP Where you're constantly doing creative, creative, create 2, you could also use it for that.

Lightclient (Matt Garnett): Yeah, I mean, I'm personally supportive of a more general use of the delegation. I think they… here, we tried to make it as… You know, small-scoped as possible, focused on this problem. But if people are open to a more generally scoped, set code. type of operation, then I think that that's honestly great as well.

Ben Adams: Yeah, it would… it would still need, an address. So rather than, you know, a hash… Code hash, it would still need an address, so that you… Yep. Copying from something deployed.

Lightclient (Matt Garnett): Yeah, I mean, that's… that's a great outcome as well, to me.

Ben Adams: And then, if we did go that way, for the 8151. That could be just changed to, if there's regular code. disallow the easy recovery, so it would affect all contracts. We'll see.

Lightclient (Matt Garnett): Right. Yep. Yep, that's good feedback. Does anyone initially against a more generalized solution for letting, you know, kind of basically building an in-protocol proxy system with set code. Common.

Ahmad Bitar: Yeah, I just want… just wanted to say that we can't really do what Ben suggested about EC Recover, where it just checks if there is code, because some account might have a delegation But it's the non…

Lightclient (Matt Garnett): regular code.

Ahmad Bitar: Yeah.

Ben Adams: Yeah, so it would have, like, it would say if you were, a 7702, you can… EC Recover works. But if you're a regular card, not a… delegation.

Ahmad Bitar: Yeah, but that's a diff… I don't think that's related to the topic, though. Like, that's… that's a different issue now.

Ben Adams: And that's the… that's the second DID. And…

Ahmad Bitar: I know the second EIP is about disabling EOA and EC Recover. After you do that, the opcode that disables the AOA, but adding another functionality to it doesn't seem to be the right Think to do? I don't know. Not sure.

Ben Adams: Okay, but I'm saying you'd change it… so at the moment. Transactions are rejected if they come from an address that has code. And it would just change the EC Recover to be rejected also from… Addresses that have code. So it's, like, a simpler… It would be a simpler version.

Ahmad Bitar: Yeah, but it has to be code that is not a normal 7702 delegation with 01.

Ben Adams: Yeah. I.e. ones that would be accepted by the transaction pool. So, yeah, regular code. No, I'm just saying we can make the upgrade path 7702 delegation. The regular pit. And then that would automatically deactivate the UA.

Ahmad Bitar: Also, Matt, I'm thinking about the potential criticism of the opcode, that it might be abused by… Phishing account… phishing, fishing, attempts. Shall we only enable SIT code opcode for… delegated accounts that have already migrated to disabling the AOA, so that the attack surface is way… Shallower and smaller, and these… people who have already migrated to a smart account fully and disabled their AOA probably are more aware of the dangers of signing, I don't know. arbitrary… arbitrary, like, hexadecimal. Bytes.

Lightclient (Matt Garnett): Think I follow… What you're saying, basically right now, though, Because it's an opcode. They have… have to have already deployed, some delegation to their accounts, right? And that delegation needed to also support The ability to permanently migrate.

Ahmad Bitar: Yes.

Lightclient (Matt Garnett): I guess, technically, you… You could delegate immediately, to a account that just immediately then calls in the same transaction. The… you know, set code from for your EOA. At the end of the day, I kind of said this in the chat, I feel like the attack surface, in my mind, if we assume that somebody could trick or convince or cause a user to sign… to blindly sign some piece of data. To me, that's… Essentially, game over for that user. You know, 7702 certainly makes it the case, but even before 7702, like, as batching standards continue to evolve. One signature could cause the majority of your funds to get drained. So I don't really see it as… Too much different than… those situations.

Ben?

Ansgar Dietrichs: Pen?

Ben Adams: Sorry. I'd just like to highlight the conversation in the chat, because there's 8 050, which is trying to use… A similar idea for deploying contracts, Which would be solved with… if there was a more general thing. And so the question is. should we change this IP, that IP, or create a new IP that's more general?

Lightclient (Matt Garnett): Sorry, what was the EAP?

Ben Adams: APO… APO fiber. 5 eighths, right.

Lightclient (Matt Garnett): Okay, 805B. My preference right now would probably be to… keep this EAP… As is. And if people prefer to… to do 80558. I haven't read this one fully yet, but…

Ben Adams: That would… that's not quite this idea, because it uses access lists to give the address, but there's, a unified Stat code would be… Would work, right, for this. But we can do that as a different EIP.

Lightclient (Matt Garnett): Yeah, I would say either do it as a different EIP, Yeah, I would do it either as a different EIP, or I would change 805H, just depends what the authors feel there. I feel like for 7851, To me, it makes sense to kind of keep it as is, just to… have the idea there. If for some reason, we find in the future that People don't want to, or we can't as easily do a generic set code from, then we have that to at least fall back to pretty easily.

Ben Adams: Okay.

Lightclient (Matt Garnett): I know there's been some proposals for reusing the 7702 delegations for deploying code. Are there any EEIPs that exist out there that already kind of do this that we should just be using? I think most of them reuse delegations, but what you're proposing is to actually set the code based on The set code. Address. not, like, make a delegation within… with the indirection in this. Is that right?

Ben Adams: Yeah, yeah, and then you could use it for… for instance, like Uniswap, the… 3 and so forth, you know, they're constantly deploying liquidity pools, and rather than Doing… paying the full cost for the transaction, since you're essentially just copying code. You can go code hash from this address.

Lightclient (Matt Garnett): That makes sense. Okay, I'll take a look at the EEIPs that exist and see if any of them do something like this, but I think this is slightly different, and so we can just introduce a different EAP. Thanks, Saul for the feedback. Any other questions or comments? Yeah, send the emojis. Alright, thanks.

Ansgar Dietrichs: Awesome. Thank you very much, Matt. And with that, that was the end of the agenda. Is there any other topic, anything anyone wanted to bring up on the call? Thanos?

Barnabas Busa: Yeah, maybe just one topic to mention. Last week, or maybe a week before, we decided to, go with Marius's, engine necessity changes instead of the proposal that I have, submitted, so if you have, If you have implemented, my proposal regarding the execution API changes, then maybe take a look into Mario's. It should be… a small… Difference, and yeah. That's it.

Ansgar Dietrichs: Ben, is that on the same point?

Ben Adams: There was a concern on the number of deposits. Is that still in any particular block as the block size increases? Is that still a… Concern, and something we need to… Addressed?

Ansgar Dietrichs: Yeah, I remember that concern. Do we have anyone with context on the call right now? Otherwise, I think we can also look into that async.

Barnabas Busa: Yeah, I think that is more… more of a CL issue, So… we could get around the issue in two different ways. We either increase the number of maximum deposits to, like, 2X, so that we're gonna be good for, like, 400 million gas. Or alternatively, we, at the… the IP77… the stable container EIP, and then we could just make that an optional field, and that would also get around the issue. But yeah, Potuz can probably explain it a bit better.

Potuz: So, just to clarify myself on what you're saying, so there's one issue, which is the EL might… if we increase the gas limit, the EL might produce a block with enough deposits that the CL will not be able to handle Not because of compute, but because we would just, like, be over the… a hard limit, a hard code limit. We want to avoid that situation, and I think we agreed That we will try to keep, progressive containers on the table. If we see that it's not getting in, then we're just going to increase the limit, a lot. We can just change the number later on. But I also want to point out that Nico Fleg… Nico Fleg, I'm not sure, or Fleg, or whatever, I don't know how to pronounce your last name, Nico. They opened an EIP not long ago, proposing a new

A new model for having a new contract to send different requests for builder deposits, and that's another way of attacking the same problem. So, perhaps you guys want to… want to, showcase your EIP.

Ben Adams: Is there a concern that there'll be too many signatures?

Potuz: So there is an attack, which is a DOS, in which someone can send a lot of money with a lot of signatures, because the deposits are now allowed to be for one ETH, and create a lot of builders, and then the CL will not be able to handle it. And then… We believe that it's… this is not so much of an issue. On the one hand, for builders, it's not good… it's not a good idea to produce such blocks. Also, we can handle a lot of signatures, and also, that locks a lot of capital in the CL side that we can just fork off, if it happens to be an issue.

Ben Adams: Okay, so it's not… there isn't a problem with… in terms of the amount of compute also, rather than just the container element.

Potuz: Well, so the one of the containers is a critical problem, because if we do hit that limit, then we're gonna be in a situation in which we can't really process those blocks at all. But the compute one is also an issue. clients will be… will start lagging if this happens. We might see a lot of, instability, but this is a very cost… attack. We're talking several millions of dollars, and we can easily fork it without, without affecting a single transaction on mainnet.

Ansgar Dietrichs: any other… Comments on this? Okay, then we still have 3 minutes to regain here, so then… Unless there's anything else anyone wants to bring up, then we can… End now? Okay, then thank you all, everyone, and seal again. In two weeks, either as a participant or coordinator, we will see. Awesome. Thanks, guys.

Barnabas Busa: One more quick mention, just a reminder that, next week, ACDC call is, shifted to a different time slot. For now, this is just, this one call about, possibly if the Australians will show up, then we might make it more regular. Oh, it is… it will be at 11 o'clock UTC next week.

Ansgar Dietrichs: Sounds good, thank you. Barnabas.

Potuz: Bye bye!

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