PeerDAS Breakout #19

Transcript

e e how's every everybody's

[Laughter] day okay hi everybody sleep well last night who wants to take under over on whether we reset reset the chain or not no maybe just some slashing but it's not clear to me I just woke up I mean a few hours ago it's not clear to me if we did we finalize an block or

just just justify it no it's not no no what non fiz are not justified uh not even Justified that's far I don't think because well not going to speak at a turn I don't think it's even Justified though okay hey Jimmy hell hello hi guys I'm just going to quickly ping the PS

testing group as well people might be busy with with Hy yeah actually I just saw um Fresco's question

about are we having the call um should we just do a quick one and see everyone wants to get back to H yeah sure yeah I don't have a ton of updates either good morning everyone good morning um maybe we can start and yeah sure um yeah um you man you want to start us maybe we can start

first sorry um do you want to start first yeah yeah um should should this this call be record or not I'm not sure if it is record normally it is already recording okay sure um yes so during this week I mainly work on um validator custody so I have uh working implementation um however it is without the back fill I don't back fill data colums when I increase the the the validator count uh it works pretty well however an

interesting point um I have a new bug actually I think it is a bug which was already here before but we didn't notice uh it's with uh with lighthous I Noti that um sometimes lighthous send some scons to to prism and prism did not um receive it and when I look in the logs um of freedom I see that um lighthous just send some prun message goip prune message for some data colum um subnets and so in this case yeah I

pris did not receive any data colum why I think this issue was here before and not visible it's just because without validator custody you custody either eight data cols or either 128 if you C only eight uh the like Hood to have this issue is quite low uh so the issue may be here but maybe you never see it and if you are super n you can miss up to 64 out of 128 data colums and thanks to reconstruction if you miss up to 64 data columns it's still okay because uh you will be you will reconstruct or somebody

will reconstru for you no you will reconstruct if you are a SP and so the block will be a ailable and I see the issue when in the worst case which which is actually um when I cust exactly 64 uh colums because in this case I am subscribed to 64 subnets and if at least one out of 64 column is missing then then the block is missing and I cannot reconstruct um so yeah I have this bug now uh I investigated it uh with Jimmy uh but I think yes it's not directly related to to to validator

custody but validator custody just uh exposed it and yes that's it and next step is to uh work on um back Fielder yes that's all for me yeah um great thanks Manu um yeah so um so we'll look into um why Lighthouse is sending those PR messages to to prism um I haven't got a chance to look into it um but this seems like an interesting bug good find yeah um and other than that we don't have a whole lot updates from Lighthouse um we've got the flag to delay publishing block and data columns

so we can so I can share that in the testing chat later and then we've done a bunch of small fixes but we still have a lot of um issues with syncing so um sometime this week we're going to try to do more testing on dev N5 and and that line has started working on V the custody implementation um I think initially we're going to also um do no do um no back fi at the beginning um I think the the main difference is probably the timing of when we do the cgc update um but but I think it would be interesting to to see um how it works on prism because if you guys just immediately update cgc um and if there's no downside of getting

disconnected by pe then maybe it's a it's it's it's not a not a bad idea to have cgc updated early so um yeah we're going to continue working on about custody and I'll share the flag for testing after this call um that's all from Li house just yes for now s um we update the cgc um when we are sure that we are correctly subscribed to sub Nets and we have enough PS but the idea yes the idea is to update it only uh when we finish the back field yeah makes sense so are you planning to eventually Implement um

backfield immediately yeah yeah yeah but this week I I'm starting to work on it okay cool cool cool um yeah we yeah I think for the moment we're probably just going to try it with the the most basic impementation and see how things go yeah cool um yeah thanks then I would uh pass it on to lar Matt do you have any updates hello uh yeah still working on a pretty substantial refactor uh to update how the da flows through uh uh through the code and it's going to make it easier in order to to to clean up our sinking uh just make that more efficient

