PeerDAS Breakout #1

Transcript

e e e

hello I can change the name hello

hey for everyone welcome to the

first um P breakout room so thank you for joining at this challenging time yeah where is our King de lion okay yeah so we have a agenda on the break on the GitHub and just a few seconds ago I just create this meeting notes and how people can help

to collaborate on the document you should have access um so I listed the basic agenda of like client updates and spe discussion and next steps um but if you have some more items you want to discuss feel free to bring it up here or on the agenda so I so see I here to moderate because uh of the SP I want to make sure that the space uh can reflect what is the current um implementation status but I

don't necessarily have to be the moderate here and I think you guys did great job in the inter and have more information and knowledge of what is um the current status uh so does anyone want to share the C updates after the interrupt hello um hi this is Jimmy um I can share some updates on the lighthouse side um can you guys all hear me yes great yeah um so after interrupt um we've we've got a few things that we've

we've uh we've changed um including making the p network parameters configurable now so we can configure um the like the the desk perimeters like number of samples and um custody requirement um those kind of variable can be can be configur configurable at runtime uh so we no longer need to rebuild it um the one thing that we haven't made a configurable the block count but I think that's probably something we can work on once we decide what we're going to do with um increasing block count in either Electro or the PS Fork um and then on that we've um de lines made a couple of good um custody look up improvements in

Lighthouse including um batching the request and low balancing request to peers and also um um prioritize peers uh based on the success rate so um there's a few Improvement lookup um and then also we've worked on um storage efficiency improvements but I think I think mostly we've just been working on U making more result making more resilient um based on the feedback that we got from interop um but now that we've most recently been focused on um our our our current release but we're looking to get back to pasas um again soon um that's it from the ligh housee

side yeah I I can go next um so for the president's side we've been slowly starting to productionize our peros code so for the interrup we to our shortcut so that you know we could get something working um one of the shortcuts was that we reuse a lot of our uh blob methods for data columns so we're slowly trying to decouple them um we're adding custom column specific you know like feeds from a database that you know you can differentiate between blobs and columns um um some of the things that we are looking at are basically on how to um is reconstruct data effectively so uh We've

managed to get that working so Manu has done a lot of work there um prism now can reconstruct data that is as long as we have 50% of data we will reconstruct it and broadcast it out to the network so we're using a Time Delta approach where um instead of reconstructing immediate um we do reconstruct it but we wait to broadcast it so in the event of the column does exist in network we don't unnecessarily like you know increased amount of duplicates out there um on another thing that we've been working on is to look at our uh basically how Val the custody would affect um how you generate node ID so maybe Manu can add

some a comment to that because he's been doing some work on it yep um let me find the link uh I brought a middle document so basically uh on pris at each uh start we generate a new um a new peer top private key uh which then we derive into public key then into non ID um it's not totally dble right now because uh if you continue to do that with pess uh um possibly the new private key will generate uh a totally new um node

ID and so a totally new um set of subnets and so at at each reboot we will have to backfill all the columns so we started to develop a strategy just to try to um Brute Force um private key in order to reach inorder in order to obtain the same um subnet IDs we we had on the previous restart and we have something working but which is totally not compatible with um validator custody because with validator custody possibly we don't know in advance um what are the um all the subnets we will have to custody because

it can change at one time and so I've I wrote a little document I just Link in the chat explaining um why we could have some issues about validator custody if we why validator custody would be not compatible with the fact that we generate a new private case at each um beon n boot I don't know if other client team uh also tries to generate a new private k each boot or if prism is the only one to do it I may say that te is reusing uh previous

private gey does generate a new one or or not sorry I didn't understand no no it doesn't generate new one okay yeah I guess prism is the only one yeah Lotsa regenerates the new node ID on each restart uh but I think we can uh sort of fix it by uh saving and rereading the previous enr that was generated uh and only DV wipes should basically uh generate new enrs but I think the reason why we did that was so that uh for example if any nodes are

Banning a particular enr uh uh on uh for whatever reason so a restart basically helps you get over it uh so those kind of issues might come up where uh you know nodes have banned some enr and they stop finding peers because you know it can happen that for example you started up started something it had some bug and then uh you fixed it or your elbows down and basically so for whatever reasons you fix did your backup but now you can't find pi so that would be a bit of a problem I think

I um I think we have discussed in in one of the PRS a little bit uh this regeneration and the I remember my point there was that if you are generating a new one but then you are trying to be in the same bucket basically observing the same columns uh you are in a quite unique position so it doesn't help your your anonymity in in in any way so if that's the goal then you are breaking it just by by searching for for a very similar one uh because you will be kind of the only node which is has

selected the same set of eight columns out of 120 that just too many yeah it was exactly the the purpose of it was to generate a new tot new private key but which match the same um data data column on N yes it was it was go yeah the thing is that um we don't have as many notes as combinations I think uh so if you are if you are going for the same for the exact same combination of of columns um then you will be the only one having that and then it's quite clear that it's still you even if you your IP address has

