All Core Devs - Testing #37

Transcript

[Music] So, first point of business, um, we did have Petra about week and a half ago now. Um, I think there haven't been any real analyses published yet. Uh, but have client teams noticed anything so far? Anything you want to talk about or discuss? Yeah. Um, great. Then that's I guess good news. Um, the first topic of

business is going to be Fusaka DevNet Zero planning. Um, so there's been a message on um on the interop chat that basically clarifies what EIPs are a part of Fusaka. Net0ero. So we I I'll just link it over here again. So everyone's um everyone knows what uh EIP I refer to. Uh essentially it's pureas mod XP upper limit. We have uh mod XP gas cost increase. Let me just mute. Yeah. Um mod XP grass gas cost increase and uh blob parameter only hard fox. I know that the bok are still a point of discussion that we will have

to the rest of ACD. Uh but at this moment are all teams okay with with both the mod XP EIP being included for Fusaka DevNet Zero and I think the main argument against it would be if it's significant amount of work for implementation on the E side. Okay. Captain Bezu say it's good for them red as well. Okay. Um is there anyone against having both EIPs? Okay, perfect.

So I think all ELS are in agreement there. Um the document has already been changed. Uh let me find it quick link that. Yeah. So you should be able to see um the Fusaka Devet zero specs over there. Uh once you do have your client ready then please reach out to us and we can already have a curtosis config updated and start testing on the front. Anything else that needs to be discussed for devet zero.

Uh so I'd like to discuss uh BO because uh there was a suggestion by Maros uh to treat uh like the like to have explicit forks on the L side for BO uh so what what's the uh agreement on that? Are we doing that? Yeah. So that would be the next big topic. Um Mario, since you posted a comment about it, do you first want to um articulate your position? Uh sure. I I posted my position in um in uh ACD channel a couple days ago. Um basically

um these BPOS are are just normal hards on the execution layer. Um they the only reason why we don't have them as normal hard folks on the consensus layer is because the consensus layer people uh update um don't want to uh copy a bunch of boilerplate code for for their folks. Um but uh since the rules change uh we need to also update the fork ID. Uh otherwise we might peer with uh peers that are on the

um on the wrong fork. uh and so my position is that we have a mechanism to update the fork ID. We have a mechanism to update uh to to specify forks. Uh so in we should limit the amount of changes that we need to do um and just use the mechanism that we have. Um the downside to doing this is that we can only specify a set number of uh BPOS.

Um and um the uh that's not really a problem for anyone except maybe for testing if they want to specify an unbound number of forks. Um but I don't see any reason to do that. like if we have if we specify five BPOS's um then um I don't see a point in doing more than that on any definite um yeah okay thank you that makes uh sense I

think on the is there someone on the CL side who can articulate the issue over there because this will be something that I guess affects both of you Or it could still be a complete hard fork on this E side and not a complete hard fork on the CL side. Right. Yeah. I I think we should like limit this discussion to the EL side. Like there's no reason to get the CL involved. They will do what what they want to do and we can do what we want to do. Um got it. because there's also a parallel long CL discussion. So I was thinking if first we can have the positions of the two sides and then see if there's any

overlap or not and if not then we make two separate decisions. Uh yeah, do you want to go for the CL side? Yeah. So so I agree with Mario that uh I mean you we can have separate discussions about the L and the CL. These are completely independent decisions but I think the same problem of peering appears on both sides. I mean yeah it's it's they are independent problems but but it is exactly the same problem. So it is a discussion to be having in both sides. Got it. So it's the exact same point essentially that you need to unpeer or reeer with someone which means your fork ID likely needs to change and at that point it

not I mean not necessarily a fork ID but the abstract problem here is when do you want peer with someone that is on a different fork? Do you want to do this at the handshake level or do you want to downscore it later on because they're feeding you bad data? I mean the question is how early in the pipeline do you want to amper from these people? Okay, that feels uh like an implementation topic that maybe we can deal with um on the next basis on the next uh discussion point. I I don't think it's an implementation topic. I mean if you if you want to do this at the handshake level then it has to be part of the P2P spec.

