Distributed Block Building Call #1

Transcript

was uh yeah put couple just a couple of things on the agenda was basically uh just to follow up a couple of the things that we discussed at um um this Monday session I think on the L1 or in the second day um yeah mainly basically the question of more immediate question of um the where the proofs should go and whether or not we we actually want to go through with what we discussed there which was adding the proofs to the transactions in the in the mle and and like some other details of how precisely uh they should work uh yeah and kind of I guess this is on the more practical

side like basically maybe just agreeing on concrete steps of um yeah where where should we go from there if this is what we want to do like what do we need to do is there any blockers and so on and so forth and then uh yeah the other question was more like speculative I guess and yeah more of a kind of uh yeah possibly relevant to fusaka but like um not I guess really as um immediately important to to like do something concrete about uh yeah basically just discuss this question of hello uh of colum versus Cell propagation um yeah I don't know do we

is there any preference does anyone have any preference on where to start from um or dun you want to um also say if you specifically have other ideas and yeah other things that we could talk about other than what I put in the agenda uh or should I just start with one of these topics and go from there hello can you hear me uh yeah yeah ah good okay sorry that's we're getting this to work

um sorry I missed what you what you already said Francesco did you introd yeah so uh yeah I was just basically saying I I put in the edge on the two things like kind of follow up on the last session of De inde D like one is this um question of um do we want to proof in the transaction which is sort of what we ended up mostly agreeing on at R&D and yeah just kind of discuss that further and then this other question I just mentioned you also of uh columns versus sell propagation and uh yeah I have this small Doc and I can kind of go over uh some some thoughts and then I don't know if you have something else that we should discuss um no I think I was just mainly going to go

over I think like the things from uh what we discuss in Vienna so like the um vertical versus um horizontal uh charting in the men pool uh then I think um I think your your um idea of uh using cells makes sense so I think like it would be great if you present that as well um yeah yeah I mean if you maybe maybe if you want to go ahead and start with the um J think let's just go from there cool

Okay cool so um uh like um in actually quite quite a while ago now in September um we had a workshop in uh Vienna and um we're like talking about distri block uh block construction um and especially how that would work with blobs and um and uh we try to like um go through everything from a bit more from first principles and um uh so we we we wanted to like look at how how everything works together um

first how how do we have a charlot man pool second how do we get this BL construction and then also how everything fits with inclusion lists which are also like an important feature of a future design um and um and I think like one of the big question in the past had always been like do we want a horizontally or a vertically shed memory pool so horizontally charot man pool um looks like this you basically have a um uh you have um different blob transactions being in different M Pools indicated by the different shades of gray here and then um and then their

blobs um would would basically be in one piece in that men pool and each note only listens to some subset of those M Pools um and in contrast the vertically shed men pool um looks like this you have all the blob transactions in the same M like everyone still knows about other blob transactions but we split up the blobs so that they are now like basically um split up into pieces um just uh basically how we how we do it for data will be something and uh and everyone only like sees a subset

of the blocks and um yeah basically I think like for a long time we thought oh like horizontally sounds much easier let's just do this like um it's like there's no huge changes other than that we like have to subdivide um the M Pool um like we have to split up the transactions somehow like we can do that for example by sender addresses or something um that seems doable um but there is basically uh there's one big problem with it which is um we can't really figure out a way in which a Blog Builder who doesn't listen to all those M Pools

knows which which blob transactions they can include uh so it's quite um yeah it's quite tricky to know um if you can include block transactions whereas like the vertically um shot M pool at least gives you some indication like you can basically look at the samples that you listen to and in that way um you can figure out um which transactions are likely to be included it's not perfect because um sampling doesn't give you perfect like certainty and that um um creates like separate challenges but it is like much better

than knowing nothing um the second thing is um when you when you start thinking about okay like the second thing with distributed block building what you want is that you can somehow um put these samples onto the sampling channels right so we have we have the in padas we have the subnets for data resampling and um and we basically need uh need to transfer whatever our charot man looks like into these subnets and now if you do that in the horizontally sh at mol uh well like it's kind of it's very there's quite a poor alignment between

the two because like um you one have like some manool that you listen to and you have some um and you have some uh sampling subance that you list listen to and basically only only on at those points where there's an overlap basically where they cross can you contribute um you to distributed block building whereas um in a vertically shot mol the alignment is perfect so you can just say the um your samples for the block and your samples for the transactions are the same so that means that everyone who does listen to the men pool which doesn't have to be everyone um but everyone who does listen to the

