All Core Devs - Testing #45

Transcript

Mario Vega: hey, Pooja! I think we can start. Just let me know when I when I should start.

Pooja Ranjan: We are, live.

Mario Vega: Awesome. Thank you so much. Yeah. Welcome everybody to acdt number 45. Today's July 21, st we have a couple of items in the agenda. And 1st of all, as always, Fussaka updates, is the 1st thing to to address. I think definite 3 has not gone. Live at this point. But we can start with. there was an East release. So I think we can start with that. If that's okay. Spencer, are you? Yeah, Spencer, do you want to give an update on the East release?

Spencer Taylor-Brown: Yeah, sure. So and we released a yeah, a feature release. And for devnet free just last Friday. And basically the changes within the release include updates to the gas prices of and the modex and the curve Clz, which I guess we'll chat about later. and the blog base fee cost change for eip, 7, 9, 1, 8, and the transaction gas limit reduction for Eip 7, 8, 2, 5, and the release also includes new tests for the Max blob per tx limit, added to the pure daft IP, and and also removes all the tests for Eip 7, 9 0, 7. Yeah, I guess we might have another release based on the end of this call. But yeah, let's see, let's see

Mario Vega: Thank you. Thank you. On the Dominitory side. I don't see one of us in the call parry. Do you know if there's any updates? Yeah.

Parithosh Jayanthi: Yeah. So there's mainly 2 things left we do have a Pr from Spencer for testing hive. So as soon as have a branch for us. Ideally. The branch name is Fusapnet 3 it should pick up all the images, and we should have hive tests running kurtosis should be running as well. I'll PIN a version that people can test out, but we haven't received client images from all the clients yet. And there are 2. Main, yeah, 2 main prs that still need to be like, we need to sort out ideally today. The 1st one is on the builder specs, and the second one is on engine. Get blob. C. 3. I think those are the main points for devnet 3. If all of this is true. As soon as we have client images, we're ready to launch ideally in 2 to 3 days.

So before Acde.

Mario Vega: Awesome great. Regarding the builder specs. There was comment. That was made by Bharat, I think, is that is that relevant to the discussion. I'm not sure if if if they are in this call. but we can touch upon that topic later. If that's okay or do you want to go now?

Parithosh Jayanthi: Wherever, wherever you want to schedule it.

Mario Vega: Alright. Cool, cool. Okay. Thank you. Anything else regarding Fussaka, or then the 3 house clients implementations coming along. Does anybody any anybody from any client team wants going to give an update best who is ready pending. Get blocked between. Get is also ready except except for the config endpoint. Red has a branch. Get underscore, config and get blobs between. Aragon is also ready without get blob. Cp. 3 lighthouse is ready. But coming back to yield clients. Anyone anybody from? Never mind here that wants to give an update.

Never mind, Brady. Okay. Cool. Lighthouse ready. Okay? And anyone from the rest of the cl clients who wants to give an update on readiness. Anybody from from Teku and Justin made the comment that there's not that many changes, for fuzeka losar is ready. Okay. just missing. Builder. Api. Okay, thank you. Alright. It seems like, I also granting is ready. Okay, it seems like most clients are ready, and it's looking good. I think there should be any blockers for the next 2 weeks. Sorry the next 2 days. Alright cool.

Next topic is gas limit testing updates Barry for this. Do you know who the person with context is?

Parithosh Jayanthi: Yeah, I can go here. So one of the I guess biggest updates is that we've been. We've had all the client releases made for 45 million or most of the client releases made for 45 million. And enough validators have updated that roughly. A few minutes ago we had the 1st 45 million gas limit blocks on Mainnet. So congratulations everyone that's definitely good news. That being said over the weekend we were working on puff devnet 2. And we had this one weird issue with Bezu, where the image with the wrong MoD X. Pricing got pushed onto the performance tag. And as a result, we've had non finality for the last one or 2 days. The issues core issues, mostly a config mistake.

But we're still trying to sync up bezoo and figure and just ensure that it isn't anything else. And in the meantime we are working on getting finality back up there. Other than this. There's been a couple of other work streams. So we have a new sync testing tool. It's called syncor. And the 1st run of syncs of all the nodes are going on now. So in the next couple of days we should have a good baseline metric. For how long it takes to sync. There's been a lot of work by Carlos from the stateless team to try and get us all the metrics we want with the State plot network. So puff devnet 2 is almost at 2 x mainnet state as well. So we should be able to run the sync or tool against it and get sync information for 2 X Mainnet State. We have a new Rpc testing tool as well.

