PeerDAS Breakout #20

Transcript

e e e

I [Music] all hello everyone e all right I'll just send another U

reminder to the chat hello hello can you guys hear me yep nice okay guess um yeah let's get started hello everyone welcome to the P

call okay I think looks like we missing a few clients but um I guess we can get started now um yeah I think um okay yeah uh I can give a bit of update on the lighthouse side to start with um I've been looking into a um interrupt issue with prism lately and um there was an issue where um the gossip data columns were not getting sent to the prism note um and emmanu discovered that um Lighthouse is actually sending PR messages to the the prism notes so um we look into that

and we found out that it was caused by a race condition um and it's kind of related to distributed block publishing so it's um when we send a when we send an I want request to prism node and then we actually get the blop from from the Y and by the time when prison respond to us we we we we treat we treat it as a duplicate so we ignore the message but then after but after a while we thought that prism didn't respond back to us so um we actually Downs scored them in Li to be lip top and then and then and then um th them as as a mesh Pier so it was a

kind of interesting race condition um but we have it but we have a fix for that um which is good it's a good it's a good find um thanks Manu um and then other than this we've got a few um sync fixes that are currently under PR reviews um and I have been also working on um the spec changes for um distributed block publishing there's there isn't actually a lot of changes but I just want to um have a clarification section similar to what we have with the neb get blops so just to specify um what's the behavior once we get the blow from the e um yeah I should have that draft um out

maybe tomorrow uh for review and I'll ping in the chat um yeah other than that we're just doing a bit of testing on beet 5 and we'll continue working on Val at custody that's all from Lighthouse and and um I'll pass it on to Manu hello everybody uh yeah so I work a little bit on the issue that uh Jimmy just described a few minutes ago about pruning pruning stuff um also yeah um two weeks ago um I finished the PO request about uh validator custody but because of the hesy events this pair was

not reviewed and so n right now is reviewing it I I did the last um fix I hope this pair will be merged today um also I start working on um backfield not only validator custody backfield but backfield in general So currently prison backfields blocks and blobs but not columns and so I work on it for backfield from checkpoint and after of course for when when the validator custody increases um also we discover a nasty bug in prison like currently we store

colons in a file so one colonal one f one file on the file system and the issue is with the 18 days rotation period for super no we got more than 10 10 Millions files and we on the devet we exploited the I the inod sorry yes inod limitation and so the pris wasn't able to write anything on the disk and so we have to to work on a new design of the database to store data col every data col in one file that's all I did and also we have Nan from um from Bas who worked on um the fact that we can request from uh

by root colons for from any PI not only from supernes it was already the case for by R request but not by root and Francis worked on the get BL B2 so I know there is no there is still no extion layer supporting this um but he still work on it in prism to be ready when an exection layer is is ready and also fris works a little and an issue we had in in our database and data cols as well um yeah that's all uh Demitri yeah te we are working on

validator custody uh not much progress on it was distracted with kesy issues but this week I 100% on this and I think we will have good progress to to the next meeting uh that's all for too thank Demitri um I guess nimas Agnes you have any updates so couple of days ago I saw a weird uh incident in here 5 where nimus and fored off and very peculiarly it is it was forking off uh at a slot for which the

previous slot there was no lob site CS so I'm currently investigating that uh along with that I'm also working on validator custody but most of my attention is right now uh towards um Nimbus is column syncer um effectively we are not so our entire column syncing mechanism is very independent we are not downloading uh blocks on under the same sync Handler there's a different sync Handler that downloads blocks so that we can sync fast and uh we can gradually backfill and since we are not um since we are not downloading blocks along with

columns it becomes difficult to group columns so for that I'm using the um hasht root of the signed block header which is a common thing in every column side card and that that that's something by which you can um group the column side cards usually apart from that um you have the like there are two mechanisms as we disc uh discussed earlier one is um a greedy mechanism where you're um optionally querying peers that have higher custody so that there's a greater likelihood that uh you can get what you need in

