All Core Devs - Testing #36

Transcript

That's okay. Perfect. Hello everyone. Welcome to Elor Devs testing number 36. Today is May uh 12 and we have five items in the agenda to discuss today. Um and I think the most packed one is going to be the discussion on which CFIDs are we going to include in the fusaka.net zero. Um along with beeras and uh a couple more of the topics to discuss is uh block scale inclusion in the CL and uh discussion about history expiry.

So I think we're ready to start and yeah the first item um I wanted to bring up the discussion but I think it's not going to be that much necessary is any PCRA related uh discussions from last Wednesday that anybody wants to bring up today uh either findings or any relevant points or topics uh uh about the the fork that anyone has in mind and wants to share. and Miguel is uh raising a point in the

chat. The deposit mechanism transition has been successfully finished 17 hours after the fork. So it pool it on it one data pool can be safely removed and this might matter for the history expiry discussion. Thank you Kyle. That's very good news. Anything else for Petra findings or anything worth sharing. All right.

Um yeah, it was very smooth upgrade. Yeah, it was it was great. Very uneventful. And James from Prism uh is highlighting that they are still looking into some performance things. Uh I think that's expected and yeah cool. If nothing else from PTA I think we can just jump into the next topic. Um I have prepared a uh tracker where I just tried to consolidate the filling or sentiment um regarding which EIPs should we uh introduce into the Fusaka net zero. Um, basically this list is all of the CF5

um, uh, EIPs for FOsa and um, I can uh, start by summarizing the uh, sentiment from steel which is basically testing and specifications eels and east. Um, and generally the we are only opposing one of the EIPs but not strongly so and if it's decided in this meeting that it should be included that's fine by us. Um and that is the uh RIP 7212 but other than that still team uh thinks that it's okay that should we add basically every other EIP that's uh uh that the the the rest of the uh teams consider important.

So I think we can start uh um just with the list and go each EIP by EIP and then we can uh just hear opinions if anyone's here in the meeting that wants to raise an opposing opinion or or for opinion. Uh yes. Yeah. Just uh I think it would be a bit quicker to go through the pure testing first before we dive into the what should be included in the next one. Uh because I I'm worried we're going to be running out of time and we're not going to have time to give a previous update. Yeah. Okay, that sounds fine. Is will hear in the are you are you ready for give an update?

Yeah, I I I can give an update on like the latest on per 7. Uh so we just launched on Friday and we had flu fork this morning. We had our spammer uh break around the flu for but it's been fixed and we've been uh spamming blobs and we have a 100% participation for now. We are still waiting for different E teams to get on boarded. Uh Bezu and Aragon uh still don't have any validators and they don't seem to have a full branch right now but hopefully we can on board them soon and that's about it.

All right, thanks. Um, will, do you want to go over the pure uh updates first? Uh, sure. Yeah, thanks Barnabas. I I think that's kind of the major update is uh shipping DevNet 7 and uh activating the Fulu fork on that this morning. Um, there's still the item, I don't know if Justin's on the call, but we were trying to urge people to make some decisions on the BO block blob schedule. Um, so that that could be merged last Friday. It looks like it has been merged. I don't know if there's still people that are in decision uh on that or what we could do to advance it.

Uh, we were just waiting until after this call to merge it. Uh, so I'll merge it soon and then I'll make a new PR to backport it to. So that's the plan. Great. Um, yeah, I think that I don't know unless uh anyone feels otherwise. Those were the the major things that I had uh kind of documented on the list. There's a handful of other um small open APIs around the beacon API or sorry open PRs, but nothing major. Uh Terrence was your question about DevNet zero spec about the blob schedule stuff?

Yeah, the BPO. Yeah, I think it should be part of DevNet Zero. My opinion also uh what should be the timeline we are thinking about for Z? Maybe in two weeks time. Is that realistic for everyone? Are all the clients came here? Um yeah, I think two weeks is fine. Even one week should be fine. Well, well, depends on what we want, right? I guess we're finalizing the EIP scope here.

Yeah, I I'm not sure if you want to include any EIPs in the net zero other than the BPO. We can also have like the one with all the agreed upon uh the piece that we agree on today. If it's just BO like speak for prison team of course I think we can do this in one week. Um how's the wrestling team's feeling over this?

Can the heels chime in? AC's cool with two weeks. Um, just to level set that would be the get engine stuff, the cell uh transaction validation and BO hard forks. Just to clarify, this is talking about the BPO only and not none of the other CFI EIPs. Is that is that correct?

