PeerDAS Breakout #6

Transcript

e hello

e e hello let's wait

for a couple of seconds um I believe at least Babas will join right ah just okay welcome to the six um P breakout

Cod the agenda and mini notes is here we can start with the Cent updates um anyone want to share the recent updates from the client site yeah I can give an update um for uh us we have been working on uh you clearing up some tech dep from basically trying to get a p do into a marable state to a develop Branch so we've been trying to improve our test coverage and a lot of

the perod specific Parts um we have implemented the uh blob side card support for pias so if you have at least 50% of the columns you know um any API consumer can just get the blob from that um we've also been looking on strengthening our data column validation so improve pipelines so that you know um any columns that we get from Gossip or that we get from other peers are correctly validated and also uh lastly we have been fixing a few bugs with Electra that came up so uh Electra with piras flush some bugs out in prism with regards to how blobs were uh used so we

had a bug where prison would drop blocks with blobs and the chain would stall so that was one B that we focused on last week and yeah that is all for now thank you testing if the the re best Electra works for the P death yeah so for us what we did was that we try to make it extensible in that um you could have prism start with either thep or Electra and it should work fine but last week when we tried with Electra there were a few bucks that we found which had nothing to do with

pasas but actually with our Electra Branch so that's been fixed now and uh with the current Pedas Branch you can start in the OR Electra thank you um other clients lar yeah I can go for lar so um as such uh I we are working on the pr to uh dissociate the subnet from groups and that is something that sort of we want included in the next devet and based

upon what the consensus is for uh rebasing p on Electra we'll also work on that thenk you and then Lighthouse hello um we have um fixed the B box um building rank sync so the house can now sync um Network and we've also fixed an issue with sampling which was sending excessive request to single peer that's fixed now so we've now disabled sampling by

default um other than that we have been focused on merging our dask Branch changes into our main branch think we're probably around 50 to 60% through hopefully we can have that done in the next um two weeks bit better so we can speed up our progress um and other than that we've we've made some progress on um the optimization to fetch L from the e um um it's also known as decentralized block building so um for super nodes we fles block from from the um the E and we build datac SAR and the publish Network

um we've done some testing on this and the testing shows that uh even proposer with um limited bandwidth they don't they don't publish all the DAT columns they can still propose a block um with the help from Super node on block building and um block application um so that's looking quite promising um I think our next step on that will probably try to increase the block count um it might be slightly challenging because of the way we currently compute um data colums and proof takes about 200 milliseconds per blob for my machine and I think then they could potentially some memory allocation isues on stack so um yeah so increasing that block count

could be something that's that's um challenging with C kg Library um I'm not sure if any client has tried testing um increasing block counts um but um I think it's it kind of suck kind of suck a little bit in the in the 1D onedimensional PS case because we need to build the entire column so it means we can only compute or reconstruct we have all the blocks we can't just partially do it because with the 2D scenario we can we can have each just Rand randomly select subset of all blobs and compute just the subset rather than Computing the entire blob so that that that's going to take a long time for 32 blop so that's something we hope to um

solve um but again with 1dp appear That's a bit challenging um um yeah so this week we will focus on fin checkpoints think working again for p and also prep um prepare for next that's all from house thank you so regarding the blab count what was the parameter you use um I've tried to change it too but I haven't got it working yet but I can see that it's a it's going to be slly challenging because I look at the Benchmark for um the r Cas VI library and it takes 200 millisecond per block

and currently we don't do any any parallel processing so like 200 per blob if we make 302 that would be like 6 second or something without any paration so we probably want to do some paration there if we can um yeah I think I think just needs a a bit more testing um just a potential sh wor raising thank you and gring hello so yeah uh our fellow that was working on on pusk made some uh some fixes and essentially we are we are waiting until

the state and likely it will be the next devet uh which uh which will not uh where there will not be a requirement for sampling uh if this is still the uh still the plan and then we will try to to join the the network on the next DEET so that's all thank you also just to be clear the next definit is the the next the one you are join will be te 3 right uh yes ER is is it still the plan to to kind of remove or not uh make a

requirement of sampling in devet 3 I think we will finalize it today but okay okay okay thanks thank then um bu have best here today no yeah uh we finished uh adding full metadata with fre support uh will match it today also uh we make reconstruction