me would already have all the samples from transactions that are in the m so that's pretty elegant um it's actually like a double saving like basically it means that um in the case where you only include transactions from the M Pool um everyone who listens to the M Pool already has all their samples so that's like basically As Good As It Gets um and uh and like those that don't listen to the M Pool or for some reason like Mr transaction only have to be like filled in like um a very small number of samples um so I think like Franchesco just had an idea so he'll come to that later which I think is like also like a

very good extension of this um right so this is like basically the reason why at least like as a final goal it seems much better to do the vertically chart meal there is one problem with it though um that makes it a bit more difficult which is that um if you like you basically have this problem that um uh you have this chicken and act problem like if you you have like one piece are the transactions and the other piece are the samples and uh and like you can

always as like as an attacker who wants to dos the mol um just provide one of the things like basically you can like send some samples but don't send any transactions so you get like you get to spam the network but like there's no transactions so nothing happens and like um uh or you can do do it the other way around and um and both of these are annoying and uh there's no like like in the traditional M Pool um we have like some protection against this because any transactions that's propagated in the mol uh can also be included so there's at least some like Hazard for that attacker that they might have to pay

because the transaction just gets included and we don't have that guarantee here and if you try to get that guarantee for example you could say oh I only Pro propagate transactions and samples when I have all the transactions and all the samples this doesn't work because you basically like um two nodes two neighboring nodes don't don't necessarily or are very unlikely actually to have the same samples so basically you would like make make the propagation imposs if you had this very hard requirement and so um the way we figured out how you could do that is um if you basically restrict who can post um transactions in

the M Pool and it turns out there are there there is a rule that basically um would um would like provide very little downside um and and still like probably like allow us to protect the M Pool from dos if we like basically um can limit the number address that can send transaction on this M Pool so the idea is that you basically um only allow those addresses that have already created some number of blob transactions over the last week to send new ones so since rollups most of the time it's always the same addresses that send the transactions any rollup

would like basically uh yeah be free to just keep transa keep um creating blob transactions because like they are always in the set of trans in the set of addresses that have created blob transactions over the last like day or week yeah depends what we want to do here and then like this of course creates the problem how do you how do you enter a new address into the pool I guess like you could obviously always do that that by um bypassing the manool and just like using flashboards protect or something to get a transaction in but like if we want to be super purist and make sure that like everything can be done through the M Pool we can also just say you can like burn a small amount of ether to enter the set um and it doesn't

have to be very much like say 0.01 ether and then like um you also enter this eligible pool of addresses that can send um that can uh can send these uh transactions and um and samples and so the um why this works is basically like uh you now have like a finite number of addresses like some thousands of addresses that can send them and basically as soon as as one of these addresses does something bad like for example uh intentionally seems to send only transactions or only samples or seems to be like sending some samples and some transactions that don't match then you can just um Blacklist them and

stop them from from doing this and um yeah the M can basically be protected um but yeah this is this is the main downside um of the vertically shoted mol but like everything else like is um aligns very [Music] um in terms of how you use this for distributed block building so um one like the the most naive way would be you just use your your local um information your local sampling as a

note to determine whether transaction is available and then you includ include that blob and um or the blob transaction and others will fill in the samples so unfortunately when you have many blobs this is not good enough because like using local information you can for example determine oh there's a 95% probability um that a blob is available but like the problem is if you have if you include 10 blobs and they're only 95% available then you're already at almost 50% that one of the blobs is unavailable so like this is like um uh this makes it uh relatively easy for someone to like um dos you in terms of U

making you create a block um that doesn't uh uh that doesn't have enough um or that does have an unavailable block um and so like uh you do need to um to use some additional mechanism um to determine the availability of a blob um so um I think like um I think like Franchesco in the inclusion lists will will come to one of these um that basically uh you can use um voting even with a relatively small

number of votes to basically find out that others like also agree that a blob is available and then you can safely include it um yeah I think like this is the summary of what we found on charlot man pools um happy to take uh any questions otherwise I'll hand it to Franchesco uh I just wanted to ask about it wasn't clear to me when you was saying about this

