Mario Vega:Awesome. Thank you so much.
Transcript
Mario Vega:Hello, everyone. Welcome to Okra. Depth testing number 43. Today is July 7, th and we have
Mario Vega:4 points in the agenda plus other comments that I want to touch upon. That people added recently today
Mario Vega:to the issue, I'll share the link where you want to take a look.
Mario Vega:Here's the link. And yeah, we can get started with Fussaka. This is the 1st topic. So I guess the 1st thing about Fussaka would be definite 2. And I see Barnabas is
Mario Vega:has joined. Do you have any any updates there.
Barnabas:Yeah, sure.
Barnabas:So has been on finalized during the whole weekend. Just late last night he managed to get back into finalization.
Barnabas:I had to exit a few validators.
Barnabas:This is due to the fact that Nimbusia was missing too many slots. And
Barnabas:it was just a bit easier to try to finalize without them being online. There are still a few validators left for them and also had some validators exited.
Barnabas:We are currently at 75% last time I checked. So we should be good to go. Prism had some sinking bugs
Barnabas:that they are looking into right now, and also Tech, who had some nodes that were stuck but that was probably due to just insufficient memory.
Barnabas:So yeah, lighthouse
Barnabas:also had a bit of issues with the Cgc values earlier on. But I think that has been all resolved.
Mario Vega:Thank you. Do we need any updates from the clients now? Of the open issues?
Mario Vega:And which ones did you say that need updating.
Barnabas:So the major issues on Nimbo side was the status 3, 2
Barnabas:on Taku side. It was the thinking bug due to insufficient RAM that has been resolved. We just bumped the RAM of the Jvm. A bit
Barnabas:the. But the team is still looking into possible syncing issues. Prism
Barnabas:had the thinking issue during the non finality that has been resolved with a restart on during finality. So
Barnabas:we might need to do another one or 2 non finalization scenarios where these bugs can be caught again.
Barnabas:But right now they cannot reproduce it locally.
Mario Vega:Okay, it makes sense.
Mario Vega:With this in mind. Okay, thank yes. Matthew.
MatthewKeil:Yeah. Lodestar. We also found an issue lower level in a Liberty update that got highlighted during onfidelity. But we're getting that resolved.
Mario Vega:Cool anyone from prism or Teku that wants to give an update, or
Mario Vega:and maybe we expand on on the issues.
Manu:Yeah, I can.
Manu:So for prism, yeah. So Barnabas, try to to reboot the node prism, node ring and finality, it seemed. And the node was stuck.
Manu:Now the network is finalizing again. I cannot reproduce the issue. I mean just rebooting the node. Just
Manu:we solve the issue when and the nerd is
Manu:up to the asynct, up to the chain, up to the tip of the chain. Now, which is a good and a bad thing. And so, yeah, I cannot reproduce the issue on the net. Now, I try to reproduce the issue on courthouses. So just basically, I created a small network.
Manu:And I created an finalization, and I cannot reproduce the issue as well. It thinks everything sinks normally.
Manu:That's all I have to say about this issue.
Mario Vega:Thank you. Anyone from Teku or Lighthouse wants to give an update.
pawan:Yeah, I can go for lighthouse.
pawan:Yeah, we had a bunch of sync issues initially, like Barnabas mentioned. And some issues with updating the Cdc values, the Cdc values thing has been fixed the sync issues we have started fixing them.
pawan:But yeah, I think like, in part of fixing them. It was like we figured that
pawan:the some of the issues were related to some clients giving us
pawan:like when we requested them for call columns with data columns by range request. They were sending us empty responses when they did not have the data.
pawan:which is like,
pawan:sort of malicious behavior, because once we received valid blocks for that range. But we did not receive valid columns for that range, and we tried to
pawan:couple those 2 together. There was an issue, basically, because the columns were invalid at that point. So it was good sort of it was almost sort of like a malicious test case where
pawan:peers were returning us invalid values. And we had to recover from that. So
pawan:we had. We basically changed our sync to accommodate for that where we downscore peers that don't return us correct data column by range values. So once we started doing that, and we eventually started down scoring and dropping those peers. Our sync has improved, but we still have, like some stuff to do on sync. So
pawan:like when I when I was testing this, the clients that I noticed
pawan:where not returning values, sometimes the numbers.
pawan:sometimes teku and grandine as well.
pawan:So
pawan:yeah, I think this was like a good test for us as well, because we are sort of handling the malicious case now and able to recover from it.
pawan:So yeah, just letting other clients know as well that they are returning
pawan:empty values when they shouldn't be.
pawan:Yeah. And we are continuing on improving sync at this point.
Mario Vega:Thank you. A couple of things on the spec side. Do we need any updates? Do you have any any? This consideration of returning malicious columns in the spec. Does everybody know.
pawan:So sorry. What do you mean?
Mario Vega:Yeah, aspect test is what I mean. Yep.
pawan:Oh, okay, I think it's hard to have
pawan:spec tests for it, because, like, there is no set way to recover from this like at least on lighthouse. We basically eventually downscore the peers and eventually end up banning them. So I think this sort of case would be hard to test on a spec test, but I'm not sure.
Justin Traglia:I agree I don't. I don't think we have a spec test for this, and I don't really know how we would.
Mario Vega:Cool. Thanks. Oh, okay, then, on the on the side of the clients that we're returning this invalid responses, I think you, said Nimbus and Grandine and Teku.
Mario Vega:Is there any stance on whether they should?
Mario Vega:I don't think they should be returning this. But is there any comments on those clients. Maybe there's a
Mario Vega:a reason why they were running like this.
pawan:And and like just to note also that some of this, like, I'm not completely sure that the other clients were also wrong in some of this points, because we could have been requesting
pawan:data columns per range for
pawan:for a range that is, before their earliest available slot. But like some of the some of the peer ids that I manually checked.
pawan:those did have like a earliest available slot like we were making a request for some for a range that was after the earliest available slot, so like it could be an issue on lighthouse side as well. But like this is just
pawan:very rough manual testing. So just noting that as well.
Mario Vega:Got it. Thank you. Okay.
Mario Vega:jumping onto there. There's a comment on the chat by Barnabas about the backfill implementation.
Mario Vega:Do we want to go into that topic.
Mario Vega:Any any anybody, any comments from the clients?
Mario Vega:About backfill?
Mario Vega:Or if you have more context, paranounce that you want to add.
Barnabas:I think everybody knows what I'm talking about.
Manu:For prisma still in progress, not yet done.
pawan:Yeah. Same for lighthouses.
MatthewKeil:Same for lodestar.
Mario Vega:Teku and Nimbus. Any updates.
Mario Vega:And one question from baritosh is whether there's any blockers on implementation that you have found so far, or it's just mainly
Mario Vega:time that is required.
pawan:Think for lighthouse. We
pawan:yeah. But I think for lighthouse. We had to make some changes in the database schema. Also to sort of introduce the earliest available slot and continuously update it to be able to send it to peers. So
pawan:like we had to get that done 1st before actually doing the backfill. So that took a little bit of time. But I think this week we are focusing on the actual backfill implementation.
pawan:hoping to get it done soon.
MatthewKeil:Yeah, for us. It was just the complexity of getting a debug for the Devnet but we'll try to attempt it, I would guess probably next week. I don't think we'll get to it this week.
Manu:Prism. I don't know. I ask internally to the team. I will get back to you as soon as I have a
Manu:don't swear.
Mario Vega:Thank you.
Mario Vega:From the other teams. Any updates, if not, that's okay. We can follow up on the next call
Mario Vega:alright.
Mario Vega:Any other topics on Devnet 2 that have to be touched.
Mario Vega:mainly asking because whether we want to start asking whether we want to schedule them in the tree, but I don't. I don't feel that's the case.
Mario Vega:Barnabas, do you have any opinion on the planetary or.
Barnabas:I've shown you
Barnabas:we need. I I think we should have a very stable devnet 2, before we even consider scheduling definitely.
Barnabas:There's so many bugs to iron out and jumping on to definitely right now would be bad, in my opinion.
Parithosh Jayanthi:I guess at that point. Did we actually fix the bugs in Devnet, or did we patch them with validator changes.
Barnabas:It's all patched. None of them are fixed.
Parithosh Jayanthi:Do we have a look what bugs need fixing them.
Barnabas:That's the thing that Manu mentioned that during finality he could not reproduce the bug.
Barnabas:So we're gonna need to do another non priority test.
Parithosh Jayanthi:Okay. Sounds good.
Mario Vega:All right. Thanks, and maybe it's time to bring another topic that was brought up on Acde, which is the 4 Kd issues. I believe, right? So we had this discussion on Acde that we wanted to introduce eap 7,910.
Mario Vega:I'm gonna link it in the in the chat.
Mario Vega:And basically, this is it underscore, configure, endpoint? Thank you. Do. We have an update on that from the teams? And I can, I can start with with testing side. We have
Mario Vega:a new command to test this.
Mario Vega:Basically, we're just lacking the configuration now. But this is this is something that we have to address with the Itband Ops team. But this is simple enough, but the main idea is that we are going to be testing this for all testnets and devnets inside of East.
Mario Vega:And the main problem that I notice while implementing this on.
Mario Vega:on, on east is that it doesn't include the fork. Id, if I understand correctly.
Mario Vega:and I think this was the culprit from from the issue that we found on acde
Mario Vega:So with that in mind. What's the status on the teams, and opinion also on on the inclusion of this eap?
Mario Vega:Does anybody have time to implement it?
Barnabas:Could we actually add fork id. To 79, 10.
Mario Vega:I mean, I think it should be a simple change. Maybe either add it to either underscore config or add another endpoint, but I don't have a preference over either. It's just a matter of how easy.
Barnabas:Why would we need a different endpoint.
Mario Vega:Yeah, I'm not sure it's just it's just just an idea. Yeah.
Barnabas:I personally feel like it. Config would be the perfect place for fork ids as well. So I would just extend the 79, 10 with a new field for fork ids, and just list it as a as an array.
Mario Vega:And one comment from Besu is that the
Mario Vega:current hash in eap is the 4 Kd. I'm not sure to be honest. Does anybody have the precise answer to that
Mario Vega:is current cache in the eap, the same as 4 kd.
Mario Vega:I don't think it is because it includes the precompiles, which I don't think 4 Kd. Ever considered.
Mario Vega:My guess is that it's not, but anybody else has.
lightclient:I went fork id is the same as what.
Mario Vega:There's a there's a configuration hash in eap 79, 10 hit config response.
Mario Vega:But I don't think it matches for Kd.
Mario Vega:So the idea is, you have.
lightclient:Yeah, I'm not familiar with that one. But fork Id definitely doesn't have the precompile.
lightclient:All it does is accumulate the fork block number in the genesis hash.
Mario Vega:So if you want to also verify fork id using it underscore config, we need to add another field right.
lightclient:I'm not sure what information is provided by that endpoint.
Mario Vega:Okay? And Gabriel mentioned that they they cannot.
Mario Vega:The 4 Kd change to the eap.
Mario Vega:Awesome.
Mario Vega:Other clients. Does any? Does anybody else started to implement it. Underscore config.
Mario Vega:Never mind, get Aragon, please.
FLCL:This week.
milen | Erigon:Yeah, we added this in Aragon today, actually. But we will need to add the fork id in there as well.
Mario Vega:Thank you.
Mario Vega:I will wait until for adding 4 Kd, until we have the eap change. Just so we have the same format.
Mario Vega:Yep.
Mario Vega:Okaysu, never mind. Already have something does get, have any updates on on this endpoint?
Mario Vega:Yeah, yeah, thank you.
lightclient:Have not implemented it.
Mario Vega:Okay, thanks.
Mario Vega:Who am I missing anyone from? Reth?
Mario Vega:Thank you.
Mario Vega:Alright. So it seems like,
Mario Vega:most of the teams are planning to implement this week, and we're gonna add the fork id
Mario Vega:into into the same endpoint, and we'll have a and best. We'll have a Pr for the eip.
Mario Vega:Cool.
Mario Vega:Okay.
Anders Kristansen:That's right.
Mario Vega:I think we can move on. And the next issue, just give me one second.
Mario Vega:All right. Yeah. So the next point. And we touched upon this last week. So I just brought it up to this week is the gas limit testing updates. Does anybody know about the benchmark updates that we had in the previous week
Mario Vega:that could give an update.
Marcin Sobczak:Bye.
Mario Vega:See Joachim. And yeah, okay, thank you.
Marcin Sobczak:Yes, I can say about our results from our gas benchmark
Marcin Sobczak:tool. And generally, we have, like the bottleneck is modex. There is a proposal to to increase the pricing aggressively 3 times. But there is still one edge case scenario for gaff and argon it's with based on modulo equal 22 Byte and exponent
Marcin Sobczak:64 bits.
Marcin Sobczak:And from what I know, clients are work working to optimize it because there is a strange issue. And we have scenario with exponent, 64 bits, which is slow and with 65 bits it's like 50% faster. So it's probably some implementation detail which should be optimizable.
Marcin Sobczak:and except of modex, we we found that our test case for
Marcin Sobczak:point evaluation precompile were broken Alexi delivered me like the valid input data for it. And right now we see that all the clients are operating at about 32 megas per second, which is like close to minimal requirement for for increasing that limit to 100 million.
Marcin Sobczak:So it wouldn't be a blocker, but it would, it will be for anything above 100 million. And there is also probably some issue with Ref. But we are not sure it's
Marcin Sobczak:like. On our dashboard they have only 9 megas per second. But when we took a look on the raw scenarios. It's like on August limit, except 60 million, and they are performing like other clients. And there is must be some edge case at exactly 60 million gas limit where they're slow. And
Marcin Sobczak:yes, it's reported to to Rev. Guys. And they are taking a look and
Marcin Sobczak:and probably for Fusaka we like. There is nothing to do about this pre compile. But we need to be conscious that going above 100 million gas limit it will be a blocker for going above it
Marcin Sobczak:before the the next fork.
Marcin Sobczak:And I think it's it's all about the updates from agony testing.
Parithosh Jayanthi:Yeah, maybe to continue we also have the bloat net effort. So we have about one and a half times the state of Mainnet, and I'm working on setting up a public network there. And once we have that, we'll run a bunch of sync tests and a few tests like with Zen contract, so we can get a baseline on how it look like look like with one and a half times the state of Mainnet.
Parithosh Jayanthi:And once that's there, we already have the spamming tools in place to continue increasing the state, and we can observe how stuff degrades over time. But that should be ready, probably in the next day.
Mario Vega:Thank you. I see there are a couple of open prs for repricings. I shared one in the in the chat.
Mario Vega:Does this need to be merged for Demo 3,
Mario Vega:I think, is your Pr or, yeah, modex.
Marcin Sobczak:Yes, so probably if if we don't want to
Marcin Sobczak:So if Kevin probably are not able to optimize enough without changing libraries, and we don't want to like it's not probably not good for for in general to to use the same libraries in our clients, so if they will keep they they once probably they're not able to optimize
Marcin Sobczak:enough to not be a blocker for 100 million. So in this case we just need to. To to increase the general price prices, and in the current shape of this eap only till
Marcin Sobczak:the 8% of the calls are affected. If you want to to increase the pricing, then 100% of calls would be affected anyway. So if we if we do it, then, in my opinion, we should do it like significantly so. This Pr is proposing like free xing it.
Marcin Sobczak:And but there is still this one at case issue. Which they are taking a look at. Because it will be still too slow even with reacting. And there is like not not a good way actually to
Marcin Sobczak:to solve it on, on like pricing
Marcin Sobczak:area. We would need to to increase like minimal gas to to 1,500 or something like that. So it would would be great to to take to take a look at it and and try to optimize because it should be optimizable.
Marcin Sobczak:Yes, and I think that's it. Do. Do you have some more more like more questions about it, or some specific areas.
Mario Vega:No, not really. I just wanted to move the conversation on on whether we have to merge or not. Marius.
Marius:Yeah, I can. I can speak on the problem, is that
Marius:But yes, it's optimizable. The problem is that it's
Marius:that we are depending on the Go Standard Library. So we would need to optimize the Go Standard Library
Marius:and the problem with that is that
Marius:yes, we can do it, and we've done it before, like we we
Marius:upstream. Some changes to the ghost in that library, but it takes us like.
Marius:yeah, kind of 2 releases of the Standard library for this to trickle down into the client.
Marius:And so, yeah, it's it's it will take a long time until this.
Parithosh Jayanthi:Just also surfacing a discussion. I think we already agreed to merge this pr in as per acd last week, so is there any blocker to go ahead with doing that.
Parithosh Jayanthi:I think we wanted to wait to see if we can do some outreach and make sure that no one's affected, and if that is true, then we would go ahead with merging right.
Marcin Sobczak:Yeah. So from my side, we can merge it as it is. I generally need to update or the descriptions, and, like the other parts of the of this eap. But yes, like it will not affect like the the equation. Just the cosmetic
Marcin Sobczak:side of of this. Pr, so I I will do it like, you know, I can do it in another one. And like one last problem with this reacting is that we we are. We know that we have one case which is still too slow even after that. And yes, would be great to
Parithosh Jayanthi:Just to confirm, but it'll it's still just too slow for going over 100 million right.
Marcin Sobczak:Yes, I don't remember the exact number but there is a scenario scenario which will be below 30 mega gas per second for sure.
Marcin Sobczak:It's right right now, like, without free acting. It's at 18 mega per second. Okay, I will do a quick calculation, and I can, I can give you the exact number in a moment, just don't want to to block the conversation right now to calculate it.
Parithosh Jayanthi:No worries. We can also do it. Offline later, if you want. That's perfectly fine.
Mario Vega:Yeah, I think Tim mentioned that the feedback he got is minimal impact. So we should be ready to go on merging this. So if you can just put together the change that you want to do the cosmetic changes, and we can move it from draft to open, so we can review it and merge it.
Mario Vega:That would be great. Yeah.
Marcin Sobczak:Effort can do it.
Mario Vega:All right.
Mario Vega:Awesome. Thank you. Good.
Mario Vega:Any other discussions on gas that were left out from Acd that we have to touch today.
Mario Vega:If not, we can move on to the next topic.
Mario Vega:Which is Peer Das. And there's just one comment on
Mario Vega:on the on the issue that is worth discussing whether the Cls will be trusting blobs from the El or not, and reading from the comment in the issue is that lighthouse and nimbus currently they do verify the blobs that come from the Els. But Prism and Teku.
Mario Vega:They trust them.
Mario Vega:and there's no response from both star. So is there anything that we have to discuss there? Do we have to like reach upon agreement whether this has to
Mario Vega:happen the same way across all clients? Or is this something that is okay. If it's like implementation details. Francesco.
Francesco:Yeah. So we definitely don't need to reach agreement. The reason we're talking about it is just that it's kind of a it makes a big difference to to decide to trust them or not, because, if you like, when you're building a block, let's say you get 50 blobs, or whatever. Now you have to verify all of them in the critical path of building a block and same thing for forget blobs.
Francesco:So it's kind of I don't know, like a few 100 ms extra that you don't really need there. So I think it would be best if we just agreed that there's no reason to be to be doing this. And all clients just drop this extra verification, because Al has already verified all these things.
Francesco:And yeah, like the yell could also give you an invalid payload. So it's which you cannot verify. So it's it's not that, really. This is protecting you even from a malicious yell, if that's something that we're worried about for some reason. So yeah, on the side of like, do we need to all have the same implementation? No, but I think it would be best to just not have this verification. I think it's it's quite expensive.
Mario Vega:Yeah. Pardon.
Parithosh Jayanthi:Yeah, maybe just to follow on that. I also didn't particularly get. Why, Cls are reverifying. To begin with. And I wanted to understand if there was some particular reason, mainly because I also agree. The El in general, like in general, the engine Api has a trusted assumption like you expect that the El behaves non maliciously.
pawan:Yeah, I think for us, like, the engine get blobs method like verifying stuff on that like, at least get get blobs. v. 1. We mainly did it because it wasn't that expensive, at least with 6 blobs, whatever we have right now.
pawan:But yeah, like others pointed out with the
pawan:with pdos, it will get more expensive, and it doesn't make sense to do it. But like for the
pawan:main
pawan:block production flow, I think the reason we do it is because we want to verify Kcg verify blob blobs that we receive from the builder. It is not mainly for local block production, but it is for verifying
pawan:builder blobs.
pawan:But like, because both of the flows are like the local block production and the builder flow are sort of interlinked, and it wasn't as expensive before peer does. We just did it for the local block production flow as well.
pawan:But we would also probably avoid doing that for paid us.
Mario Vega:Francisco.
Francesco:Yeah. Same same comment as Barnabas in the chat. I don't really get even in the builder flow. Why, it would be important to to verify them again, for the same reason that the builder could also just give you an invalid payload. And I mean, you literally don't even have the payload, so you don't even have a chance to verify it.
pawan:Yeah, that is a good point.
pawan:Yeah, I think we'll talk a little bit more about this internally.
pawan:Yeah, that's a good point that like we cannot verify the payload at all, so it doesn't make that much sense.
Mario Vega:Cool. Thank you. Okay, I think that's that's all. Unless there's comments from Nimbus, who also trust the blobs.
Mario Vega:If not, Sunnyside has comment. They wanted to add,
Mario Vega:standardized el metrics across Els for Demon 3. Would you care to expand on this?
J Sunnyside Labs:Yeah. Hi, so we have already been discussing for a while while back. And
J Sunnyside Labs:we now got ethereum repository for it, and then I just made a Pr for
J Sunnyside Labs:get blob speed to metrics. So if you guys
J Sunnyside Labs:have some time, then please have a look, and hopefully we can get it done by Devnet 3. Then we can get get some useful data for it.
Mario Vega:Thank you.
Mario Vega:Alright. Cool.
Mario Vega:Any other comments on Peerdas updates.
Mario Vega:They want to touch upon this this this call.
Mario Vega:All right. If not. There's 2 last comments on the issue that might be important to take. Take a look. So the 1st one is by Spencer.
Mario Vega:he's proposing to increase the gas from Clc. Of growth
Mario Vega:from 3 to 5 or 8. But he mentions there's no no current benchmarks. But yeah, if you want to do you want to raise comments on this, or expand on the idea.
spencer-tb:Hey, guys? Yeah, I guess. I just, I just figured because we don't have benchmarks for Cov yet, and because we probably want to finalize it for sake spec very quickly.
spencer-tb:and it might be nice, or at least safe, just to increase the gas cost from 3 to
spencer-tb:slightly higher and
spencer-tb:and kind of like with the our kind of like with our one, we can always reduce it again, and
spencer-tb:Amsterdam.
Mario Vega:I think, yeah, okay, thank you. I think the
Mario Vega:appropriate way would be if we can raise an appear in the eip
Mario Vega:for it to get get approved and merge.
Mario Vega:Do you want to take care of that? Or.
spencer-tb:I guess. If everyone is happy with that, or if anyone doesn't want to do that, then yeah, I mean, we can also wait, I guess, some days and get benchmarks, but just to finalize for cycle faster. This would be the only the alternative.
Mario Vega:Thank you. Ben.
Ben Adams:I
Ben Adams:I don't. I don't have any objections if people want to go for it. But also I just like to highlight that
Ben Adams:unlike. Say so at the moment. It's priced the same as add.
Ben Adams:but it's a single stack operation, so only pops one value, add pops 2, and
Ben Adams:add is then multiplier, quite complex instructions, and it's fairly simple.
Ben Adams:But I don't wanna block and increase it. That's what people want to go for.
spencer-tb:My gauge is that it will be well, yeah.
spencer-tb:it'd be be much more efficient than that in general. But yeah.
spencer-tb:I just it. It feels safer. But
spencer-tb:yeah, if if there's no objections, I can open the car.
Mario Vega:Yeah, I think barnabas mentioned that it should be a better way to go if we open a Pr and then proceed to add benchmarks to it. So I think that's that's a good way to go.
Mario Vega:So basically open a Pr in the eap and then just comment on it with the benchmarks. We wait for approvals, and then we can see if if we get merged.
spencer-tb:No sounds good. Can I just jump in really quick as well? And I guess
spencer-tb:suggest adding, like benchmarking requirements to the process for eips.
spencer-tb:and before the C. 5, because I guess the we've had our one
spencer-tb:and also Clc. When you upload a new precompile to me, it makes sense that we have some kind of benchmarking requirements before we
spencer-tb:add new precompiles or uploads in the future.
Mario Vega:Yeah, this is a great suggestion.
Mario Vega:I I guess the place where we can put that is in the
Mario Vega:yeah. Tim mentions it before. Sfi, I think I think I agree to be honest. We have a better benchmark infrastructure right now that we than we have
Mario Vega:a few months ago. So I think it should be it should be. It should be safer to to impose this this requirement.
Mario Vega:And Tim mentions that open a Pr to 77, 23
Mario Vega:aip which basically jails. Sorry specifies the the steps to follow before Sfi and something. So yeah.
Mario Vega:yeah, I think we should, we should definitely open up here for this and and mention that we requires benchmark benchmarking to be done before Sfi
Mario Vega:and Yay.
Mario Vega:yeah, if you want to go ahead. I think it should be a simple, simple peer. Yeah, cool.
Mario Vega:Okay. Thanks. Great. And one last comment from Ben.
Mario Vega:do you want to make a case for for this on your comment of eap, 7,983.
Ben Adams:Yeah. So there's a proposed. There's a there's a new eip from Tony to
Ben Adams:change the transaction cap to 16 million rather than 30 million.
Ben Adams:It seems to make sense to
Ben Adams:and bring that forward to Futaka rather than no wait and wait an entire work to bring that.
Mario Vega:I shared the pr in the chat.
Ben Adams:Yeah. And I, I mean that also resolves issues with, for instance, the Zen contract
Ben Adams:that we were looking at.
Mario Vega:Yeah, thanks. I think I guess my main concern with this is that this is basically a new aip, and I don't know how late in the process, are we? I I think, pretty relates or.
Ben Adams:I've I propose changing it into modification of the current one.
Ben Adams:because we're introducing the we're already introducing the transaction cap.
Ben Adams:and there was discussion whether it should be lower at the time.
Ben Adams:But since we didn't have any analysis.
Ben Adams:how much we could lower it to.
Mario Vega:I see. Is there an a Pr. Open for this specific one for eap? 78, 25.
Ben Adams:Yeah, put it in.
Mario Vega:Yeah, yeah, okay.
Ben Adams:Yeah. So at the moment we, we have the transaction cap going into Fussaka at 30 billion.
Ben Adams:Yeah. And then, rather than
Ben Adams:have a new eip cellar in the next fork.
Ben Adams:We might as well, Laura in this world got it. Got it?
Ben Adams:Change the existing one.
Ahmad Bitar | Nethermind:It's it's just a constant change like we're introducing transaction gas limit cap already in this fork. So if we know that the cap that we're sitting in this fork is not the correct cap. Why wait until next fork?
Ahmad Bitar | Nethermind:Like, if we are, gonna do it, let's do it right from the beginning.
Mario Vega:Yeah. Makes sense makes sense. So the author of this pr, is Tony. I don't believe he's here. But it wouldn't. It would be nice to
Mario Vega:to ping him to, in my my sense is that we.
Toni Wahrstaetter:No, I'm here.
Mario Vega:And just open a new oh, sorry, Tony! Do you want to expand on? Why, the new eap? And rather than.
Toni Wahrstaetter:Yeah. So
Toni Wahrstaetter:so I was creating this new Ap, just because I thought Fuzaka is already frozen and 7 MA. 25 might not get.
Toni Wahrstaetter:Yeah. The gas limit kept low enough where we should get it to.
Toni Wahrstaetter:It feels like for polarization, also for distributed proving. It might be beneficial to lower it even further.
Toni Wahrstaetter:And I did some quick analysis. I have not published it yet, but basically, even if you lower it to 16 million.
Toni Wahrstaetter:only 0 point 3%.
Toni Wahrstaetter:The transactions will be affected.
Toni Wahrstaetter:And 90% of them is Xen. So it's essentially yeah. Putting a cap on Xen.
Mario Vega:Got it. Got it? Yeah, I think the
Mario Vega:consensus seems to be that we want to make a Pr for 78, 25, instead of making a new eip.
Mario Vega:Is that correct? Does anybody have any objections to that?
Barnabas:My argument is that this is kind of like a repressing change. So it's not a significant
Barnabas:protocol change. That's why I feel like this could still make it into Fussaka without any big issue.
Ahmad Bitar | Nethermind:I remember Matt from Geth. Had issues with transaction cap as a whole, but I don't know if he would have an issue with lowering it even further.
Ahmad Bitar | Nethermind:Matt.
lightclient:Yeah, I mean, I think ultimately, my fear is something that's not happening on Mainnet today.
lightclient:I wonder like what the trickle effect will be if L. Twos are adopting l. 1 directly where there's a lot more activity with accounts, abstraction bundling.
lightclient:I mean, if this is what people want to do then.
lightclient:obviously not going to stop. It seems all right. They can always split the transaction into multiple transactions. My only comment on this more broadly is that when we make changes, even though this is kind of a repricing, it's not an issue for clients to do. But when we make changes at this point in the development cycle. We don't really give the community any time to give feedback on this. And this is something that could be
lightclient:pretty impactful to people. And yeah, you know, we've done this analysis. There's only a handful of transactions that are impacted. But there could be people who are building companies or projects based on this these assumptions. And so
lightclient:if we make this change today, then there's only like maybe one month where there's someone could voice that this is going to impact them negatively.
lightclient:That said, I don't think we should stop. I don't think we should avoid doing this. It's just something that we need to consider. It's not always that it's easy for us to do. It's also that it needs to be legible and accessible for the community to put feedback on.
Mario Vega:Any response to that comment. I think it's reasonable.
Mario Vega:Yeah. The the downturn effects.
Ben Adams:I mean most most examples that we've we've looked at, including what was it? OP stack upgrades?
Ben Adams:they can be split across multiple transactions.
Ben Adams:I think it makes it messier because
Ben Adams:I think IP stack needed about 9 million or something.
Ben Adams:So it was sort of raised and discussed previously when we were
Ben Adams:talking about lowering it initially, trying to find the the right value. And then we went with
Ben Adams:leaving at 30 million. Because.
Ben Adams:yeah, that was an urgency to find the value. And it seemed like, we'll just leave it.
Ben Adams:However, with the issues it runs in
Ben Adams:that we've discovered. If we want to go to higher gas limits.
Ben Adams:and it's better to split the transactions that are dismissible. Anyway.
Mario Vega:Okay?
Mario Vega:So I think the consensus would be that we can go ahead and open the Pr.
Mario Vega:To the to the original eap. Tony, is that is that is that okay for you.
Mario Vega:Do you want to open the Pr, and then we can start the discussion there.
Toni Wahrstaetter:Yeah, that's fine.
Mario Vega:Cool.
Mario Vega:Alright. Thank you.
Mario Vega:Any any other comments any other topic that we should touch today?
Marcin Sobczak:I will. I would like to say a bit more about modex. If I can.
Mario Vega:Yeah, sure.
Marcin Sobczak:So I did some rough estimation, and
Marcin Sobczak:after 3 x in the price, our worst case should be at about 31 mega gas per second. So it would be like close to our minimum requirement for 100 million gas limit, but would be great to test test it instead of estimating so I would like to ask all your client teams
Marcin Sobczak:to push this change to the performance modex the branches so we will see the results on the dashboard like the exact results, not estimations
Marcin Sobczak:especially important for Jeff, and as like, it's most interesting how it will look on
Marcin Sobczak:for them.
Mario Vega:Thank you.
Mario Vega:Any objections to this?
Mario Vega:all right. Any other topics. Does. Anybody else wants to write raise today?
Mario Vega:Cool. And Mario comments that Mario's comments, said he, will push the change as soon as possible.
Mario Vega:All right, thank you.
Mario Vega:Well, if nothing else, I think we can end the call here. Thank you. Everyone for joining, and yeah, have a good rest of the day.
lightclient:Thanks.
Toni Wahrstaetter:Thank you.
Justin Traglia:Cheers. Bye, bye, everyone.
Andrés:Bye.
Chat Logs
00:00:34
Mario Vega:https://github.com/ethereum/pm/issues/1603
00:01:03
Marius:43??? Time flies
00:02:08
danceratopz:when you're having fun, Marius.
00:03:35
Parithosh Jayanthi:Sync test repo: https://github.com/ethpandaops/kurtosis-sync-test/actions/runs/16106333838
Sync test over non-finality period: https://github.com/ethpandaops/kurtosis-sync-test/actions/runs/16080134128
00:04:57
Barnabas:we could plan a scheduled non finality for sometime this week.
00:08:11
Barnabas:I’m asking once again, how is backfill impl going?
00:08:46
Manu:Prysm: Still in progress
00:09:49
pawan:Replying to "I’m asking once agai..."
Same for lighthouse
00:10:29
Parithosh Jayanthi:Are there any backfill blockers or is it mainly time?
00:10:32
Francesco:Backfill not being implemented shouldn’t cause the problem though, right? If earliest_available_slot is set correctly
00:12:33
Parithosh Jayanthi:Were all the bugs in devnet-2 fixed or did we patch it over with validator messing around?
00:12:44
Manu:+1 about devnet-2 stability
00:12:47
MatthewKeil:Very much agreed
00:13:46
Justin Florentine (Besu):https://eips.ethereum.org/EIPS/eip-7910
00:14:33
FLCL:want to see it on devnet-2?
00:14:47
Barnabas:We haven’t officially “included” this for devnet 3 scope.
Can we all agree that we need this?
Also can we add forkid to 7910?
00:14:49
Gabriel Trintinalia | Besu:Besu has a PR in review
00:15:35
Gabriel Trintinalia | Besu:forkId is the currentHash in the EIP, isn;t?
00:15:42
Tim Beiko:+1 to extending eth_config
00:16:44
Justin Florentine (Besu):7910 is much broader than forkid
00:16:50
Barnabas:Could someone make a PR to 7910 regarding the forkid change?
00:17:02
Gabriel Trintinalia | Besu:Replying to "Could someone make a..."
I can do
00:17:20
Barnabas:Replying to "Could someone make a..."
it should probably include all historical, and scheduled forks then right?
00:17:23
milen | Erigon:Erigon implemented it
00:17:38
Justin Florentine (Besu):besu has a pr in flight
00:18:06
Gabriel Trintinalia | Besu:Replying to "Could someone make a..."
yeh, probably yes, that is a good idea
00:18:11
FLCL:we plan to add it this week
00:18:23
Marius:No
00:18:36
Roman:same as nm
00:18:42
Roman:planning to add it this week
00:19:13
Barnabas:7910 will be in scope of devnet 3 then
00:19:25
Barnabas:and we will expect clients to have it.
00:23:07
Mario Vega:@Marcin Sobczak should this be merged for devnet-3: https://github.com/ethereum/EIPs/pull/9969 ?
00:23:34
FLCL:May it be someone has secp256r1 benchmarks?
00:24:59
Ansgar Dietrichs:did we not already decide to do the 3x?
00:25:12
spencer-tb:Replying to "did we not already d..."
2x I think!
00:25:26
spencer-tb:Replying to "did we not already d..."
(For the curve)
00:25:40
Ansgar Dietrichs:Replying to "did we not already d..."
I thought 2x was the r1
00:25:57
Parithosh Jayanthi:Replying to "did we not already d..."
ACD discussion was this:
Increase the modExp gas cost with this PR: https://github.com/ethereum/EIPs/pull/9969
00:26:04
Parithosh Jayanthi:Replying to "did we not already d..."
So 3x
00:26:20
Parithosh Jayanthi:Replying to "did we not already d..."
source: https://discord.com/channels/595666850260713488/745077610685661265/1390396429918404690
00:27:05
Louis:Replying to "May it be someone ha..."
Maybe this?
https://github.com/NethermindEth/gas-benchmarks/tree/main/tests-wip/Precompiles
https://github.com/ethereum/execution-spec-tests/blob/e88a2113f6d93ded665a15e8e4de448c03453175/tests/benchmark/test_worst_compute.py#L1067
00:27:15
Marius:Replying to "did we not already d..."
2x for r1, 3x for modexp
00:27:18
Tim Beiko:All the feedback I got is that the effect on projects is minimal (for ModExp 3x)
00:28:27
Christine Kim:Replying to "did we not already d..."
https://christinedkim.substack.com/p/acde-215-minutes
00:29:32
Louis:What about CLZ gas cost?
00:29:40
Parithosh Jayanthi:And yeah we can chat in the gas limit testing channel about if 3x still won’t get us to 100M or not, mainly since going beyond that would likely need glamsterdam and a more comprehensive repricing is planned there
00:32:56
Barnabas:why do you verify builder workflow at all?
00:33:09
Barnabas:its not like you have any say in this
00:33:24
Barnabas:it even makes less sense to verify
00:33:39
J Sunnyside Labs:Just to add regarding GetBlobs, can we get EL metrics for it standardized across ELs for devnet-3? https://github.com/ethereum/execution-metrics/pull/2
00:35:02
pawan:Replying to "it even makes less s..."
Yeah I realize now that we only verify after we have already signed the block, so doesn’t help us even if its invalid
00:37:05
Barnabas:lets have the pr open asap imo
00:39:05
Tim Beiko:Maybe before SFI?
00:39:14
Tim Beiko:Would open a PR to 7723
00:39:49
spencer-tb:Replying to "Would open a PR to 7..."
Happy to do that unless anyone else wants to 🙂
00:39:57
Barnabas:Replying to "Would open a PR to 7..."
sendit
00:40:39
Barnabas:whats the PR @Ben Adams ?
00:40:46
Mario Vega:https://github.com/ethereum/EIPs/pull/9969
00:41:39
Barnabas:Replying to "https://github.com/e..."
this is not transaction cap pr
00:41:52
Toni Wahrstaetter:If we really want to do this for fusaka, we should change 7825. I put it into a different eip since I assumed fusaka is frozen.
We might need it in the future (post-fusaka).
00:41:58
Ben Adams:https://github.com/ethereum/EIPs/pull/9984
00:42:42
spencer-tb:Feels safer so I am in favour!
00:42:57
jochem-brouwer:Process wise its basically the same as changing gas price of CLZ. But do we have the analysis that this does not break major things?
00:43:36
Barnabas:I would just make a pr to 7825.
00:45:10
Gabriel Trintinalia | Besu:question: system calls will also go to 16M? (they already have a 30M cap today)
00:49:45
Marius:Will push the change asap
00:50:04
Parithosh Jayanthi:Mentioned in gas limit channel: https://discord.com/channels/595666850260713488/1364000461568610415/1391793763441049681
00:50:07
Antoine James:Thank you!
00:50:09
Gabriel Trintinalia | Besu:tks all!