All Core Devs - Execution #214

Transcript

Ansgar Dietrichs: I put it in the chat. Is the live stream switched over.

Josh Davis: Whenever you're ready.

Ansgar Dietrichs: Okay, yeah, let's do it.

Josh Davis: Alright! You're live!

Ansgar Dietrichs: Perfect. Hello, everyone. Let's try to get started more or less on time, because I think we have quite a bit of agenda to go through today. I am filling in for Tim today who is out of office? Yeah. Then let's just jump right into it. 1st off on the agenda. We wanted to briefly recap a few items from interop. In particular, the 45 million gas limit increase that is planned, and the devnet that was run at interop. So 1st for the gas level increase. Pari, are you on? Could you give a quick update on client readiness and the timeline here.

EF Berlin: Yeah, hey? I hope you guys can hear me. So over the course of the week we had a bunch of opcode tests and benchmarks that we ran against all the clients we were able to get all the clients above the 20 million mark without MoD. Xp. And around the thirteen-ish 1 million mark with MoD. Xp. Most clients do have some performance fixes or releases pending which should happen over the course of the next week. and also was discussed on acdt, and all the clients seem to be okay with moving ahead with 45 million. Once the releases are done, we should have some blog posts, analyzing how stuff looks and what approaches we use to get to the number. But yeah, more would be coming over the next week.

Ansgar Dietrichs: Okay, sounds good. Any client comments on this. Anything we need to talk about here on this point. Okay, then we can briefly go to the other inter point, which was the Belintop devnet 2 that we ran at intop. Barnabas. Do you want to very quickly give an update of where that is at.

Barnabas Busa: Sure. So the lunch barely interrupt approximately almost a week ago now, 5 days ago, and we have 83% participation on the network right now. There's a quick link. We have a few clients that are looking into some missed slots. I have been everyone already yesterday, and they're taking a look. And we plan to shut down this network on next week. Tuesday just the day after we have launched 2.

Ansgar Dietrichs: Sounds good, and I assume that also depends obviously on finalizing the timing for Devnet 2, which will be the next agenda point. Ben here to remark.

Ben Adams: Yeah, do we need to discuss what was in the berlin interrupted. Oh, I suppose that's the yeah. Never mind. That's the next point.

Ansgar Dietrichs: So the next point will be on the full. Devnet 2. The naming is a bit confusing, right? So basically, Belintop Devnet 2, the one that we had at interop, and then we will have full devnet. 2. I guess we could have called it Devnet 3. But whatever that we will launch hopefully next week. Ben, do you think it would be important to also briefly recap the scope of Berlin top? Devnet.

Ben Adams: Well, it it it comes up in the in the next point, so we can discuss it there. It was just the scope of it, that was all.

Ansgar Dietrichs: Okay, yeah. My understanding, my understanding was that, I mean, yeah, it basically included the Cfi eips except for 7, 9, 0 7, and it included one, not Cfi eap, which was 7, 9, 3, 9. But yeah, that's Talk about the implications of of that in the next section. Then, yeah, we can move on to thank you, Barnabas, to the to talking about the the next devnet, which will be Devnet 2, and the hope would be to launch that. And next week in general, just to briefly basically recap where we're at in terms of Fusaka progress, we are really getting to the point where we want to have the fork frozen. Frozen means 2 points, one. Ideally, we can today make final decisions about inclusion. So we have Cfi dips

where we today should make the final go. No go decision whether to move them to Sfi and schedule them for the upcoming devnet, with the understanding that whatever is not selected for Devnet 2 at least, as of today, would then be intended to also just not go into the hard fog. and then, within the already sfied Eaps there are some small last parameters that also need to be cited. And again, ideally, we would make that decision today as well. And Barnabas, I think you also wanted to briefly talk about basically the ideal timeline for Devnet 2. And but basically the plan would be assuming we can get all of these finalized today.

Barnabas Busa: Yeah. So the timeline would be that we can start testing basic interrupt functionality tomorrow. And we should be able to launch that net 2 on Monday around noon control European time. This is assuming that we will have at least 3 years and 3 cls. Ready by then. if we can get it by then, then we're gonna push the launch by today and see if this can get certified. Then.

Ansgar Dietrichs: Sounds good, so the plan would be now for us to just go through the list of 1st the list of all the Eaps where there's still a question about inclusion decision. So those are 4 Eaps here in particular, and then we have 3 more Eaps that are already included where or 2 equally that already included 1 1 special case. That's that's a non, non, protocol changing eip that we then also have to talk about. So 1st off, the 1st section here will be final inclusion decisions. Basically. So let's get going with that. The 1st item here, the 1st one to talk about is Eip 7,951. That is the r. 1 precompile. The number might be confusing to people, because there used to be an IP. IP. 7 to 12.

But because there were some small spec incompatibilities with the version that we want to have on Mainnet. The decision was made, I think on a previous call already to have that be superseded by a proper eap. So now that is, eap 7,951, that eap is currently still on Cfi, and so the proposal would be today to move it to Sfi and included. I have 2 items on my list to discuss about this, the 1st one would be the final cost of the precompile. Marius had looked into this and had found that the precompile is underpriced at roughly, basically half the cost per millisecond compute as easy recover, and so was recommending a doubling of the cost.

Do do have other clients had time to look into the performance of the r. 1 precompile? And do they generally agree with this recommendation, or would they prefer to keep the current pricing in place.

Alex Stokes: So if wait, is there an echo.

EF Berlin: Yeah, alright, it's 4. Yeah. I think if Marius found this, it'd be nice if other clients could confirm. And then, yeah, assuming we find this differential, we should just raise the cost of our that being said, I think, that can be done in parallel to having it on devnets. This is something we can keep iterating on in the same time, so I think we should go ahead and move forward with inclusion.

Ansgar Dietrichs: Well, then, I mean, I mean to just immediately revisit. The goal would be to today. Come, get to a version where at least from the El side. Basically, everything is frozen, including parameters. We could. Of course, that could mean we make the decision. And that eap then still has to be updated. If, then, in testing and everything, of course, we, we find reasons to still need changes that that is still possible. But I would still rather include the eap today in a form that at least hopefully does not require further changes.

EF Berlin: Do we.

Ansgar Dietrichs: Like my proposal would basically be to to just move the eip to Sfi with the understanding of that, that the price is doubled. And then we will just update that the eip to to reflect that today. But we can also, of course, keep the current price in place. If that people prefer that.

EF Berlin: I would say that it. The decision should be made without a specific price. So we can still figure that I think changing the price is kind of easy to do even later, and we may have to change it a bunch more times if we discover more edge cases and so on. So I feel like we should just make a fundamental decision that yeah, this precompied will be included, but not about which specific gas price. because that is just still like subject to testing.

Ansgar Dietrichs: Okay, that's fine with me. And then, just to confirm that would mean we would leave the price, as it currently is in the Erp for Devnet to launch? Or would we try to by Monday, basically get to get to a updated view on this.

Barnabas Busa: I think it makes no sense to change the price right now in a rush. We should actually evaluate what the same pricing will be, and then we can do all the repricing eips in demonstry.

Ansgar Dietrichs: Okay, sounds good. When you say repricing earpiece, you mean just repricing the existing earpiece. There won't be any extra repricing. It's like piece. Okay, perfect.

Barnabas Busa: Well, I I don't know whether party would have any other vips that they would need to get into for second. or possibly interestingly, doesn't.

Ansgar Dietrichs: Right. I mean again, I think I think we would be good if we made a decision today, whether we will be still open to including other eips. even just replacing your piece. But let's let's talk about this at the end of the section. Okay, so we we include anyone against including oh, wait! Wait! Sorry. There was 1 1 other point on our one and there was still some question around the return format. Do we have? Can. I'm not sure if we have Kyle on the call. Kyle.

Carl Beekhuizen: I mean I can. I can speak to this briefly. it's that people don't like the fact that the precompile returns either one on success or nothing, if the verification fails. The reason we have this is this is what's deployed as as the rip on all of the l twos and in terms of like the number of the amount of gas you need to spend to to like, verify what its return was. That doesn't change so functionally, it's just that it looks a bit ugly. And you need to look at what the return type is. But I I think, having, like backwards compility, compatibility with all of the l twos that have deployed the rip is more important than having what I think is mostly aesthetic improvement