and also make it a lot easier in order to actually implement the validator custody um so we haven't got to that I still probably have another week uh with testing and getting it all cleaned up but uh it's going to make us much faster uh to implement the implement the next pieces so uh but we are sinking uh everything is working now on devet uh got ourselves sorted out and uh yeah so there everything's gravy there awesome thanks thanks Matt um teu got any updates uh yeah not much on teu side we have finished uh working on data

column reconstruction and started work on valid dat custody but not much progress to time so thanks um do I have Nimbus here yeah um so we started work on validator custody but uh right now we are actually going a bit off track like I think I would take another two two and a halfish weeks to refactor our column syncing um I talked about an alternative pure pool approach a couple of weeks ago and u

what I effectively want to achieve is to give the users uh an option whether they want to syn greedily from Super nodes or they want to totally avoid super noodes for syncing uh and how we would do that is pretty simple if if let's say I custody eight columns and I'm wanting to sync those all the time um I just don't want to waste any pure query so I I almost range request whatever cgc um the peer is like I I basically range request whatever remote custody every peer has until I

get to the common common goal of getting reconstructability like activated or whatever and then I reconstruct uh while sinking and I persist only what I locally custody uh in that way until a given threshold none of my pure let's say range requests are kind of wasted and I still don't need Super nodes uh to that great of an extent um this is kind of an approach that I'm thinking and if the user doesn't want this this should take more time than super node syncing but if the user doesn't want this then we greedily

um preferentially Range request super nodes or U nodes with higher validator custody um so this is this is something that I'm working on Ive also started work on validator custody but I think um if we have this sync approach then back filling for us becomes relatively simpler even with validat custody yes yeah my question is why do you want to avoid to greedy think on super n i mean i that the client should be able to think without supern but if some super

nood are available I don't see why it a bad thing it's more like a it's more like a value thing that we have here I don't know like people from my team don't really like the idea of super noobs I don't know why but like uh I think it's good to give give the users one option the other thing is um every Pier is useful for blocks um so what we do is whenever we query a pier we try to make the most out of like if we see that somebody's existing in our pure pool we try to make the most use case out of that Pier like we try to get the blocks by range and uh

like yeah so let's say if we still get something they remotely custody just to fill in the reconstructibility requirement we are making the most use of the pure otherwise let's say if the custody doesn't match yeah we are we are skipping that from the pure pool but um I think it's just more efficient to use the peer like that every peer like that in the peer pool while sinking so um that is still an extent right I think I would be you wasting more bandwidth if I try to find the intersection or let's

say in a in a real realistic scenario if there are like as we discussed um even if there are 20% super nodes um what we effectively so like while we syn um we have sort of a quota of the number of peers we um query like that's around five like four three to five and uh for our case that probability of whether we hit a super node is pretty scanty so I think it's it's more feasible for us to get whatever they can serve and then reconstruct rather than otherwise I

think if we um query like that I think I think we would waste more bandwidth on the other case as well so yeah I I mean till an extent yes you're right that we might be wasting bandwidth uh Pillar Point but I think it's more like it's more dependent on uh what we are custody and what we get like from a probability point of view I don't think so I don't think we I I don't think we would be wasting more bandwidth than

um having failed queries if that makes sense okay um let's see um yeah thanks aish um yeah maybe I think we can probably discuss more of this approach of um ASN as well um like to understand a bit a bit more um in overall the idea is like um since we have one peer pool like if you have one peer pool if you don't have two separate peer pools one for columns and one for just blocks um I think it's best to make most use out of a peer and um reach reconstructability we have parallel reconstruction as well

for I think most of us I think U yeah I mean till an next extent till 50% if you if you just take whatever the remote custodies have to give I think it's it's reasonable and you are not having to depend on super nodes and I think that's a very big like value alignment addition kind of a thing that you can actually publicly say that you don't need Super nodes to syn or like yeah sort of like that the other the other Advantage is I think this would come in very handy in case of validator custody because let's

