PeerDAS Breakout #4

Transcript

e e e

hey hello everyone hello way today um she can't make it to the meeting today so I'll be feeling on her behalf yeah um welcome to the p as bre our call um I think we we don't have much items on the agenda today so maybe we'll just start with a few client updates um as anyone want to go first I can start uh yes so for prism uh about pure death uh

we now we run Rec Construction in parallel before when we wanted to reconstruct the Matrix we reconstructed it blob by a blob which took some time now we did it we do it in parallel and also uh for super node when for node we we used to consider that a block block was available only when we receive the whole uh the all 128 data colums right now uh we consider the block is available if we receive only 64 colums of course 64 verified Colum why 64 because when we have 64 we know

we we are able to reconstruct uh this is it and also yes we fixed the important memory leak uh we had from the beginning in the in our P Branch uh it was a cash issue actually and now there is no memory link anymore um yes it was mainly that for the last week cool thanks man um I can go next um for Lighthouse um so in the last two weeks uh we've been mainly working on stabilizing our D Branch um we've had a few issues um in

DEET one that we still haven't solved yet um one of them is the U P death HG Library um that we are running into a stack Overflow issue um Kev um Kev is looking into this at the moment um and at the moment we have to um do a workaround to increase the stack size just for now but um we're hoping to get this fixed properly this week um and then other than that we're also investigating our sync issues um and trying to focus on getting our Das Branch changes onto our main branch um yeah so a bit of refactoring worth a bit of tech dep fixing um and we're trying to make sure that we can

serve the data column by range request U reliably before hopefully before the next DEET um so that's our Focus right now and yeah that's it for Lighthouse uh I will talk about Teo uh so uh we are passing our Alpha fre reference test we have all logic before the net but uh the structures were not updated so we have updated it we did a lot of work around observed de logs potential Deadlocks uh around client stability and we plan to continue on

this side because it's a bit it's a bit prototype and buggy and we want to improve stability and that uh tests to make the client mod table also we finally merge sampler it was ready for a long time but we decided to refactor it uh and we want to combine custody and sampler uh but but we will do it maybe in a month and currently I'm working on L sampler uh both Samplers will only lock at the moment uh we are not planning to turn on uh for

choice to stop impart with one trailing slot I'm not sure it's in in current test net if it makes sense that's all for thanks sorry uh sorry please um pleas go ahead yeah so for Nimbus uh we're currently mainly solidifying the code around the P2P interface last week for devnet 2 we tried to have a super node variant but on some further interrupt testing we uh discovered some issues

with syncing it looked like uh our normal node is sort of sending out some bad range requests and turns out we had some issues in maintaining the valid custody peer set so we are currently working on that uh apart from that the last uh two weeks we have also collaborated with Kev to initiate the rust pias crypto backend integration and I think we are passing some of the fixture tests I think if Kev is here he can okay he's not here he can he could have probably elaborated more on that uh we had to refactor some of our reconstruction logic because uh of the new and recent developments of of the pioda spec in general and speaking of

pioda spec U for the past couple of weeks it was sort of a blocker for us to use CK's dust Branch because some of the nonp Dust code uh was conflicting with our base Branch so we were kind of using a fork of the D branch and we were passing all crypto tests from there and now due to the recent merge we are in process of bumping up uh ckcg in order to be compatible with the base branch and as well as the p branches um in general we are also investigating ways to maintain the least amount of diff from the base Branch but I think that can be only executed to completion when uh the fork logic is finalized or in general if we have a

finalized Fork Epoch for the next devet and this week we mostly started working on sampling so looking forward to finish that up in till the next period of just break out so that's that's all from Nimbus uh does anyone else want to give an update yes soers from Grand team so a few folks from fellowship program are working on pias I know they did some progress however as far as I know the we still have some sing issue so not that

big update so far oh thanks sias I can go for Out start uh so basically uh we were able so we successfully refactored all our S as well as uh unnown un blockings or partial blockings there where only the route was not on or where not all data columns were available in the CET so basically overall the entire thing is sort of uh working now and we also added uh uh ability to be a super no uh

through a param so if one can specify that CLI param then we can also act as a superod uh right now uh we added some test for us for for the block production uh data column synthesis part and I so we are passing that so we should also be able to do block production in the testnet uh apart from that uh we will now uh sort of uh uh add sampling onto it and U I think uh one more thing that uh we should do before the next uh uh defet start is we should basically also

