# EIP-4844 Implementers' Call #3

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

## Description

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

## Transcript

okay let's dive in um welcome everyone to the 4844 implementers call um Roberto just confirmed you're going to be taking notes this time that sound good yes thank you for reminding me um for folks who want to follow along on the notes uh you can hear um uh I'm gonna be writing a call because Tim's on a plane with Jesse coinbase six months um uh before we dive into the agenda I wanted to just quickly check and see there's a few outstanding action items um uh that I wasn't sure whether we followed through on um and they are these foreign [Music] um I think all these guys that are made progress on so I'm gonna check them out but uh let me know if it's like otherwise um okay let's dive in uh so we're gonna be talking about the spec updates Ansgar uh you mentioned that you had to jump on a flight so why don't we start with your spec update um I think the first one that's on the list is the modulus one eip5864 right so um that one basically uh I I think because it's just really too much maybe if it's something that would want to have just one boss energy uh look uh it ended up being slightly modified I'm sure we talked about this last week to also return the degree polynomial degree and I have a personal like small question mark there just a um as she best practices kind of concatenating the the values um right now that the modules and basically an inside value I might not added I think that makes sense I also think it makes sense that the leading and then the 32 by value people kind of following uh as a small business again in case you want to use um [Music] we're having a hard time hearing you because of the background noise um maybe try talking a little bit closer it might get a little slower okay okay let me yeah maybe someone else go ahead and I find a better location okay sounds good um let's come back to the ons guard ones and he's gonna do it uh it looks like uh there are three uh specs that we merged um the first one is the uh get blobs V1 change to the execution API um any additional context that folks want to share on that one um I guess yeah that that was a Proto one Proto any additional color to add there no additional color I think that the exhibition API is updated so please update the implementations too if you haven't already [Music] yeah just more question about this pre-compile um execution spec includes um like some lines about verification of values passed to this pre-compile uh and we do not verify X and Y values there I mean when we verify uh blobs but we do verify it in this pre-compile can be delegated to a cryptography Library instead of validating it on execution site client-side and just to make sure I understand Alexa I think you're asking about the execution specs rather than the execution apis is that right um it's more about pointabalization uh recompile specification yes okay um I think I think I think that's the intent is that we do want to move everything in the go kzg um but you're correct right right now there's some implementations that are pieces of the implementation remain in the clients um that's on the to-do list Alexi just so just so we can fully understand what's the specific thing you're asking about yeah yeah let me rephrase it like that uh so uh Point evaluation pre-compile is described in the specification it includes uh um just to the lens I wanted to discuss uh we are requested to verify that X and the Y values uh uh inputs of this pre-compile need to be verified being less than modulus right uh should we move it to cryptography site and do not verify like um in execution client directly right I think I see what you mean um so the way I see it is that like uh the pre-compile code um kind of guides you into that X and Y are scalar elements and hence need to be smaller than the modulus but you're right but most likely in your implementation you're gonna like you know wrap it into a type that does the modulus check um inside of it now you're saying whether we want to move this entire thing into the kcg library as in that the library should receive like integers or bytes or something and do the pre-compile itself yeah you read my mind exactly right um okay uh I I don't have we we we can if you think that is better for you because you're managing less cryptographic burden on your side uh we should consider it you're right that there is some leaky leaks like abstraction leaks there oh okay thanks uh I mean the point evaluation uh so sorry the key is a Jeep proof um uh uh pretty much takes bites right like the API does it does it not um okay well I I maybe not for this call I can make a note about this about like you know figuring out the interface of the pre-compile for client devs and uh work on it offline so that we don't hug the call yep thanks yeah feel free to bring this up in the um execution implementation the implementation tracker um I did have a chat with um Proto just yesterday in fact about um some of the stuff being moved into go kcg so we can probably align over there just to make sure just to make sure I fully understand what the outcome of that back and forth was between George and Alexei is that do we think we want to make a change to the ghost kcg um ckcg interfaces and the interfaces that we defined in uh consensus specs uh actually it's not like required because uh we already have like bite uh byte arrays based interpreter I I'm not sure that uh we need to additionally verify this modulus constraint for X and Y because uh probably it uh uh will be done on cryptography site too uh I mean cryptography Library side too um so we do this twice and we need to and Marshall with values I mean to uh transform it to integers to compare with these modulus and if we could just pass bytes to the cryptography implementation uh so we could save some like execution time I don't know and write that Squad um yeah it it could be much more obvious if we could check this specification it includes these checks for modulus and uh I I just don't see we need it there investment yeah yeah this is a fair request um presumably the specifically the verified agency improved could you check the module module um the only like not really a major concern is like the those assertions lets us bail out early if the user provides like invalid points um because we do like expensive like uh the case diversion hash later if I were to move that to the kcg library then um if the user provided like invalid points then we'll end up like doing the hash thing which is not good which is not good a good thing to do like really so the alternative is to move the entire function um kind of like what Traders say have that implemented by go Kasich I then client implementers don't have to worry about all that crypto stuff but I think we still didn't need to like keep the assertions prior to like the verification um I'm sorry Murphy which hash are you talking about the pre-compile doesn't have any hashing does it or down the I'm looking at the spec right now the kcg version hash um yeah okay and you want that to fail you want the the basic assertions to trigger before the hashing happens yes okay I see um okay you said it may be indeed to be better than just okay we then provide that heavy calculations before basic chips let it stay probably yeah right I mean Alexa if you're saying that this is gonna make your life easier I think and since ckcg is a very like tailor-made library for this specific purpose I think that a good like indicator that we should uh make the interface better now in terms of how the spec should look like uh because it's not like it's like python so it's not typed I don't see how the actual assert lines can be completely removed because that's like the kind of like the implicit thing that they are scalar types I I don't know how this the spec will look like if we change the interface but I agree that we should look into the interface to make it nicer for Developers okay uh yeah I just found this basic checks quite useful so um maybe the interface can be grouped by but uh my um like statement was just about this two basic checks um that I did not find useful uh previously so it's okay now it looks okay for me okay so I think we can resolve this it is is the kind of takeaway that George and Kev are gonna look at whether there's an interface change we want to make here to the ckcg to add another function yeah potentially okay well let's let's bro let's create an action item to do that and if you guys decide no I think that that seems like a reasonable takeaway as well sounds good great um while we're on the topic of cryptography um George uh Ritz the the last cryptography spec API experience got merged any other like contacts to share there no I don't think so I think the the pr good marriage the interface got simplified um apparently maybe not simplified enough but Alex says comments but yeah all in all I think it's like a simplification so not much to report there if there are any questions we also have like a ckcg telegram group that might be a bit more uh specific if you have questions of how to interface with cksg uh talking to the client developers here yeah and confirm confirm uh let me know if that's right wrong but I believe ckcg now implements these interfaces for client developers who want to be leveraging that is that right uh what's that can you say that a great question again the seek the ckcg implement the new interfaces from uh the 303a change uh so that that that's actually a good passion I'm not sure which um like I know Ramana had the coronavirus at some point I don't know if the branch is fully up to date with the Supreme like there is a branch with a new interface I just don't know if it's like the main branch or not I think it is danker do you remember um I believe he merged it into the um 4.844 Branch now here that we've emerged as far as yeah it's in the 4844 branch okay so yeah another question about sorry I had another question about the interface so like for the load trusted setup function basically is that how we are planning to load all the trusted setup uh values for the devnet like through a file yes exactly that that function is suppose you you pass it like The Trusted setup parameters let's not be definite let that be minimal let that be whatever it may net and it it loads it into the library to do the appropriate steps on the other functions yeah but awesome so I guess just a summary there for client developers who are doing implementations the ckcg 4844 Branch now supports the new cryptography interface um that was just merged um and so that should make uh implementation much easier I also know that at uh we now have JavaScript bindings available for that um which might be useful for ethereum.js who I saw the um implementation to starting implementation and then I believe that there are rust findings and Java bindings as well but maybe someone else can chime in on on that to confirm I'm working on the rest findings right now I like hope to have a PR by tomorrow end of the day yeah I don't think the job Java binding is up to date because there was a Java binding on the original key gcg uh repo but now uh it needs to be adapted with the new interface and I see also that all the bindings are in the repo itself while the original one was a separate repo oh yeah the Java binding needs to be worked at the moment in the end of it the sports multiple ECC backends currently have updated the interface for the BL City backend so for those who need the rest Library they can use it are there any clients that don't currently have uh like clear path on um the cook cryptography library to use for their implementation okay Enrico on the on the Java side um is that currently blocking y'all do you guys have a path to update that uh those bindings we were discussing with the Basu team because actually Tech wouldn't bezel are as far as I know the only clients that are requiring the Java bindings um we have definitely a bunch of work before makes this binding really required so we are kind of uh um planning internally the timing for start working on it uh but yeah definitely if there are some help from outside will be appreciated otherwise at some point the taco team or the basic team will will start working on it assumption is that it should be an easy binding but yeah I'm not an expert on that so don't don't have a clear idea okay sounds good well I will comment for uh an observation that you know two weeks ago there was uncertainty around the crypto apis there's uncertainty around the crypto libraries and now we have a good crypto Library strong apis and most findings on track which seems like a lot of great progress um okay gonna keep us moving uh ansar posted updates in his um on his few things so I'm just gonna talk through what he shared in the channel the first one is the uh modulus change uh that's ready for merge um uh it now return the the module is pre-compiled or the pre-compile now returns two values degree and modulus um uh and he'd love one person's eyes to double check the encoding maybe doncrude um or or yeah it's the right person look at that and otherwise we're ready to merge any any client anyone have questions on the that that change in terms of returning the modulus and the pre-compile I don't quite a lot of people okay maybe someone else I mean the current encoding is literally just uh eight bytes for the length for the number of elements and uh 32 bytes for the modulus um yeah so it's there's no encoding it's literally there's just those two values concatenated so um yeah I don't know if anyone has an opinion on this like I don't know how these things are usually done right that those are the only kind of person like just to make double check we kind of keep keep with how we compared 10 of this usually um and whether there's for example to me it feels like this ordering business regarding the not starting to buy Value First is slightly to verbal because um it makes loading from memory once it's once it's written memory uh slightly more efficient because then once a loaded you don't have to mask the leading bets because you can just take a memory location with leaving zeros anyway or something I'm not sure if compilers are smart enough to do this anyway and it will be even more efficiency again but these kind of things just basically make sure that online coding I think it's fine you can just go ahead with it at least sounds great um so the next one I'm just going to keep giving high level overview uh on score but let me know if you want to jump in um reducing this route of blobs uh values providing to PR currently 256 kilobytes of Target and 512 megabytes um reduced down from one megabyte two megabytes um uh uh that's kind of like we're yeah we're going to talk about the test we're gonna run later but that's the current proposal from unscar anyone have any questions or thoughts on that let's go one question I had is do we want to wait until after we run the kind of network test to merge this fully um or do you think it makes sense to kind of merge this and then we can readjust back upwards if necessary principle just because it seems like there's say no default but um I think either looks they would have strong opinions it's an easy parameter to update so great well I'm sorry I'd say let's let's move forward with merging that and we can always adjust it now um if we if we need to adjust it later if you need to um and then the last one uh is the pr to set a minimum data gas price there's been a bunch of discussion on the PR but no consensus reach for now this is again uh just a constant that we can change in the future um uh but anyone have any commentary or questions there foreign who is driving that investigation or is it just table for now I think on scars the running point on it okay I think we will leave that one open again it's just a big change so it should shouldn't block anything on the client implication um two other spec updates that one talk through one that just got merged um uh and this was uh Proto one from you from a while ago uh to I think just bring everything in line with the new flea market update uh on the consensus specs any additional commentary to add there um I reviewed it but you should credit unscar and I think unscar is sporting his flight so it's not able to comment um yeah I think the fee Market changes already and like they're merged so you can continue with implementation there great is there any questions on the new flea market specification or is it blocked on that in implementation today we do have some tests free market implementation in the devnet B3 demon iv2 as well as the devnet V3 um in case anyone is implementing clients is that are those in the interoper repo is that what you're saying Roberto yeah maybe mostly could speak better to it he's the one that implemented it but um yeah they're um their um spec level tests so they're they basically fire up the clients and upload a few blobs and check things so if your client is integrated you should be able to run those awesome okay uh one last spec update that is in the agenda to discuss I believe oh no there's actually one more after this um and this is yours Mophie the rebase of 4844 on capella can you give a quick status update on that uh kind of where things are and what the next steps are yeah um right now it's blocked on the withdrawals PR um we're waiting to get that merged in so that I can rebase 444 on top of that um yeah that's pretty much where we're at I think we've gotten consensus of uh how the rebate should look like and how are we testing all that's left all Cabela structures and update the pr and we should have that merge by tomorrow morning responded great so this was one of the this was probably the biggest open question in the last implementers call but with this resolved um we are planning to kind of actually let's talk about that three in a second but um does anyone have any kind of questions on uh the decision around rebasing for for on top of capella and how that will change kind of the implementation okay sweet okay the last um uh spec perspective spec changes Terence um I saw you open up a PR to discuss a few things would you mind giving us a quick overview there yeah hello everyone so I open the issue this morning there are a few more to Do's that from what I have observed over the last few weeks so the first one which is my fault I didn't fix this is that um right now the block and blobs are gossiped together but we should probably add a note saying that hey the old beacon block gossip will no longer be supported because I think there's some confusions that people are assuming that we will still be supporting the block uh Gossip topic which will not so that should be easy just a few lines of notes in the consensus networking spec yeah any questions on that if not the second one is that we currently do not have a way to request blob by by um by um root right because now if a block is missing from adaptation you you can request a block by root but we don't have a way to request the blob by root right so there's two ways to go about it the first way is to implement a Blog by root method the second wages implement the block and block by root method just assuming they're coupled together I'm leaning towards the second way just because it's just easier you can avoid too close and sounds like um some side there's a few people agree with me on the Discord channel so I'm wondering if people have feedback on this or is there yeah is there what people prefer so the range requests we're going to keep them separate right sounds like hey yeah wait so the range request we're actually just discussing this too but like we were thinking it might be better to have a range request with both the block and blob and then just a separate block range request just because like at no point you can't do anything if you just have a blob so like why would we be asking for a bunch of blobs yeah I tend to because I don't I don't see how a client ends up having only a block at this point if you if we have the main topic that gives us the coupled version right only a block after if the The Blob pruning depth is less than the block appearing depth so this that would be a reason to keep the blocks by range request but I mean we could just have a sec separate request for blob and block by range yeah my argument for keeping those separate is that you know historic sync essentially you can keep historic sync and add like stable and not have to think about it and add syncing the blobs um and rather than reworking to then have to use both of these methods um and again my argument is in the future assuming full sharding you would still do full block sync and that element and you would not do the kind of The Blob sink which became additive um and so that allows us to kind of keep this core Machinery totally stable um I at the end of the day like I'm not engineering it so I could be against otherwise I think one more like argument to have them separate just so you can sync both in parallel but then you also have this Implement implementation like complexity like what happens if one gets here without the other so I think it's a lot simpler to have them coupled from the implementation perspective yeah I agree because if you make it separate then then the uh the handling of thing two three things two different things that might be go wrong and you start also thinking about optimistically uh validate a block while we are you're receiving the blobs when you you give up when you're gonna try so there are a lot of complexity there if you keep it separate I guess I think about it as just have the blobs as a dependency once I have a range of blocks get the range of blobs rather than trying to interleave them because then you get your historic block syncing you don't have to touch it all and then you just have this kind of secondary follow process that ultimately would be pruned out of the code base so it allows for that to remain totally separate whereas if because there are going to be different pruning depths on blobs and blocks and what you would be retrieving historically then you now have to like interweave you have to totally change your previous sync process to now consider you know am I doing this method or that method and then once we go to full sharding you'd have to then change it again um again that's my argument I I will leave it there so like in the event of full sharding can we just reuse a coupled request response rpcs and then just leave the sidecars like seared out um sure then you have a cludge where you're still like switching between the two um because you're still going to have to account for different printing depths or you're going to change a constant to assume they're printing depths are the same because now that they're zeroed I mean sure there's plenty of ways to try to work it quickly we can emulate the Cobalt's request response methods by just calling one after the other it's not so much a consistency issue as it is with gossips up since we are talking to the same pair so but we still have to handle the failure cases is the thing we're like one peer just doesn't give us one of the two things um yeah and generally I feel like with the the moving window for pruning like that's not too much of an issue so much as like we're not at the like we have some margin of error passed where we're pruning where all the clients just like still have blobs um and yeah generally it's like having um The Blob and block like separately yeah looks simpler but I think because we have to deal with these edge cases that might not ever happen it makes it more complex um and then just using one request at some range and a different request at another range generally in implementation I I think is actually simpler and and what happens when I'm my clock slightly off and I make a blogs where I block and blobs by range requests that is out of your printing depth through I return zeros you know there ends up being edge cases there as well yeah I think that can be resolved generally by just like in implementation we don't specific specifically code this to like the minimum Epoch depth for like what you serve but just don't request past it if you happen to accidentally request past it like clients should have like some epochs of margin of error um yeah foreign to um download blocks and blobs in parallel as opposed to like having one big request uh Diva made the point that our bottleneck is actually processing it's not download and if you are a question separately you can't process them so you have both so it doesn't really make a difference I don't think we'll be able to come to like a conclusion from this close so should we just um follow up on the issue itself yeah that sounds about to suggest that makes sense to me and I also it's um 3087 but yeah I was also um discussing so my second point was basically we need a blobs by root method or we need a block envelope by root method right so um any objection for have having them coupled for um by root the thing with the by root request response methods is that some other clients like numbers have made the case in the past that sync should not rely on this by root methods as much and maybe even only have these by wood methods supported for a recent part of the S3 us and it's much easier to index the finalized data linearly and then store it in optimization disk and so on we have whole new file formats for this and everything and then creating this by root method just kind of Ruin starts by introducing like an additional database index to find everything by root yeah this is I feel like this is more for like missing blood from attestation more like from the current Epoch or the last few slots right let's say if we introduce it we can limit the usage of this to the more recent part of the chain so that we don't require like additional database exchanges in clients yeah that sounds good I mean I also feel this is more like the general issue than for it for for a specific right because so if we repeat the same issue then we make it much harder to clean up yeah okay so that's all I have those are the three basically questions or ongoing discussions I want to follow up on just to confirm where we're leaving these on the first one it sounds like we should just open that spec change parents are you gonna are you gonna do that yeah happy too great um on the second one it sounds like there's more discussion that we might need to have or are we yeah do you have a decision on the second one or we can open up a new PR for that one as well I can open a PR but we don't have to like merger like right away and just let it like marinate and discuss and just see how it goes yeah okay and then the third one it sounds like there's active discussion already right right right are any of these blocking um yeah I I don't I'm not as well versed in these domains are these kind of like core blocking spec changes or would they be more kind of like things that were that will make the expense yeah like how important is it to drive resolution on these over the next couple weeks do you think from a kind of like spinalizing respect perspective well I think the second one is definitely important for the death net 3 purpose just because like today if you're missing a block you cannot get a Blog then you're kind of stuck there so the second one is definitely definite three blocking but it's not so hard to respect and also to implement the third one I think it's fine I mean you can we can spend a little bit more time on it just because like I think it's for the death net 3 purpose it's not super important to like backtrack or bad thing I mean it's a nice to have but but but but it's now a blocker got it okay well I'm one for the second one which seems like the more critical one um do we think that there's a path to try and I guess is it something we can decide today or if not what's kind of the path to getting it decided in the next couple days so we can continue making progress towards seven to three yeah I just feedback from everyone so I will open the pr and I will post a PR on Discord thing and um yeah just hoping for feedback from everyone okay sounds good Proto it sounds like you have opinions there and so I think you weighing in there and and helping us not that long would be really helpful all right I'll review um I think there's a nice compromise here where we do support the Beirut method and some firm or another but the limited by root usage to a time span not as long as the full by range support so that we don't have to create a database index to support those methods great okay are there any other active spec changes or spec discussion that folks want to raise before we move on to discuss the devnet 3. okay let's move on to discuss discuss devnet 3 um quickly wanted to just look at this [Music] um spec overview that we have can folks see my this screen now with devnet3 on it I think yes yep awesome um so I believe that there are no changes on the execution layer side um we are going to include the mod just change that should merge um but there's nothing else new that we need to uh do there on the CL spec we have now merged the cryptography API we've merged the fee Market changes and we have a resolution on the rebase on capella let me just quickly make these changes in line for doing it we have so these two are merged so we can take those out because they're in the main spec uh and then the 3052 we plan to keep that in we pan to keep that in the the devnet is that correct yep yep okay great um and it sounds like we can have that this week correct no um and then it sounds like there's also one other Terence the the upcoming PR that you're talking about um with the uh with uh allowing blob retrieval by uh rude yep and does that have to be do we have to block the devnet or do we want to to kind of put that in the critical path for the devnet I think so just because like there's no way for us to proceed if today we are missing a block and we don't have a blob so you're kind of deadlocked there so yeah but you should have made that hard to pers yeah to make it happen okay any other El or CL changes that folks are expecting to be part of the devnet last time we had this upcoming PR to block broadcasting blog transactions by default did we do that is that just the gossip oh no sorry that's nose it was basically changed to and I think there was debate between Ansgar and Marius about whether we actually wanted this to be encoded in the spec or not um I think that was uh my understanding is it it was like related to East 68 and not necessarily part of the VIP I know Maris isn't here like I remember like there were two approaches to block game broadcasts one is to do it by the transaction type and the other is to um do it by the size of the transactions on Honda which direction yeah and I think the debate was basically do we need do we need to actually include this in this spec or not um and and we it looks like we haven't had an action item for ons guard to update first Best Buy net blobs must only be announced um but maybe that didn't get done I was premature in resolving that action item um so maybe we should I I don't think this is strictly blocking the devnet um but we should follow up with oh yeah Ansgar is on the call still great Ansgar can you open the pr to to do that yeah great thank you announcing and then they can pull yeah exactly okay because they're too large to be pushed on gets default limits yeah yeah that was basically the compromise we came to at um the Devcon workshops uh to make it easier for the clients to manage like dos vectors foreign okay so we will get that in and then this engine get blobs by bundle that one is merged so we can just have it there this includes withdrawal field as part of the engine API I believe that that were blocked on 3052 on the CL spec to get that in there Mophie is that right yeah yeah we're definitely clearing up okay so are you going to um once you do we have a PR open for that or can you take an AI to um open that PR once the cl's back changelands um yeah sure um also relatedly I think should we also update the eib because the VIP does specify like what uh the new header should look like because we're adding like the iso status us um it's not a big deal because I think most client does should understand that we should include withdrawals but in this in this interest of completeness I think we should also EIP to just say that it has a dependency on withdrawals yeah okay so we get are you going to take that as well sure okay um and I will make the note here uh upcoming PR to highlight dependency on withdrawals any other commentary it looks like mostly it is the things that are actually the mod just change is going to merge and then we need to get the rebase on capella um and that but other than that the scope is basically locked in any questions thoughts objections cool I think with that then I was wondering if it might make sense to do a quick client like roll call what clients were expecting to have um or participation as part of the devnet um I uh we had gathin prism existing um do folks want to quickly check in and say whether they're interested in participating in the devnet or not uh yeah for Lighthouse we definitely want to um we're pretty far along in implementation but currently working on um integrating kcg and uh flushing out sync so once we get that specked out we can oh my God yeah another mind comes to join two uh maybe not with everything working uh though I see kg Library yeah need some tests and attention and other stuff not yet merged does that mean that you'd want like a smaller allocation of validators as a percentage of network okay sorry I missed who who is that what which client never mind yes yes and then Roberto how are you feeling about the uh Aragon at this point yeah I think it's very doable we will do Aragon likely at this point any other Basu taku um I know Nimbus hasn't had the bandwidth to get started and I think that's the full set yeah very unlikely I think very unlikely for Basu as well all good okay well a sixth client devnet I think would be pretty um pretty awesome so keep pushing in that direction do folks have a sense of like a high level Target for when we'd want to be devnet ready we're ready for devnet 3. I'd like to shoot for before the Thanksgiving holiday I think that might be realistic it's sort of like we need um some degree of lag from after the specs completely stable and like I don't know it'd be nice to have before Thanksgiving but I feel like we will need the least a week more realistically two weeks of lag after the spec stable so um yeah yeah I think we can stabilize us back by Monday Tuesday next Monday Tuesday um with that timeline do you would like those four things you would still be feasible uh I don't recall what Thanksgiving state is exactly but yeah I think the week after it that seems challenging and give us one week um yeah cause there's a coordination component that might make it difficult but I think we can get the development done by then yeah all right excuse is the all core Dev school this week on Thursday or is it next week on Thursday this week this week and there's the next one on Thanksgiving on the 24th who knows oh sorry I think it's muted yes okay um okay it seems like we should be prelimited yeah I I think luckily we have a very Global audience um it seems like we should probably be pushing for the the week after Thanksgiving to have the devnet fully stood it up based on what we know today I think that make it more likely more teams could participate which would be good yeah I mean come come Wednesday on that week I just I think a number of U.S people are going to drop off for a few days and so that means like trying to launch it on the 21st the Monday which give inspect changes done maybe the 14th like that's a really tight turnaround foreign ly plan to launch on the 30th of November which will be the day after our implementers call that week which will give us this week to basically confirm all the spec changes done um next week to get implementation the next two weeks to get implementation done um and then button up any loose ends that the first half of that week in launch devnet 3. that sounds reasonable to everyone uh uh so let me just add this I mean targeting launch on 11 30. we will make it by the end of November um and I know we have all core devs on uh Thursday of this week so now I know um and it seems like from a spec perspective really the changes are the withdrawals change um uh and then this one conversation around the blob retrieval by root uh because the modulus one is is gonna merge Mophie Terence oh I guess Terence just left um I think the more we can kind of push to get those two spec changes at least having a line of sight to being done um so by the time we go into all core devs we can say hey we're basically finalized from a spec perspective I think the better okay um we are at time uh the last update that the two other items here uh that were prospectively on the agenda with the large box bam test um and the Readiness checklist the Readiness checklist we can update async based on all the the progress here in terms of the large block spam test Dan is Dan Lee here from paradigm no it doesn't look like it the I can share an update from them um we have uh Paradigm is going to be running uh the first iteration of that spam test on testnets um either this week or next week and then we'll move to mainnet and that's going to start giving us data on kind of current Network characteristics which we'll be able to use to finalize the blob um size and to just in general build our confidence around Network so folks have questions um or thoughts or want to be involved in those tests um there's a telegram group that we have and we can add you to it just let us know foreign that's all anyone have any final comments questions thoughts I guess last ask for me this is my first time ever running this kind of meeting in ethereum development if you have feedback um or thoughts about how it could have run better please feel free to reach out I'm Jesse Pollock on Discord and Telegram and Twitter um and would love any thoughts on how I could better show up for ethereum okay thanks everyone have a great day bye bye everyone bye