say validator custody changes and um like let's say validate a custody changes and your local custody columns totally differ and now you're effectively your column database is kind of corrupt um then having this Sy approach would help you backfill faster I think but in my opinion it doesn't you doesn't care about you don't care about super not or not you just know when you think what the set of colon you need to to fetch and you know you have a set of Pi

this this Pi custody some columns and you fetch the columns from the peers which custodies them if they are super no it's okay if they are not super no it's okay as well I mean and if they are if the validator custody I mean if the not only custody 64 out of8 it's okay I mean at this in prism in the code there is um when we fetch when when we think when we fetch columns we don't rely on the fact that the p is super or not we just compute the

colon thanks to the cgc and and the PRD we just comput what colons the pier should custody and we we use it and okay we try to minimize the number of peer we query so indirectly it's it it fets from super nut not for super it fets for pi with um higher count of first but if there is no won't change our Logic the logic will will be exactly the same I I do understand but in this case you're relying more on the network we are trying to sync as much good as we

can without relying a lot on the network like as much as less as we can rely on the network because we don't know what is the realtime distribution of super nodes let's say in a given main net situation so I think I think we would go for this approach for us we would we would U range request whatever they remote custody so they can provide all the time yeah yeah yeah yeah okay cool um yeah I think we should probably move on um yeah I think I think we can continue this discussion offline

as well um looks like we don't have grandine so I we can probably just go straight to devet um yeah sure I can an update on that um yeah so uh four days ago or five days ago we launched defet 5 which is basically a relaunch of defnet 4 now with the fixed G version from the start on um and that has been pretty stable um there's only right now um yeah grina that it's failing um they already like pushed the supposed fix but it seems to have some

issues at least it's going like out of memory right now um so yeah I will I will talk with them and uh let them debug this problem um yeah besides the definite 5 launch I think there was nothing else oh um thanks for well um okay then I think guess we can move on to spec discussion um I think Dimitri did mention um they raised a point about wanting to discuss removing or aling sampling concept from the fo spec um diit do you want to give a a quick quick load

out yeah I suggest that uh to to to remove sampling page from uh from the spec and uh to check data availab we just check that custody for for requested Block H is filled and it's enough to to continue Import in for choice and we could just uh um make spec simpler this way and also I suggest to make custody requirement the same that uh that uh requirement for one validate not so uh the requirements will be

equal uh see um U yeah just stic think you are talking about dropping sampling concept I think it's important to really say dropping P sampling because we are currently doing something we are doing subet samping and it's kind of misleading when people talk about about sampling for peer sampling I kind of agree with you if if you replace drop sampling by drop peer sampling Concepts but not but we cannot drum something at all I don't know if I'm if I'm clear or

not yeah I think sorry sorry did go uh I I'm not sure how it will make will it make spec simp sorry I can you repeat this so you suggest to drop uh to drop subnet uh I confused uh could you could you repeat please yeah I think um in your um in your um giup commment you are writing drop concept just drop sampling I think you

want to say drop peer sampling [Music] concept I just passed into the chat the page about pampling and let me let me let me know if I'm wrong you want to drop this this page uh yeah yeah yeah sampling yeah yeah so so it's really to say peer sampling and just sampling because currently we are doing sampling we are doing we are doing subnet sampling it's just to avoid confusion because there is a lot of confusion about sampling about subnet sampling and P something um and if you want to drop something

from the e for so I agree yeah I I see currently in Spec we already have uh something named custody sampling and it looks enough for me yeah yeah yeah um so Francesco said okay so maybe I mix custody something and subnet something for me to was the the same yeah I think I think there's a a bit of mixed terminology there um so I think what man was saying that we want to drop uh sampling bya