of both side cars so you could get it from rest API but only if you are supern if you have first 50 of data columns uh merging it today probably too and we fix it back we had an issue when we were trying to retrieve column uh we were not trying to retrieve it from all the p uh only trying first two something like this uh fix it at two and we have added all validations and now working uh for for choice to be spec compliant with Alpha for verion uh when we check on the custody and uh regarding Electra we have

not started to to move to Electra so we will start probably uh after theet to launch that's all for us thank you got any questions for the client updates com through all the CLI um so the next one is the def discussion so I'm reposting bab us proposal or summary here one second

okay um please check the chat as a link so basically the proposal is to um for defy two uh we have this the pre we have based on the previous uh spec alha four and then use then Genesis no electr reest um so one important item I want to check again in the chat is we um okay with including PS 3870 in Def 2

this is [Music] the link of the pr so yeah I think for the reactions from the this code is like people who want to have this feature and the F Choice update is uh tribute compared to the previous version so it's okay to include the whole feature into definite two if you agree or disagree please if some reaction here now um I had a question so this PR also

includes a config change right so um one issue for us is that we always test uh with the con consensus spec conf F so if this is not in Alpha 4 um our test will start of fail with this right um so I think um to to discussion why is uh do we want to include this this uh configuration change into definite two and if it's answer is yes then I I will cut the release for it okay yeah yeah that' be good enough for

us then okay good um yeah and any objections so so you're saying we will include the config change or is that a separate discussion think we will we will include it if if people are okay with it what um but but Franchesco would you like to explain the parameter I mean changes uh yeah I mean this is actually something that's been kind of um yeah in in a bunch of PRS I think

since um Kenya and it just never ended up being in a PR PR that was merged um is just that yeah we needed to increase increase the number of subnets because we want to increase the cust requirement and originally because we wanted to do this trailing for choice and we kind of needed the um the custody part to already basically give enough security and now we literally don't have sampling so the custody part really does need to uh be kind of secure in itself so I I think it would make yeah it wouldn't make sense to still leave this for a future um update um it's it's quite Central to to how custody is supposed to work and like yeah it's something that we

kind of had agreement on like basically already in Kenya so I think yeah we should just include it thanks for just go okay then um so we now finalized the definite to scope with Alpha 4 plus it's um D based and then including this PR and we will C the uh alha 5 release soon and C agree with the time line by Babas proposed I think it's by the end of this

week good think it's um should be a small release and I can make it no say in 24 hours because the new relas for supect okay so any objections okay definely two by the end of this week he um then it's Def three so it will

be another spe release number um uh we will do we want to to make it as a Col TR best version I want to I think all Cent indicated that in two or three weeks they could do a elector rebase so I would actually push for def three to be uh based on Electra any objections yeah we um yeah I agree with

Babas and um we just need to test it out on our side yeah should be okay okay great so definitely three will be the Electra rep version and previous uh we discussed previously it will be a me sub theou version um yeah can someone L the pr to the chat try to S it ah yes the c

network thank you Jimmy so we will include this PR um yeah and um Babas you want to launch it in two or three weeks yeah I I guess uh that's just an estimate timeline uh let's see how theet 2 is going to go if d 2 is not very stable then I think we're going to need to delay it a bit further mhm and would you like to um talk about the activation Flags right so we had a I I think a

couple of months ago we were talking about possibly activating p d with a a different uh way instead of doing a EIP whatever Fork version and uh Fork EPO we could do just pure death activation EPO I'm not sure if uh if this is still under discussion or what should we do about that but I think if we do an electr base then we should have a way to trigger elect uh sorry trigger P death independently still not just automatically activate P death with

Electra yeah so um for us the pias activation eoch is still separate from Electra just that in the testing config you we have it the same as the electro for ke but if if you do need to you could have it you know Electra Plus 20x in the future or something it will will work the same way are you using the G activation e or are you using Erp 7594 book so uh from what I understand um EIP 7594 is what is in all the configs so that is what we're

using right so currently the spec says EIP 75 94 Fork version and EIP 7594 Fork EPO and and the way we do the peer Des activation is by setting the fork version to denb Den's Fork version and setting the fork EPO to Den's Fork EPO and in the future when we do a rebase on Electra then we're going to uh trigger it with the IP 7594 Fork version equals to Electra Fork version and the fork AOC should be equal or be greater than Electra Fork version for fork uh EPO sorry but the fork version should be the same so the question is do we want to

keep it this way or do we want to uh possibly get rid of these two variables and introduce a new one called something like peer death activation EPO and get rid of the fork bit completely I think eventually we can get rid of get rid of the the boing po right we we raise to launch p with Electra um I don't see any clear benol changing at at this point unless I'm missing

