PeerDAS Breakout #23

Transcript

so okay great okay um I'm G to try sharing my screen I believe it should be sharing um and we can kind of uh run the meeting from this agenda just so we don't miss any of these uh these details but yeah uh basic overview will be client updates and then devet testing updates back discussions and updates and then open discussion um so is Manu on maybe we want to kick us off with the prism team update yeah hello hi everyone um yes so during this week I

continue to work a little bit on the redesign of the database um so it is currently running on peret 5 but the one running is not fully optimized so I work on some optimization uh I also continue to work on unit test this week and uh I start to work on the back field for data columns uh because right now we are able to Back Field blobs and blobs blocks and blob not data columns and also I'll give you some um requests from Bas team Francis and Nan about get blow V2 get P V5 um and all

the specification modification [Music] um yeah it was mainly that during uh week excellent thanks uh I don't know if Jimmy's on here is there a another Lighthouse team member that wants to do that update not I I flag I don't know there was discussion about a new Branch I believe that they're working on um I just dropped that there and teu yeah no significant progress on this

week we were working on distributed blob publishing uh but the changes in the spec uh now uh could could push reconstruction just from the data column side car we don't need to wait for Block anymore and this required uh some refactoring from our site and uh we are working on it that's all that's great uh on the load star side uh We've uh started implementing validator custody uh guys are doing great um spinning up uh uh spitting up that work uh still going through unit

testing and uh uh but so far refactor looks good as well um we are not doing the back filling just yet this week we're just doing the uh custody uh uh basically um changing the the groups that are custody and then we'll probably start on uh back filling I would guess maybe next week excellent um nimbus yeah uh so this week um I was working on an improvement uh using get blobs V1 my initial idea was to uh

bypass gossip validation if there's a 100% hit rate but uh in times when like I was I was testing with uh Sunnyside Labs uh if we have a high block count and basically there is partial responses from Els then it kind of weirdly doesn't apply that block anymore it was a bit buggy so right now we have some performance improvements uh with which we can basically race both go blob gossip validation and get blobs V1 with retries such that

whoever gets all of the blobs can apply apply that process can apply the block so uh with that I think uh I tested it with sunyside and we were in we were testing on Petra and it kind of was working with around 30ish blobs um I think there are better better improvements that we can come up with in the next couple of weeks um I was working on the column Sinker as well uh that I had talked about like in the last couple of weeks um what it does is it uh improves the peer pool a lot

so what it would effectively do is it would find intersecting column custody and populate these peers into buckets uh it would also of course uh work on better scoring if there is intersecting columns and even better scoring if it's a super no um I tested it today in the morning with nimbers get one uh in pios devet 5 it had been down since Friday uh so ners get one syned pretty pretty fast like at least to my eye and but like but we don't really have a concrete column sync speed uh like kind of inferred from that

test yet so I'm working on some better logging uh so that I can get some good metrics and like I can kind of infer what kind of column sync speed it's uh actually giving me uh moreover it doesn't really do pure filtering at all uh it keeps requesting columns until I hit reconstructability and I reconstruct and then I persist whatever columns I need so it kind of saves a good decent amount of time in pure filtering um this independent column Sinker would

actually also work along with um the backfilling cases of validator custody so that problem is more or less towards the end of being solved for us apart from that there is some pending work to finish validator custody and there is uh quite a lot of work on get blobs V2 which I haven't done a lot so that's my focus for this week and this is pretty much my update for this week great thank you um grandine I don't believe is able to get on the call but I added their update here that they dropped into the

Discord um gu team I think I saw Felix earlier maybe Marius I don't know if Felix is here I'm here um so uh we um I updated the the branch that they had for um so that the node doesn't uh calculate the um the sell proofs on every block uh but uh we calculate the sell proofs whenever we get a transaction from the uh from the uh from the transaction uh from the RPC

or via the network um but we don't have the uh Network changes yet um yeah uh I don't know um it seems like um sorry uh uh Francis from uh base uh also implemented basically the same thing that I did and um yeah I have to I don't know if he's if if he's on but if he's on we should probably discuss uh whether we want to uh combine our

