Distributed Block Building Call #0

Transcript

so it's become pretty clear that we need to think more about uh distributed block building in order to make sure that we can uh do like our upgrades with pias and what comes after smoothly and like at the same time um not harm self-builders who like currently I think like we agree that um we want to very strongly push to be able to keep them around uh because they um enhance our censorship resistance um so I think like some ideas have been floating around um for uh quite a while on this and like in a way it's like always been clear that this is possible like even when I first

published um uh my little summaries on uh thank sharding back two years ago like um I was trying to uh figure out how how this could work um but so far we haven't really put on the full um design engineering work and I think like um we should do that now so that we come up with a good scheme um we make the necessary changes to the interfaces and then like uh we actually like build it so that we won't have to worry about self Builders anymore um so I think like an important outcome of I guess the series of calls especially the first few

would be that we um try to decide um on a version uh of self-building um that we want to encourage I think like one thing that's definitely become very clear is as long as we're keeping the M pool around which I think like currently we have no uh no intention of changing then like we can use the M Pool um for like doing a lot of the work for self building I think um that part uh that part is obvious I think like the only part that's really missing right now in order to enable people to uh send the samples is to H have the proofs around as

well um and so there are a few different ideas like one way that has been discussed that I don't want to completely dismiss uh would be to um add the proofs to the transaction um itself um like create a new block action for y real quick sorry I'm not sure if you're actually screen sharing right now it's blank for me I am oh interesting it's blank yeah okay black screen uh I am but I haven't really started talking about what I'm sharing yet so okay um I guess let me try that again then to be clear we can see your screen like the

notifications and the Bottom bar we can't see the like what you're trying to show okay the middle makes sense right um cool so I was saying um let me

continue while I um reshare this um that um like we we can we can clearly add the proof to the transaction format um that would solve the problem for the most part um because then anyone who has transaction or who has the trans the mol transactions uh for uh the current block can always uh create the proofs for each uh column which is one sample um the downside that I see with that is that uh we now will tightly couple the transaction format um to our uh data availability layer and I think like I don't see that as a great option for the future because like we will um make more upgrades to this regularly and um it

just tends to be that transaction formats because they are not just in the clients but leak into the um leak into the application layer and leak into like obviously whoever creates the transactions um that's like it will be much harder to make upgrades in the future if we accept this um so uh one idea that I wanted to share um was a note that I wrote up last week can you see my screen now yeah perfect yes

okay um where um we do distributed uh uh computation of those proofs um and so the idea is this that we um create um an additional gossip subtopic um where any notes that want to participate in this uh can Goss up the sample proofs for transactions in the M um and um uh this is like not a huge overhead like the the proof size is about 6 kilobytes the way we've designed it right now so we're not talking about huge amounts of data given that the um samp the blobs themselves are 128 kilobytes um um and so uh basically any notes who

who sees um a a transactions M cool can can do this and then anyone can use this proofs this proofs um to create um a column sample like any node that had that is subscribed to um the gossip subtopic um for one uh sample which is one column uh can now just take um all the uh blops out of the M Pool Plus the proofs that has gossiped on this topic and um and it can um uh distribute um the sample plus proofs um for that so this is like truly distributed it doesn't really make any assumptions um about any noes like having um yeah like a whole network view

or anything like that but it does rely on that all the transactions are in the mle just like kind of like something we have to talk about in the future as well how we redesign the mle so the implementation would need that be like add the scup subtopic we would add a new endpoint to the execution um endpoint engine API that allows um the cl to pull for any new blobs and um then when we see a new new blob um we let each know decide on the Rand day after which we build a sample proof for the blob if it hasn't uh seen them on Gossip yet and all nodes can now participate in this uh temp proof

distribution by using the sample proofs from the gossip subtopic um so yeah I mean I think um this this is the first um item on the agenda so like I'm uh I guess I'm curious like um especially from the client team how they see the uh um how they see the difficulty in doing this is if there are any blockers um if we should go ahead with this proposal or if they they prefer another version uh portus do you have your hand up do

you want to say something I wanted to ask a naive question about the previous approach of like having the proofs on the transactions so I I understand that if this leaks into tooling this is a killer if the transaction itself needs to carry the proof but I don't understand what's the downside if you have by defa so you have a flag on full nodes that allows them to whenever they see a transaction to to import transactions without proofs and if they see a transaction without a proof attach it and gossip it with the proof so this way whomever sends a transaction from a wallet say metamask the metamask runner

