PeerDAS Breakout #27

Transcript

Hey Owan and Lion, we were just starting off with some client updates. Uh, Lighthouse is first if you're available to provide an update. Yeah, I can give an update. So, we've been working still on fixing a bunch of sync issues. Uh, not much different. Last week we found like a bunch of uh edge cases in our uh rain sync handling that we have fixed now and we are testing on uh sunny side uh sunny sides network and I think it is working as expected but we've found like some more

edge cases now that we're working on fixing so that's mostly being working on sync fixes. Yeah, that's it from us. Excellent. Thank you. Um, someone from the Prism team. Hey, uh, yes. So, uh, first we are continuing to slowly merge our pure D branch into our main branch. Um, 18,000 line of code to go. So, it's still not yet done, but it's progressing.

Um yeah on the other side we implemented an improvement on um the data column cycle ver verification pipelines. We we added some uh cache to improve the processing time cach about the c in inclusion proof. Um yeah uh also uh we added a new uh flag uh to only um subscribe to data column subnets. Right now before with prism if you wanted to to be super node uh you had also to subscribe to all subnets like add subnets and subnets and so on. And now

you can choose if you want to only subscribe to data subnets. Um yeah we work on uh the builder API which was not done and lastly I guess we have non from base work on emerging sync implementation. Um for example um if you are a full node and you need some some columns and if no peer at all is able to serve you the given colon you were not able to to to sync or to request by wood or by range the column. And so the idea is um if you are in this situation, but if you have peers which custody any of

the 64 columns then in in a last resort you just try to grab any of any 64 columns any of them and then you you you try to reconstruct and finally you get the colon you want even if you are a full node and this should this should help for example for devet like like the situation we had in Devet six um where it was very difficult to think. Um yeah, I guess I guess it's all for present for this week.

Excellent. Very substantial. Thank you, man. Um Dimmitri or someone from the tech side. Yeah. Uh we were implementing changes in by by root PC handler. Uh it now accepts uh columns. Uh we have not merged these changes yet. It needs review but it's finished uh and uh good at testing and we need a confirmation if it's included in the net 7 uh to to merge. That's all for us. Excellent. Thank you. Um anyone from the Nimbus team on loadar.

Uh got uh all of the uh PRs that we had open uh over the last couple weeks. Uh got them all merged in. Uh also made pretty good progress in getting uh uh refactor uh merged in. So working on a few PRs to to get that done uh and cleaned up. And then as uh as uh Manu mentioned also uh got a plan together in order to get our peer dash code onto unstable. Uh there's a few steps uh that we need to go through. So, we're slowly uh merging that in some of the uh easy to parse out pieces uh that we can get in and then we'll continue that after we

get the rest of our refactor code merged in. And then also made a couple updates to how we sync um and how we do our peer management in order to uh make that a better process. Um, so not not a ton of forward progress, but uh have been doing an awful lot of integration testing uh with Crytosis to make sure that uh uh we're going to do fine when we get to the DevNet stuff uh this week. Awesome. Thanks, Matthew. Uh Grand Do you hear? Yes, I can. Yeah. Okay. So Hung got back from vacations and he did

a few uh things. So um essentially a few fixes related to API such as engine get blobs B2 uh like a null response handling and so on. And uh today we discussed with him um on uh on the issue that on this on some uh deet he experienced the problem when um the syncing uh was not working well because not all the peers are returning uh the columns that uh that are requested and and actually that's maybe

a discussion for for call a bit later. Uh we are thinking to to implement uh in in this case where we cannot fetch uh all the columns because the other peers are not returning uh it consistently we will just try to uh reconstruct uh the missing columns during the syncing. So, so yeah, maybe after this update section we can uh discuss about this strategy. So that's good. Thank you.

Thank you. Uh anyone from the death team? Uh Netherm no significant update from Mite. Uh we have internal reviews and just uh making uh uh the PR with with pure uh closer to be to be mer the master and and production ready but uh no new features no changes like functional right now.

Thanks Marson. Uh Dan on the ref side. Hey. Um, yeah, we haven't had any functional changes since last week. Uh, we've been or will be rebasing our branch to support on top of main. This should not change any behavior with respect to the devet although uh may surface any new bugs that come as a result of the rebase. Other than that, nothing new since last week.

Great. Uh, anyone from the Bessu side? Anyone from Aragon team? uh gadget from EthereumJS. Anyway, yeah. So, the update on Ethereum JS is uh uh that the functionality was dev complete and I also added test cases for