making IPC request appears and and just do sampling via um subnet and getting a VI gossip it's not totally true to say that because um if we if we keep the subet sampling and if for one reason or another um the data column is not available via VIA gossip it's still possible to request it via RPC I mean yeah that's right yeah yeah yeah that's why I really I think we should talk about Pier sampling suet sampling and custody sampling and so I I um I agree in the F4 spec we could drw totally P sampling and reintroduce it if

needed into G fork in this case we can move custody sampling for 4 to8 and and and and implement the simplification of the spec proposed and what I'm still confused a little bit is between custody sampling and subnet sampling maybe Francesco can explain a little bit more or maybe someone someone can explain I mean what I mean is just there's this custody thing which is for full noes for and uh and that's what you advertise s nodes and and all that and then there is and and but it is done by subnets the sampling still like the I guess the actual sampling is still

sublet sampling um and then there is the extra sampling which is the um extra for that full noes need to do that is also done by subet sampling though there is the idea that in principle this could be replaced by by P sampling but isn't at the moment um so I just wanted to differentiate between these two and like I thought my understanding of what was being proposed was that this extra sampling the let's call it subnet sampling or extra subnet sampling I don't know that should be just replaced by more custody so making the custody requirement eight for everyone or the minimum one eight for everyone so still doing sub sampling but just like making it all uniformally kind of custody instead of having these two types is

that what's been proposed yeah so the mentioned that whether we can just make custody requirement equals to eight um I think the issue with that is for compatibility because if we make custom requirement eight then we can't um switch to like doing peer sampling for the the four extra um columns to get to eight samples yeah yeah yeah that's right the

advantage to have four four plus four instead of eight is that we can switch from C something to Pi something easily and if we if we yes if we say because the require amount is H we cannot switch anymore I I mean um the spec would be simple with Dimitri's proposal but currently I think it's a little bit more complicated but it's not I mean it's not it's doable I mean uh um I implemented it in prism is not so hard to to implement the current

spec uh you mean uh the cons cons consider uh switching to 4+ 4 in fork for example and if we are already with eight it will be an issue yeah if you are if we say custody custody requirement is eight for the fu fork and not four so we cannot switch in Fu from custody sampling to P sampling anymore but the question is do we do we really plan to do that for the F for or not to switch from custody sampling to Pi samping um I think that's possible right

if let's say if if some clients uh kind of ahead and implementation and we might end up having time to implement P sampling and then we end up using less than with yeah and and the still compliant Yeah Yeah from my understand it's it wasn't proof that P sampling gives better security when it work so we switch to something simple just use this last bandwidth it doesn't give you better security but it would be cheaper but I think there is no point to

save the band withd if we don't bum the B call right oh but we we will bump The Blob count H yeah but we require for anyway yeah but the thing is once we set the custody requirement to eight um if we want to drop it then it will require some extra work and also back for compatibility as well I mean Al in principle even without changing the blob count and like really needing to save bandwidth you could just have you know maybe some clients U experiment with this and without needing

like uh any change in other clients and we could just get like some actual like main net understanding of how this works even from like you know a few nodes or something like that that seems like a decent like if we do think that we eventually want to try to use peer sampling uh more then that seems kind of a useful thing if it's not too complicated to allow for this I just want to ask um dimetri so what's the current behavior for teu uh we don't do uh

uh we we just check that that's custody before this blockers fi and do you guys like subscribe to like four subnets or or eight subnets four subnets yeah yeah I see so okay so you're not doing enough samples yeah yeah yeah I see um is in pris we we we we we subscribe to eight subnets for full n and for a subnets of course for with

validator custody for a subnets for validators with low amount of e it's not that hard if you need help demry I think yeah yeah I think it's it's not uh complex to implement just uh I think full no and one validator know that should have same same requirements and it uh as a sub product it will make spec simpler and and yeah it ra me question actually um