on the return type. There hasn't been any like changes like this. This is what I presented on the last Acd. There haven't been any major changes in terms of. But my overall thoughts on this. And I think, yeah, it's mostly just an opinion thing on this. Yeah, wait. Can you clarify how it looks like now. So if it succeeds, you get back a 1 value, and if it doesn't succeed. it returns 0 Byte. As I'm not like bytes that are 0 as a 0 number of bytes.

EF Berlin: But what's the alternative? Returning.

Carl Beekhuizen: It returns all 32 zeros.

EF Berlin: Yeah, okay. And then.

Carl Beekhuizen: Again. It's it's an aesthetic thing, or, like you, you need to look what the the opcode does. So the free compile does kind of thing in the specs. It's maybe not as intuitive as as one might expect.

EF Berlin: How do the other precompiles work here? I assume they return a word back in either case. No, no, okay.

Carl Beekhuizen: Yeah.

EF Berlin: Then let's leave this. Then. Yeah, we're not changing this, I think, okay. sorry for the authoritative statement. But I feel like this is like I don't know. I mean, it's just how it is with the other ones as well.

Carl Beekhuizen: That. That's why it was chosen to be this way in the beginning. But there has been some some pushback from a number of people that they just said. They don't like the aesthetics of this, which I think is fair, but, as you say, it's it is what is also.

Ansgar Dietrichs: Right? So then, basically, I think the decision we need to do make now is just, is this, do we lock this behavior in or do we say, like the pricing, it is still up for discussion again. And the more we can lock in today, the better. So it sounds. Maybe, like we are ready to lock to lock this behavior in any objections. Okay, then, as long as no one is supposed to adding this, this eap. Then I will move this eap to Sfi and the understanding is that the just, the specific pricing is still up for potential change. Okay, perfect. Then one down, next one up, and next one up is a bit of a

contentious one, that is, eap 7,907, which is the maximum contract code size increase that is currently on Cfi as well. And the question is also to move whether to move that to sfi or not, and this one was the one Cfi eap that was not on the Berlin top. Devnet 2 and we now have an alternative simplified proposal, which is erp 7, 9, 5, 4, basically, because there are some concerns around the original erp being too complex and not being well enough tested. in general. This is a bit of a trick situation, and I'm not sure if maybe anyone could hear has any prepared remarks either for or against any of the 2 alternative eaps. Otherwise I can try to to summarize the situation.

So basically, the situation is as follows, we have the original proposed eap that was marked Cfi. 7, 9, 0, 7, 7, 9, 0 7. What it does is it makes the cost for a loading contract code from disk no longer constant, but above 24 k. So basically, the point is that it raises the limit to above 24 k. And if a contract is indeed above 24 k. Then the cost for loading it for any purpose, whether for whether for xcode, hash, or xcode size, or for directly calling the contract. In all of these cases, basically. Now, the cost is proportional to the size of the of the code, at least above that initial 24 k.

The concerns that were raised at the beginning of interop were that basically, so far this has not been tested. We also don't have performance good performance benchmarks yet. And in this eap has the somewhat nuanced implication that because you need to know the size of the contract to charge the right amount of gas. Basically you. Now, every client needs a new data structure where you basically have a table of contracts to size so that you can look up the size as a 1st step, so you can charge the the appropriate amount of gas in light of us being relatively late into the fog, there was the question of is this, maybe too big of a change to be added at this moment in time? And so that that's why we had the alternative proposal. Maybe let's 1st talk about 7, 9, 0 7, and then we can

talk about the alternative. Andrew.

Andrew Ashikhmin: So I heard, if I'm not mistaken. I heard at the interrupt that bigger code sizes make it more difficult for to produce Zk proofs. So if our strategic direction is Zk, evm, then maybe we should think twice about like increasing the code size limit. But maybe I maybe I misunderstand. Perhaps if someone could clarify how like the interplay between the code size limit and the Zkvm, that would be great. But say, if it is the case that it makes it harder. But maybe perhaps the extra, the extra pricing in 79 0 7 compensate for that, and maybe 79 0, 7 is a better version, because, yeah, it's just. But the pricing is better aligned to Dk groups.

Derek Lee: Hey, everyone my name is Derek. I couldn't find the hands up button, but I'd like to advocate for including 7, 9 0, 7, or any sort of smart contracts has increased on behalf of arbitra we have a lot of devs that hit this hurdle and delayed mainnet So any kind of increase, preferably the one specified in 7 9 7 would be great. Appreciate it. So yeah, I would definitely love to hear like some of the feedback or criticisms for you know the posting and or lack there else. and fix it.

EF Berlin: I mean, maybe one thing to respond to Andrew's point. I think it's not just the size of the contract increasing. That's complicated for Zkvm. It's more that the cost is constant right now, and it happens that 24 kB is kind of a lot to compute the hash of in the Zkvm, and there's no dynamic pricing. So it's actually better if the pricing becomes dynamic, so that you can charge for the work that's being done in that. And maybe you know the price right now is not exactly what you know. It's exactly perfect to support, but at least it like puts us on the path to having better support for it. whereas this, like, you know, just increase the code size to 32 kB, or 30 or 48 kB. These don't really address the fact that the computation requirements are different at different code sizes.

So that's kind of one thing. And then, like further term, we probably need something even better than 7, 9 0, 7. For like many reasons, like stateless execution, is probably gonna need code chunking. And that's kind of the thought with 7, 9 0, 7 is that eventually we will rethink how code is stored in the State at that point, like we have the ability to like really change the costs. But that's likely not gonna happen for a few years. And this is like a, you know, not too difficult pragmatic change to improve the developer experience right now.

Andrew Ashikhmin: So it sounds like 79 0, 7 is better aligned with the Zkvm strategy then, and the other one, then 79, 54.

EF Berlin: I don't know if anyone from the team is here. I talked to some messages from Kev that he seemed like this was how he felt. But yeah, I'm not a Zk Evm person, so I can't speak on their behalf.

Ansgar Dietrichs: Pen.

Ben Adams: 7, 9 0, 7 is in principle. The better eip. However. The issue, if we're spec freezing and going live on Monday is We? We don't know if any of the pricing is correct. anything like that, because it's it's from. Where is it the Paris for pricing? And we're we're doing much more empirical testing now to. So if we want a hundred 1 million. 300 million we don't know. This is very good pricing.

EF Berlin: Yeah, I mean, we just kind of said with the r 1 precompile, we don't know what the pricing is, and we need to commit to figuring out the pricing. But like we need to commit to the feature. And I kind of feel it's the same here, like people really need to have larger contracts. And this is like the right shape of the solution. And we need to figure out. you know what the exact numbers are going to be. I see some comments also, like I made a Pr. 2, 7, 9, 0, 7 earlier today to reduce the Max size to 48 kB. So the 2 56 kB number, I think, is kind of off the table right now. That was my feeling from the Berlin interop.

Ansgar Dietrichs: Right? So obviously, the big difference between r 1 and this is that r, 1 is fully implemented and benchmarked or basically, the benchmarking is just needs to be to be done a bit more thoroughly. So. So it's just just like a 1 constant change, I think. Here there's still more open questions. But but in principle, yeah, of course, we, this would be in a possible cause of action. Maybe.

EF Berlin: Yeah, like, we don't.

Ansgar Dietrichs: Can we? Can we try to keep the order of speakers? Julio.

Giulio Rebuffo: Yeah. So I actually also agree. 7 and 7 is in theory a better solution. however, it really depends. If you want to freeze the spec today, because if you freeze the spec today. it just seems like nobody kind of agree on the specific of the Ap. Itself yet. So I think 1st of all, if we want to. If 1, 7 and 7, it has to happen, maybe with for only 48 kB, because at 48. Kilobyte, you can to some extent you. You may even not need the extra structure, and that's easier to implement and to test. So that's 1 thing. and so you cannot go straight. 128 kB after Fuzac, anyway, in my opinion. And secondly.

and secondly, it's yeah. It's just kind of like, do we want to freeze the specs today? Because it seems to me like, we are basically now just discussing whether we we include it now and then we remove it in 2 weeks. Right? So so like depends, in my opinion, what the objective here area is. So if you want to spread the specs today? I I mean. we're not sure with 7 0 7. That's my only concern.