percentages was the model heal about the local view so what was was the difference between blops I'm seeing I'm seeing a number of blops uh what's the difference here once from another when you so basically sampling um like for example if I yeah like if if I sample a certain number um uh like of samples then I only get a certain probability that a blop is available right I don't get 100% unless I take 50% % of the samples okay so it's it's so are in the model that we are

getting a few based on the on the on the on the split on the was that vertical split hasn't split anyway B on columns and then we are sampling into it into the ones that would be selected or so everyone basically like basically the idea of the vertically sh mempo would be that like I use the same uh samples that I will sample for the whole block and uh sample the blobs according to that from the trans from the shattered transactions does it make

sense and then I would on every blob I would get individual results yes so on while on every blob you get a result like whether you get all the samples or not um and uh and so that gives you some indication locally if that if there that blob is um available okay and the probabilties the statement was that even if I would have like all your sampling succeeds on all the BLS that you would be willing to include then you would still not be true enough or if all the temping

succeeds well yeah I was just yeah maybe I don't have the menal model yet so all the sampling the problem is basically um like well depends on the number of samples let say you do something um four samples for for Block right okay so this would be relatively low but like then you have like 2 to Theus 4 like each like I I can send transactions where like where like less than 50% of the samples um are available or like just under 50% um and with two to Theus 4 you will individually see those as a value right okay

so um now the problem is like let's say you do that for 10 transactions yep now and and each of them you do like a different random subset right so each of them has a chance of tripping you into thinking it's avable independently yeah yeah um and so uh basically like the probabil just like um add up and yeah yeah I know that's good okay hey cool

um Franchesco do you want to go ahead uh yeah I guess before moving on um while we're on the topic let me just say like just a couple of words on these other uh related approach um I think I already put it in the chat but uh here it is again yeah so it's basically I think I don't remember maybe I already mentioned this story in LD Workshop but anyway the the basically the point is kind of starting from the same set of ideas around um vertically Sharden mol but trying to think of like a different way to

to basically regulate what what can come in and uh basically part of the ideas is just to really have like a strong guarantee of you can only have these many things uh going through the mpol and yeah basically the the document kind of just talks about the idea block tickets which is you could really auction off in some way um and like I'm talking about a specific way to do this as well but it's really one out of I don't know very many that you could try to approach this problem uh but yeah auction off basically the right to send a blob in the M poool but not only sending a blob in the M Pool but also uh then actually getting that blob included like you you would only be able to get a blob

included if you own a ticket uh correspond basically um and the idea of why you would want to couple these two things like mle access and inclusion for me was basically that um if you only try to auction off the this mle slots um you would I mean in some sense mle AIS is is kind of it's not very valuable by itself um you could always try to bypass it if it is bypassable like you could just go through a builder and uh yeah so the default State should be that um basically l2s just don't go through the mle they just send directly to

builders and so yeah basically trying to avoid that is why there's this like coupling of uh I mean you you could still avoid the mle but the thing is once you've already paid for for inclusion like you have to buy this ticket you kind of might as well use the mle like it doesn't cost you anything extra as opposed to really needing to buy the ticket for the mle and uh yeah it also just generally makes it harder to like basically prevent usage of the mol to people that actually want to use it because then you actually need to pay for the tickets and for inclusion um which like it only makes sense for you to do if you actually have blobs that you want to get included and so yeah basically this kind of talks about uh how this would be structured and uh a

bit about the auction and but a lot about the um what do you do with the tickets in the mle like the kind of how the gossip topics could be structured um and and things like that um but yeah other than that I mean once you have these tickets like then it's all quite similar to kind of what dun was describing just in the specific setting of like a CL based mempo um yeah I don't think it's worth going into the the details too much just kind of wanted to flag it as like a related but slightly different approach uh and then you can look at the post I guess um and then yeah if there's no questions on this um which okay I guess I'll wait like a

few seconds in case there are um but yeah if not I I would move to um this first question that I put on the agenda which is like so to recap like kind of what we discussed in the uh breakout at the L1 or in D like one of the things and this is a document where I um took some not notes on on what we discussed so this is the first point there uh which was basically uh something that was really a question coming from the previous distributed block building call uh which was where should the proofs live and like it's um oh uh I didn't really want to share the

screen I mean I can do it but sure I'll share the screen uh okay do you see this uh Breakout notes yep okay um yeah so I mean this is the the kind of point that I would go over uh now like basically yeah the the question that was um that came up at the in the previous call was like where should these proofs live uh I mean right now they uh would be sent uh just along the the column side cars um and specifically in context of distributed