lesser range requests but we also um are working on a way in which we can sync totally without super nods just by reconstruction and full nods um that's we do it basically by range requesting whatever they can provide and we keep filling the recover Matrix and once uh it's reconstructable we reconstruct and we keep back filling like that and uh yeah I mean it's it's more resource exhaustive and I think it's a bit inefficient too but uh not relying totally on super nodes is sort of taking

the side of U the home sticker um apart from that there was a sync issue that occurred in devet 5 basic basically what happened is Nimbus lagged behind like a few epochs I think it was based on how the validator duties were assigned and what happened is the sink Handler got triggered and surprisingly the blobs by range was not gated U up till Electra so it started asking for blobs by range and it got down scored eventually and all of nodes

so that thing is fixed now and uh we are we are pretty stable in devit five so that's that's pretty much from my side nice um great to hear um uh I just got a question on the the Dual um syncing mechanism like do you default to to one of the mechanism like by default or and do you switch it over to the other one under certain condition so basically ideally we have a flag um and the default is greedy um but the thing is it's very easy to estimate um your

CPU utilization if you are an impartial Sinker like if you um if you don't like uh query peers because like U I mean I mean it's kind of a stagnant the CP utilization doesn't vary based on query uh but if you are querying it's a it's a completely probabilistic model um so like you you really don't know whether you're lucky enough to get somebody with higher custody and you really don't know how many queries do you need or how many intersections do you need so um that's that's something I see thanks yeah it' be great

to see um like like once you have it implemented it would be great to see some comparisons yeah yeah I I think I should be able to wrap it up by this week Max maybe like early next week but yeah it's coming nice thank you okay um do we have Lowa oh yeah I see ginda um I think Matt come make the call um ginda do you have anything to update Yeah so basically as Matt mentioned that we have almost done with our refactor and uh basically we have also put up a PR to simplify how Val validat custody uh can be implemented or is basically also

changes it and basically also change how it is help how it is written specs uh so so what we want to do hello sorry hear some background noise can someone mute um I thinkr there um I don't know if we if we have a host here all right uh seems to be clear now so uh so basically um so what what we are proposing is that instead of uh

having uh our Dynamic valid data custody what what what could be done is that spec for example could be uh revered to say that the uh that the beacon node uh is started with a supported validator validator stake amount and then basically it for for that particular uh nodes runtime that uh uh that custody is fixed uh for the beon node and then when the validators are connecting to it for duties at that point Point uh bonot can decide whether uh you know validators that are attached to it they are going

above that attach Stakes threshold so it can re reject the duties of validators that they are going above it and uh those errors will then basically show up both in bonod as well as in validat clients and the user will be able to figure out okay uh this particular bonot does not support uh greater than uh whatever is a attached amount of stake whatever is a sported amount of stake in that particular big node and that is basically our proposal it it solves a lot of things because it moves away validator indices from the beacon node operation uh and the spec where basically it moves that pollution and

makes it nicely static so whenever we canot is spin up it can always check whether it has the custody and can resync before uh before basically accepting duties and all that so that way things uh get very simplified and uh simple for the weer note and uh and for uh for the validators basically uh uh they so so the current Uh current function that says that okay these that these many validators these these validator indices have this much stake in the uh in this particular state that basically gets moved to uh that those checks get moved to uh to the Val to the

beacon and validator apis uh and and as kman also mentioned that maybe there we also Define a better mechanism of how to register a validator to a beacon node uh that way once we have that that mechanism clearly defined we can basically uh even respond with proper eror codes at the particular time when our validator is trying to register yeah um I've shared the link in in the chat um Franchesco good um do you still want to say something I S you have your hand up sorry it was my mistake okay cool cool um yinda um is is it is a link that I share the one you