EF Berlin: I mean, we technically froze the specs last awkward. That execution dev call so.

Giulio Rebuffo: Yeah, so I, yeah, I'm just, I'm just saying, like, do you want? Do we? Do? We want to make the conscious decision not to freeze the specs today. It's just that's just my question. It's not really anything.

EF Berlin: Think this is true the same way we did our one like, it's an important thing we want to do, and.

Giulio Rebuffo: Right. I understand. I'm okay. I'm just. I'm I'm just. I'm just putting out the question right? So if the answer is, yes, it's fine. No, it's funny also, like it's just one. It's just yes or no question.

EF Berlin: Sure I think it's starting to.

Ansgar Dietrichs: So the main the main goal that I would at least be somewhat adamant on. And of course I'm happy to be ruled if there is agreement on this. I, personally, would really, really want to make decisions today that minimize the risk of us needing a devnet 3 at least in terms of el sized features. Pdas is obviously the one Cl side topic that might require further changes. The question is, if we say for a 1. Anyway, we would want to make a final call on the specific price on Monday. Can we get to a version of 7 9 0 7 that we can include today. That would only require until Monday for us to have high confidence that we can make final decisions of for all the parameters on Monday for 7, 9 0 7. If so, then I, personally would be fine, basically saying, we basically delay Devnet to launch until Tuesday, for example. And on Monday we make final decisions, but if we think that by Monday we will likely not be in a place yet for the absolute final scope of of 7, 9 0 7

then I would personally prefer we would not move it to Sfi. I don't know if if clients have a feeling for how confident they are on that timeline.

Jochem Brouwer: I just want to mention that if there's any benchmark or any test, what we need, just let me know. Yeah, I can bench everything. But I just need to know what we want. And I also like light lines. Pr, to just limit this Max code size limit. I think we should do that. and I think we should decide this on Monday. But I can make this benchmarks or any tests before Monday. So yeah.

Ansgar Dietrichs: Sounds good. Thank you, Lucas.

Łukasz Rozmej: Yeah, I think we can also stand behind more or less the newer, newer version with the with the recent pr, we won't have the implementation for next week, though, probably because we don't have it yet, so I'm not sure what that was about. The Devnet.

Ansgar Dietrichs: So that would be specifically my concern. Like we really we want to launch Defnet 2 and Devnet 2 on Tuesday next week at the latest, and so that would have to include all the El sorry, all the elite.

Łukasz Rozmej: No? Then that needs probably Devnet. We need Devnet 3 for this, then, probably at some point.

Ansgar Dietrichs: Okay. So then maybe we go back. Then the decision 1st would be, do we want Devnet 2 to be the final scope of Fusaka. Yes or not? No, because then I think that would to me imply that if we say yes to that question, then this eap would be out of consideration, and we could talk about Julio's fallback eap if we are instead, saying, this is an important enough feature to delay freezing Fusaka, and we will have a devnet. 3. And we are fine with the fork launching 2 weeks later. That then that is a reasonable price to pay. If if clients think they can have the Ap. Ready for 2 weeks from now. I, personally, as I said before, I personally would very much prefer to freeze Fussaka scope today and not have a devnet. 3. But it sounds like, maybe people disagree.

Do we have opinion on whether or not to wait for Devnet 3.

EF Berlin: Do we think that 7, 9 0 7 implementation, and clients who do not have it right now will take like weeks? Or is it more like days. And one thing we could do is just include it today. If there's fine tuning we need to do by Monday, we can try to figure that out. Then, yeah, we could start the Devnet on Tuesday, let's say, then, with Who's ready? And if it's only a few more days, I think that's fine. If other clients need a few more days to get there. If it's gonna be like weeks, that's, I think, a different conversation.

Ansgar Dietrichs: Right. Could we go through the clients briefly and get an update on? Maybe I think at least Geth has already implemented this. So Geth would probably would I? My assumption would be immature. Obviously, then, they're the modifications made. They might not be reflected in the code yet, but I assume Geth would be ready very soon. Is that right?

EF Berlin: Yep, that's right.

Ansgar Dietrichs: How about the other clients? Any other clients, I mean, I can go through call calling you I mean, yeah.

Gabriel Trintinalia: This also has an implementation. 4, 7, 9 0, 7, without a code index code size. And I could hash code size. So yeah, we can. We can get on. It'll be nice to have like the 48 global eyes decided. And that'll be nice.

Ansgar Dietrichs: So what would be the timeline from the Besu side on? Could you guarantee.

Gabriel Trintinalia: We can get the branch ready tomorrow with 7, 9, or 7, as the current spec is. If we can, we can change as well depending on, like, how this Pr.

Ansgar Dietrichs: Right and just to clarify right as the spec is today, it does require you to know the contract size before you load it from disk. So that does require the extra data structure. Of course, you can always optimistically load from disk if you are comfortable, that that's not a performance set for you.

Gabriel Trintinalia: Yeah, well, we will implement the code, the the index, but not for the net, too.

Ansgar Dietrichs: Okay. Sounds good Julio. Do you know, from the Aragon side.

Giulio Rebuffo: Yeah. So we kind of started looking into it today. I don't think it's gonna be ready by Monday, is my is my impression. I think we might have it ready without the index, though.

Andrew Ashikhmin: I think. Well, Milan, maybe you you have a more accurate update.

Milen Filatov: Yeah. Hi, so I think we can have it ready for Monday. But that will be without the The code size. Index. And this is something that I think we need to measure properly. And Aragon and that will take more time. So it it. We can have it working. But with this security consideration in mind. I think that requires more time to investigate. We don't have any numbers right now. but probably it will be fine even without it.

Ansgar Dietrichs: Sounds good. Never mind. Did I already ask about the timeline that would take you for implementation?

Łukasz Rozmej: No, I'm not sure who would be implementing that. I think, Ben, so maybe he want to weigh in my guesstimate. We can have it for next week, but I won't specify the exact day. And again, it might be not the full with the all the database indexes, we want to add, but something workable for the Devnet. Ben, do you want to weigh in on that.

Ben Adams: Yeah, probably latter half of the next week.

Ansgar Dietrichs: Sounds good. Rath any any from from your side? Does does this do these general timelines make sense? Mid middle end of next week?

Roman: Yeah. So as I've said in the chat, we'll we'll have the implementation ready. We're gonna include it in dominant 2 gonna include it later. what I was more comfortable to be.

Ansgar Dietrichs: Sounds good. Then one last check, Matt. Maybe you're the best to ask. My understanding would be that even without the index the index is more like an implementation detail quote unquote. So basically, you could launch Devnet. And then even on the same devnet clients could switch out the implementation, move to that index structure, and that would not require Devnet 3. Launch. Is that right?

EF Berlin: Yeah, I mean, it's simply an optimization.

Ansgar Dietrichs: Okay and follow up question there. Given that, we did now reduce the size from the maximum size down to 48 kB. Basically, if it turns out that we just don't have time until the fork to actually move all the clients over to that index, the we are just basically at least the the worst case here would be bounded, because even without the optimization, you only have to load at most twice as much from disk. And so the there's a limit to how much users could could grieve the client. There. Is that right?

EF Berlin: Yeah, that's correct.

Ansgar Dietrichs: Okay, then. Well, any of you addressed 1. 1 more comment. There.

Ben Adams: Or do we have any tests for it?

Mario Vega: No, we don't. That's the problem. And my concern is the the open Pr also. Is that going in? Am I understanding that correctly?

EF Berlin: I mean, I would say we should do devnet 2, as it's specified, and then have this for Devnet 3.

Ansgar Dietrichs: So then I was. I was trying to get this to a shape where we can just wait with 2 for a few more days and launch it towards the end of next week. Can you then summarize? Okay, so so what is the Pr, and why that? Yeah.

EF Berlin: I mean, I like, I can make the changes to our implementation, and we can be ready. But you know we agreed on what Devnet 2 was supposed to be 2 weeks ago, so it feels a little weird to like constantly change the thing. but if clients want to do it like. It's not that big of a change. It's just at some point we have to do. The demo, too.