the RPC server of that one would do that yeah and and and most transactions would come unless they're spam they're going to come already with the pro but I think like this has also been suggested so an alternative to this is um I think like if uh we we could even do this like ma mandatory where simply um the execution layer as soon as um it uh sees the blob transaction um like the inter pH stays the same but like the gossip changes so the gossip would now only be transactions with proofs um I think that's uh that's doable like

that wouldn't change the inter like the the way that applications construct transaction transactions so I guess that's an advantage um it does still leak the whole proof construction and verification into the execution layer so that's like one little thing that I don't like about it um but I guess like we should also discuss that as an alternative e

okay everyone's so quiet here so I I am curious how people think about this maybe like um everyone who has an opinion on this like should uh yeah Anar yeah just just briefly wanted to say on this that it does feel like the version where basically is attached on the on the E P2P layer already is to me somewhat simpler because it kind of travels together and you don't have to to think about these on separate layers so so so the main trade-off really seems to be the bleeding the comput proof computation into the E I would really like basically for specifically maybe for E people here on the call if if they could give some feedback on what extent

they would like how valuable would it be to try to keep the this kind of this piece of cryptography out of the E right because if it's important I think actually the you know your your proposal of this of of basically this more pure approach I think is is very sensible but if it turns out that maybe it just doesn't matter and it's fine to just have it lead into the E yeah then then I personally would prefer that that approach uh wait ano wasn't the whole point of not having it bleed into the e

is that it's an abstraction leak so I mean even if El's don't mind it being there isn't it just sort of a bad practice because E's don't care about the proofs well I mean they would care right because then in that sense they would care also because it's it's something they check as part of the the M propagation um but yeah there's also there's of course also two variants right there's the variant where the El just actually understands proofs and can generate them and verify them or there's the the version where the CL just exposes functionality for that and the L just

asks like talks with the CL back and forth I don't I don't op side we don't really have an API for to for asking the C to do something right that's one of the problem problems with we're facing with all of us that would be completely new yeah I guess it does seem a bit wrong if the CL the El is now needing to know about what this proof like having to verify the proofs as well like to me it seems like a CL specific uh concern

right yeah we have already done like one we have already committed a little bit that sin in that we have these um proofs that allow us to verify the blop data quickly um because we did want that in the M Pool um but yeah like I mean this would like would go much further and would like um tightly basically couple our proof format between el and cl and it's kind of like we're losing a lot of the abstraction right but I mean I could I can also take the other side on this right so like just spell out so if we basically try to prevent this and we go with with with with your proposal that means that now the proofs travel separately on the CL

side and so that means so I assume I mean maybe you can clarify I assume that they would not actually like no node would actually forward and Broad like broadcast these as they arrive they would basically wait to confirm that there's a corresponding valid transactions transaction in The Elmen pool um because otherwise you have this kind of this this this dos issue um but now B basically that means that you have this kind of weird like somewhat weird um tight coupling there basic now the CL basically has to like pull the e for um for meol updates and and then basically so those two things that conceptually belong together are not basically broadcast separately and but then always have to wait for each other um which I

think that's the cleanest you can do it I think I think this is the proposal is really clean but it's the cleanest you can do if you really want to keep it on the CL side right yeah at the cost of extra latency but I think like the question is does that latency matter that much because um most transactions will be like s well before um they need to be included so we have time but okay so then a question for example right like we are separately and we maybe talk about this later on the call but we also will will talk about like potential sharded meol design or something like this so now the E actually basically has logic that

defines which of their peers will be interested in in which transactions but but now this the proofs are are broadcast on the CL side which does not understand that logic so now basically you have this extra overhead where every note on the network will hear about every proof even though they are only interested in a subset so now all of a sudden the ratio of like datawise sizewise of um of proofs to blobs becomes less less favorable right so so this is kind of the the type of to me that's basically the the the other type of subraction leak where basically now the C and way becomes part of the meol some weird we weird way uh I guess my question is if we

could redesign from scratch like what would this perfect system look like um like would the CL just be Computing even the the current proofs that the Els are doing um because maybe we can take some short-term pain for the long-term benefits of where we eventually want to go right I mean I think like um like if we think about long term I

think the weird thing is that we have two like we have two this different um peer-to-peer networks right the El has an independent Network from the CL and that is basically just historic right like we could like if we had designed everything with the abstraction in mind that we want to separate the two then we would like have from the beginning had only one of the sides have a p to-peer network and the other would just be like feed of that peer-to-peer Network so I think like this is like kind of like maybe we should think that long term the the M Pool should actually be