something it would be just a cleanup but yeah we can we can totally keep it like this then then let let's not change anything uh how we activate it uh let's just keep all the all the same stuff as it was before okay thank you all right um so now we move to the SP discussion does anyone want to talk about some SP PRS or B changes and any questions to the kvg

libraries how manys sorry Jimmy you will cut it bit no just I was wondering um has anyone tested um like how many um like what's the number of blop we can realistically support in a u a block um if we just ignore the networking stuff just just to focus on um the crypto library in terms of CP memory in time

sorry h i mean I think at least the C library should be like which which um functionality are we talking about here um I'm talking about compute sales Compu sales improv and reconstruct recovery sorry recover I see okay um let's see so I think okay I mean I'm not sure I what numbers are you interested in like like you you want arbitr arbitrarily many blobs and you want to know the time it

takes or what or when the library is going to explode or what um yeah basically like I don't need arbitary numbers but if we're aiming for something like 32 drob um I think it'll be interesting to know like how much time it takes and um CPU memory um requirement I think at the moment I've tried running the ref U sorry the rust e casg Library benchmarking my machine and each blob take about 200 milliseconds to right compute and to recover yeah yeah and and you're wondering okay so and you are wondering

um like without like you want without paralyzation I think without paralyzation it's going to be a linear thing like you know uh you put two blobs you're going to get 400 milliseconds but you are hesitant about using parallelization um no I'm I'm not hesitant I think we probably need to figure out how like like to see like how paralyzation help I think the Benchmark for the r Li also test paralyzation but it doesn't seem to improve a lot so maybe I was looking at the wrong number but try to confirm afterwards I would imagine it's like um

like completely parallel like if if you have two cores uh and and you split it in in if you split two functions into two cores they're just going to take the same like you're going to do 200 milliseconds for two things if you do them in parallel right so if we have the two blobs and we can do eight in parallel then we need at least then 800 plus milliseconds right yeah yeah that would be uh what should happen in theory if if this doesn't happen it's something we should

know okay cool cool um yeah I'll test it out um yeah I think maybe I was reading it wrong I think the numbers just show me 200 millisecond I guess it's um for one single block but um yeah I'll try to I'll try to confirm maybe I was looking at it wrong if it's yeah I think I think I think after a certain number of blobs we will need to do parallelization anyway so I think figuring out what's the right parallelization strategy is needed and then if the numbers you get out of that strategy are not good enough then we should figure out something out yeah because I think if we try to

increase above maybe 32 then they feel that we would probably need um like distributed building because if we try to build on one machine um and each machine let's say if if a limit is up to 18 sorry eight eight um eight paralyzation then it may still take a long time unless we assume that every node can paralyze more than eight I think something to think about yeah yep do we have a way now to decouple the blobs by the way uh because we now have the max blobs per block uh config

parameter in the config ML and we have a support for this parameter in CIS as well so you should be able to just play around and just pass in more blobs but I'm not sure if the E will support that yeah I think the E will need some changes bro um I've been trying to play around with light health and Rift um I haven't got it working yet but I think on the E side should be quite straight forward is to change the constant I think we depends on the E some of them have it baked into the library so it's compile time so they might have to make a change there and you might use need to use a different image each time but we also had a PR that would change how uh

the blob blob count would be passed around from between the CL and the L I'm not sure if that made in to exactly Alex was working on that I think that's also the right way to do it but yeah I'm not sure where it is right now yeah just so just one more thing to add I think with um the the limits on um Computing the the blood prooof um if we really want um the distributed blob building I think that

that would be a lot a lot more um efficient in in the 2D P case because we don't because each know we didn't have to um deal the entire metrix they could just like like select a random subset of the entire blob set and then just compute sales on on those and publish those individually so we kind of have like many notes doing that um at the same time and we kind of get paration by default with that approach with one DP with one DP that it's a bit hard to do that so we need to do paration on each machine so I I don't quite understand this because for for reconstruction like

uh definitely for 2D it's uh it's more um it's easier to see how to distribute it like that's kind of one of the reason why we want to do 2D that you can just reconstruct um a single single rows um instead of basically needing to to have everything to reconstruct but but for constr for constructing the The Matrix in 1D you actually can just encode each blob like by itself basically like you could even for example say you're a local blog Builder as the blobs come in the M poool you know that you're about to be the proposer you can just start encoding them and Computing proofs uh for each blob like you don't need to have all the blobs to be able to uh to to compute the the the encoding and the