So, not the PIDOS ones because there's there's pur work to be done on the E. I'm sorry, I meant uh the rest of the CFI. Yeah, that's Yeah. Okay. Any other comments from EELS? Never mind. We will be ready whatever will be decided to be added. But uh it's a bit unclear for me like what we need to add on top of the net 7 like what's

the uh the features uh you're talking about to to add in this net zero in to it the BPO and only if that's true so we can add it. So just to summarize this would be the first um devet devet zero for fusaka. It will contain pure das and bo only none of the other CF5 u eips will be included. So basically would this be the same as uh dna 7 or is there anything else included? I think we can agree upon that today, especially if there's some

very obvious and tiny EIPs that couldn't like delay that summer launch in two weeks. Yeah, I would just add that we definitely want to stick to that timeline. Um, so let's only choose stuff that we think we can hit there. And the main reason for having a more rigid timeline is that we do have an in-person meeting in June and we would like to at least have one devet through where we can find some issues rather than having everything in a devet and not hitting the deadline.

Okay. So, does does it sound reasonable for us to include two of the CFI EIPs? From what I can see right now in the list of uh uh of each client, the most requested one or the most uh important one for all teams seems to be the mod x uh related pre compilers that is 7823 and u 7883 that's on the top of the of the list of every single client. And I think those those two are pretty straightforward and can even be tested like very straightforward. can make uh prep prepare a release of tests in the next couple of weeks and uh it should be

included that in my opinion. Does that sound reasonable for everyone? When you say included are you referring to devet zero or devet one? That would be devet zero that is in two We would prefer those to go into a devet one. We would prefer to see the pure dos and bo stuff in isolation. I mean from from the suggestion this means the dev zero would be only testing the video because paradas is already being tested right now.

What exactly is the would the BPI be testing? Because unless you're having lots of mini forks, is it pretty? Yeah, that's exactly what we want to test. We're going to have a bunch of BPO tests on this uh definite zero. So basically, we're going to be bumping up the glob count, the target and the max, and we're going to be dropping it back down. Then we going to drop it or push it back up and drop it back down. So basically, we want to test all the functionality of the BPOS.

Anyone else has uh posting or comments on BO only fork for Dev Zero in two weeks. Never mind. He's fine with it. If we decide to add modex to APS, uh it's fine too. Yeah, ref's preference would be to include mod x, but if we don't, that's fine.

Also, doesn't? Yeah. Well, is there reason to not include mod x right now? Uh, for us, it's a timing issue and simply isolation of pure dos testing. So, Basu is not fully on the pure dos devet. We are not struggling to include bezu also in pas or in fa0.

I missed that. Barnabas, you're super muffled. We miss your comment. Could you repeat please? Yeah. Uh I'm not sure if it's better now or it's still bad. Yes, that sounds better. Yeah. Okay. So it's also possible that we do not include bezu then in physica devnet zero and we would uh like right now devet 7 is basically for uh meant to be for pure testing. It would be very

good if Bas would have a nonb but a pure dust ready branch that we could be testing on on this feature because right now we are basically like holding back features just because bezu is not yet on on pure devnet. So I would I would actually push for having mod XP in NVN net zero and have all those features tested as well especially if all the EL are on board except BU and then try to push BU to be included in uh PL I mean watch DevNet zero without all the

clients. I think that's fine. So I have a question about PES. We are working to implement it on the CL side in Kaplan. Um but uh is there anything uh required on the EL side because we we won't be ready in in two weeks u on the CL side but maybe if if Yeah. So is it something kind of trivial on the L side or no changes at all on the L side? Um maybe one of the EL devs can talk about the chain set but um last I

checked it shouldn't be a very massive chain set but there is a kind of a there is a change. Yeah there is a change. Oh okay and some just share the um the PR for the execution APS. I think that's the main chain, right? The engine API. There was also a networking change. Um maybe Roman has some details on how large the changes were.

Yeah, it's a small networking change to treat the proofs differently and and then mostly the engine API changes. Yeah, for us the engine API is less of a concern than it is the um checking the cell proofs on the transactions that are incoming. We have an issue with uh our native crypto integration that popped up. Somebody was reporting it in Discord and so we need to nail that down before um being certain we can ship the cell proofs.

Yeah. So summarizing it, uh there is not a lot of challenges but they are definitely not trivial and giving in the chat is mentioning is asking for details on the on the issue. Justin, yeah, I was going to post those in the chat. It's a we're like I said, we're still investigating it. It's a really weird packaging issue that's very very isolated to like uh OSX on Intel type use case. So uh it's weird and we don't understand it which has got us reluctant to moving forward. Um but on the other hand it's