in the CL because we should eventually just like um depade the old peer-to-peer network but I don't know like if we're ready to do that like right now there's still lots of things happening on the network um de line you want to say something sorry at the gy sorry for the noise uh in to will this strategy be viable that could we not have the requirement to GO PBS yes if we suceed in having this what so with PS would the requirement be to be to do PBS this is what we're trying

too okay okay yeah distributed block building tries to do it so that like you can still about block blocks at all Mar is you're saying there's one gigabyte of blob transactions in M what are they doing there why are they not being included they're just chilling there I have no idea I then so they're not paying enough fees yeah right how can you not pay enough fees if the minimum fee you have to pay right now is zero I don't know well probably the normal be fee not the L fee

yeah I mean that sounds like a problem if you get I mean that also doesn't that mean you could send a gigabyte of data to all nodes like and flood their peer to-peer connections yeah I think in general the you can you can you only ever advertise the hashes of these transactions and the nodes will fetch them themselves okay so the not decides to overload itself that's rate limited yeah and also we never announced them uh we only ever announce new ones we never announce the ones that we have in the

database right interesting it it by the way it used to be 10 gigabytes but I got um Peter down to one Gaby oh like as the size limit for the m is that the size I see interesting we were very proud that we could do 10 gigabytes so that's why we kept it to 10 gabt for for a long time but uh when when it came to the fog I was like this is it's not a sane limit

let's just do one gigabyte uh wait is pus is your hand up yeah I wanted to push slightly on this issue of uh if we were to design everything again we would have only one P2P and in fact we're we're trying to actually separate the even for syncing to separate the blocks like uh if if anything we would

want to have different layers to sync uh block consensus blocks on one side and execution blocks on the other side and the only reason we keep one inside of the other one today I mean to today this is an engineering problem that none of the layers are actually saving the full blocks and if we want to serve nodes we need to go through an API to get the payload assemble the blocks and serve them and we're actually trying to get rid of this so if anything we want to separate the P2P Stags even more right I'm not up to a date on that but like I mean originally I thought we wanted to eventually deprecate the P2P

is that not like something that we're aiming for in the long term anymore sry yeah I I think that's true but but I think uh still like what we're hoping to to do eventually is to to have like the El syncing on their side with dep it to be but again yeah so this is sort of like a side to to this meeting's discussion right okay so I guess like maybe we should do

a temperature check like if we have the two options where one uh we separate the two as I suggested my proposal um and um uh uh uh we basically keep a somewhat cleaner abstraction between the two layers but at the cost obviously of probably more latency um on like the proof propagation um and option two would be uh we just bite the bullet and like say no like um we we're just never going to have like abstraction on that the execution layer should just like uh produce and verify um the proofs um

which one would people prefer maybe like everyone can write that in the chat because like I do want to make progress on this and to me it's just not clear what like the uh what people's opinion on this is okay so to repeat sorry yeah go ahead

yeah one thing that I um I don't I don't particularly like either solution uh one thing or the problem that I see with your solution um of polling is um basically or usually the Deep transactions that make it into the block arri pretty late into the block so we usually mine the transactions uh uh the good paying transactions quite late but that's true for normal transactions not for blob transactions right I think that's true for all

transactions we could just say Okay blob transactions will not be mined after a certain time or something or we could say okay they might have might um have a uxix your X difference between plot transactions and noral transactions which is fine I mean you can also you can also accept that like the Builder does still have to compute some proofs locally and we just reduce it with this right so we can also accept that yeah yeah yeah so yeah my I mean also also remember like if if Builder build at time zero and they and like typically

nodes get this after one second or so they did have some extra time to compute the proofs as well I don't know if it's enough like yeah to get them andate them uh I think the the idea of of saying like having some call like give me the best 10 blob transactions that you have in your me pool and executing that at the same time as you build the or as you or be kind of before that like we could we could yeah kind of asked the the CL ask the El give me your 10 best transactions

um once the CL knows okay the last like I'm building on top of this or like this is my slot now and then we could uh the C could start Computing this while we uh prepare Block in the background and so it might just only need to like uh swap out one or two or like recompute one or two of the of the blob transactions proof yeah it makes sense to me right but what about option two you also had you said you don't like either

yeah the other one um the other one uh it will increase kind of the the so in all of these things we kind of like limited by the bandwidth right and so if we increase the bandwidth even more by sending all of these transactions um I think it will be worse for the network and there's no real limit on the number of block transactions that you send and yeah that's the one thing and then and then you kind of need to do the proving or verifying of the

