PeerDAS Breakout #25

Transcript

Okay. Um, let's get started. So, call number 25. DevNet 6 is live, which is very cool. Um, Lighthouse, is anyone on from the Lighthouse team? If not, maybe Manny, you want to kick us off with uh Prism updates? Yeah, sure. Hi. Um, so during uh the last week uh I continue to work on the data columns verification pipeline.

Normally it should work the issues about uh verification we have on pur devetis. For example, we have some long verification compation time. We have some issue with nether 9 and some other issue which should be fixed with this put request. Um also currently on pure devetis uh we have a hack like uh we don't really use bundle v2 we use blobs bundle v1 stro with uh um extended maximum ss size which is kind of hack quite dirty

and work on something to to use bundle v2 to struct in a clean way and also I worked on uh the back field which is not yet done more complicated than expected. That's all for prism this week. Thank you. Uh Dimmitri on or anyone from the teu team? Uh yeah uh we are not a part of the net. I'm here uh t uh we are not a part of devet 6 uh but we were working on distributed uh cell proofs uh

this week uh it is done just final steps last is under review already testing it works fine tech with teo but have not tested yet with other clients looking to merge it today and maybe trying to join the net 6 if it's possible uh with this we are fully compliant and uh with DNET 6 spec and also we have started process of transferring peras feature branch code base uh to the tech master. It will take two months. So run this. We will validate the code, modify it if it's not suitable for production. Uh improve test coverage and uh get rid of the pas

feature branch in the end. That's all for us. Great. Thanks, Demetri. Uh Agnes Dustin, someone from the Nimbus team. Yeah. So uh saw a couple of issues in devet 6. Uh it's mostly related to utilizing and um mostly mostly like there are multiple readrs on the column database. Some are being created from the gossipet handling side and some are being created from the e side and uh they just need to be managed more efficiently. So I'm

currently working on that. Um most of it is done. I have locally tested things and they seem to be working fine. And right now we are again syncing back DevNet 6. And let's see. I think we should be working fine after this or like I just have another optimization in mind. If that kicks in, I think uh we should be fine with every PL. Um, apart from that I have been working on debugging some of the column syncing bugs as well which came in from the last week but I was mostly occupied with u with get blobs v2. Um, also I would like

to discuss um a spec change in get blobs v2 which uh I can talk about later. Um, but yeah, I mean that's pretty much from my side as well for this week. Great. Thank you. Yeah, I'll make sure to make time for that at the end. Uh, Matt or Kash, you have someone from the Lonear team. So, this week got quite a bit done. Um, the validator custody, we got that merged in. Got get blobs v2 merged in. Um, and seems to be working. Okay. Uh we're going to add the second pull of data this week. So we're only pulling on the first column uh per spec, but we're

going to add a second one and some metrics to to help identify if there's any timing uh or delivery issues of the blobs. And then uh got the uh sell proof uh change the uh for transactions uh implemented as well. Uh PR has gone through a couple rounds. Uh just a last uh couple comments, but uh essentially that's uh done today, I would guess. Um also made quite a bit of headway on our uh refactor. Been working on it for about a month and a half. So the first GPRs are up and uh we're going to we're going to be merging that in slowly over the next I would guess three or four

weeks. Um and uh backfilling will start uh in the next week. But we have some other optimizations that we're looking at um as far as peer management and uh a few other interesting uh few interesting things. I have also a question about uh spec changes on uh the beacon APIs, but uh maybe I'll do that async uh instead of on the call today. Thank you.

Uh from the Grandian team Salas. Yes. Uh hello. So uh hung was is on holiday. So there isn't a lot of update. Uh so there is one issue with with grandina pier. However, seems that the RE uh has issues with uh some other CL clients and uh at least from the investigation that we did it, it likely could be an issue on the side because for some reason it processes payloads uh some some of the payloads are processed very slowly.

Um yeah, I think that's the main uh uh update from us. Great. Thanks. Uh is someone from GU on the call? Okay. Um never mind. LCL or Marson. Hello. Uh so we have no significant updates. Uh we are just waiting consensus on the topic of BP.

Maybe this will be another update. Uh like we are actually working on PC of uh providing SS endpoint for get blobs V2. Maybe it uh something it is something that some consensus layer client team considers interesting to uh to calibrate on no other update.

