EIP-4844 Implementers' Call #7

okay so hey everyone welcome to uh the seventh Now implementers call for 4844 a bunch of things to cover today as usual testing specs devnets um to start uh though Georgia's gonna give us an update on uh the large block testing because he has to hop um recap what's happened in the past week or so yeah thank you team so the update from last week is that previously we're blocked on providing transactions that are bigger than 128 kilobytes because of the TX full limit we got plugged into the flashbots Builder which itself is connected to a good amount of relays Quark in turn plugged into a good amount of hash rate on girly which let us submit bundles uh which had one megabyte transactions so we got a few blocks with one megabyte transactions we've got a bunch of blocks with 10 or more 128 kilobyte transactions we can do it reliably so now we're at the point where over the weekend we got some blocks that were bigger and some people were monitoring their networks Etc so now the next step is for us to improve our bin packing for the bundle I.E kind of like optimally bundle as many well like one megabyte plus one 520 512 kilobyte plus one 256 kilobyte plus one 100 you know whatever um to basically make the block as big as possible um so that the one thing that we need to improve to make the Benchmark better and the second thing that we'd like to improve is how reliably we can get multiple bundles included in a row because we get outbid by others and I just haven't figured out yet why we're getting out of it um so if there is more hash rate that we can get to if there's more stake that we can get inside of the system to make bundle inclusion more reliable that would be really nice so that's the progress update um another thing that we'd like to do is to start running this for the 4844 devnets like proper um because the code path might be different and also more importantly because there is this mempool verification there's a bunch of like new verification code for kcg which we're not touching obviously right now with the call data benchmarks so tldr The Benchmark has been done at small scale we're trying to make it at bigger scale and we'd like to try it also out for for it or four in the near future anything you have to answer any questions or brainstorm or discuss if there's anything there so we have a third of the network running Med boosts on Gordy um do we know another big chunk of validators who is not currently running I may be boost so I know client teams have like a fair amount of validators I assume the ones who are involved in this are writing it but I don't know does anyone have an idea of who we could reach out to to add a bunch more so all the client teams together should be roughly 80 or 90 usually definitely not all the time things are running as far as I know just the EF and I would if I had to guess it would be prism surrounding it but for the other one thank you is running 5K validators on girly uh but uh we're using flashbot so you you were um so the beads were coming from flash boss relay on on girly yeah and I think that's that's what we're using for this so you would already be part so we were part of the whole wait but if I understand correctly I think Techo has more than five key validators so it's there should be more that aren't running it yeah but not all are running under Mev boost yeah I think no need for us like to go back and forth on this necessarily like but if you guys know more people that we could like put on girl in my Boost that would be fantastic and Tim it's so I just messaged him that I've been bidding with point one Eve um it doesn't need to be more like the bids like I looked at all the historical bids on maymet and like anytime yeah anytime I get out of bed it's because somebody like just looks at my bed and outbids me so it's not like um it's not like it's not a static system like other people are also trying to get their bundles in because they're screwing around um but yeah like if people want to send me a bunch of like girl leads I'd be happy to take it with okay yeah so right now or we're only getting these Big Blocks in through mad boost yeah Med boost generically or do you have to hit uh they have to be connected to like flashbots or a particular relay I'm submitting to anything that conforms to the East Sand bundle API Okay so if we ran an analog of this experiment on mainnet we would likely be able to hit a fairly large amount due to something like greater than 60 being connected in Memphis of course of course yeah yeah this this is designed so that it's kind of like you know One Click Change for Maynard got it and that's why to me it's important that I get the bidding algorithm proper and the bin piping algorithm so that you know I don't want to be overpaying for all my blogs on Mainland like okay yeah and we can look uh yeah we we can look uh offline um if there are clusters of quarterly validators that were aware of that we can reach out to um the main ask so the main ask from the group is to just make sure that people's metrics apis are up and if people are going on this um or if there's like somebody that's blocked or whatever like let us know um because I think this week by the end of this week we'll have like we'll have production as this or whatever you want to call it um and then we want to start hammering like reliably like all the time got it and I would like I would like to run this for like 10 minutes for example like I don't want to run this for like five blocks Perry and others do we have initial metrics insights like things seem like we're Gathering the data that we need yeah that's actually one of the asks I've shared um or Andrew shared a couple of dashboards earlier today if you guys could have a look and let us know if something more needs to be added then we can work on that over the next week but right now based on what we've seen there's been no like there's no cause for concern like nothing changed nothing was unexpected to be clear I don't think that we should be using the data that we got so far as signal because we haven't run really anything serious right like yeah we just need to know that we're getting the data yeah yeah yeah yeah of course just making exclusive that the fact that we got you know three one megabyte blocks or the three two megabyte blocks actually like with one megabyte transactions and over the weekend doesn't really mean anything yet yeah and I think I got some of these metric dashboards thank you Yonex attestation analysis that he just put out um using some of those tools this is all on-chain data that might be really valuable as well I just shared the blog post cool thank you sweet anything else on this okay um we had a couple spec uh PR's issues uh from last time and and new ones that we wanted to cover real quick um first one uh that lion had uh this uh PR 3141 um I don't think he's on the call oh and Danny I think you literally just commented on it uh 30 minutes ago anything we should discuss here about it um so I think from my understanding that there's generally agreement to not allow this to grow unbounded in times of non-finality so I think then wanted to reduce complexity and tutor kind of know the load that's happening here um I think the question really becomes do you and unbounded in non-finalized period If you're trying to reorg to something that you don't know is available of more than an 18 day or whatever the prune depth is do you say is data available is true or do you say is date available is false and there's certainly some educated attack scenarios to kind of consider here uh also some some ux around if your client was offline and what the recovery modes look like so it's it's kind of some trade-offs I think still to discuss uh happy to discuss a bit more here if people have questions about the state of the conversation but also it seems like we're pretty active on the thread anyone have any other thoughts comments on this okay so yeah we can just continue that uh async um and then uh yeah Terence uh we had uh your issue also from last time uh uh 3125 um it seems like this is just ready to merge is that correct yep Ready to merge nice yeah I think I'm good other than if you can just change the header comment to say what this does now um just for posterity because it's a bit confusing if you read that yeah yeah okay and then the last one I think is another one that Brian asks uh for uh three one one three um so oh wait is this the exact same thing no no no this is not the same thing as the previous one um and yeah I I've I'm sorry I don't remember what we discussed about this last time um is Sean or anyone that's been on this yeah give us a tldr or um oh Enrico as well yeah oh yeah both of them are here yeah um yeah so the issue is about how we want to handle cases where uh we need to make a like get block and blob by root request for a missing parent block um because when we do this we don't know like at what slot the parent is um so that means we could be making a query for like before the 4844 Epoch for example so we don't know whether to make a request for a block and blob or request for a block based on like the current spec so the outline suggesting this might be a reason to uncouple the block and blob request because then you sort of have like just an optional sidecar in that scenario and then the other solution we were considering was making the response to the block and Bob by root request be in enum like a union type in as I see that's either a block or a block and blob so yeah it's the tldr I'm not sure where we're at with that I for us at my house we've sort of just kept the coupled request and not bothered to resolve this um Edge case for now um but yeah right so from Prism side I don't think it's that hard to be something to basically resolve this case because you can just call the block and blob and check the error code if the error code is say something like unavailable you can try the block by Route after just like a fallback case I mean it's pretty ugly but I think like it's okay walk around yeah this is also something that will fade at into Oblivion once we're finalized and kind of firmly past this range right well it depends about I think the the error code the 437 error code specific specific for this situation yeah but at some point you will not get any any of this equation anymore but if you got yeah I don't have the details of the error code but if you we can exactly catch this situation by error code and just retry in this very educated that go away it's okay to me uh one thing is when you refer to a union you're referring to SSG Union yeah right I would want to avoid something kind of dirty in the spec for what ends up being like handling the transition cases here um if possible yeah so an error code would also be fine I got I think we can resolve this in a few different ways it's more about just coming to consensus on a solution foreign can we move that to the thread um or is that something people wanted yeah so okay and that lion can jump in there okay and we get yeah we can come back to it on next week call if it's still um being discussed um and there was one more uh CL spec PR uh that I I had missed before but uh shall I point it out uh three one four five uh which updates the max blobs per block to four which I get matches the what's on the El side um any comments or thoughts of that I guess the question with that is like should we target this for uh the deafness three or should we follow up after the definitely it's just a simple constant change right so so why not include it yeah I don't have a preference yeah well that's fine with me people are probably targeting master or whatever on on the EIP right for configuration values yes they are yeah so we should we should align it yep okay and I'll make sure to add it uh to the hike MD just in case it doesn't get merged like today so uh we can at least know that it's there okay anything else on the specs uh themselves um one thing is that um Ramana I think merged uh the pr that makes uh field elements per block configurable so that we can have minimal uh presets uh also on ckcg since that was causing problems for some um testing situations um I'm not sure if it has been used or the clients know it I think I guess the bindings also need to be updated but this is something that is uh client relevant and happened this week yeah we were waiting for this to be merged and uh we are ready or ready for for The Binding to to use it can you link the pr yep I'll find it and link it I see us on the specs okay um the next step devnet three um yeah I'm curious where the client teams at and um yeah how are we feeling about getting this up I know in the last week uh we were talking about potentially getting a single El CL combo um I'm not sure we quite got there um yeah does anyone want to give a quick update from their their client side yeah I can give a queer update so um we're passing 44 horseback tests as of last week so thank you xiaoi and uh all the people that's working on the spare test I'm working on sync that's close to Dom one thing I like to finish before uh finding the deadline threes that I do want to like do some sort of local interrupt test and uh I'm targeting Roberto's Branch for that so thank you for that as well I haven't tried I believe there is time based or slaw based Ford now so that's so that should be compatible as well as what we're doing with the capella as well I guess one thing I do need is that uh last time I checked so the engine API for 4844 is still using V2 so I do need those to be V3 to try and I'm wondering if there's a status for that oh Roberto just said that he just added it so yeah sounds good thank you I will try it today that comment was actually with respect to time-based Forks but V3 uh apis were also added last night uh thank you Mophie for sending a PR for that that's that's now marched okay sounds true so on my end I will try local interrupt today and uh and uh and the and the I will give you guys an update yeah also share your configuration for sales site please um it would be interesting to test with 02 as another reminder okay sounds good I will prepare and interrupt dog for this nice uh so for Lighthouse we're in a similar boat where we're now just trying to test locally against the latest get updates um we can test against Netherland too um and last week I'd say the major outstanding work was in sync but we've made a lot of progress there so now we have an implementation but it's untested um so after we get like lighthouse execution layer interop working we'll probably start trying to make a local Lighthouse Network working and see what sync looks like and then we'll try to hopefully work with prism or lodestar to see if we get sync working there um that's it for us nice this week so I'm now working on the SSG serialization and more people will joining me working on it this week so let's see what the updates will be next week yeah uh just want to remind Europe side who has some tricks there too I mean you will need it for uh transaction hash like that and it's quite tricky uh never mind so we uh try to to synchronize with get to run get at least it looks fine and we need to assure the set line to make a network uh we will try to run search Network next couple of days and hope for we will synchronize soon and we are working on benchmarks for pre-compile to the system foreign team hey this is Andrew from ethereum JS um and I guess I noticed it last week were like I said joining late so we're still behind we I have over the last week I've I've kind of honestly gave up trying to get ethereum test to cooperate with prison I'm not sure why it's not working on the version on um the interrupt but I'm not that experienced with operating with the CL clients so I've been working with lodestar just because I'm more familiar with that one and we have got it up in sync we can sync past the sharding block and using the the current kind of um three you know the the block the um sharding block based um hard Fork switches so we're got that working we're just how I'm working through basically finding all the bugs that I made wrote in my initial implementation of 4844 so um still working through at this point just kind of getting the getting the block the blobs to actually get transmitted to load star so they can evaluate them we haven't I haven't actually successfully transmitted a blob from El to CLIA but um that's currently where I'm at so slow not sometimes the steady progress on that and we are hoping to also Implement Implement um kind of related um the timestamp based hard for management within our client over the next week or two I'm working with good gender who kind of does work with us and also with load star so hopefully we'll have some of those other building blocks in place for when we're ready to join the the devnet so hopefully by the end of the year but I'll just see how much progress we make nice thank you I continue chipping away at the Aragon client still has a bit of a ways to go I didn't have a lot of time last week to spend on it but yeah coming along sweet any other ones I think we've covered most of the ones I had said they're gonna be part of the three okay I guess then uh for the next week does it make sense so it seems like a lot of their clients are just trying to get uh things up and running and and fixing issues on on their own um is there a a client pair that we think might be still uh more ready to start on the devnet so that others can can try to pair with that when uh when their implementations are done uh I mean after we do some local testing it might work so maybe Lighthouse um I think it sounds like probably the same for prism too okay so let's try to get yeah Lighthouse or prism up and running with uh guests uh potentially as a as an El and um yeah if if we can get those two um that'd be a good start sweet um okay then the yeah next thing I wanted to cover real quick is uh last week we we covered the Martin's benchmarks for for Geth um and um basically it seemed like the the pre-compiles were maybe uh a bit underpriced I know there's been some work done in the past week looking at that in more detail and um and uh potentially the benchmarks where I get a little bit pessimistic um so I guess I was curious to hear from people who've like looked a bit more to the benchmarks uh I don't know if yeah Kev is on a call um you know what your dad is thinking is there and then um how we should approach doing this like generally maybe across more clients um or or yeah to make sure that we we get the right pricing for for the pre-compile uh hello yeah so um I was looking into switching out the go kzg for a more native Library uh and it reduced the allocations by around 80 um so it seems like go kg might not be um as optimal uh even after switching it out I was still getting some fluctuations but uh I don't know if Martin's on the call I think this was from the GC uh so if you test it with ckzg for example uh you'll probably get more consistent results and um so I think that was the main problem but on the same order right like in terms of timing like it call it 50 instead of 67 or something but it it's not changing the order of magnitude right uh yeah it's not gonna like immediately do a 2X um but it might be the difference between what Martin was saying with 67k gas and 50k gas right okay um I just ran it on my computer I did an easy recover um I think there's one more optimization to add the EC recover was 42.2 M gas per second and the pre-compile I got it around 17.9 but there's a there's optimization in good rock that needs to be applied um so I think it can get closer but I need to do I need to just re-benchmark it and then the fail case there was an issue there and that actually the fail case should be the same as the succeed case right I think this was because go kzg was basically doing all these allocations and the GC was kept kicking in um right now when I test against I'm only testing against the feral cases uh they're roughly the same there are sometimes when the GC kicks in and then it goes to like 15 uh M gas per second but I I don't know how to sort of solve that if because you can't control when the GC kicks in okay but we're probably more in the even 100 100K is probably very pessimistic and the 60k would be if we end up going with uh not fully optimized G uh go kcg um but in that 50 to 60 range is probably very realistic I think we've got crazy it's kicking more towards at least 60. um I don't know what the allocations are quite a lot that it's doing uh we haven't tested with uh ckzg through go I'm using uh uh sort of bindings instead which is where I'm getting closer to 50.