block building the issue that they present is that You' have to compute them um once you like you get the block and now you want to kind of construct the the column Associated to it now you have to compute the proofs or you could precompute them as well so that was I guess one of the approaches um and also just in general I guess even even not in the setting of distributed block building but just regular block building you basically have to do this computation or pre-computation um as you're doing the building and and I mean it's not it's you know nothing like incredibly prohibitive but like it felt like it's a an extra challenge to putting in in the actual like critical path of building especially in the context of like distributive Bo building where it's

really um you know a bit even more um time sensitive and yeah so it felt like it's something that really should be put on the transaction senders instead um like it really can happen in this kind of distributed like non-time critical um part of the the pipeline um and so yeah the specific proposal that we discussed in the L1 R&D um was this one where basically transaction senders compute the sell proofs and then they just add them to the network rapper for for blob transactions in the Y Man pool um so yeah this like in terms of like added bandwidth is is not that much it's just these like extra few

kilobytes and uh so some other times that this has been discussed the idea was like you would also send the block The Blob U extended uh so like you also precompute the or like compute the extension and just send like this full extended blob so that you can then have all the proofs and do the full verification um so one thing that was different here is basically saying let's not do this so that you don't double the size of what you're sending in the mle but let's just compute the extension um so this would happen like at the level of you send a transaction to someone they would immed immediately then compute this exential locally like the yel would would need to do this uh and yeah part of the why is just that it's

just fast compute but it's a lot of bandwidth to to send it and then yes basically once you receive it you do this computation and then you you would immediately verify all of the proofs because you get all of the proofs not not just uh um not yeah like the proofs for the the whole extended blobs and you would actually do this before forwarding so that it's um yeah there's no kind of weirdness around unverified um things that that you're forwarding um yeah and basically I mean at least in the previous um in this session the L1 Workshop there wasn't really much of um any points raised against this so I guess one question

here is like um with some time since the first time that we discussed this is there are there other things that we should you know be concerned with the that we didn't think about last time uh and then the second question is like assuming that this is not the case then where do we go from here uh I mean I guess some of the things that are not right now in place is that you would have to do proof verification on the on the yel um which I guess that's that's not something that El do right now and um yeah I mean just generally like do these changes in the in the kind of um yell mol um yeah like putting the proofs in the in the rapper like C Etc but yeah I guess just wondering now like um what

are things that we should yeah are there things that that you know that that we need to discuss is something that we can kind of just go ahead and do um yeah basically like where do we go from here um so yeah I don't know if anyone has any any thoughts here um or concerns or I mean anything okay um sounds good to at least one person um what was the proof verification

time ah right yeah I didn't talk about that yeah it's uh so this is this is 16 milliseconds so yeah one thing that we talked about in the I mean and okay I guess this is on some specific machine which I don't know you can check the the benchmarks here I guess I don't remember what machine it is and the benchmarks are also old but I think this might be reasonably up to date um which one is this it's probably an apple M1 CPU okay all right then that's it um but yeah like so one one of the things here that we was concerning last time that we

talked about this in the previous call was like oh this is too long for transaction propagation um but then yeah talking about it again with uh Maris and Peter and I think also at the session just uh this doesn't really apply quite in the same way because of two reasons like one is just that we don't have that many blob transactions going around in the mempool so it's not the same thing as the regular transaction pool um and yeah also just the BL transactions are heavy and so these extra kind of verification loads doesn't really uh I mean relative to like the fact that already like take a while to send it doesn't really um tip the scale too much so yeah this kind of seem to be like an okay number uh even I guess with with this extra thing of extending the The

Blob um I I think that the two things to consider that one is the the actual delay kind of St and forward delay that you're adding and I don't think that's a I mean in the Mur that shouldn't be a problem if you have five I I don't know how what hop count we have usually but if you have let's say five hops we are adding 100 millisecond to the to the whole thing so it's uh I don't think we go much Beyond five Ops on that so it's just the delay itself is not a problem and then that is the the overall computational cost that we are adding to the to the Ys which are suffering or whatever and and

that's maybe to think of what's there and what can go wrong there if there are many blops in the M Pool for one reason another um yeah Ian we have to treat these totally different than kind of we do today because 16 milliseconds is on a very fast processor I think realistically it's probably closer to 40 for a lot of people yeah but he we have to treat them differently as in like um have more rate limiting blobs in a mle or or I think we just have to be very