maybe maybe for Francesco so right now the right now we have the difference between right now only the full noes have this extra four columns only the full nodes without any validator um with P sampling how does it work with spe sampling a full node with sample extra for extra column randomly but as soon as we have one validator as such do we still need to P sample or not anymore or as soon as we have one validator attached we we custody we we we with valid with validator custody we we subscribe to a

subnets minimum and then we do not need anymore to to request from the random sers I'm not sure about it um sorry could did you repeat the question I didn't quite understand yeah sure um with custody sampling for a full node so without any validator attached uh we have four custody columns and then we sub we subscribe to four extra columns for sampling and as soon as we have at least one validator attach the custody is eight and so we don't sample more

columns we just custody eight and that's that's all and after the custody amount uh increase with the number of validator attached so this is for custody sampling my question is about Pier sampling for pier sampling for a full node without any Val validator attached we will subscribe we will subscribe and C four colums and then we'll um sample four extra columns randomly with RPC what about peer sampling with some validator attached do we still need to samples random columns via RPC or it's not needed anymore because we

because as soon as we have one validator attached we already custody eight columns okay yeah um yeah so I don't wouldn't really need it like we we can just be fine with at columns um I in principle I guess we could change it like if I don't know we we saw that okay this is this is much better it works great and we're fine with uh putting peer sampling in the critical path like for full notes it's it's a whole kind of different story because even if I don't know it takes longer it's less reliable it doesn't really matter so much like even if you can't all the time finish it in 4 seconds it's

it's not a big deal um for valid validators if like okay it met some kind of bar reliability where we're fine putting pure sampling in the critical path um yeah we still probably need to think a bit about um whether we're okay with uh switching some of the custody uh over to to Pier sampling maybe leave like a minimum amount of custody that's really just for subnets um and uh yeah dude like some of the custody as spe sampling essentially like not not uh in force I think that would be fine because anyway I'm the the custody is still kind of a onest behavior custody right now so I

think it would be okay to to make that uh like not fully random like still kind of determined by um yeah like um anyway yeah what I'm trying to say is basically yeah we could I think switch over some of the custody to uh to beer sampling if we needed to but I guess the um the default would be that that you we don't need to do that and we can just keep the the the minimum like of eight for done through subnet sampling for for validators um yeah sorry that was May to bit too long but just it is yeah I I think we we wouldn't change anything for validators at first we

would only do so if we really wanted to kind of get some of the benefits of P sampling because it turned out that it was very reliable and uh worked better save bandwidth Etc okay so right now basically the P sampling only applies for full node without validator attached is that right yeah I me as in like the possibility of immediately doing that yeah or the possibility that that you know one client might Implement peer sampling and then switch over yeah it would only apply to to full nodes at first is it worth it to do it actually I mean because it's adds a lot of

complexity a appear something adds a lot of complexity compared to C something I sorry do it as in like to do to do it as in to do uh peer sampling in in as as in this first to like continue working on P sampling in general or do you mean like would it be worth it to do this like first switch or only full nodes yeah yeah yeah my question is is it worth it to switch to Pi samplings if it does only apply to full nodes without validator as such right because it's a lot of complex yeah yeah I mean I guess one reason we could want to do that is if you want to

just uh get some main net data on how it works and then like build up confidence that we can actually work were fine we have inv validators use it other than that I don't know I mean okay so that's maybe the primary reason the other reason would be just if you want to make full nodes um a bit lighter to run but yeah that's maybe not super important especially I mean given that if the comparison is with like nodes with one validator which is is not that much um so I don't know if we don't care about that then yeah we could go back to how the spec was before and just set um just custody to to aid for everyone as I said in the chat I I don't

really have much of a like this change was something that was asked for kind of a few months ago with this idea of for compatibility if I don't know um people are not of the opinion that it's super important at least I'm personally fine with with not doing it but uh I think it would be up to to clients mostly to figure out if you know if it actually is like a meaningful like if it's worth simplifying uh or if it's worth keeping in this for for compatibility I I I don't really know yes thank