uh like 50 to 60. um there's some low hanging fruit to optimize go kzg uh yeah I think because all the benchmarking is the pre-compile which is pretty uh simple like it's not any anything to do with the aggregation um so yeah if there's low hanging fruit it's not going to be on the go it's going to be sort of on the BLS side because you're just deserializing points and skaters and then just doing a pairing um so yeah I yeah once this last optimization goes through then I'd like to Benchmark it again and see if it goes to 20. No it should be closer to the 50 that we talked about so then Tim you wanted to consider how we need to play this in relation to other clients and languages as well yeah other clients and languages utilizing going to be utilizing the native ckcg because in that case I think a lot of this can and should translate but if they're not then maybe more Benchmark should be done yeah but uh I guess my question is what happens if there's a discrepancy between the Gaff code and the other clients like uh in terms of the EC recovery comparison I think it's worth at least knowing what it is right if because either you know a the clients get like if there's a large gap in like one client you know that client can probably try and improve their implementation if death is significantly quicker than all the other clients for some weird reason then it might make sense to like use something more conservative in terms of pricing so that's but yeah this is kind of why I yeah knowing that they're all within the same ballpark would be useful um but if they all use basically the same Library I guess yeah if the thing that's unclear to me is like what overhead do other clients have from like the bindings of their specific language and and how how big is that relative to um yeah the the overall execution time right yeah I guess you know I I feel like we we know generally what the cost of a pairing can and should be and you know if overheads or more than 2x that then I think that's like a sign for optimization rather than changing the price but nonetheless it'd be good to know that so that the optimizations can occur regardless yeah and I think nethermind last week uh you were kind of the other team that was sort of ready to look into this is that right Alexi uh yeah um [Music] okay nice and we have a yasik on the call I hope I'm saying your name correctly um who who can probably help look into this so um yes are you in the case I assume you're not in the kcg chat uh on telegram I'm not no okay but yeah maybe I I'll add you to that um if you want to just send me your telegram handle I'll add you to that uh and then um yeah it probably makes sense to just get started on on nevermind and see did the numbers roughly line up to what we we saw I would get sure thank you okay um anything else uh I'm just testing benchmarking um if not uh the last quick thing I just wanted to cover is um when do we want to have these calls in the next few weeks so um uh I think it makes sense for us to have it next week and then you're sort of moving into the holidays um that people want last next week to be like our last call this year do we want to do one more after that um yeah how do people feel about that okay revert those around for both weeks um okay so um we'll do it next week oh sorry I'm just gonna say I'll be around for about two so okay so let's let's do that then um let's do the the 13th and the 20th then we can Pro we can take at least the 27th off um and decide if we want to yeah it might make sense to do the third as well so like if some people are around then uh we can we can do that um yeah next to next two are okay version okay awesome so let's do the next two take the 27th off um and I'll be back on the third uh so if people show up we can have that then um yeah go from there I have one more quick Point um how to handle if people get in consideration how to handle Fork identifier and the time-based works you know essentially an EIP 2124 extension um or modification uh I think naively looking at this if we no longer would do Forks by block number and only time stamp time stamps strictly much larger than our latest block number and thus I think you can kind of like layer an extension on here where you use the un64 fork next as a timestamp instead of a block number but I think we would just need to get one that's my very cursory look at this uh but so if somebody has some other ideas and then two I think we just need to agree it's probably something that we want to certainly by the end of January be agreed upon it's minor but would be annoying if it was being a blocker yeah I agree and generally we're going to need this you know for Shanghai regardless um right yeah I can knock on a couple doors of people that maybe the co-authors of this and see if they have uh quick ideas yeah and I know on the on all Cortez a few weeks ago uh I think the teams are saying like we want to get some prototype implementation that we're kind of happy with and then write like a new EIP to specify it but it'd be good to just follow up on on where that's at then um yeah make sure we do have something in the next month or so anything else okay well thanks everyone uh see you all next week thank you bye everyone bye thanks