EIP-4844 Implementers' Call #1

um I think yeah we could probably get started uh people are still rolling in but we have a good a good group here um so I guess uh the goal with this meeting is basically to make sure we work through all of the spec implementation issues as they come up um and that we're all sort of on the same page um about where things are at um we're gonna have them weekly for now um and we'll see uh as long as they're useful we can keep them at that Cadence um and we might slow them down at some point if we feel like um yeah there's not stuff to discuss every week um I guess yeah the first thing I want to go over so there's a bunch of open PR's in the specs and I think it's useful to just understand where they're at if there's any blockers on them and and this way the folks uh working on client implementations uh can can know kind of uh what to expect and and you know what to keep an eye out as they're working on stuff um so first one this one's been open for a while and I think we basically just have to merge it but this one is uh yours and guard the fee Market one um oh and then Micah left a bunch of comments yesterday so basically yeah yeah so specifically I think the the status was that uh I don't think there was really any remaining uh open open issue um there's my first time really actively working on the specs so I was a little bit hesitant to just you know push forward for it being much but I I think it should basically be ready but then yeah yesterday Micah left a couple comments um and I think the only one really um that that still has to be resolved is uh I think people disagree around this one constant which is the the minimum um and they date I guess per per blob um so I think basically they had three different positions the original intent of introducing the constant um and I think they came out of out of some conversations that metallic and I had was just to have it basically be a basically normally non non-binding lower bound but basically um the idea would be that this this would only ever be relevant in case a in the very initial phase of the of the Yepi going live there's not yet demand so like a one-time kind of kind of just um a floor or if there ever was some Network difficulty or something for some reason for a while there couldn't be any blobs so the price would fall that it doesn't fall all the way down to to zero or one basically like right now the the normal 1559 basically can go all the way down to seven way and then whenever the network would recover it just takes a while to to run back up to normal levels and of course because you have subfloor that normally is irrelevant but like this hit whenever these conditions happen that's a bit higher than you kind of your ramp back up is faster and you and and that is somewhat relevant because the random period of course means that you have like a sustained period of double X Network load right because you always hit the hit the limit not the target um and when we're talking here like an order of an additional 30 minutes or so so right and so I think right now basically the the ramp up with the content would be something like 15 to 20 minutes coming from all the way to the floor to some reasonable price level uh without the flow if you go all the way down to one basically it would be something more like 45 to 50 minutes um then there are some people who actually want to make this be like a really high floor that is actually binding and kind of has some opinionated approach of trying to prevent spam I personally am very strongly posted that just because I think we shouldn't be opinionated uh what constitutes payment what doesn't um and then there are people like Michael very strongly want this content to be one because they think any anything other than one is basically invalid opinion by the protocol so anyway this is kind of like one Niche last conflict to be resolved I think uh once that is resolved the pr should be ready to merge I guess there's anyone on the call have a strong opinion about where this should resolve so um so my feeling is this basically so generally I mean I would agree with first um I think it's very unlikely in its current form to be a binding constant like even very soon after and the whole thing is launched just because I think there are like uh just stupid applications that don't even have to do with blockchains that we would use this like this is cheaper than my roaming data fees so like let's be honest it's nothing um Okay so um the reason um and so I think it's unlikely to be really like a problem with them and practice the reason why it makes a little bit of sense to like be opinionated in this case um so where would contradict is that um so in a way we are actually subsidizing something here right so we are introducing this new thing and um and uh it is um foreign we don't have a way to scale it just yet and uh and so like I think like um at uh initially it's very likely that essentially the rest of the ethereum network is subsidizing this new thing that we're introducing in order to get Roll-Ups off the ground so that's why I think it's actually not crazy to just add a lower bound to that and the kind of lower bounds that we're discussing are basically still very very cheap um yeah another way to see this by the way is that roll ups will in practice actually have much higher costs uh to use this like if you look at the um pre-computation uh uh or as the the pre-compile um it's 50 000 gas at the moment um so um in practice that will be a lower bound at least for ZK Roll-Ups that will be much higher than this and so you could also argue that it's kind of unfair that applications that just want to have file share on the ethereum blockchain or um uh I don't know or restore the jpegs for nfts on the ethereum blockchain they'll have this uh super cheap data because they don't actually need to connect it to the actual blockchain in any way um I'm not super I don't have a super strong opinion on this I would prefer raising the current lower limit by about 100x which would still make it very low in my opinion um and it basically uh yeah I would would remove some loud people on Twitter which I think shouldn't be like our major concern but I think it's a relatively trivia change and I don't see any downsides hence guard as you have your hand up again all right um yeah two things I'm yeah I I don't love that approach I personally I would prefer and I think I think there's broad um support for lowering the the Target and maximum amount of blobs or in in the case of the updated uh fee Market basically the the the Target and the maximum amount of data gas and I think that makes a lot of sense basically starting with even something as low as basically uh one two or two four um as as Target Max um for blobs um and for the for the first rollout of the EIP I think that makes a lot of sense and that already basically um very much limits any impact of potential Span in but in an unopinated way so I would much prefer that but as a more kind of like a how to move forward from this um so I'm wondering what we could do is uh I could I could update the pr to set this constant to one inside the pr and then we could have a separate PR um changing changing that and and have the discussion over there so that we would remove it as a blocker for for the free market Pier but would that make sense and by one you mean one way right that's right yeah yeah but like just just again like as a as basically something we're like okay now if we want to actually set it to something that would be an opinionated choice to be made in a different location I I would I think that makes sense and the thing with one uh does the because with 1559 we have this weird integer mat which means if it gets below seven it can't go back up do we have the problem with that here there's no problem okay no no we don't okay good okay yeah because we have the accumulating um yeah so that they can keep accumulating it at some point it will start impacting okay yeah I think I would I would move to do that just because this PR has been open for like over a month if we can just take out like all the contentious bits move them to another PR there's like three other comments by Micah that are just like descriptions so I think probably makes sense to just you know uh the the resolve those but the one with the actual constant gets decided we can just yeah have a different PR and and discuss there sounds good to me that's fun to me press one to that anything else on the free market PR oud um just a quick question on that it sounds like um nothing as of substance has changed since the devnet was released at least or is there something were there changes made since uh this is Roberto by the way I left a comment saying um you know when I put in the changes I'm wondering there's been so much back and forth I've lost track of uh whether there were any substantive changes since since we last implemented it no I I think I think you um right right when you when when the first uh definite with it came out they were like some last minute changes before then but that was before they've gone um since then there have been no subset of changes and and then okay great perfect and it sounds like we're up to date thank you oh sweet so yeah let's uh split this one out into and merge uh the the actual free market bit and we can deal with the minimum fee um yeah separately um okay next one vitalik had this comment about adding a modulus up code or modifying the the pre-compiles such as we can we can take the modulus as an argument um he's not here but I'm curious um if anyone has strong opinions on that then if that's something we should be adding to the spec now because if so we probably want to notice sooner rather than later this is probably a question that's best for the L2 developers I don't know if we have many of them in the call today right yeah as I understand it this is more of a user experience Improvement and not something that's really necessary for at least LTS in particular um we can deal like we can just keep track of uh what the current modulus is across upgrades of uh 444 in the future and it's not necessary but it isn't nice to have because it's like my take on it would it introduce an extra trust assumption where basically now it would have to be part of layer 2 governance to uh to update the modulus they use because if not they could kind of falsify proofs sort of like we already do have like specifications that our user rely on particularly to like make challenges so it would just be part of that whenever L1 makes changes to this we would make the corresponding change in our specifications and then users can yeah so in a sense yeah it will be part of our governance process I don't think that's a bad thing or it's a Blocker in any case and is this basically used in the same way by optimistic and ZK Roll-Ups or is there like a difference in need or requirements on on this front wouldn't you need this though if you wanted to eventually freeze the updating of your contracts right is it's only mophier you only are you always going to be in this state where you'll be able to kind of make these changes whenever uh there's an update to say the version hash ideally we should but it would be much easier if um if the pro if L1 just handled that uh yeah I mean like that's a nice thing about thing about being able to access somebody just from other ones if we can do that then uh we could at some point have Roll-Ups that uh don't need any upgradability functionality but can add the update to a new version hash which would be really cool oh um is it possible to say add this in the next hard Fork so say we add say we Implement foreign yeah can we but there's also there would also be a very simple change to 4844 which is to Simply make the point evaluation pre-compile return the modulus in addition to the result yes uh well then yeah I guess you could do that but then you would also need you always like where does the contract that calls it get that value so if it returns it yeah if it returns it on like a successful evaluation um yeah that seems like a small change now yeah um and I assume that's not something we could do in a separate hard Fork I don't know is this like the dirty like a one-line change in the I don't have a feeling for like is this a value that's already being used as part of evaluating the pre-compile or is there more work they're like expose it as the output it is it is already being used in the pre-compile yeah so that's just a question of like exposing that as a return value while you're making that call what's that right yeah yeah and just to briefly come come back to kind of the question of whether to take it in or return it though um conceptually it seems cleaner to me to to to have it as an input value because the point of evaluation pre-compel already uh takes in an external proof that has to be provided from from outside so basically just in a way it was would just extend the proof format to also include the modulus correct but it would mean that the proof size goes up from 48 to um 80 bytes so is that I mean is that a good idea that seems like why like it just seems like a some useless data that you have to pass in now every time um isn't it the same if it just returned well for the transit I mean it's just some value in your memory right like if you don't do anything with it now I assume that 90 of contracts for now will not care this is really for the hardcore I want to make non-upgradable contracts which will probably come even like in one or two years at the earliest um and uh and only they would actually read this value from memory and the others can simply ignored right like you don't have to do anything just because some value is a memory so it seems like this is less invasive as a change of course it also doesn't change yeah it could be an argument to be made that we kind of want to encourage trustless architectures um so making it more explicit right but but yeah maybe but adding extra cost also seems like a stupid thing I mean what you're suggesting adds an extra cost for everyone no but that's not right right because it's my contract that just trust that could start code um like database don't want to be future proof right hard code the value and then yes just upgrade for the others with ads but for the other sets at that cost but if they return it then they can simply use the return value and feed that to their zero knowledge proof verification no but you still need from the outside someone to basically say we we expected the modulus to be this no can you check whether well we do currently have like assertions that each point provided to the pre-compile like fits into modulus so either way that's a different thing that's independent no I'm contradicting what unsca says no you do not need some external Oracle telling you this modulus like it's simply yes you do need it for the proof but the contract would only get a proof would well I mean a proof of the pre-compile as they know it's proof for the roll up State update and uh they would uh um and they would fit that modulus into the witness sorry not the witness the public inputs for the roll-off update proof and so if you get it from the contract then no you never need to pass it in from the outside this data does not need to get into there go to the call data okay so yes what I'm suggesting is a is a real efficiency Improvement I mean maybe tiny I don't know what the other costs are they are very likely to be much larger but anyway so I guess for say we went with that is it worth it for somebody to draft a PR to the EIP about like basically what it would look like in the EIP and and like the how also l2s would would use it um and then we can discuss like the pr async and you know make a decision in the next week or two if we want to merge it but it seems like clearly this is at least worth considering and I think if we had a specific PR against the EIP we can share it like not just with optimism but with the other L2 teams and and just get feedback on that before we we merge it um yes let's do that yeah then crad there endscar does either of you have the bandwidth to like do that oh and Scar has a thumbs up nice um that was just for the idea but yeah well do you like I'm not so sure I'm tuned in very much to give a lot of motivation so I I can do the actual spec change but um on the motivation side I'm not super tuned in thank God can you help with that yes sure okay okay sweet so they create a nice car and then um yeah we can just uh put it in front of the different LT teams get some feedback on it and if it's a small change then we can included in the next couple weeks um sweet uh okay next one uh Terence had an update on uh the sync specs so basically um the idea I believe we discussed in Devcon was uh we couple blobs and blocks for kind of gossip and and quote-unquote recent sync but then we decoupled them for historical sync um yeah I see there's some conversations on the pr I think at they've caught everyone who's pretty much on the same page here any other thoughts comments on this with so the um one thing with that I was still curious about is whether we're still planning to sign the blob sidecar I think that was a little up in the air like if we're gonna gossip them together then RPC we don't necessarily need to do the signature verification um and if the blocks have references to blobs inside them then the signature of the block would in theory be enough maybe Proto so I just discuss this change with Danny and others.com [Music] um it's indeeds we can do it either way we don't need to signature it's mostly a performance thing we're verifying the ginger might be cheaper than verifying the commitment and so if we don't want to allow spammers to like give us lots of different data maybe it's better to have a signature to check first before then verifying the commitments but I want to like hear some numbers from people that Benchmark this type of thing otherwise I'd rather just simplify the protocol and remove the signature and how should we Benchmark this exactly I think someone here working on libraries might already have numbers um like just a cost comparison of verifying the commitments that come with a blobside car first is just verifying a single bless nature I think it's strongly in favor of the POS signature there I'm just not sure if it's significant enough like to be a kind of those factor or if like who wants one way or the other got it um and I guess yeah we want to keep this PR open until we have that okay and yeah I see you basically have comment Thread about that in the pr um and Terence was saying he doesn't think we need the signature for the sidecars right um right you can verify the sidecar matches the the beacon block itself just by verifying the commitments yeah the commitment certification cost is the main concern on the execution client side I think we got comfortable with doing that signature verification or the commitment verification it was something like three to four milliseconds per commitment verification is there any reason why we'd expect it to be different on the consensus side foreign oh I was just saying on the on the execution layer we got comfortable from a dots perspective doing the kdg commitment verification I'm just wondering whether there's anything different about this uh on the consensus side that would make us get to a different answer in terms of instituting the BLS signature as a workaround um basically Inc so for execution we're once with the approach of uh just announcing transaction hashes so the client has the um I guess the client is free to pull them whenever and if it becomes like a Dos issue they can start disconnecting peers in consensus we don't have this luxury because we couple the sidecar with the beacon block and everything the beacon block is valid and the proposer is valid and whoever is sending them are valid then we would always like in the worst case always attempt to verify the sidecar so we don't get to choose or at least we're not we don't we're not as flexible as execution to like choose to whether or not to verify sidecars or not foreign block cannot be matched against the beacon block so it's probably fine to remove the signature and just rely on my commitment check okay can someone just comment on the pr after this call so parents knows like this discussion and can probably make the changes on it I think that we are already removed okay okay anything else we wanted to change or discuss music okay uh yeah well one last thing I did have like a comment on the pr and uh how exactly we want um um one sec how exactly we want to um sort of like gossip those the couple blocks inside cars like what are we doing with the old topic um is it is it going to be deprecated from now on or is it still going to be used it wasn't quite clear to me how we go forward from this I left a comment on the pr so okay I didn't always discuss that async as well I don't think we should keep the odds uh topic around with only the blobs or only the beacon blocks we should just have one topic a little operation to couple durames for consistency by creating more topics or we keep the most guys that we wanted to get rid of yeah that makes sense to me um I had another question um I'm not sure if there is a comment about this on NPR but since we're getting a couple blobs and gossip then are we thinking of like more tightly coupling the blocks and blobs in like the execution engine Beacon node API because like obviously you'll need both to broadcast anything API and there's some expectation that the engine always has the blobs that match the book that was being produced so even if there's an inconsistency it should be trivial to get deep lobs where some repair to pair you might have an entirely different mesh of bare spare because of topic so you don't have this guarantee that the data is there so so let's see we could couple them but we don't really have to and for now I think it's nice to stay compatible with the existing API okay instead of introducing a new version of the amount of anything else on this VR okay and then Terence had another one basically proposing uh 18 days uh to uh to keep the blobs um you know based on some conversations we had at Defcon like it seemed like two weeks was the upper bound everyone felt comfortable with I suspect 18 days Maps yeah it maps to a a neat number of epochs um yeah does anyone have a strong opinion about this or disagree at the very least does anyone uh does anyone think it should be longer I know some people were arguing for even shorter um but I think I I haven't heard anyone argue that it should be longer so if not I think we could probably just merge this change and if we want to make it even shorter we can do that in the future change okay I will take silence as a yes uh so all the parents know and then the last oh sorry yeah sorry yeah I was just generally wondering about like what's like why 18 days I guess like is it supposed to just encapsulate like the longest fraud group periods we might imagine or is it supposed to like set like it would be like a precursor to how long you need to retain data in full sharding for like proof of custody or something like that or like is it supposed to be longer than the week's subjectivity period or right as I understand it it's um the longest fault proof and you know say you were like not on say you were like not online you had to like sync a new note from scratch and you wanted to participate or retrieve some data um two weeks felt like that and then the other thing was as well seder was a weird consensus issue um that happened on on mainnet and for some reason to resolve this consensus issue we wanted to have blobs still live on the peer-to-peer network two weeks is the period where we generally think we can solve pretty much any issue on ethereum um so it gives us like some some that some room there um yeah cool thanks yeah but it's a very yeah it's a very uh soft uh metric there's not like a hard requirement yeah yeah yeah um okay but yeah I think we can all agree 18 days is an upper bound we can change dispect to that and um uh yeah go from there and then the storage requirement like a prism said uh at one Meg Targets this would be 137 gigs it's extremely likely that we have a Target that's like well below that um so less less than 100 gigs I would say sweet okay so those are all the actual spec changes for 4844 oh sorry quick just click going back up one on the um coupling Beacon boxing Bob's is there like an action item there just don't want to follow up with parents just to like give them a knowledge that we discussed and decided on it yeah that was what I was planning to do uh okay yeah I'll I'll let him know and then I'll send him this recording as well so he can have the the context of the conversation I think he's probably the best person to just move those PRS forward yeah foreign okay so the next one um basically this one's like a bit tricky where um the idea of like how do we rebase 4844 on capella um Tim did we miss the do we want to talk about the photography oh sorry yes actually yes I did miss that one yeah yeah you're right uh the okay yeah this is uh George's PR about uh the cryptography API um yeah sorry uh so I thought yeah there were some reviews on that one I think Roberto you added it to the agenda um and you had some questions recently on the pr um so yeah do you want to take a minute to walk us through our where things are at yeah I don't know if I had any particular opinions on it I just wanted to make sure it was everyone was aware of it it was non-contentious it looks fairly straightforward to me yeah um thank God I see you were part of the yeah reviews a few days ago foreign I guess anything outstanding on this uh the pr by George about the cryptography API update in the Fiat Shamir logic so I believe it well so okay so it is ready um there's one very small question on whether we need domain separators and uh Dimitri will still look into that but um the change for that will be trivial and actually they are already placeholder variables for that so it would simply assigning value to these placeholders and even if libraries don't Implement them as they are which uh the change is still trivial so um I think we should merge that PR and then maybe uh yeah like Dimitri will still tell us whether he thinks we should add those okay sweet and I guess uh and I guess yeah Kev was also having a look so uh opinion Kev making sure I don't think Kevin's here right yeah no so Pete and Kev um oh yeah he oh you are sorry yeah yeah uh yeah yeah I agree with Don credit it's just the domain separators that are the main problem uh and I guess do we expect to like have an update on that in the next few days or is it something we're gonna need more time to determine um I don't know about the next few days that I'd have to explain quite about Dimitri's availability yeah um but yeah it's not a blocker to the actual uh PR and uh it's only a blocker if we want test factors fixed test vectors that right and I guess yeah and the reason I'm asking is just like if there's client teams that are looking into implementing it should they just basically look at this PR assuming to be part of the spec effectively and it seems like we're saying yes yeah exactly but there are there's ckzg and a few libraries around that sort of uh just implement it and client teams just need to look at the public facing API which won't change okay okay that's it okay perfect so okay so for the client themes perspectives it's it's abstracted by the library and then the work to implement this would be in ckcg basically right okay see anything else on this VR is there a person who's gonna own merging that yeah but by the way as of now I don't think all that logic is in go kgz I think a lot of it is in the clients we're moving pieces of it over little by little but it's not quite there yet yeah I flopped your uh government brunch and I was modifying the API I just haven't pushed a PR yet I pushed one to prism uh in fees brunch but not to euros yet oh sorry Roberto if you want to go and then Proto okay I mean I I I'll have to take a look at it PR I haven't seen it yet but that's that's great uh parole yeah I do think go guys let's see how's the necessary methods nicely cooked together as her um if we merged the pr that's Upstream C if it is in a federation form so I think we're complete now maybe I'm missing another method I'll take a look if we're missing anything um there was an actual issue that I opened up yesterday that um I think go kdg needs to basically check that remove the check that field elements are non are canonical um if I think the issue is free zero freeze three zero five seven um so I think that's the only thing yeah sure any particular reason why we need to remove that addition uh yeah so if I remember correctly Murphy said that uh for the when a blob is canonical it's not up to the cryptography to decide uh whether a Blob should be canonical it's up to the person that's encoding the data specifically yeah out of range like it's a few like the the bias have a value that does not fit in a field elements shouldn't just be inference yeah that's the point I was trying to make the data is allowed to be um out of range it's whatever the output of the encoding that should be basically fit in the field element and kev's point was that there are cases where you could have different data mapping mapped to the same um encoding well I guess it all depends on the coding in that scenario I would argue that the decoding is invalid and useless any correct but the point was the cryptography shouldn't be able to verify that the data was encoded correctly because that's all up to the user we can still have like the field element checks you know to make sure that it's it fits within the modulus but um the data itself it's not it's not something we can check because it's already encoded if that makes sense so I would say that if the user wants specific data to be followed with respect to the crypto functions then they can just apply the modulus or cut off the the fights that are the bits out of bonds it like there are many ways to map like data to some points in a like a specific integer range I'm not sure if he shoots create expectation that people can just encode data however they like outside of this range and then still compute commitments offerings yeah I agree was that was that did that make sense Kev um I'll just make sure that we're in the same area yeah I I understood it as Proto is agreeing with what I was saying but the you agreed as well so I'm a bit unsure but we can take it offline I can post uh the link to the issue as well here okay anything else on the pr Ok Okay um I think that was it for all the you know proper spec changes um we have this draft PR by Mofi about re-basing 4844 on capella and I guess uh the background here is that the current devnets uh kind of implement 4844 over Bellatrix and I I think the the sort of rough consensus we had reach is that it makes more sense to have this rebase on top of capella instead um and and uh but then that means it might be tricky to do some of the testing while capella is not fully implemented in all of the clients um so yeah Mophie do you want to take a minute and walk through like what's your PR proposes yeah it really doesn't propose Much Anymore the original draft basically rebased 444 and capella but added introduced a feature flag to disable Capella's specific State transitions um based on feedback in the pr I think we can we shouldn't try to enshrine such flags and the spec so the latest revision basically removes that it's simply rebased on capella but there's a section at the bottom of the spec for testing that outlines the uh necessary functions we want to stub out for eip44 specific testing that way we retain the capella containers and Concepts but no withdrawals or withdrawal interaction actually happens when testing eap44 got it and so that basically means that Cabela is a sort of like no op Fork that happens and the clients run through it but then yeah they did they don't have to have a withdrawals implemented in order to test support for changes is that right yeah okay um I'm still not sure if um I guess it depends on like client teams implementation and how their code bases are structured um I'm not 100 sure if this would be feasible depending on how like client teams Implement those functions that I've outlined to be stubbed right so this doesn't solve the issue of um yeah I don't know I guess we'll find out during testing so yeah I so I guess yeah um there's a couple client team uh contributors on the call here I think if you all can review this PR that would be great and I think um we should definitely bring it up on the CL call uh next week as well so that it gets the attention of like all the different client teams there um if if it hasn't in the meantime yeah um I'm from Lighthouse I would generally say that like we really support this because um having like the consensus objects in the EIP 4844 Fork look like what they're actually going to look like well like on net reduce a lot of work for us because otherwise if we have like a 4844 without withdrawals um like Fork I guess in a Jess cappella Fork without 404 and then like um this new set of consensus types that might be the most uh like accurate in the future this sort of equates to us having to support three different Forks um so if like if we know what drows are going to be included then this change yeah reduces work for us by like eliminating a fork essentially yeah okay I think uh for techu we're not opinionated we do all of our development on on Main behind feature Flags so we don't have Fork issues so it I either way is fine um on that see and then Dan you said yeah you've managed to implement it this way on lodestar um and Terence is aware of this because he's commented on a PR so maybe uh what's the other client uh yeah just maybe getting Nimbus to have a look at this um would be good and then yeah it seems like if Nimbus doesn't have like a strong objection to this we could we could probably move forward um anything else on this and I guess yeah the Assumption here is like any interrupt testing you know what not we would do moving forward with likely be you know using this format of like a stub capella um which is different than what we've used for the devnets uh historically okay um okay next up yes uh one thing I just wanted to check in on so um for the KGG libraries um we obviously we have ckg those bindings being developed and go um are we is anyone aware of like a client team that for whatever reason can't use any of the libraries that are being developed um or that needs you know specific bindings or something that like does not exist uh for them yet I don't think Russ findings exist yet but I know there's a couple of people interested in working on them okay so rust's bindings for uh kcg Library opening foreign sorry uh I was saying I think the same situation for Nim um right so Nim and rust both need by names after the kcg library and there's a question for another mine uh okay so there's progress as well on a.net but it's not there yet okay so we have.net in progress rust and Nim missing but then every other client team is is fine yeah um dotnet side we just need to update according to the new peer which includes simplification of the API and uh we will integrate like that we do not use old API version we want to use the new one foreign I guess yeah we can figure out offline um for the rest and and then this implementation and how to best get those done unless someone has wants to volunteer for them here oh and it seems there is a rust library in progress um yeah okay um I guess next thing I want to cover like uh there's a bunch of different client teams here um I'm curious to hear just generally where teams are at with their implementation and if they have any blockers or things that you know they think everyone else should be aware of um yeah um I guess I'll go over the order I see you on the video then I see you've started like a load star pull request that's right um yeah it's all going fine in lodestar there's a bit of a question about how we're gonna uh use ckcg we need to generate typescript bindings but I'll figure that out when I get there um I'm basically up to the networking so I have all the types and uh params and config in there um hopeful that I can get the networking and then the blob verification done this week um okay just going through the list Ben any updates from the take two side yeah we've barely started uh on this yet um in the next couple of weeks we'll we'll get off the ground but uh uh yep it shouldn't be a huge lift I think see foreign Works since the uh I guess the devnet which is still based on Bellator extracts um actually Terence is uh has a branch on eip44 and I think we would want to like start moving development to his Branch because it contains like the latest capella structures and um basically it's more in sync with uh prism Upstream nice uh Sean yeah so since Devcon we've mostly been focusing on um essentially mophie's PR to rebase 4844 on capella um then pawan's also been working on unifying the gossip topics um and I think we're pretty far along so we're hoping to join the next test net um with uh like the Cabela's trucks as well um that's about it from us cool uh Jerry well we didn't start working on it yet I'm assuming today's planning will start sounds good um so this oh we didn't hear you you came off mute but we didn't hear anything sorry uh sorry so yeah so yeah I was mostly working on Guiding you guys to to work on that kcg Library uh so I would say we probably will not start much on the client side until we have a bit uh more work done on the kcg library I think so we'll join a bit later got it um Alexa uh yeah uh we have work in progress uh it's a great important for us to have some Milestone I mean what should be on tablet three like that and we will align to that and uh ZD is to join this network and uh provide some functionality but I'm not aware of what uh certain peers will be included what do you want guys to see there uh like that yeah I think uh yeah I was gonna sort of finish up with the third deaf net I feel like next week we should probably spend most of the call on that like this week There's I think a bunch of open issues that we need to clean up and and get merged into specs and then I think in next week's call we should be able to say like hey you know this is basically the scope for the next devnet um does that does that make sense I suspect every team has at least one week of worth of work to get at least like the basic full implementation and re-based on capella oh okay this rebase is a bit disturbing for me just because it's new for me because we have withdrawals implemented like a part of Shanghai Fork as far as I remember and probably if we will replace uh it will cause some issues for us maybe I need to check yeah so I think if teams should definitely look at like we're basic all the 444 stuff on top of Shanghai or capella um and then you know all the PRS we kind of discussed today but then I think next week will be in a spot where we have like we're able to more crisply Define these are the sets of things we want to hit that if that makes sense great yeah yeah see thanks uh Roberto uh yeah I've just started looking into Aragon I'm going to be um working on that through the next week nice I haven't made a lot of progress yet though nice and I think Marius you're the other one sorry I didn't hear you oh sorry I was just I think Marius is the only other person working on a client implementation now [Music] oh are you still here Marius oh connecting to audio yes hello yeah we're working on a bunch of other stuff at the moment uh so we don't really have a stable withdrawal branch that we could rebase on top um I'm kind of today I started looking into the the list goal bindings for go for ckcg um that's going okay there's a bunch of fish issues with it right now um but uh yeah so regarding withdrawals as I said it's uh we don't have the normal withdrawal functionality in the code yet we have a branch but I'm not sure how far along that one is so got it any anyone else working on a time to implementation that I missed okay we have about a minute to go but um I wanted to make sure we also cover this um one of the big things we're working on for testing is this idea of uh having a large uh large blocks that we send full of call data on the network and see how the network handles those as a way to gauge um you know our our blobs viable from a peer-to-peer uh perspective um Dan do you want to take a minute or two and talk through where things are out there and and what are like the next steps foreign yes yeah uh so we're just trying to figure out um kind of like the logistics especially how we would submit how do we actually fill up these blocks with two megabytes of data so I think we've found um there's some issues with memorable propagation if you try to submit like a really large transaction I'm thinking maybe try and maybe boost but the issues that that's extra integration work and not all validators run mbb boost as I think the latest suggestion was um from Tim to try to submit to validators directly so I don't know exactly how we would do that but um yeah just literally figuring out how to actually make sure we get you know the transaction our transactions are the ones that I get picked and um you know trying to get as close to the full two megabyte less than that as possible uh consistently through in a row right and then yeah mirrors this might be a good question for you so get limits how much how big the transactions can be gossiped in the transaction pool um um yes yeah Matt's confirmed this morning I think it's 128k yeah we can patch that is there yeah is there a way yes no so if we want to do this on Main net so we want us to make Big Blocks on mainnet yeah yeah you want to submit Big Blocks on my net with call data yeah yeah no okay we can we can we can submit Big Blocks on our local network but we cannot do this in a minute like this this safety feature is there for a reason and uh like removing it would be yeah yeah I'm not saying we should remove it from get but I say I guess yeah and we can take this offline but basically um Stark starkware did it a few years ago how did they do it would be the question that I have well they need to control you need to control the block producers right okay but okay so that's the way it's like basically send them to either flashbots or through like some staking for or something like that I mean you're saying one block producer right well it depends how you know how how many you want to do sure yeah sure um I see yeah so wait so okay so what what does the gas block limit it's like 128k and we would like yes that's not produce blocks larger than 120 uh transactions exactly transactions so you could do it by sending you a bunch of 128k transactions yeah it doesn't guarantee they all get included in the same block right um foreign a bit more for gas than they should be yeah yeah that might be the that might be the simplest way um yeah and then we can probably wrap up right I just wanted to say that uh given that we haven't yet had any post merge load testing in general I think this we should be careful maybe not to immediately start with some Megabite loads but kind of slowly ramp up to there so just just in case we noticed that you know even at 500k then it works already struggling right yes this should there should be a moment to stop so I I think basically I I don't see much of a scenario where like this would cause permanent damage to the network well it might just in case just because projectors could just watch this and be like oh that's easy to actually bring down the ethereum network you know yeah and it does cause permanent damage because it increases the history and as long as we've got look we are looking we're talking about a few megabytes We're Not Gonna add gigabytes to the history no that's not this is not a valid argument um so I I I don't like I I think it's not I mean yeah you could flag that up to someone sure but like I mean honestly someone who's I don't know anyway we need to be resistant to that attack so I I don't think we have to be that careful I'm pretty sure well but I mean even temporary networking civility you know like we I think we we all kind of have pretty high reliability standards per minute and so I don't know I just yeah I probably would feel much more comfortable if it was like a multi if it takes a one megabyte blocks to like bring it down then we're already not satisfying that standard in my opinion so yeah yeah at least we can just use one vanilla guest like one megabit blocks will already bring a bunch of validators down that's that's just how it is like a continued one megabit blocks um there are a lot of valid editors that don't have the bandwidth requirement require required for this and uh they I mean what is a lot sorry what's a lot like let's just be honest it's not a problem fine they missed some meditation who cares it's nothing they miss they they lose a cent per attestation look it's not a concern like Bane mainnet is not gonna go down because of this just because we've designed it so that 30 can go offline without anything happening sure but if we can minimize however much we take off I don't I don't care why we why we need to start testing this on mainnet oh we don't start oh yeah we won't start a minute no for sure oh I I like of course we could do this we could do this test in in like a month on mainnet I I don't care about this but like we we shouldn't like yeah but test match are not going to tell you anything interesting because everyone runs their test net nodes oh well you would hope that's the thing so if if this works strictly on test Nets then you can move the mainnet but if we break something on a test net it's much better to have broken it on a test net at first and so I think we're already I failed people are being over cautious here but yeah fine I mean I think yeah we're already over time my feeling is like just gradually ramping up the size of things we do seems to be like the best way to go and like we probably don't have to deal with this like being bigger than the get mempool transaction cap for now um even when we moved to mainnet we could probably do like a first test with something like um um yeah we could probably do the first steps with something like a bunch of 128k transactions with like a relatively high priority fee and hope that most of them get in the same blocks um Perry uh talking about with metrics we want to track does it make sense to just move that to next week as well because I think I don't think that well first we're sort of out of time but um yeah I don't know yeah do you want to take two minutes and maybe talk about it but I suspect to get a full list we'll probably need the the chat I think we can we can do it async then that's fine okay yeah so that's I guess yeah let's in the next week uh discuss this um in the in the telegram group about this if anyone wants to be part of the telegram group talking about this experiment uh reach out to me I'll add you um and then I think next week uh for this call if we can have uh you know the issues we talked about mostly resolved a cleaner spec or Target for definite three and then uh a sort of set of metrics to Target for the for the this experiments that would be that'd be really good anything else uh before we wrap up okay yeah thanks everyone um appreciate sitting on a couple extra minutes and talk to you all soon thank you