and Rpc testing tool just is so far a proof of concept. We're gonna start reaching out to node operators to try and get a sense of what workloads they have so that we can benchmark them against all the clients, and then make a preliminary report, for this is how clients perform at 36, or well at 45 million and then we should have stronger Rpc benchmarks as well for the future. I think that's everything on the gas limit side. Maybe Camille has something else to add.

Kamil Chodoła: Yeah. In meantime, we are working on extended gas benchmarks, opcodes, benchmarks. For now we focus quite a lot on all modex because of some additional repricing which were made, and to ensure that it is fine. But yeah, this is like, from benchmarking point of view, it's almost accomplished, and we are moving all of our sources now to all of our forces, now to stateful testing, which is like unexplored ground right now, where we had a Johan with who made some tests on Perfnet. But we want to make it fully reproducible in the same way as we do with Opcodes already in contact with his team. We had a very nice discussion last week, and right now we are trying to summarize that with, together with Martin from our team to to make a document on how? How the full integration of of opcodes benchmarking with Es should work moving forward.

And what is the end goal for that we have some ideas. We want to test as much as possible right now on top of Mainnet, or even Bloatnet State. And yeah, this is like current goal. And hopefully, next few weeks we'll have much more extensive tests, which will give us much more insights from from this point of view, because computational side seems like is already quite well covered. So we can focus on something which will bring much more value. And then we'll start exploring more edge cases.

Mario Vega: Thank you. Marcian.

Marcin Sobczak: I would just like to say that Tony prepared about modex changes and network impact. So just based in on the chat. There is nothing surprising like after free xing the price, 100% of calls are affected but there are like great insights on the chat so and take a look.

Mario Vega: Thank you. Alright. I think there was a question regarding the get blocks. B, 3. Readiness. But before that I think it's just a nice that. We discussed blotnet. I think there was one person that wanted to discuss this. I think it's a good place to start discussing that C. Peris. Are you in the call?

CPerezz: Yep.

Mario Vega: Do you want? All right? Yeah, yes. Let's let's yeah.

CPerezz: Sure. Yeah. So I I'll be very quick. We are approaching 2 x main net state in Blobnet. And ideally, we want to rerun syncing tests. And we want to start also trying to run compaction testing to see how much we can stress adding and removing state. And how does it play with compaction? In order to be sure, we can reach 100 million gas limit safely. And for that we needed some metrics implemented by teams. So far, I'm gonna comment. The ones that we are missing or for the things that we haven't heard such that maybe they can get this ping and and they can update or or give us some some feedback. From syncing we are missing any information from Besu and Aragon.

And from never mind, I know they are reporting healing from blocks not in Grafana, and wanted to basically know if there's any way to get that from Grafana, as getting data from from blocks is a lot harder and requires a lot more integration for for the tooling that I mean, we would prefer to not spend the time on so maybe Camille or Ben can say something about never mind. And maybe there's someone from baseline that can basically say anything about their metrics.

Kamil Chodoła: From that reminder. I think that this should not be a huge thing to to add a metric for healing, so we'll try to push for for that metric.

CPerezz: Opia. Thank you. A 1 million.

Milen Filatov: Yeah. So I responded, last week, and I've added all the metrics for Aragon. So they're in the Grafana already.

CPerezz: Okay.

Milen Filatov: Including including including Syncing.

CPerezz: Compaction, tool.

Milen Filatov: We don't really have this concept of.

CPerezz: Okay. Fair. Enough. Yeah.

Milen Filatov: We have the metrics that are analogous to that. Yeah.

CPerezz: Okay. Awesome. Thank you.

Milen Filatov: And actually, yeah, they've been quite helpful already. I think we've spotted a few issues. So this, this effort is quite useful.

CPerezz: Thank you. Don't want to be so insisting. But if at some point you reach some conclusions on the issues you saw, please reach out such that we can lock all of them.

Milen Filatov: Yeah, we're we're still looking into it. But I will definitely update you with like a summary. Once we figure out what's happening.

CPerezz: Thank you.

Milen Filatov: Yeah. No worries.

Mario Vega: Machine.