Yes. And uh one more thing we added metrics for fully successful get blobs results or or uh failures. So uh it it will count uh when we return all requested blobs and when at least one it missing then uh it's counting it as failure. So we have two metrics which is which is counting it. Great. Um anyone from the Bessu or Aragon side? If not uh Roman I see you on the call from rep So, nobody from Boner

organ. Okay. Uh, yeah, I just thought you did not give them much time to respond. Uh yeah, we're looking into uh failures and uh so uh Barnabas flagged uh yesterday failures uh of one rest lighthouse pair and all red grenine pairs. Uh still currently investigating what's wrong. Uh the initial investigation uh pointed us to very high block processing times.

Uh yeah, just looking into it. All right. And Gagender, uh do you want to close us out with Ethereum JS? Yeah, thanks. So uh basically yeah started the PR for Ethereum JS and uh the thing is that we don't lo we don't use the CK KG library because we intend to be compatible with the browser as well as uh we prefer pure JavaScript. So we use micro uh each signer and uh we basically put in a request to extend that library to uh

have the cell based functions and we also use a wasam kg library and uh but that is a secondary one uh and we'll basically also see how to extend that uh as well. Um so while uh these while uh Paul Miller is working on micro signer library extending that with the new cell functions uh I will basically get uh the engine API and uh the other transaction stuff uh working most probably this week and then we'll see uh if that library is available otherwise we'll just bundle CKG for now to participate in the dev

nets and uh take it from there. Great. Thank you. Um there's no other client updates. Uh jump to DevNet and testing. Perry or Barnabas, do you have anything on the Panda Op side? I I noted the spammer configuration discussion here. Yeah, we have some breaking changes coming into curtosis regarding the spammer configuration. We have reworked the spammer. Uh as of now, we had two separate processes and two separate ways to spam uh your cryptosis network.

Basically, you could do spammer with transaction spamming and spammer with block spamming. and it's it has been merged and there's now a web UI for spammer where you can manually start or stop or pause or edit uh spamming tasks. So this will be a breaking change coming to the Ethereum package probably later today maybe tomorrow and yeah we also now have spammer running in 76 just a stable uh top spam and we have onboarded lowar currently with no validators and uh they seem to be up to so that's good and we

would be more than happy to also on board TEU probably also with no validators uh to begin with and then we can consider uh shifting around some validators so they can also check if they can propose blocks and stuff. Right. And did you censor DevNet 5 last night? Uh it's on my agenda to do it. Okay, cool. Saw it on my agenda. uh uh from the Sunnyside team. Manny, I think you had something that you wanted to present.

Uh yeah, I I have something for the unified EL metrics. Sure. I'll share the link here too. So uh last week uh we were talking with Katya about uh metrics on podas and uh we noticed that there are a few metrics that we wanted to add to E regarding to get blobs. So this is a proposal for adding few metrics in the EL but uh it would be really nice to have the naming and the format and the content of the metrics to be uh uh unified across different client implementations. So uh I I will you

know uploaded this uh proposal to the discord and I think we can uh do some uh discussion. Uh I also uh drafted a few example imple implementation on uh gad and nethermind. So I think we can also build up from here. But I I am curious like if uh execution client teams are uh open to having few metrics unified across clients because I I noticed that uh there are specific naming schemes and you know prefixes used in each client and that might not be easily

convertible in specific clients. any feedback from EL team members? I'm just thinking uh because there are naming conventions in the in in different TLS uh maybe it's easier to handle the the naming mapping based on the uh the L client. So like you just know what's the the equivalent name and and

map it outside. So yeah, leave the uh metrics as is and just have separate like aiming mapping outside so we can like identify them easily. Yeah. So the semantics of the of the of like I think histogram is different I guess in different implementations. I just guessing here counters should be the same. Uh so you have the same semantics and then then you just handle the mapping as a as a based on a table and maybe that might be a middle ground which works easy for everyone. Yeah, definitely.

Gotcha. So you have your hand up. Yeah. I just would like to share my experience through consensus clients. So how we did uh we had these specs for beacon metrics and um we used naming for from the specs and inside of the clients um they used their own variables uh etc. So how they get get used to it? Um the only thing uh that we try to structure is the Prometheus matrix name.