include uh uh the metadata uh custody uh PR so that because I think that is sort of a missing link as of now because if there is an incoming connection uh we assume it's cust to be Min minimum basic custody so uh for the next devet let's basically have this sort of a complete thing where uh we have this complete data and we know what our peers offer us so that we can do a better sying and uh have a good stable devet thanks

ginda I think there were some comments around the Met V3 um spec PR um I'm not sure what the status is maybe we um I'll add action to follow up on that PR um is um has everyone gone yet any other updates cool um looks like we don't have um devop today um I guess um we um there was a discussion on Discord last week

regarding um definite to launch just um in case if any of you missed it um it's been postponed and in order clients are focusing on um getting the clients um more stable and reliable before we launch definite 2 so there's no definite to now um but maybe we can um start thinking about what we want to include the next net um at some point do anyone want to talk about um any DEET one issue that that um we still data still outstanding before we move on to stet um during the last DEET I guess

some clients have had issue with um initial thinking um at this pris had and some other clients as well I guess uh I think we should have clients should have a correct initial shink um for the next devet so it's it will be easily possible to add a new nod after the devet start yeah agree um I think we should also make sure that we can serve the data column rpcm points reliably um I think that was like one of the

issues that we had in the previous St as well um anything else to add for the next step net I guess we have syncing and we also have metadata V3 um I'll just write some notes and see um if anyone else want to add any any more items for next stet um I wanted to basically like cross check with everyone of yall like uh when should the pias get activated because uh

for Nimbus it's a bit problematic to activate it at denb so if anyone of you all have any alternate uh input that would be really great is it because you you have appeared us as a as separate Fork uh yeah yeah yeah that's how we we were working it out because uh we had the assumption that it would be a separate Fork when we started working on it and it's currently much diffed with Electra so there is no way we can merge

or yeah I mean we can rebase but again that would that would be significant refactoring and maybe we might miss out on the next devet as well if we do that so a bit uh doubtful on that confused as well yeah so the way lotar sort of has handled is that I mean so the Electra current electrc branch is separate and PS branch is sort of fored out of dap and uh what what we have done is basically uh I for example have created a fork in uh in uh in that Branch uh and so what I

do is uh using uh the config uh uh and Epoch and uh uh Epoch variables I basically schedule it on uh on that particular Epoch and that seems to be working out fine for me uh on a denim Genesis so what exactly is the issue that you are facing um so what we were doing initially is we were picking up uh the pias fork version and Epoch and we were um like at the very beginning we were replacing it with Electra but then we realized that uh the devet uh starts at

denb so we were replacing it at denb and since we were replacing it it was uh like the logic uh to like have some of the pias functionality going uh was sort of like um if I am at um a fork version greater than equal to denb but um I'm just having too much of a blob activity as well and uh that is sort of uh making like just using up more resources in general so uh that is why I was asking yeah so you mean you are doing blob uh API calls and all that as

well yeah like we we were doing like if I don't obviously comment out stuff we would do uh because we went with a design like that uh but yeah there is no way to have it uh Backward Compatible at this point yeah but you would sort of need to do the same thing uh whenever we merge it in Electra and activate it at a certain eoch yeah but like if we merge it at Electra I have like a we have a separate logic where we can specify that if my Fork version is greater than equal to Electra then uh do all the p d stuff like RPC and all of

that but you right now you don't introduce a new Fork you just are replacing denap Fork that is what you saying yeah yeah yeah all right maybe you should just add a new Fork I mean to simplify your life you can just add it as Electra and use that uh the variables uh yeah right right right uh yeah but like again that would that would probably uh I don't know about if we were to refactor and like have a less diff lesser diff uh from Electra but yeah I mean that would

do but like I think uh from our perspective if um we activate uh pios if we even if we have a denb Genesis and we activate pias at a slightly later Epoch that would be helpful because I think why while uh running curtois I was checking the config and it just says that for keok of pias as well as DB is zero so uh yeah one of the ways basically uh this can be sorted out for you is that let's say in first few eox there are no data column SL blobs so that way basically you know you could

configure for example to activate your stuff ATO one right and thereby keeping the backward compatibility as well uh for blobs I guess is it uh yeah so maybe when the when the next DEET is launched maybe for a few Epoch we don't start any block TX right exactly exactly that would be good yeah Dustin has a question D what do you mean by fake denb stock uh am I am I