Ansgar Dietrichs: So then, okay, then, my general question. So so we still don't have tests for this yet. So there's some extra concern. It sounds like basically in this in this latest version, with with the 48 kB maximum, at least, the uncertainties are limited. So we have 3 choices. Now, we can either go ahead without it for Devnet 2, and then decide that we definitely will have a devnet. 3. That we will add this erp in at a later point we can launch just devnet 2 without it and remove it from the fork and not have it, or we can wait for 3 extra days have it be in Devnet 2, and launch Devnet 2 at the end of next week.

Again, my preference would be either of the 2 options that do not include a devnet. 3. Because I think a defnet 3 just adds a lot of extra delay to the fog. I'd just be curious what people's preferences are.

EF Berlin: I mean, we're gonna have a definite 3. That's a certainty. There's no point in avoiding it.

Ben Adams: I'd I'd want this pr in whatever it is. Devnet 2, because that's the the IP changes the one that has the 48 TB limit, etc. So we should probably put that in rather than have a transition on size.

Ansgar Dietrichs: So then So my proposal again. I don't want to be too many here. My proposal would be to add. 7, 9 0 7 in this modified form a simplified form, with with the 48 kB move it from Cfi, from Cfi to Sfi for Fusaka, and wait with Devnet 2, until at least 2 Els, or whatever threshold we think is reasonable, have it implemented at least in the unoptimized version sometime next week. This might mean a delay of 1, 2, 3 days for Devnet 2, and then launch it, and again, with the intention that there will not be another change of the El side. Even if we go to Devnet 3. Because of Pdas, that there will basically be no further changes to the El spec.

Is this? Does this generally sound reasonable, or is there a counter proposal in terms of the way to approach this.

Guillaume Ballet: So I can't raise my hands in the new zoom interface. But I I think, yeah. And on top of that, sorry. I'm also watching a baby by myself. So sorry for the screams in the background. But I think we should not do. 7, 79 0 7, simply because it's just bad code, Chunky. And we could have Code chunky in Amsterdam and solve all the problems. Yeah. So I'd rather have an eip for Glamsterdam that is doing code chunking. And then, since there's clearly a lot of questions about the parameters and everything, and no one has really implemented it. And we want a site index and things like this. I'd rather not have it in Fussaka 7,907, and then do the thing the correct way in Glamsterdam.

Ansgar Dietrichs: Okay, then let's simplify the decision. Just 7, 9, 0 7 in Fusaka. Yes or no. Guillaume has concerns and would prefer not to be included, can we? Matt obviously is in favor. Do we have other voices? Do we want to include this in Fusaka? Yes or no? I really would want to make that decision. Now, basically. it seems to me like reading chat that there seems to be a pretty strong majority opinion towards including it. Obviously, we do have to consents with the testing. So I think, including it does mean that we all agree that there is a reasonable chance that this might add some delays. It will already delay Devnet 2 by well, we haven't talked about Devnet yet. But basically.

yeah, but it sounds like we can make the decision any last chance if you want. If you want to speak up against including 7, 9, 0 7 into Fusaka, now is your chance. Otherwise I would say. okay. So then I would say, we will move, and we will include 7,907 in the 48 kB version in Fusaka. Then let's get back now to Devnet timing. So now now we're down to 2 choices, because now we can't. That simplifies it. So do we launch Devnet 2, as planned on Monday without this, and agree that we will need a devnet. 3. For this, or do we say we wait for a few days and launch devnet 2 next week, as as soon as we have enough clients ready.

photos and chat is prefers to launch Defnet 2 on Monday as planned, and delay this until Devnet 3. Matt also was in favor of definite 3. Stokes is in favor of waiting with definit 2. Roman and Julio. When you say Devnet 2 on Monday, I assume you mean, wait, wait for the Cfp. Until Devnet 3. Is this right? Or are you saying? On Monday we see whether we have enough clients to have it be part of Devnet 2 do it without. Okay, then it seems like other than Stokes. The majority seems to actually want to push this to Devnet 3.

Okay.

EF Berlin: Then. just to clarify. I was saying that we should launch Devnet 2 as soon as possible, and if that's Monday great, I do also think we should include 7, 9, 0. 7. But if that means.

Ansgar Dietrichs: I understand you. You were the only one, though everyone other than you said that we should launch. We should not delay Definite 2 for any cost, and we should.

EF Berlin: Without net. 2. Yeah.

Ansgar Dietrichs: Oh, the old one!

EF Berlin: I think we were aligned. There's never been a devnet, 2 spec. Without 7, 9 0, 7. So I was proposing that we implement 7, 9, 0. 7, as it was originally specified for Devnet 2, and the Devnet 3. We do the Pr. To make it 48. Kilobytes. It seems like most people, would rather just do the Pr with the 48 kB change. Now in that, too, it's not that big of a change.

Ansgar Dietrichs: I see. Sorry they're really not paying Tim enough of this job. This is complicated. Okay? Yes. So then, sorry. The distinction is actually not, as I described it before, the question is definitely, will definitely have 7, 9, 0 7. The question is, is it the original version? Or with this Pr. And the Pr. Would delay Devnet 2 launch by a few days. Sounds like in chat. People prefer to not delay Devnet 2. So then my understanding would be the majority decision. It would be to launch 7,907 with the old sorry to launch Devnet 2 with the old version of 7, 9, 0 7, and then have the new version be in Devnet 3. Is this majority opinion? Does anyone to speak up against that? I know, Stokes. You would rather just wait for the Pr to be merged and to be implemented by everyone or not.

Yeah, Tim really is the goat. the Pr, so fresh it needs more time. Okay, then we just make the decision. We will launch Devnet 2 on Monday with the old version of 7, 9, 0 7, and we'll add the updated version of 7, 9 0, 7 for a later devnet. 3. Does this work for everyone? Is there any client that will not be ready by Monday with even the old version of 7, 9 0. 7.

Ben Adams: No, the mind won't be ready with the old version on Monday.

Ansgar Dietrichs: Okay? Then the idea would be to launch the Devnet without, never mind initially, and have your guys join at a later point. Okay? Sounds good. So, Barnabas, that would then be up to you. Basically, once we have enough clients ready with the old version. So basically, Devnet 2 specs is the old version of 7, 9, 0 7, and we already agreed that the final version for Fusaka will be then including the Pr. So that means we will need a defnet. 3 at a later point that we can discuss at a future call. Okay, that concludes this section of the call moving on to the next eap. But none of the other ones are complicated hopefully. Eap 7,934 lp. Execution block size limit. Again, it's Cfi plan is to move it to Sfi, just to confirm. Is there any blockers on this? I understand that there's not perfect test cases for this yet. But

is there any blockers for having this in Sfi and in Devnet? 2. Okay. So then we will move. 7, 9, 3, 4 to Sfi, and it will be included in Devnet 2, and the last one. The last eap to make an inclusion on inclusion. Decision on is Eip. 7,939 count leading zeros opcode. Now this one is a bit out of process. This was not Cfid in the past. This was not proposed even in the past is my understanding. But it was included in the Berlin Belintop, Devnet 2. So they are still now. Some people would prefer would actually like this to still be in Fusaka. Given that it was in one of the Devnets. Do we have some a champion on the call that would want to make the case for that.

Ben Adams: Factorized.

Vectorized (Ben): Oh, Hi, okay, I think just all the client teams don't have any protests against like including it. Then I'm for it because it's like stateless. You can reason about it very clearly on on the worst case. Safety stuff.

Ben Adams: Do you wanna say? Why we want it in.

Vectorized (Ben): Okay. So let's say, if we don't have it in So okay, from like practical point of view the compiler will probably need one to 2 months to adopt it. L. 2. So probably need like 6 months to adopt it. And by the time, if everything adopts it. let's say we pushed against them. Then we mo will realistically only see it being used like in probably 2 2 0 2, 7, and for something with such a high impact to at foot. Okay, you can argue that it's our process. But yeah.

Ansgar Dietrichs: Right? Thank you. Obviously, on this eap, the main question is just process. My understanding is it's a very self-contained eap. Testing is already basically done for it. The problem is basically that it is only being proposed today, we kind of long closed Fusaka for newly proposed eaps. So the question is, do we want to overrule process here, to fast, track it, and include it, and have it be part of Devnet 2. I would really only do this in this case, if all the clients agreed, given that it is such an exceptional kind of process here. But if so, then of course, why not do it, Julio, you have an opinion.