Okay. Uh Terren, do you want to go? Sure. But like on the CL side, so I've implemented the BO stuff, right? So like on the CL side, the peering, they actually use this like net uh commitments per blob and that's actually cap at like a very very high number already. That's like 4,96. So that's like the max he can go. So I think on CL side it's slightly different, but like P said, yes, maybe we can like change it to more like a E side, but C doesn't have a man pool, so it's slightly different as well. So yeah, it's not clear to me what's the best path forward.

Okay. Um, and Raul also has a comment. Uh, do you want to uh just read it out, Raul? Yeah, besides kind of like the protocol and the peer-to-peer um details, I think there's another relevant point here, which is it does change a BO change does change the rules um and therefore clients that it breaks back backwards compatibility and therefore I think in just a general sense it should be treated as a hard fork also for signaling um in terms of like communicating why in the future like in the future they're communicating why they change change a particular rule at a particular point in time. Um

otherwise it's just going to be blended into kind of like a file somewhere an obscure file somewhere is going to be really hard to communicate this change and track it over time. Yep, that makes sense. Um so at least summarizing the points till now it seems like hard forks would be the most straightforward way to go. Um, is there anyone on either sides arguing for a non-h hard fork approach? Yeah, for those Yeah, if it's possible to avoid the hard fork, I would rather avoid it on the CL side. I think we can just signal this on the handshake uh and not add all of the boiler plate of having an actual hard fork in the CL

side. It's not a hill that I want to die on, but if we can just only scope it so that at the time of the handshake, you signal this, it would make our life much easier, I believe. And it would not delay peer deaths. Yeah. And I guess that uh is toend's point then that um if we were to do it just with the handshake then it would leave scope for some bad data, right? I'm sorry.

Gajenda's point was if we only do it with handshake that means there would lead to some scope for bad data because you're not doing handshakes all the time. Well, I I mean if if you get a handshake I mean that's that's quite quite normal, right? If I get a handshake from someone that tells me I am in this set of consensus rules and it sends me bad data anyways, then that's either a buggy client or it's a malicious client. But um we can deal with that. The issue here is that if we don't do it at the handshake level, we might be talking to clients that are honestly thinking that they are on the same fork as we are and sending us the wrong gas computation and we can only find out about this after the EL has returned that the payload is

invalid. So this leads to a situation in which we reconnect to peers that are in the wrong fork. So I think the right solution to this problem would be I mean the solution that I would prefer on this problem would be that we set an ID at the handshake level and on on top of that we rely on this thing that if the client is buggy and is sending us the wrong computation then the the block will be invalid eventually. Okay. Um that makes sense. So is there anyone speaking against the hard folk at this point then?

Sorry. On the CL side doing it the handshake approach and on the E side doing it as the as a hard folk. Okay. Um it okay maybe we again just open it from each side uh perspective. So for the E side uh let's first finish that discussion and then we can open up the CL side discussion. Uh so on the E side Roman do you want to go? Uh I just want to ask a question like what what

are we actually implementing then for uh DevNet zero like are we just predefining five future BPO hard forks and that's it and if that's the case like why are we doing this now for foraka instead of I don't know later when the actual BPO time comes. uh it isn't necessarily on the critical path for Fusaka but one of the ideas is that if we can showcase that the BO approach actually works then we don't need to do a massive scale increase directly at Fusaka but we could first deliver peas at roughly the same blob

count or a modest increase and then already pre-ched a blob increase shortly after. So this gives us some amount of time to make sure that everything is working as expected. So BO would be the primary mechanism in which Fusaka actually gets the scaling. Uh yeah Terren actually think there is a gap today in how the consensus spec is defined with regards to BPO right because when you have fusata we all upgrade to the correct like sub ID that's right but whenever BPO like changes this number like I think there is a missing gap the P2P interface back is not defined today