uh for the uh new trans cell transactions uh for the cell uh network wrapper and uh uh and also uh end to end client test. Uh so now my next aim is to test uh with ktosis and hopefully we should be able to join devet 7 this week. Excellent. Thanks again. Uh speaking of which Barnabas do you uh I don't know if you want to speak to testing devet updates.

Uh so basically I've been mainly focusing on uh back testing and not really focused on per testing after the network has kind of died off. I think the major issue was the executioner clients were basically processing uh specific blocks for a very long time and I'm not sure if we have uh a fix for that already and I also mentioned this in chat. It' be nice to have bit more yeah clients on this call especially uh maybe Marios and Roman would be most up to date regarding this. maybe someone from Netherland. Uh I also know that

Netherland had some longer block processing times in domestics. Any nodes that could speak to that? Uh there was also some clients that had uh some CI clients that had uh some bugs in the data custody implementation and they might have reported incorrect subnets that they holding while they were not actually consing it. So yeah, we we're going to be really looking into pure I think uh starting

after Petra fork uh most of our efforts are uh currently like petra debugging and we also now have a shadow of work running there. Uh if there is the big push to like roll out Evan then we can probably squeeze it in for uh the end of this week. But I yeah I'm just not sure what the progress on delegated custody implementation from different CL teams and whether they have run any local tests. It would be nice if all the C teams would be able to verify locally that their Wish custody is working as expected uh proing the subnets that they

are supposed to and etc. I can speak for freedom quickly. Uh so the status right now is um we didn't did not find any bug in valid custody or subnet advertising in prism u as long as um there is no new validator added uh in flight. So because we we still do not do back fill. So if new validators are added, we we don't back field the new columns but it was not the case in the dev net 6 unless I'm mistaken and so um

we didn't not find any bug. If any of our clients team think there is a bug in prism, please um reach out to me else we won't do anything more um about this topic and on the is there anyone from the Sunnyside team? I don't know Barnabas it sounds like the Sunnyside network is near feature parody with deadnet 6. is I guess I'm just uh trying to ask a question with Pekra right around the corner if there's a if anyone has a need to push for DevNet 7 prior to Hector going live or if uh people are able to

still test a complete feature set on the Sunnyside network. I think we are good with Sunnyside network right now. It's working fine for us. Okay. Uh man. Yeah, the network is working right now and we can keep it up uh as long as you guys need. So if like the resources are contri to like petra, we can keep the network up for longer and we can like uh update the images and new features from the client teams as well.

And I guess before we move on, Barnabas, you had a question for Justin about how the Bezu implementation's going. I don't know, Justin, if there's any kind of uh welcome to the call. If if there's any intro questions or updates that you want to provide just to kind of help set context for where your team's at. Yeah, sadly I don't have that context at the moment. Apologies. Um I'll try to get you something on that. Um, I'm unfamiliar with this proposal problem, so I need to I need to get my head around that.

Great. Sounds good. Thank you. Um, and then I guess moving forward, I don't know if Sunnyside or Pandoffs if you had anything else that you wanted to cover in the testing DevNet section before moving forward. Um I think the BO scheduling would be a good topic to discuss whether we have any updates uh regarding the BPO scheduling from this things especially. Yeah, last week we kind of left it off with CL teams uh agreeing to remove the BO fork schedule from the current blob schedule I believe and EL teams needing to communicate async to make some

decisions on a structure for the BO blob schedule. Um, I don't know. Justin, is there anything that you've sort of been moving forward or like trying to land on an answer for either of those or if you have any questions or you I mean for the CL side it's a bit complicated because our testing infrastructure doesn't exactly uh it doesn't work so great with the blob schedule if we include an Electra in there.

uh the the version that we have in the PR which does not include DNV or Electra and and it just includes a few um BPO fork examples. Uh this works. Uh I don't especially love it. Uh I do think that we should just have like a DAB and Electra in there uh and then have it work for previous forks as well and then not include the BPA forks in the specs. right now kind of like we agreed upon last time.

Um but we've just run into difficulties with testing uh because I don't know how much to get into it but uh like in the in the configuration file we specify far future epoch for like upcoming um like upgrades uh and it's a bit difficult to test around that and especially with minimal as well where everything is far future epoch Um what we can do is just kind of uh get the spec in a way that like clients want it uh and then figure out the problems like spec testing problems later. But uh it's a bit

