PeerDAS Breakout #18

Transcript

e e e

up Francisco hey how's it going oh very well dude very well how about yourself uh good yeah [Music] tell me about it hey Paul hey how you going oh another peachy day in paradise excellent how's down under in Thailand yeah yeah my desk in my

house it feels weird to say in my apartment that's been so long that's cool I'm just kind of lurking here so I'm going to go mute yeah same e hey hello

everyone hi nice looks like a pretty good turnout um let's get started guy everyone um this is the P breakout

call um yeah it's um so we've moved to um like a rolling breakout call time so this week it's it's it's 10 10: a.m. UTC but next week we're going to be moving back to the usual um the usual time okay see if we have everyone now so so about this should we actually move next week back to this time and then like get on the right cycle because fossil uh is next week at three like somehow we moved the wrong week um all right so so maybe so so so you mean we keep the same time for next week and then and then and then flip yes yes

that's the week after yeah yeah it sounds good to me I um yeah I'll set that up cool okay great um I guess maybe we can start with some client updates and I can probably talk about lighthouse first um so with Lighthouse we've um mainly focused on refactoring this week and it's just fixing some sync issues that we've ran into on Deet 4 um we've also um implemented the fix to unsubscribe from The Blob topics at the fu Fork um and we had a syn issue where the sync doesn't start until like 5 minutes later um we have a fix for that and we are currently testing that fix um

and then um last breakout call we proposed to have a um COI flag to delay block and column publishing and um we've got an external contributor working on that and it's currently under review so we should have that um delay block publishing flag ready soon this week um and that's all for Li house um I will pass it to teu is TE here Demitri yeah here uh we had a back when we were requesting bobside cards from other not and some cases we found and fixed it uh we have improved data column side car cash uh but we are going to ROK

it and currently we finishing the construction it was not working and so we want to make it working so we could be able to pass for scenario that's all nice thank you Dimitri um prison yes hey uh so yeah during this week um um so yes we had a bug in prison because fu is the first um Fork where the Bon block and the state are the same than in the previous Fork which caused some issues with the prison uh so I work on that and now it's

solved uh Al we totally change the way we store um blobs in our database uh and so it impacted a lot also data column because we we store data column the same way we store blobs so basically now it work well um with um Kev still we we still we are still using C and not go and go has still a little worse uh worse performances compared to C and we are working with Kev on this topic and yeah we continue to work on

uh validator custody uh I wrote a little design document about how we want to implement validator custody and actually how we beg to implement validator custody in prism uh and yes that's uh pretty all uh loar uh got ourselves sinking everything is working although we're having an issue with GTH uh that I think Perry noted um when he restarted the rest of the clients and also there's issues on the devet so we've got our nose running uh in our clusters um at chains saafe

and everything's working correctly um went through a pretty big refactor this week just trying to make sure that the uh it's easier in order to uh find these bugs and then we started on the uh validator custody didn't make a ton of Headway uh but that'll be uh probably over the next two weeks we're going to start uh get that get that over the home nice thank you Matt um is Nimbus around do we have anyone from Nimbus um doesn't look like it um what gring yeah so uh for the last week we

have been uh find the back on our sying logic so we have been fix that issues basically it is the it's just a missing a single slot at the fork boundary so find it and we f it and and then we try uh we have been about to uh try to sing the our full note with the current running down net so it is a b to sing uh in the optimistic note but uh not for the super not and currently we we still have to uh refactor over sying loic yeah that's all from nice thank you thank helan

um and I guess we can move on to devet update um is Perry around yeah um I can devet update so Petra devet 6 um sorry p devet 4 basically launched with a version of um a fork of G however that Forks also continued to get some updates and we decided to pin like a certain um hash that has all of the commits we want but doesn't do anything on fulu um however it seems that when we're doing some syn testing there's one block that's still produced in Electra by the old Fork that isn't being able to import isn't able to be imported with with the

new one uh when we tried using the old commit for syncing that also wasn't working as expected uh rather than spending more time kind of debugging it because it feels like a oneoff that yeah just wouldn't happen usually uh um we thought it would be prudent to just reset the devet um so exact same specs exact same any everything it'll just be a brand new DEET and we can move on with sync testing uh we have not tried any other Els it could very well be if we just switch to another El it's fine um but we just want to kind of avoid time having to debug this if possible so mainly wanted to see if everyone's okay