talking about oh let me check 4154 yeah that's the one okay great um yeah um yeah I don't know if teams have a chance had a chance to look at it yet so maybe we'll we'll spend this week um yeah it' be great if all the client team can have a look at the the proposal and then um we can uh we can like uh just comment on the pr if there's anything that people want to share um yeah great um okay so got Loa uh

this gring here we got got H yes uh so for cring uh for this week uh we will try to um optimize our uh sying logic so because uh the sying right now is U we uh use a lot of uh resource so we facing a resource overload while we sinking so we try to optimize that um because like uh the way that uh we are uh checking uh to a sub block we have to delay until the all the colum are available and the request uh load

was like uh H so we have to optimize that request yes so this week we will try to fit it and if we be able to Fig it on time in this week we will try to look in into the valid validat cost nice thank you an um yeah I think it would be good to get a uh a temperature temperature check on on like where we are with the custody because I think um bab did ask in the chat like where the teams would be ready um I can provide a bit of upd update on Lighthouse side we we' started working on it we've got a few PRS open but um we

are um not not close to finishing yet so I think we probably need need another maybe two weeks um but I'm not sure aish uh yeah so I was um curious about maybe a potential spec change that is um if our validator custody changes like let's say it increases and what happens is the custody columns since it's governed by like I think it's decided by a hash function or something so I think the numbers like the indexes should totally Achi so that way whatever columns we backfill goes corrupt right

so we need to re back fill it um can we like advertise the fact in our DNR or metadata that we are backfilling so like as an implementation detail or as a spec people don't Downs score us so that that's not the case that whatever you had before um kind of drops out of the list of things you have to custody when custody goes up you custody all of the things you were custody before and something more like it's still is it's it's like a uh the things you're customing before is a prefix of your current custody oh um I thought it's random but I think still it would make

sense to um advertise the fact that we are back fing um so the way the we had a concern like this before the way we decid to handle this was to write in the spec that basically you just don't increase your advertised um what's it called the custody group count um until you're done back filling so you just don't tell other people that that you have a higher custody until you you actually have uh so in the pr 4142 basically then this also become simpler in the sense that uh before uh you you get synced you fill up your whatever custody that you

are missing before you show you are sync but yes till that time maybe uh still you might still advertise a higher custody uh level but that could be a small time and the window because the window is small for uh for the EPO that you need to maintain the custody for okay nice um so it seems like we still have a few pending um discussions on on on validat custody before we can

probably provide a accurate estimate where we are given that potentially change so I guess this week it would be be great if um client teams can um have a look at kenda's PR and um and provide feedback if possible um I see a few chat in the few I see a few mess in the chat is there anything that anyone wants to talk about regarding B custody before we move on okay cool then uh we can move on um the next uh feature distri distributed blob

publishing um previously it's U it's called distributed blob building but um now if given that we are planning to offload a computation to the transaction sender so it effectively effectively becomes distributed block publishing um and we kind of just to get have a bit of understanding on um where teams are at the implementation have have any teams started implementation are you talking about G BL get BL V2 um well um we don't have V2 yet

so I was kind of asking about V1 um because at the moment we don't have to yet but um it's so it's still distrib block building but I was kind of curious like how many C they actually published the data columns that was computed yeah so at prison we choose not to use V1 but directly to implement V2 uh of course as I said no change that the E needs right or is this something else yeah yeah we need to there is no ready right now but we still chose to to start implementation with V2 of course it's kind of block right now but at least we we have

something uh do you have a PR or a spec I see Marius is on the call just unmuted so I let him talk yes so uh we're planning to implement V2 today um and have like a b version that uh that turns all of the blobs and the transaction pool to the new version so that c contest should be done today or tomorrow okay cool uh let me know and I will try to test thank you that's fast nice thanks

Marius um yeah any other clients want um have distributed publishing working um we have dead blobs but I don't think we have reached that stage where we actually didn't publish the so I still have to know what we have the things done but yeah I it doesn't happen S I missed that aish did you say you have kept lops but you don't have the publishing bill yeah I mean we have it written but we don't have it in in exercise in this definit okay