changed you are going back into the same scenario uh same subset of notes in which it is a very small subset because there's only you in it and you to that so it's at the surface you are having a new identifier uh but then you are linking it in in a way which is easy to to correlate uh s this okay that's my feeling interesting uh yes I see the question it was for anonymity totally per and Francesco yes and so we we were quite okay to lose

a bit of anonymity by brute forcing and but yes it's not really possible anymore and as uh Anon said yes we may be in the position where we are the only one to select to have a different private key and to select the exactly same subnets as well one compromise here could be that you I don't know how is it is in practice to do this but like as a full node where you you only have to custody four columns maybe you can still do this

if you don't run any validators and if you run validators then it seems like it seems to me like you already don't really have any chance of being in any way Anonymous like you have you know there is a clear fingerprint that comes from just you running those same validators um so in that in that case I'm not sure that it really matters to or like what what it adds to to do this um so I don't know yeah maybe you can it it might still make sense to to keep regenerating it if you don't run any validators but if you do then I think yeah it it would seems like it kind of clashes with validator custody um to try to do this yeah right yeah yeah yes even if you are not running in

validators you will need to have the consistency because you won't be able to serve peer request and then you will get banned so you won't find any peers so doesn't matter whether you run validators or not you will have to maintain the custody consistency for whatever node ID you are publish you are advertising you you then you can Brute Force like if you're if you're running just a full mode with the c requirement being for then it's it's pretty feasible to Brute Forces I think is what you were saying yeah yeah it is quite easy with um so I Linked In My document all the computation so for um 32 subnets uh yes there is only of course 32 combination

possible with one subnet custody and with and with so with 128 subnets and with four minum custodies there is about 10 million combinations which is a lot but which is still doable as Bo Force so yes for full no without any validator it's it's perfectly doable but with validator is more complicated because you don't know you have to to match more than for subnets and yes and as bar said if you have a validator I mean the networks already knows you because you have a validator so maybe it's not so important to to try to get

an anonymized peer-to-peer n peerto peer beon n private Key by the way you don't have to do this calculation at startup right you can you can pre-compute the next one y yeah or pre compute let's say a few ones maybe 10 ones or 16 ones in case of Rapid restart for any reason boot loop basically each B not will for

example now need to support another parameter that says that what are the uh data columns that you will custody or subnets that you will custody so that you can generate a node ID that is basically uh consistent with that custody or use you generate some in the beginning and then you'll have to sort of persist and reread it each time if you want to change your PR ID um yeah yeah the goal was to generate each um at every boot a new a new private key and so a new node ID which is consistent with basically at the first start of the node we we just

Generate random random private key and so Random n ID we compute all the columns which custody we store we store them in a file and at the subsequent boot we just load this file look at the previously custody columns sorry col colum subnets and then we try to regenerate a new private key corresponding to this subet it's quite simple so four out of 128 is still 100 million combination no it's 10 million

combination so you would be still like the the node which has the same combination so which I don't know if it's a problem um it's so my question is why why are you changing your your ID as it has why do you want to why do we want to change the ID in the first place that is a question I just what are the reasons for that yeah yeah it was for for anonymity yeah maybe maybe can can have

more answer about that it's okay I mean just you are giving up on that in the that it can be un covered but it's a it takes some effort to figure out the relation between the two not in the ID so I need more information than the ID because I need also to know what one level mod just if I know what you are subscribed to I know that you are the same because it's you are one out of 10 million we do not have 10 million for for some time everything single not you have a [Music] unique uh sorry to just recap it uh so

only pron and Loa gener new ID at each restart or other client also do the same thing um low St sorry Lighthouse Lighthouse doesn't regenerate the ID so we yeah so we maintain the same not ID yeah Nimbus actually does regenerate node ID uh yeah and did you achieve to do it uh when is

the uh no not yet not yet okay okay I can link my if you interested in I can link my my Po request about yeah yeah that would be nice thanks it's still in progress is not not as much St because maybe we we we we will don't we won't merge it maybe because of validator custody but yes this is my Pro request yep taking a look yeah um one question is um how critical

is to keep the same custody the uh um over a long period of time if if if not are restarted in production just every couple of months because of I don't know so far upgrade or something um is is is it critical to keep the C the same custody Set uh at that moment or or is it feasible to actually change the custody set and maintain the previous one for some period of time I mean it's fine if like one you know a few people like certain percentage of the network changes even all at once but if let's say um I don't know whenever we have a hard fork and everyone upgrades or something like that uh everyone uh