Giulio Rebuffo: Oh, no, I just actually just wanted to say what you just said. But I mean, Aragon is pretty much in favor of inclusion. because it's easy and small. And yeah, it's already there.

Ansgar Dietrichs: Sounds good. Just, of course, to repeat one of the problems with these things is that it's, for example, it's in the opcode, so that it means it is taking up one specific opcode byte. There could be some incompatibility, say, with the L. 2 s. Or whatnot given, that we didn't give them any advance warning that we will now propose and then potentially immediately included. These things are never ideal, so I think in general, we should try to stick to the process in these things. But again, in this case, my understanding is that all the clients would want this. Is there any client team that has concerns or would prefer to not include, the cip into the into Fusaka.

Okay, then. Yeah, I will. Just, you know, in the absence of Tim Tim. I will just make the call to overall process here. We will add, and then immediately move to Sfi. This eip, and that means it will then also be part of Devnet 2. If my understanding it would be correct. Is this, is this right? Is there any reason to not to delay that. Well, basically, is, is everyone okay with adding it to Devnet 2. Yes, definitely 2. Okay, then let's go ahead with it and have the Cfp be part of Defnet 2 awesome. So that's the all the inclusion, non-inclusion decisions we had to make today sounds like we went with inclusion on all of these 4 points. That's great. Now, we have 3 more erps that are that that we have to talk about in the context of the of the fork. So the 1st one is 7, 9, 7, 5, which is the E 70 protocol.

My understanding is that Felix is on the call and could give a quick update on this.

EF Berlin: Yes, I can give a quick update on this. So this eip was created specifically to address the issue that beyond a certain estimate, the receipts. List of the block can increase so much that it will break the sync. And we have been discussing this eip for a bit. And I think, while it is not a change that requires a hard fork, we will still have to roll out this change kind of on the same timeline as Fusaka. Basically, it has to be in the Fusaka ready client releases in order to make sure that all clients are ready for gas limit increases after the fork, because otherwise there will be this implicit boundary in the protocol, where, for example, we cannot increase the gas limit beyond 80 million. Because of this condition.

So I am happy to answer any questions. But I want to say, upfront that this eip is still under development. And so, yeah. it is not fully ready by now.

Ansgar Dietrichs: Thank you, Felix. Julio had to end up.

Giulio Rebuffo: Yeah, I just want to specify that this is not really like, this is an IP that doesn't need to be in an offer, because it's a network. IP, so it's completely parallel to to Fuzaka from that perspective. But it is needed. If we want to go above 100 million, or at 100 million.

Ansgar Dietrichs: Yeah, just to clarify. So basically, we already agreed in the past that Eth 69 will be basically part of the Fusaka Fork spec meaning. Yes, it's not a an actual protocol change, but it is basically something we would want to roll out in. The client releases because the Fusaka fork is the last kind of natural point this year, where basically everyone will have to upgrade their clients anyway. So it would be quite desirable. So in the past, we decided that we are now open to having such a piece also in hard forks. Agree. If if we can't make it into Fussaka, the nice thing is here. We can always delay it. Then, just if we needed to actually go across a certain gas limit threshold, we just have to manually go through the effort of making sure that all the clients have been updated, so it would still be very nice if we could indeed get it into the

final releases for Fusaka and Ben. You had a comment.

Ben Adams: I don't. I don't think it's particularly a problem if it doesn't go into soccer. I mean, obviously we have to do it, but because of where it will occur which is syncing. The initial. Essentially, you're starting the client. You'll fail to sync. It's a good time to update anybody. Running will be fine. I don't think it's necessarily tied to the fork.

EF Berlin: And the problem is that we need this change in the server side. So this is kind of the the main issue with it. You. Yeah. not able to sync unless the server supported. So there has to be sufficient number of E 70 servers in the network in order to be able to sync after the fork if we chose to increase the estimate. So.

Ben Adams: That's a fair point.

EF Berlin: Yeah, that's good. general, like, with the network vips, there's like, we always just also do the testing a bit out of band. So it's not really, I mean, we can at some point, including indefinite. But so far there's no implementation of this vip. So there's also no way for us to include it, for example, in the definite 2 or 3 or something, but we will definitely include it at some point. So, yeah.

Giulio Rebuffo: Yeah, there is like, if we want to just put, if we really think we should should be going to the aspect, then there is also another eip. That is a bit ugly, that like is, it's simple to implement, which is just increasing the receipts message packets. Max, maximum size that solves also this problem. But it's not like the best solution. But that probably is much like that that's already spec, and that can be done probably tomorrow, and by Devnet, too. But I think gonna be fine anyway, like, I think we can, just this can be asynchronous. But yeah.

Ansgar Dietrichs: Okay, yeah. Then, I think, indeed, we can kind of given that. We have still a lot of agenda to go through. I think we kind of then all agree. This is something we would want to do, or maybe potentially still investigate alternatives, and that we would basically want to in the next few weeks. Kind of like get to a decision point on whether this will be in the client releases for Fasaka or not, but that we don't have to decide this and don't have to decide this for the Devnet scopes, because this is technically not a feature. Eip! Felix, does that sound right from your end?

EF Berlin: Yeah, I mean, like, I said, this vip is still under development, and we will have more input about it later. But I do think it's important to discuss it as a part of Fusaka, because we wanna be ready for the gas limit increases after that fork. So we will have to treat it as part of the Fusaka scope somehow. But it's not like it doesn't have to go through the same process exactly, you know.

Ansgar Dietrichs: Yeah, sounds good. So then, for now it's basically just notice to the different clients. Please keep track of this as it evolves, so that once it is stable it can be implemented as soon as possible, so that we keep the door open, at least to rolling it out with, together with Fusaka, but we can make a call on this on a future acd awesome. Thank you. Thank you, Felix. so that was that. Then we have Eip, 7,918, that is Andas's eip for the Blob Fee market. There's 1 last parameter we need to finalize there, Andas, are you on the call. Can you briefly give a summary of this? And if so, could we try to time box this a little bit just because we we don't have that much

time left.

Anders Elowsson: Alright. Hi, yeah. Do you hear me?

Ansgar Dietrichs: Yes, we can hear you.

Anders Elowsson: Yeah. Yeah. So we had a preliminary setting in the net. One. It was 2 to the power of 14, that is, 16,000, and we were also meaning to get back to to what exactly we should set it to. So I made a post. I can link it in the chat where where I go through the various considerations that we can have. So if we strictly want to ensure a functioning fee market, then 2 to the power of 12, that is, around 4,000 gas would be perfectly sufficient. But if we fully wish to short, and for the compute costs that blobs impose, then we would rather wish to go, probably above 214. So that's sort of the the context in which we should make a decision on what exactly we set this constant to.

If I reflect on what people have said when we're discussing with people, I would say that some people are in favor of racing and some lowering, and I would say the average sentiment has been around 2 to the power of 13, perhaps, or something like that. 8,000.

Ansgar Dietrichs: Sounds good. And just to give a little bit of context here for people listening. Basically, the idea is just that we want to make sure in the future that basically the minimum blob base fee is always set so that basically a 1 blob of a blob transaction would cost at least the equivalent amount of normal gas of that value. So currently, it's set to 16,000. So meaning that any one blob would cost at least the same amount as 16,000 normal gas. So that would, for example, mean that a 6 blob transaction would now roughly consume at the minimum, of course, roughly consume 120,000 gas, which is, of course, a meaningful raise over the normal flow of 21,000. But it's also not in the millions.

Is, that is, that the correct understanding.

Anders Elowsson: Yeah.

Ansgar Dietrichs: Okay, so that so.

Anders Elowsson: Yeah, posted a table here. You can. You can check out the table in the shelf which can be helpful in understanding. You know how we affect, you know the real price of of

Ansgar Dietrichs: I think, for now we can't go too deep into this. I think, as you said already, basically, the some people would want it higher. Some people would want it lower. To me, it seems I mean I personally would want it lower, but it also seems kind of at a reasonable level. Right now, I think you said maybe the the average between the different opinions could be one power of 2 lower. So basically 8,000 instead of 16,000. I think I heard you say.