Ameziane Hamlat: Yeah, thanks. On pesos side, we do have the matrix on sync. but it seems they are like removed when we start the node. So we need to check our implementation, to be sure that the metrics are are persisted, because I see we have them on few nodes, and we don't have them on other nodes. So we need to. We need to double check. We do have some metrics on compaction. But so so what's the the kind of metric we are looking on compaction. Is it like the the impact in terms of time, or in terms of.

CPerezz: Yeah, I just send a link to a Hackmd which basically has the summary I will update on now. But for a quick description in compaction. We need to start and end time. And we want also to get I/O performance when we are and when we are not in compaction especially best, worst and average. Read and write times for each block for every operation that basically removes or stores stuff into interstate into the dream. So insertion, removal type basically.

Ameziane Hamlat: Okay, yeah. So start and time compaction. We we do have them. But we have them like under a set of set of metrics that we we don't usually enable, because they have some overhead like a lot of metrics. So we need maybe just extract that one outside, like the the set of those metrics. And and we'll double check the the rest of the matrix, and we'll update.

CPerezz: Awesome. I'll get in touch offline to to follow up. Thank you very much. That should be it for, blonded Mario.

Mario Vega: Alright. Thank you.

Parithosh Jayanthi: Mention if clients could. Please make sure that all the metrics changes are pushed to the performance branch, because that's what we're running on the block net.

Mario Vega: Thank you. Awesome. Yeah. Going back to the get. Blob. dB, 3. I see role. Do you want to add some context to this question?

Raúl Kripalani: Yeah. I think in in general like this, Els have most of them have implemented the the Api sales have nothing to do here, and in general, I'm seeing some favorable reactions in the chat to just merging the spec change so that Els can merge their implementation branches and move on. I think that's what I would propose, and we can close this topic.

Mario Vega: I see Dustin the main counterpoint. Do you want to, Dustin? Do you want to expand on this in any way?

Dustin Brody: Sure. Yeah, So I understand. And I agree, very based on, you know, as as best as I understand where this is going that get Bob 3 3 is is ultimately something like it is ultimately probably what we want. What I fundamentally disagree about is entwining this with the Fusaka fork, because essentially, as I have have written, but obviously this is a weirdly threaded environment. So I'll summarize here and to say, like the Els can can merge what they want, and it's and it's and it's great. I I hope that if we that that at some point the Els do, if we are moving in this direction, do merge such such a Pr. Where I I would distinguish here, though, is that

treating it as part of Fusaka, it is effectively, not from my perspective, if it's not been tested in a very similar way as the rest. And we have recent experience with, you know, simple seeming things that were not tested. and they didn't go very well. And so that that that's sort of the the gap or gulf here for me is the idea. Can I just shove this last minute thing in and don't worry about it. It's like we can't rely on that. We, Nimbus can't rely on this. I can't speak for other cls, but like, yeah.

Raúl Kripalani: Yeah, I think the operative point here specifically for me is that we did wanna make sure that while people while peered as and in general, blobs are are in the refactors. There are fresh for people. They just get this particular change in so that we don't have to context, switch it later and incurring the coordination overhead, of getting releases of Els out and doing an off cycle engine. Api change, and so on. And and yeah, this this, as as we all know, v. 3, is not exercising Fusaka's code part specifically, this is more of kind of like an A. A, I would say, smart way of like trying to offload a context switch from the future, which is gonna be coming so that we can just get this work done when it's a simple thing that it's actually, I agree with you. It's simple.

I am. I'm not very privy to what happened in in Holeski. I wasn't. I wasn't there at the time. But in this particular, in this particular case we have the guarantee that this path is not gonna be used. And what if in consensus from consensus? So I don't see how it could have an destructive impact? But yeah, other than that I would. The the thing that I've proposed is is creating some hive tests so that we can test this separately. Directly with with that test suite.

Mario Vega: Thank you.

Dustin Brody: But okay, okay, so what? What I would, what I would would right like this is why we question, is that kind of, as Marius is just saying in chat is like, there's there's hmm! If it's Glamsterdam, then there's no rush to get into Fusaka by definition, if yeah. But clearly it's not. But clearly it's not right, because otherwise that that this coordination problem would would doesn't really exist. You can coordinate in Amsterdam around Amsterdam so that that either it is not meant to be in Fusaka, and therefore this is a pointless push now, or I mean again, clients can merge what they want, but from a spec perspective, I don't really care deeply what Pr is best you merges, or something like that, I mean, I hope they're good Prs, but like from from like as far as get 3 but in terms of including in a spec or or not what I would.