Um and um in this case it should be the same. Uh and we we are able not to use um not to use uh mapping in this case and we can um we can see all the clients on one dashboard that would be great. This is how it works currently for consensus clients. If execution clients are interested they they can just take a look um on this and in this case these metrics are new. they are not in in the production that's why it's easier to standardize them. So if for execution clients it's not an issue

uh that would be great to discuss and maybe Barnabas we already need a repo for execution metrics and we can open an issue for example and discuss there so to keep everything in one place in the chat uh Roman notes that all of their histograms are actually summaries Right. Uh Marshall.

Yeah. So I just uh wanted to add that like uh for us never mind the the first two metrics we already have. So uh it's like not not a big issue for us to to just rename it. Uh and uh for get blobs v2 uh [Music] we already uh change the behavior of of this method to return all requested blobs or or nothing. Uh so uh counting like number of of blobs which are requested and number of blobs which are in uh in a blob pull uh can be misleading a bit because uh uh it it can

mean that that most of the uh of the requests were like successful respond or it can mean that uh there was like one missing blob and uh there was nothing uh as a response. So, uh would be great to add two more metrics uh just uh uh counting uh how how many uh how how many response were uh with blobs and how many were like with with empty array meaning that it was like a a failure in in finding all requested blobs in a in a blob pool.

Yeah, while implementing it on the nethermind get and red I noticed that there were there was a single boolean function to check if there is all the blobs in the blob pool. All the requested blob is in the blob pool. So I slightly modified the behavior to actually check the number of blobs in the blob pool to get the correct number of the requested blob in the blob pool so that we can you know actually know in the metrics like if how many% of the hit rate we are getting in the uh request. So I think those kind of changes could work here as well.

Uh yes that that's informative for sure but like in in in context of uh of peras I think like uh we are adding uh like on ourselves to new metrics with that and uh I think it can be reasonable to to add it on client and we will have like a better view of of the structure of these responses. then I'll follow up on Discord.

Yeah, sure. Let's take it up. Yep. Thanks, Ben. Um, was there anything else that you wanted to note regarding I I saw some next steps in your 408 uh update in terms of your your next steps that you're going to take with those studies. I don't know if that's above and beyond. Yeah. Oh, I see a 415 posted here. Yeah, for the uh new DevNets, I have been running the DevNet 6 configurations on the uh on our site.

So we are looking into any you know new things that might be noteful to the client teams and we are taking that discussion to discord and Jay has been running a few tests with the different execution clients so I think he can give a short update on that as well. Great. Thanks for that. Go for it Jack. Yeah. Hi. Um I think I left a comment on the issue for the latest update. um for April 15th. Oh, I'm sorry. I messed up this morning. No, no, it's fine. I think we've just done it few hours ago. Um so, yeah, I've been looking at running

different ELS with Lighthouse this week and combined the results from last week as well, which ran different ELS. So basically what we have done is we tested lighthouse with um G, Argon, Bessu, Ref and Nethermind. Um the um main um things that we found was Bessu was able to achieve the highest which was 50 blobs per block while everyone did the lowest which was 18.

And um yeah, we were interested in how Bessu performed outperformed than others. And there were quite the figures seemed quite unstable, but it was able to recover better than other ELS for some reason. Um meanwhile um Argon seemed to have lower um blockit fetch rates. So and also lower P2P status. So that might be reason why with everyone it was performing less than others.

Um but as um Mino is working on I think we definitely need more metrics more unified metrics for ELS so that we can compare and um carefully make conclusions. Um, one last thing that we found interesting was G. With G, um, we were using less resources, so less CPU and less RAM, but it was able to reach I think it was about 45 blocks per block. So, um, yeah, those were the key things that

we have found. And for the next week along with um um DevNet 6 enablement, we will try running more DevNet 6 um tests. Great. While you're presenting, Katcha asked in the chat if people think that that we need separate CL and EL side metrics for the git blobs v2.

Um, sorry, could you repeat the question again? Do we need get blobs v2 metrics on both the EL and CL side? Um, and this might be a more general discussion topic. Mino could you um add on? So I have a viewpoint on this and I think uh get blobs on uh on the CL they they should be about the height rate that uh get blobs we do metrics on CL should be about the hit rate whether you know how many times uh you get all all of them or empty result and uh get blobs metrics on