efforts um yeah uh otherwise the the networking stuff I will tackle at some point that's it um yeah hi this is Francis U I think we definitely should like think a little bit uh to combine the efforts what I implemented is basically like directly using sell proofs instead of like any kind of like computation and the things I haven't done is kind of like the same as you like I haven't changed the like Network rapper yet and the go is to hopefully get one EO client guess uh to be ready for integration so that we can test like end to end changes so yeah

let's think maybe after this great thanks there was a note from par in the chat about SEAL Teams moving to prioritize get blobs V2 over validator custody just so that everyone sees that um NE mind uh flcl um yep hello uh so we have a branch with um uh API according to the draft uh implemented according to the draft uh and uh uh as

far as I uh see uh according to the latest changes we also handling uh TX pool uh new proof propagation I mean uh what else uh it's uh uh still of proof of concept quality uh in some places and for today today for example we found an issue uh we will use uh this CIS setup provid it to test it more but uh like our aim was to implement everything needed for OA and U

uh provide of to be integrated in to be used in End to End scenarios uh cases test cases yeah that's it I put um my best attempt at summarizing there was a side chat my morning that I SE side eror I think it was related to some integration testing that Barnabas started with uh the nethermind implementation I don't know any of this should be discussed but like to hear yeah thanks for the notes uh we Fe it and I guess more notes will appear

later okay Roman rest update uh yeah so last week we did not prioritize uh but this week we'll be working on it so the update stays the same it's one two days of work but uh yeah this week we should be able to complete great and I don't know is there anyone from Aragon on the call okay uh devet testing um sry

Barnabas um I put a link to the new devet 6 specs here that we worked on I flagged the one open question that you had on that sheet um and then there's also some updates I don't know if this relates to the steel team that I got uh in a side chat uh I don't think we have any definite updates for de five right now okay yeah and for def 6 I think we are still waiting for Cent to begin and work on implementation once we have like maybe two or three client implementations then we can start rolling out ad D slowly and maybe you

can make some deposits later or shift around some validators but yeah we can we can launch it maybe once we have two on each side two two CL because there's no real point of doing that before that in my opinion okay uh and then Dan or Felix uh I don't know Mario's on the call uh I try to summarize the update that you provided me uh from the steel side of things here if you want to do any voice over um yeah sure thanks will um so basically I don't have much more to say

than than written in the agenda uh basically I think Mario spoke to uh Alex and understood that basically the L changes limited to like of the network rapper and because like eels the like this the reference spec implementation in Python doesn't touch this layer we can't really like it's not really testable for us using the consensus tests that the East generates but how we can test it is via Hive um Hive engine simulator and we'll start light adding test there um but we haven't started working on this yet so we don't really have any estimate of how long that'll take I'm sorry about that

um if if Marius is still in the call it would be awesome if you could read this update and uh tell me if he agrees with it just to see if we're on the right track thanks uh where did you put this update this is just it's in the agenda issue from will okay I will read it thanks uh I think mini or Tam uh from the sunic side

team yeah he guys uh thank you will for the summary so this week we were testing on the individual client Dev Nets so like we were running 50 notes of Lighthouse get pairs like 50 notes of teu prism load star grandine and we uh notice I think we I identified how much blobs we can currently support with the pi Das and mostly get Blob V1 spec so uh one of the thing that we noticed in the test was how the declining G blop hit rate uh affected the theps column reconstruction work and like Network networking so we were

seeing uh get blobs hit rate probably correlating with uh the nodes unable to you know build blocks in time so we have those discussions ongoing in Discord uh so uh in the coming week we are going to focus on running another suit ofet devet test and it's going to be we are trying to decouple get from these findings so we first want to run the same test with another executioner client and and see like how the different implementation in regards to like BL get blops affect P's throughput and we also are going to run a defet without a

get Blob but with PS so we want to see how much uh blops just with PS can support so that's it that is something that we're going to do in the coming week and then uh we were uh when we were analyzing the results from the devet we noticed that uh there are like differences in the metric systems in the different clients and I know that uh uh there is effort to standardize metrics in the different clients for the PRS metrics and I was wondering uh maybe if there's anything that we can help with

