EIP-4844 Implementers' Call #6

okay uh so let's get started uh this is what now the sixth uh of these four four calls um just posted the agenda in the chat uh as always a bunch of spec updates um then uh we were supposed to be launching them at three tomorrow so it makes sense to chat about that where things are at there um and then we have two other updates uh or at least one update on the some benchmarks for the pre-compile um and we can also talk about the large block spamcast uh as well um and see how things are going there um and I don't know if xiaoi is on the call uh but uh right before she posted oh yes you're here shall we you want to just give a minute to talk about the new test sectors on the CL I yes so yeah thanks for sharing it uh the so Terence found the issue in the test vectors that we released last week so uh I caught a new release today here yes and I hope that many of you have tested and please let me know and if there's any new issues and please pay me thank you awesome thanks um okay next up uh we had two specs issues uh open uh on the CL side that we didn't have much progress on uh last time and I just wanted to follow up on them the first was uh Terence one of your issues um about adding a blob availability checks for ancestors um what is the status there yeah so hey everyone I have a corresponding PR to the issue so the pr was um approved by Danny but there's more feedback regarding that we do not want to remove that is data availability because it's nice when you're the 10 charting you still have that notion so um so I made a minor update to that and the pr is ready again so yes feel free to take a look and uh further comments it's welcome so yeah okay and that's pr3125 right the io yeah okay nice um and I just linked it in the issue so if anyone was following just the issue and weren't aware um yeah they can go there um great and then uh George you had some updates on uh the crypto side of things so you uh 3093 was merged and now there's another uh PR 3138 you want to give a quick update on those two uh yeah sure so okay for a quick update um basically we settled down on how we want to handle uh empty blobs um empty sidecars basically and now like the the correct behavior is on the spec that's settled so basically now um you know uh client devs can basically pass empty side cars to the crypto library and it will handle it gracefully um so that's done and the future things on the cryptography side is uh another thing raised by client devs about um when we use the pre-compile and we are given a scalar filled elements as bytes uh whether we validate them or not before we were not validating them and we were just kind of using them as they were given to us uh but it seems like the more correct more correct approach is to actually like um validate them and error out if they are not canonical so this new PR 3138 uh basically introduces the validity condition that should have been there from the beginning um yeah that's also isolated on the cryptography side so that that's one nice thing from the uh API we have designed that kind of all these things are nicely uh abstracted away on the cryptography land and it it doesn't give much clutter to the rest of the client Dev workflow um and another thing that's happening I'm not sure uh Kev are you here let me scan the the the yeah I'm here ah right okay you want to give an update on the pre-compiled gas cost or where we are right now because I'm also not sure where we are right now uh yeah and Martin is here as well he ran the benchmarks originally right um we could we could maybe do that after so we already already had a note for that yeah sounds good uh sounds good one question by infy what is it does three one three eight resolve the canonical encoding issue you highlighted a while back that's a question to care yeah yeah it does uh it causes the issue okay so I guess that's it from the cryptography side sweet um any other updates or uh concerns about the spec um and then if if not we can we can we can cover the the benchmarking of the pre-compile but anything else just at the design level or read to the spec uh we had a concern on Lighthouse estate so for the interrupt Depot we have uh like a specific preset that has been generated by the slots per Epoch is set to three so like they were wondering why that is because it's a bit annoying to handle it on Lighthouse because we have to Define another preset which is only valid for the purpose of the interrupt specs testing so I was wondering like if like if it's not that big of an issue we can just like change it to maintenance spec ification why it exists uh yeah there's anyone no why we set the three um are you talking about the the minimal the minimal specs for 4844 I know like this this uh eip48448 report like uh we assume that that's what it's going to be used for the devnet eventually there's a different preset defined which uh has like the slots for Epoch said to three which is like not uh not not mainnet and it's not minimal either so it's it's a bit Hard to Handle handle this specific case only for the test net I was just wondering why it exists basically okay yeah yeah so uh uh Mophie answered you just said it it was easier to debug and I guess it makes sense with uh with the three key boxes just quicker um yeah does that does anyone have an issue does anyone have an issue moving yet to 32 okay it seems it seems like uh we want to move it to maintenance um uh Mophie is not something you can do all right awesome so Mophie will make that change anything else on the spec I see there there is no lion here correct me if I'm wrong and just want to highlight one issue that he opened and is highlighting a couple of edge cases that to me sounds reasonable to discuss yeah uh so that's the three one one three that you just posted yes exactly um so if anyone has some some room to have a look to that and maybe start discussing in there would be nice has anyone already reviewed this uh so we're like looking at it in Lighthouse and like these are the type of edge types of edge cases we're still trying to figure out how to handle so we're aware of it and like we'll comment on it soon but don't really have ideas yet yeah same with prism that we are actually studying this issue it's a tricky one but yeah we will review very soon does it make sense to to like chat about this on the CL call in two days or should we basically come back to it next week on on this call um I think if we have more traction on it it'd be worth it on the Seattle call but I I'm not sure so I'd say no for now and then next week but yeah sounds good um yeah so if people want to have a look at that and and share some thoughts on it uh yeah we'll keep an eye on it any other issues or speculated concerns okay um I guess then the next one that's kind of uh also part of the spec uh Martin you ran sort of an initial set of benchmarks uh for the pre-compile on the get branch do you want to take a minute to kind of walk through what you did and yes sure so what I did is basically a rerun of what's been done a few times before when we added new pre-compiled um Blake and the BN ad and the beer mode on those a long time ago that was that was at the time when the implementations were I guess and CPP ethereum and parity so kind of the scripts that I used to take the raw data and transform it into the columns uh there are three formats for that one forgetful the other one for CPP ethereum and one property so right now I only have data for GIF which I ran and two different machines and both of those kind of indicate that the proposed gas cost it's not it's not far off but probably it would be good to bump it by a factor of 1.5 or maybe two uh and that's something I mean it doesn't need to be set in stone now because it's very simple constant change and that's also pretty nice with this pre-compiled that there is only one flat cost it's always I mean it's more difficult last time we priced something it was um where you have a formula where the pricing depends on the complexity and or the length of the input and of course that makes it another dimensional difficult and yeah so now we've got some some preliminary results and it would be nice to have the same kind of executions done on the other El clients never mind and bisu I suppose that they're gone it's mostly on par with guest [Music] um yeah and at least we have a sense of whether they're on on the same level as death or someone something is dangerous system and the methodology used is uh to compare the new pre-compiled M Gus per second wise with the other pre-compiles and the reference one we've used has been easy to recover um and yeah that's about it I guess uh I don't have much more else to say I don't care if you had some thoughts on Discord do you wanna could you give an update um yeah I guess it wasn't uh entirely intuitive that the failure cases were taking good like longer or more expensive than the correct cases uh I've managed to reproduce it on my computer so I'm just investigating why that's the issue yeah and I I kind of assume that that's something that can be fixed uh I don't know but but that's my instinct at least yeah um and then I guess for the other El teams um how easy is it for you all to reproduce this um is this I assume people might not have had a chance to look at I think I think I mean I know that now that my um both now the minorities have done guns marks and pre-composed before that we've done some comparisons on okay okay so I I can reach out uh because I don't think there's anyone from base you on the call um and then I think Alexa maybe from oh Jerry sorry yeah yeah uh we're just starting to actually determine things so very almost nothing's done yet right okay so there's not much to Benchmark fair enough um and then on the uh nevermind side Alexa I see you here uh how uh do you have like the bandwidth or how easy is it for you to Benchmark uh the 4844 pre-compile relative to uh other pre-compile in terms of the pricing and then uh there's a script the the last comment I had in the chat is uh Martin's results for doing this um and we have quite a basic uh tests for the pre-compile on dotnet side and we did not run any benchmarks actually from inter repo or of from any other place yet okay got it um and do you think the creek about itself would be in a spot where like is the implementation far enough that it makes sense for you to Benchmark it or are you still working through it than even if you benchmarked it now it won't be a good uh a good Benchmark because there's still stuff to optimize benchmarks are always good and we can compare probably implementations uh it's official right okay um because we do have uh we do have people who like might be not inclined teams who might be able to help with this stuff so um I'll reach out after they call it and check with them if uh if they could help with at least another mine one in parallel so if uh this way if if you're all still work on the implementations you can get get the advantage marks in parallel um okay so I'll follow up on that um and then Bruno has a comment about the pricing um being more of an issue for ZK Roll-Ups and optimistic Roll-Ups um I don't think there's anyone here working on ZK Roll-Ups correct no okay um I can follow up offline as well and and uh opinion uh some some ZK teams and um yeah get them to share any thoughts they have on their repricing foreign anything else on the pre-compiles okay um then next is uh the devnet uh so devnet 3 was supposed to uh be launched tomorrow um from skimming the chat it doesn't quite seem like we're ready um so maybe it'd be good to just get an update from the different client teams about uh where they're at generally and and um yeah what the next steps are for them um yeah yeah I think oh sorry go ahead I was gonna say Tim I think I agree that uh we're not nearly ready for Wednesday things are coming along quite well though so I'll delegate the individual teams yeah uh I can give a quick update on the prison side so uh thanks shall we again for fixing the spat test so right now we have been testing the spare test as of this morning we fund um two to three test failures and that simicide those taste test failures are on our end so yes I think we just want to fix those as soon as possible and then after those we should be ready to begin interrupt but no guarantee no guarantee that uh what's right out of the gate I kind of imagine some like trial and error but yeah that's where we are today call it um any other teams from prison uh so for the White House we still have things to iron out with sync um I think otherwise we're there with an implementation so we've been working a lot more towards trying to join the interoper repo and making solid progress but um now we sort of need an execution client to test with um and then also like Juan mentioned earlier if we can make the spec use 12 or sorry like the mainnet slots for Epoch 32. um that'd be helpful um and I I think part of the reason it was set low was for the tests in that repo to run faster and I'd like to have us run the tests so I was wondering is it possible that we can just like start the test net from a later Epoch so we don't have to like wait a ton of epochs to run the tests uh wait let me use the minimal preset oh sorry what was the question so if I understand the suggestion is to use the mainnet32 why don't we correct so if I understand the interrupt is a bit odd because it has three that we could make that eight which would be the minimal uh all clients should support right so why don't we use and and I assume the minimal preset is used on like existing test Nets or something well so the the issue with the minimal spec is right now it has an incorrect Fields per BLS elements I think and like that value um is hard-coded in the ckcg library so um yeah I don't think the kcg library works with the minimal spec at present but if we update that in the spec at that point I think we could change the tests in the interoperito to use minimal Sean did you say update the the hard-coded value in the spec um so I think the field is like it's in the minimal preset the Fields per BLS element it's lower in minimal versus and that value is hard-coded to the mainnet value in the ckcg library so like sales Square blog right field element for blow yeah yeah I think so it's like 4096 yeah yeah this is something uh just to say that I want to talk to Ramana today so that we make it compile time configurable he was amenable to it last time we talked so I think uh we can now move on with that okay so if that's the case then like whenever that's configurable we can transition to interop repo tests to use the minimal aspect so that'd be reasonable so I I don't know much about these um presets but why not just change the minimal one to use the 4096 value so we do have that right or no we were we didn't want to change that right sorry shall we I hello so so the minimals uh preset and config are for the specters to provide the minimal test vectors with us less low cost for the clintons to run in the CI daily or weekly so we also provide the many perspectives at the same time so but for the spec side since we are using a pi CC the python implementation and our uh our kcg information are actually from the speak lines so I that is incredibly slow and compared to the C uh implementations so forth stake itself um I think many more config minimum preset with uh like build elements for block with like four or eight is needed for the space side but for the definite you can free to generate to use any numbers uh in the configurations or in the preset if I understand correctly okay so we don't want to change the minimal preset because it'll be two burdensome on on certain testing but sounds like there's not another existing preset yeah I think you can Define your the definite only preset if I understood correctly that we might have used it in the previous uh short-term definite before and Sean is that an issue just to find a devnet specific preset with 4096. uh so we we actually sort of have that right now because we were trying to get the Test passing so that's not too big an issue um yeah I guess if we update the slots per Epoch at least to match like the minimal spec so if we just update that to eight and keep the BLS field elements high until it's configurable that seems pretty reasonable so the dev map has the minimal configuration do I understand that correctly so what's there now is that already is sort of custom configuration where it's mainnet apart from slots per epoch 3. but mainnet is 4096 right so you wouldn't have a problem with ckcg about right but the question would be if we just wanted to switch to a preset that exists it would be minimal and that one wouldn't work yeah and why would it be minimal maybe you already said that but I didn't catch it it's to have the slots for Epoch be lower so that the tests run reasonably quickly because we have to Fork through multiple ebooks okay got it volume so yeah if I understand are you are you able to run with the interrupt now with the current slots per Epoch of three no we got like we're able to run up until the withdrawals fork and then at that point we don't really have anything to test against so then it breaks but we have like like pre like up to Bellatrix working and the issue is this three slots per Epic no we we have that working it would be preferable not to have that though because we had to like have a like one of the assumptions we make is for example like his slots for historical route being divisible by slots for Epoch which that doesn't work when slots for Epoch is three so we have an AI to change that to 32 so let's let's assume that's going to happen what what else do we do certainly I mean if if it's changed to 32 then we can just use the mainnet spec in that script cool and and Mophie you you did most of the interop config stuff as I understand it is other than the tests maybe running slower is there a another concern with that we may have lost Mophie Mophie says it should be fine in the chat that complains we can add more machines okay so tentatively let's set it to 32.