with that so I wanted to add something Perry is that we're running uh two different versions of gu uh we're doing 1413 and uh and the P Das branch that was pulled six days ago uh does that seem like both should work and if so like do we just use 1413 have you does 1413 work for you it is like so we have two separate nodes on the P Das Branch connected to the devnet one of them is using 1413 and one of them using is using the the pure Das uh tag from seven days ago now uh and both are synced and having no

issues interesting okay the pias one definitely doesn't work for me so okay I can try spending a bit more time on it um and maybe try 1413 as well but if not then I would just bump up the debet number so this would be P DEET 5 but it's essentially the exact same thing and the main reason we wanted to bump up the numbers that there's no confusion about Genesis files and it's very easy to communicate and everything we wanted on podas Deet 5 just gets moved to DEET 6 um yeah I'll so I I'll give a shot to see if we can fix this one um and if it doesn't seem worth it then we'll just relaunch and let everyone know sounds good thanks

Perry any any uh questions on dev Nets then um we'll move on to actually um I think Manu had a comment on the agenda um the proposal for the deet reset um kind of briefly mentioned it in the PS testing Channel where we want to like test those scenarios man do you want to briefly talk about it yeah yeah so my proposal was to think um only three out of five ND per per cent um during um to start the devet with

three out of five NS per cent so in this case um it is not enough to finalize the network because we have only 60% of validators we wait for one days and one day after we start uh one out of five new clients uh it should finalize again and so with this uh test we are able to go from Den to Electra to Fu in unfinalized network and when it is okay we start with the remaining clients and in this case we are able to test dat to Electro to Fu in a finalized

Network um yeah that was my my proposal um I was just wondering do you think we want to test um all the scenarios on the on the on the de net or do we do we test on separate de net I mean um we already know that on this Cur devet pet 4 with full with only super n uh it works well I mean uh for the majority of clients we could for sure um restart the exactly exact same devet but I think it could be a good no good

occasion a good catch to to test thinking um with finalized and unfinalized network on this reboot of the devet 4 which is actually the devet 5 yeah I think the unfinalized stuff I would just move to a local network um it's relatively easy to do in curosis and I don't see any big value in having it publicly there mainly because uh I think it's very rare that we would ever see a fork transition with an unfinalized Network especially multiple Fork transitions um but it is worth testing so we would I would propose just doing that

locally okay yeah I see the point it's quite uncommon case but however testing in finalized network is common case I mean normally you you start to be you think with a checkpoint sync but I think it's still valuable to to try to think from Genesis yeah across the update I want to do in the next test net is the testing that's left over from last week uh essentially making sure the Genesis Works to begin a Genesis Inc Works to begin with checkpoint Sy Works to begin with as well as um making sure that we can uh have a network with lesser than 100% super nodes so all of these things are stuff that I would prioritize over non-f

finalized for transition test for example sure let makes sense great um yeah I note that down um so we so just to recap we want to prioritize um testing the scenarios the snc scenarios that we were planning to test in De net for um on the dev net and for now we will just test those um unfinalized testing scenarios on the local devet so we will move on to spec discussion does anyone have any spec um

questions to um that you want to raise so I've um I've added a comment to the agenda um so both both Manu and L um has shared some documents on on ver on related custody um design um there are some complexities um and challenge around um implementing this um nicely so I think both of both of the document kind of describe it pretty well um and try to simplifies it so it'd be good if if uh people can have a look at

it and and Al we can probably just continue the discussion in P testing Channel um unless anyone wants to talk about it here okay so if there's nothing to talk about for dat custody I guess people would just start implementing it and um another point that um I wanted to talk about um was the moving proof computation to transaction sender um change that we need to do to to to upload some computation um of the CL so I see that we've got some EO clients here so um I'm kind of keen to hear if there's any any um

discussion points or any questions that people have from Reading um the the proposal um I I I can speak for for best maybe so so in general we like the The Proposal it seems to be I mean we we have to we have to include the data availability samping to the El but considering the trade-off that we will be able to include many more blobs into a block I I think that's that's worth it um our main question is I I think and which is still open is what we are going to do with the

existing 4844 transactions um so if if if we are going to convert them in the node itself or if we are going to introduce a new transaction type so I mean that's that's a bit unclear for us but in general we we are in favor of the of the proposal I think there's some there's some discussion going on on how we want to handle this um and um it's on the on the ACD Channel um maybe if Franchesco if you want to like do like kind of ke to