uh we would be glad to help like implementing like metrics in other clients that are not currently worked on right so that is something that we can do that's great thanks for the offer um I I don't know if any of the client teams or researchers have any questions or want to discuss anything about findings from this past week or the strategy for next week if not what's the Discord Channel you mentioned mini uh we are mostly talking in the p as test Channel okay thanks um I I don't know when when I

when I looked at these results I was kind of shocked how bad it was performing even with get blocks so uh as I already wrote in the chat I think we should be very careful not to make any decisions based on G blocks because in my opinion G blocks is just an optimization that we have um but the network like the safe parameter should be chosen without having uh G blocks because we cannot in in in the case of an attack where someone uh I don't know bribes the the big block producers to only include their trans their their blob transactions then no one will have the

blobs so uh de line hey I join a bit late I can give the lighthouse update if you guys want oh yeah that'd be great yeah so we we merge up here for Valor custody it's not complete yet but we are progressing we fix adding issue that was causing the Val client to crash which had some issues with our testing then we updated the offload kcg proof

computation PR to the latest spending spec and Jimmy has a PR which I think it's fully implemented but not merch yet but we are pretty close and then we have a bunch of syn fixes that we also mentioned last time uh that we have an merg yet and that should fix the the fly note on the uh but it's a bit complicated and it's going to take a bit of time and all things we have pending is at the max blops for Block Fu config parameter and also we have a flag to advertise a false cgc so we can do more complex attacks

testing and that's it great thanks um back to the testing I saw some uh I don't know par if there's anything about the discussion I think you dropped uh regarding gossiping and V2 V3 is that around G blobs V2 V3 uh yeah so maybe we can start with the first one um I think there's a bit of confusion around the transaction types maybe we can first address that topic and then we can switch to the get

blob's discussion okay um I think we're a bit confused what the difference is between Type three transactions version it feels like there are three versions or two versions um I can I can take on that a little bit so there should be only two versions they should Al Al always be like type three blob blob transaction type version zero to be with block proofs and version one to be with sale proofs the version two was previously proposed as the new version and we will previously we treat version one as the old version and version two

as the new version and have after some discussion basically changed from vers version zero as the old version and version one as the new version so that so so that's kind of like maybe why we see like zero one and two but hopefully you going forward we only have like zero and one as versions okay so it's basically a sub version we have the existing version zero and we have version one which is blobs with proofs by the transaction Center yes okay and is the idea that the RPC accepts both versions and irrespective of which version is sent that the node converts it before gossiping by RPC what do we mean I

thought the version was the execution layer not RPC is that used for P2P or is that used for get blobs no this is for submitting The Blob so let's say I submit the blob as I do today so version zero what happens in the RPC um it's un specified it's it it depends on on how you want to do it in your in your implementation like it's it's not it's not specified also uh it's not specified if you have a if you already have an existing blob uh transaction in your transaction pool whether you want to uh

just drop it or whether you want to create the sell proof for it that I think purely depends on on what what the client teams want to do plan that implemented sorry go ahead um I have a kind of like suggestion for that which is I think we should just draw up the old transactions uh and do not do conversion on the client side like even delayed conversion like when you are building the blocks um the reason being that we want basically all the block transactions to have sale proofs as fast as possible so that when the SEO kind of like tries to get it

through get blobs or like some other means they can get it like immed mediately without any potential delay that's caused by conversion or some otherwise so that we can basically unblock the block building critical path to be as fast as possible and uh dropping it seems to be the easiest in terms of implementation and also like on like like generally improving the speed so yeah okay so then we would need to specify that after the fork um only type one blobs blob transactions exist in any Meo as well as any PTP networking layer uh yeah kind of uh it in indeed

may depend on implementation and just uh uh some notes will not um um agree to receive CE old proof types when it will be passed through Network just will decline or not accept it and ignore it or they may uh try to convert it into new BL type it it is clearly not a consensus uh uh question so yeah but I think we just need to know for uh testing because otherwise we're test we're comparing Apple Store enges and it would be good to know that we know what strategies client teams are

using at least uh it's indeed may cause issues on testing because uh if you send uh old and new transactions from the same account maybe uh some pools will U be locked uh if all transactions will not be evicted but still uh yeah so it's a good um thing to test to send both types uh before after Fork during the fork okay um yeah so we still miss some tooling for doing type one and we'll