hacky. Yeah. Sorry that's a lot. No. And then anything on the EL side? I don't know if you were a part of those conversations. Um, I think last week we were trying to get a commitment. Okay. Yeah. Someone else will have to say something for anyone from an EL team. Uh, never mind. I don't know if you made any headway on landing on a format light client I see you just

joined the call on sorry I had a question for the CL side so the I didn't completely understand the issue Justin so you're saying that we like for the testing in the consensus specs repo we need to incorporate the uh den den and electra fork epochs into the bo schedule somehow or we don't need to do that I didn't understand what you mentioned uh yeah sorry um currently it does not contain the nab and electra uh but I would like for the blob schedule to contain the nab and electra and also be able to test that properly.

But uh unless we have the like default uh defaulting to like max blocks per block electra like it won't um should I say it uh unless the epoch is after like you know whatever the net the main net epoch is like it'll just return zero which does not work. I see. Whereas we like most of our testing is from genesis. So we assume that like uh at slot zero the like the current fork is dabb for example. So all of the the states that we pass into like the reference or the states that we pass into the tests they

all have slot equals z epoch equals z. So we would have to somehow handle that so that it has a an appropriate slot value. Cool. Thank you. Great. Uh light client I don't know if you're able to provide an update from GE on peros implementation. Hey, unfortunately I'm not sure what the latest is. Marius has been the one who's been maintaining the PR. I was just trying to come in and try to get a bit caught up so that I can start helping

out more. Sir. Yeah. I mean right now the I think the big uh update you know both for you and Justin is really you know correct me if I'm wrong burners but trying to work through some uh sync issues uh with DevNet 6 right now people are testing on the Sunnyside network while um I guess everything gets uh worked through and implementing some uh fixed PRs to launch DevNet seven. Um, seems as if the plan for that is to like obviously prioritize a smooth PCRA uh hard fork and then uh sort of I guess

direct more attention back to DevNet 7 and getting that launch. So, we're trying to get some uh finalize some decision making around the bo block blob schedule. uh the CEL clients are a bit further along in making those decisions than the E clients. So if that's something that you all could give some thought internally and maybe provide an update on next week, that would be really helpful. Okay, sounds good. Yeah.

Uh Sunnyside J, you had opened and flagged this. I'll just kind of start opening some of the uh open spec PRs that we have to go through. Did you want to say anything about this J? Uh yeah, I just want to quickly go through. So um from fu fulu um blobside cars by range and root RPCs will be deprecated after supporting for the um data availability window for the u blobs to um request the electra

um blobs. Um but then the um concern we had while I was implementing for lighthouse was like how to deal with if you request with some fulu blocks. So um initially we did maybe we can penalize the peers but then um lion suggested that it might be too harsh for them and also we have to implement the um penalizing logic just for that 18 days of the availability window. So um my suggestion is just don't punish at

all during that duplication period and then um even if they request it just don't return anything for that slots. So um from CL teams I want to hear like if there are any doubts in terms of implementing this kind of thing for duplication. Yeah. CL teams any uh fine by you I see from Manu in the chat Dimmitri any thoughts

on your end or any other CL client team client deb Sir, Justin likes the PR. Thank you. All right. Uh Justin, were the two that you noted in the chat? Let's see. That's four. I would just open the second one. Those two uh on the open specs in discussion aren't really relevant. That's just the blob schedule like a Gotcha. The blob schedule PR and what's up.

That's the first one. And then the second one. Yep. So, this has already been merged. Um, it was a suggestion from Terrence a couple weeks ago or last week. Um, pretty much we just changed the like the request for uh data col data columns by root. Uh so it's one route and then multiple indices instead of one root one indicy per time like each request. It's a bit more efficient. Um smaller worst case size as well. Uh I did merge it. I might have merged it a bit too soon. Uh if anyone is against it, please let me know. I just want to call it out.

Great. And then the other link that you dropped in there, the FU blobside car by range. Anything that you wanted to speak over there? That's the one that uh we just went over. I'm also happy to merge this now unless anyone is against it. So please speak up. Okay. But yeah, that's it. Awesome. uh the two carryovers that you had, I mean that you know have been on here. Anything that you wanted to highlight in terms of trying to move forward?