an almost negligible proportion of our client base. So um we we need to understand this issue better before we disregard it. Could we not use a branch to test in the meantime? I mean, I understand that this is a super niche uh bug. But in the same time, it would be very valuable, I think, to have PZU on boarded on. Yeah, nobody's debating the value of having it done. It's just not ready yet.

Okay, it seems like um also we are divided on mod XP. Um should we defer that decision until uh ACDE because it seems like um if there's issues right now with pure alone it might be it might delay um even further if we include mod XP that's just the sentiment I feel. Um, any thoughts? I mean, didn't sound like a pure issue to me.

And Tim is asking in the in the chat if there's other clients with issues at the moment. Yeah, and I guess maybe to expand on that a little bit. This I if we do have it seems like we have ref and nethermine who could uh start working on mod XP. Um, I feel like there's value in trying to get three clients to interop and, you know, find any potential issues in mod XP given how uh uncontentious the EIPs are. Um, so that's I would personally bias towards having them included in

DevNet zero. Um, even if it means like yeah, we don't have all clients on day one for DevNet zero. They're also pretty trivial EIP. So you can even imagine something where like you know if say baseu is fixing their bug and doesn't make it for devet zero at all by devet one like the incremental work to add mod xp should be pretty small. So they could maybe like join straight into devet one or something like that. Um, but I I feel like mod XP is so uh um I don't know unanimously like desired that we should just get testing it ASAP. And then it also gives us the more time if we if we've like confirmed those to have further discussions in ACD about like

what would be the bigger features we'd want to bring for DevNet one um while keeping the focus on pure ass and like you know relatively small changes in the next couple weeks. Yeah, also we can start repairing the tests um in the in this week. Yeah, we're going to priorit prioritize um mod x. Uh some mentions that we should add the payup code, but it feels to me that that's higher complexity than mod x. Uh so maybe we should defer that discussion

for dev net one if that's okay or does anybody feel like we should definitely include it in devet zero? Yes, Johan. I just want to say I don't think we should include it for that net zero and that's also because I have a PR open for uh for pay because the the current EIP is not uh um it it misses some edge edge cases from the EIP and if there is some some offer of the pay up code here then please review this EIP because I really want to get this in the Faka but uh none of the authors had has left an review there yet.

will be really helpful. Cool. Okay. It sounds like we have a decision uh at the moment. So uh just to summarize DevNet zero in two weeks that that includes spear and bop uh bo sorry and the two mod x uh EIPs and that is um EIP7823 and EIP7883.

Are there any opposing uh opinions? Cool. Okay. So, I think it sounds like we have a plan. Um, great. Um, um, yeah. Anyway, I have this this other document. Um I I I we can continue on adding things to this and uh just please uh keep an eye on it. Uh if there's any opinions on the rest of the EIPs, please just reach out and we can just um discuss uh for

the EIPs that we have want to include in the middle one. Okay, cool. Um yeah, and going back to Pieras, I think we uh we cut that off. Uh will is there any other discussion on per that needs to be had? Uh no I don't believe so. There is a small suggestion to limit uh block count per transaction uh uh to like uh uh maybe not to the next uh

internet but maybe we could discuss it and um confirm potential inclusion like one or So the idea is to bring uh additional field that uh would mean that uh uh like in range of in time range of current uh uh fork uh transaction cannot hold more blobs than load.

Yes. Yes, it will be extremely helpful to to have a cap on uh max number of blobs per transactions like uh if we aim in having max blobs per block at uh let's say 72 then like having 72 block transactions will be like uh harder to handle than than transactions with with lower amount of blobs. uh we see no point in in allowing such a big amount of data in in one transaction. So having a cap on on blobs per transactions to 12 15 or or whatever

uh uh will make our life uh simpler and uh yes we would like to uh to have something like that if if there is no position. Yeah. So I agree. I also raised my hand as well. I think like another venue to bring this up is at the role because this will change how uh layer two raw batch poster work typically because today like layer 2 they t some layer 2's

l transaction but some of them actually do prefer uh batching as much as they can to essentially amotize the execution tip amount because currently the tip is specified in the execution format rather than the blob DA format. Because of that, there is a cost saving that you can do to essentially batch post blobs like for the bigger amount such that you just have to be pay tip once. So I guess the raw venue will be like yeah definitely can bring some the raw venue. I don't see there's reason not to do this but it will be good to give Rob a little bit of heads up because this because because this this this will

change how they work and then and it's also worth mentioning different robots slightly different like base opt like like they they they all work differently here. Yes, Francis. Um, yeah, I agree with Terrace. I think um this there's no reason to not have it. And uh I guess my suggestion or like my like two cents here is that can we maybe tentatively include it and have clients start working on it and we just