work on that and how to specify if the sender should be using typ Z Ty and on the meantime it would help if El teams then drop a message on Pras testing as to what your strategy is so do you convert when you receive it in the RPC what happens at the fork what's in your M Pool uh I thought we agreed on on the last call like to leave the conversion logic to the ALS and not not like specify we just want to know what you're doing as in okay write down what doing so we don't have to read your Cod okay

uh I think it would make sense if like if everybody's moving first right now it would make sense for everybody just to drop all BLS I think like answer suggested and and then maybe later on we'll come up with some strategy what to do at the fork boundary yeah that makes sense uh par do you want to T up the get blobs conversation the second part of this uh yes sure um so the question from ancar was um are we doing Deets without get blobs at all and purely because we need to be sure that the network is

stable even if the um get blobs V1 or V2 um is not working as expected and I think the followup comment I had there is I think even 4844 has gotten a lot more stable once we've gotten get lobs um so I'm not even sure if minet without get blobs can support too many more blobs but I agree I don't have exact data I remember there was some initial ones um based on cryptographic libraries um maybe ancar car and then Francesco yeah I just wanted to say I I do think it's kind of important because the kind of these Explorations are

supposed to set to give us the targets that we that we go for for fusaka so I do think it's important that we only choose targets that are at least I would call it like semi stable without get blops meaning that there's some tradeoffs we can do right so if if weak nodes are usually like too late on a testing for these blocks that's in principle fine because they still end up rejoining they they will still get the blobs just a little bit later so as long as overall the blops are still reliably accepted by the chain that would in principle be fine so um I I I think we can make some compromises or for example run these death Nets with somewhat higher bandwidth um assumptions and these kind of things um but it can't be completely breaking right like we can't

we can't we could not Che any throughput numbers where without get get get blobs just blobs just usually don't drive on time Franchesco uh yeah so something I first wanted to ask when you say um that things are not working without get blobs um What scenario exactly I mean I guess two questions one is like uh is this based on the the devet from the sence side people or something else uh and also like um I think there's a difference in things not working based on who is the proposer like if uh things don't work when you don't have G blobs and the proposer is someone with very

low bandwidth I think that's kind of fine like I think that's part partially a lot of the point of get blobs is to allow people with uh lower upload bandwidth to still be able to propose possibly at higher block counts if things don't work when you have someone with gigabit then like yeah that's really not fine so I think we should differentiate between maybe these like three cases like having get blobs or like four cases like get blobs no get blobs and also who is the proposer like how much bandwidth they have and yeah we like we should carry about different cases differently yeah um I think my point to get blobs itself was um based on 4844 before and after on Main net data um client teams did notice significant

better significantly better performance around October November once they started rolling out get blops um seems to have reduced realog rate reduced um like helped on a lot of levels so I think that was mostly the basis for that and having get blobs was also part of the decision making process for um increasing the blob number cuz the network is stable overall in general um but in yeah I I agree with you that I think we do need to have numbers for all three so we probably need a way to disable get blobs and choose if a client uses get blobs V1 or get blobs V2 and I don't think we have that ability right

now besides using like an older version of a client yeah I I think it's not even just a question of like being able to do this is not just a question of like uh do we need G lops to have certain throughput or not but would just like we're probably likely to not be able to figure out that there's some uh maybe low anging fruits on the cell like uh to implement like propagation and so on or or just like issues um if we can't actually observe like by itself how does that work like if you know we kind of just rely on G lobs um in in all of the devat and we we can't really figure out what's actually going on on the on the CL propagation path sorry Stokes and then

Saba yeah this might be a tangent but why would a client use get Bobs B1 if they have get Bobs B2 uh who's that for who's the question for whoever can answer yeah at we just decided not to use get Blob B2 at all for p we did not implement it and we are going to use directly get Blob V2 yeah I think so the answer would be no one would really use V1 once V2 is live on minute okay

gotcha BTO from Nimbus in the chat um SAA yeah Fran go said it m already mainly but uh so it's get we are really sueding the data uh and it really important to test TW out that to see what the CL can do uh so I think that that's very important for for the learning um not not because we want to maybe tune based on that but that that was allows teams to uh to fix the others in the C Fusion uh so I think I I would do it at least for that and then tuning the numbers is another question Francis did you have something add um