changes their custody at the same time then that's really bad uh like there should always be some like stable kind of part of the the network that that that that stays on the same sub subnets and can like uh respond to historical queries and just generally you know like the subet like fall apart uh all at once let's see I think if you are changing your custody then you will have to sort of download the data columns for mini box to data column or some uh whatever that

period is and sort of make sure you can custody right but even for that you need to make sure that other people are not trying to do the same all at the same time like if if you know everyone or like 90% of the network was was trying to do this all at once um then it it really would be chaos basically notes can adopt this strategy on restart whenever the p is changing

they can basically do this sync of this small window if they want to what maybe work that would be huge chaos so if not would know that this is the situation then then they could so they the gossip sub networks would have to be built and then not could

receive things even if it's not their own uh column but it would be very CTIC and I don't know what we take that so yeah and in are just there would be a small percentage of notes which would happen to have some common column in their old set and new set um but otherwise all the others would just hit on data that there is not on their go and chrome set I'm kind of thinking whether the the

mechanism that we have for for repair and cross seeding is slowly solving such a such a thing uh as a last resort back up but it's it's definitely not ideal I feel that we it's hard to get a conclusion in this Cod for this topic um the people wants to

keep investing I mean in talk uh discussing about it or we move on to leave it to the of my discussion I guess for me the my takeway is um um we will discuss it internally but yes for for no full node without any validator we we we can try to maintain this U shuffling of private ke at at start and for full not with valid L uh I think we will uh keep always the same

private key but we will discuss it internally with with your team man um okay keep continueing the K updates uh any updates from teu uh to be honest on my best knowledge

uh no major uh things changed since interrup uh yeah probably we have uh draft PR for sampling now uh yeah probably that's it thank you and any update for nus um so we kind of started working on pus at interrupt um since then we have implemented all of the like whatever finalized spec is there till now uh for in terms of consensus spec tests we are passing um like networking and SS

consensus objects mer all of that stuff we are also uh passing all of the kzg uh spec tests from the Nim side um we have to do some more work in the request response protocol get data column side car by root all of that stuff and yeah mostly just keeping up with the p and the spec changes um yeah pretty much that we also have uh support now for configurable Network PMS but I think it would be nice if we get like a finalized uh finalized document or anything from e panda Ops or yeah whatever they want to keep

configurable so yeah that's pretty much up from Nimbus yeah um Bas I think the general idea is that we keep everything that's in consensus spec as a spec uh configurable and if you don't want to be configurable then it would be a preset yeah okay yeah um no we probably need to go through uh by the way each uh spec value whether we actually want that to be changeable in the future or not I think there was some discussion

about this in the interrupt event as well yes so I think it was there like some I think we've moved some preset into configuration and is there any other configuration that we should move I think there's uh EIP uh activation no Fork Epoch right now and then if we are changing that to Pras activation e that would also be another change that we

can let see yeah okay we we will have time to talk about the Def One configuration thank you and uh is there anyone from lar here uh one sec show I think Jimmy mentioned something in chat you want to bring it up Jimmy oh yeah um so the max blobs per per block is currently a preset so um in ligh house we can't we can't configure this at runtime at the moment so I was wondering if we were to bump this value um maybe we could think about putting into the config or there's

any thoughts on this I think the main issue with moving it to a config is that it also has to be changed on the El side I'm not sure if we have any other value that's in the config and arbitrarily Changed by the CL that the El doesn't know about what is the actual reason the El need to know how many blobs there are uh gas estimation otherwise you can't sync also it needs to know for building block but like couldn't we tell the e um

this is the current block count that has been voted by all the validators same way we do for gas limit today and then it just uses that your mic is very badan uh did you hear it no no still shaking that I didn't hear you really well uh okay let me try again so right right now for transactions what happens is that you know we tell the El that this is the gas limit that has been voted by

the uh bar and there agreement we would bump up the gas liit so could we do something like that for the blob count does the CL actually tell the El what the gas limit is today I don't I mean you okay there any El dep here maybe they could so we don't basically CL does not send any blob gas parameters in the FCU but I think this is a change uh that has been proposed as well that uh uh the CL should send it so that uh uh El doesn't

need to hot folk each time uh when C wants to raise the limit so it makes probably makes sense and maybe we should include it in the Electra itself that CL will send uh like how Max gas limit is send Max blob gas limit will be sent and on the basis of that uh basically El should be able to produce block uh one of so danrad and ancar were thinking about this and I think they wanted to propose it and they probably are way ahead in their thought process at this point but when we spoke about it um the issue was that it break sync on the El side because the El would then be syncing an old block and not know how

many blobs it was supposed to have so it wouldn't be able to validate if it estimated gas properly um so you would then have to somehow add it in the header or added in the block body and that would be more changes that need to happen need to add in the header I mean it couldn't just be part of the max limit right so El should just check Max limit of the gas or uh I need to check it still needs to know right if the CL decides what the max limit is and the El doesn't know Max Li is Max commitment limit which is 4096 yeah okay then you change the