thanks um what about te sorry I missed the question oh yeah so the question is um do you guys have distributed blog publishing working already like doing a get blog from EO and then and compute column I card and publish through Network yeah yeah sure uh it's j on by default for super n great thank you um any other clients want to update okay um then I see that we have a

few e teams on the call um does e teams have any updates related to PS okay so I I'm uh I'm writing uh EL support in nether mind right now uh and uh generally it's uh in progress but I have one issue I'm struggling with and I would like I would like to clarify that I am missing something or uh or or we missed something so u in when we receive a blob in in Blob transaction in a new format so with Stell proofs we need to

verify it and uh like in Old structure there is one blob one commitment one proof in new structure it's uh uh one blob one commitment and end proofs so in one blob it's it's 128 for now uh sell proofs and when when I'm trying to verify it in CK ckcg it verifies C kg proof buff it is re requiring one commitment per one cell not one per the whole blob so my question here is I am missing something or we need to extend commitments to not only

proes I think you just have to repeat the the same commitment like 128 times uh like for each cell because just because the function can be used for for verifying cells from different blobs like you could use this across different blobs um sorry yeah guess so if you I said you have to one commit 20 times that's also not right you have to repeat like um the commitments for the first blob 120 times and then the commitment for the second blob 120 times and so on so you basically have to match each cell with the commitment and it's going to lead to like a bunch of repetition okay thanks for thanks for clarification so I I will do it and then I think uh uh it will be uh yes when it it will be

finished I think I can uh um prepare our uh get blobs like with C communication and it should be done like soon that's the current implement take advantage because there's some optimization that can be done when you have many for the same sorry um I don't I don't think I got that um than C you're breaking up

you're breaking up a little bit um would you mind repeating that oh so there is an optimization in the verification function you have so like I wanted to check if anyone knows that ckcg has done that if you repeat the commitment does it automatically compare those commitments I don't know if there's anyone here but I I can ask Jus uh later yeah yeah we should check that because the original specs I implemented like basically allowed you to do a pointer to the commitment I think and that's like directly to advantage of this so I don't know if the can't run do but like what

those youth CAS course like massage yes te I have a general question regarding get LS that is um I saw the grafana charts that you posted a couple of weeks ago in yeah in P testing and I noticed a Mis rate um it was as you mentioned it was 0 to eight glovs El Globs per minute so

the point is like how much of an optimization is it really like so for us what happens is um when I try to like get get blobs working in of pectra the thing is there is a Mis rate and whatever is missing I'm getting it from Gossip it's like I'm not being able to totally bypass gossip blob gossip validation as well I mean if I could do that then I would save a lot of um like bandwidth and CPU as well but like oh I mean not not maybe not bandwidth totally but still at least what do you call um nine

verify kcg proofs and nine verify inclusion proofs on an average like not on an average like on the Max uh side um but there is a Mis rate right so that's mainly the reason that we are still uh not putting it in action in let's say in p as well like um because there is no there is again no clear spec whether we should retry or not um whether we should like do something else to get a better success rate from the El side um so that's that's pretty much the reason why we don't have it in

action right um yeah thanks um yeah um I had a bit of thought on that as well um because um with pias it's the heat rate is actually really important because if we don't have all the bloves then we can't we can't really compute the The Columns so it's this is something that that um that we um I think we should try to we should we should try to optimize um just to see how we can improve the hit rate and yeah I think I feel like we need to like probably spend some time working with the E team to see how we can improve the heat rate and um the the response time because I also noticed that between different EO clients the response time and hit rate

could defer so I think it'll be good to get some numbers on that and I know that there are some teams that are currently actively testing um and capturing some metrics on G lops yeah I mean so Dimitri mentioned a couple of minutes ago that he uses get clubs um for the super l so that would be my question like if you don't receive all the blobs then like a question for dimitry maybe like what do you do do you retry or do you receive the rest from Gossip um like yeah uh we just skip uh we just skip uh this this kind of