proof um both on the CL and the um so you're spending these resources kind of twice um and every node needs to needs to verify the proof um um on every transaction that that arrives and um so kind of transaction transaction verification is one of the biggest things that we're spending CPU time on which is weird in my opinion um but um it's just uh we're spending a lot of time uh of our CPU time on verifying that these potential

transactions that might make it into the chain are valid looking or valid and if we add more time to that that's not great in my opinion right okay I mean this is actually something good to figure out what is the time to verify those proofs I don't have those numbers ready we should probably get those um we know how much it takes to compute but right now how much it takes to verify all of them is this in a batch or are you

verifying uh it it would be batch like it would be all proofs for one row wait was marus talking about 4844 or are he talking about 75 padas a verification it's padas like it's it's basically it's all the proofs for one row verifying all the proofs for one row that's what you have would have to do every time just just say he's going to look it up you have your hand up yeah just just to find out though right like because I

think the problem of every note would have to verify a proof um per blob transactions that transaction that that is to um no matter which approach we choose as long as basically um like basically both in kind of D's proposal and kind of the the the variant um if they travel throughout the entire network they have to be verified at every hop so if we think that is a problem in terms of CPU time and and everything um and we also think that just the Builder Computing them is also a problem because of delay for propagation um I mean the only third option we we would then have to investigate would be some some sort of

more complicated setup with where the Builder basically finds someone directly in their in their neighborhood some individual kind of note that is willing to do that for them or some or like something like you know the relay offering a service like that or something but then there would be a very different third type of of solutions here right if if we if we consider all both other if we come to the conclusion that because of the computation time both other Solutions are um unacceptable then really we kind of running a bit out of options for Solutions here well with my proposal the advantage would be that uh you could make it optional like you can choose just not to be part of that topic um but but then how do you actually so you You' still basically

forward the mle transactions if you see them even if if us doesn't have the the proof to them I guess say come again yeah no I was just wondering basically then you just accept that some some not basically only forward the transactions on the mol side without ever having seen the the proof okay that that actually is an interesting interesting tradeoff uh okay Chaba where where did you get

that number uh it was the verifi proof in The Benchmark on a on a p call if I remember correctly okay yeah that's a lot yeah but let me just double check okay we need to verify that because that might that might preclude certain options if we know that that's true then maybe it just doesn't make sense to like um add all the proofs well but like I mean we already

have to do this anyway after the block creation right so so basically you know once we once we distribute um samples the sample proofs also have to be verified I mean of course there's somewhat different different rest structured and you you only see a portion of the data and a portion of the proofs but if that is something you have to be able to do in reasonable time and like long term with with mle charting and everything we will probably have a similar portion of basically like any noted Network will'll probably see a similar portion of the overall data first travel through the M Pool and then return back in the in the block propagation step and so if you have to be able to basically spend the time to verify

one then you should also be able to do on the other or or or there like specific dos concerns because it's it's free to send transactions that fail that verification step okay Justin says it's 17 milliseconds but I think the 17 was of frequencies which is not it's okay if you doing only that but once your CP is doing this and that you don't get those all that's how I remember Marius is 17 milliseconds for for verifying a transaction is that crazy or is that

possible I think that's crazy like right right now right now at the at the boot notes we get roughly 5,000 transactions per second that arve there 5,000 transactions per second yes wait but like I mean most of these can never be included yes most of them are not included also they what what are these transactions do meth those what those are numbers from from when like the math uh when the meth wars were were still happening on chain so it might be less

now but at the peak it was roughly this and so if we spent uh 170 milliseconds on verifying each one of them and of course they were well that's that's that's only blob transaction I don't know how many blob transactions arrive at a note uh per second right can't be that many I mean we could in any case like rate limit them way way way way way more than that like you know even if we scale much more the target is going to be like 64 block transactions per slot 128 block transaction per slot so at most on the mle you should see like T per second or something or like

it should be Rel limited to be at most T per second yes yes we should maybe see one order of magnitude more than what we see on or what we can include in a block that's what I would guess do we have data on let's say these same boot nodes how many blob transactions they're seeing these days um I can see but I don't think we have

the metric for okay okay so my expectation was always that most transactions that make it into the M Pool will make it on chain like otherwise like shouldn't be we would just be more aggressive on filtering transactions in the menol and not let them in if they aren't paying enough I guess transactions can be replaced but don't we limit that as well and only allow it if like there's a significant increase in fee yes we need a 10% increase in normal