Paradigm to some sort of optimistic method where it just checks that it is something below 4096 but it doesn't know the exact value how does it how how how is it different from checking against let's say six for now right it doesn't actually matter once they have the state on which they can execute the block they will come to know or basically it since it's basically a optimistic sync uh anyway the parent uh so parent is sort of validated in terms of hash right sorry yeah um I mean I had an initial cono with Marik about it and I I think the problem is that if you

just knew it had to be some value below 496 then I could get a block and I have to sort of verify it and all I can verify that the gas is Right assuming it's below 1496 which is different from how it works today CU today I know that the max is six so if I get a block with seven blobs in it I know it's wrong but you verify against uh the transactions but hashes right so it's not just the number of blocks or blob gas it used says in the header and we have that in the header right blob gas used so uh that is already there yeah fair enough uh why can the CL just let the E

know in an engine API call what the Target and the this is for discussing and that's the fact that would break sync or you would have to think about sync on the E I mean the problem is what par is mentioning is on the optimistic sync when you basically get an FCU and then you sync back the chain and then you want to validate uh the data that you are getting in that chain for which you have not received any FCU and anyway the F and any with the parameter that CL will be sending to uh El will be in the block production FCU not the normal FCU that it would send on

the blocking P yeah and then the FCU triggers snap sync and I think the issue then is that snap sync needs to take this into account right snap sync doesn't sync any blobs right snap sync only straight but yeah but I would need to import the block to validate if it was valid or not and you don't validate The Blob at all when for example you get a block and in a noral trans in a normal uh scenario when you get a block and you send it to over to the E you are not sending them the blobs you are sending them the transactions which has version hashes which is basically used to validate blob Gast uh so actually blobs are not syn by

the E once they are produced yeah that's fair um I'll try and get the argument we had and I I can send it to you but yeah there was definitely something on this yeah you can start a thread on Al Cod and we can talk about it yeah because I think marik's preferred approach was to for example treat it like a difficulty bomb change if you want to simplify it or add it to the headers like one of the two approaches versus preferred option I mean it's not really required to make it more complex I don't see the reason why we can't just have this upper limit and Trust the data

that is in the headers because if you for example get an FCU from the CL and you have to sync back the optimistic sync through optimistic sync all the entire chain that you are downloading is valid because it is the parent child relationship that you are downloading and not downloading anything else so if you are for example basing your can Canon aity on the basis of the block hash that you got in FCU then all of the ancestor chain is sort of validated yeah fair enough um I'll I think D's also here so I can just ask him if he wants to post stuff or just in general bring it up do we actually want to change this for

uh Vectra by the way three and six so I would support basically CL fcing uh the max blob gas for the block production and then Max BL per block would become a config variable instead of a preset so max blobs per block for or uh the El would then shift to 4096 gas so they have Max gas uh ma Max blob gas parameter which would basically now correspond to 4096 times uh blob gas parameter so uh they would shift that they would configure

that parameter to the new one and then uh the CL configuration can happen on the basis of whatever we decide whether we want it to be uh uh up basically a Time based roll out or increase of the gas or uh of the max blobs or through a hard fork or soft Fork kind of scenario I mean that that all that is fine just to eoda discussion that is going on

in the chat yes I think uh we should do it in Petra and not bump up the blob count from the CL side as well um regarding the what what was the consensus on EIP 7 uh 5 94 Fork version Fork EPO naming scheme so how do we want to trigger P death actually I saw some push back or actually using it as a fork and some push back against doing it as the

fork I Am pro having it with a hot frog because easier and more clear just my opinion I also favor it as having the heart F because then uh uh the typing of the data that is referred in the code everywhere is sort of more clear and more easy and less messy and I think uh the boiler plate code that would be required to add a new hard Fork uh if it's not minimal it is it must actually be fixed across all the clients so this is my opinion that it is cut and dry and should be just be a hot

folk but uh if uh teams choose it to we some activation obviously will make that happen as well just a quick clarification when you guys mean hard hard Fork do you mean a pi specific fork or do you want to just activate it on Petra post Spectra folk on top of uh so it could so as a hard for as a sort of which has basically its own for question and forok but scheduled after Petra I think after Petra is going to be confusing maybe it makes sense to do Den

plus pias I'm I'm mainly making the argument because there's three streams and we haven't still decided what Petra is so eof is also having a similar discussion right now on how they should activate it if you decide that pias needs to be activated on Petra as well as electron sorry EF needs to activated on Petra and we don't know what Petra is I'm sorry but that's going to be an insanely huge cluster of mess that no one's going to be able to untangle um it would be easier all three start with denb as the base and then we do essentially three fors and then we can have three different lines and whenever we decide