um I'll try to make that change today awesome thank you Roberto yeah that's it from my house we're sort of just like trudging through interop and then trying to finish up sync awesome um [Music] development we we want to to have someone with timestamp based works for Shanghai and for withdrawals and for the AP 4844 to test with so we are a bit blocked method um just to like form the structure of Docker campus with our uh notes we made a pull request but we still don't know what uh Genesis uh will be relevant for deadness 3 with timestamp based works and we'll continue our testing with available tests um we hope uh to join the network right after or a few days after some other execution client and consensus clients like prism and get and will provide us will provide the community with time-based timestamp base Force that's the status all right I'm not sure we have anyone working on switching to time-based Forks right now at least in a um guest slash prism um or or Terence are you guys doing time-based presets in prism fanbase books yeah so from the sales perspective it doesn't really matter it's the changes will mostly come from the El side so what we have been doing is that we have been testing local interrupt and there's a and there's a local interrupt with withdraw and that's also withdraw test net and then they and then I believe that is based on the timestamp 14 mechanism and then we have been using the like high-end Branch so uh so my client Matt has the branch for that so let me post a branch here so maybe we can you guys can look at how that branch is done and because because that is the branch we're using for um testing withdrawal based on timestamp uh so Does it include uh APF rate of foreign with rules both um no it doesn't include 4844 so someone has to basically um build on top of that okay let's see uh it's just a special case uh another mind special case we did not uh plan to have a block number based works for these two cases of some kind of charging for so we will just until we'll get some um other teams implementations with thanks them based folks um if I understand Right Time same base Forks are the preferred going forward Fork mechanism so it makes sense to to switch to that if it's not too much trouble yeah we're gonna have to do that anyways um yeah because withdrawals have to be time stamped and because uh the the the um the 4844 Fork even if it went live you know effectively at the same time it still activates after and after the merge so I think it there's no world where like we do withdrawals with timestamps and then we come back to blocks for 4.4 yeah um okay so let's cue that up as an action item to get uh yeah statement-based forks and Geth within the interop um or if we have a volunteer for that if not I'll I'll try and get to it I have a I have a commit somewhere um that is it's just like one one commit that you need to pull in it's it should be really easy I'll fantastic nice because I'm capable of starting with a merge Network as of now yeah hey lion so we just merged it we just merged the feature like last week so yes as of today we are capable cool can we update the interrupt repo for the IP potato for to start at capella organization at the same time yeah we can't do that awesome thank you guys okay so and so yeah we want the interrupt repo to start post merge basically foreign yes okay okay and so I guess I I can add those two changes to the the net three specs so to clarify we're using timestamps for fork and then um would we want devnet3 to also start at capella basically I'm not a boast foreign go ahead Sean I was going to say I'm also not opposed to anyway are there any drawbacks to doing that other than just perhaps not exercising more of the forklogic but I guess it doesn't matter really if we're gonna go out post withdrawals anyway right we could start at the electrics as well right like you could start at the merge go through the capella fork and then does anyone have a preference either side I think capella if we're going to do not um like a phase zero start a capella start would be better just we don't have to deal with the like terminal total difficulty logic and whatnot okay I mean we could we could also do Bellatrix Epoch zero TTT zero and then foreign foreign yeah I don't know maybe this requires a bit more thought okay but so for sure we want to do timestamps because that's what we're doing everywhere else anyways um and then whether we start at Bellatrix or capella TBD um but clearly not starting from k0 does that make sense yep yeah okay um okay I'll add those two notes to the devnet three specs um after the call um okay uh anything else under divnet we sort of went through some client updates and technical issues but um any other client want to share updates or any other issue um uh yeah this is Andrew from ethereum JS I'll just just like I think I noted in the last call I was Ableton that we were you know we're going to be very very late to devnet 3 if at all at this point um I I have a mostly working local Fork of the interop replay now so I can at least get our client up and running I think I've been able to get it partially working with Lloyd stores having a lot of trouble getting it to interact with prism correctly for some reason so I'm going to start working on that again today um but I I do have I think most of the spec implemented at this point on the El side so have the the new engine apis and we have a we're using this the ckzg library and it at least Works in local testing not that's my goal for this week is to try and get interop to actually kind of cross the sharding block um that that's where things are breaking with lodestar right now and um so I've been looking at that and we'll be trying again with prism just to see if I can get it to go past capella to um The Shard block on the heel side so hopefully at some point maybe in the next week or two we'll be able to actually start really um running the tests in the interop repo and then possibly join devnet3 at some point before Christmas foreign next week is probably may even be optimistic but I think we should try and shoot for end of next week as a new deadline sorry relate the question so Buddhism and Geth are able to run the fully IP of 4844 logic today um we at both fee and coinbase were mostly online I believe they have like they so we they have that there too but that's not the latest specs so I wouldn't say we're fully functional as of today based on devnet 3 there's still more work oh um I got I have the prism repo in in the interop um it should be abiding mostly by the new spec um I think we still are waiting for Kev to submit the zero blobs tweak um but uh that's under review I imagine that's gonna happen you know probably within a few days so my point is during early days essentially start the death Nets really quickly and really fast on whatever was the latest spec and the definite was only taku and running with four nodes but it was incredibly productive to have that test net as a Target to testing tested project quickly when you are developing so if that is available it would be extremely helpful if you guys can quickly spin as long as that's somewhat working um a tiny desk net that we developers can use that will be very appreciated and that could be done in parallel to the webinar three um if please is ready before and I guess the prism thing the biggest uh concern is that it does not uh we're based on capella foreign so what's a What's the quickest elcl combo we think we can get um basically rebased on capella using timestamp Forks um and uh kind of running so uh other teams can can try to interrupt with yeah so it sounds like the issue right now is a ACL client that is rebased on Candela yeah um we have this and like we might be able to get it working um if we have like a local test net where we won't miss blocks because for us The Big Meet uh Missing Piece is sync it's like we have sync partially implemented but it could get messy if we're missing blocks so if you have a test Network or a devnet where Lighthouse you know there's only Lighthouse validators perhaps it starts then yeah like maybe like a couple Lighthouse nodes with just Lighthouse validators might work local to each other yeah could we use ketosis on this one because all it does is as long as it it is just a beaker node a validator and an El then you can set up a local test Network that quite easily we just need Docker images uh yeah I mean I could build a document that's what we've got um yeah I think that work cool I can give you the amplifier to learn that then cool so we've understand you cannot sync or you don't know do not expose for others to sync um we I think we'll Panic if we get a blocks by range request right now for signed blocks and blobs um and then we'll sync because like we're able like we have gossip implemented so like we'll just import blocks as we see them but it's if we miss a block and have to request a block I don't think that'll work for us um so yeah got it and blocks by root I expect really yeah I don't think let me think no because we're trying to figure out how to handle the edge cases you pointed out where like what are your requests pre and post um Fork as well as um before and after the prune boundary so I don't yeah it blocks my root I don't think we serve either okay so I guess let's it seems like either Lighthouse or prism or probably the two first that are going to be ready on the CL side let's try and get that and get running um and on the dev on the interrupt repo hopefully you know it doesn't lead to Lighthouse the same blocks and having to sync um and then Roberto you were saying uh before end of next week would be like an aggressive but nice Target for the devnet um yeah uh that people think basically say before all core devs uh next week is is realistic that's about 10 days nine days yeah it's really up to the CL devs I think at this point um I think Geth is going to be ready um you know I think I'll be able to implement uh the AIS that that have come up around making the Epic changes in the time-based fork um but the the CL stuff's a little outside my control I don't have a good handle on that got it so Lobster should be ready logic wise and it's released but we have never attempted to run like the whole the whole thing so Kathy is ready today uh gets will be ready soon I think yeah a few more things to be done on the execution API I'm working on that right now um other than that I think it's in in the zero blob stuff for example things to be integrated all that's ready though just need to pull it all together got it so on on your Rebel on invisible now the CI passes for prism and Geth so if that is the case what is the difference between those tests and actually what we want to do in the net I think once um we've done the execution API work for withdrawals those tests May no longer pass I'm not sure um Mophie might be able to better comment on that so I think that's where we start getting interoperability issues with between the the interop repo prism and where the gath is right now foreign so yes it's passing Now with an older version of Our Guest repo um that is not doing the entire expectations of the capella rebase that will break very soon and we'll need that updated seal at that point okay so let's try I mean yeah let's try that then anyways we'll have the call next week uh a couple days before it's a review where we're at um I agree before uh awkwardness would be amazing um even if it's not all the times you know even if we get like three or four out of six running uh the other ones can come after and then having the whole set uh before the holidays would be great so um we at least know this is uh this is working on the devnet yeah I think it's possible um I'll I'll push it along best I can yeah sounds good anything else on devnet3 okay uh last big thing that I wanted to actually recover is uh this big blog test uh I know uh Georgia's here still on the call I think yeah yes uh yeah you want to give us an update there yeah quick context so last week's progress was that we'll run it on with 128 kilobyte transactions and it looked like nothing happened um now we wanted to do it with 520 256 1024. um I'm connected the flashboots Builder but right now there is a our cryptic RPC bug that I'm waiting to get support on so that's the Blogger but the code is written and once I'm unblocked on the um on the flashbots uh MAV boost girly Builder um it should be good might even be today so I'll let people know async in the chats awesome and Perry I think you were saying that you've added uh um you've added support or are gonna add support uh for Mev boost on a lot of the EF devops validators yep uh I've already done that so now something like 30-ish percent of Kali should be running mapus and we are getting a couple of consequent proposed blocks that are all coming from map boost nice uh very cool um any questions maybe let's coordinate after this call along like maybe giving me like the RPC for the EF Builder um and the address so that um we don't have a builder we're just relying on the flashbots one ah okay yeah but but the relay is plugged on the Builder so we have more hash rate for inclusion of multiple blocks in a row thank you sweet anything else on that okay [Music] um and then the last thing uh Henry I think just had to leave uh but he started working on a nimbus prototype uh so we should start seeing more on the Nimbus side in the next uh couple weeks um there's already a initial PR open [Music] um yeah anything else anyone wanted to cover okay so it's the first time we've ended these uh not over time um so I guess that's a good sign uh yeah thanks everyone for joining and talk to you all on the CL call in a few days thanks guys thanks everyone bye thanks bye