# EIP-4844 Implementers' Call #5

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2023-10-09
- Duration: 59:11
- Topics: blockchain, smart contracts, distributed ledger, ethereum, Science & Technology
- Watch: https://streameth.org/watch/yt-tTF2VHcAMzE
- YouTube: https://www.youtube.com/watch?v=tTF2VHcAMzE

## Description

https://github.com/ethereum/pm/issues/670

## Transcript

foreign good morning everyone afternoon for Europeans uh this is our fifth Ford 4-4 call lots to cover today um as always a bunch of spec updates um then I think it's probably worth spending some time chatting about uh this large block testing that we've been doing uh Georgios has managed to send a few rounds of uh large transactions on Gordy and so we can chat about what we want to see next there um chat about devnet3 how that's going uh we were supposed to be launching next week so are we still feeling like that's possible and then um I think lastly if we have time um uh I know uh we're right in the middle of discussing Shanghai inclusions and whatnot right now so um it would be good to just make sure the Readiness checklist is roughly up to date and and um yeah just discuss uh how people feel about Shanghai um but yes uh to start I think the first thing uh spec wise was um what to do for uh blocks which have no blobs uh George had uh oh Kev sorry had a PR uh about this PR 3093 in the CL specs um Kev do you want to maybe just give us a quick recap of where things are out there uh hello yeah so um currently I think we've all agreed on the strategy in the pr and it's uh we just need to know if clients actually are going to incorporate optional sidecars um if I remember correctly George I think even if they don't we might still go through with this PR yeah I think I think that's indeed the case so I think like a bit of background is that uh there were some bugs that appeared when uh an empty side car was given to the cryptography layer and we know how to fix the bug and the fixes will get Incorporated regardless of whether the sidecar becomes optional or not but um I just want to to to to understand why uh the sidecar is not optional when there are no block transactions if this is something we did uh if this is a good thing maybe because it doesn't have any special blocks they can if else condition and you know if that's the case uh if if the sidecar becomes optional then it means that we can be sure that anything given to the cryptography layer will have at least you know like uh one commitment and one block and this might let us do a bit more defensive you know like have a bit more invariance in the code but uh the cryptographic pr will not be affected too much I was just wondering about the Russian are defined the sidecar is not being optional I mean I would ask why make the side curves optional you know they're otherwise if you make the zeigars optional you're going to have a bunch of places like in the network which deck where you're like well if you have a sidecar do this whereas you know you have you have two messages it's easy to send two messages and one message will be empty if the commitments are empty any other message I I you know I think I guess you end up having some logic hoisted somewhere to handle emptiness but if you're going to put that in the cryptography layer regardless then I'd say it's actually easier to have sidecars with everything okay that makes sense I mean there's another there's another argument which is currently the data available you check is is there a sidecar for this block and does it validate um and in your case we would have to make that logic also something like uh does this block have any blobs and if yes is there a sidecar and if no yeah don't do anything yeah so like I mean also not a huge difference but we would have yeah but it's pretty much like it it just rather than just hey given the commitments and given the sidecar does it validate it becomes you end up with preconditions to kind of even get into that logic yeah I I think I mean I think it makes perfect sense definitely to program it so that we can have empty once and we can install like have a discussion later on if for some reason it seems easier to like make it optional but as long as it's small I think there's not really a strong reason for that sounds good sorry so my take is I prefer it for emptiness and don't do optional unless we have to just because when you do optional there's also additional complexity to implement or for the Marshall and the our Marshall layer and yeah it just like it's just like a one more thing that could go around there so that's just my preference okay that makes sense I mean I was thinking that like you know I'm not sure if we're going with it the couple block sidecars thing or not but I was thinking that like if it's the couple maybe the last block verification to go through faster but um I think we have good consensus here and that that we don't do optional and mandatory and empty and in this case uh things can get the cryptographic ER uh married uh like probably tomorrow probably tomorrow nice okay on oh sorry guys yeah yeah Tim there is another PR that got married just as an update uh I think it's three zero nine seven uh which basically um what it does is it makes the verified kcg proof interface be a bit more high level so like accept bytes and not field elements these uh remove some burden from decline devs when they're implementing the pre-compile um we did that from feedback by Alexei uh and and there is a another PR on VIP side which like simplifies the the pre-compile to use this new interface so that's good um Roberto suggested that maybe we do the pre-compile interface of the KCT Library even more high level and incorporate also the hash check uh we didn't do that in this PR but as more clients uh implement this thing and as we get more feedback on what's the right interface we might want to um revamp the interface if needed so yeah uh let us know if you have feedback on the cryptography API other than that uh I think we're at a good stage right now did was 3097 that was in the um spec release on Friday right was it may I'm not sure I believe it was let me just confirm yeah I think so is this a good thing or a bad thing it's just context for implementers if they're targeting this release it it is out it is in there yes as was the validate blob side car drastic condition a number of other things okay anything else on either the empty Bobs or uh updates on the kcg side library right now the field elements per block is sort of hard coded in the ckcg library and uh like for the minimal spec in on the continuous layer side we have like a different value than what is hard coded guys so maybe we want to make that like a variable rather than have it as a constant in the ckcg library itself uh what is hardcoded exactly uh the field elements per block it is hard coded as four zero nine six and the minimal uh preset for the consensus threat that value is set as 4 so like I think it might be better to sort of have that value configurable also if we want to sort of say a benchmark different values of uh field elements per blob or something I see I see what you mean so you want this to be configurable on the ckcg side like a make it um a compile time parameter or something yeah something like that because right now uh like The Trusted setup parameters also checks that whatever you get from the file is equal to the hard-coded parameter in the CKC so like if you pass it anything which is not four zero nine six it might it will basically crash sort of because there's an assert in the load trusted cetera thing okay all right I think that makes sense I mean we do want these to be a smaller value in the minimum preset so the library should support that so I guess I will I think Ramana is not in this course uh for whatever reason so I can let him know that we want fields for whatever the constant B code to be parameterizable okay that that makes sense thank you thank you and uh one more thing like we were thinking about uh when we uh when we batch that if I uh a range of blocks we also sort of want to do the same thing for blogs like right now in Lighthouse we uh batch TLS verifies 64 signatures for 64 blocks at the same time so uh like on the kcg verify aggregated kcg proof site would it be as simple as just adding up uh like the individual blob arrays from each block block side that we get and adding all the individual kcg proofs and then just passing it to the KCT Library as is or would that be something different like would we have to do something additional on top of that [Music] um I was thinking of what Proto wrote in the comments but what let's let's touch this second uh question what what what what are you saying exactly you want to do more things out of the crypto layer before you pass it into the crypto layer or what um did you say I think he's saying that uh currently we have this verify function that works for one block and uh he wants the verify function to sort of work for multiple blocks so you do like a batch verification because you have only you would need to compute just one pairing I guess I'm not I'm not really sure though where would this be used get uh when we sync basically on the consensus layer side we get a range of blocks right now so presumably they would be doing the same for blocks and blocks with the blocks and blocks by range method and because I see 64 blocks at once and instead of passing like it one by one we want to pass it like badged basically I see so this could be like a helper only during sync right yeah sort of that's right okay uh and and you have found that this is a like the speed the Turing sync is and make sure that it would benefit from such a great batch verification uh like we haven't really tried it yet but uh the thing is that we do the same for uh batch verifying BLS signatures that right now in like the current main net whenever we get blocks we batch verify all the proposal signatures and the aggregate attestation signatures and stuff like that so I thought that it would like be similarly faster if we do it in a batch instead of doing it one by one yeah yeah I mean I just wanted to check it's definitely possible I'm just wondering like Roberto said if it should be part of the library or it should be um okay maybe we can take this offline so we don't have the meeting but I I agree that if it's taking you considerable time to think uh we could do some sort of batch verification to to speed it up I mean we actually used to have one before we we introduced the kcg proof technique a few like many months ago we used to do batch verification so it shouldn't be too hard to bring it back on um on your first comment uh Proto said uh whether it's worth making the field thing parameterizable or just keeping it 4096 for all the presets I I don't have an opinion on this but if you think that's a good idea we could also do that Proto I think it's more show ways domain because uh Taiwan was talking about the minimal specs having a smaller trusted setup than the main net specs yes I think we can do that but just using the long largest trust is there is also slower in Python implementations that's what I saw from the basic pie test but so we haven't generated a lot uh many blog verification tests so far just some like maybe only four or five basic tests um so I will need to try if we can do so uh in the CI test with that with the many setup role does the CI usage so I will try something locally and report it back later thanks okay I mean I can see how 4096 will be quite slow in Python um but uh May and especially as we add more tests it will like get slower and slower but um I mean do the test shall we and if it's indeed quite much slower we can also talk with Ramana and see I don't I don't expect that it would be that much harder to make it a compiled time configurable thing uh if he gives me some sort of build system so I think it we can do it that way but I can ask Grandma to see what he thinks okay anything else on this okay the other open one parents you had this issue about ancestor blob availability check uh that you opened in a while back and um still is it's been sort of pending um anything there you think we we should discuss now um I think from the issue there seems like to be a good consensus on just like we should do cannot import meaning that if we don't have the blobs uh ancestors that's up to 19 18 days you cannot import the sub subsequent blob and I think that just I think the rationale it's uh it is like easier to um rational rationalize because like when you do optimistic thinking you only do this for thinking part but we don't need to sync here so there's no point imported optimistically so I think the next step is just to like um look at the spec and then and then further clarify it which I'm not sure if it's bad today space cannot import or if they can't import but import optimistically so that's just something to check this back for and I don't think this is like a blocker for like death net 3 for example but yes yes it will be good to clarify that in a spec got it okay any comments on that um okay sweet next uh Ansgar you had some spec updates as well the first one uh on the minimum gas price for blobs uh use team to have moved to say we should just uh just use one away and and uh basically go with that any objections or thoughts there okay so let's uh yeah I mean I'm still up here I'm still of your opinion that it's better to be opinionated here because there's no reason to impose the cost of the network if there's no economic benefit it's well it's not a sustained cost right it's like can the network handle this load and it becomes kind of constant over some unit time rather than say building out you know expanding the blockchain or the state forever so I don't see it quite as like that we either should be able to handle that load or not and I don't see it as like kind of a it is an increased fixed cost rather than like an increased sustained cost so I'm not too worried about it so I guess I don't know does it just in like the spirit of trying to get this back to a spot where like it's it's pretty much finalized like do we just leave ends garage PR open launch the devnets and I don't know if later we want to have this argument we can but like and maybe I don't know once like all the time teams have started implementing it there'll be more to discuss but I think for now just to move quicker I'd be inclined to leave it at one and um see if that yeah see if there's like strong objections there Beyond background I think this is a yes um okay and you had three merge PR asgards do you want to give it a quick update on each of them so I think the modulus one is probably the both the biggest ones do we just say too close to the BPL um so so sorry yeah actually that wasn't here uh the I mean I don't so the spec right now uses the value one right right my preference would be to close the piano I think we sometimes make the mistake of just trying to basically not make decisions until very late and then that always just adds kind of uncertainty for people involved I think given how people how much people disagree here and that one leaving it at one for minute launch is not an issue in any way I would prefer to revisit this for the after and just have it in a place where we don't have to worry about it for now anymore but I mean if people really prefer to leave it open I'm fine I'm with that as well I think we should just go that and we can always find it on GitHub if we if we want it it's not like it's a complex like PR either um so if we want to refer back to the conversation it'll still be there um yeah so yes yeah let's close that one do you want to give a quick update on the three other ones uh so the the modulus uh the transaction blog broadcast and the fork Behavior sure so basically the idea was to by the score have all all the kind of spec updates done and so they all these PRS are merged um so that the one was uh we talked about in the past the the pre-com power return values we ended up um deciding to pad the degree value after all so that it's also 32 bytes um the extra cost is so small and just in case um there there are some incompatibility so it's just easier to do that so that's that's merged um and then we have the um the mental Behavior clarification specifically now the spec requires clients to not Auto broadcast for it before and transactions there was a small question last last week whether this should just be recommendation or a um uh mandatory um requirement and Mary has pointed out that if you actually want to be able to restrict your own kind of bandwidth um and and and and because it's the amount of incoming for transactions basically it is necessary that you can actually kick peers that flood you with 44 transactions so it has to be a respect violation to do that so so that's why um respect now makes it mandatory that you no longer you that that you just don't broadcast um incoming blob transactions you only announce them um and then with the 68 um a few the upcoming 868 um version uh you'll actually as part of the announcement also announced the transaction type and the size so that clients can make a more informed Choice whether not to to the requests of transactions from you it'll make transaction Publications slightly uh slower but that but that's fine um so that's that's merged um and then the uh one second the third one is uh ah that was just a like a really small small one it should be common sense but just uh the spec didn't didn't actually clarify the behavior at the fog block itself specifically because um part of the of the of the basically ASP calculation is the the the parent header field with the excess gas but that of course doesn't exist at the fork block so it's just now explicitly initialized at zero at the at the fork height um but yeah it should be common sense I assume that's how people already implemented it um that's all so then from my side basically I don't see any I don't have any any kind of future spec updates that are still missing like from my side perspectives physically you know you know good place awesome um okay Danielle just saw your comments do you want to take maybe a couple minutes and we'll walk through uh your dog or just like kind of a brain dump uh yeah what what you think we want out of this basically um and then we could probably go from there yeah yeah so I mean the the big thing that we want to see is is how much at different data sizes under a reasonable amount of bursts so five or ten blocks um sustained that the chain and nodes continue to function as as expected you know in previous minor experiments we just had the orphan rate but we now have a lot more data on chain so we first and foremost kind of want to look at the orphan rate we want to look at attestation inclusion and success rates which become an indicator of um how well validators are performing which are nodes of quite a diverse type and then we also want to understand if any degradation of that chain data is um kind of random as to which validators are degrading degrading depending on the the slot or if it's a particular set so maybe we see that 10 validators are always kind of Performing poorly at some data load size um which would indicate you know at some bandwidth or Hardware some sort of threshold there there's beginning to be issues um and then additionally we have the prism Sentry nodes it would be good to have some other node type because we might have asymmetries on how prism performs uh or is connected in the graph versus others but these Sentry nodes are going to dump um first arrival time of various messages so blocks adaptations and Aggregates um these this will give us like additional network data as to how um how these these messages are being propagated so you could imagine you know some low resource node in say Australia actually gets blocks like nine seconds late um but most most validators maybe aren't of that type so Sentry nodes kind of complement the chain data it'd be good to have a diversity in region and good to have a diversity in the requirements that they're they're facilitated with um really what we're looking for is we want to know the norm on all of this and we want to know deviation from the norm and then we want to understand deviation from the norm with respect to some of our key thresholds key timing thresholds so you know call it when things are deviating towards arrival times in like the three second Mark then we're kind of entering into the danger zone so we want to understand we want to do this on test Nets we don't expect crazy things to break on test Nets but if they do that's a sign and then we want to carry forward you know whatever the successful data thresholds were on testnets we want to go to mainnet and observe this data I think ultimately what we want to do is pick a number that functioned very happily on mainnet and maybe lower than that given other simulation and pen and paper analysis so that we're certainly in kind of a safe Zone as we initially launched for April 4. I do have to run uh talk to you all soon catch up with you bye maybe beating up from where Danny left off um if these are our goals the current status quo is that we have a very simple script which submits a bunch of 128 kilobyte transactions no weird Behavior was observed but 128 kilobyte is not expected to do anything I would say so right now um I'm gonna connect with flashbots today probably on getting a builder which has a bigger limit I'm gonna start spamming 520 and 10 24 kilobyte transactions um yeah nice yeah I think I think that's useful and I think if we can get even like a like even the 128 transactions like I believe you managed to get 11 in a single block at the same time so like if we spam it about it so we are gonna be submitting full block templates we are the Builder so we're gonna be eating up the entire block and so far the biggest one that we have gotten is like 11 11 128 kilobyte transactions 2 million gas each um another thing probably was the biggest block for girly um yeah happy to refine in any way that people think is relevant that's um parents um yeah so I just have a question for um the consensus layer client teams here like Lighthouse tech crew and low star in the bus do you guys capture um attestation or rival latency in I guess probably not like in the DB right but do you capture that in like the Matrix form for example like histogram yes we do okay that's perfect so um yeah so if you guys do then Perry and the devops team can also launch you guys us outside Century node so the more the better I think Lighthouse dos and Nimbus those two nice yeah nice um and I guess is it uh realistic to expect uh the Builder to be up and running like in the next day or two I think it would be really neat if before all core devs Thursday we could have had you know a couple yeah build their existence set up and I should have it today like that's what I've been told my I've been told that I should have it so if I have anything okay if not okay and I guess that the thing we need to make sure is we have some Sentry nodes up and running like today or tomorrow um yeah so I'll I'll follow up in the in in the telegram chat about this but um yeah and maybe uh one thing that would be helpful uh so uh uh Lighthouse and lodestar you mentioned you have all these metrics uh do you mind sharing like just your docs page or like uh say we're sending this to people already knows like where they should look to configure the metrics correctly if you can post it in the chat here that would be super helpful sure I can do an issue to write us sorry I yeah we we will we will send a link it's not ready now yeah I can get something together too okay great um sweet anything else on this big block testing okay um and yeah if anyone wants to be on the telegram group just send me a message and I'll I'll make sure anything maybe one parting thought on this because I also have the job um in general I mentioned that in the chat but we should have a very high bar and very rigorously defined metrics and I don't want to sound like a broken record or like you know breaking the party but we should have again I think we should we have a dog already let's have a dog which has the checklist of the things that we really need and let's like focus on these things and work backwards towards making the Benchmark successful um just saying this is a process point to kind of like minimize round trips and for us to make this kind of like you know we're doing this to to cover all the edge cases and we should be prepared for all the edge cases so I'd love to see like a more systematic approach at least in the future yeah I agree and I think that so I'm just looking over to changes that he did um so I think he's at least added since yesterday uh a lot of the numbers we're looking at so like you know uh these like thresholds we want to make sure we're not exceeding um so I think that's like a good place to start but I agree we can we can probably refine it beyond that yeah um and I guess yeah and probably the best way uh also the frame this is like if client teams have specific numbers or thresholds or whatnot that they are concerned about um this is yeah you know I think the reason we're doing this is sort of to convince ourselves and all the client teams that this is sound and so like yeah exactly every spray colder in this has a feedback loop that needs to be surfaced and that feedback loop might be the latency it might be the CPU the Ingress the Ingress whatever but it's like ideally every client team would have like a list of like here's what we need to be true for us to be okay with it and then be able to work backwards and the academy all of this may already exist but you know um having it in one place as a single source of Truth matters yeah and you know everybody's having signed on it like ad hoc is good but like you know you have to have things in one place anyway sorry Durant yeah hey no yeah I agree yeah I happen to have a list with all the metrics from all the consensus clients about blog latency and Association latency I put it on the chat awesome thanks I'll I'll add this and that is stuck as well um yeah um foreign yeah and here's how our different clients tracking the people still think launching uh like next week makes sense um yeah well Roberto I see just put your camera on so I'll call on you yeah I mean I I think we need a little more momentum on the client side to be honest um the the good news is I guess the um you know the client API libraries are now pretty pretty solid with him go kcg and ckcg um there's been work making sure they uh interoperate nicely and you know barring the few edge cases and a few of the other um details from the PRS that have been closed just you know over the past day um it's all working pretty well um but as far as you know clients that are fully capable of interoperating um right now within that interop repo it's just that it's just prism and um yeah um lodestar I think is close um I'd love to hear an update from from the team working on that the folks working on that if one animals get there I myself am working on Aragon to get that up to Snuff um I haven't heard a lot about what's going on with some of the other clients though as far as prism goes like I think we still need the the version and the interop repo anyway um needs needs a couple updates one being like I think right now it hasn't combined the beacon block in the side car in the same uh together it's still doing the decouple thing so so I'd love to hear an update on that as well um but you know those are kind of my updates okay thanks uh elected applied yeah kind of they download Star so as of Friday I would say optimistically I completed the full implementation of the current spec I was able to run with the interrupt posts post tip filter for proposed blocks with blobs and retrieve them on the P2P but it's not passing the interrupt because there is some weird protocol issue that I have to debug I think the implementation of the P2P to consume and assert the tests have some incompatibility with us but working on it cool great let me know if I can help is Mophie on the call we can get a prism all right yes yeah I cannot from another mine site yes for now we have like and then the three version complaint client I believe but uh with some bugs and uh no withdrawals yet merged uh like that and the single question I have now is uh how we arrange the docker compose with all the containers uh do you guys see an idea to add the beacon notes like who execution clients more candles or replace a guests for followers like that so what will be in this file uh we want to make a pull request but I just wanted to clarify this question before like what will be continuous set of the network yeah I'm sorry I'm not sure I followed the question repository contains Docker compose which include the beacon notes and the execution site the data and so on and we now need to update uh like at our clients right yeah another mind I believe some here side clients so um should we just add the additional uh Beacon notes uh for execution clients or we can use like we can replace uh I guess as a uh if we can which is in the pair with one of followers like that we want to yeah any ideas always not clear I mean we we need uh to be added to this network and what would you advise yeah I think ultimately we want to have to be we want to be able to fire up kind of mixes and matches of execution clients and consensus clients um you're right though the docker files that are in there do not support that yet so um you know I think we're we're open to um suggestions on how to how to best do that um I don't have any firm ideas myself um um I think this is related to the testing discussion which is also on the agenda and but in particular something that's Hive could support and I will have some time next week to pick up more of the hive testing uh because the first in the testing and also enable to swap clients more easily for testing not only if more um but maybe let's discuss async because I think Mophie also likes to discuss this but he's sick and chat works better yeah but I think in the meantime before we sort of figure out a full General solution just submissions that are um you know fire up specific clients independently of the other ones just to run them through our existing and then tests and make sure they pass would be really helpful well okay uh so we will just make a here just with additional Beacon notes of lodster and uh prison connected to our client and uh let you judge what is the best way maybe any suggestions appear yeah thanks no more questions sounds great uh so for Lighthouse I'd say we're maybe a day away from my car full initial implementation and then at that point until the test net we'll just be working on testing it out trying to get it running um trying to get interrupt working so I think we'll be we'll be ready we want to we use the different execution clients like that sorry are you asking whether we plan to test with multiple execution clients yeah yeah that would be the hope I think initially um we'll just start with one but probably initially get but then maybe a net of my next okay um just to clarify are there any clients who have concerns about the cryptography or need stuff to be done there oh we we can make it work in Lighthouse there's just some inefficiencies um I think for the time being but that's okay of almost a bit um yeah a date from Taco on this because we started working on the Java binding you might be interested also the the better team so yeah um from the cryptography I think we will have something in the coming days uh yeah that's it all right thanks for Georgia there have been concerns in the past around performance of the mempool during verification when many transactions arrive and I wonder what the state of benchmarks there are if any I don't think we have any there um but yeah I'd like to hear more about what the concerns are there well I I think Murphy did some benchmarks it was like five milliseconds to verify the Blobs of a transaction um I don't know if the entire transaction but I think the cryptography part was five milliseconds uh I I know that also answer has an argument on on why uh we don't expect to see too many transactions under normal case on the mempool but I don't know if you're wondering about malicious what about in the existence of adversaries what's up say that again sorry I'm just asking a question to be clear I don't have any opinions here but um what about I understand that in the happy case yeah there's gonna be few blob transactions might be fine but I would urge you guys to think what happens when an adversary spam finds kind of like an optimal number of like transactions and abuses the fact that there's no batch verification done on a client right I mean I think I think one one thing to to to consider here is like um the cryptography thing like I mean even even if the cryptography verification took one millisecond I feel like you know it doesn't make a difference adversarial scenarios but uh if it's one millisecond or five milliseconds or three milliseconds you know like it's in the same order of magnitude and hence it's still the question maybe putting it in anywhere like more granular form how does the attackers cost profile look like when they try to abuse it and if it's fine it's fine but like that's the question I guess like can an attacker come up with a sequence of like blobs that like takes some time that makes it for Mev for whatever I don't know just asking right so I I think basically this is mostly a a question about like um mental implementation mental logic so um now that we have disabled broadcasts I don't think it is a like it this is not a problem that can bring down a note anymore at least if if the client uh is probably implemented in some some throttling for requesting web transactions but what what it could do is of course you could just uh if if it's naively implemented you can spam spam appear and then the people would have to stop processing web transactions so you could kind of bring down the the blood transaction propagation throughout the network um and so things that can be done here and maybe a question would be like should we have a place to kind of talk about this to specify this or something or is it should that be up to clients but what you could do is um a you can batch per peer verification because if I ideally you'd want to disconnect from a peer if even a single verification fails so you don't have to you wouldn't have to do like um bifurcation to actually find out which of the transaction fails you don't care if if they send any one invalid one um then that then that's it for for them and also ideally what you would have is you just have a per peer throttling where basically you just the only doubt the only work Quest you know five blob transactions per peer per slot or something and if you have some rudimentary logic like that should all be fine um again because it's up for clients to implement this is not part of the AP or the specification so I'm just wondering should should there be some central place to discuss this or should there be just something left for clients to to make calls on um one thought here asgar and I was reading the EOP yesterday um would be that just use some shoot must RFC logic or language um I don't know but it feels like some guidance should be giving there because given the fact that we are having this conversation now and have the room kind of like went silent when I asked the question makes me think that you know we haven't thought about that enough or maybe three people have thought about it or maybe it's not an issue and we can just like write it down somewhere but it should be somewhere about the process right maybe maybe the best place would actually be is you it's the same basically the the kind of the um the rationale slash kind of backwards compatibility section of the of the AP where it's not it's not required specification but it is um advice for for client implementers yeah and also might have just said something about the separate mempool also this is the first time I see this so again there's a bunch of ideas and it would be good to crystallize again just in the best interest of the AP yeah yeah I and I think I think asgar what you what you propose myself like um if you can add something to the to the to the EIP um I can also link it in like the Readiness checklist and when get has an implementation uh for the for the separate transaction pool we can also like reference it there um I think the EIP should have at least a mention of it but then we can track you know ways people deal with that somewhere else um right is there any value I mean what I can do is I can just you know whatever thoughts I have I can just put them into the AP um I'm always with this slightly worried because it's so much client implementation details that it might just be something that's not realistic realistic approach for clients to take so ideally of course there should be some sort of I would be kind of happy about some sort of client feedback is there some Avenue to take here to to kind of get fans to talk about this or should I just put something in the AP to begin with and then we can talk about whether clients think that's reasonable right then maybe there's a higher order bit here or conversation to be had around the feedback loops between the EIP process and client development but I understand this is out of scope for this conversation yeah so I yeah and I think let's let's add it to the EIP we can obviously always discuss it on awkwardness uh you know once once clients are like a bit farther along but I think the yeah my feeling is probably a lot of the elf teams just are not even like that far yet and So like um if it's in the eapf if you won't forget about it it'll be there um yeah and then and then we we can obviously this as an awkward ads or on Discord async but it feels like Beyond get there's basically not a uh a team that has like spend the time to to consider this very deeply um anything else on the devnet I love you see yeah I guess just to be like extremely clear this is like solving this is not in scope for the the three obviously um status updates on all the clients which I think all the clients seem uh the previously committed Lighthouse never mind load Star Gas and Aragon all seem on track for the devnet but I couldn't quite tell what the status was with prism um yeah all right I can give an update I'm also working on it as well so I'm mostly done with the synced PPP changes I think we are on track I just before we start a definite I do really wanna run through the eip4 changes with the consensus layers bad test and then switch away all that just to make sure that we somehow among the consensus so therefore we don't like just fail like right away we definitely do not want that so yeah we are on track that's the tldr okay and that's I guess this means all the client teams I have previously committed are on track um so next week uh we're gonna have a call like a day before we were expecting to launch the devnet um ideally by then I guess what's the thing we want yeah buy like next week 24 hours before watching the devnets we should have like clear branches or PR's for every client um and and is it on every client to add themselves to this interrupt repo um basically that's like the the thing you would expect or yeah what's I guess yeah I'm trying to get what's the what's the like product that we want out of client teams before we launch the devnet um I think we should do something fairly similar to like kinsuki or like Emperor just have some the client tracking she was really useful and then maybe Define some sort of like Milestone base like m0 m1n2 and then you keep and then you keep building on top of that yeah okay okay I think that makes sense I can I can put this together uh I can put the high committee together I think and then but then we're saying like the client teams basically we just provide the Genesis file and um we kind of do like m4a where you check your interoperating you know it works and whatnot and then uh we can add some I guess some boot notes in that file as well so people know where to connect but um we're not and and this means basically it's not going to be like a single Docker repo that just runs everything but it's more like you know any team can connect to the devnet with the right uh right Genesis file and and peer settings is that correct yeah okay so yeah I'll I'll put this together in the next couple days uh just so we have this um yeah this this definite checklist and uh do we want yeah actually I did like your idea of putting every of having everything in the interoperative world well so I don't know yeah I guess Milestone as well is that better or worse because it feels like it's it might be better from like the perspective of you know it's tractable and we see where it is is it worse than that like it makes clients do all this config work um that is not really realistic with how we actually run networks and also maybe ends up being kind of a crutch if like you can't run prism separately but I I don't have a strong opinion there um I mean it's it provides that initial sanity check of you know is it going to sink right with our other clients well I guess yeah if you had to if you so say we use this like Milestone uh approach I assume it's easier for clients to have a branch that's compatible with the devnet than to have that Branch part the interoper repo correct um they sort of need the first to get the second one yeah which is fine I mean because the interact repo is simply uh you know it's a sub module which we can point out any any branch yeah yeah okay so just so what I'll do I'll just separate those out in the in the in the Milestone stock so you know like the second the last one is like have a branch that people can use to run on the devnet and then the last one is like have that Branch tracked and part of the interoper repo um um and so yeah so I guess then at the minimum what we'd want for next Tuesday is everyone has like a branch that's working that follows the spec for.net3 um and then ideally it's all in the interrupt repo in like one clean place um yeah uh okay and we only have two minutes uh to go I guess the like next two or more of just like an announcement slash heads up um but we have this and on on Thursday we have an awkward ads where we want to talk about uh Shanghai CFI um oh sorry Xiao AF I didn't see your hand uh do you want to go first oh yeah just uh in case that anyone didn't see the meeting chat so uh there's a bug in the test vectors that really released last Friday but I am generating the new test vectors and we'll uh publish it in 24 hours that's not the spec changes it's a bug configuration yeah okay got it um okay great and then um okay sorry what I was saying is uh result Thursday we're gonna talk uh about shanghai's TFI lists uh there's been obvious formal proposal to add 444 as a CFI protologists put this on the awkward agenda he posted an update also on East magicians and on GitHub about like the status of the EIP um so I think that's that's pretty good like I think we can kind of present where things are at maybe the one thing where uh it would be good to have an update is if there's any testing uh tools or or things we've worked on um to kind of Link those on the uh Readiness checklist um and then the other part maybe that would be good to to have a sort of written update about is just the status of the different uh bindings for uh the kcg library I believe every single client team is covered um but just being able to point to that I think would be would be valuable um so people can kind of know uh that they exist and and it's supported but yeah anything I guess is there anything else people think we should try to like explain or or um or or kind of put together before awkward devs uh on on Thursday okay if not I guess this is a good place to end um yeah thanks a lot everyone um and we'll chat with most of you on aquatives and otherwise uh next week on this call to launch this definite of course thanks everyone awesome [Music]