EIP-4844 Implementers' Call #9

okay uh we're close to the holidays I don't know how much bigger of a crew we're gonna have so I think we should go ahead and get started um okay this issue six eight nine on the PM repo there you go uh we'll talk about some lingering spec items which I think are very near just clicking the merge button um devnet three updates I'm not sure who's gonna give us the update but someone can step up uh George just gave us a quick on the large block spam test um quickly revisit the pick a power benchmarking and then if there's anything to hit on the Readiness checklist as we move into the new year Okay so we had discussed this many times on how to handle unavailable data outside of the prune window there is a PR up 3169 that will be merged today which I believe reflects uh the general consensus on this both on this call and only consensus their call if anyone has any final comments please say so now or jump into the issue really in the next hour or so because it's time anything on this one okay great the other one also is kind of a last call in that um how to handle this Edge case where um in certain contexts you might not be able to get a sidecar whether that's past the prune window or outside of um you know the 444 Fork depth or whatever it may be and the general agreement here was to have a particular error code for the resource not being available and then you can try on the non-unified beacon block and blobside car you know this was by coupling this was a known Edge case that we're going to work through and there's a PR three one five four with this this is also in the state where it's going to be merged very very soon today so if are there any comments on this or um otherwise if you don't have them here jump in really in the next hour or two any comment sorry what was the pr number again this is three one five four I'm gonna drop it right here thanks yeah great okay and then um I did open up an issue that I shared um I wish I had noticed this earlier but just where we're doing this data availability check in the spec um is a bit strange with how the Spec's been designed thus far it kind of brings it's like hidden and should be cached input to the stake transition function or hidden and hidden to me not the right word but an additional input to State transistor function other than the block and even a data availability sampling it would be kind of a square Dynamic call to the network um how things have been designed it's more appropriate to go and kind of fork choice and be a Blocker on uh getting the tree in place from a from an engineering standpoint you know things are done probably in various different places and results are cash for example you know you do you do parts of the state transition function when you're checking gossip like the proposal signature you probably cached that then you go into your fort choice so like the actual like implicational engineering I think is pretty low here it's more on getting the spec in a slightly more standard place and where this would be tested in the spec um I believe on everyone that works on the spec uh regularly uh there's General agreement here um seems like Mikhail kind of agrees here too and uh but I I I'll leave this up for discussion I'm happy to take questions or discuss right here um sending an input but I just want to kind of draw your attention to this that I likely this is going to be shipped around a little bit okay please take a look at this if uh you are curious or want to weigh in this is 31.70 on the consensus specs rate though are there any other spec updates or spec discussions um any any pressing items on possessive specs uh the EIP or engine API um so I'd be interested in talking about um an idea yasik brought up um which was rather than gossiping blobs like could we possibly gossip just blocks and then directly request blobs via RPC once we see the block so you can there's a bit of a chicken and egg problem here if you're only um doing the requests on the RPC then at initial like it it's much you don't necessarily have like the blobs well seated in the network and you end up kind of just hammering exactly who just sent you the block um to get what you just asked for there are like mixed strategies on Gossip networks where you kind of you you and we have this in Gossip sub kind of implicitly where you you push to summon you announce to others um so you know it might make sense to find a more explicit hybrid strategy here where you're the push announce ratios may be different um but I think that what you end up with if you have purely uh only announce on that is that you end up which is like a much slower instant gossip and if those blocks are getting far ahead of where the sidecars are you know you'd be asking people that don't even have what you want and then be searching around for it so does that make sense in that you like you kind of need some amount of push to get the network seated here yeah like the way I would think it would have to work is you wouldn't be able to propagate blocks until you had a blob and then you would always ask whoever just gave you the block for their blob but I could definitely see that being really slow but on the other hand like now please uh I was gonna say on the other hand like not gossiping blobs would reduce the bandwidth's concerns and then it also generally structurally looks more like what it sounds like full data availability sampling might look like so I thought it was an interesting idea so I guess generally what we're trying to do here is potentially increase the rounds of communication but reduce or eliminate the amplification Factor because so I I know at least if you're honest if you've given me the block that you do have the blobs and I can ask for them now if three other people give me the block because the amplification factor I don't ask for them so then I I kind of take some round trip hit communication hit on each step to eliminate the gossip amplification is that is that kind of the strategy here um yeah I mean that sounds like it could work I I don't really know I just thought this like uh line of thinking was something that was interesting to explore I guess and I get it sounds like it's been explored to some extent but I mean this is already in part of the spec right that we're not supposed to announce the blobs it's not implemented in devnet but it's part of the specification as far as I recall uh right now we send like the blocks with the blobs together so it's like I guess an answer one of the blocks oh so this might just be just for the um transaction gossiping then rather than the blah blah yes yes there was a a trade-off on that one and not but transaction gossip is arguably less timely and so the kind of like uh announcement and the round trip is more okay um at least can be handled I think with a little bit less care than with the block here um I guess Sean the other I think I think that could work um I think it complicates our gossip rules a little bit although I think we can kind of shove it in there um I think it it's going to make each hop take longer but it's going to reduce greatly reduce the amplification Factor on Gossip I think the other thing to consider here is the uh episode because episode attempts to try to reduce the amplification factor of all Augusta but in a more kind of generic way um but I'm certainly willing to kind of like put this on the table as we discuss things in January it might be we're very worthwhile yeah I'd be interested in like I don't know testing it out experimenting a little bit has he or you or anyone open up an issue I know this was in more of like a DM chat no I don't think so okay I can open one after the call yeah thank you um any other initial thoughts on that not for me very cool let's take it to an issue and discuss I think certainly there are probably a few different strategies to reduce the bandwidth here that would be one episode would be one um Erasure encoding together uh but we can let's let's keep that conversation going in in January thank you uh any other stack items great um devnet 3 updates I am not I've not been following this so I and I'm not sure who on this call has the info but if you do please speak up foreign yeah um I guess I can structure this by requesting updates from people that have been working on the ferris clients um I I can start with um prism um taryn's already posted like his update on the uh on the Implement is call PM but basically prism is pretty much um up to date with the devnet um there's like a couple issues like what president Terence highlighted block spot blobs by root isn't quite implemented but I don't think I think that's something we can um I guess update eventually and it's not necessarily for the devnet to get it operational because it's it like covers one Edge case for the dev nut um but yeah prism is ready and um Roberto how's um the um I think Aragon you're working on how's that going yeah it's it's um I've made considerable progress uh it's not ready yet though um maybe by the end of the week I'm hitting some pieces to code out um that are quite different than Gaslight so to set me back a little bit okay and uh speaking of guests Geth is also um pretty much implemented um and um is Alexi or frilly curly in the call maybe we can get us an update on the um never mind uh yeah uh we linked our implementation with the latest I guess and recent changes and looks like it it's working uh there are some known issues um but well not very critical it's it's still be able to be on in the network foreign and uh Sean for Lighthouse yeah I'm still sorting through a couple sink bugs but I think I identified the problem as of this morning so I'm gonna try to fix that and test it today um but other than that we should be there excellent um any other client Dives in the call I want to share their updates so we have been successfully able to interrupt with get an as well as generating a transaction and sort of including it in the blog uh mostly we are ready for buying drop excellent and the things why I I think I'm there representing ethereum JS as well since entry is not here or ethereum JS as well we have made a considerable progress and we are also able to interrupt for ethereum.js with load start and I think at the MDF would also be able to join my group great that's good news um any other client devs yeah here Taco um we're progressing um on the storage for blobs sidecars and we are progressing on the networking for the erpc methods so um currently what is is still missing as important is the async logic so but everything is is kind of progressing and we expect to be able to join some test Nets by hopefully by the end of January to be ready for for the meeting claw thank you for the update um I think that covers all the client devs um so some some extra news about the stuff not um we actually do have a tentative and I'm very particular the word tentative The Cure um because we only have one client combination working um which is Geth and prism we have a devnet deployed adherent to devnet V3 spec with those two nodes I would like to add more clients including specifically never mind Lighthouse since they're the closest and I guess um code star um into the devnet so that we can get more like we can be able to test the Deep behaviors just like client interop um I'll post the details of the devnet configuration and parameters on the uh eip4 4844 testing Channel but um yeah hoping to see get some more contributions here in the devnet is that I meant already running yes it is okay so maybe we can try link up the.net locally and that would be a good idea yep thank you nice are you sending blood transactions on this debit yes I am and uh yeah there's like a hack indeed user guide similar in the style of Def W1 whereby you can interact um with the devnet we have a bunch of public endpoints exposed so developers can start building some tooling similar to the previous stuff not on top of this one yeah it all works out fantastic great work I have a quick question um I'm looking at this devnet 3 Dock and look at the milestones and then at M3 uh how did the El plus CL interrupt test sectors work I apologize I'm not familiar with this this is your repo Mophie so I guess yeah okay so that um basically we we have um a suit of tests um it's similar it's styled like Hive tests but they're more succinct um for every client implementation we add that to that repo and execute those tests and if they're passing then um I guess they're good at least for the most part we've already gotten some contributions to um get those tests passing for various clients but we've been running it through a couple issues um integrating the clients with the interop repo um gotcha yeah the hard problems um do just for my edification or any so like our gathin prism passing M3 um death in prism is not passing all of it there's one particular test in prism um that is not passing which is historical sync um okay I suspect the issue is mostly on the client side it's more of a technical issue than it can census critical issue which is why but for all purposes um prism and gas they should be working fine for the for like that that's not sure okay thank you any other discussion points were devnet 3. great thank you Murphy thank you everyone um large block spam test we have a status update here maybe Georgia's or maybe Georgios is not here does anybody have any visibility on this I know um we're they're going to be running another wave of tests with the additional monitoring up but I do not know the status of that okay well we can Circle back outside of this call and see how the monitoring worked here um I guess to contextualize the bandwidth reduction proposals whether it be episode whether it be some a different push-pull strategy I guess these types of tests and simulations will hopefully help us help inform us as to um whether we want to add additional complexity by following one of these bandwidth reduction proposals okay pre-compiled benchmarking Kev are you still here I saw that you maybe had to drop out uh hello yeah I'm still here uh yeah I wrote in the chat uh never mind gave some numbers last week uh for 52k so it's uh a lot closer to the original estimates um and yeah Nim and Java client uh I think we're still waiting for estimates from them okay but we're increasingly honing in on that 50 to 60k number and nothing nothing unexpected on those benches have shown up after we resolved the negative case right right it seems that we just need to optimize the go kdg client a bit more okay because that's like 67.