what's going into Petra finally we can merge stuff through and that was kind of the advantage of having the Petra for Activation Epoch approach but activation you mean for the dev Nets or you mean when it will be activated in main net right now I'm meaning for Dev Nets um but yeah I I have no particular thought on how it would be for later I think I'm okay with that devet approach and midet will Anyway come to decide when we'll see what what is ready at what times timeline but uh yeah so if if it's as a as a fork happening then

basically we'll obviously decide whether pectra comes before or where P has come before but I'm fine either way you we mix everything all together all the time but I think the C part is to figure out if we need to bump the blob count and the P desk upgrade all together in that case we need a half f for the I mean also to clean the E part as well in the same upgrades and including into P another

topic here I think it depends on the timeline and that's f with forever for the defate but just for the minute half I think it makes more sense to combining together and sorry to try to stop here because we have still have many things on the agenda so I want to speed up a bit and so what's the action here we want to use the activation epac for the defate I think different teams have

different opinions on this yeah I think that's part of the problem the argument keeps coming up and then we're always just moving between the two slides but not making a decision yes oh the plan is now here for the Deets can we just continue doing what we did for defet zero I mean just have it as a fork and or or has Lighthouse already moved to the new mechanism for devet zero we kept the same Fork version as DB and then we had like yeah we had a fork Epoch which

activated Petra which in effect is Petra activation Epoch no no no he's talking about peer death and P death activation was thep 7594 Fork version and Fork EPO that we activated at like EPO one or two or whatever it was and we didn't activate uh pectra at all yeah yes sorry I was talking about P pector so is the question do we want to have P Des definate um combine it with Petra or not or separate def I would keep it separate for now because

Petra and pias just have completely different teams working on it and if we combine everything right now we'll be blocked by other teams who haven't finished their stuff oh it's good but then the idea is to keep everything the same so we would have still EIP 7594 uh Fork version and Fork EPO keep it as a hard fork and uh let's leave everything aset zero and just try to do devet one and once uh devet one or devet whatever is stable then we can come back to this and decide how we actually want to activate

it now it's good to me I mean at least we can keep moving and T all good okay I see some SS in the chat and okay thank you uh so somehow we only have 10 minutes left for all this uh St discussions so I think it it would give some some time for the pr also to give a quick recap of all the pr that we listed uh staff um Chopper okay so quickly the uh the pr

which is the second in the list is the is clarification of samplings and everything sing around sampling so it's splitting the description into a simple selection and simple query and then descriptions for both um and it contains a bunch of clarifications of how it is recommended to randomize uh and also a function to have the uh to how you can get more samples and and allow for some losses so what we call loas um I have most I had a bunch of comments most resolved I still have a

few from Pops pop uh which I not resoled one is is just U function naming and whether we the constants are going to the parameter just used internally I'm just waiting for pop on that to be happy with the solution I hope and others and the other one is is more on a theoretical Point uh I was writing recommending uh sample selection without the placement because it's just easy to implement and uh and just gives better performances so if you just go and implement the spec you you get the better behavior um but we had a small discussion on that and uh yeah I'm just waiting for pop to

agree or disagree with my last Point uh yeah I think I think the I mean the the function signature like the the parameter of the of the function I think is good already yeah okay I agree with that yeah yeah on the other one um you might need times other want to to chip in um it's it's really just uh so I'm I'm recommending uh when I'm describing what's the random selection which is good to describe something in the the specification so that if you implement specification without thinking too much you implement the right thing I'm recommending uniform L selection without replacement uh as a recommendation so if

you have reasons to implement something else you can Implement something else um yeah I think it's not a big deal uh but uh pop was saying maybe I should not recomend the uh without the placement but uh yeah I also think it's not a big deal like yeah I think it's not a big deal like I I I just like my first thought is like uh I don't I just don't understand why selection with displacement is like more perable or like more recommended like I don't see much difference and that's that's all but I don't have strong perence like yeah it's okay it's okay

for me to put the recommendation in yeah it's just uh so you have to choose something either this or that and and and uh slightly better the the result replacement so if you just implement the spec you you implement that and then you get slightly better performance uh that's the the only reasoning there I I think uh I think to be honest I think uh selection with replacement I think is in my opinion is a lot easier to to implement you just you just select the the column like uh from the same set like every time so if if you do if you do select the the column without

replacement right you have to remember what you have chosen and I think it's like uh it's harder to implement but I I think the the one with with replacement is simper in my opinion yeah it's I mean it's it's slightly simple but the difference is is is is small it's typically A Primitive in the in in the libraries or or you just remember and and cross it out or you do a permutation um yeah so you you you can implement it easily um anyway uh I was putting it as a recommendation so it's you know it just means that you can just forget it and and do the other thing I just wanted