Uh nope. We'll keep working on the block schedule PR. Okay. Uh Francis, anything that you wanted to call attention to with u uh the so the engine change has been merged. Uh Yeah. Um, so I guess the only thing maybe needed from for the team to implement uh that based on the like engine API change and just to call that there is a little bit of a change maybe addition for the uh like validation rules for like older APIs etc that's been added uh to the PR. uh if you implement it a little bit earlier like

maybe three weeks ago maybe double check the um PR to make sure that you implemented all the requirements from the spec but other than that you should be good to go um yes and for the second one the builder one I'm curious if Alex has any updates from the kind of like community engagement from the MEB site I do not yet get them to you M okay great thank you. Uh but the general idea here is that uh just to recap we want to when when we are like sending requests to the builder like submit the blended blocks uh previously we require them to return us the both the all the blobs and

the execution payload and now we are discussing probably definitely like we remove the blobs like when like after pas or fulu because there will be many many blobs it doesn't make sense for them to pass it back uh like they can propagate themselves And uh maybe the discussion point here is that uh do we require them to ex return us the execution payload or not. Uh there seems to be someone supporting like not at all because they return those things like super super late uh to the sale anyway. So it doesn't help with propagation. Some say it could be helpful. So I guess that's the kind of like the main discussion point um over there. Uh the final one so is this one. No. Uh the final one

is like a minor change for the like get blob sidecar like spec. So after fulu basically like we will store data columns and not blobs. So it's not easy to just like return certain blobs being requested. So the idea here is that to update the like API a little bit in place to only return like uh blobs if you have all the blobs uh available like like you are a super node. So if you don't have them return return everything as now uh so that uh it's kind like make it easier on the client teams to implement that and make the logic a bit simpler.

There is another like um recommendation by agender mentioning that let's just scratch this API and just start a new API called get blobs to make things simpler because we are kind of like treating this API as a trusted API and we don't quite care about the all the proof and related like commitments potentially uh returned. So it could be like simpler if we just like have a get blobs API and return just blobs. So that's the situation and would love to get more like reviews and discussions on that.

Thanks Francis. Uh Dan, did you have anything that you wanted to add to that? I see your handset. Uh yeah. Um, so the changes since a few weeks ago for the uh engine API changes are these uh for example breaking API changes or are they just uh validation rules? Just validation rules. So there are two changes. So the first one is that pre like we added one validation for the get uh blob v2. So the new addition is that if you pass a invalid blob hash or a

blob hash that is kind of like prefu uh we will return all news instead of like returning any kind of like errors. Basically you are requesting something that maybe not existed or something like that. Uh the second thing is like for the get blocks v2 and get payload v4 I think uh if you get if they get caught like after fu they you you will return like uh unsupported fork error. So that's that's the main change. I see. Um yeah and then I had two other EL related questions. The first is the BO stuff.

What exactly is left? What needs to be decided essentially by EL devs? I know that there was some, you know, I know I think Will asked, you know, have any EL devs made, right? Are there any decisions made? Uh, I think the last time I heard about it was on a recent ACD. So, if I were to guess, there were no major changes since then.

But is this maybe we can just set up a thread in Discord to finalize the format. Would that work for everyone? I think there is a thread from Justin like in Discord uh that is kind of like has been discussing that like the Y kind of like broad schedule format. I see. Um yeah, I'm thinking maybe we can add all the kind of like stakeholders like more clearly there to like reach a decision.

Yeah, it it seems like something pretty easy to to finalize. And if this is the main blocker from the E side, um I think we could wrap this up quickly if we um if we make a decision in like next week. There's there's no real point in standardizing this on the E because we have different genesis formats anyway. So yeah. Yeah, we can pick a we can try to align, but like this shouldn't block anything.

Right. Um, okay. I mean, that Yeah, that makes sense to me. Um, and then the the final question was there was a there was a note in chat from Barnabas about block building timeout issues. Uh, which thread is this in or we had this uh discussion in the pis channel. I'm not sure if I can find it, but I will look for it. Okay, cool.

Uh, and I think that's it for my Oh, thank you. Yeah, I think that's it for my questions. Great. Thanks. Yeah, follow up on the EL format. Uh I believe last ACDE we agreed to do well I linked here on magicians. So it's just the what's in the EIP and for each name you just use BO with a number.

Okay. Yeah. And we'll I mean yeah every client has its own you know internal representation but uh but yeah this makes sense to me. This would just be in the config and then Justin was saying it'd be nice to align them. So the VPO numbering you're saying? Yeah. Just have the same syntax, the same keys and values and the configuration. Yeah, it would be pretty bad if some client starts from index zero, other one was start from index one and then we would have huge mess up just