it's that saying that okay based on that we have to like connect to the new peer And here is the new Per ID blah blah blah. And that part is actually missing in the spec today. So we probably should update that. Okay. Um maybe could you put that as an issue on the consensus specs repo and then we can track that and make sure that someone has a look at this. Okay. So on the EL side that means that we are basically choosing the hard folk approach and we are just setting a bunch of BO times in advance and we're

agreeing to a fixed number and that fixed number could be five which should be also okay from a testing perspective and if and when we need more than five we would just go through the cycle and the ELS would schedule essentially more BPOS for us. Does that sound okay for all the E teams? Are any teams against it perhaps? And also just to clarify, is this fine

for the testing teams? Um, yeah. Okay. I don't see I don't see a problem. Yeah. Yeah. I I also don't see an issue with this approach for ktosis tests. Um, yeah. Barnabas. Yeah. I got a quick question. So, on the ER side, do we need the time stamp now inside of the blob schedule? in the Genesis file.

Uh yeah, why do you need that? Uh we were discussing that last week uh to have the time stamp in there so that you don't have to actually have BO one time defined as a port. I'm just curious if uh if you still need that or if we agree not to have that anymore. All right. So, I'm of a mind that we only need it outside of the schedule itself. So, it's a hard fork. It activates at a time slot and then the details of what goes into the hard fork is defined in the blob schedule.

This request was made by German I I think last week. So, I'm just curious if now we are we are all on the same page that we don't need the time stamp inside the schedule. Uh yeah, I can clarify a bit that uh all of my misconceptions regarding the BPO format uh were coming from a fact that uh I did not appreciate that this needs uh or ID updating as well until Marius pointed that out.

So I I resent all of my previous comments. Okay. So we don't need the time stamp in there. I wanted to ask about the format because in the E and in the example shared the values are rendered as JSON numbers while in the rendered east fixtures I saw that the values were rendered as hex strings. So could we actually render them everywhere as as numbers not strings?

I think Nethermine needs it at at hex strings and that is only hive I think. Um I see. Yep. Yep. Yep. Yeah. I mean the problem is that we have to homogenize everything uh to to be either extrins that that is a problem in east. um do you want decimals or exodimals? Well uh I I prefer them to be decimal integers. Um I mean we could but but okay we could implement reading both formats but it's a bit I think we definitely shouldn't mix it.

Um I think Netherland is the only one using hex right now. So for the Netherland chainspec format we can continue using hex but for everyone else we should keep them on the same format they exist at right now. Uh yeah, Dustin. So there is one case where we would have to intermix them, which kind of sucks because my understanding is that JSON uses doubles under the hood. And so for any uh integer values that could blow through that, you might need a workaround where you hex encode it or at least stringify it. Um seems to be a known issue with JSON and it kind of contributed to the the intermixing in the design. I am also not a fan of it, but I think it's a thing.

Okay. Um, Mark, yeah, just to clarify about Nethermind uh format, I I'm almost sure that we should handle not hacks as well. By default, we have hacks everywhere, but I'm almost sure that we can handle uh other numbers to be confirmed by some testing. But yeah, I think it shouldn't be a problem. Awesome. So if that is the case, then we should be standardizing on um integers and not on hex.

We can give it a try uh to change everything to decimal. I I wouldn't I would like to first make a pass on the generation of tests to see if anything like uh uh is the to see if this this JSON error produces something that is invalid and I I'll have to get back to you uh and and but yeah I I can I can keep up an update on the on the discord. Someone from the east team uh can can check on this. Yeah. Awesome. and we will update the EIP and whatever PRs we've already made to remove the time stamp inside BPO um array and instead it'll just have the

BPO one time and so on. So similar to every other hard fork on the E side. Any other E set questions? Okay. Um and I guess you guys have uh so e side summary for fusaka net0 you guys have the mod xp stuff that has to go in and the bo changes for reading the genesis file. I think besides that most of the fusaka devnet zero topics are cl related. Any other eite comments questions?

