EIP-4844 Implementers' Call #4

okay um let's kick this off we have a good group of people here and I'm sure more will join in um welcome to the fourth of these 4844 implementers call um we have a ton of spec stuff today as always on the agenda um and then uh hopefully we can get through some updates on devnet 3 on the uh large block test that we wanted to do um and then Terence had a couple PRS that he's put up that um he wanted to get feedback on if not on this call at least async so we can uh we can we can go over those quickly um and maybe I guess to kick us off uh endguard you gave some updates on a couple of your PR's uh in the agenda yesterday do you want to just take a minute quickly to sort of walk us through where those three are at sure yeah yeah they're always like a few of these uh small ones also just to check my microphone works well this time around yeah that's right very good so um basically uh I think it's poor but but one of the PS didn't have a status change that's the one where we just discussed whether or not to have a minimum price so the three were actually something happened um first uh the kind of throughput reduction um yeah um API is emerge so now the the target um and Max are like the quarter megabyte and a half a megabyte um the understanding of course is that once we collect metrics it could be that we end up setting like a slightly different uh throughput uh for bringing this domain net but I think as a kind of default um this makes more sense now and then the second one is the pre-compile the the pre-compile return values um that one is still not merge just because I had like some concerns last call around the the formatting of the of the return values um and I looked a little bit more into this and it turns out indeed that uh there's some precedent with existing pre-compiled that handle this differently so there's this um the n128 um pairing check pre-compact for example where the return value is padded uh also it doesn't return explicitly return a successfully instead of failing um if the pairing fails um so I preach out to the solidity team just to basically get their take um on whether or not it makes a difference and whether or not it's worth basically following and precedent here um it's a small alternate change but I think for this given that like also protesters are not like it doesn't really like like nothing depends on this right so I'd rather want to get it right um and merge the thing that we can actually bring to mainnet and not have to change it later on so this this one is still pending um waiting for clarification there um and then the last one um that's one that I had forgotten last week was the um the mempool situation was not automatically broadcasting um block transactions I did I I opened a PR that adds a dependency on Mario's um um yeah P 5793 which is the e68 transaction type announcement but I do have one question so maybe if we could briefly discuss this here um so the the way the Erp works is that it only adds the the transaction type and the size of the transaction to the announcement message but in itself is not like does not prescribe whether or not clients still broadcasting certain sections so this this change itself basically just says you have to you know in your announcement message you have to include those into this information but then basically whether or not clients still ought to broadcast these transactions by default or choose to no longer Auto podcast over threshold that's up to clients um for now I basically also kind of word it this way and just give it as a recommendation to stop auto broadcasting I was just wondering if people feel strongly that we should basically have that be a requirement required behavior for clients uh football transactions so there's been not just have it as a as a recommendation but but a better extra requirement um I don't know if anyone has opinions on this okay otherwise I think having it just yeah be a recommendation makes sense to me but yeah and I guess maybe once we do this like blob spam tests if we see something break at the pool level or gossip level then maybe we want to make it more with a recommendation um yeah Morris didn't look like he's here but I'm just referencing back to the execution layer workshop at um Devcon and I think the key thing we're trying to mitigate here was dos risk of the execution layer and basically giving execution layer more optionality in whether they kind of were going to take in blobs or not or large transactions or not and so um I can imagine Mario saying that it actually is really important for it to be a requirement rather than a recommendation but I think we probably need we need we need someone we need someone like him or Peter to really weigh in on that of how strongly they feel I'm not sure that that helps because if someone's trying to dos the network they're not going to follow that anyway right they're gonna broadcast blobs like mad yeah but if it's a requirement not a recommendation I think the idea was basically you could terminate the connection the peer connection yeah you can just stop playing so they can broadcast blobs as much as they want as long as they're connected to peers but if every peer drops them um right yeah yeah but anyway yeah I guess we can revisit but it seems to me like you could drop you drop them anyway right regardless if you've noticed some spamming and drop them rather than you've noticed yeah otherwise how do you tell that they're actually broadcasting something right yeah yeah um yeah I suppose if everyone's required to request rather than yeah I suppose so yeah maybe that does help all right could somebody articulate the concern in like concrete kind of conditions that we're looking to violate from this I I guess like that has been still a bit abstract for us what are we trying to find what does break mean so I guess if nodes are just unable to process through blocks or get put offline because um of the increased bandwidth requirements of getting a bunch of blobs that are either invalid or yeah are these concerns written somewhere where you can point to or can somebody own kind of like um I suspect if they're somewhere already they would be in that EIP nsgar link to but let me check it real quick well it's it's basically just the existing policies section in the EIP it's a really small section but the idea is just that it's not only bandwidth it's also compute given how expensive the block verification are the idea is just that you want to have some mechanism to throttle ideally you could also do that in an existing world with psgrowing but the execution friends just don't have a concept of peer scoring um so by the time they would basically validate blobs and and see that they for example they are invalid block transactions in there they just don't keep track of which peer this came from and and so that would mean a complete re-architecture technique of the fmm pool to be able to handle this so uh instead if you do it with announcements then all of a sudden you have explicit control over like a okay I only pull drop transactions from this peer once every so so many seconds or something that's awesome and then even more zooming out um I guess my my point is that the stress test they were doing is not testing blobs it's just called Data transactions and I think I heard that the concern is not just bandwidth it's also a compute because of the kg verification cost in the mempool and that's something that we'll be testing with the stress test is it does everybody in this group understand that this is the case or have we been have we not so I think the stress test actually tests something different we have two different concerns here we have the consensus about the size of the of the of the actual assembled blocks and then we have the mempool and and those are completely separate and so what we are testing with that stress stress test um is at the size of blocks because that is consensus critical right everyone has to download these box um and um and so they might be kick from the network the mempool side of things is somewhat more forgiving because if you uh make a very constraint the bandwidth a situation you don't have to actually run a mempool you don't have to to to propagate all these these transactions um uh but on the compute side for example it's much more problematic because on a bug like for Block verification the compute is really negligible because you do one check for the entire assembly blocks but for the block transactions you have to do one check per transactions there might be hundreds of transactions coming in so it's it's basically it's much more of a compute issue there so it's again like those are the stresses we're doing is is just for the block propagation that's that's separate from mempool on this one I feel like it we probably need someone we probably need Marius to weigh in here um because he was the person who had a strong opinion on it and given he's not here do we want to push this async and ask for his feedback on the pr yeah I think I think that makes sense um and I think the test also like yeah the test even just on the bandwidth side is really valuable right um yeah I'm good we'll get it done this week um I'm writing this today we'll try to run it on girly by the end of the day might start doing more coordinated tests over the week cool also just in terms of philosophy very briefly I think it's important to find out that the mental concerns are a little bit less of an issue because we can always launch this Erp with a mempool that is very restrictive and maybe a little bit less efficient in propagating transactions um but doesn't actually break notes and then make a propagation performance better in the long run whereas block propagation really has to work right because the entire network breaks down if it doesn't work so mempool is more forgiving right okay um okay so those were your three uh ends Garden you said there was a first one a fourth one sorry um that uh yeah you said there was a fourth one that you hadn't got emerged or given an update on oh the minimum the minimum cost okay so just no update there exactly okay perfect um okay um so next up uh what was this one the oh then okay Danny can't uh make it unfortunately um but he was reviewing uh the spec uh yesterday and highlighted this issue um where I think two calls ago we decided to not verify the blobs as we are propagating them um and um Danny was saying that there's a way in which this means a any node on the network might be able to propagate an invalid blob which is not something we would like um I know Mophie the two of you were chatting about this yesterday you have a quick update on where things are out there yeah I think it's we sort of like figured out that it is a concern um the options we have is to either use Reliance signature verification to um deter invalid side person being gossiped or rely on the kcg commitments and based on the Contra I'm leaning towards using signature verification as uh Danny proposed in the pr um yeah up into feedback there from anyone else that has a review um so we were looking at the uh times it takes to do the kcg verification versus signature verification and I think the difference for 256 kilobyte blobs is like two milliseconds um and I think that's probably not significant enough to Warrant the signature just because the signature requires the um changes to the beacon API and the validator client um and like it'd be nice to avoid those changes if we don't have to um but yeah I mean if we end up going with bigger blob sizes it would be okay to add later too so it's sort of my two senses like like Maybe not maybe we shouldn't prematurely optimize for this um because we also could do things like figure out kcg verification of The Blob in parallel with other aspects of Gossip verification so you're saying it's like almost because the blobs are not that big now it's not you have the world if you're not doing the signature check is that uh yeah so yeah so we we do need something and it's either we need to do the kzg verification or the signature check and the KGG verification is more substantially slower the bigger blobs are right okay if we're targeting relatively small blob size sizes it might not warrant signatures yet if you know things are going well and we're like we actually have a lot of Headroom I think it'd be okay to like add signatures later because signatures like it impacts the scope of work by requiring changes to the beacon API and validator clients so right right um I guess I'm curious if other client teams uh do any other kind of teams on the CL side have thoughts on that yeah I agree it feels like a premature optimization okay is this worth I guess bringing you up on the CL call Thursday or should we just comment on this issue and try to resolve it async in the next couple days uh I mean I think it's still worth bringing up again but yeah I'll reply on the issue awesome yeah if you want to share that on the on the issue um yeah uh that'd be great and then yeah we can we can follow up on it on Thursday's call sweet uh okay so the next one after that uh I just wanted to follow up I guess on this rebase uh PR uh I know we've been working on this uh a lot uh and and there's comments on it from yesterday and today but um yeah and you won't have anything they want to share bring up on this or and uh just to um reiterate the point of the rebase pr um the point of it is to make it easy for client desks that are already working on withdrawals to add 444 on top of that um there's a clause in the spec in the pr to make it easy to disable withdrawals just for testing and I think Danny brought up a comments of like if that's like what are the other ways of doing it and the approach we went with is to Simply know up withdrawal sensitive functions such that um there are no withdrawals that we can block and the withdrawal route is whatever the root is like an energy tree it should be um so that's kind of like where we're going we're testing this lets us um avoid introducing withdrawals to the El so that we can test eip44 on Els that haven't quite in fully implemented withdrawals um as soon as possible and also it lets us avoid any bugs in El or the CL that could be attributed to neutrals okay so I guess yeah we can just keep following up on the pr there but it doesn't seem like there's anything um urgent to decide here um okay I I guess yeah the next thing I wanted to make sure we covered was just definitely three so um last week all of the uh uh or I guess yeah 16 teams said they were trying to get uh yeah get this implemented so that we could launch a devnet uh on around November 30th which is two weeks from now um so yeah I'm curious to hear about just the different implementations how things are going if people think this is still possible or if there's any issues that uh yeah that seemed to block this I can give an update on some of the work I've been doing so I've got devnet B3 I've got Aragon as in prism updated to most of the new spec um depending issues are the the pr we just discussed um um some of the capella uh rebasing as well as uh I think we still meet a couple Beacon the side cars with the beacon blocks and the consensus layer um so those are pretty close um those are in great shape I've also been spending some time pulling out some of the remaining kcg code mostly from the execution layer into you know what I hope is a clean Library um that's in the crypto slash kzg package within get even though it's in Geth I'm using it both for the consensus layer as well as the execution layer um kcg related or EIP 4844 related functions um so all the go clients can hopefully share that likely that stuff will move into the go kcg or some some similar external library but for now we're trying to get it right there once we're once it's ready then what we can then think about moving it out and I think that some little bit of discussions like you know should it contain Persian hash related functions or should it just be kcg so there's some some discussions around the edges uh but anyway I think it's in pretty good shape um for people to start using on it uh if if you're writing a go anyway um and I'll be starting to integrate that in Aragon this week nice really cool um any updates from nethermind yeah uh so we are integrating everything uh like in master Branch or no no new desk regulations uh still there and probably we have no uh bundle we won in point being added uh but everything goes quite smooth so I hope we will join with everything edit uh the difficulty actually the main difficulty was to repeat all the binary layer of encodings new encodings over here when uh the cap I mean SSD encoding well oh what else oh different hash algorithm and like a bit different layout for transaction encoding is this what slows a bit but in overall it's okay the main problem I see now is um we still have no um knows the same outputs as uh go kcg library for ckcg library because uh it's for as far as I know implementations a bit different in terms of like getting some internal caches because uh it it is based on different like a binary layout like that so uh this way it's hard to synchronize with uh going with gas and the other implementations now and we just keep verify verification for now um but I hope we will find we will like wait for update from go library and um we will we will have some tests for both libraries uh with the same inputs uh and uh who hope to get the same outputs that's the only issue which is not resolved for now got it and who like who is working uh on these like harmonizing these these libraries um I know uh yeah I I know there's a bunch of people working on on them but um yeah is this just something that we're tracking or um I don't know yeah yeah I started with test factors but I think we've started integrating any of them um I can definitely speak with lxc offs uh offline to sort of um interrupt the go kzg with the ckzg rapper that he's using okay nice would that a library I have in Geth be a solution to this yeah so I'd uh basically just make sure that that is interoperable with whatever Alex he's using cool uh I have a question about the ckct library so uh like I'll I'll be expecting like all the bindings for different languages to be hosted on the ckcg repository itself like who would be like responsible for maintaining the different language findings [Music] Sigma Prime we can have it in our own repository like the bindings for rest something like that so just wondering what other language findings we're thinking of yeah so right now the go and the cdkcj stuff is pretty separate and even the Go kzg stuff is somewhat scattered about so um I think the short answer is no we don't have a good story for that yet um whether we should consult I I'm not sure we can console it we need to consolidate it all in one we just need to make sure that they all work together right work the same but maybe people have ever been yeah we were discussing this um today actually because we are starting working on the Java binding and uh we're asking ourselves if we want to have a separate repo for the Java binding or try to initially stick everything in the current binding directory in the library and I think if it is this the the idea I would prefer the second if if actually the end state will be having everything in the same repo what do you think it makes sense but like like another question that was like in the end like uh maintenance of the ckcd library itself like will it be done by the EF like uh so like whoever maintains that Library would also have to maintain binding for different languages so like that might be hard or not like I'm not sure about that you know a solution will be that has been will be maintained by several several groups maybe someone are more c c and crypto oriented but maybe the bindings inside the directory will be mostly maintained by different groups of people I don't know if this is the make something that makes sense yeah makes sense to me like I made a draft PR for the rest findings today to uh the C kcg uh dankrad's Fork of the ckct liabilities so like like that's that was our intention like at least from Sigma Prime that like we would want to get the rust bindings merged into that repository and like any time like in terms of Maintenance of the bindings itself we could help with like reviewing PRS and stuff like that that stuff my understanding from the latest conversation in the telegram group is that Ramana is going to maintain the kind of core crypto and C libraries and then that just like you guys are suggesting um we're going to have kind of separate people maintain the bindings but all in one place yeah I just wanted to clarify like what I added in the comment was I think it's just bindings for the C kcg library then it probably doesn't make sense in the same package go kcg however is not a not a rapper around Casey ckcg it's its own thing so that probably belongs remain should be remained separate you also rust have a completely different implementation it's not simply a wrapper am I right I think that I like my like my pure first implementations also around but uh yeah like I was talking specifically about the bindings to ckcg okay and there's also a comment in the chat about like working on common test vectors um is that something anyone is is working on or wants to work on um and we don't yeah I guess we don't have to do this now but I know in the past like for say BLS we would fuzz all the libraries against each other pretty extensively um so that seemed like something that it's probably valuable to do as well but um yeah it doesn't have to happen now um okay and I guess yeah I'm curious to hear so this was mostly for folks on the El side with regards to participation in the devnet um on the CL side we have prism Lighthouse and load star say they would participate um anyone from those team want to give a quick update on where things are at uh so for Lighthouse we're still planning to participate in the next devnet um right now I'm working on the peer-to-peer portion of things and Pawan is working on integrating the rust bindings for kzg that he just finished up with him um and yeah I think we're on Pace to get there so nice um for president um oh same just uh says yeah I'll I guess speak for the busy team and the stuff I'm working on so we the work is basically right incorporating all the um the 444 rebates on top of capella um we are basically going ahead with what I have in the pr for three days uh targeted that as soon as it gets merged and um also working on in adding like the logic for the rebase on eip44 on capella um it's still going um just a lot of uh development every stock doing work going on nice and let's start yeah uh let's hear I think is on track to be included in this devnet we now have lion from lodestar on on this call who might want to be giving updates in the future as I try to hand this back to chainsafe I think it's looking good and we now have um lodestar integrated into our interop testing repo with only the first of our test Suites running against it but um it's using the updated gossip topic and the chain advances and that all works it doesn't actually save the blobs yet but most of the foundation is there sweet um and I guess anyone else uh think they might join the test net or uh still those six themes well a small update from from Tego we are working content in contemporarily with uh progressing with capella and for it for four actually a capitalistably um um far ahead with the works compared to the works for the 4844 so we are progressing in parallel strictly and and bushy things directly on master so uh things are progressing but I don't think I'm gonna change the idea that we are able to join the devnet so far I don't think we will the next one will be the one for us that's good happy to hear about the progress anyone else want to give an update this is Andrew from ethereum JS I mean I'm just going to comment that we We're Not Gonna Be Ready for devnet3 I don't think I've got a mostly locally mostly done local implementation and I'm still testing it I'm still trying to get it to work against the local version of the devnet just from the interop repo so until I feel like we're able to actually like trade blocks and try you know serialize and deserialized transaction there's no point in me trying to go to a public.net at this point but um but we're I'm I am plugging away at that um at some point it would be nice to kind of understand the current status of the actual EIP it feels pretty out of date in terms of like the pre-compile spec doesn't match up to what y'all are talking about right now and so I've just I'm just trying to we can talk about later offline it's not important I don't know I don't want to submit that I do have some questions about that at some point I've talked to Kev a little bit but um could use some clarity on a couple yeah the pre-compile is probably the bit where there's the most like just like we were talking there's the most you know potential changes but aside from that it should be pretty fixed okay all right well then maybe I'll look at it again I thought there were there were a couple places that I went astray um and Andrew feel free to reach out to me I'm trying to keep on top of all these things yeah be able to help out no that's cool I appreciate it yeah like I said I'm still just trying to get the all the code in place to even start testing it within a Rob so yeah I I agree so but maybe in December that's probably the early Sunday with travel plans around Thanksgiving I'm not gonna have a lot of time to work on it and get ready for bed three all good yeah thanks for the update anyone else want to share any development updates okay um if not I'm moving on the next thing I I want to chat about was uh this large block spam test uh Georgios posted an update on the agenda about the way they're thinking about doing this um and given that we're probably going to run a test net run in the next week or so um I'm curious to just hear feedback from folks here about like is there anything that we're missing or that we should be looking at or do you think basically George Joseph's approach is is broken in some ways so that you know once we start running them if we can get that feedback or before we start training the test we can have that feedback that's great and then otherwise we'll probably run this on test Nets a few times and share results here before we move to mainnet um yeah maybe George's you want to take like a minute to just explain sort of how you're thinking about approaching this and then see if there's any feedback thoughts comments on it sure I'm Vlogging so it might be a bit noisy um tldr my understanding is we want to create sustained load on the network for some time and we're gonna do it in chunks of some size which we want to be which we want the parameter over default base case we're gonna do 128 kilobytes I don't know when that would be useful but it's also like one exercise yeah and it's generally low cost to just make the the tool generic over whatever transaction shape we want um so my idea is that we'll just make a general load tested for call data transactions and it's going to be able to submit either 20c I landed on maybe for a builder to bypass 100 creates not in scope for me to do any metrics Gathering and I assume that either you know somebody will be watching or um analysis I'm curious for any thoughts reactions if there's no feedback I guess one thing that's probably worth emphasizing is right now we have a prism branch which is specially configured to uh track a bit more metrics than they usually do um so we'll be obviously looking at on-chain uh metrics and we can run some other clients as well um but if if any other client team thinks it's like trivial for them to add some extra metrics and monitoring um it might be worth just looking at what prism did and and that would help uh kind of send it to check the data across more than one client um I don't have the branch real Handy but I'll try and find it and post it uh in in the chat here and we can have it in the notes um but yeah worst case we'll just have uh the on-chained data and um and and it's prison that's that's specially configured um yeah oh I found the branch uh so I'll just post this here um yeah and I guess once we get the results from this first run we can come back and and um and uh and discuss them here and see if there's anything we want to tweak before going to magnet anything else on the spam test if not um parents had two PRS he wanted to discuss um uh he's not here uh to do so the first one uh was adding this block inside car retrieval by root uh I think it just it got approved this morning so um I don't know if there's anything more to discuss on this uh well something related that isn't quite this PR but is um the buy range request like the counterpart for this request um whether to keep it as a separate block and blob request or combine the mentistical request um I'd be interested in discussing that at all uh I think for Lighthouse generally whether or not we have the requests together are separate we're probably going to treat them as if they're a single request even if like they're specked out separately just because it makes um handling things like attributing false to peers a lot simpler um so we would generally have a slight preference for just combining the request but it's also not a huge deal if it's a pain for other teams so it's just interested about other teams to think about this laughs yeah we're having this discussion on GitHub and I come up actually with the same reasoning about that the only thing that we were internally discussing a couple of days ago about having a separate uh call is for let's say archive nodes that for for some reason they imagine that you want to have um yeah a node that wants to to uh suddenly start uh getting archive blobs and start searching for notes that provides blobs for for uh a deeper history and then this node would like to start filling up the uh archival blobs for for the very deep fast so in this use cases where you want to have a those kind of nodes having a separate method definitely makes sense because in that case you have to download the blocks another another time but the part of this archival nodes I think um we think that having the coupled version is simpler yeah that's an interesting part I hadn't thought about archival nodes um just to clarify we they are still decoupled um and if you if you requesting sidecars that are um not recent we do have like an API to request a response to RBC so that we get those in a decoupled manner is is not what you um it's not the concern for cargo notes or something else yeah I was thinking that having the um coupled version actually does not assume that you we will have also the dedicated sidecar method but if you think that we will have both of them the couple and the coupled version this definitely yes of the the issue but I don't think it was at least intended in the first place to have them both might be Rocky yeah we only use both um during gossip so that um notes can easily have like the blocks and its requirements outside car all in one message it makes it easy as Sean mentioned to attribute any problems in the message it's really different here and also avoids weird race conditions where um you get a Blog but not the sidecar and vice versa and you're waiting for one or the other but there is a fallback to requests like a specific blob given its root or by a range request signals are highlight for baking blocks it works okay yes also having them also adding the option to have this dedicated sidecar method yeah it's uh definitely works you know hope you just so I understand it like this PR that John Jared is the remove blob sidecar by range are you saying that we wouldn't remove blobside carbo range or are you saying that there's another method that's not bobside car by range that would serve a simple purpose of this like blob retrieval oh I just assume you could so Sarah just proposed the uh blobside car by roots we could use that instead plus I'm missing a use case where that wouldn't be uh sufficient oh I mean so I was suggesting rather than like having a black side carbide range request we have a block side car with signed block and sidecar by range request um essentially just saying like for a cut like I feel like we're converging and coupling these two things everywhere so in the one place that I don't think we have them coupled yet which is the buy range requests should we um and I think for us like whether or not we do we're gonna handle them as if they're coupled so it's not a huge deal if it's specked out to suggest this should be coupled but it would be nice if all the client teams are going to handle them seriously or similarly so was just curious about like what other client teams were planning with these by range requests um yeah like so I am interested how the um uh prism implementation works right now do you guys like cash blogs and blobs separately and then as a buy range request for Block sport blobs completes like kickoff processing at that point or are you just like making both requests at once if either request fails both fail and then once both complete you just start processing yeah I can't really speak to prison but the way we had it worked included first two couple death notices to do the ladder um request of logs block requests the blog site cars and if either of them fails then it's just short circuits the other yeah so this is I think what we would implement if the requests are separated but it's more or less the same as just having a single request just like a bit quirkier and like I mean you do potentially have an advantage of parallel download but yeah to be seen um yeah that's all that's generally what I was curious about because I think if if all clients are going to implement something similar to that we should think about just having a a couple of requests there as well we well at least for prism we do they do try to like avoid parallel downloads because it's like attribution into your scoring a bit wonky um like for example in the case where you make few requests to get the box or the Sidecar and one of them is invalid um ideally you don't want to keep communicating with the other peer especially given like if we go like with one megabyte size blocks of blobs we don't want to keep making that request so I imagine a lot of clients would make a request to get the block ensure that that's valid before proceding to get the sidecar in the decoupled case but if it were coupled then we can adjust like our peer squared parameters to take advantage of the fact and make a single request that'll just be easier well either way I don't think it'd be that useful at least not without crazy workarounds to make two requests at the same time trying to like exploit owls in there yeah so I we can keep talking about off offline I guess um but that's definitely um it'd be nice to have some clarity around that um relatively soon and if it's if we're getting too close to the I don't know devnet and we're not sure we can go with separate requests um but yeah Mophie can we at least pick a solution for the devnet even if it's not well thought through yeah I think the current solution which is what the current spec is right now will work for the devnet we still do need to apply root but um other than that yeah or Forest house right now but we should work yeah so maintaining the range separates and having the coupled by root this is the current location right so yeah also considering also what I was discussing before right with regard of the potential um archive and blobs archival nodes we definitely have um sense to maintain them separate and integral we were also thinking about in any case having kind of simulated coupled version of it so you talk always to the same year and you ask for block and blobs and if they match okay but if something goes wrong you you can easily uh pure score um yeah don't score the the pill you're talking to I just want to make sure I get this for the notes can someone reiterate what the decision we just made is I think I think leaving uh by range as it is for the next definite right and then I mean open to discussion in the future but we're we're not going to merge this yeah uh the 3087 PR that's removed Bob sidecar by range I believe so to be honest I linked that more for the discussion on the pr I haven't looked at the pr itself uh there is a VR it's just a discussion it's just an issue right now but yeah okay so we're not gonna do anything on that okay is there anything else that we are going to do or are not going to do for the devnet um all right let's check the devnet dock but my root is still something you want from the devnet of because there can be which is the uh 3089 ad block inside car retrieval by root yeah yeah do we have a clear next step on that oh I think it's approved at this point so we just need to merge it foreign yeah that's pretty much done let's go there margin and um the other thing was um Brian's PR to um or issues who decided to flipping it you said rely on signature verification or TCG commitments to um it's her and valid logs like Argent gossip I think we kicked the decision to do this for next week um I think that's probably something we want to have for the devnet um but hopefully by next week we'll have like a decision on what we want to do and then update the dog yeah oh go ahead please I was just gonna say looking back my notes it looks like we had a recommendation to proceed with just the kcg commitment rather than the signature but maybe we haven't formally decided that right we we do kcg and we just confirmed this on the call Thursday um with the other um yeah with the other uh CL teams but yeah generally that's I think we agreed to yeah so end of next week we should know for sure like end of this week sorry we should know for sure what happened do we have a PR open for that one the Spectrum there's no no there is no PR that's actually a good point we just have the issue from Danny um but it might be worth uh opening a PR before Thursday's call um yeah with the kdg and then discussing yeah yeah um does anyone here want to own that I I can make a TR um so just so we're clear like the pr would be to add the kcg verification as a gossip condition right correct yeah okay cool and then on the CL call we can discuss that PR and if for some reason you know people think we should do full signatures then like right we can always change it but I think it's at least we can come to the call with like something more concrete uh the the proposia uh cool yeah thanks a nice I think there was everything from today there just if we have two minutes left there were a couple action items from last time um so we discussed like end scars at the beginning um George and Kev had this one around disgusting uh the ckcg interfaces uh and how they handle handle asserts that this happened uh we have two non-blocking issues um for the crypto so there's three zero nine free we're waiting for a reply um this doesn't block clients there's three zero nine seven um which is the interface for the pre-compile uh we agreed on a byte array interface but there's a bit of discussion around whether diversion hash code should be in the crypto but that's also non-blocking okay thanks uh and then uh uh Mophie merging the pr yeah uh we're basing for it for foreign capella we're we're getting close there um Mophie open oh yeah uh open emerge PR switch between withdrawal fields on engine API specs at eip44 did that happen oh yeah the execution apis I don't believe that's been merged yet uh are there other PR's for it nice thank you um okay uh and then Terence had three of them but he's not here um and I think basically the two last ones yeah the two last ones are the the sorry so the two hate shoots you pointed today um one is adding the block sidecar and retrieval by root uh so I believe this is the first action item he had um and then uh this second one uh was ancestor blob availability check uh and I think this was the second one if that's correct um yeah that seems yeah this is more uh Associated to us back a change requiring to be more specific about what should do a validator in terms of start testing the he had with regard of having all the blobs already downloaded guys yeah this has been a discussion that started on Discord by me and then became an issue here but then blended with all these things around the by range methods but I think we were converging to the um option to say uh avoid block import antly if there's no blob downloaded and verified got it okay is there anything we're just a bit over time is there anything people fear we I miss saying you haven't yeah I just linked one on the which I think is the the 3090 for the beacon block I think that's in Alex Stone in stokes's course at this point okay oh yeah yeah I wonder if Alex is on the call yeah he is yeah this was just like deprecating the beacon block gossip correct emerge yeah uh I was gonna make one edit Danny like wanted a clarification but I was gonna be there right after this call and then that should be merged okay um so anything else anyone feel like we should have touched on but haven't and yeah so so I'd like to come back to this test vectors question which we shortly discuss it at the chart and at least in my opinion it looks like it would really it will be really great to have these test vectors um something like we have now for a consensus layer that the titanium Foundation is maintaining and so so for these um uh a developer level for the library interface because looking at the the charts I see that there are a lot of edge cases where people are trying to uh you know to to cover and this Discover it and there are multiple implementations multiple wrappers and then detailed test suit for a developer level will be really uh useful especially if it covers those new discovered edge cases so I don't know if there are some resources available that somebody could take care I saw that Kevin is is worrying on that but I don't know is is does he have enough time to develop the full suit and follow all the all the details uh I can add in the edge cases that we discussed um it's mainly basically going to all of the rappers and uh by passing the Json and adding the tests into them I'd have to reach out to maybe Alexi and the others for stuff like C sharp okay so so you feel comfortable to to try to take care of that yeah just making this aspect is fine okay okay that's cool thanks by the way uh is that we were provided basic test vectors in the spec test in the next release and I am Keen to merge the best PR as soon as possible and we will talk to any to agree with it and once it's done then I'll have a test generator period which is on the which is based on markets PR so we will provide the test vectors later oh and by the way uh in the CEO test vectors we use the minimal uh trusted setup configurations so the format is described in this PR so just in case uh if you have time uh clients can take a look if you agree with the format and if any issues we could change it before the next release cool um okay anything else before we wrap up okay well thanks everyone um see most of you on the CL call this Thursday um that was yeah talk to you next week at this call uh thank you