# EIP-4844 Breakout Room #3

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2022-10-09
- Duration: 51:26
- Topics: blockchain, smart contracts, distributed ledger, ethereum
- Watch: https://streameth.org/watch/yt-3s_od5WjN7Y
- YouTube: https://www.youtube.com/watch?v=3s_od5WjN7Y

## Description

https://github.com/ethereum/pm/issues/586

## Transcript

okay we are recording um this is the third 484 breakout room uh share the agenda again in the chat um at a high level uh there's been like some updates in terms of the implementation on the devnet and uh we'll start by kind of sharing those and going over it um there's a bunch of things left to do in terms of like work on the devnet and uh i know over the past couple weeks a bunch of uh engineers have reached out that they wanted to help so we'll make sure to take time to cover those and and see you know if there's some some folks here who can help with any of these these tasks um and then i want to make sure we kind of spend a good chunk of the call as well talking about the the higher level uh kind of uh design questions um so there's there's two main or three main ones um this idea of like how the the base fee and the whole flea market works for this um the sync uh the sig design which terence wrote a really useful dock for and then uh updates on kcg verification optimizations um if we get all that done we're happy if we have some more time i think some stuff to chat about it's just like you know if we have a second devnet what's the features that we want um if there's any updates on the kcg ceremony side um but yeah these the kcg stuff has called every every two weeks so it's fine to leave that to there um yeah i guess mophie do you want to give us a quick update and maybe like demo of of the devnet hey tim yeah yeah sure so um we have a devnet out um this is going to be the first of uh hopefully only two devnets uh we're going to have rolled out for the eip4844 um this devnet basically um there are a few things in the spec that we still need to um i guess discuss and finalize so hopefully the the goal of this death tonight is to let us um i guess test what we have what we've already come into consensus and um have something that a community can start like playing around with and hacking with um before we later like decide on what we need for the spec at that point we'll have like a second devnet and then um we can go from there so um devnet we have running available um contains basically four validator nodes and four beacon nodes and i wrote up like a pretty handy guide that's linked in the github issue to help onboard folks into it let me post it here on zoom so to like connect to the devnet all you need is basically um the latest death and prism implementations of the spec and i posted like some configs you could use it's not really geared towards um um i guess folks that are not very familiar with um running death or prism so the the guide is a little bit baroque but it should be able to get you started um let's see here let me see if i can maybe demo how this will work i don't think i've done that yet just to like show you how to work um let me start my video if that works is that where i could like share my screen you should be able to share this video okay um let's see here there we go sure screen all right um i hope everyone can see my screen now yep cool um so um we actually have like so michael from coinbase has like this really cool repo that sets up like the daca compose um making it very easy for you to like connect to the devnet um let me post that in the chat i think that'll be like the easiest way to onboard users basically takes um the guy that i wrote and like um solidifies that into like a couple scripts and uh i think michael we still need to like update the genesis and that reaper right yeah i can do that right now cool so i have that repo um pulled in um in my instance i have the genesis running and pretty much if you want to like start the devnet for my containers here you can pull the repo like i posted in the chat and i think once michael has like updated the genesis files i think you also need to update the the guest image to point to the latest one because it has the embedded uh geth genesis as well once you have that set up um all you have to do is just run dock and compose up and it should start both gaff and prism connect to the boot nodes we have set up for both execution and consensus and uh should be good to go um this would take a while because like i think um we started the devnet like over a day ago so it would take like a couple minutes not hours to like sync it and then once that synced in i created like this really handy script um called bob utils um it basically lets you upload and download blobs pretty easily so um we'll post that in the chat as well you kind of use that to um interact with um with blobs in the network pretty easily so for example um if you want to like upload a blob file or rather to send a blob transaction kind of like you just like this command it gives it like a your guest url a blob file private key hopefully no one everyone forgets that one and uh two and you can easily send blob transactions uh to the network um same thing you can do it for like to download um a blob that was sent to the network you use the same tool it's really self-explanatory if you take a look at the help page yeah i can't really do that right now because my node is still sinking but hopefully you get the idea um so right now one thing that's kind of missing we'll get into it later um while you can like interact with the beacon chain network um you can't send any vouchers actions without eth right so um feel free to ping me on discord or telegram if you need some east to get started with and then i can just send that to you um if you want to start sending blobster's actions yeah that's pretty much it um yeah any questions yes no questions but yeah that's very cool thanks for for demoing mafia um yeah and i guess uh you kind of hinted at this uh like there's there's a couple things missing right now so like one of them is obviously a there was like a faucet or some less manual way the the the to get eat on the devnet i think that would be pretty useful um and then beyond that um yeah beyond that sorry i have like a little list of other things um yeah beyond that i guess is if there was a way to like automatically use your blog transaction sending tool and like kind of spam the network or create like a high load of blog transactions i feel like that would be good to see the nodes processing that um to be able to also just like verify that when the blobs expire they're actually like taken out of the network and like um remove kind of from from the beacon chain um and then i don't know if like it would make sense to have an rpc endpoint as well so that people who may want to interact with the devnet but not uh run the whole docker setup uh might be able to do that um yeah i is there anything else you think yeah yeah the rpc endpoint um i think that's something we can definitely add in a day or two we just need to like harden it a little bit on our optimism side to make sure that you just don't spam the network yeah awesome yeah that makes sense um and then i'm curious i know yeah there's a bunch of like newer folks on the call um does anyone feel like one of these things like around either the faucets kind of a blob spamming transaction tool um just like testing the expiry of blobs that's something that someone's interested in working on and we can follow up after the call to kind of get that sorted yeah it's probably something i could i could look at i obviously this is a new tool so i'll have to try it out and i'll have to set up a vm to um put guests and prism was there a thing in particular in that that you were like interested in working on or just generally and i just just want to um help with anything and i'm sort of learning at the same time so like i run a mainnet validator node but it'll be good to to set up a test that and while i'm playing with it i can help out with whatever whatever testing you need cool um yeah that sounds great and we can chat uh in the in the discord uh yeah i could i could try my hands with the faucet if that's helpful yeah that that would be um okay and and i think georgios is on the call i think paradigm has a faucet repo that might be open source um i don't know if that's 100 so correctly yeah we do so it might not support for new networks to the extent that you can give us okay cool okay i'll take a look at that um sweet yeah i can probably get um uh some notes running as well and i could take a look into uh writing like a utility to just kind of spam transactions or whatever that would be yeah you also mentioned uh you also mentioned it might be useful to have like an rpc endpoint so i know mofi just said that you want to harden it to avoid spam on the network but is it useful to kind of have an open one that we designate for spam maybe that can be useful to just kind of look at node usage and things like that i think you probably it's probably best to just if you're spamming the network actually run your own instance of the test net and like propagate the transactions that way um okay yeah yeah unless mofi disagrees that would be my gut feeling but yeah rather than rallying it through like a like external rpc yeah yeah um i think i guess by spam i mean not quite the right word um meant to like to dos like there are our endpoints it's generally fine um the the end point once we have it set up you can spam it um it's just you will have like some dots protections and it's best if you really want to go that far then like what tim said it's best to just run your node and uh send transactions to that yeah yeah okay makes sense whether that blob spammer uh should it basically simulate kind of like a realistic scenario where it's like the you know like a roll up posting blobs to the same contract every time or same address rather every time or should it like try to balance between addresses and try to just like throw things everywhere to see if you create something like what's that what's the worst case scenario i guess for the on the note side um i i would say try to like trigger the uh so we have limits in place like for example the number of blobs in the block um that can be included in the block or the number of uh the size of the blobs that can be included in the block um it would be really useful to be able to um um push these limits or trigger them and that's one way we could see to make sure that the network is still working even as those limits are being hit and i feel in terms of like yeah that's probably the main thing if you want to make it like a tad more realistic it's like there's probably gonna be a handful of different contracts that like mostly uh get like interact with the blobs you know if you think of like l1 right there's like call it maybe five to ten roll ups there's not a hundred but there's also not just one so that's maybe the order to aim for but i think it's also fine like for a v1 to just yeah make sure hit the limit on one contract make sure that works and then if it does you can uh you can kind of scale it from there um and yeah i'll i'll post this here i'm not sure how helpful this is for the spamming stuff but marius from the get team has a bunch of like fuzzing repos and transaction sending repos like i don't know like i know that they don't work with uh blob transactions i don't know if it's easiest to extend something like that or just to write something from scratch um yeah smaller in case that's helpful um sweet yeah and i think yeah the the i think uh at a high level if we can get the faucet up just like some spam on the network an rpc endpoint and then a couple people running uh the devnet and also trying to like look at the kind of blobs expiring and making sure that works that's really valuable um i think the other part that's like maybe not as urgent but it's if we have a second demo of that working swords like documenting things better um and that can be as simple as like if you're playing around with this and like you're in mophie's hacking d and something is like wrong or could be better documented just like gradually adding to it um that's that's always helpful because you've hit a bunch of hedge cases when you have different people running this stuff and um yeah uh hopefully the devnet v2 is like a bit more accessible where you don't need to be like a protocol level developer but maybe you're just like an app developer and you're able to use it smoothly maybe i missed this but is the blob experience set to something pretty low on the devnet so it's easily testable like i think it's a day is that right mafia yeah that's right yeah yeah cool yep yeah um i guess any other questions thoughts comments um yeah i have a bit of a new question about uh getting the devnet running um are there should i just follow the same sort of hardware guy guides for like mainnet for uh disk size number cpus ram things like that or can i go lower um you can go lower um i think particularly the um the disk requirements will be much lower yeah but i imagine though as as people start spamming things things can get quite gnarly okay cool i've got a few servers on hexner that are bare metal and have a fair amount um of resources but okay cool thanks yeah that's actually a really good question like maybe we could just add something in the hacking v as well for just like a recommended like yeah minimum processing and storage i i can take on another task which is just to sort of monitor the dev uh um the monitor the node and uh try to get like a baseline of resource usage um and we can maybe publish that as like a first step for how much you actually need for uh erp 4844 yeah that would be great actually yeah tim it seems like it'd be useful to get some of the l2s to be running on this so we can see you know actually have some real roll-ups yes i think uh turtle's not on this call he said he was planning to look into doing this uh on the optimism side i believe they still needed some changes to like bedrock to make it work um yeah and i think uh yeah i can i can also send it around to uh the other l2 teams to see if some of them have the bandwidth to deploy on it quickly um no that's a that's a good point i think i guess especially once we if we have like an rpc setup then it's much easier for them to you know they don't even have to run the devnet basically they just have to like deploy their smart contracts and um yeah anything else on the devnet itself are there plans for an rpc setup what is it uh yeah mophie said he was gonna work on one yeah okay great yeah is that a typo for the 20 gigs mostly or is that actually 20 gigs it's actually 20 gigs okay i imagine we'll probably bump that up pretty soon but yeah yeah okay um see anything else on the dev map um i think that's it sounds good um okay next up i guess the thing i wanted to chat about uh was uh like scientific pr about uh the the fee market um i know proto had left a bunch of comments on it um i'm curious you have a feeling basically of where we've landed and um whether whether we can go ahead and and and merge this or is there still some some work to be done um so my understanding with the disagreement on the fee market is it's a question of are we targeting more of a like long-term um number of blobs or are we target i mean i guess they're both going to target a long-term number of blobs but one is going to target the long-term number of lobs in a much slower way whereas the 1559 mechanism is going to very quickly change the price of the blobs to reach that amount and i think that the original idea was that we didn't want to like use the 1559 mechanism here again um because of how quickly it was moving within just a handful of blocks um so on that front i don't know if anyone has any other thoughts related to it like i don't think that this pr is changing the fee mechanism from what it was it's really only removing the fee mechanism from the state contract right that was the original goal of the pr is to not modify anything but just take it out of the state contract yeah and do you think i like my recollections like we were all on the same page about that but then it probably makes sense to not merge this now if we want to make further changes is that is that right i mean i i'm on board with making this change because i think that like the change is only removing out of the state contract which everybody except for vitalik is okay with and we should separately modify the fee mechanism if we desire okay i think yeah i think that makes sense um does anyone else have thoughts on this yeah i also just briefly wanted to give my plus one to that as well i think it makes a lot of sense just because um kind of having it in the state is just this excess source of complexity and even if we gonna change it in the future that the mechanism itself i i don't see why might make sense to wait into bundle so i think having them separate it's the right way to go cool and then okay so let's yeah let's do that and then uh we were going to discuss this on the cl call last week but we got busy with the merge um and maybe we can bump it to next week's call and see if there's a yeah some more uh insights there because i think yeah the core of photos things was like is it better for the nodes to receive like short bursts of blobs or just like a more constant stream of them and we wanted cl teams feedback for that can't we question for formats in that you mentioned that the reason you choose one over the other is that one results in a slower adjustment can't we get that from the 1559 mechanism by just tuning the constants so we can adjust like how fast it reacts just by tuning constants i think that we should be able to also achieve it um by by tuning the constants i mean i think for now this is unfortunately kind of like the distinction between the kind of this long run average and the 59 mechanism is always on these chords a little hand wavy because i don't think we've fully kind of looked into like rigorously i looked into it enough yet so i think that's definitely like the next thing to do um i'm yeah i'm also not 100 certain that it's in a playset where necessary it's already very helpful to get cl teams feedback on just because again like it's a little bit hand wavy right kind of describing the distinction for now um but yeah we we can talk about it offline and i think i i think the thing that the reason why uh we did want to reach out to cl teams is there's an argument that like maybe actually getting like burst of blobs is like a bit easier to process because uh yeah they're like easier to process in chunks than like in small increments and i think if there is something there with like how the clients work that can at least help like cuts the design space or like yeah narrow the design space a little bit um i don't know terence do you have any thoughts on that or actually yeah and enrico is here as well so yeah yeah i don't have a strong opinion i need to see some benchmark data or even just play with myself first before i form and uh before i format an opinion for this what type of benchmark data would you like to see uh like just the basic like the how like just the compression data and how fast to verify and to validate stuff and yeah [Music] uh enrico that's from you yeah and i just jumped into the into the topic and i need to wrap my head around this so i need some time to to form uh some this kind of question before different asking yeah okay that's good um by the way sorry just to add one thing um you mentioned that there's some sinking uh discussion uh uh taking place in some somewhere in github or somewhere do we do we know where this is taking place so i can catch up i don't know that there's a discussion and i was gonna be the next thing but basically we did discuss it in various places and like terence wrote a doc summarizing kind of the approaches um i guess we can move to that next if there's nothing else on the free market yeah just on the feed market it seems like merging this pr just about this moving things to the the header instead of the state is like we should do that um unclear about what the right like design mechanism is and um we probably want to get some more data and potentially some more opinions from like client teams to like inform that but it's also not it doesn't seem like the most urgent thing and getting like the verification optimizations in before is probably uh better does that seem roughly right i'll take this as yes um okay so yeah next up blob sync uh terence do you wanna actually take a minute oh sorry sorry i just wanted to say one last thing on that if somebody could just go through and give a thumbs up on it so that um yeah we feel confident because there was a change in how we're calculating the gas cost for the blob it should have the same result but um it would be nice to have someone else thumbs it up just to make sure i can do that that helps okay thanks so i'll go ahead and merge it once we get the thumbs up sounds good um sweet okay on the blob sync terence do you want to take a minute or two and like walk us through your dock uh either sharing your screen or we can pull it up i've i've uh posted it in the chat yeah sure i don't so like if you just open the dog sorry yeah okay i am a muted yeah so just open the dock and um i don't think we need to keep this loan so i can just quickly um i can quickly like go through it so there's just two approaches we are considering right now one is you essentially um decouple the the the sidecar and the block and that's that's how the spec is right now so there are two different objects and the uh and and one is just tightly coupled right so you put the sidecar within the block right and there are just essentially pros and cons between each trade-off for the coupling right so if it's not coupled then it's likely more optimized and more extensible for the spec because for then sharding we can essentially use the same like function and then if it's coupled then it's more better for the client i would say so but like honestly like i went through like two different approaches here and there i thought about this at some time and i don't think the difference like is that drastic right so if you if if you don't couple it like there's more code on the client side you have to handle the queue you basically have to wait until you receive the blog before you can process the sidecar and before you can run for choice and then the changes are like not that bad because we kind of do this for attestations already today just say today you receive like attestation on the beacon chain right you can't really process the attestation until you get the block that the attestation is voted for so it's kind of the similar concept so i don't foresee like that like i don't foresee like that i don't foresee that bad of a pushback from the client team but with that said right i do want to like give more inputs to the client team because like if just my input is not enough there's like four other awesome teams out there they definitely should voice their uh opinion i would say so and um yeah so tldr like it i i think it's okay to not having them together but it just requires more client work and then i love to give more feedbacks on the client team side and that's it got it um enrico i assume you haven't had time to form an opinion on this yeah just yeah to go through it and uh it was more more thing thinking about uh thinking what i see at the very end of the the document you you mentioned the blob side cars so i mean this one is the change to actually be able to sync yeah so right now there is a request response gossip topic basically allow your peers to request the site cards by range right so one thing that like one scenario we can think of is that a note joins say you've seen the checkpoint sync whether it's finalized epoch finalize checkpoint or with subjectivity checkpoint uh when he joins right and uh that's usually gonna be like t minus a few days or t minus one week something like that right so he needs to basically backtrack and get the and get the blob data right but usually it doesn't mean that he has to backtrack and get a block so that's kind of the symmetry right there so if they're coupled together right you can just say hey we can just backtrack and just get a block for the last month easy but now since they're not coupled you just you have to backtrack and get a blob without the block so that's kind of like the little odd part i mean it is workable but that's just something to thought about yeah to think about yeah right so yeah on my end i'm gonna also like forward this to paul from lighthouse and then everyone else just to try to get more feedback on the client side but i really don't think like since they're everyone's really busy working on the merge i don't think we'll form like an opinion or a decision until like maybe shortly after the merge so yeah yeah fair enough yeah asgard yeah i was just wondering this could be a stupid question but um would there be any sense in keeping them like loosely coupled like like basically separate but creating some sort of new rapper to just uh kind of doing kind of uh so so why while you are at the head of the network with why you're not kind of doing history or something that like they usually come in together but then for basically further back data they they're still in their separate form so it's kind of like kind of combining the properties of the two yeah uh yeah no that's what i'm actually doing on the code but that's kind of in my opinion like implementation detail depends on like other languages may handle like differently for example for go i'm just using interface for it which is quite nice so on the code level they're pretty much treated as the same object but the point is that you cannot do one thing without the other for like for the fourth choice so you always have to wait right so i think that's kind of the debate here but from from the language perspective like people can make the look the same basically i know but what i meant was just like though and then on the networking level right you basically have some news kind of official kind of structure something that's kind of like you know block with blob or some with blops or something and then basically you usually request that entire thing so they just come in together um but but yeah yeah so basically a new network object no i think that's definitely one option as well that we should probably consider yeah anything else on this sink okay and then i guess um the last kind of spec level issue was around uh the the verification optimizations uh george i know you've been spending some time looking at that and talking to the super national team you have a mic one two one two one two oh yes we got you we got you x okay so i talked with the supernational team like two weeks ago or something um and we gave them like a list of um tasks that we need from i mean that's not exactly related to the verification thing that's more about the kcg library situation right but like um we gave them a list of functionality we need from the library they came up they came back with us with like some timelines and stuff like that then we discussed it further and kind of scrutinized the stuff that we already sent them and kind of tried to minimize the work to make it come out as soon as possible so that we don't um [Music] so you know so that ideally client teams have a library to work with as soon as possible so now um they're supposed to get back to us this week with a new um deliverable list um but i haven't heard from them this week so i don't have any more precise updates got it um i assume no one else has updates on this okay and then i guess on the actual optimization side so i think the the gist of the issue there was like mophie you implemented like some of the original optimizations are added to the spec and then they were not actually as uh as performant as as expected and i know there was like some back and forth about that in the in the discord uh but i'm curious yeah what was the status there yeah um um so yeah basically i think um george pointed to um basically so the the crux of the i guess performance uh problem was it was there were two major operations that i think we can you know optimize um when computing aggregate proofs and one of them is the the modular inverse we do a lot of them when evaluating the polynomials and george pointed out that we should be batch um um running modular inverses and pointing out helpfully pointing out to like a resource and kill it where this could be done i've been taking a look at this um but this week that'll be like my like my main thing to get back into that related to that this though um one other thing that kind of like want to bring out is that we also noticed that running the sse routes on the fiat premiere challenges is expensive um would it make sense to use a different um method of like computing like those challenges for the polynomial evaluation yeah i think we really don't need the entire like miracle 3 situation that ssz has to get security here so ideally we would just switch that entire hashing thing to just use like straight up um you know a basic hash function instead of computing like crazy miracle trees um i guess that also has um we have to change the spec i guess to be able to do that um i haven't done it yet but you're right that this is probably also um useless time drain right okay um so yeah i will also look into that um and i guess we can discuss the details offline um because before we i think before we should change the spec we should like take a look at a a couple hash functions and see what works um performance wise and without sacrificing security and now we can go ahead yeah yeah that makes sense i mean my my basic intuition would be to just use the underlying hash function that the miracle tree uses but instead of doing the crazy three things just like straight up hash the value however um yeah we should talk about it offline and we can figure it out that's a good point i actually forgot about this yeah because that seems like the main blocker it's like if we can get that or i mean for like a next iteration if we can get that then we can get some benchmarks it helps figure out like uh the the throughput with regards to blobs and and that might shape the free market design as well so yeah that seems like a really valuable next step will you be at sbc movie uh wait spc what's svc okay some conference in um stanford or something in two weeks oh that um i hadn't had plans to but i could take a look yeah why not okay oh great it's in the states so yeah i should be able to make this one just anything international i'm still like trying to get my passport yeah if yeah if you do plant it though i think there's a bunch of side events as well and we can probably oh yeah they're actually they're listed literally on the on the top of them so that's that's good nice hello i just want to tell you that if you come we can take like do some um hands-on together and figure out more precisely performance stuff yep i think that'll be really useful yeah i'll try to make it sweet um okay i think yeah i think that was like the last kind of big i guess design level issue in the spec um is there anything else that people feel is like really important to make progress on on this that we haven't discussed so far okay that's a good sign um and the case of g-side like i said they have like bi-weekly calls now so we don't have to like uh kind of rehash all of them but it seems like they're getting audits started for uh the ceremony both for the spec and the implementation um so so um that's that's good so i don't think we'll be blocked on that um and i think yeah just in terms of like next steps generally um [Music] we had all these like tasks about the existing death nets so um yeah if folks can help out with those that would be valuable and then that means like mophie can start focusing on this verification optimization um that seems like the main thing we want to like unblock now and then based on how complicated it is to get the fee market we might want to have a second definite either either we we just like combine those two in the second devnet or maybe we like launch them separately if the fee market is a big other separate discussion um we are just getting the optimizations right seems like the core thing um anything else oh sorry i just wanted to add on to that like an interest of progress um really appreciate if um we could get more feedback on like clients pr so that we can merge that as possible and i know like there's some things that probably can still hash out a bit but i'm just thinking like from an implementer's point of view um the bulk of the work is getting consensus on um where the uh i guess where the the fees like are being tracked whether it's the system address or in the block header and that's like the most important aspect to me as an implementer and if we can get that merged then we can iterate on the actual like fee mechanism later on in the free market later on yeah yeah yeah i don't think there's any players back on the header so i think but i think yeah if enzgar can review that give a thumbs up then we can merge it probably sometime next week and yeah and also just proof it by the way that's one of the nice things about the p market at least that it's like it's purely a theoretical kind of question and so once we have a kind of a final decision there it should be really lightweight in either way uh on the on the instrumentals like that this should not be at all like one of the challenges for them and just whatever we land on anything else anyone wants to talk about um in the last uh 4844 meeting um we had brought up that test coverage on both geth and prism needed some work is that something um that's still either in progress or active or needs help with yeah i can give an update on that so um so since the last meeting i look so a few days after the last meeting i managed to um sync uh mophie's awesome repo with our latest develop branch so it took me like a while actually to see that just because there's so many conflicts so i finally finished that and um as of our update so this friday will reduce our v3 we reduce our v3 release so that means that there will not be any code changes unless my critical body is found post merge so i think like after this friday our clothes should be in a very stable place and then so after this friday maybe over the weekend i will resync again from um just to make sure the code isn't in the latest state and after i'm finished that i will ping you or anyone else that's interested to contribute so therefore then we can start adding more unit tests so sorry it's hard right now or the last few weeks just because there's so many moving pieces and yeah i think we should be in a much better state coming soon okay awesome thanks um i had uh one other comment about uh some of the perf stuff um i i don't have a ton of context but just a quick suggestion or question i guess uh are folks using like flame graphs to measure performance or how is that process working online we typically do that um on like the running process so yeah we definitely do that but i would say like we'll do unit tests we'll measure like production performance so uh so so we'll run the note and we'll run flame graphs just to see the latency of just for the traces as well and yeah we i mean we do everything so definitely like anything you you can help like feel free to take it cool thanks anything else okay um i guess last thing before we wrap up uh does it make sense to already schedule another call or should we wait a bit um and their reason for waiting is like about a month from now the merge is scheduled to happen on main nets so i feel like we can maybe schedule something today but there's a world where we just canceled it if like it's really close to the merge so i don't know what what do people prefer or is it and is it also worth waiting until like we've had time to actually talk with the the cl teams um or should we just yeah schedule something optimistically and if the merge happens on that day we scrap it the people have a preference okay yeah i like that um yeah let's wait after the next cl call see if we've had time to discuss see if we get time to discuss any of those issues on the cl call and then we can we can potentially schedule something after that anything else before we wrap up okay well yeah thanks again everyone um and yeah talk to you all on the discord have a good one thanks bye everyone see ya you