Anders Elowsson: Yeah, yeah, essentially, having talked with around 6 people and if we go by that, yeah, we would end up at 2 to the power of 13, but I mean for me 2 to the power power of 12 to the power of 13, 2 to the power of 14 would be acceptable. And I I would I would say that that for me I don't know. 2 2 power 13 maybe is. yes, something. If if people feel that this is okay. There's some people that feel strongly about lowering it below and some higher. So maybe they should opine about it.

Ansgar Dietrichs: Yeah, Ben, I think you were on the side of wanting it higher.

Ben Adams: Yeah, I mean, I I think recurrent price is underpriced in terms of work done. But you know that that's fine. But so I think we should stick with the the current value rather than decreasing it further.

Ansgar Dietrichs: Okay.

Ben Adams: Especially especially since a lot of our recent motivations is trying to get things priced correctly rather than let's massively underprice everything.

Ansgar Dietrichs: So I just wanted to point out one. Maybe nuanced point here is that while it basically, the crp does give some sort of equivalent amount of gas. It doesn't actually count against the normal gas limit. So unfortunately, it does not in any way help limit the total compute load of a block, you can still have a block that uses all of the normal gas for a normal compute, and then the additional kind of blob gas for Kcd compute. So I think in in the sense it does not. Basically a higher value here does not help limit, compute, load, or help with scaling, or anything like that. Yeah, I personally feel again, feel slightly uncomfortable with at the current level, because it kind of does basically raise the minimum amount that a blob transaction, a full 6 blob transaction can cost by a factor of 5 or 6, which is a bit much to me for the original purpose of just trying to make the fee market more responsive. But also I don't want to drag this out too much. So, Ben, if you you said you. You prefer to stay at this value? I don't know. Do we have anyone else on the call with an opinion on this?

Anders Elowsson: Casper dropped 2 to the power of 12 in the shot, and Stokes dropped 2 to the power of 11. As preferences.

Ansgar Dietrichs: I see well, then.

Ben Adams: It's a it's a it's an extremely low value, anyway.

Anders Elowsson: Yeah, it's very low.

Ben Adams: Current, look.

Ansgar Dietrichs: So then given that all the other opinions would be below the current eap value. Would you be fine with going down one order of magnitude, one power of 2, and basically go with 2 to the 13 instead of what is currently in the Ap. 2 to the 14. As a compromise value. I mean, I understand, that's not fully principled, but just just to basically make a pragmatic decision here and and lock this info for saka.

Ben Adams: Yeah, sure.

Ansgar Dietrichs: Okay? Then I think again, in the in the spirit of just having this locked into Fussaka, because we've been discussing this for quite a while, and we can always revisit this in Amsterdam. Then I would say, we just finalize at 2 to the 13 and move and basically just have this value be be basically the the final one for Fussaka. Is that okay? With everyone.

Anders Elowsson: Yeah, as mentioned for me. Yeah. So I think that. yeah, it's I'm fine with either either of these options.

Ansgar Dietrichs: Okay, yeah, perfect. Then if, unless if you could change it to 2 to the 13 in the Ap. Then I think we can move forward with that and again. Sorry. I'm not super familiar with this process. Does this, then, mean that we will target this new value of 2 to the 13 for Devnet 2. Or does that make sense? That's how I would do it, at least. So yeah, then, if no one protests, then we will. Basically, we should have Devnet 2 already. Use this updated value of 2 to the 13. Okay, perfect. So then the last eap to talk about here for Fusaka is Erp. 7, 8, 9, 2. That is the Bpo fox. And they're specifically the question is about the per transaction blob limit, which is currently set to 6, I think, is my understanding. I think, Alex, you wanted to talk about this.

EF Berlin: Yeah, there was just a question that came up so I believe I forget the yeah, I forget where the Pr is on this. But essentially there was an introduction of this Max Pops per transaction constant. and it was to the Bpo eip, so that we could presumably change this. Per Bpo. we should just agree on how we want to do this. well, okay, there's a few things here. One is just what this number should be. I think we discussed some last week, and I think the most common preference I heard was just 6 per transaction. There isn't a question if we want to have this be part of the Bpo schedule, as in configurable within, like a named Hard Fork. My take is that it should not be. I think we might want to change from. Let's call it a named fork. So from like, say.

you know Fusaka to Amsterdam. But I don't really see the need to have this like fine grain control within Hppo to change this number.

Ansgar Dietrichs: Lucas.

Łukasz Rozmej: 2 things. Why, it's generally good to limit it. In the 1st place. So gossiping 72 blob transactions in the current vampole will be really hard. and that's 1 thing. And block building with such a big blobs is also hard to do it optimally, and it's easier to do it with a smaller number, I think 6 was chosen as a kind of extreme of a current state. 12 is also completely fine, for example, or even 18.

Ansgar Dietrichs: Shaba.

Csaba Kiraly: Yeah. So so my point is, it's again voicemail to these 2 things. What value and and how you want to set it. And I think I don't see any reason to go beyond what we have now. There are drawbacks of of having this larger than than 6. So so one thing is, I think we don't need more than 6, and the other one is, if we don't need really to change this, then then I would not make it part of the fast track, changing mechanisms which we call Bpo, so yeah. Why, why, we don't need more than 6. I think it it introduces a bunch of of issues. So then, we have a larger span from one to 12. Say, then you have to add more size, based logic to to handling this. We have pricing issues, whatever comes in. If we are increasing it. Then we have more problems on the on the

transmission of these, we would start to fragment it. But that kind of doesn't make sense, because we can already fragment it by not sending these big ones, and it just doesn't have a have a use to to make it large. We already amortizing the cost by 6 we wouldn't change that too much. And and I don't think the L twos need or other users, or whoever they are, they would need larger ones. So yeah, just simply let's just keep it as is. And I don't think we need a fast way of changing this, because we want.

Ansgar Dietrichs: Pen.

Ben Adams: Yeah, I don't. I don't think we need to change it to a high level one of the one of the issues is again, it will create a non functioning market because. essentially, you have tetris blob packing. So you might have over demand in terms of the number of blobs available, but they had 9 slots, and you have 2 7 blob transactions. Then you can only fit one of them. So you know, it's gonna or 2 6 blob transactions. You can only fit one of them in a 9 thing. So you're you're gonna get underfilled. So putting a lower limit on the Max size of blobs means you can include more blobs. Paradoxically.

Ansgar Dietrichs: Makes sense. Alex, do you maybe want to synthesize what that means? Decision, wise.

EF Berlin: Yeah, well, yeah. So I mean, it sounds like, everyone's comfortable with 6 as like a flat limit. So I would even suggest taking it out of the vpo config, and just having this be a parameter that we just have for all time. And obviously we could raise it in the future if we need to. So that might look like putting a Pr to the pure cip. I mean, I'm yeah. I'm flexible on where exactly it should live. But it sounds like we're fine with 6 and not changing right? I feel like computer dos. Eip is the right place to put this parameter.

Barnabas Busa: Well, this was adjusted to the block schedule Vip, because, the values are actually only represented in the blob schedule. So we're gonna need to make a Pr. To remove it from the blob schedule and then make a Pr. To hard code it in the curiosity, IP, I think. and then we should aim to do these changes for demonstrate or definitely 2. I really don't care because the values will not change. So we could actually just target them.

EF Berlin: It is this is actually a question. Should it be 2 or 3? Is this going to be a lift for people to in time for Devnet 2.

Barnabas Busa: It's a constant.

EF Berlin: Yeah, but they need to take out of the config. And then there's like, Vpo logic. They might want to change like, it's more a question of like if we want to launch Monday with Devnet 2 like, can we just make this change in time? It shouldn't make any difference to doing Demo 3.

Ansgar Dietrichs: And my understanding is that this is actually a Cl side question, right? Because this is a Cl. Oh, sorry.

Barnabas Busa: To see you. I can.

Ansgar Dietrichs: Then.

Barnabas Busa: On our test. Then.

Ansgar Dietrichs: Yeah, how do we make.

Barnabas Busa: That's the question.

Ansgar Dietrichs: Decision. Do we have Eldevs with an opinion on Devnet, 2 versus Devnet.

EF Berlin: I personally feel like it should go in Devnet 3. Like the more things small little things we add to Devnet 2, the like. More likely it is Devnet 2 is gonna take longer. We're talking about like 2 working days, and we've already discussed a few things that we need to sort out for Devnet 2. It like to me just makes like we're gonna have devnet 3. Let's just say we'll do this change in Devnet 3. I don't really see an issue with that.