E should be also should should be more detailed and for all the blobs that were requested the E should basically have the metric zone when they saw it first and uh or when they saw it first in their me pool. So I think these could be differentiated and uh E could provide a deeper set of metrics than the CL. So yeah, it would be great to hear from the clients. It depends on the implementation. So

uh this could be a good segue into the spec changes. Um and you had noted something that you wanted to add to the agenda regarding get blobs v2. I don't know if this in any way relates to the metrics discussion. um it's not related to the metrics but um overall u my my discussion is basically so in the spec it says that there is a get blobs time out of 1 second and I think since we are not exactly mentioning don't make use of the yes could be that if you could mute please Gadender, could you please mute?

Thanks. Okay, go ahead. Yeah. So in the spec it says that the get blob's timeout is 1 second and um I think since we are not exactly mentioning um how the CL should make use of the get blobs call or like exactly when or how many calls or if there are retries or something. I think either we should keep the get blobs timeout to something like 250 milliseconds because usually I have seen it as a benchmark it's around 190 to 220 millisecondsish if I get a good response or even a null response from the EL or I think it should be varying upon the implementation detail of CL's

but it shouldn't be 1 second I think it uh currently in the spec it's mostly like a copy paste of get payload but um I can afford to wait for 1 second for get payload. I cannot afford 1 second delay for get blocks. So I think we should either stick to 250 milliseconds which is good enough. I think even Manu from Prism is kind of waiting for 250 milliseconds. Uh I discussed this with him. Um or I think we should just leave it up to CL's. Yeah. Exactly. 100 milliseconds even better. But I think we should just leave it to CLS.

Francesca was asking what do you mean by you can't afford to wait? I can't afford to wait as in um so in situation I basically made a decision on uh whether to validate from gossip or not. The point is let's say at that slot or at that time stamp u let's say the e the CPU load was too high okay and uh and let's say let's say it's get and get wants get wants to send me a good happy response but it waits an entire let's say 800 milliseconds like there's a latency of 800 millconds so after 800 milliseconds if I even get a happy good

response it doesn't make sense uh because I'm already too late I wouldn't be able to do anything. I wouldn't be able to uh reach before attestation deadline like finish blog validation and everything. Like what what about I don't know you maybe um send the get blobs thing at 1 second into the slot because you just get the block early but you get the response late the response might still be useful um regardless of what happened in the meantime. Like maybe in the meantime you still didn't get all the columns that you wanted. like I guess I don't really uh quite understand like why can't you just like whenever the response comes decide if you need to make use of it or not.

uh because so so I think if we if we then in that case I think we should specify in the spec when to call get blobs from the CL because since that thing is not mentioned uh I think 1 second uh like writing it down as a timeout is uh a bit too much because like every CL can have a different approach they can call get blocks even before receiving the block. So I mean my my impression now I don't remember what we put in the spec um but uh also I guess when you say spec talking about the execution APIs or the content specs um execution API. Oh okay

I see. Um, so somewhere there should be this like distributed blob publishing spec uh that Jimmy had a PR for which I think was merged if I remember correctly and I think there it says basically you should call this like as soon as you get a block or I mean maybe it doesn't say you you should but like I don't remember what the exact phrasing is but like basically I guess the first time that you can do this is whenever you get a block or a column and I guess I don't really see why wouldn't you at least try calling it as soon as you get either one of those. um even if I even if I call it as soon as I get a block and there's a timeout of 1 second and somehow let's say the real is giving me the good

response but it is taking a good let's say 700 millisecond for some reason I am uh I won't be able to do anything with it like I get the good response I can construct all column side cars from it but I'll be too lazy I mean why like if for example, you get the block at 1 second, you you call it, and then you get a response 1 second later. That's still in time. I mean, it might be that in the meantime, you already got all the columns, but it might be that you haven't. I mean, I think I think we do a lot of more things. Uh I it's not I don't think it's that simple for us at least. Uh yeah, we need more like we need to receive it