yes um I think I agree that it would be great to test like purely the like diffusion of the the data ETA but it seems to me that or at least from my experience working on prism like get blobs is a little bit like baking um right now and maybe like with get V2 as well do we want to spend oh what I'm my my question is do I want to prioritize this or do we want to say maybe let's get get blobs B2 and then the whole thing work better first and then when we have time and then we prioritize maybe um finding a way to get to kind of like disable get Blob and test the fa Lal diffusion yeah I think it makes sense to

first get get blums V2 working on our clients cuz I think we're not there yet um but yeah agreed first we should get get blobs V2 working and then keep all of the analysis steps in mind sa yeah one thing I want to add is that uh so get blops should start working less and less as we are inclusing the the prop count uh so I mean just because of that uh at least until we have sell messaging so just because of that I would I would test without it so to make sure that you know we are not relying on something that then then hits back EAS hits back easily when we have increased prop

count Franchesca yeah just want to like push back a little just I do think that it is um we're kind of getting to a point where like it really would be nice to to be able to know like what can the C handle like what what's like a blob through that just based on on on the cell propagation path you can actually handle I I I not seeing you know now aband all the get blobs work and uh go and like find a way to to disable it but I do think that it's not something that we can like uh just you know push off forever like I I think it's there's somewhat of an urgency to to having a better idea of how that work

Anar yeah I just wanted to agree with what Franchesco said but also specifically clarify right like if we to the extent that we do run Dev Nets without get blobs the important thing is that we don't actually want to test the bottleneck of the proposer so it's basically important that these Dev Nets are set up where the proposal have at least in in first pass approximation infinite bandwidth so at least a gigabit ideally even above that so that we really are certain that we are not specifically testing that that bottleneck because we have other mitigations in place for those bottlenecks on the life Network so so yeah I think that would be important that these devet specifically focus on just just figing out the propagation after the first HP um so let's if there's anything else uh

feel free to jump in right now or we'll move on to uh conclude the back half of the agenda um Alex I believe that you added the top two things in the comments to the agenda uh comment open comment on the EIP and then a consensus spec yeah so I think we've touched on them let me go see what we need to still talk about uh sorry one second I lost the agenda item that I had um okay hang on um

right I mean I guess one okay so the first one I would just like to merch as PR um I think the one last comment that you linked here was around this vzero behavior that there was a comment there I think Franchesco said he took that out already and as long as we're okay with that then yeah I would like the last call um and what I really mean here is can we merge this after this call I think it's good enough for now but I wonder if there are any final comments great uh Franchesca you had your hand up I don't know if that was from previous conversation or this uh no previous sorry oh no

s okay um and then Francis if you want to provide an update I've got all of your open PRS related to sell prooof competition I don't know if this is um if your best yeah yeah so for as long as we are okay with the EIP and that is merged I believe um all the PRS here can be merged as well the only caveat here is that on the Bon API side I added something related to the get BR side car API uh to to indicate that okay after the fork you can we can keep this API

but you clients can choose to return block proofs uh or no proofs um by their like own choice and so that's kind of the main thing we can take it out if we think that there's still something to debate there but other than that all the other parts I believe are already hashed out so yes if we are going to like merge the eips we love to make a fast followup to mer the three apis that is kind of like related to the as well okay great uh Dan there is just an open EIP here

um that's related to testing I believe this is just a tracking issue um so we can move beyond that unless you want to flag it uh and then Manu this is I believe what you added just recently maybe late last night related to API yeah um yeah so the idea of this this one is um when um when a validator want to propose a block um so he has to he call Produce block V3 uh from the Bon node and Bon node just sends the block so K proof and the

blobs um the validator client sign the block and return the sign block so C CG proof and the blobs um directly to the beon node and then the beon node can publish a block and the side cures on the network the fact is the validator Cent does not do anything with the proofs and the blobs and um actually it's very convenient to have blobs and and proof in this end points because after when the because node want to propose a block it has all the needed information in the in the payload however um I did some small computation uh for 48 blobs uh with an one gab bits