you yeah thanks so it sounds like if we do p sampling for full noes with no validators it could um potentially save I don't know how much maybe up to half I don't know if it's up to half of bandwidth because we cost it we got the application but if we don't have to subscribe to those subnets and do p sampling then we could probably save quite a bit depending on the blob count if we have a high block count it's probably quite a lot but I don't think we have much data on it um do we want to make an inspect change at this point um yeah I I have a question demitry

about your last comment which is but increasing time for always with full not in in network something to me I I I mean if you if you have have uh one pier and it has only only four columns in custody and you need to sync eight columns so you you need uh two Piers for for the same thing uh there was enough one I mean for not share on only four columns yeah and my question is we we

discuss we discussed on on on Discord last week that um even a full node should store should store in it in its database the the four extra sample colum of course we should store the four custody colum but also the four extra ones and so my question my question is when we think when a full n s does a full no no no no I I meant when any when any other node need to sync validate a node for example one validat node needs uh two full nodes to sync at minimum yes at minimum yeah

yeah that's my point is that you need to all of them have all all blocks but for data columns you need to full no and currently in the no every node has all block for comp but my question was when we think with a full node do we need to think only with the four cust cols or also with the four extra sampling colums samp sample columns because if a full n needs to if we make the hypothesis that a full n

should store even doing the Sy the eight col so four cust plus four sulate colums in this case as as I understand if we keep sampling they should sample on sync too yeah so we still need eight in in both case yeah I think so yeah yeah franisco mentioned again it's um we have the um meain custody 8s for security reasons okay um do we want to yeah I'm

not sure if we can make a decision now whether want to make a spec change um is is there any any further question that we want to discuss further or are we okay to continue this discussion iyn k yeah I have a question uh about the issue you discussed with Manu at the beginning is it somehow related to to the dashboard what we've

seen on the dashboard for Lighthouse or or not this gossip um gossip issue that um you don't have like 128 columns for the gosip can it Rel yeah so I'm not sure which uh metric um you're talking about sorry before we jump onto that topic I just want to make sure uh we're finished with this discussion or do we want to continue offline because I think there's du active discussion going on in the chat uh just want to make sure everyone is uh um does anyone want to um talk further on this on this topic before we continue yeah Ju Just a final question

just so if I understand correctly from what's been said in the chat right now they're essentially being treated exactly the same except for uh the advertising and so the only question then it's not so much contributing to network or like these kind of things but purely just a question of like complexity of having these two different concepts in the spec implementation right like it's it's not really about like any kind of practical difference in Behavior but just the extra complexity correct any more thoughts we've got two

thumbs up Manu mat do you guys have any thoughts on this no sorry yes I agree it add some extra complexity yeah I mean nothing from my side Jo I think it's a silly differentiation and if we're going to custody eight why separate them to two different terms like just save the data serve the data if really the only downside is you have to store more data in the database for you know two e per whatever the 4 pox whatever it is you know the availability period so

it makes it easier I mean the original design of four plus 4 versus eight I repeat this is because with four plus 4 plus 4 you are able to switch from P for custody sing to Ping without any hard for it is really the main reason why we custody four and we some for extra if we decide not to switch to Pier sampling yes in this case we can ask the question do we still need to to keep this extra complexity yeah and I guess just to

repeat something related to this that we mentioned before uh this will only apply to full nodes so I guess the key question is like is there a tangible meaningful benefit in being able to switch full nodes to piering we got a hard for to me it seems like basically the only benefit is just being able to try Pier sing on mainnet and without needing a hard for for that I don't know if people think that this is useful I think but I I guess I mean that's the only benefit sorry go ahead considering how the hesy roll out went out today like do we really want to try features on do you know what I mean