proofs uh but for 2D you actually need to have everything before you do anything you or or like you can you can extend each blob but the vertical extension for the 2D thing you you can only do it once you have all of the uh blobs basically all the extended blobs so you can only do kind of half of the work um in a in a clearly distributable manner like at some point you need to do also the vertical extension and uh that seems like it's a it's harder to distribute I don't quite understand why you say that block construction is is more easily distributable in 2D um yeah so um the um the experiment I'm doing right now is to have super no speci BL and and

construct the um the cells and the column side them but the problem right now is that we we we transmit um the blobs in the unit of doac colums by themselves but um if we want if you want to send one data column to up here then we need to have all the blobs does that make sense yeah okay yeah sure in terms of propagation yeah I mean you you do need to yeah um get the the whole column but you can do all of the computation blob by blob like all of the actually encoding and Computing proofs uh though yeah you can send them out but I mean one thing that I I I don't think that this would necessarily

change with 2D just because uh yeah the idea was that 2D would have sampling being by cell so that you could like uh yeah send these small parts but still I think distribution will very likely be um with bigger chunks like that it was still meant to be like by rows and columns in the in the kind of original design but another thing is that to even have the cells uh to begin with you still need the whole Matrix to and like have done the computation on the whole Matrix uh which is I think harder to distribute actually like you can't you can't uh do um you can encode all the blobs but then only once you've done that you can even start doing the the vertical uh extension right let's see

um is it would it it beneficial we could like break down like the the uh the data columns so that we can just send whatever cells we have in that column rather than having to send the entire unit once because I think I think what you're talking about is what's happening on the proposal note right that the proposer can start preparing for the the uh the cells as soon as they have the blob in the the e um but if you want to do um like distributed construction then um the other n could can can only start

building once they have the block and they have the Block in the right so they will have to do everything at once so and I so in in the version that uh that we were playing with we always do distribution cell by cell I mean we we we've been playing with doing cell by sell versus column by column but when you start to do recovery based on the 2D structure you anyway need the the cell by sell distribution so just based on that we usually said let's do it cell by sell from the from the beginning uh but there were others doing

more low and column based distribution in the two DEC and then kind of doing sell by sell for for recovery and for sampling uh that's for the for the networking part for the generation I think the difficulty is that you need the uh the kzg commitment against which you verify on on the column Dimension and and to have that commitment um I think you need all the basically half of the M of the column so basically all the column um yeah but I

have to think about it I'm a bit confused on what we're talking about here because um we don't have commitment column commitments we only have row commitments and also I feel like if we start propagating cells instead of columns we're going to run like propagating entire units is is nice because you don't have to worry about all the race conditions and all the edge cases of what happens if I get some but not all whereas if we start sending just cells we need to start like we will get there will be much more complexities I

feel like yeah okay so so so one thing is whether we have permanent low commitments and and and you're right it's it's only low commitment so you can verify individual say just based on that so that's not an issue on the on what is being propagated uh I mean cell by cell might seem like more complex than than only rows and columns uh like rows and columns might seem more complex than dist in the whole block uh I don't see a huge difference in complexity but uh yeah but let me know what complexity you see in in cell by cell distribution

it's I mean from my point of view the efficiency gain was the complexity uh and the complexity is not that huge but but yeah us on that might be different yeah I'm not sure I think it is very similar to the to when in 4844 we had to decouple the blobs and that came with its own complexities uh but yeah I don't want to make a statement about this because I just felt like when we coupled things in 4844 it was uh more complicated but I think yeah I'm not sure where to draw line yeah I mean I think it's a it's

it's it's a of a compromise that we have to understand well later on when we are potentially going into this direction um the we have been running simulations but those are high level simulations first on cell by cell versus versus line by line so so those in columns and there are efficiency gains if you do sell byell uh for for a few reasons of peer top networking um uh but there are simulations with a few assumptions which you know how it plays out at the end is is still to be verified

I think I'm I'm not quite sure I have kind of lost the connection between this discussion and the original question which was uh about local block building and stuff yeah I I I don't know if if we have gone a bit side yeah I think um it's kind of related but um the original question was like how many how many blobs can we realistic realistically produce on a node in a block um I think when we hit 32 um going above is going to require like more than paration on a

