 Okay. We are recording. This is the third 4844 breakout room, share the agenda again in the chat. At a high level. There's been like some updates in terms of the implementation on the dev net and we'll start by kind of sharing those going over it. There's a bunch of things left to do in terms of like work on the dev net and I know over the past couple weeks a bunch of engineers and I've reached out that they wanted to help so we'll make sure I think time to cover those and see you know if there's some some folks here who can help with any of these these tasks. And then I want to make sure we kind of spend a good chunk of the call as well talking about the higher level kind of design questions. There's two main or three main ones. This idea of like how the base fee and the whole market works for this. The sink, the sink design which Terrence wrote a really useful doc for and then updates on case the G verification optimizations. With all that done, we happy if we have some more time. I think some stuff to chat about is just like, you know, if we have a second dev net with the feature set we want. If there's any updates on the case G ceremony side. But yeah, these the case G stuff has called every every two weeks so it's fine to leave that there. I guess, Mofi, do you want to give us a quick update and maybe like demo of the dev net. Hey, Tim. Yeah. Yeah, sure. So I have a dev net out on this is going to be the first of hopefully only two dev nets. We're going to have rolled out for the EIP 40 year 44. This dev net basically there are a few things in the spec that we still need to, I guess, discuss and finalize. So hopefully the goal of this test and that is to let us, I guess, test what we have, what we've already come into consensus and have something that a community can start like playing around with and hacking with before we later like decide on what we need for the spec. At that point we'll have like a second dev net and then we can go from there. So Dev net we have running available contains basically for validator nodes and for beacon nodes. And I wrote up like a pretty handy guide that's linked in the GitHub issue to help on board folks into it. We posted here on zoom. So to like connect to the dev net all you need is basically the latest geth and prism implementations of the spec. And I posted like some configs you could use. It's not really geared towards I guess folks that are not very familiar with running geth or prism. So the guide is a little bit baroque but it should be able to get you started. Let's see here. Let me see if I can maybe demo how this will work. I haven't done that yet. Just to like show you how it works. Let me start my video. So I can like share my screen. You should be able to share. Let's see here. There we go. Share screen. I hope everyone can see my screen now. Yep. Cool. So we actually have like so Michael from Coinbase has like this really cool repo that sets up like the Docker compose making it very easy for you to like connect to the dev net. Let me post that in the chat. I think that'll be like the easiest way to onboard users basically takes the guide that I wrote and like solidifies that into like a couple of scripts. And I think Michael we still need to like update the Genesis and that repo right. Yeah, I can do that right now. Cool. So I have that repo on hold in on in my instance I have the Genesis running. And much if you want to like start the dev net. My containers here. You can pull the repo. Like I posted in the chat. And then 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 with Genesis as well. Once you have that set up. All you have to do is just run dock and compose up. And it should start both geth and prism connect to the boot nodes we have set up for both execution and consensus. And should be good to go. This would take a while because like, I think we started to dev net like over a day ago so it would take like a couple of minutes, not hours to like sink it. And then once that sink in, I created like this really handy script called blob utils. It basically lets you upload and download blobs pretty easily. So you'll post that in the chat as well. So you kind of use that to interact with with blobs and the network pretty easily. So for example, if you want to like upload a blob file or rather to send a blob to this action. And I like use like this command. Give it like a your guess your a blob file, private key, hopefully no one everyone forgets that one. And to, and you can easily send blob transactions to the network. Same thing you can do it for like to download a blob that was sent to the network. Use the same tool. It's really self explanatory if you take a look at the page. Yeah. I can't really do that right now because my node is still sinking, but hopefully get the idea. Yeah. So right now, one thing that's kind of missing, we'll get into it later. While you can like interact with the you can chain network. You can't send any vouchers actions without ETH right so feel free to ping me on discord or telegram. If you need some ETH to get started with. And then I can just send that to you. You should want to start sending options actions. Yeah, that's pretty much it. Yeah, any questions. Yes, no questions, but yeah, this is very cool. Thanks for demoing. Yeah. Yeah, and I guess you kind of hinted at this. Like there's there's a couple of things missing right now. So like one of them is obviously there was like a faucet or some less manual way. The get ETH on the definite. I think that would be pretty useful. And then beyond that. Yeah, beyond that, sorry, I had like a little list of other things. Yeah, beyond that, I guess is if there was a way to like automatically use your blog transaction sending tool and like kind of span the network or create like a high load of blog transactions. I feel like that would be good to see the nodes processing that to be able to also just like verify that when the blogs expire, they're actually like taken out of the network and like remove kind of from the beacon chain. 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 run the whole docker setup might be able to do that. Yeah. Is there anything else you think? Yeah. Yeah, the RPC endpoint. I think that's something we can definitely add in. We just need to like harden it a little bit on our optimism side to make sure that you don't spend the network. Yeah, awesome. Yeah, that makes sense. And then I'm curious, I know, yeah, there's a bunch of like newer folks on the call. Does anyone feel like one of these things like around either the faucet kind of a blob spamming transaction tool, 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 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 put Geth and Prism. Was there a thing in particular in that that you were interested in working on or just generally? No, I just want to help with anything and I'm sort of in the same time. So I run a main net validator node, but it'd be good to set up a test net and while I'm playing with it, I can help out with whatever testing you need. Cool. Yeah, that sounds great. And we can chat in the Discord room as well. I could try my hand at the faucet if that's helpful. Yeah, that would be. And I think George is on the call. I think Paradigm has a faucet repo that might be an open source. I don't know if that's 100% correct. We do not support for networks to the extent that you can give us the. Okay, cool. Sweet. Yeah, I can probably get some nodes running as well and I could take a look into writing like a utility to just kind of spam transactions or whatever. You also mentioned it might be useful to have like an RPC endpoint. So I know mostly 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 a network, actually run your own instance of the test that then like propagate the transactions that way. Okay. Yeah, I don't. Yeah. Unless Mofi disagrees. That would be my gut feeling, but. Yeah, rather than rallying it through like an external RPC. Yeah. Yeah. I think I guess by spam, I may not quite the right word on meant meant to like to DOS like there are endpoints. It's. Generally fine. The endpoint once we have it set up, you can spam it. It's just you will have like some DOS 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 own node and. Sentries actions of that. Yeah. Yeah. Okay. Makes sense. What about blog spammer? Should it basically seem like kind of like a realistic scenario where it's like the, you know, like a bullet. Posting blogs to the same contract every time or sorry, or it's the same address rather every time or should it like try to balance between addresses and try to just like throw the things everywhere to see. Like what's the worst case scenario I guess for the on the node side. I would say try to like. Trigger the so we have limits in place like, for example, the number of blobs in the block that can be included in the block or the number of the size of the blobs that can be included in the block. It'll be really useful to be able to. 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 going to be a handful of different contracts that like mostly get like interact with the blobs. You know, if you think of like L one, right? There's like, call it maybe five to 10 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 V one to just, yeah. Hit the limit on one contract to make sure that works. And then if it does, you can kind of scale up from there. And yeah, 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 transactions sending repos. Like, I don't know. Like, I know that they don't work with blob transactions. I don't know if it's easiest to extend something like that. They're just to write something from scratch. Yeah. I want to share a case that's helpful. I'm sweet. Yeah. And I think, yeah. I think at a high level, if we can get the faucet up just like some spam on the network and RPC endpoint, and then a couple of people running the DevNet and also trying to like look at the kind of blobs expiring and making sure that works, that's really valuable. I think the other part that's like maybe not as urgent, but it's, if we have a second DevNet of that, working towards like documenting things better. And that can be as simple as like, if you're playing around with this and like, you're in Mophie's HackMD and something is like wrong or could be better documenting, just like gradually adding to it. That's always helpful because you've hit a bunch of edge cases when you have different people running this stuff. And yeah, 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 expiry set to something pretty low on the DevNet so it's easily testable? Yeah. I think it's a day. Is that right Mophie? Yeah, that's right. Yeah. Cool. Yeah. Yeah. Sweet. I guess any other questions, thoughts, comments? Yeah, I have a bit of a new question about getting the DevNet running. Are there, should I just follow the same sort of hardware guides for like ETH mainnet for disk size, number of CPUs, RAM, things like that? Or can I go lower? You can go lower. I think particularly the disk requirements will be much lower. Yeah. But I imagine though 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 of resources, but okay, cool. Thanks. Yeah, that's actually a really good question. Like maybe we can just add something in the HackMD as well for just like a recommended like, yeah, minimum processing and storage. I can take on another task, which is just to sort of monitor the Dev, the monitor the node and try to get like a baseline of resource usage. And we can maybe publish that as like a first step for how much you actually need for ETH 4.8, 4.4. 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 Trolo is not on this call. He said that he was planning to look into doing this on the optimism side. I believe they still needed some changes to like bedrock to make it work. Yeah, and I think, yeah, I can also send it around to the other L2 teams to see if some of them have the bandwidth to deploy on it quickly. No, 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. Yeah. Anything else on the DevNet itself? Are there plans for an RPC setup? Yeah, Mofi said he was going to work on one. Yeah. Okay, great. Is that a typo for the 20 gigs? Mofi 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. Sweet. Anything else on the DevNet? I think that's it. Okay, sounds good. Okay, next up, I guess the thing I wanted to chat about was, like, find your PR about the fee market. I know Proto had left a bunch of comments on it. I'm curious you have a feeling, basically of where we've landed it and whether, whether we can go ahead and merge this or is there still some, some work to be done? 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 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 blobs 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 because of how quickly it was moving within just a handful of blocks. 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, 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 right? I mean, I'm on board with making this change because I think 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. Does anyone else have thoughts on this? Yeah, also just briefly wanted to give my plus one to that as well. I think it makes a lot of sense just because I'm kind of having it in the state. It's just this excess of complexity. And even if we going to change it in the future that mechanism itself, I don't see why it makes sense to wait into bundle. So I think having them separate is the right way to go. And then, okay, so that's, yeah, let's do that. And then we were going to discuss this on the CL call last week, but we got busy with the merge. And maybe we can bump it the next week's call and see if there's a, yeah, some more insights there. Because I think, yeah, the core of those 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 we question for Matt? 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 by tuning the constants. I mean, I think for now, this is unfortunately kind of the distinction between the kind of this long run average and the 1559 mechanism is always on these cards a little hand way 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. I'm, yeah, I'm also not a hundred percent certain that it's in a place yet where necessarily it's already very helpful to get CL teams feedback on just because again, it gets a little bit hand wavy, right? Kind of describing the distinction for now. But yeah, we can talk about that. And I think I think the thing that the reason why 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 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 cut the design space or like, yeah, narrow the design space a little bit. I know Terrence, do you have any thoughts on that? Or actually, yeah, 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 an opinion for this. What type of benchmark data would you like to see? Like just the basic, like the, like just the compression data and how fast to verify and to validate stuff. And yeah. Enrico, any thoughts from you? Yeah, I just jumped into the topic and I need to wrap my head around this. So I need some time to form some, this kind of question before asking. Yeah. What? Sounds good. By the way, sorry, just to add one thing. You mentioned that there's some sinking discussion taking place in some somewhere in GitHub or somewhere. 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 going to be the next thing, but basically we did discuss it in various places and like Terence, Roland doc summarizing kind of the approaches. I guess we can move to that. Next, if there's nothing else on the fee market. Okay. Yeah. Just on the fee market, it seems like merging this PR just about this moving things to the header instead of the state is like, we should do that. I'm clear about what the right like design mechanism is. And 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 better. Does that seem roughly right? I'll take this as a yes. Okay. So yeah. Next up. Do you want to 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 and with 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 parents, do you want to take a minute or two and like walk us through your doc, uh, either share on your screen or we can pull it up. I've posted it in the chat. Yeah, sure. I don't. So like, if you just can just open the dog. Sorry. Yeah. Okay. I am unmuted. Yeah. So just open the dog and, um, I don't think we need to keep this long. 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, the couple, the, the, the side car and the block. And that's, that's how the spec is right now. So there are two different objects. And the, and the, and one is just tightly coupled, right? So you put the cycle within the blog, 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 it's tangible for the spec because for then sharding, we can essentially reuse the same like function. And then if it's coupled, then it's more better for the client. I will say so. But like, honestly, like, I don't think we need to do like two different approaches here and there. I thought about this at some time and I don't think the difference like it's that drastic, right? So if you, 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 side car and before you can run for choice. And then the changes are like, I can't do this for attestations already today. Just say today you receive like attestation on the big engine, right? You can't really process the attestation until you get the blog that the attestation is vocal. 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 get more inputs on the client team because if just my input is not enough, there's like four other awesome teams out there. They definitely should voice their opinion, I would say so. And yeah, so TLDR, like it, I think it's okay to not having them together, but it just require more client work. And then I love to give more feedbacks on the client team side. And that's it. Got it. And Riko, I assume you haven't had time to forward opinion on this. Yeah, just to go through it. And I was more thinking about you're thinking, but I see at the very end of the document, you mentioned the blob sidecars by range. So I mean, this one is the change to actually be able to sync. Yeah. Right now there is a request, respond gossip topic basically allow your peers to request the sidecars by range. Right. So one thing that like one scenario we can think of is that a note joins, say you seen the checkpoint sync, whether it's finalize EPOG finalize checkpoint or with subjectivity checkpoint. So when he joins, right, and that's usually going to be like T minus a few days or T minus one week, something like that. Right. So he needs to basically backtrack and get and get a blob data. Right. But usually it doesn't mean that it has to backtrack and get a block. So that's kind of the cemetery right there. So if they're a couple together, right, you can just say, hey, we can just backtrack and just get a block for the last month. So now since they're not coupled, you just, you have to backtrack and get a blob is without a 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 going to also like forward this to Paul from lighthouse and everyone else just to try to give 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 decision until I maybe shortly after the merge. So yeah. Yeah, fair enough. Yeah. Yeah. I was just wondering if this could be a stupid question, but would there be any sense in keeping them like loosely coupled like like with separate, but creating some sort of new kind of, you just kind of doing kind of. So, so why while you are at the head of the network is 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're still in their separate form. So it's kind of like kind of combining the properties of the two. Yeah. Yeah, no, that's what I'm actually doing on the code, but that's kind of in my opinion, like implementation detail 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 life for the four choice so you always have to wait right so I think that's kind of the debate here but from the language perspective, like people can make it look the same basically. I know what I meant was just like though on the network right to basically have some news kind of official kind of stuck to something that's kind of like you know block with blob or some with blocks or something and then basically you usually request that entire thing so they just come in together. But but but yeah. I see. 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. The last kind of spec level issue was around the verification optimizations. George I know you've been spending some time looking at that and talking to the Super National team. To one to one to. Oh, yes, we got you. We got you. Okay, so I talked with the Super National team like two weeks ago or something. And we gave them like a list of tasks that we need for I mean that's not exactly related to the verification thing that's more about the KCG library situation. Right. But like 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 try to minimize the work to make it come out as soon as possible so that we don't. So, you know, so that ideally client teams have a library to work with as soon as possible. So. Now. They're supposed to get back to us this week with a new deliverable list. But I haven't heard from them this week. So I don't have any more precise updates. Got it. I should know what else has updates on this. Okay. And then I guess on the actual optimization side. So I think that the just an issue there was like some of the original optimizations are added to the spec. And then they were not actually as. As performant as, as expected. And I know. There was like some back and forth about that in the, in the discord. But I'm curious, yeah, what was the status there? Yeah. So yeah, basically. I think. George pointed to you. Basically. So the, the crux of the. I guess performance problem was. It was, there were two major operations that I think we can, you know, optimize. 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. Running module inverses and pointing out, helpfully pointed out to like a resource in Kilwich where this could be done. I haven't taken a look at this. But this week, that'll be like my, like, my main thing to get back into that. Related to that, this though. One other thing that. Kind of like want to bring to the table. Is that. We also notice that running the SSC routes on the. Feature of your challenges is expensive. Would it make sense to. Use a different. Method of like computing, like those challenges. For the polynomial. For the polynomial. For the polynomial. For the polynomial. For the polynomial. For the polynomial. For the polynomial. For the polynomial. Method of like computing, like those challenges. For the polynomial valuation. Yeah, I think we really don't need the entire like. Mercel tree situation that SSZ has. To get security here. So ideally we would just. Switch that entire hashing thing to just use like straight up. function instead of computing like crazy miracle trees. I guess that also has, we have to change the spec, I guess to be able to do that. I haven't done it yet, but you're right that this is probably also useless time drain. Right. Okay. So yeah, I will also look into that. I guess we can discuss the details offline. Because before we, I think before we should change the spec, we should like take a look at a couple hash functions and see what works performance-wise and without sacrifice and security. Now we can go ahead. Yeah, that makes sense. I mean, my basic intuition would be to just use the underlying hash function that the miracle tree uses, but instead of doing the crazy tree thing just like straight up hash the value. However, 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 the throughput with regards to blobs and that might shape the C market design as well. So yeah, that seems like a pretty valuable next step. Will you be at SBC, Mofi? Wait, SBC. What's SBC? Okay, some conference in Stanford or something in two weeks. Oh, that. 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 you do plan to go, I think there's a bunch of side events as well, and we can probably, oh yeah, they're actually listed literally on the top of it. So that's good. Nice. I know. I just want to tell you that if you come, we can do some 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. Okay. I think, yeah, I think that was like the last kind of big, I guess, design-level issue in the spec. Is there anything else that people feel is really important to make progress on this that we haven't discussed so far? That's a good sign. In the case of G-side, like I said, they have bi-weekly calls now, so we don't have to rehash all of them, but it seems like they're getting audits started for this ceremony, both for the spec and the implementation. So that's good. So I don't think we'll be blocked on that. And I think, yeah, just in terms of next steps generally, we had all these tasks about the existing death nets. So yeah, if folks can help out with those, that would be valuable. And then that means like Mofi can start focusing on this verification optimization. That seems like the main thing we want to unblock now and then based on how complicated it is to get the fee market, we might want to have a second death net. Either we just like combine those two in the second death net, or maybe we like launched them separately if the fee market is a big utter separate discussion. We are just getting the optimizations right. Seems like the core thing. Anything else? Oh, sorry. Yeah. Go ahead. I just wanted to add onto that, like in the interest of progress, really appreciate if we could get more feedback on like clients PR, so that we can merge that as possible. And I know like there's some probably can still hash out a bit, but I'm just thinking like from an implements point of view, the bulk of the work is getting consensus on where the, I guess where 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, the fee market later on. Yeah. Yeah. I don't think there's any pushback on the header. So I think, but I think yeah, if Ansgar can review that, give a thumbs up, then we can merge it probably next week. And yeah. And I was just briefly, 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 on the implementers, like that this should not be at all like one of the challenges for implementers, whatever we land on. Anything else anyone wants to talk about? In the last 4844 meeting, we had brought up that test coverage on both gap and prism needed some work. Is that something that's still either in progress or active or needs help with? Yeah, I can give an update on that. So since the last meeting, so a few days after the last meeting, I managed to sync Mophis 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 so our update, so this Friday will release our V3 will release 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 code should be in a very stable place. And then so after this Friday, maybe over the weekend, I will re-sync again from just to make sure the code is 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. I had one other comment about some of the Perf stuff. I don't have a ton of context, but just a quick suggestion or question, I guess. Are folks using like flame graphs to measure performance or how is that process working? It feels great to say talk offline or whatever. We typically do that on like a running process. So yeah, we definitely do that. But I would say like, what do unit tests will make sure like production performance? So we'll run the node and we'll run flame graphs to see the latency of just for the traces as well. And yeah, I mean, we do everything. So definitely like anything you can help like feel free to take it. Cool. Thanks. Anything else? I guess last thing before we wrap up, does it make sense to already schedule another call or should we wait a bit? And the reason for waiting is like about a month from now, the merge is scheduled to happen on mainnet. 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 to like, we've had time to actually talk with the CL teams? Or should we just schedule something up and basically, and if the merge happens on that day, we scrap it, the people have a preference. Okay. Yeah, I got that. 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 potentially schedule something after that. Cool. Anything else before we wrap up? Okay. Well, yeah, thanks a ton, everyone. And yeah, talk to you all on the discord. Have a good one. Thanks, bye. Thanks, everyone.