reconstruction it's not used so if we get all blobs we do it if not we just failed we we get it in normal way data columns and right exactly so exactly so that's that's pretty much my concern like even if it puts you to an advantage I mean how big of that Advantage is it so anyway this this need more resarch of this yeah um also there's I I think the there least two Advantage like one is um on on the on the N where you you do a fesh blob and if you get all the blobs

then you can make the block available and start testing to it so you can you can essentially like shorten your block available um delay and the other Advantage is if you have some super noed Network that's able to fetch all the blobs from the e then they could like compute and publish um the scard to the network so to help with um propagation just in case if the proposer is not able to publish it publish them all out quickly um so they're still like it's still quite useful for um for like blob propagation in PS right I mean um for for Petra when I was looking at it I was like um we would

still like let's say I got the first um five out of nine gloves from get blobs and the last four are left but since I'm already subscribed I anyway receive all nine I just don't verify the first five so I mean there's not much saving in bandwidth as well maybe like one uh one really good optimization would be like if there would be a very high chance of hit rate then we might as well unsubscribe from BL I don't know maybe I don't know because is oh that's what

that's what the entire point is right maybe if we can cash exchange capabilities I mean U yeah I mean we we still have to see but uh I think the point is uh I don't in terms of in terms of pias it does put us to an advantage but um for Petra I'm not very sure so yeah I mean that that's pretty much I to say yeah okay cool cool um yeah hopefully we'll have some numbers um soon to to understand the the behavior a bit more

um okay uh do we have any more client updates um I guess marus kind of gave us his update so unless you have anything else to add Maris uh not really but uh we might wanted to talk about uh the networking uh package layout lat like Felix is yeah hello so um I most just wanted to get some clarity on this uh TR for E 7594 regarding the format of like the

encoding of the uh transactions on GP and hello hello yes we can hear you yeah so um in the pr I'm not sure if you guys are aware of it but basically we just propose um uh an encoding for the uh transactions where we would add some kind of proof type identifier into the encoding so it seems like so far one of the proposals has been to just reuse the same rlp format that we have right now since it contains pretty much the same Fields but we do think it would be good to have some kind of explicit identifier

for the proof type and I just wanted to quickly discuss this so we can get to an agreement there like what we're going to do is any EOD devs want to chime in on this yes I generally like idea but I have concern about backwards compatibility so if we will have have a transaction uh without uh this uh uh this version then uh we can say it's it's old type and when we'll have uh a new version so with version two then we we will treat it as uh as new

format or how do you see it yeah so I feel like it's pretty much the same as always in ethereum like we started out with the with like the initial version and it doesn't have version identifier but if we just add a single version by now this is something that can very much be detected during the encoding so because RP decoding always proceeds field by field so it means that as it enters the list it will first uh uh parse the uh trans the normal transaction uh payload which is uh unchanged for the proof and then it will as soon as it hits the second element of this list it will then it can then check is it like the bite with value two just a single bite and if it is then we know it's like the new

proof version so what I propos there in the in the in the pr is kind of something that can be parsed uh correctly right now whereas with this other thing it's kind of like you would have to pass the entire transaction and then while you are passing you have to count the elements and then if it has more more than one element then you know it's the new type I mean it's possible but it's nicer to have an explicit identifier kind of yes okay so for another mind it's it's like not a problem to to add it yeah so my I also commented on the pr and proposed that maybe uh you know we leave the third element of the array as

undefined or empty element and then the fourth one is a sell proes and I think I think this is pretty easily identifiable and would not really change anything in RPL and coding decoding or any of the other places so this will be pretty contained and we don't even need to have a separate uh transaction type uh that we need to include sorry G where did you ah yeah okay yeah this that that that kind of sucks I think and might sorry that is probably not the right uh uh probably not the right solution because if we do a version by we can even change the um uh the encoding or