kind of like give it a like initial tentative number nine or whatever to start with and then we we can start gathering like informations and stuff. But I feel like the work can be started um now. And just for context, do we have an EIP number on this or is that work in progress? I assume no EIP now. Um,

yes, I think we can. I I don't know if if it's a good call to add it to Devon, right? I don't think so. It feels to me that if we add this should be added to the net one at least. I don't think there's a EIP for that, but I do remember seeing a consensus spec PR for that. see if I remember correctly. Yeah, there's a PR link in the chat. Thank you.

Yes, Kevin. Kevin. Uh yeah, I vaguely remember there being this proposal to have a 10 megabyte limit on the transaction size. Uh does does this limit also include the number of blobs that are in the transaction? I think what that was a block limit, right? uh if I'm not mistaken you're talking about 7934 and that's RLP execution block size and I don't think it will include it because it's only the RLP which does not include the network regression of the transaction so I don't think this is uh or do you mean like u

I think there was a oh I thought there was one to limit the size of a particular transaction on the P2P network or there's one to limit the pass of the transaction. Okay, I see. Right. Yeah, I know that one. Yeah, I see that your hand still up. Do you have other comments or was that from the last time?

It was from last time. Sorry. All right. Any other opinions on this topic? It feels to me that is uh deferred at least to the middle one. unless every anyone wants to chain. Okay.

Um if not we can move on. Um next topic would be um this PR. It was raised uh as a topic by Alex. I don't know if he's in the call. Um this is the the link to the PR and it has emerged. I don't know if there's any other things that you want to add uh to this topic, Justin or uh Alex. Uh, no. We talked about this just a little bit ago. Uh, I've just merged it.

Okay, cool. Sounds good. Um, if nothing to discuss about that, we can just move into history. Uh, Barnabas, I think that you were going to discuss this today. or was it Partosh? Uh yeah, I can try to discuss mic keeps dropping off. Sorry. Uh so we wanted to begin testing uh history expiry possibly with portal and we have asked them to add the support for curtosis so we can try to do arbitrary history drop at any specific

height. Um this is still work in progress. uh regarding dropping history in Sapolia and uh mainet we were discussing to push the uh possible deadline for that to next month. So like 1 of June for Sapulia. How would everyone feel about that? Because the original deadline was 1 of May. But I think we still have some um ELS that haven't defaulted to dropping history on Sapia. This is pretty much history only.

Yeah. And in terms of readiness, um, please also include like documentation or user guides or something that we can point to and test especially for a public test net. Um, so would you guys be okay with 1st of June as a deadline for including documentation? Base is fine with one gin. other eels?

I don't I cannot say anything to that yet. Um, we have it in the code. Uh, but it's hidden behind the flag and we probably not going to uh enable it by default um for quite some time. So um yeah, but uh I think we will probably be able to uh create documentation in two weeks. Any comments from Nethermind or any comments from Argon or Red?

Um, I'm checking in with the team right now. U in Argon we have a PR but it's not merged yet so we are still reviewing it and um but uh in any case we won't uh most likely we won't be we won't make a release by the 1st of June. So we maybe we'll make a release in in a couple of months. I guess that's one of the questions. Is there some reason we have to coordinate this across clients or is the

understanding now that every client just enables history expiry whenever they're ready? I think we agreed to do it by by Fusaka. Uh so I think uh yeah to me it sounds like as long as every client does it before it's okay. I think we don't have to coordinate it and basically just uh say that we will not drop before uh before some date right and this should be good enough coordination and then it's up to client when exactly we will release something

here. Yeah, I think the main issue with that approach was we had agreed on a deadline of May 1st and essentially it didn't happen. Um so the question is are we just now setting arbitrary deadlines or is the 1st of May like the 1st of June does it have any purpose besides just a signal?

I think that's true but okay because the first one was arbitrary and then we wanted to kind of delay it till after Petra shipped when so when Pekra slipped a little bit that was no longer the case and so now we have another arbitrary deadline which is fine but it's after PCR which is the point so I think that's that's how I square that concern Perry okay um so we can set it as 1st of June and then we just bring it up on the weekly meeting to see if there's any update and try to at least have some clients that are um ready by then. I guess what we can do on Sepia.

Yeah, this was this is okay. Uh, sounds good. Anything else regarding history expiry? Okay, just to summarize, uh we're

expecting 1 of June to be a release or document and our documentation for Seapoleia uh history expiry. Um great. Um yeah, I think that's everything we had for the agenda today. Uh is there any other topics that anyone wants to raise? Okay, sounds good. Okay, so yeah, we can let everyone go with 20 minutes to spare. Great. Thanks everyone for joining.

Thanks everyone. [Music] What's up?