Great. Um so let's start the CL side topic again I guess. Um are there any open questions for how the BO format needs to be on the CL side? Uh no I don't believe so. Yeah. I I would have disagree with Justin. I I don't know how it has to be on the CL I mean we either we leave it as it is now and we're going to start downscoring peers or we have to do something on the P2P layer so that we can actually signal that we are on this or that fork.

I thought that we were talking about the format of the schedule not like the implementation. I think at at this point it's the whole BO topic in general. So yeah, I guess the open question is what Pus stated right now, right? I I mean do we need to agree on how this is going to be signaled? Is there any issue actually uh like we only going to have an issue if we bump bump the next blobs down, right?

because then we could have an invalid block which has more blobs than what you're expecting. You you can have it both ways. I mean, if you increase the blob count and you send a blob a block with low blob count, then the gas in the next payload is going to be different on one fork or the other one. Even if you send a block without any blobs, the gas might be different. So I think we need to we need to agree on on what is the best way. I mean I have a proposal but it doesn't mean that it's the the best proposal and I don't even know how to implement that. But but if at least we agree on like the the when do we want to start banning these peers

if it's at the handshake level we we agree that someone is going to go and specify it. And if it's not at the handshake level and it's on down scoring then we can just leave it as it is. Now it feels like if we want to hit the Fusaka Devet zero deadline, we should leave it as it is now. But it sounds like the handshake approach is better longer term. Would this be a massive change if we were to tackle the handshake filtering in the future of SAP net one and that would give us enough time for figuring out the how, who, what, and so on.

Okay, that sounds good. Any objections to this approach? Yeah, Barnabas, could we not just include the gas cost calculation in the CF and hell no. Hell no. I think that's going to add that's opening a whole other kind of worms. Yeah, I would also not do that. Okay. Uh since there's no immediate objection to POTUS' approach, um PUS, did you have an idea on how we can achieve this? Where do we specify this

P2P change? And no, I I'm sorry. I'm I'm not the right person and we just lost the expert on the prison team. Uh I don't really know. Uh it is part of the handshake message. I would just add this a single configuration on the handshake message. Um is this something that you guys could help us with? Raul. Yeah. Yeah. uh we definitely can but I honestly need to understand a little bit better why this is not formulated as a fork uh in itself I I don't think I have full context here so maybe oh I can I can actually answer to that thing if we specify a full fork then that adds it depends on the client but

at least I can tell for prison it adds a lot of boilerplate a lot of code duplication a lot of new testing that needs to be added we are getting good at it we went through many many forks But this is a a place where there can be a lot of bugs included and it takes a lot of time to actually check that we are adding everything to at the same time correctly and it's fully tested. So we want to try to avoid this. That was the whole point of this BO forks. Got it. Got it. So let me let me restate that to to make sure that I understand it. Uh basically from the protocol perspective and from the conceptual perspective we kind of agree that conceptually it is a hard fork but because of implementation difficulties and practicalities it's better

formulated as an independent entity to be communicated on the wire separately. Correct. So we want to minimize what what are the things that are being communicated but but exactly what you just said. Okay. Okay. Yeah I I can stand behind that. Um yeah, it's it's a matter of adding a field in that case and maybe like a hash of the BO um schedule if um if it's if there is a standard interoperable format or like something else we can we can figure that out. So um Awesome Harry you can you can you can assign this to me and I can help steer it.

That's amazing. Thank you so much. Uh yeah, Terrence actually curious what other CL team think because I don't think I fully agree with like if today if you look at Fata right like just pure does by itself it's actually a quite simple change because there's no block structure change there's no state structure change so it is a hard fork but the only changes are of course the new like P stuff but if without P does the only changes are just P2P which is what we wanted, right? We want to have some sort of like time activation and you jump to a new subnet and stuff like that. So, basically,