What I do care is is this considered to be part of of Fusaka or not? And what I would argue is that it should not be given that we are running into like the spec freeze and the last devnet. and no testing, and that that to me, just doesn't work like that. We cannot consider anything like that to be part of for soccer as a spec.

Raúl Kripalani: Right. I mean the I think the rationale here, and just to kind of like explain for everybody. The the facade slash, glam, stam slash in the middle. Sort of like thing here. That. Yeah, it's this. V. 3 won't be consumed for Fasaka, but we aim to consume it through optimizations and the cl and the cl, and specifically the peer to peer layer before Glamsterdam. So that's what kind of like creates the extra coordination challenge midway. And the the bet that we're taking here is that by doing this now we'll remove X-ray for everybody later. And it is done and given that this operation is not consumed in any way. Because it is exposed only through the engine. Api. The engine Api is privileged, and it is only consumed by the Cl. If the Cl. Does not consume it, which is agree, it's it's not part of the Fosaka spec for the Cl. So it's not gonna be consuming it. Therefore there is no risk here. Other than possibly the implementation risk

which is what we are aiming to test by hive tests, and I think that is sufficient testing.

Matthew Keil: I I think the thing that's being missed here, though, is that there is risk. And it's from a process perspective. You know, the the biggest issue we had in the last work was, get last thing in, get last thing in. It's not going to get used. It's just a minor change, and I think this sets a precedent of trying to sneak things in under the wire when it's not going to get used. And to speak to Dustin's credit. I mean that that feels like just it. It makes the process messy. And that really is the biggest concern. It's not so much whether it gets used or from a technical perspective. But I think if we want to be able to ship

hard forks on regular schedules, and we want to get used to that. This. That's how that's how releases are done, at least on our team. And I know they were done in the web. 2 world is that you have a hard date. Specs get in by that date. If it misses it, it's in the next release. And because there's always going to be this incremental one more thing, and that that to me, is the biggest issue here, not so much the complexity or the how it gets rolled out, or or even the merit of the feature.

Mario Vega: I I absolutely agree. So. I think, this is contentious enough to not be further discussed in this call. I think at the very least. I would defer this discussion to acde if we're not sure if we're gonna implement something in in Infozaka. I don't think this is the place to discuss it. But yeah, that's my opinion. Pari.

Parithosh Jayanthi: Yeah, maybe to play the contract. Let's say we don't include it right now, and we assume that it's going to go down the approach of get blobs. We want assuming we have a single el as well as cl implementing this in the future, and we deploy it asynchronously on the network. Would that still work out for us long term? Or would we then be locked until Glamsterdam, before we can actually make use of this feature. Also note that we have this we have this other concept system. We have a Bpo fork. So there's sort of another sync level between Fusaka and Amsterdam that we never had in the past. Ideally, we're not making any code changes there, and it's only Bpo. But if let's say, guest as well as lighthouse, make a release with using this feature, and that, would the Bpo fork would imply that every guest and lighthouse node on the network has implemented this feature. Would they then be able to use it? Or is it a useless feature until the whole network uses it.

Raúl Kripalani: Yeah. So from the perspective of the optimization that we're planning, this would be at the Cl level. And basically clients that are supporting the gossip, sub partial messages feature that uses the partial blobs return from the El would be able to use this optimized path when reconciling columns with each other. Essentially. So basically, the goal here is to minimize the band superfluous bandwidth usage here by that would be incurred by transmitting columns that include cells for blobs that deals already have because they are in the elm pool. And that's the that's the goal here. So basically, this is being shipped as a as an extension, and that extension on the gossip sub level is discovered and then used only if both clients are are supporting it, so this can be shipped.

As an optimization implementation level optimization that has no potential. That's the way that we planning it. Would be having no or at least envisioning it would be having no spec changes necessary. On the on the sales side of things, and the idea was to have the Els ready to support this from from the get go.

Mario Vega: Francesco.

Francesco D'Amato: Yeah, I just wanted to say that, I think in sure, when he was last week. I don't know. Last Thursday we, he said, and this has been going on for really like a long time, that we would make a final decision today. And I think we should really stick to that like, if we cannot make a decision, then let's just default to not doing it. If we otherwise. Yeah, let's try to make an explicit decision. We don't need to spend all the rest of the ball talking about it, but it would really be good to just end this today. I think.