per second connection so back and forth um time uh to to transmit the blobs are about 100 milliseconds um yeah we can say it's not an issue right now even with eight 48 blobs but maybe with 90 six blobs it will be 200 milliseconds and and so on actually the the duration needed to transmit the data between the validator CL and the b no is proportional with The Blob count and so this full request just this issue just proposed to remove the the proofs and the blobs from the the payload of of beon API request with some

cons and the con the main con is we we switch from a stat less uh beon API to a stateful beon API um yeah that's it great thanks um I don't know if there's any comments on that if not I do want to go back and double click on the uh sorry3 first one yeah um yeah like I think gender was here and you or wait gender or d lion uh yeah this comment here um there was this

extension about having the zero value be a valid bite that then treats the rapper with the version bite as a 4 for four style transaction can we just drop this for now yeah no problem for me okay thank you yeah for what it's worth I I removed it already so if you want the question is if we want to add it back in but no let's just leave it like it is for now um I think we need an EIP Editor to merge this in but I will P one after the call great um there were two other draft

spec PRS um gotta we talked about this last week I'm just going to kind of carry it on the agenda feel free to let us know if there's anything timely that you want to discuss with it uh and then the other one was oh yeah this is I don't know Dan if you have visibility on this I believe um oh this is just noting picking up some post progue refactors I didn't know if that should be glommed into puros or not but I will remove he will sorry you

you were referring to the execution specs PR yes I I don't think that's very relevant to be honest okay great I'll remove it then uh kachcha yeah hi one uh I'm just happy that metrics are um definitely needed now and uh I think we need uh we have a beacon metrix repo so probably we need the same for E clients um yeah Perry is here right so probably to initiate another one yeah I can create one but I think e metric are bit more wild than even

ones uh but yeah we can at least give it a try yeah so yeah so probably we will update it for p d as well and I would like to collab with this sunny sunyside team because they will actively use it so yeah just tell me in the Discord please thank you yeah I can you once the repository is created yeah with this new metrics uh for G blobs um I will probably follow one of the teams um I don't know like plot star or te who is going to deliver SE soon so we can check thank

you uh and then lastly Justin um I saw you note this in the Discord yesterday uh didn't know if I'm just going to flag it here but uh you've got a schedule release for later this week uh we've actually already made it we decided to do it yesterday I Just sh a link in the chat excellent uh and then Stokes I clipped your table in here from the hackmd That You released last week uh your proposal for a BPO blob schedule if this is seem to be one of the discussion items if you want to te it up at all

sure yeah um so I think the document is linked there where it says here but essentially the idea is just what um is here in this table so uh it's just a concrete proposal for something you know that roughly looks like this BP idea and it would be like a concrete suggestion for how we think about scaling blobs in faka so yeah high level the idea is I believe it's EIP 79 82 uh from E dreamer and it's just um a configuration you say for example this you know Epoch or slot uh The Blob should look like this both Max Target

and then also the the fee parameter but that's um yeah not here in this table either way uh the proposal would be say okay we have faka at the current blot parameter counts uh you give two weeks for like an observation period period um just to make sure that like the periodos mechanism works well at the current blob Counts from there you then aim to double the blob counts every two months until we get to the theoretical Max of puros and yeah mainly I put this together just to open this discussion it'd be good to have people think about this and you know if we could agree to this as the thing we want to do for Saka that'd be great um getting an agreement

on the strategy over the next few months I think really viable and I guess the other obvious thing is just simply that yeah you know if we go to like uh future pios Dev Nets or even as we get to like Fu Deets you know we might see that we need to adjust these numbers uh you could both parze the increase here and also the timing of the steps um but yeah so I think that's the the sufficient context for now and yeah I mean I'd be curious for any feedback if anyone has any um there's different ways to think about this you could have like this this exact schedule is like pretty blocky it's like piecewise linear you could imagine that

we have a more continuous function and there's trade-offs to either strategy but yeah for now I think the ask is just to take a look at this think about it and it would be nice to have some kind of consensus over the next few months on what we actually want to do uh Tony yeah maybe just to add to this CP it would be nice if we can directly use it to automate The Blob base fee update fraction because currently the AAP is just using dummy values and if we say we are fine with the target be being two3 of the max then we can yeah have a very