Ansgar Dietrichs: Sounds good. And just to repeat this change that we're talking about is only moving it out of the Bpo parameter space into just like something that's fixed per hard fork, right?

Barnabas Busa: And then moving it into the IP, and making it a constant.

EF Berlin: Yes.

Ansgar Dietrichs: Okay, perfect. So then I would say, we do it for Devnet 3. Given that there seems to be limited opinions and opinions seem to point towards Devnet. 3. M. Okay. Perfect. Then.

Barnabas Busa: And we should also discuss who is gonna make the Prs for this.

Ansgar Dietrichs: Guess any. Thank you.

Alex Stokes: I said, Yeah, I said, I can do it.

Ansgar Dietrichs: Sounds good. Then let me briefly recap, and then hand it off to Barnabas to confirm. I have let me post this to chat, paste this to chat. This would be the these would be the diffs for Devnet 2 and Devnet 3. So basically for Devnet 2, and that we want to launch on Monday we would have we would include 7, 9, 5, 1 with the the r 1 curve with the old pricing. We will have 7, 9 0. 7. The old version included 7, 9, 3, 4, and 7, 9, 3, 9. Those were uncontroversial, just included, and the 7, 9, 18 parameter change to to the 13. Those would be the only changes. Well, the only basically, though this would be

for definite 2. And then we would wait for definite 3 with the potential pricing changes for the air, one curve with the new version for 7, 9 0 7, and the per transaction blocks moved into the Ps. Eip out of the Bpo. Does this sound right? And then, if so, Barnabas, can you confirm what that means for definite, true timing and everything.

Barnabas Busa: I think, 7, 9, 1, 8 parameter change to to the power of 13 should go to 3, because it's 1 of these repricing style vips, and I haven't even seen the Pr. For this, so I would just shift it to definitely.

Ansgar Dietrichs: Okay, that sounds good. Then we make that change. It's going to be out of definite 2 into Devnet 3. Other than that. Does that sound good? And then can you confirm the timings for Devnet 2.

Barnabas Busa: Yeah, other than that sounds good. And then if we have at least 3 years and 3 cl to launch on Monday, then we're gonna do that. Otherwise, we're gonna shift it by one day. and we're gonna reevaluate.

Ansgar Dietrichs: Awesome. I will also post all of these changes that I just listed out, including moving this, as Bannabas recommended, into the Discord channel after the call perfect. Then that seems like that would conclude the section on Fusaka, and we can move to Glamsterdam. Is there anything last on Fusaka that anyone wants to briefly talk about. Okay, then let's move to Amsterdam. we have 2 things to discuss, one Standalone Erp proposed, and one headliner proposal. and for the standalone. Eap. 7, 7, 4, 5. Zalt wanted to give a quick overview if you are on the.

Zsolt Felföldi: Yes. Hi, hello, everyone. So yeah, I will just do a quick introduction of this. We are not wanting to go into too many technical details. So I will try to share my screen. Yeah, let's just around this. I can.

Ansgar Dietrichs: Okay, I can see your screen.

Zsolt Felföldi: You don't.

Ansgar Dietrichs: I can. Sorry I can't.

Zsolt Felföldi: You can.

Ansgar Dietrichs: I can see your screen. Yes.

Zsolt Felföldi: Then present slash show. All right. It's just so that I remember my talking points. So what I want to present is this eip I've been working on since, like, I don't know last year, September. So, but actually, this is a problem I wanted to solve since a very long time. It's about like trustlessly proving log queries, and why I'm so interested in this, and why I think we should like pay attention to this like. Obviously, logs are important part of this, this whole ecosystem. And and this is just practically an unsolved problem to to really prove existence of logs, I mean, I mean, I mean the completeness of the of a response. And and even, I mean, even a full node needs to like, maintain external, like additional indexes to to do like like an efficient search. Because if we just want to scan all this like 500 GB of of receipts. Then it takes like, I don't know 20 min depending on the system to

to search in the entire 10 year log history. And yeah, there's also like other stuff on similar runs of problem. This transaction look up by hash. Also, we cannot really prove that a certain transaction is not canonical, because there's just no index of them in the consensus. And yeah, in general, I'm really interested in making basically everything trustlessly provable. Because let's just say, now, endgame is like like a popular term. And and if we really want to make ethereum as we wanted, then I think, okay, for a while, we can live with this, this suboptimal solutions. But in the end I think everything should be trustlessly provable. And 7, 7, 4, 5 does helps with that. It's it's something that obviously, it's a little bit more complex than the per block bloom theaters, but it can replace the the per block bloom. Theaters, which are totally useless now.

And this allows actually, really efficient lookup. And yeah, so so let me just quickly and high level what I how I wanted to achieve this and and what are like the the issues so like, like currently, what we have is a linear index which is obviously really cheap to append, very expensive to look up also like like a history expiry is easy to do. But yeah, it's like, absolutely too slow and too expensive to do, and also, like another approach, is like putting all the all these, these lookup events in a big merco tree, just like the State, which will pretty much cost the same as the state and logs. Were. I really like logs, by the way, so I think it's a really good idea that to have this this thing that contrast cannot access directly, but they are like significantly cheaper to add than state entries.

And yeah, so we also, for, like the lookup data structure, I wanted to just find something kind of in the middle. So what I came up with is is basically it's not a bloom theater anymore. It's still a probabilistic search structure. You can imagine it as as a as a series of sparse, two-dimensional bitmaps, which are then 3 hashed also into a fixed size lookup trees. And this whole thing is tree hashing kind of a smart, smart way. So that I mean updating this, this structure is is cheap, because the latest map that's being filled with with this, this probabilistic lookup entries is kind of small. So for maintaining the the consensus data so minimal data structure needed for consensus generation is something like 20 something megabytes. It's it's like very convenient, if it's into memory also, like. So it's obviously, if it's memory that's also cheap to add, and everything.

And but still, these these maps, because they have this is trees, because they have fixed size. They can organize in a way that look up for a single event, for longer stretch of blocks is is efficient, both the database exercise wise, but and also Merkel proof wise. So so, yeah, this is, this is basically a general general purpose hash lookup table. But it also gives a very an exact position of where this event happens. So it's also suitable for pattern matching with log address and topic and topic. But it's also suitable for looking up transactions and everything it. It can also give like exclusion proof if the if the event is not present. And and yeah, another important thing is that, unlike the per block bloom theaters. This designer puts a fixed number of events in each of these maps, and therefore the density of the maps is constant. Therefore positive rates are

consistent, and also it, they depend kind of on the type of search pattern, but they don't depend on like the gas limits. So like it's it's it's it's it works well with element scaling. And yeah, also, the there was, I mean, there's 1 key problem that the Bloomfielders didn't solve. And also I found it like like a major issue, that these lookup keys, and were very, very uneven distribution. So there are keys that happen like once in the lifetime of the chain. And there are certain keys that make up like more than 10% of certain block, like he had certain esc 20 token contracts. And yeah, like, wrapped eater, very popular and stuff like that. So

yeah, obviously, I also wanted to come up with something that will fit the scaling end game. And yeah, here, this is something that probably should be like, examine. So like like discussed further or or research further. But I believe it's most of the most of the work that has to be done as hashing. So yeah, I mean, we just have to. Currently, I'm I'm working with sha, too. But yeah. any other hash function will work. And just, yeah, I want to quickly like, grab this whole thing. So the so the point is that that for for a like 10 year, history lookup typically depending on the complexity of the of the of the search, it requires, like one to 5 MB of data which is significantly better than 500 GB. And even if we want to, at 1 point zk proof like individual lookups, it was obviously still easier to work with lot, less data.

if security can make the be. The individual proofs even cheaper than because, like adding the new logs is, is a lot cheaper at the block generator, but on X than then adding state entries, then it might be even viable option to just use logs and proof or logs. Yeah, it's yeah. not want to go into this too much. And this is my last slide. Yeah. So thing is that this thing already exists, I mean. in go ethereum. Currently the data structure exists. It's not in consensus, it doesn't calculate root hashes, and that don't generate remote, trustless proofs yet, but it does serve work when serving it get logs. And yeah, I already have some numbers. These are, this code is really not optimized yet. The database access patterns could be like way, but better so currently for like an entire 10 year history lookup, it's somewhere between a few 100 ms and like 5 seconds, maybe, if the disk is slow, that it can be more. But also, I think this could be optimized to like typically below one second look up for.