Parithosh Jayanthi: Yeah, I think if the consideration is on the testing front, we're happy to acknowledge or commit to adding some testing bandwidth from our side to make this happen. I'm guessing the testing teams also. Okay, with that. But yeah, I don't want to speak for the process decision, of course, but if it's purely about testing, and that we agree that no Cl would roll out any change in the future without going through the regular testing process. Then I think we can accommodate that from the testing side.

Mario Vega: Yeah, I mean, we can do it definitely. The problem is that we don't have it exactly now. So I don't know how much is gonna delay. I would I would. I would love rather to have this test already for definitery. But that's not the case. So yeah, I'm not. I'm not confident. we we're gonna have sufficient testing for definitely, in my opinion.

Raúl Kripalani: So just just one more thing to note here the decision ends up being not to include this. Then I think we need a decision on what's gonna happen with the version? That's on master right now, which does introduce a schema change that Cls would need to support which I don't know if they have an implementation change already, for my my understanding is that they they don't.

Mario Vega: Is there a pr. For for this? Do you have a link.

Raúl Kripalani: This is merged in master, but, as far as I know, no Cl has implemented it. So this, this Pr that we're discussing the one that includes gets Bob v. 3 would revert reverts that change on master to the behavior that cl's implement today, and then adds the V 3 endpoint.

Mario Vega: Does any cl have any input on that? Do we know if it's like implemented.

Pawan Dhananjay: We haven't implemented it.

Mario Vega: Is that the case for all other Cls.

Matthew Keil: We have not either. We're just using v. 2 as it is.

Emmanuel Nalepa: Time for prison. We haven't implemented it.

Dustin Brody: Same, for Nimbus have not implemented it.

Matthew Keil: I mean that in and of itself feels like that makes the decision, at least for now. But yeah.

Parithosh Jayanthi: Maybe expanding on Francesco's point. So this would imply that we stick to get blobs v. 2. And we basically don't do anything with get blobs. V. 3. Right now for a sec. The right reading.

Mario Vega: That feels like the safest way, and the correct reading at the moment.

Parithosh Jayanthi: Yeah, maybe someone can respond to the message Kapria mentioned as well get blouse. V, 2. Allowing partial responses or not.

Raúl Kripalani: It would be a no, it's an it would be. It would go back to all or nothing. Get block speed 2. Which is prior to merging the Pr. That I just linked in the chat.

Mario Vega: Sounds good. Okay? So then, just to summarize, get balls, be 2 with all or nothing, and it's going to be reverted in, master, and we're going to stick for that on devnetary. All right. Great thanks. Everyone. Yeah, I think. The next topic. If that's if that's okay, unless there's any any other opinion. Next topic to discussion is a point brought up by Mikhail regarding the usage of safe blocking the engine. Api response. Michael, do you want to expand on this.

Mikhail Kalinin: Yeah, thanks. Hi, everyone. I will not go much into the details of the Confirmation rule. It has been already announced before. Just give a brief context. There is a Pr, there is a paper with the Confirmation rule algorithm. There is a Pr open at Pr to the consensus tax which implements this algorithm. And recently, we did work on a slightly modified version of this algorithm, which is more efficient computationally wise and easier to implement. And currently recently, the there is a pro project started a week ago on prototyping this algorithm in lighthouse. So there is a work towards having the Confirmation rule delivered to Mainnet. And One of the things that's we need to decide is how how we will actually provide this confirmed block

to to the, to the blockchain data consumers, and historically it was supposed to be the safe block was introduced. and was supposed to be set to something closer to the head that we think that is confirmed. So basically, it was supposed to be set to the confirmed block. But this work. Yes. But there was no actually, the algorithm that would provide this data. And we, we used justified. or some clients use and realize justified block for for the safe one and yeah, should. And and the main question is, should we actually overload the save block and to use it for to pass the confirmed block to it. Or should we introduce a new block tag to engine Api Json or Pcpi

which what we use for for the confirmed bulk. So I don't know. Also, the One of the question is obviously block is actually used by data consumers. Can we figure out, can we get this information or not? And maybe it is somehow used by the clients? And yeah, all these questions need to be. all these things need to be considered to make this decision. So yeah, that's that's about it. I don't know if people have any opinion here and and want to express it now, or should we move this discussion to probably discord to some other venue? So much open to your suggestions.

Mario Vega: Thank you. Yes, Terrence, you have an opinion.