to specify it it it does give better probability sometimes slightly sometimes slightly more it actually starts to matter when you are doing the the incremental stuff but that's not something I want to describe in the specification because that's more like a client strategy um yeah but I don't want to steal all the 10 minutes so we can we can continue it on the pr yeah thank you tra um next uh Franchesco would like to talk about the F Choice PR hi uh yeah so there's this PR that I

just linked uh which does a few things I most of it or like some some of it is just uh the parameter changes that we sort of agreed on and interrupt I know like it wasn't you know exactly agreed that we would do 128 but um that's I mean up for discussion whether we want to do that instead of 64 um I guess some people had the feeling that it makes sense to maybe try that out and see I don't know if there is any reason not to do it because if we can do it then we do get some kind of um well we do get basically like a 2X um better uh kind of efficiency um and yeah the other thing is volid data custody um there was some discussion um with uh with Justin uh

around like how exactly that should work um and I think this is still I don't know I think there there's more to say about this there's questions around like um I think particularly Anar even though we didn't comment on the PR but we've had some discussions and um about if there's ways to um introduce this uh assignment um basically really being like in protocol kind of like a public assignment uh so that there's some degree of accountability and whether or not it's possible to do this in a way that doesn't really conflict with the anonymity um questions and uh so yeah I think there's more more to say about that but I guess yeah the the general we we still wanted to like introduce the

the general concept of valer custody because we do think that or at least I think um that it's uh it really der risks the whole transition to pias and just like really you know lets us use the fact that we don't actually have just uh a million validators but like some concentration of stake um and then there's the the four Choice part um which it's a few things like one is basically changing the way that uh on block uh that basically that the availability checks work in on block uh in in the spec which is the block importing part um basically right now um the way that that part works is that you just don't import something uh that is

unavailable um whereas here like the only check that you would do there is um after justification so you would you only wouldn't import things that uh would justify an unavailable block um and and their unavailability is um basically you know determining whether or not something is unavailable there would just be through peer sampling um otherwise the kind of normal kind of uh you know the live let's say availability check is just a custody check so you wouldn't do beer sampling um and yeah again this is another thing that I think I we talked about is the interrupt like it makes everything kind of simpler and more robust and lets us like delay by a

lot uh the usage of peer sampling um and I mean another small thing is like in the um kind of um in the for CH filtering part where you you normally would just use custody you also would use peer sampling but only if something is from more than an appoo um and so again it's like quite loose like you should have plenty of time to to uh be able to do Pier sampling uh and I mean if something you know if you really cannot satisfy peer sampling after a whole EPO of trying then it seems like there's good reason probably not to um follow that that Branch um I guess yeah if anyone has questions about that there's linked a couple of

documents that one is like kind of summarizing what we talked about it interrupt and why certain things um may make sense to do um which is a lot of what it's in the pr and then yeah the other document is more specifically about the the for Choice part um yeah if anyone has questions uh we can talk about that and but before that one last thing was um basically there there was at some point um the idea of trying to move to a four Choice which is like block slot or some other thing which essentially um would make it so that when um people don't vote for a block then that the block is kind of discarded from from the fourth choice like that

you can essentially have the empty slot kind of win um and this makes certain attacks a bit um basically yeah it deals with certain reor attacks a bit more easily um but I think that it's probably not worth the complexity in practice to to do to do this right now I think basically these attacks are not that much different from a proposer dos um kind of situation that we already have today like in theory you know this could happen and we kind of rely on um well two things like one is just you know proposers like at least like bigger proposers protecting themselves um and

then also in principle if it really became a problem we could have measures in place um and yeah here it would even be simpler than you know what we would do with proposer dos like we don't need the whole ssle Machinery we could do this for TR change um which is much smaller uh and so yeah I think basically I would leave I would tend to leave things as they are um from that perspective and kind of don't embark on this complexity of trying to change the for choice in that way and try to have a a backup scheme and things like that but yeah open to I mean I I'm not sure if this is like something that people have opinions about because it is a bit um deep in the you know the whole realm of

Fortress attacks but it's not that complicated so if you do have time I think it would be nice um for other people to to try to like familiarize themselves a bit with this specific attack factor and like you know try to have an opinion on whether or not you think it's okay to just do nothing um because yeah I think that would be that's my preference now but like it would be good to have more comfor like what we think about this um and again this is discussed in in the pr and in the docs uh yeah now if you have any questions or whatever let's yeah um open up the floor thank you justco on the next is menu and the the enr

record um just quick know I think that's ready and just want to be any objection if not then I will go merge it yeah yep so um on pias WE introduce a new field in the eum N record this field is named coding subet counts and this is a key and the value is um ssz u64 as you may know there is a thir three 300 bytes maximum for the eum not record and so what I propose to do is just to reduce the key from cust subet count to CSC which saves 19 bytes and to move from as for the value to move from