So it's it's and also with the remote proofs. So I already know the amount of data that needs to be accessed and proven. So also for a for a trustless proof or a light wallet. This would be something like 5, 10 MB of data. Worst absolute worst case, for like 10 years of history, but for like a last year, look up of a single wallet, it will be typically more like a few 100 kB. And yeah, so so the you can already look at like some parts of this. This implemented in goiter, master branch, or slash filter maps package also, we just set up a proof of concept single node devnet with Ethan and and nimbus guys. And also I have a have a proof of concept, prover and verifier for for remote query proofs.

This is still like working progress. And yeah, this whole.

Ansgar Dietrichs: Yeah, maybe in the interest of time, just jumping in because we only have 5 min left. And Ethan also wanted to give a presentation. If you could try to wrap up.

Zsolt Felföldi: Yeah, this is this is, I practically did. So, yeah, right now, I've I'm just so my current focus is just just containing the complexity and making it something that's that will be easy to implement. And yeah, I think this is pretty much it. I just wanted to introduce this this eip. And yeah, that's it. Thank you.

Ansgar Dietrichs: Yeah, no, thank you very much. Actually, I think it makes a lot of sense. Do we have comments on on the cip already? Luke.

Łukasz Rozmej: One comment from me is that it looked. I took a look this week, and it looked extremely complex for me. I didn't. To be honest, I didn't understand it correctly, even though I tried. And I know. So yeah, my, my like main potential reason is complexity. And okay, you you have here to improve specs, to to reduce complexity. Maybe that will help, and the second one is that it will compete with all the other things. So I'm not sure if we can prioritize it from Amsterdam. But that's a different problem.

Zsolt Felföldi: Yeah. complexity is definitely main challenge. But the consensus generation code is currently under a thousand lines. The eip is obviously not a easy read. But I'm willing, like, I'm working on that. So yeah. this is currently at this stage. And yeah, it should be made more approachable. Obviously.

Ansgar Dietrichs: Sounds good and just to clarify. I think my understanding is that this is not a proposal for a headliner for Glam Saddam. So more a general eip that then can be slotted in either Glamsterdam or future fork. If we have agreement that we want to do this, and if there's room. So this is not a headliner proposal specifically. and we only have 3 min left of official time. I'm sure we could run 2, 3 min over. But, Eaton, I'm not sure if you would still want to briefly talk about your headline proposal now, or if you then want to maybe push this to next acde up to you.

Etan Kissling: I don't know. I can. I can try but I need to be able to share my screen.

Ansgar Dietrichs: Yes, so if you could. N.

Etan Kissling: Can you end your screen share, and then I can do mine. so my proposal is about the 7, 9, 1, 9, the period. Let me see Mac OS is keeping me. I have to rejoin the call. Let me let me quickly do it.

Ansgar Dietrichs: If you have a link to share in the Zoom chat, I'm sure someone else could also share screen.

Etan Kissling: Okay, I'm back. And now this one.

Ansgar Dietrichs: Can see your screen.

Etan Kissling: You can see my screen now, right? Okay. So it goes into the same direction. That we essentially want to solve this problem that wallets have that today. It's very difficult to use an Rpc in a trust minimized way. That's a security problem, because the Rpc can lie to you by accident because they got hacked or due to misconfiguration software box today. There is this Eastgate proof Eip, that solves it like for the balances. And you can also run your own evm against it. But there are some things that just don't work. For example, Eth transfers. They are not part of the logs. You actually have to do a trace, call on every single transaction, and subscribe to an external indexing service. If you are in exchange, otherwise there is no way how you can find out that a user deposited to you that's affecting smart contract wallets.

Similar problem for beacon withdrawals. You don't really know in what block, you got a withdrawal, so you cannot really verify that easily. and the priority fees. Then the other problem is the completeness for the eth logs. Like. You can prove that a log happened. But you don't know if the server provided everything to you. And sometimes there are these bugs where logs are missing here on alchemy is one of the biggest providers. It took over a day, and during that time the wallets just could not access any logs, and you also cannot just fall back to an alternative. Rpc, because then you have to trust that Rpc. Right? Then another complaint that I get from wallets a lot is that the receipts are extremely inefficient to prove like there is no from address. There is no contract address, no authority. There is like this Rpc. Field of the log index within the block for which you essentially have to download all the receipts there is the gas used like on chain. We have cumulative gas used. But if you want actual gas used, you need to download the prior receipt as well.

and we also have this logs bloom field. and if you want to verify the logs bloom, you have to download all the logs as well. So it's kind of pointless to have it there because of this linear hash that we use for the receipts for transactions. It's similar that we have, like 3 different hashes here, and then a 4th one in the Cl based on the serialization. And the actually important hash transaction hash is not actually on chain, like the one that users use on our Pcs. All the time we don't commit to it because it lacks this mpt prefix and also the verifiers have to keep updating their code because of all these transaction types that have a lot of legacy stuff like we added these access lists, and the only reason why we have them is for users to unstock their funds on a

contract that did not respond well for gas repricing, so they need a way to lower the gas cost so they can still get their funds out. And we also have these fields that are added in the middle. So the verifiers have to keep getting updated for every new transaction type. And yeah, pure tries to solve these concerns. The minimal scope is like Schultz log index. That one gives us completeness proofs. It gives us the ability to efficiently search proofs within like one request. Then we also need to log all the internal East transfers. That's like extra information that we extract from the evm, but we don't have to change how the evm works or how it prices things.

And then, like, essentially, when we hash transactions, try root and receipts, try root. We use Ssc. and when we process an execution, payload or build one, then we use Ssc encoding. That's not that big of a deal, because nothing of the rest has to change like the guest, can still use its same transaction object internally, it has Rlp encoding, it has Json encoding. We just add a 3rd one ssc. Encoding. And when we interact over the engine, we use that and Ssc gives us also benefits. When, for example, we want block label access lists because we can just summarize it to the hashtree route, so we can drop the pre finalized access lists that are already executed.

and likewise for epbs and fossil, and they move stuff around on the Cl side. So adding the stability there for Ssc also makes sense. And yeah, like for the 3 core pillars of ethereum. Ux. l. 1. Scaling l. 2. Scaling. We improved the security. That means that now we can ask any Rpc. Not just trusted ones. That also means we can use anonymous access over like decentralized networks, such as Tor. Otherwise it's like accessing a website without https over Tor, where the exit node can scan you. and then we also get rid of those external indexers that are needed to track east transfers. So they're quite expensive. So getting rid of them reduces cost for projects this new log index from scholt it scales to arbitrary gas limit, including gigas. It will not become inefficient, like the current logs bloom.

we get better. Rpc. Latency that reduces cost. Further, it means that Ux is much faster, especially in a scaling world. Also, like these receipts. Networking change would be trivial with Ssc. Because it can prove inclusion more easily. and for the L. 2 s. Essentially, many of them are forks of l. 1 code, so they benefit by inheriting the changes, and it also means that when an L. 2 event has to be proven on l. 1, that it needs lower gas cost, because you don't have to send the full receipt anymore which can actually exceed the call data size. That was something that brought up from optimism back then, was also asking for. yeah, like, this is the proposal, like the pure is to focus really on Ux, so that it makes sense to use a theorem in a trust minimized way.

It's not a either, or it goes really well with the other headliners that have already been proposed. Yeah, that's that's my presentation.

Ansgar Dietrichs: Perfect. Given that we're already above 5 min, we probably don't have much time for discussion. If there's like one question or something, we could briefly take it otherwise, of course, the idea is, anyway, that these headliners will be discussed at a later date. Okay? Well, then, thank you. Eaten. And in general. Thank you. Everyone for this call. Quite happy. We have all the decisions now for 2, and more or less for Devin. 3. thank you all, and can't wait for Tim to take back over awesome.

Etan Kissling: By the way, thank you.

Ansgar Dietrichs: Thank you.

Jochem Brouwer: Great job. Thank you.

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