faster. I'm I'm genuinely curious. Um, is it possible that you just leave the like execution layer like time out to 1 second and on the sales side you can specify your context, right? If you think 500 millconds makes sense for your case, you can just specify that and ignore these eo kind of like timeout, right? We can we can do that but so far we didn't I think or maybe other did but I think we didn't u at least for uh things like get payload and stuff like that.

I I guess what I'm I'm a bit confused about is I don't really understand what's the harm in receiving a response later like what what's the problem with that? I mean in the meantime you can locally like if if you for example I don't know half a second has gone by and you want to send some high I want requests or like anything like that you can but then what's the problem if you later end up getting these columns from the like even if it it's it's later than I don't know it would be ideal then why does it matter? Oh so usually what happens is and my query is why does even needs one second and the reason uh why why you know we

want it earlier is that so that uh our the code flow can be simple. can just do this call and within this particular timeout make it a decision whether the blobs are in there or not and then do other stuff and parallelizing more and more stuff is definitely going to make uh code more crazy and more bug prone uh I don't understand why we need one second time out in the first case Dustin dropped in the chat eels on their side don't necessarily have a timeout as a server the entire point of the execution API is that they specify client timeouts.

Yeah. So we are talking about client time amount timeouts only which uh with which we'll run the API and uh EL so so unless E needs 1 second I mean the timeout should be in millisecond only. Okay. Um so one more thing like the other thing in general is that uh let's say let's say uh gossip validation of columns and let's say this EL side stuff processing is uh we are all writing on the same column store or reading from the same column store and the more and more parallelization we do in this point u

there is just more mess ups that can happen in terms of readr consistency with the column store and yeah it just gets messed up and um yeah it's very easy to like just get offended or something. It's very simple to like it's very easy to not pass DA for that matter. So like for those reasons it's always good to get some time. Okay. Um we should probably move on. I don't know if there's a clarification that needs to be made to the spec, but um if we could continue this async. Uh Justin, you had asked me to note this uh

remove placeholder max blobs per block fulu. Uh yeah, an issue. I mean, we made two issues related to blob blob limits. Uh yeah, we'll have to remove the the fu culu max blobs per block. Uh so it will go back down to the it'll start at the the petra limit but uh we will introduce a like a blok schedule or blob limit fork schedule. Uh we need to decide on what the configuration format looks like first though. Uh I know that's the discussion item for later. So maybe we could discuss that but I guess just know that we're we're going to work on this

and make it speced out. Okay, great. And we'll come back to that here in a second. Uh there's Francis, I don't know if there's anything that you wanted to flag on the open uh PRS related to the selfproof. Um, no. I think it's been kind of like ready for a week now and I've I've checked with uh Felix, I think uh to have him try to like approve and merge it, but seems like uh he acknowledged acknowledges the situation, but he says he'll look over it, but seems like he hasn't got time to do it yet. So, I'm curious if there's anybody on this call

that can help uh approve and merge it if there's like no further discussions. I I am wondering a bit about in general with these BPOS. It's a this changes the setup from BPOS's being sort of an optional thing that people could do to being an absolutely inextricable part of of the spec. uh in terms of uh deploying a fork. Uh obviously this is at some level uh intentional now but is

that I I guess right. So I guess the question I would have is is that how how is this um how is this synchronized kind of like in the sense of um making sure that like it it it has to start at the same fork like there's now a bunch of consistency issues that were not there before that as long as max bulu was specified so when you start the fork there was always some value. Now you could have you have to what simultaneously start your BO fork at the same time as a FU fork like

at the same epoch like like it and yeah it's the whole thing is a little odd. I think I think we were going to come back to that discussion topic. We were going to close out some of these spec conversations first. Sorry. Okay. All right. No no no problem. Um, yeah. So, did anyone have any outstanding comments on the two open PRs that Francis has? Francis, I I received one uh request. I also made a discussion item, I think, from Agnes. If it's possible to update the title so that it's more easily distinguishable uh which spec section these are in because they're both titled the same. Okay.

Yeah, I'll update the title according to the suggestion. No problem. So a little bit to add there the execution API part I think it's mostly ready and for the builder specs part I believe Alex uh wants to check with the like me like community uh a little bit before we merge it. So that part the builder specs can wait a little bit. Okay. But the engine API is good to go or execution API. Yes I believe so. It's just no further questions.