Terence Tsao: Yeah, thanks for the questions. I guess I'll answer a few questions in line. So I think, like, if the concern today is for disparity. The disparity already exists today. Right? Because prison is already passing unrealized. Justify for safe block cash. But I think there are other clients that's passing by justify. So there is this disparity here today. and then, on the presume side, I have a fast Confirmation branch. I have been testing it since couple of days ago, just because I think there is some renewed interest on fast confirmation. And what I ended up doing is that I added a client flag on the prism side to allow the node operator to specify whether they want

fast confirmation or unreal is justified or justified, or some future algorithm to be passed as the safe block patch. So this ends up to be a client flag on the prism side that people can use. and in terms of consumer. I guess I can answer for arbitral micro software just because I have a little idea how it works they use safe block hash to essentially allow layer to to consume layer, one message. So when when a batch poster post a batch. or when someone submit a message from layer, one to layer 2, or when layer 2 learns a layer, one block price that delay is essentially the safe block cache. So today's unrealized justify, but with the same block cash they will they? They they should be able to consume the message in the optimistic case in under 30 seconds. So that's 1 use case in terms of

what the plan you say block hashes for prism. We don't use it for anything internally. It's except for passing it to the El, and I cannot answer for the El. So yeah, someone might want to answer. There.

Mikhail Kalinin: Great thanks a lot, Terrence. And you've mentioned that our bedroom use is safe. It means that if we start passing the confirmed block fast confirmed block instead of justified it, could affect their security models right.

Terence Tsao: Exactly. But that is a note, operate this choice that is basically to be specific, that that is the sequences choice. They have to make right. So there's 1 thing I have been essentially testing is just to make sure there's no reorg. There's some there to accept, reorg. They don't really like reorg and stuff like that. So for them a reorg will be pretty bad. So I've been testing I I don't want this to be like a I miss a software, but on my end, if there's a reorg that happens. But yes, if there's a reorg, then the sequence of where we work.

Mario Vega: Thank you. Marius.

Marius van der Wijden: Yeah. So as I, as I kind of wrote in the chat, I think we are significantly underutilizing safehood. It should be like the default thing when when people are building applications that are like they don't like need finality, but that can rely on this pseudo finality. And I think for that to make safe hat really useful, it should be as as soon as possible. And so, as far as I understand this new rule, would be much faster than the than the than the justified and so I do. I do like the idea of giving the node operator control over what the safe head should be depending on on their use case. And yeah. So I I think

if I would like to CC alls. implement this new fast confirmation rule. And yeah, I guess from the, it is a mostly Cr only change. It doesn't really impact the eo, we will mark whatever the Cl. Tells us is safe, we will mark that as safe for for the Rpc, so, yeah.

Mario Vega: Thank you, Miguel. Where do you want to take this conversation? I it sounds like it should be to the execution. Apis a modification. There, at least. Do you think opening a Pr would be the proper follow up? Or how do you feel.

Mikhail Kalinin: Yeah, it's a good question. If we decide to to reuse safe then basically, as Mario said, it's it's mostly CEO side. It's mostly a kind of all the work. Actually, what would happen on sales side? We don't need to change anything on El if we? If we do make this decision, then probably there's not much to discuss. But if we want to debate at it, I don't know. If we decide? Yeah, yeah, probably. Let's try to follow up and discord on this. I'm mostly interested in. Is there anybody that think that we should not touch safe and change its semantics.

Marius van der Wijden: The only.

Mario Vega: Yeah, no, thank you. Yeah. I'm sorry. Maurice.

Marius van der Wijden: Yeah. The only thing that I can think of is like big Rpc providers. Who would like to expose them? That to the users to justify to the users. But I don't know. I think it would be their decision what to what they will mark as safe then and right now, if they run 2 cls. there might be a difference between what they mark as safe already, so it it could also be flip flopping, depending on the load balancing so. But I think this is for the big Rpc. Providers to figure out.

Mario Vega: Alright. So I think if we can follow up this up on discord, and I think bringing this up to Acd would make definitely make it reach a bigger audience that needs to have a say on this. And opinion. does that sound? Okay.

Mikhail Kalinin: Yeah. Sounds good. Sounds good.

Mario Vega: All right. Perfect. Yeah, thank you. Yeah. There are 2 topics left. One is the builder. I think there was some discussion in the chat. But Bara was the 1st one to bring it up. Do you want to expand on this.