transactions and 100% increase in BL transactions to replace um so my mental model is there shouldn't be really much more transactions than are included on chain like so I expect if we have say 16 blops per block that there should be 16 blops per slot in a m I think that's true for normal nodes I think the issue with these boot nodes is everyone's kind of hammering them because they very well connected in the network I see okay I think this is like an important

new um uh discussion point so I guess we should we should uh definitely because that was also like something I mean we did add the the proofs like I do remember we had this discussion um a couple of years ago where like um we were uh discussing the blob transaction format and like without the additional proof that we put in there there the verifying that the commitment was correct took about 30 milliseconds or something um and I do remember saying oh that's really bad and that's why we added the proof so I do wonder if we should uh if if if this is enough to say that

that solution is just not going to fly if every node now has to verify this for transaction well I don't know is that too much like let's say it's 10 transactions so we're adding like 200 milliseconds or so in verification time it doesn't sound that crazy to but I am curious like what is the main argument that this is too much per transaction mares uh sorry what was the question my question is like I I am surprised that we're saying like this uh 17 milliseconds per transaction

would be like a huge uh killer well I assume those benchmarks is like not on One Core it's like the whole oh that's a good question is on One Core so the the 30 millisecond is on One Core not running on running on normal frequency not so not a not on a to frequency yeah yeah this is Task set to to one performance of 12 generation okay uh but the yeah I think to to meain the main main questions are what are kind of the filters on the transaction so so one filter point is is

clearly when it gets to the block and if you are doing proofs only after that that's we understand that quite well but whenever proofs are generated on on transactions before they are getting to the block what is the filter that we have there and I've seen some filters put in here in the discussions like how it's related to the base F Etc but but we don't have a clear filter before that so you might have to calculate in a lot of transactions that just feels a bit undefined at that level so we kind of have multiple filter steps

right like we're checking we're checking the signature we're checking like all of the basic stuff um and then we we're starting with the heavy checks and the heavy checks are looking up the nons um that is already really heavy and uh then we need to verify the uh The Blob uh the the commitment to The Blob um The Blob proof and then the question is like if and now we would need to verify this proof then the question is if the blob proof is correct and this is a

correct transaction just sent with a wrong proof what would happen there would we need to compute the proof ourselves and then send uh transactions just drop it yeah I think I think the problem is not the when it fails the proof it's it's too many transactions which are passing passing the all your tests oh but yeah I mean this I guess that's an interesting question like I guess like Mario is saying if we like that we could have a Dos Vector where you send this transaction um but with incorrect proofs okay yeah I see and then and now

like now it would mean that you can't um yeah but like anyone could now create those proofs and resent that transaction and it would be a correct transaction but I guess if nobody's doing it then yeah sorry like are you saying if there is a normal transaction like a good transaction let's say it's not the sender that is putting a bad proof it's just someone is taking a transaction attaching a bad proof to

it no um I guess that's also possible but I mean it doesn't matter because you would still get the real transaction eventually I don't know uh no I'm more talking about the situation where someone the sender sends a um sends the transaction already with a bad proof attached because yeah just in order to like make everyone waste some computation time but I mean in this case can you just disconnect any Pier that sends you such a transaction because it's it's provable that I mean they should have verified it and right right right yeah go yeah I was just wondering basically a

variant of this what if we just do the stupid thing and basically allow transaction send us I mean again we would have to decide whether it's part of the transaction format I don't I think probably not that but just basically some some some optional side thing that you can attach to the transaction but that is signed by the sender um basically for proof and then you just don't verify it you just ignore it you you send it with uh on on on the M Pool and then it's it's basically just a hint for the Builder and then only the Builder before before B production verifies it um and if it's wrong you know too bad you just ignore it um and if it's right you use it and so basically that means the game theory is just if you want to make sure that even

if the next Builder is a is a weak local Builder and you still want to be included as soon as possible you attach a proof because why not um and if you don't care you don't and so basically that way we don't waste people's time with with verification but people will still be incentivized to do the the right thing and and and the failure mode is very harmless right uh it would have to be signed though right so that nobody not someone else can't simply attach um like incorrect proofs and make it fair yeah yeah yeah so that's one extra verification by assuming Norm signature verification is much less overhead compute

wise how do we do we have this at them moment to is the is the rapper um signed in the current blob transactions it's not right so that would be a major change so I guess given that we only have seven

