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?
Transcript
Ansgar Dietrichs: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.
EF Berlin:and also was discussed on acdt, and all the clients seem to be okay with moving ahead with 45 million.
EF Berlin: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.
Ansgar Dietrichs:Okay, then we can briefly go to the other inter point, which was the
Ansgar Dietrichs:Belintop devnet 2 that we ran at intop. Barnabas. Do you want to very quickly give an update of where that is at.
Barnabas:Sure. So the lunch barely interrupt
Barnabas:approximately almost a week ago now, 5 days ago, and we have 83% participation on the network right now.
Barnabas:There's a quick link. We have a few clients that are looking into some missed slots. I have been everyone already yesterday, and
Barnabas:they're taking a look.
Barnabas: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
Ben Adams: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.
Ansgar Dietrichs: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.
Ben Adams: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
Ansgar Dietrichs: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
Ansgar Dietrichs:Talk about the implications of of that in the next section.
Ansgar Dietrichs: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.
Ansgar Dietrichs:And next week
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Ansgar Dietrichs:decision today as well. And Barnabas, I think you also wanted to briefly talk about basically the ideal timeline for Devnet 2. And
Ansgar Dietrichs:but basically the plan would be assuming we can get all of these finalized today.
Barnabas: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
Barnabas:control European time.
Barnabas:This is assuming that we will have at least 3 years and 3 cls. Ready by then.
Barnabas:if we can get it by then, then we're gonna push the launch by today and see if
Barnabas: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
Ansgar Dietrichs:2 equally that already included 1 1 special case. That's that's a non, non,
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Ansgar Dietrichs:Sfi and included.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
stokes:So if wait, is there an echo.
EF Berlin:Yeah, alright, it's 4.
EF Berlin: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.
Ansgar Dietrichs: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.
EF Berlin: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:I think it makes no sense to change the price right now in a rush. We should actually evaluate what the same
Barnabas: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.
Ansgar Dietrichs:It's like piece. Okay, perfect.
Barnabas:Well, I I don't know whether party would have any other vips that they would need to get into for second.
Barnabas: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.
Ansgar Dietrichs:even just replacing your piece.
Ansgar Dietrichs:But
Ansgar Dietrichs: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?
Ansgar Dietrichs: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.
Carl Beekhuizen:it's that people don't like the fact that the precompile returns either one on success or nothing, if the verification fails.
Carl Beekhuizen:The reason we have this is this is what's deployed
Carl Beekhuizen: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.
Carl Beekhuizen:And you need to look at what the return type is.
Carl Beekhuizen: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
Carl Beekhuizen:on the return type.
Carl Beekhuizen:There hasn't been any like changes like this. This is what I presented on the last
Carl Beekhuizen:Acd. There haven't been any major changes in terms of.
Carl Beekhuizen:But my overall thoughts on this. And I think, yeah, it's mostly just an opinion thing on this.
Carl Beekhuizen: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.
Carl Beekhuizen: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.
EF Berlin: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
Carl Beekhuizen:some pushback
Carl Beekhuizen: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
Ansgar Dietrichs: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
Ansgar Dietrichs:any objections.
Ansgar Dietrichs: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.
Ansgar Dietrichs:Okay, perfect. Then one down, next one up, and next one up is a bit of a
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Ansgar Dietrichs:in general. This is a bit of a trick situation, and I'm not sure if maybe anyone could hear
Ansgar Dietrichs:has any prepared
Ansgar Dietrichs:remarks either for or against any of the 2 alternative eaps. Otherwise I can try to to summarize the situation.
Ansgar Dietrichs: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
Ansgar Dietrichs:no longer constant, but above 24 k. So basically, the point is that it raises the limit to above 24 k. And
Ansgar Dietrichs:if a contract is indeed above 24 k. Then
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Ansgar Dietrichs:somewhat nuanced implication that because you need to know the size of the contract to charge the right amount of gas.
Ansgar Dietrichs: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
Ansgar Dietrichs: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
Ansgar Dietrichs: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
Andrew Ashikhmin: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.
Andrew Ashikhmin: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.
Andrew Ashikhmin:But say, if it is the case
Andrew Ashikhmin:that it makes it harder. But maybe
Andrew Ashikhmin: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.
Andrew Ashikhmin: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
Derek Lee:So any kind of increase, preferably the one specified in 7 9 7 would be great.
Derek Lee:Appreciate it.
Derek Lee: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.
Derek Lee:and fix it.
EF Berlin:I mean, maybe one thing to respond to Andrew's point. I think
EF Berlin: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
EF Berlin: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.
EF Berlin: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.
EF Berlin: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
EF Berlin: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
Andrew Ashikhmin:then, and the other one, then 79, 54.
EF Berlin:I don't know if anyone from the team is here. I talked to
EF Berlin:some messages from Kev that he seemed like this was how he felt. But
EF Berlin: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.
Ben Adams:However. The issue, if we're spec freezing and going live on Monday is
Ben Adams:We? We don't know if any of the pricing is correct.
Ben Adams: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
Ben Adams:to.
Ben Adams:So if we want a hundred 1 million.
Ben Adams:300 million we don't know.
Ben Adams: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
EF Berlin:to have larger contracts. And this is like the right shape of the solution. And we need to figure out.
EF Berlin: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.
EF Berlin: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
Ansgar Dietrichs:fully implemented and benchmarked or basically, the benchmarking is just needs to be
Ansgar Dietrichs: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
Ansgar Dietrichs:keep the order of speakers? Julio.
Giulio:Yeah. So I actually also agree. 7 and 7 is in theory a better solution.
Giulio:however, it really depends. If you want to freeze the spec today, because if you freeze the spec today.
Giulio: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.
Giulio:and so you cannot go straight. 128 kB after Fuzac, anyway, in my opinion. And secondly.
Giulio: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
Giulio:depends, in my opinion, what the objective here area is. So if you want to spread the specs today? I I mean.
Giulio: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: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: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.
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
jochem-brouwer: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.
jochem-brouwer: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,
Łukasz Rozmej:we won't have the implementation for next week, though, probably because we don't have it yet, so
Łukasz Rozmej: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
EF Berlin:weeks? Or is it more like days.
EF Berlin: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.
Ansgar Dietrichs: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
Ansgar Dietrichs:I mean, yeah.
Gabriel Trintinalia | Besu:This also has an implementation. 4, 7, 9 0, 7, without a code index code size.
Gabriel Trintinalia | Besu:And I could hash code size.
Gabriel Trintinalia | Besu:So yeah, we can. We can get on.
Gabriel Trintinalia | Besu: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?
Ansgar Dietrichs:Could you guarantee.
Gabriel Trintinalia | Besu: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
Gabriel Trintinalia | Besu:depending on, like, how this Pr.
Ansgar Dietrichs:Right and just to clarify right as the spec is today, it does require you to
Ansgar Dietrichs: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 | Besu: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: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 | Erigon:Yeah. Hi, so I think we can have it ready for Monday. But that will be without the
milen | Erigon:The code size. Index. And this is something that I think we need to measure properly.
milen | Erigon: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.
milen | Erigon:We don't have any numbers right now.
milen | Erigon: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.
Łukasz Rozmej:And again, it might be not the full with the all the database indexes, we want to add, but something workable for the
Łukasz Rozmej: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
Ansgar Dietrichs:end of next week?
Roman:Yeah. So as I've said in the chat, we'll we'll have the implementation ready.
Roman:We're gonna include it in dominant 2 gonna include it later.
Roman: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
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Mario Vega:the open Pr also. Is that going in?
Mario Vega:Am I understanding that correctly?
EF Berlin:I mean, I would say we should
EF Berlin: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.
Ansgar Dietrichs: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
EF Berlin: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.
EF Berlin:but if clients want to do it like. It's not that big of a change.
EF Berlin: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
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Ben Adams:the IP changes the one that has the 48 TB limit, etc. So
Ben Adams:we should probably put that in
Ben Adams:rather than have a transition on size.
Ansgar Dietrichs:So then
Ansgar Dietrichs:So my proposal again. I don't want to be too many here. My proposal would be to add.
Ansgar Dietrichs:7, 9 0 7 in this modified form a simplified form, with with the 48 kB
Ansgar Dietrichs:move it from Cfi, from Cfi to Sfi
Ansgar Dietrichs:for Fusaka, and wait with Devnet 2, until at least
Ansgar Dietrichs:2 Els, or whatever threshold we think is reasonable, have it implemented at least in the unoptimized version sometime next week.
Ansgar Dietrichs:This might mean a delay of 1, 2, 3 days for Devnet 2, and then launch it, and
Ansgar Dietrichs: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.
Ansgar Dietrichs:Is this? Does this generally sound reasonable, or is there a counter proposal in terms of the
Ansgar Dietrichs:way to approach this.
Guillaume: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.
Guillaume: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs:yeah, but it sounds like we can make the decision
Ansgar Dietrichs: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.
Ansgar Dietrichs:okay. So then I would say, we will move, and
Ansgar Dietrichs:we will include 7,907 in the 48 kB version in Fusaka.
Ansgar Dietrichs:Then let's get back now to Devnet timing.
Ansgar Dietrichs: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.
Ansgar Dietrichs:photos and chat is prefers to launch Defnet 2 on Monday as planned, and delay this until Devnet 3.
Ansgar Dietrichs:Matt also was in favor of definite 3.
Ansgar Dietrichs:Stokes is in favor of waiting with definit 2.
Ansgar Dietrichs: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
Ansgar Dietrichs:do it without.
Ansgar Dietrichs:Okay, then it seems like other than Stokes. The majority seems to actually want to push this to Devnet 3.
Ansgar Dietrichs:Okay.
EF Berlin:Then.
EF Berlin: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.
EF Berlin:There's never been a devnet, 2 spec. Without 7, 9 0, 7.
EF Berlin: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
EF Berlin: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.
Ansgar Dietrichs:The question is, is it the original version? Or with this Pr.
Ansgar Dietrichs:And
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs:Yeah, Tim really is the goat.
Ansgar Dietrichs: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,
Ansgar Dietrichs:and we'll add the updated version of 7, 9 0, 7 for a later devnet. 3.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Ansgar Dietrichs: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
Ansgar Dietrichs:is there any blockers for having this in Sfi and in Devnet? 2.
Ansgar Dietrichs:Okay. So then we will move. 7, 9, 3, 4 to Sfi, and it will be included in Devnet 2,
Ansgar Dietrichs: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
Ansgar Dietrichs:Belintop, Devnet 2. So they are still now.
Ansgar Dietrichs: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
Vectorized (Ben):all the client teams don't have
Vectorized (Ben):any protests against like including it. Then
Vectorized (Ben):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
Vectorized (Ben):So
Vectorized (Ben):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.
Vectorized (Ben):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,
Vectorized (Ben):and for something with such a high impact to at foot.
Vectorized (Ben):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
Ansgar Dietrichs:kind of process here. But if so, then of course, why not do it, Julio, you have an opinion.
Giulio:Oh, no, I just actually just wanted to say what you just said. But I mean, Aragon is pretty much in favor of inclusion.
Giulio: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
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Ansgar Dietrichs:Well, basically, is, is everyone okay with adding it to Devnet 2.
Ansgar Dietrichs:Yes, definitely 2. Okay, then let's go ahead with it and have the Cfp be part of Defnet 2
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
EF Berlin: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
EF Berlin: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.
EF Berlin:So I am happy to answer any questions. But I want to say, upfront that this eip is still under development. And so, yeah.
EF Berlin:it is not fully ready by now.
Ansgar Dietrichs:Thank you, Felix. Julio had to end up.
Giulio: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
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Ben Adams: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.
Ben Adams: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.
EF Berlin:Yeah.
EF Berlin: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.
EF Berlin: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.
EF Berlin:So, yeah.
Giulio: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.
Giulio: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
Ansgar Dietrichs: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
EF Berlin: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
Ansgar Dietrichs:awesome. Thank you. Thank you, Felix.
Ansgar Dietrichs: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
Ansgar Dietrichs: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
Ansgar Dietrichs: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
Anders Elowsson:I made a post. I can link it in the chat where where
Anders Elowsson: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
Anders Elowsson:that's sort of the the context in which we should make a decision on what exactly we set this constant to.
Anders Elowsson:If I reflect on what people have said
Anders Elowsson:when we're discussing with people, I would say that
Anders Elowsson: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.
Anders Elowsson: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
Ansgar Dietrichs:blob base fee is always set so that basically a 1
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Anders Elowsson: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
Anders Elowsson:would be acceptable. And I I would I would say that that
Anders Elowsson:for me I don't know. 2 2 power 13 maybe is.
Anders Elowsson: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.
Ben Adams:But you know that that's fine. But
Ben Adams: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
Ben Adams: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
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Anders Elowsson: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
Ansgar Dietrichs: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.
Anders Elowsson: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
Ansgar Dietrichs:does that make sense?
Ansgar Dietrichs:That's how I would do it, at least.
Ansgar Dietrichs: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.
Ansgar Dietrichs:Okay, perfect. So then the last eap to talk about here for Fusaka
Ansgar Dietrichs: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
EF Berlin:yeah, I forget where the Pr is on this. But essentially there was an introduction of this Max Pops per transaction constant.
EF Berlin:and it was to the Bpo eip, so that we could presumably change this. Per Bpo.
EF Berlin:we should just agree on how we want to do this.
EF Berlin: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.
EF Berlin: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.
EF Berlin: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.
Łukasz Rozmej: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
Csaba Kiraly:so my point is, it's again voicemail to these 2 things. What value and and how you want to set it.
Csaba Kiraly:And I think I don't see any reason to go beyond what we have now.
Csaba Kiraly: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
Csaba Kiraly: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
Csaba Kiraly: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
Csaba Kiraly: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
Csaba Kiraly:and I don't think the L twos need or other users, or whoever they are, they would need larger ones.
Csaba Kiraly:So yeah, just simply let's just keep it as is.
Csaba Kiraly: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.
Ben Adams: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
Ben Adams:2 7 blob transactions. Then you can only fit one of them. So
Ben Adams:you know, it's gonna or 2 6 blob transactions. You can only fit one of them in a 9
Ben Adams:thing. So you're you're gonna get underfilled.
Ben Adams:So putting a lower limit on the Max size of blobs means you can include more blobs.
Ben Adams: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.
EF Berlin: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?
EF Berlin:I feel like computer dos. Eip is the right place to put this parameter.
Barnabas:Well, this was adjusted to the block schedule Vip, because,
Barnabas: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
Barnabas:and then make a Pr. To hard code it in the curiosity, IP, I think.
Barnabas:and then we should aim to do these changes for demonstrate
Barnabas:or definitely 2. I really don't care
Barnabas:because the values will not change. So we could actually just target them.
EF Berlin:It is
EF Berlin: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: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
EF Berlin: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?
EF Berlin: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:To see you.
Barnabas:I can.
Ansgar Dietrichs:Then.
Barnabas:On our test.
Barnabas:Then.
Ansgar Dietrichs:Yeah, how do we make.
Barnabas:That's the question.
Ansgar Dietrichs:Decision.
Ansgar Dietrichs: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: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.
Ansgar Dietrichs:M.
Ansgar Dietrichs:Okay.
Ansgar Dietrichs:Perfect. Then.
Barnabas:And we should also discuss who is gonna make the Prs for this.
Ansgar Dietrichs:Guess any.
Ansgar Dietrichs:Thank you.
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.
Ansgar Dietrichs:I have let me post this to chat, paste this to chat.
Ansgar Dietrichs:This would be the
Ansgar Dietrichs:these would be the diffs for Devnet 2 and Devnet 3. So basically for Devnet 2,
Ansgar Dietrichs: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
Ansgar Dietrichs: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
Ansgar Dietrichs: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
Ansgar Dietrichs:per transaction blocks moved into the Ps. Eip out of the Bpo.
Ansgar Dietrichs:Does this sound right? And then, if so, Barnabas, can you confirm what that means for
Ansgar Dietrichs:definite, true timing and everything.
Barnabas:I think, 7, 9, 1, 8 parameter change to to the power of 13 should go to 3,
Barnabas:because it's 1 of these repricing style vips, and I haven't even seen the Pr. For this, so
Barnabas: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: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.
Barnabas: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
Ansgar Dietrichs:Discord channel after the call
Ansgar Dietrichs: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.
Ansgar Dietrichs:Okay, then let's move to Amsterdam.
Ansgar Dietrichs:we have 2 things to discuss, one Standalone Erp proposed, and one headliner proposal.
Ansgar Dietrichs: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.
Zsolt Felföldi: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.
Zsolt Felföldi: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.
Ansgar Dietrichs: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
Zsolt Felföldi: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
Zsolt Felföldi: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
Zsolt Felföldi:to really prove
Zsolt Felföldi: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
Zsolt Felföldi: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
Zsolt Felföldi: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
Zsolt Felföldi: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.
Zsolt Felföldi:And this allows actually, really efficient lookup.
Zsolt Felföldi: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
Zsolt Felföldi:also like like a history expiry is easy to do. But yeah, it's like, absolutely
Zsolt Felföldi: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
Zsolt Felföldi: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.
Zsolt Felföldi:And yeah, so we also, for, like the lookup data structure, I wanted to just find something kind of in the middle.
Zsolt Felföldi:So what I came up with is is
Zsolt Felföldi: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
Zsolt Felföldi:3 hashed also into a fixed size lookup trees. And this whole thing is
Zsolt Felföldi:tree hashing kind of a smart, smart way. So that I mean updating this, this structure is is cheap, because
Zsolt Felföldi:the latest map that's being filled with with this, this probabilistic lookup entries is kind of small. So for maintaining the the consensus
Zsolt Felföldi: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.
Zsolt Felföldi:And
Zsolt Felföldi: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
Zsolt Felföldi: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
Zsolt Felföldi: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
Zsolt Felföldi: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
Zsolt Felföldi:it's it works well with element scaling. And
Zsolt Felföldi: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
Zsolt Felföldi: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
Zsolt Felföldi:certain block, like he had certain esc 20 token contracts. And yeah, like, wrapped eater, very popular and stuff like that. So
Zsolt Felföldi:yeah, obviously, I also wanted to come up with something that will fit the scaling end game.
Zsolt Felföldi: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.
Zsolt Felföldi: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
Zsolt Felföldi:that for for a
Zsolt Felföldi: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.
Zsolt Felföldi: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
Zsolt Felföldi:then adding state entries, then it might be even viable option to just use logs and proof or logs. Yeah, it's yeah.
Zsolt Felföldi: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.
Zsolt Felföldi:in go ethereum. Currently the data structure exists. It's not in consensus, it doesn't calculate root hashes, and that don't generate
Zsolt Felföldi:remote, trustless proofs yet, but it does serve work when serving it get logs.
Zsolt Felföldi: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.
Zsolt Felföldi:So it's it's and also with the remote proofs.
Zsolt Felföldi:So I already know the amount of data that needs to be accessed and proven. So also for a for a trustless proof
Zsolt Felföldi:or a light wallet. This would be something like
Zsolt Felföldi: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.
Zsolt Felföldi:And yeah, so so the
Zsolt Felföldi: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.
Zsolt Felföldi: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
Ansgar Dietrichs: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
Zsolt Felföldi:that will be easy to implement. And yeah, I think this is pretty much it. I just wanted to introduce this
Zsolt Felföldi: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?
Ansgar Dietrichs: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.
Łukasz Rozmej: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.
Zsolt Felföldi: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.
Zsolt Felföldi:this is currently at this stage. And
Zsolt Felföldi: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.
Ansgar Dietrichs: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 (Nimbus):I don't know. I can. I can try but
Etan (Nimbus):I need to be able to share my screen.
Ansgar Dietrichs:Yes, so if you could.
Ansgar Dietrichs:N.
Etan (Nimbus):Can you end your screen share, and then I can do mine.
Etan (Nimbus):so my proposal is about the 7, 9, 1, 9, the period.
Etan (Nimbus):Let me see Mac OS is keeping me. I have to rejoin the call.
Etan (Nimbus):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 (Nimbus):Okay, I'm back. And now this one.
Ansgar Dietrichs:Can see your screen.
Etan (Nimbus):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
Etan (Nimbus):that today.
Etan (Nimbus):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
Etan (Nimbus):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.
Etan (Nimbus):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.
Etan (Nimbus):Similar problem for beacon withdrawals. You don't really know in what block, you got a withdrawal, so you cannot really verify that easily.
Etan (Nimbus):and the priority fees.
Etan (Nimbus):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.
Etan (Nimbus):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?
Etan (Nimbus):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.
Etan (Nimbus):and we also have this logs bloom field.
Etan (Nimbus):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
Etan (Nimbus):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
Etan (Nimbus):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
Etan (Nimbus):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.
Etan (Nimbus):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.
Etan (Nimbus):And then, like, essentially, when we hash transactions, try root and receipts, try root. We use Ssc.
Etan (Nimbus):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
Etan (Nimbus):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.
Etan (Nimbus):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.
Etan (Nimbus):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.
Etan (Nimbus):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.
Etan (Nimbus):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.
Etan (Nimbus):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
Etan (Nimbus):also asking for.
Etan (Nimbus):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.
Etan (Nimbus):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
Ansgar Dietrichs:otherwise, of course, the idea is, anyway, that these headliners will be discussed at a later date.
Ansgar Dietrichs: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.
Ansgar Dietrichs:thank you all, and can't wait for Tim to take back over awesome.
Etan (Nimbus):By the way, thank you.
Ansgar Dietrichs:Thank you.
jochem-brouwer:Great job. Thank you.
Chat Logs
00:00:26
stokes:gm
00:00:26
Wei Tang:Replying to "@Ansgar can we als..."
It does contain some changes and I'd prefer to just make sure we're on the same page.
00:01:20
Ben Adams:bit quiet
00:01:29
EF Berlin:better?
00:01:31
Ben Adams:👍
00:01:32
Justin Florentine (Besu):we can hear you, but is suboptimal. better
00:02:40
Barnabas:https://dora.berlinterop-devnet-2.ethpandaops.io
00:03:13
Barnabas:Yes
00:03:39
Barnabas:fusaka-devnet-2
00:06:49
stokes:r1: ship it
00:07:26
stokes:Replying to "r1: ship it"
Cost should be higher
00:08:10
Barnabas:Replying to "r1: ship it"
Is there a PR for the cost increase?
00:08:33
stokes:Replying to "r1: ship it"
no
00:08:38
stokes:Replying to "r1: ship it"
We don’t know how to raise it
00:08:47
stokes:Replying to "r1: ship it"
The specific number
00:09:23
Barnabas:Replying to "r1: ship it"
looks like due to gas limit changes repricing will be required either way.
so a devnet 3 will be required either way.
00:09:51
Gabriel Trintinalia | Besu:Replying to "r1: ship it"
🚢
00:10:16
spencer-tb:Replying to "r1: ship it"
Devnet-3 please!
00:10:21
stokes:If we can get to an updated price Monday, that’s great
00:10:27
stokes:But lets not block inclusion in devnet-2
00:10:30
Luis Pinto | Besu:Yeah keep the price but revisit in other devnets
00:11:48
Kamil Chodoła:Perf wise doesn't seem like except modexp and log we need repricing for now
00:12:42
Som - Erigon:Why don't we re-price the heavy precompiles with a much higher gas target in mind?
00:13:09
Louis:Nothing returns when r1 fail or invalid signature
00:13:27
Barnabas:lmao
00:13:36
stokes:Consistency good
00:13:52
EF Berlin:make the chain beautiful
00:14:01
Barnabas:consistently unaesthetic
00:14:11
EF Berlin:Replying to "consistently unaesth..."
also known as beauty
00:14:15
stokes:Ship it
00:14:16
Barnabas:SENDIT
00:16:02
Potuz:I’d like to get the audio at the EF office room, something very funny is happening there
00:16:27
EF Berlin:Replying to "I’d like to get the ..."
just some weird stuff happening outside the window
00:16:32
EF Berlin:Replying to "I’d like to get the ..."
nothing to worry about
00:16:40
Potuz:Replying to "I’d like to get the ..."
Oh now please move the camera 😛
00:17:45
stokes:Can we get 7907 in place in time for devnet-2?
00:17:48
Barnabas:Thats a problem for future us.
00:18:00
stokes:Could make final call on ACDT, if someone wants to put in the work over next few days
00:18:14
Derek Lee:I would like to advocate for the inclusion of EIP7907 (on behalf of Arbitrum)
00:18:16
stokes:Replying to "Thats a problem for ..."
Metering is better than none
00:18:32
stokes:Replying to "Thats a problem for ..."
For zk we may need code chunking, but yeah it is a problem for tomororw
00:19:08
stokes:Main issue right now is just doing sufficient testing in time for spec freeze
00:19:25
Ansgar Dietrichs:Replying to "Main issue right no..."
spec freeze is today
00:19:43
stokes:Replying to "Main issue right no..."
Right and we don’t have full analysis in place :/
00:19:48
Derek Lee:What would it take (time wise) to do that analysis?
00:19:50
stokes:Replying to "Main issue right no..."
I do think we should find a path to bigger contracts though
00:19:56
Ansgar Dietrichs:Replying to "Could make final cal..."
that would mean delaying devnet-2
00:20:01
Derek Lee:And we are confident in a smaller increase, absent of these analyses?
00:20:56
Barnabas:I don’t think 7954 was considered anymore.
00:21:47
Łukasz Rozmej:Maybe we can do 7907 with some "small" limits for now like 64kb, and increase it in future forks later if needed?
00:21:47
Derek Lee:So is the current discussion EIP7907 or nothing at all (for contract size limit increases)
00:21:48
Barnabas:can we do the same for 7907 as 7951? SFI it and allow repricing?
00:21:58
Łukasz Rozmej:I'm afraid of that 256kb number
00:22:00
Derek Lee:Replying to "can we do the same f..."
Definitely in favor of this please
00:22:06
Derek Lee:Lets do 128kb then
00:22:30
Giulio:Maybe we should do 48kb
00:22:32
jochem-brouwer:I can make any benchmark test we like, just need to know what we want. We should increase contract code size lim
00:23:06
jochem-brouwer:7907 but now with 48kib lim? Instead of the 256kib
00:23:44
jochem-brouwer:👍
00:24:06
EF Berlin:my pr to 7907 based on feedback from 7907 https://github.com/ethereum/EIPs/pull/9910
00:24:07
stokes:We should freeze as much as we can
00:24:58
Barnabas:we can’t freeze the spec as we already discussed we need to reprice r1
00:25:14
EF Berlin:we are going to need a devnet 3
00:25:18
EF Berlin:that is certain
00:25:39
jochem-brouwer:Antwoord verzenden naar "my pr to 7907 base..."
I like this PR
00:25:47
EF Berlin:are we going to have the numbers by monday for r1?
00:25:54
stokes:“Freeze” today should mean final EIP set
00:26:13
stokes:Replying to "“Freeze” today to sh..."
Ok to have some details to sort out, as long as it isn’t a large number of such details
00:27:02
Ben Adams:Replying to "my pr to 7907 based ..."
fix linting :)
00:27:13
stokes:Ok to launch devnet-3 with the clients who are ready
00:27:18
nixo:Replying to "we are going to need..."
blog post is already out of date 😭
00:27:19
stokes:Esp if only a day or two for others to join
00:27:40
Potuz:+1 I think it’s absolutely fine to launch without all ready
00:27:49
EF Berlin:we can freeze fusaka and just say 7907 is going in
00:27:55
Barnabas:@lightclient promised me that geth will be ready by monday
00:28:16
Justin Florentine (Besu):"firm" >>>>> "freeze" because words mean things and freezing stuff isn't really in our culture
00:28:36
Gabriel Trintinalia | Besu:Besu has an implementation ready, without codehash index
00:29:39
Roman:reth has an implementation ready as well
00:29:53
Barnabas:@Ansgar Dietrichs this is the pr: https://github.com/ethereum/EIPs/pull/9910
00:30:51
Barnabas:erigon copying geth behaviour. They start talking to each other on ACD calls 😂
00:32:12
Barnabas:Sounds like geth/reth/besu should be gtg
00:34:07
Roman:devnet 2 as specified has 7907
00:34:30
milen | Erigon:Replying to "erigon copying geth ..."
@Barnabas this quite an unnecessary comment which shows you have very limited knowledge about Geth vs Erigon differences
00:35:17
FLCL:devnet-2 = Jun 30?
00:35:28
stokes:24th
00:35:43
FLCL:(it's suggestion)
00:35:50
Barnabas:Devnet 2 - Jun 23 - all EIPs
Devnet 3 - Jul 7 - All final repricings
00:35:56
Potuz:I advocate not delaying devnet 2, as long as there are 2 clients ready we should start that devnet
00:36:06
Gabriel Trintinalia | Besu:Launch devnet-2 as it is, and merge the lighthouse’sPR for devnet-3?
00:36:52
Barnabas:Replying to "I advocate not delay..."
welcome back to ACD btw 😄
00:37:23
Potuz:Replying to "I advocate not delay..."
Was promised by @ethDreamer (Mark) that LH was committing to 7732
00:37:28
Potuz:Replying to "I advocate not delay..."
lol
00:38:03
stokes:We can code chunk the bigger sizes
00:38:19
Łukasz Rozmej:@Guillaume do you have some code chunking spec examples?
00:38:20
stokes:I’d like to include in fusaka
00:38:27
Andrew Ashikhmin:Include in fusaka
00:38:30
Derek Lee:On behalf of Arbitrum, I would like to see this included in Fusaka
00:38:50
Potuz:Let’s not delay devnet 2 🙂
00:39:06
EF Berlin:🚢
00:39:21
Barnabas:Replying to "Launch devnet-2 as i..."
Matt has been rechristened
00:39:36
Potuz:Are there 2 clients that have this ready for Monday?
00:39:40
stokes:Devnet 2 as soon as clients are ready
00:39:42
Potuz:I think that’s the question
00:39:45
Roman:devnet 2 on Mon
00:39:50
stokes:Replying to "Devnet 2 as soon as ..."
As in only 2
00:39:53
Giulio:Devote 2 on Mon
00:39:53
stokes:Replying to "Devnet 2 as soon as ..."
monday/tuesday
00:40:01
Giulio:*devnet
00:40:04
EF Berlin:let’s do devnet-2 then
00:40:09
Roman:yes
00:40:10
spencer-tb:Can we push devnet-2 to Wednesday/Thursday? We can at least get some basic tests out for 7907.
00:40:17
Giulio:Do it without
00:40:20
Roman:on Mon we launch devnet 2 as is today
00:40:21
Giulio:Then add later
00:40:24
stokes:yes
00:40:25
Som - Erigon:7907 on devnet-3 completely
00:40:27
stokes:Launch on monday
00:40:36
Barnabas:Test in prod 😂
00:40:41
Potuz:This can be added to the same devnet without needing to run on dev3
00:40:42
Barnabas:who needs tests?
00:41:07
Potuz:+1 Alex
00:41:14
Sophia Gold:Sorry, what kimd of code chunking could we have in glamsterdam?
00:41:25
stokes:Replying to "Sorry, what kimd of ..."
There’s a previous EIP
00:41:28
stokes:That would be a good starting point
00:41:29
spencer-tb:Replying to "Test in prod 😂"
Game! Don’t want to delay
00:41:40
Trent:lol
00:41:53
Trent:Tim 🐐
00:41:57
Gabriel Trintinalia | Besu:Either way is okay, 48kb on Monday or original spec. Tests before devnet would be perfect
00:42:03
stokes:Replying to "Sorry, what kimd of ..."
But code chunking would be good for zk context
00:42:13
CPerezz:Replying to "Sorry, what kimd of ..."
https://eips.ethereum.org/EIPS/eip-2926 😄
00:42:24
Roman:stokes is not an EL dev
00:42:25
Guillaume:Replying to "Sorry, what kimd o..."
Yes that one
00:42:27
Barnabas:The pr is so fresh, it needs more time
00:42:31
stokes:Replying to "stokes is not an EL ..."
He is also misrepresenting me
00:42:33
stokes:Replying to "stokes is not an EL ..."
Its ok tho
00:42:34
Barnabas:so lets stick to devnet 2 spec as it was
00:42:41
Guillaume:Replying to "Sorry, what kimd o..."
Updated with the learnings from verkle
00:42:42
CPerezz:Replying to "Sorry, what kimd of ..."
I’d go for this and skip the EIP. The problem is that if this doesn’t happen in Glamsterdam it’s a double loss
00:43:51
Potuz:EL clients are easy to swap on a live devnet isn’t it @Barnabas ?
00:44:06
Sophia Gold:Replying to "Sorry, what kimd o..."
Thanks. Tbh I didn't realize there was a proposal to chunk still with the storage tries
00:44:06
Potuz:You can launch with the full staked set
00:44:09
Łukasz Rozmej:why do 7907 in devnet 2 if we need devnet 3? doesn't make sense for me.
00:44:21
ethDreamer (Mark):Replying to "I advocate not delay..."
Hell yeah lol
00:44:56
ethDreamer (Mark):Replying to "I advocate not delay..."
Currently working on a blog for why I’m supporting 7732 for glamsterdam
00:44:57
Potuz:It was proposed
00:45:09
Roman:it was proposed during prioritisation, but was ignored in the process
00:45:14
Giulio:In favour, it is already well-tested and in-devnet
00:45:50
Roman:reth in favor
00:45:52
Barnabas:We are not looking for potential issues, we are looking for why we want it in
00:46:05
stokes:Replying to "We are not looking f..."
Good for contracts
00:46:10
Giulio:Replying to "We are not looking f..."
Bitmaps
00:46:12
Potuz:Replying to "We are not looking f..."
It saves gas
00:46:14
Giulio:Replying to "We are not looking f..."
Makes bitmaps easy
00:46:17
nixo:https://eips.ethereum.org/EIPS/eip-7939
00:46:18
jochem-brouwer:Antwoord verzenden naar "We are not looking..."
gas golfing
00:46:23
Ansgar Dietrichs:Replying to "why do 7907 in devne..."
that was my understanding as well - but apparently it was already accepted for devnet-2 last acde
00:46:23
Roman:Replying to "We are not looking f..."
it counts leading zeros
00:47:15
stokes:I think the process here was a bit wonky but it does seem like we are ready to ship on all other fronts
00:47:17
Łukasz Rozmej:Replying to "why do 7907 in devne..."
we only protested the EIP (mainly due to 256kb limit) and it still got accepted… eh 🤦♂️
00:47:31
Roman:don’t set a precedent Ansgar, it WAS proposed in the past
00:47:44
Gabriel Trintinalia | Besu:Besu in favour as well
00:47:45
EF Berlin:Replying to "don’t set a preceden..."
it wasn’t proposed by the deadline though
00:48:09
EF Berlin:Replying to "don’t set a preceden..."
i (light client) am in favor of it, but it technically did not get proposed in time
00:48:48
Ben Adams:The current workarounds for not having CLZ are terrible; so for it
00:48:53
Barnabas:Devnet 3 spec sheet:
https://notes.ethereum.org/@ethpandaops/fusaka-devnet-3
00:48:53
stokes:Yes 2
00:49:03
Gabriel Trintinalia | Besu:Yes, devnet 2
00:49:40
FLCL:what new will be in devnet-3?
00:49:45
Potuz:Dropping early, @Ansgar Dietrichs you’re doing a great job, you seem to be stressed, it’s not an easy job, but you’re handling it perfectly without showing any prior bias nor influencing the discussion
00:49:51
nixo:https://github.com/ethereum/EIPs/pull/9906
00:50:28
stokes:Replying to "what new will be in ..."
Any parameter changes that aren’t ready in time for 2
00:50:49
FLCL:Replying to "what new will be in ..."
and https://github.com/ethereum/EIPs/pull/9906 ig?
00:51:04
Barnabas:Replying to "what new will be in ..."
that needs to be still discussed
00:54:51
Giulio:We cannot do 100M without it
00:55:57
Anders Elowsson:https://notes.ethereum.org/@anderselowsson/BLOB_BASE_COST
00:56:35
stokes:IMO we should just go for 2^11 so we have the smallest change possible to achieve our goals
01:00:19
Caspar Schwarz-Schilling:At a high level, 7918 was mainly chosen over a flat min blob base fee because it's more elegant to couple blob and execution fees to make sure blob basefee floor is high enough to ramp up quickly even when execution fee is very high. And then secondly, we can charge blobs something that reflects actual compute costs more accurately. When it comes to choosing BLOB_BASE_COST I would lean towards a value on the lower end, say 2**12. It fixes the ramp up problem and rules out pricing considerations.
01:00:51
stokes:Reposting 2^11
01:02:38
EF Berlin:i feel like we should stop changing devnet-2
01:02:56
stokes:Replying to "i feel like we shoul..."
This is one constant
01:04:07
Barnabas:I think what we need to do is talk to L2s and see if there is any actual benefit for them to have more than 6 ever
01:04:11
Barnabas:then we don’t even need this in a config
01:04:12
stokes:Replying to "i feel like we shoul..."
The more we can do now the better
01:04:30
Ansgar Dietrichs:Anders can you mute?
01:04:58
Anders Elowsson:Replying to "Anders can you mute?"
👍
01:05:43
stokes:Could even just have a single constant of 6
No need to have config data in the BPO schedule
01:05:52
Barnabas:Replying to "Could even just have..."
this was my original idea
01:05:54
stokes:Let me go find the PR im talking about
01:06:02
stokes:Replying to "Could even just have..."
To have it in, or not?
01:06:17
Barnabas:Replying to "Could even just have..."
not having it in the config
01:06:19
Francesco:+1 on not needing more than 6, and no need to adjust it all the time
01:06:21
Barnabas:Replying to "Could even just have..."
just clients hardcode this in their code
01:06:23
Raúl Kripalani:And increasing it further can complicate future mempool sharding techniques
01:06:54
Barnabas:Replying to "Let me go find the P..."
https://github.com/ethereum/EIPs/pull/9623
01:06:55
stokes:https://github.com/ethereum/EIPs/pull/9623/files
01:07:08
stokes:So it was put here bc we needed a way to express
01:08:16
stokes:Yeah I can do that
01:08:19
EF Berlin:LGTM
01:09:23
Csaba Kiraly:Limit of 6 or 7? I think (not sure) currently one can make TXs with 7 blobs. If so, maybe setting it to 7 would make more sense.
01:09:34
stokes:This is a mempool condition as well
01:09:43
Ben Adams:Replying to "Limit of 6 or 7? I t..."
6
01:09:49
stokes:So IMO cross layer (if not mostly EL scoped)
01:09:53
Csaba Kiraly:Replying to "Limit of 6 or 7? I t..."
OK, than make it 6.
01:10:04
Ben Adams:Replying to "Limit of 6 or 7? I t..."
Can currently do tx with 9
01:10:24
Csaba Kiraly:Replying to "Limit of 6 or 7? I t..."
Well, not in the public mempool.
01:10:25
Ben Adams:Replying to "Limit of 6 or 7? I t..."
but causes bad blob fills
01:10:38
stokes:I can
01:10:41
FLCL:it seems still useful to have an option to customize it later
01:10:41
stokes:Make the edits
01:10:43
Csaba Kiraly:Replying to "Limit of 6 or 7? I t..."
In the public mempool you are limited to 1MB
01:10:45
Brian:Base is self limiting to 3 blobs per tx now for more consistent inclusion with the current 6/9 params. The one major drawback of a small per tx blob limit is that empirically it is difficult to simultaneously propagate multiple pending blob transactions into the mempool given the current gapped nonce rules.
01:10:54
Ansgar Dietrichs:devnet-2
- EIP-7951 included, pricing as-is
- EIP-7907 included (old version, without PR)
- EIP-7934 included
- EIP-7939 included
- EIP-7918 parameter change to `2**13`
01:10:55
Francesco:Replying to "Limit of 6 or 7? I t..."
Given that the users here are a handful of L2s and it was 6 until a month ago, I wouldn't worry too much about fully preserving current functionality
01:10:55
Ansgar Dietrichs:devnet-3
- EIP-7951 pricing
- EIP-7907 new version
- per-tx blob max move to peerdas EIP
01:11:08
FLCL:not happy seeing this was decided in 3 minutes
01:11:19
Francesco:Replying to "Limit of 6 or 7? I t..."
Going back from 7 (or 9 depending on which value you care about, mempool or private) seems just fine to me
01:11:22
Barnabas:- EIP-7918 parameter change to `2**13` to devnet 3
01:11:23
EF Berlin:Replying to "not happy seeing thi..."
which part?
01:11:45
FLCL:Replying to "not happy seeing thi..."
remove blobpertx limit customization
01:12:09
stokes:Replying to "- EIP-7918 parameter..."
I will agree if it means devnet-2 sooner
01:12:11
Brian:As the blob target and limit increase, we may need a larger per-tx blob limit in order for the L2s to actually utilize the available capacity
01:12:13
EF Berlin:Replying to "not happy seeing thi..."
raise your hand 🙂
01:12:50
stokes:Replying to "As the blob target a..."
We can update the limit later
01:13:08
stokes:Replying to "As the blob target a..."
We don’t want to the per-txn number to go much higher as it becomes harder to deal w/ on the mempool
01:13:08
FLCL:Replying to "As the blob target a..."
that's what this option was designed for
01:13:45
Gabriel Trintinalia | Besu:Replying to "As the blob target a..."
This is only for Fusaka, isn’t it? you still can change for the bpos
01:13:51
Barnabas:Replying to "As the blob target a..."
couldn’t L2s just send blob txs in multiple multiple txs?
01:14:02
nixo:https://eips.ethereum.org/EIPS/eip-7745
01:14:07
stokes:Replying to "As the blob target a..."
They can, although e.g. nonce mgmt can become trickier
01:14:17
stokes:There’s a fairly high-dimensional tradeoff space to navigate here
01:14:57
Barnabas:Replying to "As the blob target a..."
then maybe this decision shouldn’t taken so lightly
01:14:58
Gabriel Trintinalia | Besu:Replying to "not happy seeing thi..."
This is only for Fusaka, isn’t it? you still can change for the bpos
01:15:06
Brian:Replying to "As the blob target a…"
Base does this now with 3-blob transactions. We tried using 1 or 2 blob txs but it's too difficult to get these propagated through the mempool consistently. This is likely due to EL rules - for example Geth will drop any blob tx with a gapped nonce.
01:15:41
Barnabas:Replying to "As the blob target a..."
@Brian do you see base ever needing more than 6 blobs in a single tx?
01:15:50
Csaba Kiraly:Replying to "As the blob target a..."
I’m working on reviewing those rules, but that’s also an important protection mechaism
01:15:56
FLCL:Replying to "not happy seeing thi..."
not using schedule but with new eips
01:16:02
Csaba Kiraly:Replying to "As the blob target a..."
So we don’t want to just “bump the numbers”.
01:17:45
Csaba Kiraly:Replying to "As the blob target a..."
@Brian One thing I wanted to signal is that there are inherent cons of bumping maxBloblsPerTx.
If you see also advantages, we can definitely look into them.
01:17:46
Brian:Replying to "As the blob target a…"
We see Base needing more blob throughput. We're not strongly opinionated about the number of blobs per tx as long as we can consistently post these to the L1. This means avoiding issues with block packing as well as mempool propagation issues. I could see a future where we only send 1 blob per tx if the mempool allowed
01:17:56
FLCL:Replying to "As the blob target a..."
12blob tx can allow to increase l2 throughput by x10. Specific tool was designed to allow it later in safe manner. The tool has been just removed in 3 minutes
01:18:38
Sina Mahmoodi:An important point about EIP-7745: it improved log search speed in geth by 20x (that’s in addition to making log query response provable)
01:18:40
Etan (Nimbus):https://xcancel.com/sina_mahmoodi/status/1930565142183387627
01:18:47
EF Berlin:you’re saying 1 blob per tx isn’t allowed by txpool?
01:20:39
Brian:Replying to "As the blob target a…"
It's not practical if we need to post >1 blob per block. If we submit multiple transactions to an L1 node (or cluster of nodes), as they propagate through the mempool any tx could get dropped due to inclusion rules.
01:21:23
Raúl Kripalani:Replying to "not happy seeing thi…"
increasing the limit can produce high variability in mempool bandwidth requirements. more blobs per tx actually harms tx submission to inclusion latency (takes longer to propagate). and can result in spiky shard sizes going forward (if we shard the mempool)
01:21:27
EF Berlin:Replying to "As the blob target a..."
okay i see, the issue is more the gaps that occur during propagation
01:22:28
Brian:Replying to "As the blob target a…"
By the time the tx makes a few hops, the probability of a nonce gap increases dramatically
01:25:37
FLCL:such effects will be revealed with way higher blob count. And the idea is to invest further in more effective tx pool
01:26:42
Trent:I hit "allow”
01:28:14
nixo:https://ethereum-magicians.org/t/glamsterdam-headliner-proposal-pureth/24459
01:33:38
Wei Tang:Doesn't seem we have time any more, so I'll move my EOF headliner discussion to next call. Anyway, just want to briefly talk about my perspective for the small new changes since it was proposed in Fusaka.
01:33:39
Csaba Kiraly:Replying to "As the blob target a..."
We want to increase overall system level blob throughput, and we should also increase the “per-user” throughput. The two are related but slightly different goals.
The current mempool protection mechanisms were not designed for a case where one user sends 50 blobs per slot into the mempool (especially if these are not sent through the same entry point). I would say we should work on these, rather than just bumping the parameter. I think we can achieve better results this way.
01:34:10
Gary Schulte:thx Ansgar
01:34:15
stokes:Thank you!
01:34:24
jochem-brouwer:👍👍