Bharath Vedartham: Yeah, I mean, so I think we raised it. There seems to be consensus and client devs on the semantics of the Pr. And on the like under the timing, in the sense like just to give a tld around the Pr. We're introducing new V 2 api in the relay which basically doesn't. Return the execution payload and the blobs right? This is barely for like scaling and network bandwidth. So as we increase the number of blobs, and we're also like different seems to be broadcast on the semantics, that is. the Api returns like a 2, 2, not 2 success. If the if the blinded block which is sent is valid, and it publishes the block in an asynchronous fashion. So that's there. So I'm raising it here to 1st of all, understand if there are any concerns about it. Secondly, if there are no concerns we are planning like this probably should be something we can target for like Devnet 3

so we're currently implementing that in the flash bots like Mev boost relay. And hopefully, we can get that live for net 3. So and like, hopefully, we can test it with the clients implementing the V 2 Api, so yeah, just putting on the stage like there are any concerns related to that. and stuff.

Mario Vega: Any other context? Pari, do you? Do you have any context on this regarding we should like introduce it in Devon tree or not, or I feel like it's like very close to.

Alex Stokes: Yeah, I I think we should merge it. There's work underway to have this change in the web stack and everything. And then, yeah. I'll just move forward.

Mario Vega: Okay, thank you. Sounds good. And yeah, the last 2 topics are, I think. Clc, I think that's that's that's 1 of the the last topic, and also the block has 60 million. If we want to touch upon the topic today. So the 1st one is that the Cl set up code was bumped to 5. And Rakita, do you have context on the if I understand correctly, there's data that shows that it might be unnecessary. But if you want to expand on that.

Dragan Rakita: Yeah, physically, at least in my mind previously. Clc is very similar to any other bitwise operators. instructions of codes. So it was changed for me. It was bumped to be more similar to the move. It was bumped from 3 to 5 gas. It's not that big of the deal. We can always reprice it in the next half fork. But I have created few benchmarks to check that hypothesis, and it seems Clc. Is even. It deserves even lower gas than tree, so I would like, if to see if clients are open to changing this, to to be back to the tree gas. I shared those benchmarks inside the okor dev chat in discord.

Mario Vega: Thank you. Yeah.

Dragan Rakita: I'm not sure if clients have an appetite for this change.

Mario Vega: Yeah, I think the main problem is that we are very close to finalizing. So I don't think a roll rollbacking. This change is like really a possibility at this point. I don't know if everybody still feel the same way. But that's my opinion. Yeah.

Dragan Rakita: Yeah, it's basically one. Characters don't even line from 5 to 3. I'm up to changing it. I'm not sure if anybody else is.

Mario Vega: Yeah, to raise Marius's point. regarding benchmarks. it feels like dragon mentions that he has benchmark for this. Is that correct? Or do you have this for all the clients? Or is this just rep.

Dragan Rakita: There is bytecode that can be found in repo. But the fastest batch project I could do is basically from our evm. So I did it in the code. And I did it in the code speed. That basically shows amount of the time spent on every upload. And I compare this output that I got from the outputs, from the different topcodes, and it is more similar to other bitwise opcodes. So it seems that Batchpark is correct. Now there are different limitations and different depending on implementation. You will have different execution. but either way seems correct to to use tree gas here.

Mario Vega: So just to summarize. I mean, I think this change was done a week or 2 ago in regards of keeping things safe right? Because we don't really have much benchmark, that many benchmark for every single client team. So if I understand correctly, your benchmarks are only for red, so we would need to do a deeper like analysis on benchmarking for the rest of the clients before rolling it back. In my opinion, so I would echo Maris on this that we don't want to change it, because it's very late in the process. But if anybody else feels opposed to that, just please speak up from the other El clients would be nice to hear. Yeah.

Ben Adams: I mean, it's very simple to change. I mean, just revert the previous pr that increased it. But don't feel any particular way on it.

Mario Vega: Yeah, the the change is not the concern. I mean, I think that the change is super simple even in the test is simple, but I think benchmarking is the main problem that we have now, and we don't have. and up benchmarks for this from the East Side. We're working on benchmarks, but we're not quite ready, because the framework's not fast enough to deliver the benchmarks yet.

Dragan Rakita: We didn't even have benchmark that pushed it from 3 to 5. The data that I have shows that it's even less than 3. But either way, it's not big of the deal. The main thing is, we have Cls included. So if clients are not up to to the change, it's fine to have it. 5.