Okay, great. Um, I think that that brings us back to the BO uh conversation. Um, Dustin, I don't you had opened the the two threads in Discord related to, you know, trying to take a temperature check from E clients and seal clients. I don't know if there's anything that you want to say to tee up this conversation.

Uh, sure. Um, I don't I'm not very up to date though. I've been distracted by other stuff. Okay. Uh pretty much we just need a way to specify the configuration for the BP to fork limits or the max bot limits on both the EL and the CL. Uh I think the E side is a bit easier. Um they already have a like the bot schedule. Um and I think Mario suggested that we use we treat BPO forks like regular hard forks. Uh and on the Yale that's pretty easy. I believe there were other suggestions as well. I don't recall what people wanted. Uh and then on the CL, I believe we've come sort of to consensus that

we'd like to try to define like a an array in the primary configuration file. Um yeah, I mean I think we can do that, but we just haven't done that before. It's kind of Yeah. Great. Uh Dustin, was there anything that you wanted to come back to on this topic? Sorry for that. Oh, yeah. No, no, no, no, no. I I sorry, I hadn't realized that the the agenda sequencing on this.

Um Okay. Um I anyway yeah I it it changes the structure of this a bit which is that now you have kind of coinciding as far this is sort of I guess I'll use the term activation epochs although yeah I don't know um in term in terms of the the BPOS's and and fulu epoch uh the fu sort of fork epoch Um that and and that is something that is I mean if if the specifications say this this is how this is supposed to work I mean it can be specified to work fine but it is worth noting that it it sort of definitionally if people want to

talk about these as quasi forks it becomes a little weird at that point no that that you have basically two of them happening at the same epoch because they have to because otherwise there's this BPO specification for the max blobs doesn't exist yet. It can't it can't exist if it's going to be removed. Um if the quote unquote placeholder value is going to be removed. Uh yeah, I mean uh so when Trulu happens, it'll just keep the same blob uh at first. I think it was for the first two weeks and then the first uh increase happens like at a specified

epoch that we all agree to like just imagine a function that returns the blob limit and the blob limits based on some epoch. I don't if that makes sense. already noted in the chat, we could also have a BO4 cap after the epoch. Yeah, I think that's basically what Justin's also saying. I said it had like a couple of weeks after I I I understand that that concept and that's sort of what I had thought was something closer to what people had intended to begin with. Um certainly when people are talking about this is I'm just linking this is link is

directly from the media agenda that so you know anybody with that open can see this anyway um but this is the remove placeholder max pops and block fulu um uh link and the thing is if that's going to be removed then where if let's say we do the what Perry is talking about and there's this like two weeks you know or whatever amount but nonzero amount of um delay play between FU and the first BO. Where is this coming from then? Like if if I mean it'll just keep using the electro version or the electro limit which is I believe nine. Uh but we can

also backfill the like CL's blob schedule to include that from DAB and Electra. So I mean we could just entirely depend on whatever this new format is that we described. Ah I see. Okay. No no no. Oh now no no no no. Uh now that makes more in that case. So this is an I see it's an issue not a PR. So the functionally the is my understanding correct here? putting aside what what other things one could or could not do because like otherwise exactly it seems like to allowing the BPOS to not be tied to exactly

the hard fork was probably useful um is that it still means that somewhere in that specification you don't have to call it max block fugu anymore but um the the consensus specs have to have something that You might even you can call it a placeholder if you want, but um you're correct. It does have to have something and it will I I imagine it's going to be a function such as like get blob limit at epoch. You just give it an epoch. Um right. Okay. And and that and from the perspective of the of this consensus specs, this will be another one of those abstract functions that

that has to be implemented. However, CL's implement these things that it's that um I would prefer to I'd prefer it to be as uh well defined as possible like if I don't want it to be very abstract, but we'll see. It's hard to know before we do it. Okay. Sure. And uh one other thing I want to note is that the the Fulu placeholder actually does include an increase. I believe the limit was like 12 or 16, I don't recall. So I mean that will Hulu will start off at a lower block limit than what is currently specified, right? Okay. But okay, so