cognizant about accepting blobs into the blob pool maybe even more so than we already are today because the verification is like on the same order as it takes to propagate The Blob to the peers and that's just like for one so if we have to do this this is for every blob in a transaction might have to do this several several blobs yeah I mean actually if you have multiple blobs I guess it's better because you can do even more batch verification um but yeah you could batch the verification across the blobs I think so okay yes you should be able to

do that yeah so there all these kind of strategies of of batching and so delaying batching and and amortizing uh which helps in general but still I what I would like to understand is whether the kind of the over CPU consumption that we adding can can hurt how many Bops can be coming in not too many I suppose I mean not too many right now but if we have pios like what what is the expected blob per block Target that will be

looking for okay yeah but but so that that's one point is is was the kind of drut and then after those which are going the block but then this is the M Pool still right so it's uh gated to some extent based on this previous document but still you can have blobs which are not just not making it and those are also adding CPU cross everywhere so yeah but if we would have 100 blops you would burn your CPU for 1.6 seconds uh just for this

I mean with 100 blobs like we would almost definitely not be doing all of this or like regular nodes would not be doing all of this you'd only um I guess I don't know if you do you mean 100 blobs in a mol or 100 blobs as like in general um but either way I think it's like we should not be getting to having 100 blobs in the M poool um unless we are close-ish to 100 blobs Target um like it's really yeah I mean I think the mle has to be quite strict with blobs that there cannot be a lot more blobs going around than actually land on chain um so yeah I think I mean in the short term you before Pier dust I guess the blob counts we be dealing with is

like maybe 10 15 or something in the mle per slot or something like that um after that maybe higher but eventually with some form of sharding and this form of sharding I guess if we go the that we were kind of discussing with dun before should involve some more explicit um constraining on the mol like on what can enter the meole also that many blobs you could potentially paralyze this in some way so like across four or eight cores you could do like multiple batch verifications at the same time yeah that's what I just wanted to understand the the kind of the the single core CPU

time that you are burning on this and then you can the more course you have you still use the power but uh but you you have the Z yeah but I don't think it it's like with the with a number of 10 10 blobs this shouldn't be a a big burn CPU yeah and I guess the other thing is like the more dense blobs are in in coming in like like basically the more blobs per second you get the more batching you can do without actually slowing down propagation so that that's also and that that's not just using like multiple cores like you can parize but you can also batch and that's just like kind of a pure saving um so yeah I guess things are not quite as bad um even at

higher block counts yeah I see I see the compromises so we are in the mindset of basically every blob which is coming into the M Pool is is going to the block right that's the kind kind of the mindset that might not be true if that's the mindset we are burning thep here or burning it later uh is just a question of actually we are better burning it here because we have more time here so you can do more batching and you can amortize more so until that's true that the manool is basically full of blops so sooner or later the blops on the mol will be on

chain um he would basically burn the same CPU then but even more I mean I guess by default right now you still then eventually do the same verification on the C but um in like I guess in a different format you'd be verifying columns instead of blobs but still you you replicate the same effort but um yeah we could try to limit that yeah there's two that that because of the the client division you you would just replicate it once small uh but I mean still I mean if if we can burn it on one side we can burn it on the other side I mean CPUs are it's not like one can be an order of magnitude

bigger than the other uh is is the same except if if for some reason that can be a bunch of blobs which are not making into the chain yeah so actually this like um kind of mle sampling post that I mentioned blob TI like part of the idea is really this like to make sure that there is an equivalence between what goes on chain and and what goes in the mle and so there is no kind of uh yeah there's no wasted effort um for things that don't end up on chain and also do not replicate the effort like just saying that you only do things like you only do sampling you only do

verification you only do propagation in the mle uh and then you don't have to do it again like there's no um there's no then separ kind of path to propagate columns afterwards it's just you know the mle sampling SL propagation is the path basically but like yeah this is all kind of more speculative and more like research land I guess and the um yeah then the more concrete thing um so okay I guess m yeah I guess with this we at it sounds reasonable but like should

