EIP-4844 Implementers' Call #2

thank you okay let's get this started um thanks everyone for joining second public 4844 implementers call um bunch of small spec updates uh today and then uh hopefully we can spend a lot of time talking about uh definite three um high level like last week uh there were a couple um a couple different uh spec issues we had to go through uh I think we resolved all of them so we'll go into those as we as we cover the spec and um yeah I and then yeah we definitely want to chat about uh ckzg uh there was some changes done to the interface um and also uh support for uh rust and Nim uh that we want to discuss and then yeah trying to put together respect for the devnet what that looks like uh talking about this blood testing a bit more and um yeah I think that's that's pretty much it oh and Jesse just added something about uh the capella spec changes so maybe to start uh we nsgar you close the fee Market issue and you opened up a bunch of new uh spec issues do you want to just give us a quick update there um where are we at on the free market uh yeah sure so um the free market PS finally merged um there wasn't really any changes since last week's got the only one uh kind of substantive uh spec change that did happen was the one we agreed upon that is to reduce the um the minimum uh 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 FEMA could right now I think the spec and the the test net then do diverge but other than that um nothing changed so that's much now um and then basically I I opened PRS for all the remaining places where at least from from what I can see about the the Erp basically there's still things like actual specs things that will change between now and um bringing this domain uh just basically so we have all of them open because people uh on Awkward as did Express a desire to basically get to something at least close to spec freeze as soon as possible um and so these three places uh one is just a pi again to change this minimum beta guess perspective to something other than one um yeah it's more more made as a 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 um the second one would was the one that we also talked about last week which is the um uh returning the modulus from the pre-compile actually the pre-compile does not currently return any value so it would now just return the modulus although uh dunkrat um I I didn't really give time for any time to to add the rational section I only did that yesterday evening but you already um still already at 11 and and and and wrote something about the rationale um and there might be we might have to add something not only return the modulus but also even the [Music] um uh the the some some second value I forgot exactly what there was uh maybe don't talk about it um in a second and then the the third one just for completeness um I think we all kind of agreed um in in Bogota and everywhere that we should initially kind of reduce the throughput of the AP started the smaller one and um and then ramp back up in later heartfox 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 um two blobs Target for blobsmark so 0.25 megabytes Target point five megabits Max as something that seems like the same uh starting value but if people are opinionated should be higher lower um yeah that that would be a good place to to also come there and um I think that's all for my there's one more small thing that came up doing kind of uh getting all this PS merge uh right now we we do have external links in the Erp which is a little bit annoying because um that's against the Erp editing rules so the bot is always unhappy so right now uh basically author approved PRS do not get Auto merged um we should fix it in some way we should either get the AP editors to modify the Bots and allow this or we should remove the external links but this is not a great place to be in yeah I think and I think yeah I think on that note the EIP editors are literally discussing adding external links um ASAP and especially like having you sort of allow list for external links and uh the CL specs would definitely be part of that um I can follow up on that to see if if there's a way to just like make that single change quicker um yeah so we're not always blocked on that um sweet any comments thoughts on uh the various spec changes that Ansgar just discussed the modulus one do we think that that it seems like the minimum data gas price in 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 the next awkward tab so we can say like at least all the interfaces are yeah I think we can hopefully get to all the interfaces being being merged I I think I I would say yes um just one trivia modification that someone is made we need to you know adjust the modulus we also um meet the size so 496 as a value should also be returned but yeah that's all I don't see quite happy but tomorrow how's it 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 I don't know about that I haven't heard about that uh what was metallic had like these four options um so two of them were like a modulus op code and then and then yeah there was a question of taking the modulus as an input versus returning it as an output I think we all agreed that we preferred it as an output on last call um but then yeah the only other uh design Choice was would we want this as an opcode instead my personal opinion is no but I don't know if there's someone who like strongly feels we should have it as an OP code instead I think we had the whole debate about this last time and we landed on that yeah so that's anyone else okay great then yeah let's try and get this merch in the next week or so um and yeah that would be nice to come on Awkward abs and have only basically the two constants left to to Twitch um in the EIP yeah um Marius what do you mean in the chat so we need a spec at some point that blog transactions are not sent via broadcast anymore so if we allow plot transactions to be sent via broadcast that opens up with those Vector uh on the transaction pool and uh the thing we came up with on uh in in Bogota was to disallow transactions to be sent via broadcasts and so we have two 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 uh the transactions that we have MPS can ask for the transactions by by uh by hash and we expect East 68 which basically enhances this announcement message so we not only announce 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 blob transactions or only pick non-blood transactions depending on on their state if they have enough Club transactions in in the transaction pool then they will not uh fetch further blob transactions and uh or or if they like if they are currently being tossed or don't have the the uh the the very like the the compute bandwidth then they're not going to fetch block transactions and um we have to spec for 68 we know also we rolled out the implementation of death um but we don't have the spec that block transactions are not allowed to be broadcasted and broadcasting block transactions is a protocol violation and um 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 Blog transaction in the public mempool but your peers will have to specifically request it from you is that correct yes exactly it it it's just like you're not broadcasting the transaction uh but you're announcing the transactions to your peers and they will fetch it from you it's it's just like turns around the like yeah the announcement mechanism basically uh enter right I was just wondering um am I correct in my understanding that right now the kind of the broadcast would not include uh the the the gas price or the other that they take us price uh yes the broadcast only includes the size of the transaction and the type of the transaction okay and that's it's it's it's it's it's good enough um I think uh it will allow you to create a transaction pool that uh if you don't have any valid Trend any valid plot transactions and you have enough time to verify them you will fetch them and um uh you you can hold like maybe 100 block transactions in memory or something and make sure that you have an enough block transactions to fill the next couple of blocks should you add the max key to that so that when you broadcast a transaction you're saying it has this Max fee and so this way I can know like if we if we start adding more Fields then it becomes very very brittle uh because people can always lie about these kids yeah yeah you need to know the okay I see you need to verify the balance how easy would that be to 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 it's it's very very out and everything it's very easy to to just create a new use protocol version and add fields to this announcement message okay because it feels like this is something where like six months into having the Erp life and just seeing Behavior we can always just revisit and see if maybe some I don't know specification of book transactions not ideal and we can improve it or something but this should definitely be sounds like this would be good enough for them and so for the for the disabling of the gossip is that an extension to e68 or do we need like 870 for that um it's 69 um no we had 869 already no it's uh we we kind of made the choice not to go ahead with each 69 because it's 69 just adds the uh withdrawals to the block body um but we changed the structure of the messages before um for example when we added 1559 without a new youth protocol version and since it's only optional for you it's it's kind of fine not not to create a new easy protocol version um the kind of similar thing with this um we can create a new product each protocol version but it's not really needed yeah it feels like conceptually having it all in e68 would be nice because you can say this is the eat protocol version Change Report so why we didn't do it in e68 now is because we we want to roll out if 68 now oh um and it's not a change that needs to know about withdrawals it doesn't need to know about blob transactions it it just does modifies this announcement message and so we can we can roll it out now we can have clients update and um in six months we can we can actually use it okay that that's the idea okay so then let's split it let's put it 69 does that make sense and can you and this may be a dumb question but I'm trying to learn uh what what what's preventing us from just putting this in 4844 as like a component of the specification networking just has this so uh having having this this rule about the plot transaction actually kind of fits in into void for four um so I I that would be my proposal to editor 4844 um yeah I don't know it is it is it basically just saying these transactions cannot be gossiped in a member they need to be announced using p68 and then sent the peers yes exactly okay did you want to make that change or is it helpful as somebody else makes the change to the spec I I I'm not an author of 4844 I have no idea about the speaker for it for four um so I don't like I don't want to intrude there um if if someone wants to take over that would be really nice and I can I can help them uh with it yeah I I I can do it and also just um to mention because that was one of the last small changes with the free market PR and someone pointed out that the mempool issues uh section was no longer kind of relevant because that was written for with like a dynamic block pricing in mind like when it was still kind of charge dynamically in gas so that was mostly deleted and then replaced with like a small section this motorization section does already say that basically recommended changes uh would be to no longer propagate um large transactions I kind of wanted to to link to to marius's um EAP but uh again one of these external 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 we allowed to link to it and it would be small change to actually basically explicitly mentioned I didn't stick to 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 um and we did this for the merge IP they get around this um like 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 dip sounds good and I can um double check with Marius that um the the way we mentioned in the Epi makes sense awesome thanks Sam Scott um okay there was another PR at is Terence here actually uh I don't see him but Terence added uh yeah I'm here oh okay sorry oh sorry yeah lots of people on the screen um yeah you had your PR for the uh engine API that you wanted to discuss um so yeah don't want to take credit away uh that was that was photos PR but I do think like we need to do something with it other than just having that like the pull requests out there it's been there for a few months I think there's two ways to go about it the first way it just merged it to the master and then because we're gonna 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 4844 folder and just put that in the 444 further similar to what we did with the consensus back I yeah I don't think like I just don't think for the short term you know PR is a good idea because first of all it is very hard to find for like like to 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 and uh I don't think there's any engine API authors here unfortunately but whoever is working or whoever has the right to merge in GNP IPR feel free yeah to speak out so uh is this about whether to like make the get payload versions and the new payload versions like different from prior versions so like having the version increment as the payload changes right so I think in this definition which is V1 um get Blob is a separate engine API call so but then for v2 I think it's meant to be coupled So when you say give payload he also returns The Blob bundle as well I think for now we just have to worry about V1 because that's what Gap has implemented and it's quite nice it is I mean it I don't think there's that much implementation complexity it just two calls versus one call but yeah so my point is just like if we have this definition um I think we should put it somewhere else that's more official so therefore other clients can begin experimenting such as like never mind like and and and like uh and 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 apis like there's just one spec um 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 and Matt who both let comments on the PR but um I can I can send it to the two of them see if they have any objections the emergency merging it as is um and then yeah we can we can discuss uh the V2 uh yeah the V2 method separately but I agree having this actually merge would be it would be good okay yeah sounds good yeah um and assuming that like yeah either Mikhail or Matt doesn't have an objection I think we can just merge this um yeah so one thing I would say though is um if we keep get payloads 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 B1 that's like the merge Fork get payload V2 that's Capello Fork and then either include the execution payload fields in that one or we would need a V3 in order to separate the withdrawals version from the um cappella version so like if you have to implement three versions of that like uh can we not have them as optional fields in V2 so we already have V2 for withdrawals and um I I don't believe we actually need we V2 forward Scrolls we could just have options here um but the way we implemented right now we have V2 and I think it should be possible to let the the um blob stuff as optional that's in fact the way I'm I'm adding it in right now just adding another uh optional field seems to be fun okay sure I mean that's fine with me okay so we merged 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 paid old V2 and in the separate call as his problem Okay so I I don't know I mean does it unblock people working on prototypes now to have this get blobs bundle V1 call merged or should we close this PR and instead open one with get payload V2 with optional pipes 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 but at the same time no one will use it right so I think it's important to come to consensus soon and I do think like uh maybe on Thursday we can bring this up again to see what people prefer and yeah oh Frodo do you want to give your why do you like the Vlogs bundle so 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 by just isolating it to a single method it's really easy to work with and since we only call this API against one single node we know the content is consistent we can expect the plops to be there after we see the blobs in the block or the payloads that we just retrieve with the regular method so I don't think there are many consistency issues to worry about and we can just use these methods long term a combined methods might make sense but I think it's very like pretty major optimization all right so just one one small thing it would be it's very important for execution layer clients to once you once you call uh get payload to stop building new payloads and just cash the one that 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 for execution layer diffs 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 Mikhail don't see a strong objection and then we can yeah worst case we can just deprecate it in favor of get payload V2 with optional Fields once uh yeah once we're ready to integrate stuff together a bit more um anything else on this um okay um next big spec thing is the rebase on the consensus there side uh of of 4844 on top of capella um I have this on the agenda for the CL call uh later this week but curious if anyone had uh thoughts about this um yeah I'm in the I'm in the process on the execution layer side within Geth of um pulling in the um withdrawals PR into our eip4844 devnet I think um Jesse's working on the lodestar version of that for the CL and um Mophie on prism um I think from our and sorry yeah sorry for interrupting you I think uh from our ad so there's two drop here out there today I think one from Danny one from voters there are essentially changing how the withdrawal works by basically uh by by basically removing the withdrawal q and it's not clear to us like whether those will be merged or what it was did with the old way but that actually does like dramatically like uh basically different with the current capella spec today so for us we're waiting until Thursday's consent to their call to basically to to to to to basically become consensus on like on on like what withdrawal mechanism will be before we start putting 444 on top of capella okay what does it look like in the code right now for you Electrics yeah right now let's talk about the electrics but since like yeah but since like capella we're not sure what the final stay of withdrawal would 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 floods yeah we're just waiting on that okay got it um so I guess I'm not sure we'll be able to close out the withdrawal issue on Thursday um hopefully but I yeah I think there's a chance we still discuss it for another another few weeks um what's the best what's the most useful thing for like people working on prototypes now if um if we don't have a clear withdrawal spec on the CL side well I think we need to know what is the scope for devnet 3 whether withdrawals should be there and if withdrush should be there if we draw just part of like the beacon block and we can stay object or or it's withdraw part of the state transition I think those needs more clarification yeah together right um oh sorry go ahead I was gonna say I thought we decided last week we do want to include at least the um you know the block changes for Cabela withdrawals I mean right in depth do those change based on POTUS is PR parents um so those change would matter because importers PR the beacon state does not have the drug Hue anymore versus currently that we can stay has the withdrawal Q so but if it just become block itself then it's probably fine would you 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 gonna skip mature or something so therefore like basically though we draw objects are basically stop with zeros or something here no yeah my my preference would be that like we don't want the devnets 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 of work once we have a withdrawal spec um to merge 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 to which all spec is right now I think if we have a clear Target for 4844 that's somewhat independent um that would be best um but I don't know if there's a way to do that in in client teams is that just including the fields but having zeros stub yeah I think for Bitcoin block is fine we can improve because we can improve withdraw those in the bacon block I don't think those are yeah I think those are fairly stable it's the beginning state I'm worried about if but then it's just also kind of weird that you have withdrawing the beginning block but not in the biggest state and uh yeah so I think my preference is for definitely agree to unblock this just go ahead without withdrawal that's my personal preference but yeah I'm also happy people like you know others feedback as well um yeah I think for us it'd be generally better to include the withdrawals consensus types um and then stub out the consensus logic so that would mean like stub out the block processing and the State Processing um but then just keep the the fields in the Block in the state so they would just like remain empty because we'd never apply anything to them um yeah so that that'd be preferable for us um but it does kind of stink that the withdrawal types might change but if there's no corresponding like State transition block transition logic and it's relatively easy for us at least to change the to update the tides to reflect the type changes but um I don't want to make this too Lighthouse Centric yeah yeah I mean we can't do that as well I mean I think we're I think you're assuming the latest consensus back which that would draw a high secure because we we actually have that implemented we're just thinking whether we should remove it or untuck oh yeah yeah um yeah I mean my our preference would be to keep the capella types even though they are a little less stable um and then just once we have a devnet Target just like we'll freeze that and maybe we'll have to uh diverge from the withdrawal specs to some extent on the devnets 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 of devnet is there a chance stuff will become more clearer what's the contentious issue here Tim um Terence I think you could explain it better than me because POTUS wrote it but just how the withdrawal queue is designed um 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 stacks of Simplicity versus ux so there's so there's two way to go about it the first way is just like include the withdrawal Q 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 Cloud implementation every client implements this differently so people have different preferences and the other preferable method is just to remove the queue from the beginning state but that kind of have a shape to your ux for a lot of people that want to do full withdrawal 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 I think like Thursday meeting we can follow up more on this oh yeah I mean I don't have a perspective on I'm just curious whether um why it would take more than a couple weeks to figure figure out this issue um but it sounds like so I think yeah I think a couple weeks is is what I would expect as well it's just that 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 to call after that right like I don't think it would go beyond or even between the two calls like does it need to be gated 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 I got p4844 won't go out without it right so I I'm you know strongly preferring we get as much in there for our devnet 3 as possible um that'll put us in my opinion the best shape okay so we can definitely we can definitely uh wait until at least Thursday's call um um yeah does that make sense to everyone and I had it okay I had a a very rough hack in the um 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 um yeah and I'm curious yeah what people think about this um so high level obviously uh 4844 uh in and then if this PR has been merged this would uh yeah so this is merged so the the the the dev the fee Market PR would be part of the El spec um I don't think we have any other pending PRS on the El that we'd want to include in the devnet um what about the modulus change yeah I guess is that something that we want to try and have in devnet 3. I think that was minor enough to where we can do it either way I don't feel strongly they'll be preferable if we could get it in but you know okay it's not so I think yeah let's try to get it and then especially if we're waiting so if we think we can resolve the budgetus in the next week or so and we're waiting on withdrawals on this CL side as well um I would rather we we get it in um it's okay and I think the the the gas price and the 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 uh yeah okay and then at 868 do we want to have this as part of the devnet I guess do we need like yeah I I'm curious mayor 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 then great but yeah sorry what what um so for the next 4844 devnet should we push for an 868 implementation across our clients okay and so this means then what I would also exclude is this um upcoming PR by Ansgar about uh not broadcasting the blob transactions um because if we don't have e68 we need to broadcast the blog transactions um and just for the record top by the way I would prefer if this if basically we only include that into the prospects anyway as a recommendation for client developers I don't think it should be part of what we technically speak out like it should be part of the issues rational section out of the spec section because it's not a consensus change um but I could be overruled if people feel strongly that way better it kind of will be a consensus change for us oh like a bigger change than just the spec change um because we will drop notes that don't adhere to it to this right right but it's still ah okay because it's like it's a product of violation yeah right but it's still more like we don't have a efp for you're not allowed to dose your peer but you'd still also be dropped um well if you if she tells us right now we're not going to drop you right or like to send now from what whatever whatever I can I'm sure there's something peer-to-peer that I can do to make you drop me um and there's no yes send an invalid packet right and like yeah and so yeah we can see about it I wouldn't know I don't feel terrible about having a part of this okay but yeah let's leave out of that out of devnet 3 though um what's your thinking for leaving that out of devnet3 I guess 868 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 I guess uh we only have the e68 change but not the like the different transaction pool the only like dropping people on if they send if they send stuff on broadcast and yeah I would also leave it up yeah because we could because without it we can figure out if all the consensus changes work across all of the clients right and and then this is this extra step of just the networking across all of them but if the core consensus logic does not work um yeah that's that's a deeper problem um okay on the El side anything else that's missing or that we should specifically exclude I think this generally looks good okay CR spec a bit more tricky um so uh these recent changes probably aren't that recent anymore I did this last week but um just as a heads up like we couple the the blobs uh to the block uh for for recent history but I believe it decoupled them for historical sync um we lowered the blob retention period about two weeks so this has already emerged in the spec but just wanted to highlight them um oh see there's a chat uh I'm not sure what your question is Alex say oh no I mean okay okay um in terms of just pending PR's um so we're basing on capella um so we said we're gonna wait until the withdrawal conversation is resolved it might not be this PR um but yeah we'll have to do something um along those lines um but not for now uh we had this other PR to the uh update uh the interface for kzg um I know we had this on the agenda as well uh uh George or bankrupt divider if 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 um the idea is that in August we made proposed API for the kcg library that like clients would interface with uh that API was pretty low level so as to make the C library the ckcg library pretty minimal uh but in Bogota uh we discussed this um with dankard and Ramana who know more about how the kcg 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 now we expose three high level functions uh the nice thing about this is that this is less burden to the client devs so that they only interface with the 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 hashing feature stuff all of this is handled basically by the kcg library so um I was away but today I came back and I've been kind of reviewing the pr the changes since then um and I think um I can get it ready uh today for merging um and Ramana told me that he has made most of the changes on the library side um so we are pretty much kind of ready on this but depending on when the next definite is it might be a better idea to keep the old thing going into 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 I think it would be more like two weeks because we already discussed we're gonna like wait for withdrawals on the CL side which will probably take you know up to a weekend 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 um yeah have it as part of the spec yeah I was gonna add there's still a good deal of crypto code in the clients that would be nice to move out um 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 they start starting now I I won't Implement all of the crypto code that will be in these libraries I would much prefer for it to be in ckg kcg okay that makes me lean toward let's let's include this spec uh let's include this PR as part of our test net spec if it means that uh yeah we can simplify a bunch of the next prototypes and um and then if if next week I guess next week let's make sure to like come back to this on on the call and if for whatever reason um you know this is being delayed or whatever and like you were like I wouldn't want this to hold up to test Nets but I think if if we can have it then we very much should push for it yeah agreed um I will um 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 as new bindings will need to be written uh 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 uh very closely the pr already yes so I think the findings are already um 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 spec just because yeah but yeah that is yeah two or three yeah yep four eight four four underscore 30 . all right that's the one okay nice um okay and then on the CL side we had another open PR that was blocked on this free market changes um should we can we go ahead and merge this Proto once the pr from unscar with the Feed Market just merged then yes this is merge yeah it was like this morning Chris yeah yeah yeah yeah um so it's probably worth just sanity checking that there was no changes in the pr that uh made like that's for sure from this but yeah check the if there are any changes there and then I guess it's 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 IP Market change um anything else um on the CL side that we would want to specifically include or exclude um from deva3 okay and then on the engine API we already discussed this but basically this is uh we would use uh this uh [Music] um this uh blob specific API um rather than get paid all B2 and then we can try and get this merged uh today or tomorrow um and then last thing on the devnet three scope um there's a question by Alexi in the chat about withdrawals on the El side um 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 um curious what people think about that uh well so the out effect whether we have withdrawals the payload attributes struct which is like CL El API my preference would be to include that just because we're gonna have to eventually include it 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 um 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 or engine API endpoints okay okay does this make sense for everyone it makes sense to me and but it's also worth like we probably should also ask tattoo members and them as well just they're like and just they're also like big client team so I'm curious to hear that anyone I see Ben from techu here I don't think there's anyone remembers wrong button you can see me um yeah nothing to uh add um I I can't speak intelligently to this need Enrico because he's not available today so uh he will catch up later and then feedback yeah and anyways I guess we're probably going to be discussing withdrawals and how they relate to devnet 3 next week as well so um yeah it's it's sort of having teams look into it but uh I think we have a bunch of other things that are a bit more settled that we can make progress on and until then um and then uh Roberto you had started a GitHub issue the track sort of status um of things on the devnet um so I guess if people want to share updates uh there that's the place to go as they're working out yeah it's just meant to be uniform informal tracker no okay have a lot more clients starting to be implementing it hopefully cool um anything else on devnet3 okay um 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 um and the ckcg bindings uh we said we have uh we're planning to have some for go um I guess for rust and Nim do we have a plan uh to expose things oh I was just gonna say for us um I think Ramana uh volunteer to help with that um okay but that has been progress I think just because the API is still stabilizing yeah so in terms of the apis it's also best if someone from a client who wants to consume it comes forward and then uh then it can be done together I think Ramana is happy to work that out but it's hard to just build a build an API for language that you don't actually use yourself and then yeah you're probably not uh build the nicest API for that language uh yes so Pawan is available from our team to work on that um so he's out today but okay um Alexa you have a comment saying ckcg needs additional discussion um we have a minute to go is there something specific you think we need to discuss or um on on this call or yeah what do you think is like the most important thing here uh yeah it will be cool to have like a synchronized question was between Google and all the violence uh in terms of uh like cryptography outputs consistency so I cannot we cannot synchronize with go we get because uh we cannot verify blobs because with ckcg we have different outputs we have different formats in setup in kcg setup like that and it prevents us from like finishing the VAP actually and uh well it's not yet cross-platform this library ckcg and uh we could calibrate on fixing this inconsistency and the absence of other platforms it's not just Linux so I know we have like the 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 is the best way to get this result yeah maybe let's continue to in the shot I just wanted to raise the problems and we have a client uh someone to collaborate on this you know since uh so who is currently working on go kcg actually a Proto Lambda working on it or yes I maintain Goku SG um I just need a staple spec or something of the spec and I'll implement it 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 uh then we just implement the same interface for both okay um okay uh the only thing we didn't have time to cover on the call was the The Blob testing we discussed it last week as well and um we have a group chat for that so I I don't think there's much to cover um last thing before we hop off uh there's daylight savings happening in the US uh and Canada this weekend are people okay if we move the call to 15 30 UTC um rather than 1430 so it'll be an hour for North Americans it would be one hour later than it currently is or it would be 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 um yeah does anyone have last weekend oh you already did it okay yeah so it's one hour later uh like 15 30 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 it'll be 3 30 in the UK and 4 30 in Central Europe foreign Asia Pacific lives matter yeah Lighthouse and take cooking um does 1530 UTC versus 1430 UTC make a big difference um in Australia uh well so I I think it's pretty late regardless for them so I mean I can represent Lighthouse uh whatever Eastern okay okay oh nice I didn't know I didn't I assumed you were also in Australia I did not know uh you had spread more continents now okay that's great um okay I'll move it to 15 30 UTC then um yeah it doesn't seem like there's super strong objections um sweet thanks a lot everyone uh yeah this is really good and um talk to you all on the CL call in two days everyone have a great day bye thank you