the ssz u64 to just a big Indian integer which which can save if we use strictly less than 128 subnet count seven bytes and yes I think we will use exactly 128 um subnets so we will save six bytes so in total we could save 25 bytes and about the big integer is just using the same things than we have today with the UDP Port of the TCP port for example because yes right now there is not at all SSD uncoded stuff in the enr and by the way enr is already RP uncoding so

there is really no reason to both uncode with rlp and with ssz that's pretty it and so in total we save uh about 8% of the maximum size of the not record that's all thank you and the next is um pop and the asive sampling uh do you like to give an update uh yeah yeah uh uh I noticed that uh when when you do samping right you I think we don't us know like when to

samples like uh we we should know like because if we sample like too early we will not get a sample right if we sample like too late oh uh we we like uh lose some time like waste some time so uh I think uh I I think I have an idea of like something called passive samping like instead of just using the request want to get the sample you just uh Joy the subnet like just a moment before before the slot and then you just passively receive the sample yeah so by doing this you you you get the sample as soon as possible yeah it's like uh if uh yeah that's it let's call passive something

is this the same as introducing the sorry new control message observe in Gossip sub uh yeah actually yeah I think uh actually you you can do passive samping without the the topic observation that is an upgrade to the that I I I just propos like it's just a different story but but with the topic of observation uh it's uh you can do passive even right in term of the band consumption like uh what you can do is just like instead of joining joining the the subnet like directly you just

observe the topic because because when you observe the topic you you get only the message ID of of the message in instead of the the actual message so you you you you will get no notify when when there is a new message but you don't us have to download the the actual message so so that yeah that is that that is a benefit of topic observation so yeah from my point of view I think there there are three different ways of interaction possible here and then you can Implement them as try to implement them as part of of Gossip sub uh or as part of the request response so one is the first one is I ask for the for

the column and and you give it if you you have it you tell me you don't have it if you don't have it the second one is I ask for the column I tell you that I'm interested in the column and then after some time when you get it you send it and the third one is is what you say here I think which is I tell you that I'm interested when you have it you tell me that you have it and then I tell you okay now give it to me and then you give it there is three different ways of of getting a column at the end of the day and uh we are a bit jumping back and forth between these three ways of of doing it and then we are also discussing a little bit what kind of networking Primitives to use that to use a new Li

P2P gossip sub primitive which is the observe or to use a request response interpreted as once you have it send it to me um honestly I don't know which one is the better and I think it also depends on on the sizes of the columns which one is batt I think I think like the second the the second option the the the send the column to me when you have it is I think is actually joining the the subnet right it's like how is it how is it different from joining the subnet like because when you join the subnet you you actually tell your PS that okay when you have the message you just send them send send me the message right is like I

think that is actually the the sub subscription yeah the joining the sunet comes with a with a bunch of U limitations like the uh the MH degree and so on and so forth so that's why it's not it's kind of similar from the message point of view but then you have lots of side effects there so that's why one way is to use the request response and I send you the request and the semantics of that is send it when you have it and then freeing yourself from the from the gossip sub considerations but but I agree can be mapped to the gossip sub if you modify the gossip sub um interpretation it's just you know I I don't know which one networking p is is

the best and I don't know which one interaction is the best um just trying to about the options um if you do use it as part of Gossip sub there are a few issues because from what I understood in the pr you'd be using a different mesh size than what we have now so there is no way to you know like differentiate um a normal Pier that's going to you know forward the message where was this special P that's just trying to observe message yeah so you would even need to modify goip up to to put this differentiation into it basically I think yeah that' be pretty non-trivial

from what I've SE okay guys I B the seed of the meeting time um before we wrap up this Cod um could we go through what the to do actions or like any very important thing that we should discuss today instead of the S St CLE i s St I'm inan the ACDC no okay so I think we could

definitely talk about the BL Max uh configuration and setting in and how it's in the e um the S St C that could be a good topic to be there and and the second action this here is to go through the forr preset and configuration files to check if anything that should be on in the configuration or another side and anything else and I make a small p in the

in the chats to see if people want to make it a weekly call or bi-weekly and so far we get more votes um the weekly I think it's because it's the first goal and we have too much too many things to discuss and running out of the time and so okay mobs are coming mobs are coming H okay interesting so uh Jimmy please yeah um I actually want to talk about uh um maybe we can talk about this a but um on Discord we've started having

a conversation on um what um what what we can do for the proposal that are doing local block building because like um if we move to pias and we if we increase the the block count then it's going to significantly increase the upload um when when the proposer proposer block and if they use local block building then that means they need to have like um um 32 to 64 megabytes of upload in one go um so I think we talked about approaches to how we can like maintain home stakers feasibility um so maybe we can just continue this

discussion async or unless if anyone want talk about this now like is the argument that it's unfeasible right now or in the future um it's unfeasible if we increase the blob count to I mean at at the moment um I think with the current block size is okay but if we try to increase it to like like 32 megabytes or I don't think it has to be 32 but um once you increase the blob count it will basically make it like

