 Welcome everyone. This is merge implementers call number three. Let me drop the agenda to the chat. This is going to be short one. No major spec discussions is planned for today. We'll start with the Ryan's updates from client updates then go to the update on the first dev net that we are about to launch tomorrow, which is called stick law. Then we have some research updates, not much there. Then go to spec discussions, probably some questions are there and we're done. Let's start from Ryan's client updates. I'll start from Techu's side. Techu is ready for the first dev net launch. It's been tested with Bazoo, Net-O-Mind and Catalyst. That's it. We're excited to see it in the first dev net and see how the things are going. I didn't try to interrupt it with other clients, but just tried to run it on a couple of machines. Let us see. Also, the update is not about the merge, but Anton started to work on shorting implementation and Techu implemented shorting spec and did some sanity tests. Works in general and he keeps doing progress on that. That's from Techu. Who wants to be next? I can take Lighthouse. Not a whole lot to report on our end. We got interrupt going with Net-O-Mind now, so we're now working with Geth and Net-O-Mind. We're ready for the dev net, I believe. We're still not calling the finalized endpoint, but we can probably throw that in pretty quickly. That's it for us. Great. Prismatic. Hey there. I think we're pretty much ready. We spent the last few days debugging Azure root for the transactions field and thanks to Proto, he helped a ton there. We were able to get interrupt working locally between Prism and Catalyst. Today, we'll try Net-O-Mind and other ET4 clients. I think we're pretty much ready for the test net. That's so cool. Nimbus? Yeah. I think we're ready. We've been testing with Geth, Catalyst, and so far the interrupt has been solid. Looking forward to see how this works tomorrow. Great. I guess we can go to each one of the clients. Who wants to be first? I can go first. Nothing major. We will be releasing a hot fix for what Lighthouse submitted to us. A small issue in the contracts in the response, but nothing major. We'll be releasing it today, so we'll have a newest release and newest Docker today. What is this issue about? The issue is that the response wasn't serialized correctly. I don't know. I think it's something in Docker because in general it should work. I'm really confused why it happened because it works fine for me. Sorry, just to simplify it. The response is instead of success, instead of saying value, and Lighthouse said that it is generally okay. I'm interrupting because it may be a question to can we not release it and simplify it so they can continue? Can Lighthouse say if they will work fine with this response? We don't let an error on that endpoint stop us from progressing. Lighthouse just logs an error that we didn't find the feel we expected in the response. The success that the call works well in the other mind. It doesn't really stop anything from working. It just creates an error log. That's not really easy to not confuse any people who are using already some Docker. What do you think? I don't think that release will hurt anything, so we will be more stable. If you just grab a new Docker image, it should be fine for you. I would still release it. Okay, cool. Anything else here? Who wants to speak from Go Ethereum from Catalyst? Is anybody from Go Ethereum here? Okay, okay. I can speak. Yeah, I can give an update on that. It just works. I tried it. Okay. Bezu? Yeah, we just got a working Bezu teku local net yesterday and did some debugging and got it into a good enough state that we think that it's good enough to join the Friday test net. It's still pretty early because we just recently got it stable. Right now it's just a ranism branch and PR and a private Docker repo, but we're looking forward to participating. Great. Anybody else at TurboGath? I have a quick question before tomorrow. It seems like a number of each two clients have tried different each one clients underneath the hood, and then have we had a number of each one clients tried like a number of each two clients in the hood? Have we run at any short-lived transient test nets with multiple different consensus engines driving or is tomorrow the first time we're doing that? So I've successfully paired Lighthouse and teku. That works. There were some initial issues with Lighthouse and NetherMind because I've been resolved, I believe. So I'm confident it will work. Okay. So by and after teku agreed on the consensus changes are very minimal, obviously, but I'm just curious if they can stand up in that work together. Yeah, I've been also like using teku with NetherMind and Catalyst in like one local local. It was not actually local. It was a couple of machines. Yeah, but we want this net it worked well. I mean, if we're. So one thing I like to share here is that at first we were just looking at launching like the very minimal set of clients to just get something stable out that we knew now like shoot work. But we had tested for a longer time. And in the past few days, there have been like immense amount of new clients and instructions on how to build all of these things. And although I think and I'm still confident that we can run like this multi-client test nets, it's a lot. It's like clients are being added faster than we can rewrite deployment codes for them. So yeah, it's actually great. I think yeah, and very exciting to see what we'll have tomorrow. So, okay, so we have like four if two clients and three if one clients ready for the first DevNet, which is very impressive. Brother, do you want to give like more details on tomorrow's launch? Sure. So we have a configuration up yesterday. We had an initial configuration that we changed that a little bit. So we changed the validator sets and we changed the fork version on the Ethereum 2 site. Other than that, it's the basic familiar configuration you know from previous test nets. It's a main configuration this time down. It's not the minimal configuration you may be using locally. And red and in chat, you can find the link to this test net configuration. We'll set a boot notes right after the call and then deploy some notes of our own. And then I think today we'll just focus on connecting all of these notes, getting everything running. And then tomorrow at noon UTC, we will start the chain. So I would like suggest to jump on the Discord, one of the on the Ryanism Discord voice channel after this call to do some coordination on this first DevNet to understand who runs what and would be great if we have like full coverage of different mixes of each one and two clients in order not to miss any interrupt. I believe with four different Ethereum 2 clients and three different Ethereum 1 clients. We have to test at least 12 combinations. I think, or at least we will try to run all 12 of them. But then I also need other teams to run as many combinations as they can. And if you don't have validator keys already, please reach out and then you can get your menomic to participate with validators. Any questions to the Stackflow DevNet? What's the precise time it's starting again? 12 UTC. Gotcha. And maybe Proto will throw up a Zoom link 30 minutes before the congregate. We will be live a lot during like the run up to the testnet in Discord and chat and the Ryanism calls channel and we can do Zoom right before. Yeah, I'll just look to Ryanism Discord channel for coordination purposes. I think a lot of conversations will happen there. Back today and tomorrow. Okay, I see Peter just joined. Peter, do you want to give any updates on the catalyst? Mainly in the context of this short-lived merged DevNet that will start tomorrow. The update prior to you joining was catalyst seems to work because multiple people have interrupted this. Right, and I have like a follow-up question about like transaction propagation enabled for a catalyst mode. Do we have any like estimation on when it could happen? Peter, can you hear us? Okay, probably not. Okay, I'll ask later. Okay, let's just go to research updates. There is like the first update I have made to the folk choice rule section of the design document of the execution layer design document. This update is just to remove the recommendation on using the new block as the signal for the folk choice. Because even if the new block that is coming from consensus side is valid, it does not mean. I mean, this even as if execution payload is like valid one, it does not mean that the whole beacon block is valid. And depending on the implementation of consensus side of consensus layer of consensus client, it will be like it could be the case when they're like the new block has been sent to the execution layer and it's been valid. But yeah, but like state root mismatch happened on the consensus side later. And yeah, in that regard, in this case, the new hat won't be issued for this particular block. So that's why it's been removed. And the only trigger for the folk choice is the new hat message. I don't think like it has a big impact on implementations currently, but anyway. Wait, sorry. So this is the trigger for changing the folk choice on the execution client side from being group of work to be in transition mode. No, it's not about transition, but it's just about, you know, there was like, yeah, there was a record. Oh, it's post transition. Right, right. It was a recommendation. So you can was like, you can use like new block if it's valid and if it's like in a child of the head of the chain, you can switch the head of the chain to this new block, which might not, which depending on the implementation might not work correctly. Well, why is this, is this because we, we want the execution clients to not trust the, like it's a disquiet for this or Because you, you might like run things and so you might say you ran execution and consensus validation in parallel, then you might actually find that the some of the beacon block content were invalid and even though the Oh, I see. Or any type of like ordering issues on that. Right, right. I see. Okay. So like if the client basically if the client's implementation sent the execution block to the execution client before it did at least one of the other checks and if those remaining checks where it ended up like not asking that it will be a problem. Yeah, like for example, if you don't want to do this until the end, then you wouldn't actually know. And so you can't take the shortcut of like get the leaf block of the head. Right, right. Big sense. But whereas a new head message or something that would come to an execution clients after the consensus client did the full validation cycle. Okay. Yep. So that's it. Just pay attention to it. If you have started to implement this external folk choice stuff. The next update is the withdrawal design dog. Dimitri has like gained like this, this dog from his proof of concept implementation for the withdrawal mechanism. And this, this is what we will probably take into kind of spec for Ryan is in the next couple of weeks, because there was an idea to deploy with the roles to deploy the withdrawal test that. So, Dimitri, do you want to speak about it? Yeah, a few words. I'm working on this roles and I've created a specification. It's not actually a specification more like design document, but the spec could be made from it. The link is in the chat and in the agenda. And then if it back appreciated directly to me or by commencing HMD. It doesn't support partial withdrawals. It only works with validator exit, which leading to full withdrawal. But from what I made, I see special withdrawal somewhere around, and I am going to extend spec with them in a few days. I was skeptical about partial withdrawals in the beginning, but now I see we could make them without much pain. So I still think we should resist. It's so we will not, we will not see withdrawal messages one per day per validator. We should restrict it in such manner so it will be less frequent. And that's all for me. Any questions to Dimitri about this doc? I was able to review it. In general, I think it looks good. I left a number of comments on there and we don't have to go through it now, but I just want to make sure you saw them. And yeah, I think, I think the base of that can probably be extended with partial withdrawals if as long as the withdrawals are unique. And they have like a unique identifier or something so that the mapping isn't based on validator index. And that also allows for reusing the validator into the later, which is good. But otherwise, generally looks good. So I encourage everybody who's interested in the draws and or just want to take a look just take a look like like in the next week. So your questions on this court, like in comments to this talk. Definitely feels like a simple and clean method. So I'm happy about that. Yep. And yeah, the research updates. Yeah, that's because a lot of work happening on the right. Sorry. I was just going to mention that we are going to attempt to turn on the like core suite of tests for the merge spec that's in the repo for the next pre release. But as I say that I'm also realizing that the Ryan has emerged back is probably potentially diverged a little bit on the big content side from what's in the spec repo. So that might not actually be very useful, but we can talk about that, I guess, in a few days. If that is useful, I think we can cut some test vectors next week. It's primarily just like whether you can support the types and things because most of the changes are extremely minimal. Yeah, what do you mean by diversion? What has emerged? Oh, and I'm not certain of the case, but the had the Ryanism spec from the. Is that just pointing to dev currently or is that pointing to a particular commit on the big content side? It's pointing to dev. Okay. Gotcha. Then cutting the test vectors would be useful. I wasn't sure if it had pointed to like a commit that was from maybe a week ago or two weeks ago. Okay, I see. Okay, thanks. Yep. I think we're done with research updates. Let's get to spec discussion. Um, so any, any questions? I know that there is a work happening on the, on the state and probably blocks in complementation. Does anybody have any questions with regard to this particular work or any other work that happened on the execution layer from the spec perspective and from the researchers perspective? Okay. So I guess, yeah, everybody is busy with the Ryan is which makes a lot of sense. So I think we can get back to this. To this life in a couple of weeks. Um, any questions for the big and change side, the big and change back. So I have a question regarding the merge spec. I look at the merge spec and the, I think the merge shoe ideally be built, the merge spec should ideally be built on top of. Sorry, the shorting special be built on top of the merge spec because we've found the execution panel hater. I'm not sure how useful that is, right? Well, theoretically, these back part, like the changes to the spec that needs to be done are pretty independent, right? So like you can, like you can work on the two in parallel though, obviously, you know, there's not much value in actually implementing sharding before the merge goes through, except for just like testing value basically. Yeah. Okay. Current state of the spec is. Phase zero is stable. Everyone has implementations of it. And so it's easier to have the spec currently both of those specs merge and sharding be based off of phase zero so that if changes to the merge happen, if we want to go in and change the starting spec and vice versa. And so we kind of independently iterate, but once they stabilize and once there's like a very concrete order, like merge will go to main net first, which I think we all generally agree on. We would see like sharding be rebased on kind of the merge spec. And similarly, once I'll tear implementation doing the correction here sharding is already based on the merge back in the if two specs repo. Okay. Okay, because I don't see the execution panel hater in the region state, but maybe I'm missing. I think it just extends the state. Okay, got it. Anything else. Any other questions. Okay, open discussions. They want to discuss anything. Did we want to chat about the, how are you going to set up ranism nodes in here or do we definitely want to do that in a discord after. I would suggest to do it in discord after like in less formal manner, just like if it would be like an offline event, you know, so I would just like to say thanks. Implementers teams. Or their hard work that they just done to to be at this line. At this line, I mean, in terms of ranism progress. Thanks a lot to Proto for doing a lot of coordination and other other stuff. So I'm very excited about tomorrow's launch. Let's go to, I think we're going to just wrap up and go to discord. Or do we want to like take a 30 minutes break or kind of my preference is a 30 minute break. It's 11 30. I was going to say that for Paul as well. Yeah, okay. 6 30 am here. Nice to get some coffee. Yeah, let's just suggest to wrap up here and go to discord and whoever joins at whatever time so doesn't make too much. Okay. Thanks everyone for coming. Thank you. Yeah, thanks. Great work everyone. Thank you all. Bye bye. Thanks.