hear your idea if you have any thoughts on this uh I mean I definitely don't think that I I'm uh any kind of authority here I think this very much like a question for for else to to figure out I I guess my what I don't quite understand is why we're talking about it as if um we should be introducing a different transaction type like it seems to me like transaction type really refers to the thing that you sign over and not to the network rapper and other than that I guess I mostly just I mean my personal feeling is let's um go towards the side of having the least um kind of like not supporting multiple things long term um like yes it's seems nice in principle to

um still let people submit whatever things in the same format that they're submitting now and converting them in the node um but also that means that like are we going to keep supporting both of these formats forever and that just seems a bit unnecessary to me like I'd rather just do this onetime transition which seems pretty straightforward from the perspective of blob submitters like how many blob submitters even is there maybe like 30 I I don't know there's really not that many entities and it's they're all kind of sophis at enti entities at the end of the day so it just it seems to me like it would be better to kind of go towards the side of protocol Simplicity and and and not having all of these formats to to support yeah thanks Franchesca um does

anyone from the EO teams want to want to talk about this if you guys have any thoughts on this I'm from NE mind subra here uh so from our point of view um it's like when we change uh the form of proofs uh it will not be compatible when when sending transaction between your clients so uh how we can do it one option is just a new transaction type but if we don't want new transaction type then we can just uh add support for um to when when we receive a block

transaction from other El by by uh peerto peer then uh let uh two forms to be accepted like one the current form and the other the the new one with cells and it doesn't require a hard for so we can do it at at any point and then uh we can if like the when we receive transaction from RPC endpoint then translate it from old format to the new one and send to other Els in this form but uh it it needs to be done in the same time so so having like accepting two forms for some period of time seems reasonable and uh after hard for when

when all the clients will be ready we can just drop support for old format on peer-to-peer ler and uh then like in El mul there transactions will be in in a new form and uh uh the only thing which we will be doing is to translate from old format to the new one when receiving transaction from RPC endpoint but I think it's like implementation details and it's doable nice thank you um so do you mean that

the RPC andong would support at both forms and but if the E receive an old um like a the 444 form then it will convert before it sent over to PTP so on the PTP there's only one form is that or or am I mistaken yes I think so because like if we want to have it in in in a new format like old format doesn't have sense anymore so we can have it in in new format and just when when sending from one e to to the other like between Piers it can be in a new format only so we will translated only once when receiving it from from our PC endp point

thank you thank you um anyone have any any other questions or concerns on this topic oh it seems like um it seems like this approach um um seems like agreed by by some people um I guess we can continue discuss continue the discussion on on the PRS once people create some spec change PR to it um is anyone from the e team is anyone from the e team able to

to start drafting the pr or like I'm not sure what the usual process is okay so I mean we can continue to to coordinate um async um trying trying to figure out like how how we can plan this work forward so because now we now like we're kind of have to work together with Theos and and cl's to make sure that uh we can ship P that so potentially um if we have a spec ready um in the next like before the next def defet launch

then um we'll be doing like like an interrupt with with all of the EO clients if possible I think one of the open questions that we weren't able to answer and I was hoping that Mario or someone would be able to is um is this something that goes in the execution spec because it's a transaction pool changed right is that something that's specified to begin with as far as I know the TX very weekly specified I I I I think that the first step in any case is to to open a PR no

to the existing EIP and then to present it at uh acde because I mean we we don't have all the the El teams here so we need to discuss first and also get their opinion uh regarding the implement okay see yes I'm not sure if it is uh in this spec but what we are doing right now when we receive blob transaction from an endpoint uh we are validating if uh uh commitment proof Etc are are fine so we require the number of proofs to be the same as number of verion hases Etc and

it so uh it will be changed with the new format for sure but I'm I I don't have the uh the knowledge if if this is in Spec or it was just coordinated between your clients like I I'm not the person who was reading it okay uh that sounds like uh PR to the EIP is the first step then we present it to ACD and then parall we can have a conversation a with the testing team on where best to add test for this and so on so Clan teams can implement it um small thing here um there is in