in such broad context I mean it seems Seems dangerous as a as a potential to keep it around for that kind of a potential I mean this could even be like a single node it doesn't have to be that you know like a full or I mean I guess I said midet but yeah it could also be like I guess on a test net um but yeah I I don't mean like you'll switch over um 80% of the net and and and again it would only be full notes so it's much less risky but yeah I guess maybe one thing we could try to agree on is like is is that the only benefit are there other reasons that we would want to do this and then at least we can say

okay if that's the only benefit is it worth it I don't know does anyone else have other benefits in mind from doing this I mean as a as just a general code perspective it adds a total of 15 20 lines of code to our implementation to have both same and custody uh configuration um so really it's not it's not it's trivial from an implementation perspective uh it just feels from a spec perspective it feels a bit confusing and convoluted but you know honestly as just Devil's Advocate you know it's really six and one a half a dozen the other almost not even worth a discussion

to me personally this is kind of a it's a it's a nuance so I guess I'll go with whatever consensus is uh amongst everybody else um yeah I kind of agree with Matt does anyone have any strong feeling about this I am happy with the current spec but if the consensus decides to simplify it and to go from 4 plus 4 to 8 um I won oose yeah it kind of feel

like not many people have strong opinions on this as as I can tell um it's not the it's not that we don't have consensus it's just I think some some of us don't have strong feeling about this because since it's already implemented uh and implementation wise like like what Manu says it's simple but the spec is a bit convoluted um yeah I don't know if we can make a decision on this call um yeah anyway we are too far from finalizing full spec so we have long time to go okay so wouldn't say that though because I don't think we actually are

planning to make any other changes to spec so um like in principle the S spec should stay as is if we don't see any reason to change it uh okay yeah yeah um I think the soon we finalize spec it better I mean just to point out like besides valer custody which like the pr has existed since last summer or something I don't think anything anything really has changed in the spec for a very long time besides this uh El transaction pool thing now

silence is all right it s seem seems like we can probably continue this offline I mean we I think we've discussed most of most of the pros and cons of this issue and um yeah yeah we can continue this discussion offline uh yeah so Kya sorry um back to your metric question would you mind St again yeah my question was about the um gossip verification metric um which I shared to you so what I've seen on the dashboard that um uh TCO and prison have the same number of um verified columns like 128

and uh Lighthouse number was different so could it be related to this issue you have between Lighthouse and prison um you it at the beginning yeah I'm not sure because I haven't dig um enough because um the issue that man was highlighting was um The Columns that not like not all the columns that got being gossip from the LI house no to the prison Pier um I think what you're seeing is like kind of the opposite so you you're seeing that Lighthouse is processing less columns if I understand correctly uh what I've seen is it processing like less than

128 uh or super node yeah um so I'm not sure I haven't looked into the metric yet um but I can take a look I can take a look at this um this week okay thanks and uh I can't see currently the clients for devet 5 so maybe I will uh drop the link I will discuss it with rapael in the in the channel sounds good thank you um any other open questions

aish can we decide on some action items um so that we can get a deterministic super note percentage like I know it's just uh been heski and yeah there has been all of this news but I think it would be very beneficial and also like it would it would help us estimate column syncing latency and all of that stuff if we get a good decent um estimate on what um what yeah yeah the validator custody thing yeah like how many DMS have enough validators attached so

that the total note balance is just about above 248 e so like I'm like we have we have some estimates in mind yes yes yes all right sorry I I was um I was going to ask if you mean like an estimate of how many super we have in the network um because I think in my opinion that shouldn't really met with syncing um I don't think we should rely to we should have an assumption on um percentage of super noise when we're sinking yeah yeah yeah I agree to that but like at least it would help us estimate um what kind of network we are seeing and it would help us estimate U

at least the full node super node distribution while we run Dev Nets um in terms of that yes so yeah if something can be done along those lines like if we can get a decent number maybe ask all the institutional stickers I don't know like exactly how to go about this but um yeah this is like open for discussion I tend to feel like that is going in the wrong direction that excludes uh individual stakers and to have any kind of Reliance on super nodes uh they're kind of in my mind a nice to have not should be a need to have and to