minutes left do we want to try to Define next steps or how do we make U yeah progress on the decision here yeah I mean we kind we kind of not really decided between the two yet I see a uh weak majority for uh for option two I think um sorry where is it can't see it anymore [Music] um I guess I don't know if that's still

the case with the with the information of that time it takes to verify I'm not currently not completely sure if that's going to work I guess like um maybe given this week majority maybe we should just specify this first and see what it looks like and then see if client teams can work with that um I don't know I can I can um have a go at that uh that sounds good but how do we address the um verification issue that Marius mentioned is there do you have any steps to sort of solve this or figure out if it's a problem okay PTO seems to integrate okay

do we want to another have another quick roote see if it changed I'm going to post option one and option two again in the chat and we see we just talking about how to structure the API calls basically so I don't see why like the performance will be the performance regardless of where it lives right yes um the the advantage of my option is that you can like that not everyone has to participate so if it's a problem for anyone that the CPU that this users um it would be uh they could just not subscribe to

that gossip St I agree with your point that it's like less clean on this Ultra Pier question but it's not still not an ultra Pier like it doesn't it doesn't require anyone to subscribe to um all uh uh All sample topics for example okay and so option one here is saying some sort of pulling architecture where the C is getting Bobs from impo

and can proofs okay Y and then that would still be to gossip them or I guess that's what was confused about if we're talking about your gossip proposal or just how we're actually structuring this we're still gossiping yes so we're gossiping and then like when the when you receive a block now anyone with um with the proofs um is able to create for their particular columns um the complete proof at like very low cost because they have the proofs anyway from goet

all right given that Ana says this um should we uh maybe like we need someone to champion each option and like think further about this like I'm happy to keep working on option one and think about um all the things does anyone want to take the take option to and like basically uh think about how it would work and if and what the what the mitigation for for that uh for the computation is this

okay great we have Ana as a champion for option two cool um okay I think we're almost at time any any other comments on this does anyone want to bring up any other concerns or ideas are we generally like going in this direction do this to everyone feel the right direction getting rid of the um the previous Ultra Pier

ideas um which is basically what this is would anyone rather go back to what to our previous designs I guess I did have a question like we still discussing because I think where this originally came from was just the fact that it was taking too long to make the proofs during building um so even aside from like having some other peer compute the proofs do we want to explore designs that would pipeline this a bit better just so that you know you could imagine building locally yourself in any case um what what do you mean by that I

mean doing the building yourself is always is always an option right you can always just like I mean you might as well after you've sent your block compute the proofs and send them in case nobody else has done it okay so I feel like there's there I mean part is just to like add some redundency the gossip part is to reduce the latency on this so that like the proofs are already ready um you don't need to compute them so this also helps like even if you're like even if you are a self Builder and want to distribute them all yourself this also helps you with proof

computation because you can just listen on that gossip Channel and just be like okay I have all the proofs so I don't need to the computation locally only the distribution one thing that I worry a bit about is like uh so we said 6 kilobytes for the 12 um of a blob but then you had the gossip Riverhead and compared which we wouldn't really have in the uh y cuz it the mle is pool based and it ends just I don't know it ends up being like a much bigger bandwidth Factor um right so we're saying we get a factor of six right so would be 36 kilobytes well but the nice thing at

least is now if only basically more powerful nodes opt into this gossip uh into the Subnet in the first place right those are probably I mean assume we would assume that there's some amount of correlation between nodes that have extra CPU to spare and extra bandwidth to spare right so so maybe that kind of just works out but like you also need proposers to like I mean the whole thing is for local blog buildings so generally you do want people to at least when they're proposing be able to subscribe yeah I mean if we had worried more about average uh bandwidth and Peak bandwidth then you could simply like subscribe to

it whenever you're building the block right well and for basically the concerns about Peak bandwidth and then the Builder bandwidth specifically that really is something we have to discuss in the context of the meem pool in general right because I mean at least for now we still assume that the Builder has to have all the blobs local anyway for those transactions they're about to include so that's that then yeah basically already that causes big challenges right okay cool I think um oh PTO you

something no I I'll ask you off I'll ask you after Okay cool so we're over time uh thanks everyone for the call and I think that was at least helpful in terms of knowing like uh what we're doing next um hopefully like on the basis of more detailed proposals we will be able to make uh a better more progress next time and um hopefully have a decision but yeah thanks everyone for joining byebye thanks care bye thank you bye thank you