that that at least clarifies um um what's going on for me. So that's okay. Thanks. And so was the I kind of concluded this with a schedule. We addressed a discussion item two just so people know. Um is the aspirational goal to have this BO implemented uh in Fusaka DevNet zero. I would like to see that implemented in zero. Yeah, I think that would be really ideal.

So the the schedule I tried to summarize here at the bottom um we've got DevNet Beardos DevNet 6 live got on the radar petra mainet happening uh in two weeks on May 5th and then the sort of stretch goal or the I guess the base goal rather is to see a Fusaka DevNet zero with a BO implementation live by June 1st to be able to observe that prior to interrupt think I'd like to see the Faka devet zero a bit earlier purely because we do have to coordinate with the ef guys and having a few even a week or two of slack

would really help with that. Okay, great. I will update that to be we'll call it like June 20th. Give it split the difference 10 days earlier than what I have. Yeah, that should be okay. Okay. Oh, May 20. Thanks, Francis. Good. All right. Um, any other discussion items? We've got 9 minutes left. Did we agree on which format we want for config on DPLs? Because there were about three or four different proposals, right? Yeah, we did not. We should talk about that.

you. Uh, is there someone that can advocate for each of the proposals? Uh, I guess I can start things off on the CL side. Uh, I would like to advocate for the one that I mentioned earlier, which is just to define an array in the primary configuration. Personally, I'm not a huge fan of the like BP1 epoch and then like eventually down the line with like BPO7 epoch and then BP7 max. Like it just doesn't feel very good to me.

Um, and then uh I also just don't like having a number in the name. I don't know if that's like me being be me being too nitpicky, but I think an array is just like makes the most sense. Yeah, on the sales side uh I would prefer the one where we uh we have uh array in the uh we have block schedule in the config itself but they are keyed by the epoch and uh yeah so that that is the variation that I would prefer on CF. So instead of a list it' be like a dictionary or how does that work? Can you do that in

what's the question? Oh, uh, you said you wanted it to be keyed by the epoch. To me, that implies like a dictionary. I guess I just didn't understand. Yeah. Yeah. A dictionary under I'm sorry. Can you do a dictionary in YAML? I didn't think you could. I think Stokes has noted in the chat that's referred to as an array of records in YAML. Cool. Yeah, we can look into that. Yeah, I don't know exactly what they call it, but it should be possible.

And then uh Mini from Sunnyside noted or asked the question, what happens if the increased blob count seems unsubstantable for us to continue to the next BO fork count? Oh, we would just update the schedule to reduce the blob count or to just u delay kind of like what Harry said in the chat.

I see. Okay. Yeah. I think whatever values we choose would give us enough time to react. Essentially, we're not going to be saying um double the blob count today and double it again tomorrow. Probably we'd have weeks in between where we can coordinate changes. The proposal that Stokes had laid out was I think showing two months between each of those uh step functions. I don't think we should discuss timelines about that. Yep. You think we should? Absolutely.

No, I think we shouldn't discuss timelines. Sure. Gotcha. Yeah. Just that the concept allows for a lot of time in between as well as reducing the block count if we feel like things are moving in the wrong direction. Yeah. And uh Demetri noted that we should I should have said release instead of config. So clients would just come up with a new come out with a it would make a new release. Operators would upgrade.

I know there's not a lot of time and seems like there's no further discussions. I'm curious, should we discuss the builder specs changers? Yeah, I do have a discussion to bring up. I mean can shortly I can bring it up in short time. Yeah, please do. Yeah. So, basically uh while uh we were uh reviewing the work of uh we were optimizing our uh u our cell computes in uh Lorstar. We basically uh thought that why do we even need blobs as such from E and why does EL even need blobs? Why can't it just be cells all across? because uh in the end

uh the block consumption is to be done by uh by by uh by L2 APIs by L2 clients and in that particular function that we are going to provide to them we'll just chunk one to 64 uh cells together and to give them blocks but rest of the entire pipeline that we have even for beacon APIs between uh validator as well as uh beacon client where we pass block contents. I mean all those APIs we can just uh uh replace blobs by cells and basically then have this format where everything is just ready to be consumed

by EL and CL layers all across. Is there anyone that can weigh in on that that from the E side? I don't know that I followed all that. sound like a a sizable revision though, right?