Mario Vega: Yeah, I was still in to leave it as is on 5. But yeah. open. I think I think we should leave it for for dignity. And yeah, consider it for for Dumpster, for reduction. Kev for your question. I'm not sure for the answer to be honest. Yeah, okay, Marius. So you're saying like, it's 5 times yeah. it's 5 times worse than ad. Right? Do you want to expand on that on get the site.

Marius van der Wijden: Yeah, I literally just did this in the last 2 min. I I wrote a benchmark. and from what I can see it is. do we have one benchmark for adding 64 Byte and and that is like 5 times faster. Then cl, z, and even the multiplication is like. at least 4 times 4 and a half times faster than than clc. so maybe there's something weird with our clc implementation. But yeah, it seems like. at least for us. It's not in the same vicinity as the other codes. But, as I said, I I wrote the benchmark just now. So maybe there's something wrong with with my benchmark. But I would like to.

Yeah, I would would love it if we had some if we had like a full benchmarking suit for this, and I think that is. feels like an oversight that we don't have this right now.

Mario Vega: Yeah, I agree. So how this I think the main question right now is benchmarking. I think we can work on that this week and do benchmarking against all the clients. and I would lean towards changing the gas price upwards instead of downwards. So I feel like leaving it as 5 is the correct decision at the moment, and then we can, after the benchmarking, we can decide on whether bumping it because of security concerns rather than just lowering it. Now. does that sound fine by everyone? All right. Cool. Yeah. We only have 5 min left. I think if I'm not, if I didn't miss anything from the from the chat. I think the last discussion is or at least was brought up, is the 60 million gas question at the moment. I don't remember who posted the message. But do you want to expand on the

whether we want to go on that today or not?

Kamil Chodoła: It was me actually, just wanted to, maybe brought the discussion, as we already hit 45 and 60 is not a matter of any further eaps, at least, for now we do not know about anything which we need to be repriced to hit 60 before Fusaka. We know about some optimizations needed to be made by some real clients. But maybe anyone is having any doubts or anything like this to to see, or at least make any kind of temp check if we should try to to reach it before Fusaka, or there is anything else which anyone have in mind against that. for sure. What we know right now is that we need to optimize a little bit more modex libraries in go implementations. But this is a ongoing work, and we have a lot of benchmarks around that.

So yeah, so we know how how much we need to improve around modex. But yeah, except of that, there is not much. Things which feels like are any risky.

Marius van der Wijden: I don't. Oh, maybe the receipt stuff, because. like, if I remember correctly, the receipt stuff breaks around. 72. My goodness, a million gas clocks.

Kamil Chodoła: And last recall, it was 85.

Marius van der Wijden: Oh, oh, okay, then,

Kamil Chodoła: Kuwari also mentioned that here.

Marius van der Wijden: But with the with the with the with the refund bump, you can probably get that down right by like 20%. That's valid. Yeah.

Mario Vega: Ben, do you want to add something or.

Ben Adams: Yeah, I was just gonna say that the receipts is the blocker on getting to 100. It's not not a problem for 65.

Kamil Chodoła: So generally, I put that in a chat. And even we have those few minutes additionally, but just wanted to throw a topic. And maybe we can think about it throughout the week and get back on that and add it to our agenda next week to to discuss and see. because at least. Personally, I don't see any like big blockers. Instead of some general performance improvements to to reach it before actually, Fusaka will come in place and solve some of these issues. which would be nice because we still don't want to probably go in one big jump between 45 to I don't know 100, after addressing modex repricings. would be nice to have something in in meantime.

and 60 feels like a good stop which we can pretty safely achieve prior to that.

Mario Vega: Alright. Thanks thanks for bringing it.

Kamil Chodoła: Growth is also a good point from from Marius, which is being worked on.

Mario Vega: Yep, perfect. Yeah, I think I think it's a it's a it's a nice topic to bring up. I think next week we can be well, maybe not today. But in the in the coming weeks we can have more more information on this. But it's nice for it to be brought up so we can have it in the back of our minds. No need for a decision right now. Cool. Okay. Any other topics. We only have 1 min, but if there's anything like alarming that we have to race right now. please speak up. Otherwise I think we can wrap it up here. Alright thanks everyone.

Mikhail Kalinin: Thanks, so much.

Dmitrii Shmatko: Care about.

Antoine James: Thank you. Everyone.

Marius van der Wijden: Thanks. Brett.

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