like the algorithm by which we are we are verifying so in the future we might want to switch away from uh from uh kzg uh we could have different um different uh types for the same because it's only in the the same rep yeah I also kind of see it like this I think that ultimately this area as we are now seeing is something that will be a bit of an ongoing project because as the dis in ethereum adapts we may even want to change approves one more time or something so it's kind of like I feel like having a version here is kind of appropriate because it's it will probably change again

especially because kcg is not uh Quantum resistant so or we can also go for SSD transactions uh yes but I don't I don't think we need like we should speculate on on stuff that might come in the future like we can we can also decide not to have any transactions in the future anymore and just like only only send the raw data or whatever or we create a transaction type that encompasses all transaction types but I

think this is this is a way to uh make it kind of future proof to uh uh it's an easy way to make it future proof for different um different uh proof schemes nice um seems like there's a bit of discussion on the pr um do we want to carry on the discussion here or are we good to continue um asnc after this

call I think the the quicker we can the quicker we can make the decision the quicker we can actually start implementing it and so the the since is not locked on us I don't know I would give it maybe like let's give it one one or two more days finish the discussion on the pr and then then merge it as soon as possible okay great um yeah so yeah um I'll also Post in the chat as well just to remind people to have a look at this PR the next one or two days it'll be great to have this finalized so um yeah not only the E team but also the CL teams can start

implementation great thank you um any more uh spec discussions given that we've already jump to uh spec discussion right we're going in reverse order today um I guess uh Perry do you want to give an update on the the devet yeah sure um so since about a week week and a halfish we have been running some portion of the devet as full notes um there was one bug in prism where we had the subscrib subnet flag left over

from a different config stage um that's been since been fixed it would be nice if all clients can have a look again um if we are indeed set them up properly as full notes we're still working on making that concept a bit more configurable on our stack but we got a bit s track with Holi um I updated the network earlier today to be 13 full nodes and then around eight um super nodes so that represents about a 60 40 split and uh this is very similar to what we imagine would happen on Main net as well we of course stress it more but it's um been stable for the last halfish hour um we will do a few Genesis sync

test but I've been told other client teams have been doing this as well and that's been working okay so I think the basic happy path is looking good and now we can start um more stressing the network and trying to break it I guess um yeah I think that's it for devet 5 I would like to start discussing and scoping devet 6 so we have all the pieces in place for that um do you want to do that now Jimmy or wait for some other updates on dev next five before um I don't know if if we have any other five updates Agnes so um I think since we just

um put the like full not density up right now I think we should let it leave like we should leave it for to run for a few days at least yeah yeah DEET 5 won't go anywhere um I just see DEET 6 is something that happens in let's say two-ish weeks so it would be nice if we already align on what needs to happen for DEET def6 so that everyone has enough time to work on that it sounds like like the biggest the like the biggest change that we could do in Dev ntic would be the E integration on the sale prooof so um it might be longer than two weeks but I feel like at the same like in the meantime we

probably need to do a bit a lot of testing on de5 with Val custody um okay maybe maybe we then start with uh what else we want to do on defet 5 and then we can end the topic with what we want to have on defet 6 yeah is there is something I would like to see on dev 5 is a checkpoint sync uh checkpoint sync yeah unless I'm mistaken right now CHP Point z um the finalized checkpoint uh available on CHP Point Z is the last ectra checkpoint and not full at all um yep that should be uh will p s about it I think he would just need the

dependency updated uh we we'll figure it out all right that's cool thanks um any other specific tests we want to see on Deet F I think we can take the Super node density even lesser after we see that it's stable for a week um and I think validated custody should be and yeah yeah valid customer but that's something as soon as any client has we can just update there's no need for coordination on right yeah but I think it would be

interesting if we spin up the new devet and we like every client team actually gets to see um validated custody getting enabled across like as soon as Fu gets figured that part we would be missing that part if we don't up validator trusted in so I think that that might be a useful to that I got it um yeah makes sense but that we can also do parall with um with cus I guess ah yes man yeah um I would like to know if it

