PeerDAS Breakout #12
PeerDAS Breakout · 26 Nov 2024 · 35:47
PeerDAS Breakout #12, held on 26 November 2024. PeerDAS, or peer data availability sampling under EIP-7594, lets nodes check that blob data is available without downloading all of it. These breakout calls cover specs, client work and testing.
Topics
From PeerDAS Breakout, hosted by Ethereum Foundation.
Transcript
e hello
oh e e
I hope you have recovered well after death um welcome to the p d breakout room number 12 so let's start with the update anyone want to that yeah hi um yes so right now we have um the p d branch which is on top of the develop branch and devop bunch contains all the
Electra changes um however there is a lot of line of code something like 20K line of code to match and so what we are doing right now is to slowly create some small pull request from the P Branch to De Branch reviewed by people in the prism team which are not involved in F basically and so yeah we are slowly merging every change into the devop branch directly and um yeah and so what I want to test now is to run uh the to run p d uh on top of pectra I know we are not
going to do that uh in the devet but um before Running P on top of Fu I want to test it on Petra and when it's okay I will try to implement p on top of Fu um that's all for me thank you you mean full on top of pectra right sorry you meant the other way around yeah maybe maybe I mixed sorry maybe take yeah uh we are reing P to to both
Electra and we will be able to start everywhere in Electro full soft foring uh in the at the start of the fork or everywhere in the middle uh we will finish it uh at the end of this week I hope already testing already good that's all thank you and next liouse yeah so we have not started the Reas effort but it should be pretty
painless to the way we have architected it we are currently focused on a B6 release in Lighthouse but we will wrap this up this week and focus on this p uh F of now I think no substantial updates we have still pending refactoring sync to make it more resilient and I think some other uh backs and improvements from previous tests that's you and anyone from
lar anyone from Gran yes hello so hling from fellowship uh program he seems that um uh dat basing on the on the develop Branch uh I think it's uh at this moment likely it's not clear is it is is everything working all right but I think once we once we will have a uh test net it will be much more clear of that but yeah essentially a large portion of of um a repacing is done thank
you do I have anyone from nus today okay anyone else I me I guess uh be more productive you talk about death net first um and like f b could you give an update about to think with everyone
about the current plan yeah so the current plan is to launch the deut on top of Petra and not not to do another def with the previous spec because everyone is already working heavily on their base so I think it would be just applicated efforts to do another uh dment now so the plan is to have uh SP five PS uh finalized by end of this week hopefully we're going to be discussing this on Thursday on ACD call regarding 7742 then hopefully we can launch uh P 5 next week or maybe the week after that
and then we would probably want to have at least a week of uh stable finality before we can rebase on top of that spec uh all the PES changes and then we could activate uh PES as Fu or as uh yeah 7594 Fork version and Fork book it depends on the client implementation whichever is easier for them but you can just Define both of them and whoever wants to ignore Fu can ignore Fu and whoever wants to ignore thep uh 7594 can ignore that thank you Babas um does anyone have
concerned or question about this def kind I open PR okay um I guess the the TBD is so if we can launch picture as we expected um right then any other questions about definate otherwise we will jump to the spe discussion he cool
um any spec items we'd like to discuss today I saw on agenda that pop posted [Music] the network one yeah I I would like to ask for a last call in in this meeting like because like it has been open for a long time already so yeah uh is there any uh objection or or is any recommendation to postpone it or or if not uh I think like yeah we should mod now okay I think up yeah so so I think we
can watch it now right yeah uh I guess the maybe my question is uh We R includeed to the definite the incoming definite yeah for the deapo yeah one can maybe can the client give us some up about ready
r i mean right now we struggle to have a devet running with finality for more than one week um I'm not against this spec change but I think I would like to see before maning it and so before implementing it in the next devet so before implementing it I would like to to see at least one death net um running correctly for at least one week without losing finality and yeah that's why I think maybe it's not worth it to to merge it right away and to interrogate it for the
um for the next datet thank you Manu anyone as then or different opinion here and I saw Franchesco ask a question
about validator custody I would ask the same um before adding new stuff um a part of um you know running as Fu uh yes I think we we would like we would need to to to be as conservative as possible in order to be sure to have a finalizing devet at least once I mean I I tend to agree um just wonder
how how much change it would be for the kinds yeah any feedback on the deapo S one feels like
um no nice to have and like two weeks later is a is it a nice is a I mean do we have this bed with to include this um nice to have then think we could go but I mean at the moment for the speak uh I mean can we can the cting signal more about should we go or not
here I so I mean I think than PR signal it but how about other things what do you think about it uh I don't know we we spent a lot of time of Mer branches uh Master Electra andas in in the fork and I would like to end this soon but if I agree with you that current pect net is not yet stable and if we
uh add to this our not very stable peras it could be Ms so uh I think I could agree on both how about lighthouse uh either way it's fine for me how about Gran same I think it's it's okay both
for us if so I say that merch it okay thank you and the next item probably the one that justco posted in the chat about the
V it it's been a while anyone wants to give a overview of any concern or any support of this PR or it's just good to merge right now I would say the same thing than for the previous uh spec change I mean right now we didn't have any penalizing devet so I would like to before introducing new changes I would like to to see at least once finalet I'm not against if
every other client wants to to match this P request it's okay to me but I just feel it will introduce more an additional complexity and without this complexity we already struggle to have some something working right now so I mean depending on how many validators are what is the distribution of validators on nodes uh in a devet
then it should make it easier but on the other end you could just do the same thing by just having more Super nodes or more nodes that do more than the minimum custody so it doesn't really help in that sense um like maybe if anything it could even make it slightly less um flexible like maybe you know now you need to pay attention to the validator distribution to like figure out um yeah the distribution of like uh C requirements instead of just setting whatever you like so yeah I don't know I I can see an argument for just not doing this and and just more ad hoc just continuing to set a certain number of Super nodes um until
we we can get something that that works like I feel like this would be very helpful on meet I don't know how helpful it is on um yeah in in actually getting into work on dev Nets yeah that's fair um we could also I guess achieve the same thing by just doing a super node only Network maybe I'm wrong but if we do this validator cust on devet I guess all NES will become super nutes because basically every client every n has a lot of validator attached so if you do it yes every not will become super not by
default yeah if uh it's like I guess if uh I think 128 is is the number after which everyone node starts becoming a Super node so yeah I feel like maybe it's a reason not to merge it and and um yeah like it might actually make things harder on on dev Nets and less flexible I mean this PR does look like they are
more there's more design space for for things to think about um so probably not for the next definite but that's Target on the next next definely that Mak sense um I guess one question is even if we're not going to do this now we should eventually figure out if we do want to do it at all how do we um how do we deal with devet like we don't want to just test uh all super nodes so I mean I guess you can just sprinkle in some uh some nodes that have smaller numbers of
validators but yeah I guess so something like that would need to be done I think first we should have a happy case scenario where we do all super noes and see if we can even get that working and then move on to the next test it can be iterative as well so it doesn't need to be running for two weeks but at least we should have like I don't know five to 5 to 10 days of finalization with all super nodes and then we can move on to the next one yeah I really meant like eventually like if you eventually want to merge this and still be able to test it in like a somewhat realistic scenario but yeah in general I right now I agree I think we should just try to get something that
works with we do it all super nodes any feedback I I was just wondering was what be the
right timing or or process for merging these so is it like we have first a devet which is working with the current spec and and then we feel confident to merge these two for example like for me they seem to be things that we want to merge it's just not the right timing and I'm just wondering what's the how we see the process I think usually we just try to U minimize the number of variables so if the devet was already looking great then there would have been absolutely no objection to merge it but uh the main reason the there's hesitance is because we already are having a lot
of issues with status quo do we want to add more changes because that's not going to make things easier but yeah in in the happy case for example in Petra um the moment we have something working we tend to start introducing more edge cases more changes and so on okay thanks maybe a bit of another question another Direction but other changes outstanding PRS uh are something that we would need
to merge or specify better to make the devet more stable or is it more really making the implementation inter theate we had a discussion during the defon about Rec construction timing okay um right now yes I know at least prism and lios do the thing differently so bu if I'm not wrong reconstruct as soon as I have 50% of the column but Lighthouse Reed all the missing col immediately reason why from 3 second into the slot it's a arbitary value and unless I'm mistaken there is no spec
um about no specification about the timing of weed if we should randomize a little bit um the timing of Reed maybe it could help to have this timing specified yeah I think in in the specification at the moment is just saying that you can delay it if if you want basically uh uh was it identified as something creating issues or it's more of a fairness type of problem no I think there is I didn't uh don't any issue with that
um but just yes talking with different time team I realize that yeah everybody did things cently um maybe it's not an issue maybe it's okay yeah so it's it's also under different
scenarios which we are absolutely not trying now I suppose different strategies make more or less sense and having the diversity might actually help make the network more resilient so I'm I'm at the moment I'm not sure specifying some Behavior Uh delay C whatever would would make it better okay like it's so much inter so is the local resource decisions what's prioritized what's on a single thread what's on
multiple threats etc etc that yeah I'm just not sure what would be the optimal strategy under what conditions yeah I see I I understand e well
so I suppose we still have cion to the pr itself so just for the incoming release next week we will probably I mean suspend this and then if we can get it back on next defate okay for the S 3871
okay and do we have any other open discussion topic no like again other things we could help with
the thinking logic to be more smoothly any updates of the distributed black building after decom oh to oh got Cher is in the in the
chat uh do we have um a new proposal reading somewhere yeah uh so I think tomorrow uh we are going on Thursday we are going to decide whether we will include uh the change that I proposed in 7742 with regard to pushing the target to 4 as well as changing uh changing the computations for the base fee uh normaliz basically normalizing the excess gas as well as pushing the main base V uh 22 to the^ 25 uh so we'll discuss and take a call on this uh and decide whether we want
7742 with this change or or just uh include 7742 ases which basically means that the Target and Max doesn't change there is no actual computation change on El as well because the current computation is also with regard to uh with regard to three and six so uh so uh so that so nothing nothing really changes um and uh only engine API now provides uh uh provides the target as well as uh in the block production Max uh so that uh El can do the corresponding block
building thank you vender uh so I suppose we will make decision on Thursday and if you have people here have time can please VI the IP proposal anything else for today no
no okay um thank you for your attending have a nice day thank you byebye thank you thank you thanks bye thank you bye