hard for hom stakers to um publish the block and blobs timely um and I think there's proposals on allowing a c flag for the U validator to um provide a Max blob count on like what they can what they can um handle but I feel like this might actually limit our scaling so it would be good if we can find alternative approaches so from the networking point of view we had uh s writing on the discussion in our simulators since quite a long time we are using a a modification to to gossip Sub in which

we are sending out the data in a way that we are sending starting by sending out one copy of everything first and that reduces that that means that you don't have to necessarily count with the goip sub multiplier uh it can still be quite some data to send out a full block uh or an extended block uh but at least you don't H have to count with an eight times multiplier on on the B requirement and I was promising to to have a light upon that which I don't have yet uh but

it's it's something we have used in in our simulators uh since last year okay you want to talk about the idea you mention in the chat um yeah it was just that we could uh send it to relays who are probably already doing it already for um block Builders or altruistic nodes uh like

maybe the super nodes that we have in the network who will just propagate the BL um the blobs would you need to statically PA with those notes because how how would you know right that these guys would send the whole block out yeah they might have to have like a flag that says you know I have a lot of bandwith or something like this I don't know how we're GNA um identify super nodes on the network either way I think they just look like regular nodes uh we we could CU if we know their custody count um we can figure out that they'll be

hosting a lot of data right um yeah so that's sort of one possible mitigation for this but that means if we have 32 blobs we still have to send out like how many um like 8 megabytes of blobs to that um super noes right yeah yeah yeah so that there was in the depos there was there was one proposal not to be not to need to send out which is building the block also in other places kind of a distributed

building uh but otherwise you have to send out at least one copy of everything and uh the we can try to identify places which are kind of super seeders in the network so that you just send one copy to them and then they are leing it all around um I'm not sure that that's the most reliable solution so having all these kind of network optimizations in also come with their risks and I'm just not sure that's the right choice but it can be done

like send a first copy to someone like that and then if you have to send out a second copy uh then send it to send it randomly you can have these kind of mechanisms um the so you're mostly looking at the 2D case and the 2D case the the code is very good in and you are just sending out one piece of random copies and even if things are lost things are also recovered very well with the underly Reconstruction that we have in the in the 1D case so in in here buildas if things are not going out because you are only have the band to send out one copy and then they are stalling then things will be stalling until there is a a node which can

reconstruct and then then seed other uh other topics um and the issue is the timing right like if I if local block Builders as they had like 10 seconds to send out um all of the blobs that that would sort of it would no longer be an issue or is the issue just the total number of bikes that need to be sent out regardless so the the issue is uh so with noral goip behavior you typically uh start sending out and then you are sending it to eight copies of the First Column and then eight copies of the second com so you

you you end up doing an uneven sending out if you don't have enough bandwidth if so the thing starts from if you don't have enough bandwidth to to send it out in time uh then you will have this ordering in and in in in what you are sending out because you are sending out to to to eight notes uh one piece and you are sending out another piece to to no notes so so the another colum The Columns are not treated equal in that sense and was balancing that so that you are putting notes in the network in the position of doing the recovery faster in

the timeline basically so that's what you achieve by sending out um one copy of everything first each of each column you are sending out one copy so the amount of data that you are sending out is basically twice the lock size then depending on your bandwidth that means something um depending on how many megabytes and how many megabytes per second you have Uplink um you took a few seconds to send that out but at least you you are not taking eight times more to arrive to a position where uh where nodes can uh can start the

construction if if problems happen the problem way would be I send out the first go uh eight copies of that uh and I'm queuing up the second column to others and I'm queuing up the third column and and it gives a an ordering to the to the columns so that's why either you are spreading where you send and you are making sure the first copy is going out of everything relatively early so that the network can do his job I mean the peer to-peer distribution can do his job on every single column okay thanks give me some Jaa CH test and

do we have any final point before we close today thank you so much I I started a PL on the on the Reconstruction and on the CR seeding so it's related to I think what Nishant is already implementing and and what had been discussed in the interop I was trying to write down spec for that but I'm not sure it's already major uh I think it's a it's a first

version for the next call thanks right so I think we will um for the pet uh it's in a highly iteration stage so I think we would merge PS more faster than the Petra um content so I hope the cents can also help signal like which PRS that you think we should include and which shouldn't on the GitHub otherwise um I know like TR open the P

for a long time and but we was still don't have that competency to merge it as soon as possible so just hope to see more know thumb UPS approvals thumb down on the PRS and any other things for the call today so I went back to see the the boat so it turns out we still get more we get more boats of the uh Bi weekly code

so uh the next code will be likely will likely be scheduled on the 25th June 25th okay okay so uh let's talk about it um Thursday and two weeks later thank you um the video will be published in the on this call thank you thank you bye thank you thank you