Yeah, it will be a sizable revision in terms of there's will be there will be quite a good number of code paths and API changes that will be there but I think it should be manageable uh in the sense that all those paths are well defined and there isn't going to be any research question about it. Francesco, do you have Go ahead, Francis. Oh, yeah. One quick thought on my side, uh, is that, um, I like have changing everything to sales can be very efficient in terms of like on the protocol side, but it can add a little bit like more work on the client side

because instead of like sending blocks, they have to like send sales now and when they get things back, they have to reconstruct it, etc., etc. Um, I'm not saying it's not like it's not possible, but uh it feels like a an abstraction that the external clients of the protocol does not need to know about. Um, yeah, this just like by quick source. I mean even external clients they will just be creating some transaction with some uh API some API tooling and then they will anyway be consuming our get blobs uh sidecar uh API or something like that in which we are already saying

that for full nodes only they will serve and we'll chunk the cells together for that uh 1 to 64 cells together for that and uh so in that sense I don't think uh how immensely those uh consumers final consumers or final producers of these transactions will be affected. Uh gadget there's a question in the chat. Uh don't the eels need to know about blobs? How's the TX sender send blobs to the E?

Yeah. So TX sender will not send blobs to the E. Uh they will now sell send cells. Apart from that uh I don't think in the E we do much with the blobs over there. We just verify the proofs and once the proofs are there we just accept the transaction and uh uh then basically whatever is accessed in EVM is uh is uh basically on on basis of version hash. So I don't think in E we really need blobs as such. So my proposal itself is that transaction will not carry blobs and now they will carry

cells. Why is this useful? So this came up when we were looking at the get payload v5 is we're getting blobs back from the e. we have to split it into cells in order to do the verification of the proofs and then the package gets sent to the validator for signatures and then sent back as blobs. Um so we basically convert to cells do validation convert well use the blobs to go back and forth and then either have to cache those cells that we split up or recalculate the cells a second time when we do the actual publish is where this came up with. So we were discussing is why not just have cells all the way

around if the paradigm for uh fulu forward is cells you know just just have it start as cells and it just carries all the way through and there's no conversion back and forth between blobs and cells and there's also no um there's no uh confusion about whether it's blob proofs or cell proofs or which you know what I mean it's just it keeps everything consistent uh across the stack. So the changes with the engine

API or with the RPC. Sorry, I think I missed that part. Uh so change will be in uh the transaction encoding network transaction encoding as well because we are saying that the transaction itself will carry cells not blobs and then in the engine API as well because uh that will again uh carry uh cells not blobs as well as in the beacon API between uh uh validator as and beacon to sign uh in the signing flow because again that uh in the block contents. Uh, it will not carry blobs. No, it will carry cells.

Mhm. Uh, is this proposal written down anywhere? Uh, we just came up with it a couple hours before we got on the call. We figured we'd just float the idea and see what everybody thinks before we really took it any further. Yep. Um I'd be interested to know why there's you convert from blobs to cells then back to blobs again. Uh we don't convert back to blobs but we basically convert to cells in order to do the verification when it comes from git payload like to verify the proofs and then uh the uh beacon API uses blobs when you do the publish. Uh so basically

the signature flow uh is based on uh a blob. Um so like you basically have to cache those cells and then send the blobs back on and then either use the cache cells during the publish flow or recalculate the cells during the publish flow. So, we just thought, well, maybe we just do it one time and and let the cells flow through, but or or we could still do this caching thing where you basically to avoid having to recalculate the cells twice, right? And I think when you say cells, uh, convert blobs to cells, you mean we basically take half of the, um, like

when you convert blobs to cells, it's basically doubles the size. You mean like basically to take half of the size instead? So you still have a blob. It's just that it's in the cell format instead. Yes. And that is the tradeoff is that the the API calls between the the beacon and the validator will increase bandwidth. uh but the memory and computation time uh or really it's computation time gets cut because you don't have to recalculate twice or store the result of the slicing.

Well, um maybe if this is something that uh you want to draft out in writing and continue async. Uh I think there's some concerns around like any time implications that this might have. Um so but I would just encourage you to uh sort of flush out the proposal and circulate it uh async and we can pick it up on the next call if if need be. All right. Good to talk. Thank you all.

Bye everyone. Bye everybody. Thank you. Bye.