yeah, basically I do think maybe it is worth looking at like a hardford as a approach versus like trying something else, but I'm not so sure. So, I'm actually like curious what other CL team think about that and I and I could be wrong. Yeah, just just to just to add there um sorry also kind of like take my perspective from somebody with fresh eyes and kind of like you know with a bit of um lack of knowledge here but it it sounds like a lot of the concerns are based on like how we approach hard forks today in clients which is by using the boiler plate and so on. But um given that we're like the solution that seems to be agreed here is to add a protocol

um field to avoid all that. Wouldn't it be simpler because all we need in reality on the wire is to bump up a number on the protocol which would be the fork itself right and that number is coming from yeah all the system to actually that that requires boilerplating but maybe you can intercept that and maybe we can have something like a second path that takes precedence um and at the implementation level and that could be an easy easy thing to implement. So, it does not activate the entire traditional hard fork machinery, but it's um but it's it may be a hack quote unquote, but at least it does not percolate at the

protocol level, which I think is going to oify and it might be hard to pull out in the future. Sorry, I don't know if that was that was too long or maybe unclear. I can rephrase if necessary. No, that sounds like uh silence of agreement potentially. Uh but maybe we can create a thread for this topic in the uh the consensus dev uh channel on Ether R&D and discuss a longerterm solution.

Um either way the decision for today would be that this won't be a blocker for Fusaka DevNet zero. Um we can come to an agreement on what the decision needs to be for Fusaka Devet one and then block over there and it would be great if um we can if Raul you could create the thread on um consensus dev and then we can take it forward there as to what the proper solution should be. Sure. Awesome. Thank you. So that should be the BO topic. Does anyone else have any points to add or discuss for BPOS's?

Okay. Um let's move on to folk specific stuff. Um so pureas in itself uh we do have devet 7 up and running. Uh, Barnabas, do you want to give us an update on how it's going and if there's anything worth knowing? It's been pretty smooth. I think uh the back filling is the only question at this point. Uh whether clients are able to backfill and I think every single team is testing that independently. I haven't actually had the chance to take a look and do uh thorough testing.

Okay, got it. So, it's just a question of um clients actually testing their code and making sure that it's working, right? And uh we also have a checkpointing uh that's fully compatible now. Nice. Uh do any CL devs have an update on backfill? Has anything been harder or easier than expected? Something that needs discussing today or is it just a matter of time now. Okay. Um I'll take that as a signal that it's just a matter of time then. Um

Prism doesn't implement backfill. Okay. yet. Um, yeah, do reach out, sorry, do reach out to us and we should be able to help with testing that. Um, but yeah, other than that, I think we'll assume that client teams are working on the topic. Um, will do you maybe want to go sorry, Barnabas? Yeah, go ahead.

Yeah, my quick question would be if every client team would be on track to ship uh fa0ero images by Monday, next week Monday. We we wouldn't need like uh every single client combinations, but it would be nice to have at least three uh ES and three CS. And it looks like we already have three. Yes. Yeah. Mario, I think the main problem would be um that we haven't finished tests. Um the

main blocker has been so far that we are creating a new um east format to run um PRA blobs and verification of the of the proofs. So that's been a little bit complicated on our side and we're still like trying to fix that out. Um but I don't think we will be able to have I mean maybe maybe for for the end of the week we could probably have the finish with the test. Also modex is still work in progress. So I think we are the main blocker at the moment. Um if we want to launch uh without without this tests I mean it's it would be okay as long as we don't trigger mod x probably uh but yeah I think generally next week is going to be

like safer for us to have a release of east with the mod x test and also the pas test. Okay thank you. Um yeah, I think since we have Pas DevNet 7 running, we uh we can still take a call on it um on Thursday if we urgently need Fusaka Devet Zero or if we can wait a few extra days for the test releases and so on. Uh but it doesn't sound like a decision we have to take today.

Uh would you guys also be having a BO test, Mario? I need to check on that. Um, yeah, I would definitely have to do it somehow. Um, but yeah, no, I don't have an answer now. Yeah. Okay. Uh, if you since you guys already have a lot on your plate, maybe the BO test for now can be done on curtosis cuz we already merged in the PR/ have one open PR left to have the ability in curtosis. Um, so for now, we can just do BPO tests on curtosis and then eventually they can come to execution spec test. So you guys don't have to spend time on that right now.