uh in the best case it's uh 67. but the worst case it was going to more than 100 because of the garbage collection yeah it was just doing a lot of allocations yeah okay hey what's the average yeah um I can't remember what Martin said and this is uh with uh which Library um I don't I don't remember what the default one it was using it might be kilich yeah okay yeah yeah with good knock I think the the worst case was better than go kzg's best case and so there's like a big difference and help me understand are the allocations are there lots of allocations in one call and thus the garbage collection can be kicked in or is it because of the benchmarking and repeated calls that kind of ends up being allocation blow up that hurts some of these calls um it seemed like it was in one call okay okay but I guess other libraries coming in at the numbers that we expect the signal to fix the library that doesn't rather than to tune to that library but we can continue this in January cool thank you uh anything else on the pre-compile benches excellent um the last link that Tim had in here which is linking out to the Readiness checklist I don't have particular items on here it looks like you know testing is certainly um pretty important thing with respect to Hive transaction pool especially on the execution layer um any updates on testing just in general uh hello hey just okay so I did updated notes with the progress of Hive testing so there are some good PRS from Mario let me put up some PRS what if we did is we added support for go workspaces in Hive so now we can deduplicate the does not related codes of these type simulators meaning that the it does not that's basically runs these simulators that spawns these clients we can reuse for for it before and for other like future eips now aside from the workspaces and the go to duplication we've also been working on some extra features like metric support and hive My Hope Is that eventually we'll have some benchmarking in half where we can asmets metrics which might be really useful for the blobs benchmarking and I believe Mario is working on the withdrawals testing and with that in place I think we can basically on top of that also implements for testing but there's this sequentiality error if we're going to test the the engine API of like posts are high the the it might depend on the the returns testing got it okay any questions for Proto or any uh further comments on testing okay um anything else on the Readiness checklist I'm gonna do a pass on this for example the setting the Min gas price is still in there but that PR is closed it's a few things like that but hey Danny can I Circle back to testing real quick with a quick question do we have an ETA on updated retest teeth um cases I'm specifically working on the kzg pre-compile contract and I was wondering if anybody had or if there were plans to start working on ref tests for that same same question basically extends to all the different types of functionality we need to add yeah I can Circle back on this outside of the call I'm I know the intention is there I do not know um if it's at the immediate top of anybody's list Mars do you have any visibility on that if you're speaking we cannot hear you um I'm gonna make a note on that and follow it no problem thank you okay um anything else on the Readiness checklist really any other items we want to discuss today excellent we'll close thank you everyone happy holidays we will reconvene this call I believe the first week of January yeah that January 3rd and Tim will again be leading the call oh yes thank you for writing us okay cool happy holidays everyone talk to you soon take care uh happy holidays