single machine um but it's worth experimenting I think like if we do 64 the we and and we don't have 64 CES then um then it means there will be batches of like computations right so it will take longer to Compu to Pro but I think I was trying to think of ways to see if can distribute the workload so that's how we kind of drift away from that initial question yeah so it's it's it's SC scaling uh at one point requir distribution especially if you want to have also enable smaller noes to build somehow and that's that house it fits in but uh yeah I think it's longer term

research I think one thing is worth differentiating though is like there's kind of two components to um local block building or block building in general and like the complexity that the blobs introduc one is the networking part and one is the the computation part and the computation part at least there is nothing in the current structure that makes it uh harder like actually I think the the way it is right now it's as easy as it can be like it's perfectly parallelizable and I mean of course yeah if you hit the limit of your you have more more blobs than cores yes you you will have to still uh do it in in batches somehow but there's kind of no way to do better than this like there's no way that you know doing going to 2D

doesn't help with the computation um it can perhaps help with the networking or or at least like changes like you know not Distributing columns uh could help with the with the propagation part um but on the on the at least computation part maybe yeah the one thing that you can still do is even if you don't have enough horse for the amount of blobs you can still distribute the the workload over time just because blobs don't will not come right as you're proposing like you're not going to get like 32 blobs immediately at the second you're proposing you get them in the M Pool uh over a few seconds and you can just kind of distribute a computation over over that period of time so I think in

principle um yeah even even um a node that doesn't have uh too many cores should be able to do a lot more blobs than you would think just based on the number of course like you can you know you get blobs at six seconds into the the previous slot you have a lot of time to do the computation for those um in advance basically but yeah but I mean these things I guess eventually um like there's like a bunch of like of these tricks that probably eventually should be um implemented um for the propagation part one one thing that we've uh kind of uh um disc C is that eventually would be nice to basically allow uh nodes to um just send out the block first

without trying to immediately propagate blobs uh and like basically you know once they've sent out the the block to all their mesh Piers then only then start uh trying to propagate blobs um basically um trying to use the fact that there will be nodes that have all those blobs already like if you have any kind of super node uh Pier or like super node in in the propagation path uh they will be able to get all the blobs from their mol if you're like a local block Builder and have been building stuff from the mol and they'll be able to basically just do the Reconstruction and start propagating things for you so I think eventually it would be nice to um yeah basically try to use this as a way to um

have um local block Builders not have to do all of the propagation work or like basically be able to rely on other nodes um to to help them with propagation um and yeah only kind of being able to do as much um to to go with as many blobs as they can deal with on the computation side even if that's not necessarily what they can deal with in terms of appropriation yeah thanks Fresco I've just Linked UP P that basically does exactly what you just described um so I think um you so there actually two different angles that you can can

you can you can think about this so so one from the proposed side um we can definitely distribute the computation over time like during the entire entire duration of the slot but um if we if we want to use the distributor computation like using other supernes to help with the the block buing and and distribution um then um basically each each super know that help with the computation we have to construct all the cells so I think there's a limit on how much we can we can scale in terms of number of blocks um so that's why I was kind of thinking if we can just have each super construct a subset of all all sales but I guess that's that's like like further research required I think but yeah I think I think we

probably hit this problem once we get to 32 BL be interesting to see what happens at least I would suspect that the networking problem would be F would be we would hit the networking problem much sooner than the computation problem just because I don't if you have 32 cores you can you know even if the blobs were I don't know 128 you could do this in less than a second um still I mean of course like using all of your course time but like it seems at least like you know fairly manageable numbers especially because we're not going to have 120 blobs for uh very long time so it seem it seems to me that in like the foreseeable future it's unlikely that the computation part would be the the

bottleneck even for like pretty um low power nodes yeah thanks go Ahad I think when but yeah I think I think I think that's good discussion thanks KY um any other topics for this last today just want to make sure that V3

metadata should be in too does everyone else dis does anyone disagree we have metad dat version three any other topics uh yeah I have like a small

question for something like a potential maybe eventual spec change related to valider custody um if um it was useful for for this validat custody thing would it be um deal like much of a problem to basically replace the custody subnet count thing with um like a bit field like I think we have that for attestation subnets right like something where you just say which subnets you're you're part of instead of um like this custody thing where you just say I'm in 10 subnets and then determin compute which ones um if it was helpful to explicitly state which would that I