be I don't know maybe like investigate a bit um the the kind of resource usage for for per verification and like possibility of batching that that at different blob counts and things like that um and I guess generally I mean this is independent of this but like we should uh I guess think more care about what does in the short term like the next year or uh you know however long until we have these different ways of thinking about the mle like what does the uh relationship between blobs in the mle and blobs on chain look like um even like with an adversarial mindset and like what can we do to kind of improve that and like have better um worst case

guarantees on that I guess I don't know if there's anything else to say on this for now um did uh for this proposal is it like what is the relation with blob tickets or any of these ideas about like creating a system for accepting the pool transactions is it separate so I guess it's separate in in the sense that yeah like with vertically shed mle for one thing you would have the uh

extension necessarily be part of the mle because you already want to be doing sampling in the mle so you yeah there wouldn't be such a thing as like you cannot save save the cost of sending extension because you're you're not just sending a blob you're really sending like all of the samples kind of separately um so that's one thing I guess this aspect just does not apply to to like a vertically sh M Pool um yeah and I mean I guess the yeah the aspect of like um proofs being computed at the transaction Center level that does apply like you would be sending as a transaction sender uh samples with proofs so you necessarily have to to do the computation yourself to be able to

send something um so yeah that's kind of the relationship I guess it's not super relevant as in like this is not a step towards that uh I I guess this aspect of like proof verification be done at the center level level does apply to both but uh I guess in my mind this is more like to me this seems like possibly the right way for things to work uh in the current uh M poool uh and especially with respect to distributed block building like it seems to me like it's it would be better if proof ver sorry proof computation wasn't um wasn't done in in in this like path of distribut block building um and this seems to me preferable to like pre-computation but uh yeah yeah it's

not like it's not so much of a um trying to make a step towards something else it's more just like maybe this this is a good way to do things for now okay yeah if we have exhausted this topic for now at least um yeah we can keep these things in mind and uh quickly just wanted to can you still see my screen yeah seems like it um yeah basically maybe quickly go over this uh Cells versus column gossip um thing that we also talked about at del1 R&D so the

point that was raised was basically um it would be nice maybe for distributor block building to have the ability to to not only gossip full columns but cells uh because basically if you can only gossip full columns you need all of the blobs in order to to make any meaningful cont or like any contribution at all to to this like distributed block building process like if you don't have all of the blobs you cannot construct a column um if you have just one like it doesn't let you do anything and so if you could instead uh Gossip individual cells um you could even if you have you know one blob two blobs three blobs however many you can gossip the cells corresponding to those in the in the topics that you're in um

so so yeah I mean one question I had generally speaking is like sure this sounds nice but then in practice does it actually make the system perform better or like meaningfully more robust and like it's not entirely clear to me that that that's the case um but yeah and I guess just my thinking is like in practice um it's going to be it's most mostly going to be like nodes with high a bit higher bandwidth that uh really end up like you know meaningfully contributing to distributive block building um and they're probably going to have all the blobs so yeah that's one quite especially in the short term like when

we're not talking about you know crazy um blob counts but yeah so that's that's kind of one question is like is this worth doing particularly like in in fusaka let's say like if you really were talking about this as as like a you know we want to change the the current per dop uh since we have more time um so yeah that's one question and then and the other question is like how exactly we should do it so one design that I thought about is this like basically having the same um kind of um gossip topics as today uh like basically like column gossip topics but where like you now don't gossip uh full column but individual cells and like a cell basically just looks like the same as a

column today except that it has like only a single cell and a single proof um and um it has basically this so I mean there's many ways you could do this but playing around with it a bit like this was the one that made more sense to me uh basically to have uh this like kzg commitment side car that's something that basically it's it's it's corresponds to the sort of inclusion proof material that's exist today in columns so it's like the the sign header the commitments and then inclusion that shows that the commitments are contained in the in the header uh or like in in the block ultimately um yeah so this like the

thing that kind of allows the column side cars to travel by themselves basically detach from the Block um and like resolves all of these like equivocation questions and and all of the stuff and doesn't require the columns to be signed um so yeah but the annoying thing would be like if we included all of this with each cell that would be like a crazy overhead like it just wouldn't work we could do something milder so we could include the single kg commitment uh for for this cell so it could be like you know kg proof kg commitment and then uh the header and an inclusion proof that's just for that uh cell um it would still not be great like the header is like about 10% overhead on