is possible to add the prison flag data colum with hard count um on this flag when a prism propos a block uh it withhold on purpose uh some data colum so in this case 64 data columns and so it can force it can test really in real conditions the rec construction power of other nodes at Network perfect um how many pris no should we add this to all of them or just one well let's test with with at least one as a month and if it is successful we can maybe test with more than one okay we have a high participation

rate so you just here we like nonf finality testing cool um anything else with de5 only have 10 more minutes left I think we still have a few things to go through you still have your hands up is it is this from previous round yeah I guess so um okay then maybe the tldr for devet 6 is we focus on

getting e involvement we'll do some local tests in the meantime and then report back as soon as Marius gives us an image and I guess we just coordinate on the P testing chat as to which CL is also ready for the El change if there is a specific uh CL that's already going to work with the changes then please let us know we should probably also discuss timelines otherwise we just going to keep pushing this forward so maybe we can try to aim for uh launch the N with in like next week week after that yeah say ideally next week but it seems like

valid custody might take about 2 weeks yeah yeah I'm not sure like when we're going to get the D6 scope uh I mean implemented because I mean do we just want to start with one EO client or do we want to like have as many EO is possible to start with I think one for now is good and then we can focus on more let's start with gu and then we can expand that once that's ready and yeah the jender is uh would dogs so we can do that too nice cool then um yeah client team can share can share progress and see

like and we can start def whenever we're ready um is the change on the side for this by the way so could you repeat that P how is the change on the side um Mario offered to do it by end of day so can be massive okay so do by end of day um also not on defet or generally death Nets um so I've been thinking about um mining some not keys so that we can like better uh control the column

distribution across the dev net um so that we don't have to you know randomly spin up many VMS and instead can like uh I don't know spin up like 32 VMS that cover the whole uh distribution for the columns um and the only requirement for this would be that we can set the note keys at the CLS on every client um I've pinged already some of you on Discord I think most clients replied and I think it's possible um but yeah correct me if I'm wrong yeah I think it's mostly possible

is there any c clients that's that that U doesn't overwriting no keys okay but ask the same question yeah so it seems like everyone supports it does everyone also support it in a nice way like not a way we have to put a file in a certain location in disk or something well the file is good um but yeah I guess if it's just like a CLI flag or file or an Nar I mean that's all simple um but it's a file for

us it's not so smooth it's sounds good right um yeah we've only got five minutes left um I just want to quickly share that um Francis from Bas team he's um he's he's created a document I'm sure some of you have already seen it um I've sh in the chat um he got a basically like a road math for p like containing all the tasks um that are in progress and that needs to be done so I think for now this will replace the the Readiness checklist because it's easier to edit uh for people so um it' be great if everyone

can have a look at it and see if we've missed anything um yeah we we only have four minutes left um I think we actually have one agenda item from t t Park I don't know if he's on the call um but um yeah what he's uh requesting is basically um you want some um some ideas from client teams if there's any if there's any particular metrics that um that that that you want to see um would be good to um to to share ASAP because um yeah they're they're going to start testing just start going to start running some testing um with big Big Blob counts so uh be good to get some interesting metrics um yeah we do have a threes

start on the PS testing chat so if you have anything we can also add it in the chat nice we've got nether mine U for the next step net that'll be great does anyone have any any open questions or any open item to discuss for the last three minutes right um yeah thank you everyone

so um in the next couple days um be good if people can review um gend does change and provide feedback and also um review the the networking format PR and we'll try to finalize in next two days and yeah looking forward to to to Tes in The Next Step net with all the Els um and we're getting closer to to ready okay great thank you everyone good call uh for next week's call is going to be back to to 2: p.m. UTC so I'll I'll add a reminder to the to the chat as

well yeah spec fre is hopefully ASAP thanks everyone see you in chat offline than Care by thanks by bye