the source of truth for them to look at is that was sorry uh you you haven't linked to the blob schedule PR if you just click pull requests at the top of the repo well of the consensus specs repo but it's not the s source of truth for the e this is only for the jud blob schedule correct this will be the source of truth for the cl side uh when it's merged but in terms of uh as Alex was saying trying to sort of

have some sort of uh you know, common vocabulary across the two. Is this one far enough along that eels would be work working to match this to some extent? Maybe. I mean, just we uh we start with index one instead of index zero. Yeah. No, let's not compare them between E and CL. Um, one thing that came up was it was much easier for the EL's just to basically make quote new forks like in their code. Uh, so it works just to say BPO whatever 012 whereas we needed to handle this a little bit differently in the CL. So

they don't need to match across the EL and CL but they should match across clients within I think. Yeah, that's right. Um and then I think Francis within your update um you mentioned something that maybe we I just want to surface if there's any other discussion around it but uh would you say a get blobs specific API? Yeah, the get get blobscar spec. Uh I think it's ready if we don't want the new get blobs API. Um if we want to just keep this one and make minor changes to it. uh would love to have more maybe like plus ones to it and get merged if there's no further

questions but if we kind of like support the new get blobs API we love to see that on the PR as well so that we can continue the discussion and hash that out there I saw plus one from you any any other plus ones or dissenting opinions on that plus one from Manu Okay. All right. Um, Alex, you had this draft uh just a couple like polishing to the EIP.

I don't know if anything you want to comment here. Um, I can just give some context. Um, this is becoming the premier EIP of this fork for Saka. And if you look at the IP, it's uh a little sparse. So, I was starting to add some things here. Uh Franchesco was actually helping me with some language uh with the security review. And yeah, this is just kind of in progress. Um it's not blocking anything, but it does need to happen. Okay, great.

Uh were there any open discussion questions or topics that people would like to cover? Um I see that we're getting more e uh client devs on the call which is great. I don't know if there's any open if you want to use this time to like ask questions. Solius, you had a topic. Yes. So I shortly introduced this question when I did a update at the beginning on the uh of this call but the the key question that I wanted to get feedback.

So whenever we need to sync uh all the to fetch all the columns uh all uh all the columns from the network uh and the hungling when was testing he he often not received uh part of the columns from the network and uh the way our sinker works it's a bit optimistic syncer it essentially uh if something fails it fetches everything there. Uh maybe more correct would be if if the head is not if the chain is not moving forward then we try to refetch what we already got. So, so we came with uh with

the idea that maybe it makes sense uh whenever we need to sync those uh 128 columns, maybe it makes sense that if if we cannot fetch from the network, we start to reconstruct uh the missing columns uh assuming that we received 64 of them. So my question is maybe some clients already implemented such strategy and uh is there some downsides of this except of obviously the higher CPU usage for the for the reconstruction part.

Um yeah it it is actually and neuron from B is exactly what uh he was implementing u last week what you said. Okay. To yeah to to recon if you want a colon if you have if you have full node if you want to colon and and no PS is able to save you this colon just try to fetch 64 colons any of them and then reconstruct the colon you need. Okay. And the the is there some I mean if the implementation is already completed and tested was there some you know insights from that.

Uh so um so we had the ID a few weeks ago the implementation is uh I mean there is a pull request and I just started to review it 10 minutes before the start of this meeting. Okay. If if you will figure out some some interesting outcomes then let us know. Okay. And and this this particular scenario I think is quite interesting because it's likely to happen on the unhealthy network uh where we will not be able to you know reliably fetch all the columns. So, so I think we we may have this idea to to mature enough maybe all the clients eventually we'll need to

have such mechanism to be protected from the cases where the network is just not healthy enough to serve to reliably serve all the columns. So yeah that's that's all just a question you want to do it for by range by route bus uh I think we didn't discuss this uh so far we we will need to check for exactly the for the exact cases. Okay. Okay.

Uh I see Francis and Pawan have hands up. Are these related to uh this particular topic or separate topic? Uh Paul on was yours a followup to this or a separate topic? I see. Okay. Uh any uh followup comments [Music] on S's discussion point? Yeah, sorry I uh raised my hand down by mistake. So uh I had the same question if you were talking about rain sync or for root sync because I'm pretty sure that we do this uh do the thing that you mentioned solius when we uh can't fetch uh like