don't know be like an easy thing to do is it is does are there any challenges really that kind of come from that I'm just yeah curious if it's something that I can consider as part of a design space or not what do you get from that um right now nothing like in the current spec there's no reason to do that it's um yeah it's related to if you wanted to do this accountable valid custody which works a differently and the the assignment that each person that each validator have wouldn't be a public um and uh yeah it wouldn't basically would not necessarily be able to compute uh deterministically what some which subnet someone is supposed to be in uh

based on their node ID um but like I guess yeah the don't worry too much about the why for for the moment it doesn't do anything I'm just wondering if um yeah if there is reasons to like not want to do this where it to be useful for other things I think one down side is that uh it will become easier for the attacker to map the the veror to the to the node right so it's like because you you you put more information in in the enr but in this case it's uh you know the cust subnet count still allows someone to exactly know which subnet

someone is in uh this thing would it would be the same just that they're explicitly explicitly stating with which submits in instead of stating something that then has to be fell into a function and it wouldn't be actually the idea would be that it's it's it's private what a validator is assigned to so there's no public assignment of validator um so it's yeah I'm kind of um really just want mean to ask about this this uh bitfield thing like if that in itself has some downside so with the current assignment it would be the same information disclosure the for as a bit map if if you think of of a potential future where

you have 500 plus 500 rows and columns then you are having a bit map of 1,000 bits which I don't know if it's a problem or not but it's definitely more data than than the the current count for example so it's it's a question of yl size I suppose well um for us it it won't be an issue we already do this for the stations and sing subnet so it's it's pretty much I think the same thing I I also think in some sense it

would be be better to do it this way rather than having um a subnet count because for all the other uh the station thing subnets we have a bit field for those topics so you know sanitizing it on just having bit fields for all of them is I think is a rational idea any other comments

hey so Francesca we move on from here oh good okay any other topics for today no yeah sorry actually another quick question um I'm just curious what what is the roughly like ratio of super noes to non super nodes that's been done in Deets or like that you plan to do in DEET okay sounds good we can do any other if if there's a request to do some something I just

think no I think that's fine I think it just probably doesn't make sense to do like something super low just because eventually if we do have AER custody there should be like a reasonable number of Super in hour but yeah half half some sounds perfectly fine yeah we don't have too many nodes right now so that's that's another possible bottleneck that uh we have a very few nodes and it's going to be very hard to have all uh all the custody requirements fulfilled with the number of nodes that we run basically if they are not super not um does it make sense to increase the custody

requirement before we have Val custody because right now we don't have Val custody and the default is just four four I think just four for the cust subet I was wondering if it makes sense to increase it to eight before we have Val C I don't know if the question is to me but uh yeah I guess to me it it seems like it could make sense um but uh yeah I think I don't know I I'm not sure what the specifics of the like how many notes are there in the network roughly 10 to 12 like we can maybe one pit up to like 20 but I I don't know if

if you're going to see any benefit if unless we run like hundreds of notes but that's just very expensive okay yeah I mean it's yeah I don't know I it's hard to I I have to think what yeah how will do things map to this kind of world uh I'm not sure yeah better come in the chat um I think the the biggest like problem on a small death is that most of the requests go to super noes so um there's less there's less pressure on the the regular full no and we're always sending stuff to Super not um I'm not sure if it helps we increas it or the um share the the

load something to think about that there's a complete change in the kosis um sorry so you want to do contact switching or what what did you what did you mean by that uh sorry I was just wondering if it's worth having the the network have a default custody requirement of eight which is the default default for B custody in the future um just because we only have 10 to 12 nodes and currently all the IPC

requests go to super wouldn't it still be the case though uh if you have higher cost if we have a k custody then there are more PS that we can quest one for a given column I guess that make lot difference yeah we we could uh we could totally do that for the devet but I don't know if we need to change this spe for this like we could just overr that value and then and then unless this is hardcoded to any client which it really shouldn't but you can also modify this value in CES and each of your runs there's a flag

for that so yeah we can we can definitely play around with that yeah because I remember last time when we were running some uh syncing test then all the supernes got like peer limited I'm not sure if this was like the root cause of that yeah hopefully that's fixed now hopefully we don't don't any other super nice if had more PS try from yeah so um any other topics for

no okay so we have the okay us updated the the def to document by the end of this week please uh let me know if I should use a different branch than whatever we defaulted to and then I can run some local test and then we can launch the by the end of the week hopefully thank you okay um thank you for attending and that's go back to

work thank you byebye he okay bye bye bye guys goodbye