That that sounds amazing. Yeah. Yeah. Okay. Thank you. Cool. Um will do you want to maybe take over a bit for uh PA spec discussions? Yeah, sure. The I think the majority of items have been discussed. There's two that are uh still open. the 519 that's tracked on the Fussaka DevNet zero spec um which I forget who opened that oh Manu um open that not sure on the status of that and then also Francis the uh get side get blob sidecar spec uh still

continues to be open which it's been open for a while not not sure what the uh holdup is on that or if anything's blocking it. Um I can talk about the first one. Um, at least from Prism, we are very probably going to implement the same strategy that lo that is to say have a blinded local flag internally.

Uh could you repeat what the flag does please? Um so it's written um in in the in the issue. Um basically this bl user say to the beacon node. Okay. Um if you are um building a local bidding block with some blobs uh do not send the data related to blobs to the validator client and the validator client won't send won't send them back.

Um but uh the main con of using this is that the node operator must have a sticky connection uh between the validator client and the bean node. It's a it's a needed condition and the main pro is that it will save a lot of boundaries between the bean node and the and the valid client. Um my main proposal in in this uh git applicate was to do it by default. Uh but the main issue is that in this case we have um stateful uh beacon API which is something we

avoid we avoided to do um with the beacon API. And so using this um implementing a blinded local flag for a client is kind of hack to to avoid yes um big big data um transmission between the beard and valid clients. Okay. Um, are there any other points

people want to add to the PR or should we just reach out to the maintainers to be merging it soon? Okay. Um, we'll follow up on that later then. And then regarding 524, I don't see Frances on here. Um I don't know Justin if you have any context on that. It seems as if that um it hasn't received any conversation for uh several weeks. So I'm not sure if

it's just been forgotten or if it's blocked by something that I'm not catching. Uh I don't really have any context on it. I just left your Okay, I'll I'll ping Francis. Um, that's really all I had. And then I don't know, POTUS, I saw the the post that you shared with uh that you did the work on the RLNC uh the random linear network coding uh as it relates to like uh determining max blob count. I don't know if that's I just added it into my uh list of things that I'm keeping track of. I don't know if that's uh No. So currently this this linear coding

is only being tested and implemented only for broadcasting of blocks. Uh there's other people uh Franchesco's here who's been evaluating the viability of random linear network coding for blob propagation but it's not really clear I mean currently with the current uh assumptions on that work it actually makes it worse uh so so for DA and for propagation of blobs that type of eraser coding is still far is early research Great. Thanks.

Yeah, I think the RLNC stuff might be prime candidate for new ACD discussion topics. Perfect. Yeah, this is uh by the way, just chiming in. This is something that the peer-to-peer networking team plans to also help drive. Um, so yeah, happy to to help here. One thing that I wanted to say is that I I agree in that in itself in itself everything else um as it stands today it probably won't help and to actually truly leverage the benefits of approaches like network coding well we're going to need to change the meshing topologies and even use transports like UDP um and and other stuff so or unreliable datagramgrams and

quick and stuff like that. So, so yeah. So, it's a it's a major work stream. Great. Yeah. Other than that, everything else seems to be covered on the on the spec for Fusaka Devet Zero and was discussed earlier in the call. Awesome. Thank you. Um, so any other blockers towards DevNet Zero? Great. if you could discuss some MV uh track on Fulu as well. So last week I tried the mock builder and we seem to have some issues and Pan mentioned that uh he was getting on it. Uh but I'm not

sure if anyone would have an update regarding the MV stack. Yeah, I'm guessing the builder specs have to be updated for Fusaka, right? That should be done already. Yeah, we have like a provisional uh version of those. There's We might change them, but they're good enough for Any of the clients should be ready to be tested with, by the way, because uh Pan mentioned that it was a lighthouse bug, but I'm happy to try it out with anyone else if anyone have done the implementation.