the document that Jimmy made there's also a link to a document that I wrote that's like basically meant to be what maybe the pr to the E would be to to the networking uh section um d lion mentioned that um he doesn't really like the nested uh list in the definition of cell proofs so I now replaced it with like a just all the cell proofs been uh listed I don't know if anyone has any opinions on that but yeah that seemed simplest so I just went to what that plent suggested also another question is when is the next AC is it uh I don't remember anymore is it uh next week or in two weeks um

because yeah or I mean yeah I guess which one is is the is the one on Thursday just because uh if we're going to wait until uh ACD to like yeah I don't know anyway sounds like it might be worth trying to coordinate a bit before then depending on when it is okay so it's just next week so I guess that that's fine yeah right um yeah so that sounds like a good Next Step um yeah

um so I guess um Franchesca you already have like most of the the changes um would you mind creting a PR against the IP uh yeah sure um if yeah I guess I can just do it and people can review there but if you have any comments before I the pr uh just let me know the as I said the doc is listed in Jimmy stock I've sh the link as well thanks yeah also I'm not sure if there's anything other than this like networking section that needs to be changed um that's what jumped out to me but yeah if you if you have thoughts on what else needs to go in the AIP let me know sounds good um yeah thank you Franchesco

um so so it seems like so I guess on the E side like what Perry just said um um PR2 thep would be a good first step and potentially on the on this consensus spec side do we want to do it in parallel or are we um people like to wait for the EIP to be finalized first before we continue I guess the co changes a b a bit more straightforward um it's probably something that we can potentially do in parallel any any thoughts on this I've got thumbs up um okay maybe

we'll just continue the discussion offline um on this one but it's seems like um yeah we've got some some input from E which is great um yeah yeah thanks for the E de for joining um it's really helpful um yeah we'll continue working on that so next item on agenda um actually I think Paul just left a new comment um is there something they want to discuss now or just a comment to the previous comment it was more just a comment on lions acmd um I really don't know enough about the enr to know the answer to my question but I was just wondering if we're not

backfilling maybe we can do something to say the period of time that we have the data availability so that you've got kind of a middle ground between you know lion proposition is saying we have no history for 18 days some sort of middle Day Middle Ground where we actually have to find that yeah uh any anyone have any thoughts on this so um so so in the current spec um the last change was that we we would like once the cgc is updated a client must do backfill and until the backfill

is completed um the the client may choose to update the cgc in the enr so they can choose to update early or update until the the back is completed and what um Lion's proposal was that we just don't do backf at all and then after 18 days we we update the cgc in the enr and and Paul Paul saying is there any Middle Ground um to to say that um we um that we have a date that we have a time that that we we started um syncing with the new cgc so people can start using our end points to to um to cery columns is that is that what you

mean yeah that's kind of the gist of what I was thinking just some sort of way of saying yeah I'm not a supern yet like I don't have all of that history but say I could provide the last five days there's still value in that to the network Crow if we needed to sync things that was my theory anyway in might silly thing line might say that's dumb but we see what happens um other question um does that mean the node will have to advertise to cgc because they've got one cgc that they currently serve and the new cgc um and then and then the time when the new CG cgc becomes

effective it's a very naive question so I really can't answer it it's just an idea sorry no worri any any thoughts on this okay thanks for bringing this up for um I think it seems like like we just need to dig a bit deeper to see if there's any any more ways to simplify this so like I think what what and and um Lion's been trying to do like both attempting to um to to simplify

things um and both look pretty good so maybe we can just dig a bit deeper and see um if there's any particular approach want to do or or if it needs to be speced out at the moment doesn't seem like either of those are breaking the spec okay cool um so any any open questions okay sorry I'm just reading through the comments in chat now for the devet considering the issues

with um gath are there other Els that are ready maybe we could start testing with them what is it you specifically want to test with the El just turn on mix them client diversity I mean we can but I would prefer not to uh not right now at least because in the future we're going to be um merging either pias as well as eof and at that point it would make sense to test it but right now I would prefer focusing on like P bugs and getting them out of the way as much as possible oh that makes

sense yeah I think likely in the next DEET or whenever we have to um move transaction proof computation thing um ready we'll need all the EO deps and the EO clients anyway thank for thumb up thumbs up any any other comments discussion points looks like we're going to have a relatively short one

today which is good given that we're doing this weekly now okay great thanks thanks everyone um I guess we can call it um and just to re just to uh remind everyone um the next call will be the same time on Tuesday um I'll just create a new agenda that reflects this um and that's all thank you everyone for joining the call than care bye thank you by bye