the cells uh of the size that they are today and it would be even more overhead if we had like smaller cells which could be nice for to make sampling cheaper um so yeah like the header by itself is quite heavy and also then the inclusion proof would also be heavy like you it would be heavier than the the current inclusion proof because it would be um needing to show inclusion of a specific commitment as opposed to like the whole list of commitments uh so there's like a few more uh like leaves that or like nodes that you would need um so yeah like both ways to to kind of have an inclusion proof uh in each side card doesn't seem great so what I was thinking is basically you could have this same kind of inclusion proof

material that you have today but you only send it once you only send it like the first time that you send a cell um like considering a specific pier in in this topic the first time you send them any cell you would send uh this kind of proof side car and you don't do that um afterwards like um any other cell would just come with these things so basically kind of the raw cell material plus the kg proof which is like the bare minimum kind of that you need except for the indices but uh They Don't Really weigh that much um so yeah this I guess was the General approach that after a bit of like playing around with it made made most sense to me like it seemed like the

most similar in some way in terms of um the similar most similar to the current one in terms of um overhead basically and like in terms of like B with overhead at least and then the other thing that to consider in terms of overhead is is just verification overhead so um yeah like by default you kind of lose batch verification which isn't great but yeah it seems like there would still be plenty of opportunities to to basically introduce batching reintroduce batching um things like waiting a bit and then you batch verify um you know at fixed intervals you verify everything that you um accumulated and you could do this across topics as well I think today if my understanding is correct clients don't

do this for columns uh but like here you could maybe try to introduce this like whatever cells you have even across topics you could best verify um so yeah these kind of things um seems like that there should be like a like plent of way to like regain some of the efficiency lost um by by having cells instead of columns um don't have too much more to say about this cuz yeah it's it's really just just like some thoughts about I'm curious if anyone has like I don't know I guess General opinions on the doesn't make sense to keep looking in this direction like is this something um I mean I guess one thing is just like doesn't make sense in general the second

thing is like does this make sense as a potential thing to do in fusaka uh or is it like a crazy idea to to change the specs um with this and then the other thing is if you have any like specific thoughts more about the the design or or things like that so yeah let me start from the end so from the from the batching uh the batching is um so nus is already doing similar kind of batching with the with the verification where you basically um you you kind of naturally batch because if if you are lagging behind in in your verification job then then you look at the queue you have 20 pieces there

and you just validate them together uh and that kind of behavior is is solving naturally many of the of the batching things it's it's more of a engineering software organization saying that you should not you know Lun loue the uh the verification job on every single piece but uh have the CPU resources allocated and then when when you add back to it again you you just look at the queue or I have 20 of them I do them together so that's kind of handles this dynamically based on your resources so I I don't think that's a that's a problem still you have this CPU burn issue but if if you're going with these numbers I don't think it's a

it's such a big problem we looking into that in the in the 2D large case and then there it starts to be more of a of an issue how much CP you use uh if you cell-based for the cell-based distribution itself uh uh the these two questions what what to do with the headers and uh and how to handle those and and and whether to do sell based distribution and uh on the headers it's I think we were floating that since quite a long time I think but we never actually looked into it uh but I think the hadle would have to be basically presentent like it's its own message start with that push it out

every gets it um and then you have your local logic if you if you didn't get it uh but from the propagation point of view you just you just send it out it's in that context it's small by a separate message you mean like literally like a separate topic or within each topic top separate message cord header and in which you just send send it down everyone gets it fast diffusion uh has it has its own message class is it much different at that point than just saying you just wait for the block I mean the header is obviously much smaller um but I don't know in practice does it matter super much in terms of diffusion

time um I mean technically I think the the overal effect of of bundling it with the with the first okay so wait what was the question is B oh like uh no no it was like comparing to if you just let's say forgot about the header and just said you just have to wait for the Block in order to be able to uh verify and forward anything like the block will already have all the things you need of course the block is heavier and like takes longer to do to propagate but um I wonder yeah I'm not sure like how how big of a difference there is um to to wait for the Block versus like wait for

the header that's fine as well uh it's just these are different overlays so maybe because of the different overlays uh it's redundancy we are fine with redundancy like like we're doing it in in for many things so it might make sense to you know just send the Headly ahead on on this specific channel uh so that it it kind of propagates on the same structure and and just goes ahead um but I don't think it would be a big difference whe just wait for the block or or send it ahead here as as an extra redundancy the header is is small right