simple formula um I posted it in a comment to Stokes um to Stokes comment and yeah this could be done in one go and also the other EIP um 7691 with the blob increase also defined the blob Bas V update fraction so we might just stick to that uh Agnes was there anything that you wanted to note on this I saw there's some that in the comments um just a men um in Nimbus every Fork is uh it behaves like a like a strong type and and

everything like all of the functionality is kind of encircled around that if you are raising blob count then uh the the most like the best solution that would ADH here to our architecture currently is don't change the fork name uh if if that can be done then uh it's very limited changes for us but like with every block count increase if the BPF for name changes uh then I I think we we would have some problems yeah I got to say that that's

the whole point of the BPO Forks in Lighthouse again it's B expensive to write the new for name we need to do like 200 of bullet plate so yeah the idea would be to not have a different name yeah in that case it's fine it's okay for us because yeah because of the same issues great and then if we're ready to move on from that uh Francis I added your the summary on the beacon API get Blob sidecar discussion here if you wanted to speak to that if there's areas where you need

direction um okay u i I'll quickly touch on the previous one a little bit so I like I think like at least from Bas side we are like very very like supportive like super supportive with this like proposal and one thing we'd like to hatch it out um maybe a little bit further with you guys is that what kind of like scenarios or what kind of like metrix information that we want to see to basically approve or like revert the schedule changes and if we get that kind of like really nailed down that would be great so that we have Clarity on uh like like how how we're going to proceed and um please work with us and

Sun labs and all the folks to see okay uh so that we can produce those like repetitive or like automated like testing or like M sking uh stuff so that you guys all we all can use and like gu Z like next increases so yeah that's that's on the B schedule one and uh for the second one it's I think it's a small change basically like after um flu or after like the like suaka like hard workk uh on the S side we don't store blobs directly anymore Like We Only Store data columns and from the client perspective mostly l2s we only care about blobs so the idea is that uh basically to propose

that we keep the old get Blob side car API and uh Clos Implement a little bit of the conversion or reconstruction logic uh based on if they have the enough columns or not and they only reconstruct the blobs but not the proofs just to like save the computation time and like um CPU whatever and um when they pass things back we don't change any of the existing schemas uh when they pass this back they can choose to um pass back zero values for the block proof or they can choose to pass any kind of like fake block proofs and on the client side we treat the API as pred

so that we don't verify the blow proofs and directly use it so that we can minimize the amount of changes on the C side but also keep the kind of like relatively simple and um API for like external clients without worrying about like underlying data columns etc etc great um and then just I guess trying to make sure that we have rough consensus on this BPO blob schedule um before moving on this is seems like an important one any descent on that um one thing I wanted to bring up was

the topic of how that would look like um so we would have I posted a message there let say you'd have Max blobs per block P1 and then Max blobs per block P2 um this would have an Associated activation Epoch um but the question is if we're not doing it that way um because a said it might be problematic then how does that look why is it problematic I'm not sure yeah I mean I feel like he said in the chat it might be okay um so as long as we are under the

same Fork version I think we should be fine because our Fork version are strong types and U everything is kind of in like sort of overloaded to that strong type let's say beacon state or like almost everything uh within the code base so yeah so it like I mean if you if you raise the blog count and it behaves like a hard for kind of that that is a problem but yeah I get do the idea yeah yeah the idea is that it doesn't right so your client would read this config and and you would just need like the

only real complication I see is if you use max blobs as some like typed parameter uh like a compile time thing that is harder to change this issue has come up in previous context with other features and I think clients have found workarounds or just different ways to structure it so the only real thing we just be moving you know if this is say like a compile time constant is just not a dynamic thing and then it is just fusaka there's one fork then you just have this config that says okay at Epoch X you know the blobs are this at Epoch y the blobs are that and then you just proceed as usual like the whole idea here was to

get away from having clients to make new formal hard Forks let's call it right okay so in that case I think I think yeah I also just change what the parameter can be called I mean it can be BPO Epoch doesn't have to have the word for it and that would also work on the um Elite cuz they have a blob schedule either ways all right um looks like we're at time was there anything that anyone wanted to highlight feel like you're not getting closure or consensus on

if not I promis to get the zoom invite fixed for uh next call apologies for again great Kev I see your note about zkg I'll make sure that we discuss it in the next call thanks all thank you bye everyone thanks all by every thanks