audible yeah yeah okay I mean that P never it won't yeah it's fake I think there's some audio issue yeah so uh this is mostly an artifact of how interrupt was done because we're working on pias and electron parallel so this is why we

build off the neb for now the I mean yeah I agree like it will never be deployed during na but the ultimate goal would be to have it after Electra I do not know when that will be I think DEET 2 is still early to do that but how will sort of this basically change anything I mean basically in my eyes it just rebasing p on top of Electra when that happens so uh does that uh basically impact things in any in any real sense uh for us no it's uh so we've already like worked it out we can build

it on top of either DB or Electra but from what I understand this is It's not that simple for Nimbus because uh they have to do a lot of stuff to get it to work um but right now if you would configure pias on Electra prism would be able to also we shouldn't rush towards reasing it on top of Electra because that code bases sort of moving and it would then require multiple rebases as we move along and I think it would be best that we rebase on top of Electra towards the end to avoid spending those depth [Music]

Cycles yeah um I I don't know about the other clients like I I think Electra is not in a stable state yet where we can comfortably build on top of it because there still hasn't been a long running Electro devet so for testing purposes you know it makes sense to go with the neb for now yeah I think that makes sense um maybe we can we can make sure that you know when we launch the devet we don't start blob spamming from from the

beginning and maybe from few talks down the line depending upon uh what Epoch nus is comforable with then from that point on I guess everyone should be on board yeah I think I think that is uh yeah that can be like the most minimum uh workable way out yeah sort of yeah agreed cool but in general that would that would still make like that would still make our code base kind of non-

mergeable but yeah but okay like it it it should work enough for testing yes I mean yeah we should not basically worry about modability as of now because we know that Electra uh is basically quite big and it's changing and there are other few other things that are being pushed Tred to being pushed on Electro stable containers uh for cl so uh I I think we should not just worry about merging it into El of uh yet and just focus to get the P functionality working properly yeah okay seems okay to

me anything else BL to dead um if not um I it to talk about um but I think there are two main big spec changes coming um one is franchesco's um Fork choice and B the custody and the other one is pops um the couple um the couple subnet change um I'm not sure if Cent team has had a chance to look at it yet um but I feel like it would be it'll be great if we can have those two um spec changes finalize soon soon so we can

prepare yeah actually I have a question about validator custody um right now if uh node doesn't custody the good amount of colum so we we we can don't him for example if the eum node record announce I don't know four subnets let's say four columns and if the nod actually doesn't reply to um let's say request by root for the given columns we can don't score the node and at the end the node will be the pier will be ejected from the pier set um but with validator custody I'm not sure how we can ensure

that a node really um really set in its no record the good amount of cust colums for example if a node um had let's say 100 validator attached so normally he should custody all the columns and so the not should say on on its record he the N has 128 um custody subnets and if the not instead of that just announce its custody for subnets I think we don't have really a way to ensure the nodd isn't

lying and yeah and so we we cannot penal penalize the per in such a case I I don't know if you see what what I am saying or not and if yes if you have an idea of how to solve this this issue yeah I think I can wait saying um so you're saying that we can't really enforce the the validators to be honest about how many how many validator they have attached to the beta node exactly

yeah so um yeah I'm not sure if there's any way to enforce that but I guess I think we want the older client to be advertising the custody um sub that account based on the spec um but I don't know if there's a new way to enforce that anyone else have idea well I will write a comment on the

pro request we will see oh thanks bner anything else on spec changes yeah again I think it'll be good if if clients that hasn't look at the V it would be great to to have a quick look um because I think um there are quite significant changes um that we probably need to think about

soon um yeah um that's it for spec discussions um anyone else have anything to talk about I think everyone is still focused on on testing with ketosis right um is not having deant a blocker for anyone cool um guess it's fine with ptosis um I think there was one spe in

the last breakout call um from Alex they the want to uncouple The Blob limit block across C and um I think there's a there's a e created um for the for that change um it's been raised in the last AC acde I think I think the the outcome was that um client team should review it before um the next ACDC um just in case if anyone's not aware um any open I to discuss I guess it's pretty short one with no Dev issues great in that case I think we can

finish the call Early um yeah thanks everyone we'll see you in the next call in two weeks thanks thank you thank care bye thank you see you guys see you