make hard requirements or planning around them feels like tailoring the discussion towards these like we personally like we're planning uh to to do the best we can with no super nodes and treat those as a nice to have like if you happen to have one as a peer great but to lean on them is I I feel is antithetical to the ethos of what we're trying to do I I totally agree but then in that case we should run some devits without supernes then or like at least I agree with that have yes or like we at least have some report out

from each team that how is um a column syncing like entire drag exactly running with just full nodes in the network like I I wouldn't even be against like if we were to do a devet where just the boot node was a super node or something like that so like at least there's one on the network just in case there's some kind of an issue uh but everything is a full node and see how things go like we should push it to see what breaks because we shouldn't be relying on them uh to make sure the network uh stays whole exactly exactly so I mean from that angle again that's why I'm I'm basically

raising this question of getting the realistic percentage or the number it's always good to know uh what can be the estimate rather than you know so that's why so I don't really get like what exactly is the concern because if you know if you imagine a Dev net or I mean testet whatever it is like net with all full nodes there I mean there would be problems in that like uh we need Super nodes for for reconstruction in the current design that's just like part of the design and it's it's not going to go away magically but in terms of syncing it shouldn't be that different from what

it is today like if all full nodes just get four columns or eight Columns of whatever it is um why would it be significantly different than than it is today I guess really worried about just uh I don't know that peer count is not enough to have enough full nodes that that cover all of the columns or like I mean what I mean what I what I mean when I say similar to today is in terms of bandwidth like it would be roughly the the same uh yeah the same kind of uh amount of data that you're requesting from from your peers if you can if you find peers that have the that you need yeah but like I'm concerned about

the sync speed um the SN speed would drop if we are just considering full nodes like why would it drop to lower than today like if you're because you're because you're spending more time in finding intersections of what your like or like subsets of what your local is with other remote peers like for every slot because like like the peers also get disconnected so yeah because in case of let's say blobs blobs was not an

optional thing um all of them had the same thing so um I mean that's why mainly because of that yes yeah yeah just say so we I kind of I guess your concern is that so like you know you're connecting to the right peers in order to make sure that you're going to have access to the columns that you need um and is if is that what I'm following

yeah exactly I mean um like so we're doing that with our py like that's that's not necessarily a super no concern that's more of a like we we have a score waiting kind of like uh gossip but not exactly uh in order to uh basically cash the enrs uh that we discover and then when we need to connect to new peers we basically pull the pier that has the uh desirable columns that overlap with ours uh to make sure that we're going to be able to to to uh get the data that we need um does that answer your question

though like I don't I don't understand what your concern is yeah that that kind of does okay okay I I can I can take it offline if you want we can take it offline um yeah thanks for raising this um so I feel like what what you really want to get out of this is um how fast can we sync with P right um I kind of feel like we do need some sort of research in that area um I mean I could put that down as a um as an action item and then we can we can probably continue from there is that is that okay yeah that would that would be really good that would be really good okay because this is not just about this is not just about U

syncing it's also about um if validator custody is in place like we all are doing it and one second I'm sorry yeah if validator custody is in place and if we are all doing it then with a bump in validator custody our databases need to be reback filled if I'm correct yeah I read Lions hackmd recently where he said that there should be like an 18-day period where there should be no column bad column scoring for peers all of that um so yeah I mean just overall around this context yes um I I think there should be more

research on column sinking speed like all like syncing with pias yeah exactly okay okay thanks aish um yeah I will probably reach out to you um and then we can probably add a like action item to our um P redness checklist if that's okay um yeah so time's up so I think for the for remaining stuff that we want to discuss we can continue offline and for next week's call is going to be back to I believe :' on Tuesday so uh yeah different time next week um and I'll send a reminder in the chat um yeah thanks everyone for join the call see you all thank you bye

bye bye happy hes everybody woohoo by e