 Okay, let's get this started. Thanks everyone for joining second public 4844 implementers call bunches fall spec updates today and then hopefully we can spend a lot of time talking about definite three high level like last week. There were a couple, a couple different spec issues we have to go through. I think we resolved all of them so we'll go into those as we as we cover the spec and. Yeah, I, and then yeah, we definitely want to chat about CKZ G. There was some changes done to the interface and also support for rust and nim that we want to discuss and then. Yeah, trying to put together a spec for the dev net what that looks like talking about this blog destiny a bit more. And yeah, I think that's pretty much it oh and Jesse just added something about the cappella spec changes. So let me just start we ends gar you close the fee market issue and you opened up a bunch of new spec issues you want to just give us a quick update there. Where are we at on the fee market. Yep. So, the fee market PR is finally merged. There wasn't really any changes since last week's call the only one kind of substantive spec change that it happened was the one we agreed upon that is to reduce the minimum price per data gas down to one for the PR itself so that has happened and I think my understanding is that the current test net uses kind of the original value that that was there so basically that is the one place in which the fee market right now I think the spec and the test net then do diverge but other than that. So that's much now. And then, basically, I opened PRs for all the remaining places where at least from from what I can see about the the IP basically they're still things actual specs things that will change between now and bringing this domain and just basically so we have all of them open because people on all could have stood express a desire to basically get to something at least close to a spec freeze as soon as possible. And so these three places are one is just a PI again to change this minimum beta gas press back to something other than one. Yeah, it's more moment is in place of discussion so we could do that we could not do that we could change it pick a different value whatever but like at least, you know now there's a place where we can make the decision. The second one would was the one that we also talked about last week which is the returning the modules from the pre compile actually the pre compile does not currently return any value so it would now just return the modules although I didn't really give time for any time to add the rationale section I only did that yesterday evening but you're ready. Still already delivered and wrote something with the rationale. And there might be we might have to add something and not only return the modules but also turn the the some some second value I forget exactly what there was, maybe I can talk about it. And the second, and then the third one just for completeness. So we all kind of agreed in Bogota and everywhere that we should initially kind of reduce the throughput of the AP started the smaller one and then ramp back up in later hard forks. So just to actually get that into the spec I also created a third PR. That's maybe the one that the most people would have opinions on I just picked two blocks target for blocks max so 0.25 megabytes target but five megabytes max as something like the same starting value but if people are opinionated should be higher lower. Yeah, that don't be a good place to come there. And I think that's often mice. There's one more small thing that came up during kind of getting all this PR smudged. Right now, we do have external links in the AP which is a little bit annoying because that's against the editing rules. The bot is always unhappy. So right now, basically author approved PRs to not get auto merged. And we should fix it in some way we should either get the API some API editors to modify the bots and allow this or we should remove the external links but this is not a great place to be. Yeah, I think and I think. I think on that note, the API editors are literally discussing adding external links ASAP, and especially like having a sort of allow list for external links and the CL specs would definitely be part of that. I can follow up on that to see if there's a way to just like make that single change quicker. Yeah. So we're not always blocked on that. Any comments thoughts on the various spec changes that Ansgar just discussed the modulus one. Do we think that that it seems like the minimum data gas price and the reducing of throughput those are constant changes. And so it seems like we probably are comfortable with leaving those open for a little bit longer and having discussion, but the modulus one is an interface change. Do we think we can get that merged in the next week ahead of the next all for that so we can say like at least all the interfaces or yeah I think we can hopefully get to all the interfaces being being merged. Yeah, I would say yes. I'm just one of the modifications that's so nice to make we need to, you know, just the modulus we also need the block size, so 496 as a value should also be returned. But yeah, that's all I don't see quite happy. So there's no there's no like contention around the approach. It's just a question of like actually merging it because I know on the last call we had like four different options. But, um, yeah, we don't know about that. What were they, what were the options. So the italics had like these four options. So, two of them were like modulus opcode. And then, and then yeah there was a question of taking the modulus as an input versus return it as an output. I think we all agreed that we preferred it as an output on last call. But then the, yeah, the only other design choice was would we want this as an opcode instead. So the opinion is no, but I don't know if there's someone who like strongly feels we should have it as an opcode instead. I think we had the whole debate about this last time, and we landed on that. Yeah, so that's anyone. Okay, great. Yeah, let's try and get this much in the next week or so. And yeah, that would be nice to come on awkward ebbs and have only basically the two constants left to tweak. Yeah. And Marius, what do you mean in the chat so we need a spec at some point that block transactions are not sent via broadcast anymore. So if we allow block transactions to be sent via broadcast that opens up with those vector on the transaction pool. And the thing we came up with on in Bogota was to disallow transactions to be sent via broadcasts and so we have to turn to two types of like sending transactions basically one is just broadcasting them. We usually broadcast to the square root of the number of peers. And the other way we do it is we announce the transactions, the transactions that we have and peers can ask for the transactions by, by, by hash. And we spec E68, which basically enhances this announcement message so we don't not only announced the transaction hashes but we also announced the transaction type and the transaction size. And doing so makes it really easy for clients to only pick block transactions or only pick non block transactions, depending on on the state if they have enough block transactions in in in the transaction pool then they will not fetch further block transactions. And, or if they, like if they are currently being tossed or don't have the, the, the very like that the compute bandwidth then they're not going to fetch block transactions. And we have to spec for 68 we and also we rolled out the implementation and death. But we don't have the spec that plot plot transactions are not allowed to be broadcasted and broadcasting block transactions is a protocol violation. And we kind of need this for security at some point so we need to create a new spec for that. And so this means just so I understand correctly it's like you can still send a blood transaction in the public mempool but your peers will have to specifically requested from you. Is that correct. It's like you're not broadcasting the transaction, but you're announcing the transactions to your peers, and they will fetch it from you. It's just like turns around the announcement mechanism. Right, I was just wondering. Am I correct in my understanding that right now the kind of the broadcast will not include the gas price or the data gas price. Yes, the broadcast only includes the size of the transaction and the type of the transaction. It's good enough. I think it will allow you to create a transaction pool that if you don't have any valid block transactions and you have enough time to verify them, you will fetch them and you can hold like maybe 100 block transactions in memory or something and make sure that you have enough block transactions to fill the next couple of blocks. Should you add the max fee to that so that when you broadcast a transaction you're saying it has this max fee and so this way I can know if we start adding more fields then it becomes very brittle because people can always lie about these fields. Yeah, you need to know that. You need to verify the balance. How easy would that be to later modify because the nice thing of course is that this is not like a consensus change. So like it sounds like this should definitely be good enough to kind of roll the EAP out and everything. It's very easy to just create a new EAP protocol version and add fields to this announcement message. Because it feels like this is something where like six months into having the EAP live and just seeing behavior we can always just revisit and see if maybe some propagation of block transactions is not ideal and we can improve it or something. But this would definitely be sounds like this would be good enough. For the for the disabling of the gossip. Is that an extension to eat 68 or do we need like eat 70 for that. It's 69. No, we had it 69 already. We kind of made the choice not to go ahead with it's 69 because it's 69 just adds the withdrawals to the block body. But we changed the structure of the messages before. But when we added 1559 without a new EAP protocol version, and since it's only optional fields. It's kind of fine not not to create a new EAP protocol version. This kind of similar thing with this. We can create a new EAP protocol version, but it's not really needed. It feels like conceptually having it all in each 68 would be nice because you can say this is the EAP protocol version change for 444. So, the why we didn't do it in each 68. Now is because we don't we want to roll out each 68 now. And it's not a change that needs to know about withdrawals it doesn't need to know about block transactions. It just does modifies this announcement message. And so we can, we can roll it out now we can have clients update. And in six months we can we can actually use it. Okay. That's the idea. Okay, so then let's split it. Does that make sense. And this may be a dumb question, but I'm trying to learn what what what's spending us and just putting this in for a 444 as like a component of the specification. Networking just has this. So having having this, this rule about the block transaction actually kind of fits into for it for fall. So, I, there would be my proposal to editor for it for fall. Yeah, I don't know. And is it basically just saying these transactions cannot be gossiped in the mempo they need to be announced using each 68 and then sent the peers. Yes, exactly. Okay. So do you want to make that change or is it helpful as somebody else makes the change to the spec. I, I'm not an author for it for fall I have no idea about the spec of for it for fall. So I don't like I don't want to improve there. If someone wants to take over that will be really nice. And I can, I can help them with it. I can do it and also just to mention because those are the last small changes with a few market PR and someone pointed out that the mempool issues section was no longer kind of relevant because that was written for with a dynamic block pricing in mind, and also kind of charged dynamically in gas. So that was mostly deleted and replaced with like a small section this much research does already say that basically recommended changes would be to no longer propagate large transactions. So I wanted to to link to to Marius's EIP but again one of these external like like it's not an external link but it's a link to an EIP that was not yet merged and that's not allowed either so I couldn't get linked to it, but once that is in a state where it's not allowed to link to it and it would be small change to actually basically explicitly mentioned it. Yeah, I guess, is it possible, can we do the change now without the links, we can just mention E68 is in text, right, and we did this for the merge EIP they get around this. And then once it's merged, we can just add a link but I think it would be good to have a PR for that sooner rather than later, even if we don't have a merged link to the actual E68 EIP. Sounds good. And I can double check with Marius that the way we mentioned in the EP makes sense. Awesome. Thanks Ansgar. Okay, there was another PR, is Terrence here actually? I don't see him but Terrence added. I'm here. Oh, okay, sorry. Oh, sorry. Yeah, lots of people on the screen. Yeah, you had your PR for the engine API that you wanted to discuss. Yeah, I just posted it in the chat. So yeah, don't want to take credit away. That was that was POTOS PR but I do think like we need to do something with it other than just having like the pre-request out there, it's been there for a few months. I think there's two ways to go about it. The first way is just merge it to the master. And then because we're going to have a V2 at some point anyway, so therefore we have a V2 for the long term, we can just deprecate this one. And then the second option is just have like a 4044 folder and just put that in the 4044 folder similar to what we did with the consensus spec. I just don't think like I just don't think for the short term in a PR is a good idea because first of all, it is very hard to find. Like you told me and my teammates a few minutes to find it. So yeah, I'm open to both options and I'm curious to hear what people think. I don't think there's any NGAPI authors here unfortunately, but whoever is working or whoever has the right to merge NGAPI PR feel free to speak out. So is this about whether to like make the get payload versions and the new payload versions like different from prior versions so like having that version increment as the payload changes? Right, so I think in this definition, which is V1, get blob is a separate engine API code. So, but then for V2, I think it's meant to be coupled so when you say get payload, you also returns the blob bundle as well. I think for now, we just have to worry about V1 because that's what get has implemented and it's quite nice. I mean, I don't think there's not much implementation complexity. It's just two codes versus one code. But yeah, so my point is just like, if we have this definition, I think we should put it somewhere else that's more official so therefore other client can begin experimenting it such as like nevermind and like, yeah, basically. Yeah, I guess I would rather not set up a whole 4844 folder because we don't really have that in the execution API, it's like there's just one spec. I would lean towards just merging this and then maybe the two people I'd want to get like a sanity check thumbs up on or Miguel and Matt, who both let comments on the PR, but I can send it to the two of them, see if they have any objections to merging it as is. And then yeah, we can we can discuss the V2. Yeah, the V2 method separately but I agree having this actually merge would be would be good. Okay, yeah sounds good. Yeah. So, and assuming that like yeah either Mikhail or Matt doesn't have an objection I think we can just merge this. So one thing I would say though is, if we keep get payload separate. Like, we need get payload to have the pre and post fork versions of the payload. So like, I would imagine this would look like having a get payload be one. That's like the merge fork get payload V2 that's Capella fork, and then either include the execution payload fields and that one or we would need to be three, in order to separate the withdrawal version from the Capella version. So like, if you have to implement three versions of that like I guess that's coming. Can we not have them as optional fields in V2. So we already have V2 for withdrawals. And I don't believe we actually need we V2 for withdrawals we could just have optional few. That's the way we implemented right now we have V2. And I think it should be possible to read the blob stuff as optional to be to. That's in fact the way I'm adding it in right now, just adding another optional field seems to be fine. Okay, I mean that's fine with me. Let's watch this one as is as a separate call which we've is there still. Yeah, I guess, is there still value in this separate call if we're adding the optional fields to get payload V2. In the separate call as is problem. Okay, so I don't know. Should unblock people working on prototypes now to have this get blobs bundle V1 commerce, or should we close this PR and instead open one with get payload V2 with optional types for the blobs. I think either is fine but we just have to make a decision because like from the execution of their client point of view, they need to know what to implement. We don't want them to spend time working on the separate call by the same time no one will use that right. So I think it's important to come to consensus soon and I do think like maybe on Thursday, we can bring this up again to see what people prefer. And yeah. Oh, prodo do you want to give your Why do you like the blobs bundle. We spread it out to enable people to work on this without having merge conflicts or consistency issues with the ongoing withdrawals work and the changes to the engine API, but just isolating it to a single method it's really easy to work with. And since we only call this API against one single note, we know the content is consistent. We can expect the blobs to be there after we see the blobs in the block or the payload that we just retrieve with the regular methods. So I don't think there are many consistency issues to worry about, and we can just use this method. Long term, a combined methods might make sense, but I think it's very like premature optimization. Just one one small thing it would be. It's very important for execution layer clients to once you once you call get payload to stop building new payloads and just cash the one that they have at this specific point. I think it's something that most execution layer clients already do. But it's just something to keep in mind for execution layer depth. I guess, yeah, given all the prototypes use this now, and it's easier to work on it separately I would also lean towards just merging it if like client and Mikkel don't see a strong objection and then we can yeah. In the worst case we can just deprecate it in favor of get payload be to an optional fields once. Yeah, once we're ready to integrate stuff together a bit more. Anything else on this. Okay. Next big spec thing is the rebase on the consensus there side of Ford for four on top of Capella. And I'm curious on the agenda for the CL call later this week but curious if anyone had thoughts about this. Yeah, I'm in the, I'm in the process on the execution layer side but in geth of pulling in the withdrawals PR into our. Yeah, P4A44 DevNet. I think Jesse is working on the load star version of that for the CL and Mofi prism. I think from our end, sorry. Yeah, sorry for interrupting you I think from our end. So there's two withdraw PR out there today. I think one from Danny one from voters, there are essentially changing how the withdrawal works by basically by by basically removing the withdrawal queue, and it's not clear to us, like, whether those will be merged or whether we'll stick with the old way, but that actually does like dramatically like basically different with the current propellers back today. So for us, we're waiting until Thursday's consensus of their call to basically to to to to basically see we can come consensus on like, on, on like what would drama can some will be before we start putting for a full four on top of propeller. Okay. What does it look like in the code right now for you. Is it on the metrics. Yeah, right now it's on top of Bellatrix but since like, yeah, but since like Capella, we're not sure what the final state of withdrawal will look like we're just waiting until Thursday but yeah it kind of sucks because I ideally we can replace like today pretty easily, but even that withdrawal is still kind of in the flux. Yeah, we're just waiting on that. Okay, got it. So I guess, I'm not sure we'll be able to close out the withdrawal issue on Thursday. Hopefully, but I, yeah, I think there's a chance we still discuss it for another few weeks. What's the best. What's the most useful thing for like people working on prototypes now if, if we don't have a clear withdrawals back on the CL side. Well, I think we need to know what is the scope for definite to be whether withdraw should be there and then if withdraw should be there is withdraw just part of like the big hand block and because they object, or, or is withdraw part of the state transition. I think those needs more clarification. Yeah. Right. I was going to say I thought we decided last week we do want to include at least the, you know, the block changes for Capella withdrawals. Right. Do the, do those change based on POTUS PR Terrence. Um, so those change would matter because in POTUS PR the beacon state does not have the withdraw queue anymore versus currently the beacon state has the withdraw queue. So, but if it just become blocked itself then it's probably fine which, but if the beacon state it doesn't matter. And yeah, and then I also assume that you just have a flag that says hey we're going to skip withdraw or something so therefore like basically the withdraw objects obviously stuff with zeros or something here. Yeah, my, my preference would be that like, we don't want the dev nets to be blocked on withdrawals work. That said, if there's a way to make it somewhat like, you know, future proof that's like, ideally, you know, we sort of stub withdrawals or something so that like it just doesn't require a ton of work. Once we have a withdrawal spec that emerge everything over. I don't know what's the simplest way to accomplish that but I don't think we should try to test, given how like, yeah, unstable the withdrawal spec is right now. I think if we have a clear target for 444 that's somewhat independent. That would be best. I don't know if there's a way to do that in client teams, is that just including the fields but having zeros stub. Yeah, I think for beacon block is fine we can include beacon, we can include withdraw those in the beacon block. I don't think those are. Yeah, I think those are fairly stable. I don't know what state I'm worried about, but then you just also kind of weird that you have withdrawing the beacon block by telling the beacon state. And yeah, so I think my preference is for definitely to unblock this just go ahead without withdraw that's my personal preference but yeah I'm also happy if you like your other feedback as well. Yeah I think for us, it'd be generally better to include the withdrawals consensus types, and then step out the consensus logic. So that mean like stuff out the block processing and the state processing. But then just keep the fields in the block in the state so they would just like remain empty because we'd never apply anything to them. Yeah, so that'd be preferable for us. But it does kind of stink that the withdrawal types might change. If there's no corresponding like state transition block transition logic and it's relatively easy for us at least to change the update the types to reflect the type changes but I don't want to make this too lighthouse centric. Yeah, yeah. I mean we can do that as well. I mean, I think we're, I think you're assuming the latest consensus spec which that withdraw has a cure right because we actually have that implemented we're just thinking whether would you remove it or not. Yeah, yeah. Yeah I mean my, our preference would be to keep the Capella types given that they are a little less stable. And then just once we have a dev net target just like will freeze that and maybe we'll have to diverge from the withdrawal specs to some extent on the dev nets but yeah I don't know maybe we'll have more clarity Thursday. Yeah I was going to add I mean we had at least a couple more weeks of work dev net youth is there a chance stuff will become more clear or what's the contentious issue here Tim. Terrence, I think you can expand it better than me because put us right but just how the withdrawal queue is designed to accommodate partial versus full withdrawals beyond that. I'm not sure. Right, so there's basically a trade off right now between in terms of like specs of simplicity versus us. So there's so there's two way to go about it the first way is just like include the withdraw queue in the state. But with that it's slightly more complicated for the beacon stages now you have to implement the queue. And then this is also client implementation every client improvements is differently. People have different preferences, and the other prefer the method it just to remove the queue from the beacon state, but that kind of have a shape you ask for like people they want to do full withdraw they have to wait a few more days. And that's the trade off but yeah I don't want to like go on rent here but yeah I think that Thursday meeting we can follow up more on this. I mean, I don't have a perspective on I'm just curious whether why it would take more than a couple weeks to figure figure out this issue, but sounds like. I think yeah. I think a couple weeks is what I would expect as well. It's just the PR I believe came up like late last week so like on Thursday's call we might have a resolution I think if we don't it would be the call after that right like I don't think it would go beyond, or even two calls like it doesn't need to be dated on the call. But I, it's possible that in two days we don't have a resolution, but in two weeks, I'm, I would be surprised why we wouldn't. Okay, because I would highly prefer waiting on some stability and the withdrawal spec because we know you have people or one go out without it right so I'm on this. You know, strongly preferring we get as much in there for our DevNet three is possible. That will put us in my opinion the best shape. So we can definitely. We can definitely wait until at least Thursday's call. Yeah, does that make sense everyone. And I had, okay, I had a very rough hack and be with what I think we should aim for in the DevNet. Let me share the link here and I'll share my screen as well. Yeah. And I'm curious, yeah, what people think about this. So high level, obviously, 4844 in and then if this PR has been merged this would. Yeah, so this is merged so the dev, the fee market PR would be part of the EL spec. I don't think we have any other pending PRs on the EL that we'd want to include in the DevNet. What about the modules. Yeah, I guess. Is that something that we want to try and have in DevNet three. Minor enough toward we can do it either way. I don't feel strongly. They'd be preferable if we could get it in but So I think, yeah, let's try to get it in then, especially if we're waiting. So if we think we can resolve the budget is in the next week or so and we're waiting on withdrawals on the CL side as well. I would rather we get it in. Okay. And I think the gas price and the number of blobs we can just leave as is. I don't think we need to change the constants there. Is that reasonable for everyone. And then each 68. Do we want to have this as part of the DevNet. I guess do we need it. Like, yeah, I'm curious, Marist, is this something you think we need as part of the DevNet or if client teams are going to start working on it anyways, should we just like leave this out of scope and if a certain client has it and great but Yeah. So for the next four and four for DevNet, should we push for an each 68 implementation across all clients. No, no, no. Okay. And so this means, then what I would also exclude is this upcoming PR by Ansgar about not broadcasting the blob transactions. Because if we don't have each 68, we need to broadcast the blog transactions. I'm just for the record though but by the way I would prefer if this if basically we only include that into the four specs anyway as a recommendation for client developers I don't think it should be part of what we technically spec out like it should be part of the issues rationale because it's not part of the spec section, because it's not a consensus change. But I could be a little bit people feel strongly that we that it should be. It kind of will be a consensus change for us. But a bigger change than just a spec change. Because we will drop nodes that don't adhere to this. Right. Okay, because it's like it's a protocol violation. Yeah. Right, but it's still more like we don't have a EIP for you're not allowed to toss your peer, but you'd still also be dropped. Well, we, if you, if you toss us right now we're not going to drop you. Right, or like send map on whatever whatever I can, and I'm sure there's something peer to peer that I can do to make it drop me. And there's no yes, send an invalid packet. Right, and like, yeah, and so. Yeah, we can see about it I wouldn't give her about having. Okay, but yeah, let's, let's leave all of that out of DevNet three though. What you're thinking for leaving that out of DevNet three. I guess it's 68 being like having to add all this peer to peer code beyond the core consensus logic. That would be my. Yeah, we don't have we don't have implemented yet, not even guess. We only have the E68 change but not like the different transaction pool the only like dropping people on if they send if they send stuff on broadcast and I would also leave it. Because we can, because without it, we can figure out if all the consensus changes work across all of the clients right and then this is this extra step of just the networking across all of them but if the core consensus logic does not work. Yeah, that's, that's a deeper problem. Okay, on the EL side anything else that's missing or that we should specifically exclude. I think this generally looks good. Okay, CL spec, a bit more tricky. So, these recent changes probably aren't that recent anymore I did this last week but just as a heads up like we couple the blobs, the blocks for for recent history but believe you decoupled them for historical sync. We lowered the blob retention period about two weeks. So this is already merged in the spec but just wanted to highlight them. Oh, I see this in chat. I'm not sure what your question is Alex say. No, it's. Okay. In terms of just pending PRs. So we're basing on to Pella. We're going to wait until the withdrawal conversation is resolved it might not be this PR. But yeah, we'll have to do something along those lines. But not for now. We had this other PR to the update the interface for KZG. I know we had this on the agenda as well. George or Dan Cradd, do we have you want to give a quick update on where this is at and if you think we should include this in the next iteration of the DevNet. Uh huh. So, the idea is that in August we made the proposed API for the case G library that like clients would interface with that API was pretty low level. So as to make the C library, the C KZG library pretty minimal. But in Bogota, we discussed these with Duncan and Ramana who know more about how the case G library looks like. And they're okay with making the crypto API, a bit more high level so you know like instead of exposing like 11 functions. There's three high level functions. The nice thing about this is that this is less burden to the client devs so that they only interface with a high level functions and they don't need to care at all about how the cryptography works they don't need to do all this. And Fiat Shamir stuff. All of this is handled basically by the case G library. So, I was away but today I came back and I've been kind of reviewing the PR the changes since then. And I think I can get it ready today for merging. And Ramana told me that he has made most of the changes on the library side. So we are pretty much kind of ready on this but depending on when the next definitely is, it might be a better idea to keep the old thing going in. I don't know like if it's in two three weeks I guess it's a good time to use a new API but if it's like this or next week. Potentially it's better to use the old API for more stability. It would be more like two weeks because we already discussed we're going to like wait for withdrawals on the CL side which will probably take, you know, up to a week and, or something like that. So I think, if this is on the order of two weeks, it probably makes sense to try and go for it and yeah, have it as part of the spec. There's still a good deal of crypto code in the clients that would be nice to move out. Maybe maybe that, you know, fits nicely with this work. And there's crypto code that won't be implemented in the clients. If this change lands right start starting now, I won't implement all of the crypto code that will be in these libraries would much preferred for it to be in CKG. Okay, that makes me lean toward let's let's include this spec and let's include this PR as part of our testnet spec if it means that yeah we can simplify a bunch of the next prototypes and and then if next week, I guess next week let's make sure to like come back to this on the call and if for whatever reason. You know, this is being delayed or whatever and like we're like I wouldn't want this to hold up the testnet but I think if, if we can have it then we very much push for it. Agreed. I will talk to Ramana who is not on this call and ask his opinion about how it's going to be next week but from what he said I think it should be okay. Of course, new bindings will need to be written because the maybe I don't know I need to see the interfaces. I think some of the bindings are already done basically I think like he's been following very closely the PR already. Yes. So I think the findings already. I mean there might be minor adjustments to the bindings but generally we've already adjusted them to the new format that's all bytes and everything. Is there an open branch or something for CKCG that implements the new SPAC just because. Yeah, there is. Yep. Yeah. For it for four underscore 30. That's the one. Okay, and then on the CL side we had another open PR that was blocked on this fee market changes. Should we, can we go ahead and merge this for a little. Once the PR from Ansgar with the fee market is merged then yes. This is merge yeah. It was like this morning. Yeah, yeah, yeah. This is probably worth just sanity checking that there was no changes in the PR that made that sort of from this but yeah check the if there are any changes there and then this is ready. Cool. So then this is something we would want in the DevNet as well obviously because it's like the counterpart on the CL side to this latest fee market change. Anything else on the CL side that we would want to specifically include or exclude from DevNet three. And then on the engine API we already discussed this but basically this is, we would use this blob specific API rather than get paid will be to and then we can try and get this merged today or tomorrow. And then lasting on the DevNet three scope. There's a question by Alexi in the chat about withdrawals on the EL side. My feeling is that if we're going to be including them on the CL side we should also include them on the EL side but curious what people think about that. Well, so the out effect whether we have withdrawals in the payload attribute struct which is like CL EL API. My preference would be to include that just because we're going to have to eventually included anyways but I don't know. So this is basically we include them in the in the EL and also in the engine API. Is that the implication here. So we would include withdrawals in the payload attributes portion of the engine API, right as well as like all the execution payload structs would include withdrawals fields as well so that would like obviously impact the execution API engine API endpoints. Okay. Does this make sense for everyone. It makes sense to me and it's also worth like we'll probably should also ask tattoo Nimbus and then as well just there are like, and just they're also like the client team so I'm curious to hear their thoughts. Anyone I see Ben from Deku here I don't think there's anyone from Nimbus. You can see me. Yeah, nothing to add. I can't speak intelligently to this need and Rick over these not available today so he will catch up later and then feedback. I guess we're probably going to be discussing withdrawals and how they relate to definite three next week as well so. Yeah, it's worth having teams look into it but I think we have a bunch of other things that are a bit more settled that we can make progress on and until then. Roberto you had started a GitHub issue the track sort of status of things on the DevNet. So I guess if people want to share updates. There that's the place ago. As they're working out. Yeah it's just meant to be in a form informal tracker. Okay, I have a lot more clients starting to be implementing it hopefully. Anything else on DevNet three. Okay. And then we have a few minutes to go. Oh one I guess yeah one more thing I wanted to make sure we cover is the CKCG bindings. We said we have for planning to have some for go. Rust and them. Do we have a plan to expose things. What's so for us. Oh, I was just going to say for us. I think Ramana volunteer to help with that. But that hasn't been progress I think just because the API so stabilizing. Yeah, so in terms of the API is also best if someone from a client who wants to consume it comes forward and then. Then it can be done together I think Ramana is happy to work that out but it's hard to just build an API for language that you don't actually use yourself and then yeah you'll probably not build the nicest API for that language. Yes, so Poana is available from our team to work on that. So he's out today but I like so you have a comment saying CKCG needs additional discussion. We have a minute to go is there something in specific you think we need to discuss or on this call or yeah what do you think is like the most important thing here. Yeah, it will be cool to have like synchronized version of between go KZG and CKCG and all the violence in terms of like cryptography outputs consistency so I cannot we cannot synchronize with go with get because because with CKCG we have different outputs. We have different formats in setup in a KZG setup like that, and it prevents us from like pinching the API actually and well it's not yet cross platform this library CKCG and we could collaborate on fixing this inconsistency and the absence of other platforms. It's not just plain simply. So I know we have a big group chat for CKCG. Is that the place where we should discuss this or do you think we need like an actual call to go over this in more detail, and what do you think the best way to get this result. Yeah, maybe let's continue to in the chat I just wanted to raise the problems and find someone to collaborate with this. So who's currently working on go KZG actually is a proto lambda working on it or Yes, I mentoring go KZG. I just need the stable spec. Yeah, something of the spec implemented. Yeah, that's what I would suggest right so let's wait until we have that and that should be like very soon. And then, then we just implement the same interface for both. Okay. Okay, the only thing we didn't have time to cover on the call was the blob testing we discussed it last week as well and we have a group chat for that so I don't think there's much to cover. Last thing before we hop off there's daylight savings happening in the US and Canada this weekend. Our people okay if we move the call to 1530 UTC rather than 1430 so it'll be an hour for North Americans, it would be one hour later, then it currently is, or it would be a sorry for North American it would be at the same time next week that it currently is for Europeans it would. I don't know when you all change times. Oh you already did it. Okay. Yeah, we're on. So, is one hour later, like 1530 UTC does anyone have a strong objection to that. It makes life of North Americans slightly more tolerable. I don't know what time that is in Europe though. 1330 in the UK and full 30 in central Europe. Okay, that seems reasonable shall we. Asia Pacific lives matter. Yeah, lighthouse and take a team. 1530 UTC versus 1430 UTC make a big difference. In Australia. Well so I think it's pretty late regardless for them. So, I mean I can represent lighthouse said whatever. Okay, oh, I nice I did not I didn't I assumed you were also in Australia did not know you had spread to more confidence, which I know. Okay, that's great. Okay, I'll move it to 1530 UTC then. Yeah it doesn't seem like they're super strong objections. Sweet. Thanks on everyone. Yeah, this is really good. Talk to you all on a sea alcohol in two days. Everyone. Have a great day. Bye. Thank you. Thank you.