you don't want to send it many times but to to send it out once to on this channel that won't change anything like on the yeah yeah I mean sending it just once per topic it's whatever it's it's the same size as uh uh yeah that's yeah anyway it's just more so so I think it won't it won't make a difference and then then you are kind of having it just pagate uh on this and then you don't have that conern anymore you still have to handle it in in software anyway this the complexity of having it not having it what do I do do I cue stuff for how long and then for the for the actual

cells if we are not doing the if we doing it like this so we have the the column the side car as the main mechanism and then this is like an an addon I would do it with a with a pull logic so I I will not try to figure out the the push push logic to do this and that because I think the clients would would bit suffer with with was the right logic there and I so I can't say what's the right logic there I would just have this kind of I have I want mechanism in in these channels in

which I know that others have these and I have those and I'm personally in the situation that I'm blocked by not having that one cell then I pull it but I'm not pushing all the cells uh no one is pushing all the cells because then you are kind of duplicating uh the so what what I was thinking actually was you would not be sending columns like you would only be sending cells um do you see like a strong reason if we did want to deal with cells to not just deal with cells if assuming like there you know there is no overhead from doing so and um like yeah we've removed the header

and kind of we figure out the bash verification Works kind of well enough um that way like is there a reason not to just not have full columns gossiping so I if with with sending just cells I'm I'm quite positive about that there are two problems with that one is is a bit more of the overhead on the uh on uh so yeah so so suffering from a number warheads and uh and and many of them boil down to implementation Rel thing so by on the N implementation I have quite good results with sending a bunch of

cells around I I would easily imagine many of the implementations would would have problems uh sending that although the other is sending a bunch of small messages so maybe not uh the I mean the overall effects of sending small cells would be kind of a a mixed bag because you are sending smaller messages you have slower forwarding delay so your to forward delay is smaller uh on the other hand you have more overhead because of the of the message overhead the message ID overhead all these kind of things so you have this kind of strange

balance um I think we can enable just the the the cell only Behavior Uh but it would be a much longer testing uh and because the the normal testing is not going as F fast as I was imagining I I'm a bit afraid of saying let's let's let's switch to the to the cell based because it opens up uh maybe a bunch of implementation related things in the clients yeah so I guess one overarching question here is like um is this something that at all we want to um explore for f i mean I guess we want

to explore it but like do we want to open the can of worms in any way um for fusaka or no um and if so maybe makes sense to do it earlier because there isn't really I mean implementations right now are not working anyway I at least not like not in a way that that you know where DEET can be stable um so maybe it's kind of okay to to change the spec at this point um but yeah I don't know I don't have any strong opinion here um and also as I said I'm not entirely convinced that um there are like big benefits to to doing things this way in the short term at

least like maybe there's benefits to like future compatibility and I think it might might be nice that we generally experiment with with cells um like for example eventually we probably want to deal with cells for reconstruction um oh speaking of which uh Justin had this comment around reconstruction yeah I just wanted to quickly say like um I guess you could think of it as like gossiping cells in in vertical topics is is in like column topics is for distributed block buildings and gossiping cells in horizontal ones is in is for reconstruction and it's just easier for us to start from the vertical ones because we have them it's like something that we need versus like the horizontal ones is something that we would have to add like the the actual like you we we don't have row topics

right now but yeah this is just a parenthesis um but yeah so like it would be you know something that it's nice to experiment with and um eventually probably want to do in some form but it's not like super clear that there's huge short-term benefits to doing it so um yeah I don't know if other people have opinions around this kind of aspects yeah I just just wanted to add still that I think it's nice to experiment with and I I see some some people I think would be happy to experiment with it like I can imagine Anton would would play with it so it's maybe it's something that it's easier to experiment it then then change the spec and then and then Force everyone to kind

of go through easier to experiment in in in one one two clients and just see where they go okay I guess we are at time uh or P time um yeah I don't know if there's any last um comments on this or I don't know otherwise yeah let's we can just keep the discussion you think if anyone has thoughts on like what's the right Next Step if uh I don't know um yeah there's

like specific people that that are interested interested in maybe trying things out that that could be nice yeah it seems like I think you're right that like it would make sense to experiment with it it would not make sense to now make like uh any kind of yeah actual to take any like actual action like change in the specs um so yeah if there's anyone interested in experimenting with it uh let's keep in touch okay thanks everyone thank you bye everyone but