Uh just be warned that Pawan's um mock build uses lighthouse underneath. So if there's a lighthouse bug then one other client testing it won't help you. Yeah. But he mentioned that uh this specific bug that he thought was uh not related to lighthouse like uh the mock builder should in theory be working. But yeah, we haven't the way to verify it. So yeah, I think we can push more for that once we're done with DevNet zero and we have basic stuff working. Um but yeah, I think it's a good idea for teams to

start looking at a release. Um I see Camille was on the call as well. want to give us an update on the performance devets. I yeah I was off for last week so do not have much but captured what we what our team done. So for performance devet we are uh in a preparation for a second version of that which will be more mainet aligned and it will be clean clearer for everyone uh to ensure which gas limit is more is safer than other comparing to original perfet which was running some crazy numbers and was

exposing some uh performance uh leaks some some performance possibility fixes. in clean cleaner way and also in meantime we are reviving one of our previous uh researches with up codes research with worst case research and right now making it much more better observable for any of the client teams. So this is work in progress and yeah we will run it again on the latest versions and share some results on the gas limit research uh project. So right now, yeah, we're still working on new perfet.

Awesome. Thank you. Um, and I think the other topic related to that was we have 60 million on already. Uh, do we want to start pushing on hoodie or has anyone seen anything on that indicates we should stop right now? I guess as signaling already started to happen on mainet, we should do that on hoodie as soon as we can so we can see if there is anything problematic on bigger amount of validators.

Okay. Um yeah, Mario, just to your point, um Sam did an initial analysis once, uh Sepia did went into 60 million and he didn't really notice any changes or nothing worth writing about yet. Uh but we have to still do a followup and we're first finishing up the PCRA follow-up before we do the 60 million followup. Um okay, so that sounds like we should go ahead with um 60 million for Hoodie. Sorry, for hoodie at least. Um, and I see that there's a bunch of discussions on the gas limit testing topic. Um, especially related to 10 MB blocks. Do you do you feel like discussing it Tony

or I don't know if Ben is on here? Hey. Um, I mean the network will basically break without it. So I think it makes sense to to be into sucker and then we don't have to worry about that as an element. Um because we can't we can't propagate blocks larger than 10 megabytes. So we should cap cap it and then we don't have to worry about the block size when increasing gas.

Got it. Yeah. Um, yeah, but I guess that isn't directly related to anything that happens at 60 million gas, right? No, we're fine to about 105. Okay, cool. Um, and one thing that PK also brought up over the sorry over the last week is that um the 10 MB block size also includes um a tester slashing. So, we will probably test um hoodie at 60 million with a bunch of slashings in there so that we can make sure that this will land up on the network fan.

Okay. Um anything else on the performance gas limit topic that we should be discussing today? Um there is a discussion about transaction limit and um I don't know if it's worth discussing Uh yeah, I'm all I I only saw that discussion from earlier today. I haven't fully caught up on it. Um I don't know if anyone has something else to add to the topic right now.

Um so originally it was set at um 30 million gas. Um and we're thinking that maybe 5 million gas might be more sensible based on what transactions are on chain. because the ones over 5 billion are either subdividable into smaller transactions or um Zen mining which are also subdividable into smaller transactions. And if a transaction eats the entire block, then it's it's not very fair to other transactions that want to be in there. And um you can't

parallelize a single transaction like if the block is a one transaction that then becomes our worst case in terms of parallelism. Yeah. Um makes sense. But maybe you could add that as a discussion topic for ACD this week. I think that would give more people time to catch up on the discussion to begin with and probably ACD is a better platform for discussing wider protocol changes.

Okay. Um then the last topic on the agenda for me is um history expiry. Has any client made any progress over the last week? Um, something people want to discuss, releases, defaults, change documentation. Okay. Um I think there is a portal call happening um immediately after this. So in case any client teams are interested

in that then please head over there to discuss history. Um anything else that needs discussion today? Okay then. Thank you everyone for joining and have a nice day. See you guys. Thank you.