when we can't fetch columns at uh head like but we don't do this during grain sync but I cannot remember the trigger at which point like we actually decide to do this reconstruction but we can follow this up offline I think great uh Francis maybe let Marios like give an update about gas and stuff and I can go later okay great uh Maris you want to provide an update yeah um so uh if after yesterday's discuss

discussion I uh I I pulled out the um eof stuff from the uh from our Pas branch um and updated it to the latest GUM master. It's still a bit under construction. Might work, it might not. Um I will have to check it myself. I think your audio cut out there after you said you were going to check yourself doing a little more. Posted the one that is guaranteed to work in the chat. Um I will make sure

that the updates that I did today uh are working fine on the devet and uh then I will move the branch to the upstream repo so that you you guys don't need to uh pull in my my uh my personal fork anymore. Um uh regarding a BO uh there's not I don't really know what to do there. Like I don't think there are any ex except if we like if we schedule some BO then there might be some changes but otherwise there aren't aren't that many changes that we need to do in the codebase. Um otherwise for the engine

API we are um we we do have this mode where we only uh returning the full um uh the full blobs um and not like half half full blobs. Um and yeah, there's there's sometimes this error message um that uh we have some V1 blobs in the payload. Um and yes, I'm aware of this and I will fix it. Uh yep, that's

it. Thanks, Paris. Uh Dan said, "Yeah, it doesn't look like the BO impacts anything for DevNet 6, although it would be pretty nice to schedule a BO fork somewhere during Fusaka DevNet Zero. Great. Uh Francis, yeah, this actually like cuts into what I'm trying to kind of like mention here. So since EOF is kind of like no longer inside Fusaka, does that impact our schedule a little bit, maybe we could put like Faka down zero a little bit earlier or maybe like there's some other things we need to

consider. Just curious about may Yeah, the the situation here. I think it kind of depends on uh what other EL changes will be uh speified. I think the the mod x stuff is already speified. Um so uh yeah we will we will need to add that before we go to um fusaka net0ero. Um but otherwise there's not like there's nothing

that as Barnabas said there's nothing uh with EF that would have slowed down Fusaka timelines in my opinion. Okay, great. Good to know. All right. Uh, any other open discussion items? Um, so I I kind of wanted to want

to go back to this this uh like all or nothing on the on the blobs. Why is this beneficial? Because from from my point of view like there will always most likely when it ships on mainet there will always be uh transactions that we don't have in the in the public meool. So if we if we change this uh uh get blobs API in this way um it will not be very useful like is there is there that's the whole thing that we were

talking about uh and have been discussing is that the likelihood that all of them are going to be there is especially at the very first object that comes across uh is low. Um we've implemented two different polls. So we basically try to pull get blobs v2 right at the beginning when the first column or the first or the block comes through and then we also do it uh at the end of our waiting period before we start resping anything that's missing. And we're going to look at the metrics basically once this happens. But realistically like the DevNet metrics aren't going to be very useful for this

assessment of whether it's actually going to be useful or not. But like the big picture is is that it's a great point like is it going to be is it going to really work? Yeah. Even even then you are only measuring the pro propagation of of these transactions over the public mess. But correct we kind of live in a world where like most of the like a decent chunk of the transactions are not going through the public meool anymore and so okay so but we have uh metrics on get blob v1 on mainnet and we can show that 60% of the times that when we call uh get blobs v1 currently on mainnet we get whatever blobs we've requested. So

whatever blobs that are missing that didn't come across gossip by time the 2.5 second window ends that we make the get blobs v1 call 60% of the time those blobs are available. So is that also going to hold true with globs v2 that we'll be able to get everything that we need maybe. That's interesting. Have you seen a Oh, well I don't It would be extremely interesting to see if that number changes uh with Pectra because we have the we have the more blobs in Pearra and I suspect that the more blobs we have the

more blobs will go through through like uh not the public me. I would guess not though. Like there's not really a big incentive in order to send them to the to the private mess. I mean, there's really no MEV in them. So, why pay to have them included by uh by builder? Just leave them there unless they're looking to get the to make sure that the transaction happens uh in builder blocks, you know? So, they send it to the private and the public men, but like the builders see the public menool also. So, why wouldn't they pick it up? I don't know. Yeah, that's that's true.

That's true. But I I guess uh I think probably all L2s will try to send the uh the blobs both in the public and the private mess to get them as quickly as possible. Go ahead. Sorry, Patrick. No, no, no. They're just confirming. Good. Sorry. Uh yeah, Franchesco had added some comments to the chat. I don't know if you want to jump in here, Franchesco, or I can just read them off. But yeah, I mean can just repeat the comment basically. Yeah, I mean I guess one thing just um from what you were saying Mario like it seemed to me that there

was like a bit of an implication that someone were changing API in a way that introduces this problem that it's it's somehow a choice. I just wanted to clarify that it's not really a choice. is just like it doesn't matter if we use get blobs v1 or get blobs v2. This will anyway be the the case that we need all the blobs. This is just because column propag like we do column propagation and not blob propagation on the CL. So it's just this mismatch between the EL and the CL that like we can fix in the future if we instead uh work with cells directly. But yeah, that's just not going to be the case for for pure. So that's just something that we're like forced to kind of deal with for now. Um and then the other thing is uh yeah that I I I think the the issue about private

blobs just isn't too much of an issue because most of the point of of this feature is for local blob building and uh yeah then private blobs are just not an issue there. Still we have to see okay at a higher uh blob count how many nodes are actually um do we expect to have all of the blobs that that will be published. I suspect that this is probably not going to be much of an issue because um if you assume some like random local block builder as a bunch of blobs at time zero like even you know this being like 30 blobs 40 blobs or something like that you really would expect that at least some nodes around the network do do have all of those because just you know in practice

actually that's just not that much data like 40 blobs is is just uh um like a few megabytes and yeah so we and we don't need everyone in the work to have them. We just need someone to have them and then to be able to kind of contribute to to repropagation and just kind of help out with their bandwidth. So at least for for the local block building use case, I just would wouldn't necessarily be too worried about it because of the all or nothing nature. I mean then yeah, we we should see this in practice. And for the non-local block building use case, I don't think it matters that much. Like if you want to put private blobs then well just you need to have the bandwidth to to actually do your own propagation and not rely on get blobs.

So the the the only issue I have with this is um like get blobs is designing for the average case, right? And it's not designing for the worst case and the worst case kind of an attacker withholding uh or like p like not publishing this the blobs on the on the lo on the public man pool. And so the way I see it, the network should be stable without get blobs and uh because get blobs is just an optimization that we can use to save bandwidth. It's not not something that we can rely on for the health of the network. Well, it's not exactly for for

saving bandwidth. It's for helping publishing. So like when CL's publish the columns, uh we are optimizing for the subnetss that we're sampling for. So like we're making sure that we have enough peers so that we're able to pull the data we need in order to sample on a typical slot. But when it comes to publishing, we need to be able to have a peer that's going to be on every single subnet. And this is only for local block building flows though. So like only when you're doing a local build. All right. So now if for instance I have I do not have a peer on column 110 subnet or column 100 or a missing one or two I'm going to publish but I'm not going to publish all of the columns. So like the network needs to rely on either super nodes that are or nodes with more than

64 custody that are going to be able to do that reconstruction or this is a backup so that you can attempt to pull the blobs from the the E in order to do the reconstruction of the columns uh to help help propagation for local block builders. It's not necessarily a a network optimiz a network bandwidth optimization. It's a column reconstruction uh backup for lo for local builders. Yeah. The point that I want to stress is that we shouldn't think of this as like uh that that we shouldn't think of this as like this is the worst case like uh sorry we should always think of the

worst case as the blobs not being available on on meool and we should be sure that the network still functions without but again like for for local block building like local builders are going to be pulling blobs from the from the public mint pool. So like those should have also been propagated to other people on the network as well. So the likelihood of like the the use case where it's really built for is backing up the publishing is for local building and for local building those are public meal blobs.

Is there an open thread in Discord where this conversation can continue just because we're at time? It seems like there's still a lot to say about it. Can I add one last thing here? Yeah. So like it the I think the assumption with local builder is that if the blobs arrive at their main pool it should be mostly arrived at majority of the like men pools like around the like all the I don't know in the world and in that case like somebody has definitely had all the blobs that local is trying to publish and can help with the propagation But yeah, like um if if you think this

needs further discussion, please feel free to maybe start a thread in the PA testing channel and we can hash this out. Great. Okay, thank you all. Thank you all. Bye. Thank you. Bye. Thank you. We're both