EIP-4844 Implementers Call #11

Transcript

foreign welcome everyone 11th 4844 call um I guess two main things uh today actually three main things uh I think we should chat about so first is the spec uh and specifically uh with the interrupt uh Workshop coming up um trying to think about what are all the things we want to resolve before we freeze the spec it would be good if uh um in the next week or so uh like by next call we could have this back in a spot where like it's it's pretty Frozen and um teams have uh something clear to work off so we get to interrupt and everyone sort of on the same page

um then uh second thing I can talk about uh Dev 3 and and if there's any updates in terms of client implementation and and Bug fixes there and then lastly uh testing so we had a bunch of uh work in progress PRS uh last week um and yeah just get uh some updates on that front um there's anything else people want to chat about please uh either post a chat here add it to the agenda um but yeah I guess to get started just on the spec side um like I just said so we have interrupt uh in about uh two weeks um if we had a proper week before where the spec is Frozen that would be ideal um I think we're in a spot where like most things are done but there's still a couple uh open issues

um so I'll go over first the things we we still don't have quite closed um Roberto your issue actually got closed but because the IP editor wanted to move the discussion to eat magicians um so I just wanted to check in with you about the status there and and no it's closed um I got the pr submitted yesterday so it's all updated we're gonna use serialize SSC for both hashes and it's in the spec awesome okay anything else on that for anyone okay uh another one I think somebody might have literally just clipped oh an hour ago okay so uh this other one we had open uh 31.70 uh also just got

closed an hour ago and uh yeah it seems like everything is fixed there anything else on that one you're talking about this data available that's in the the release as well so okay oh sorry I just messed up something doing your copy and paste okay and then we had uh xiaowie uh you just open something about oh yeah

okay the thing you just posted about in the chat uh did you want to quickly cover that uh yes so today we have a PR to fix the yeti 444 uh folk Dot and D file and this is something that we miss to uh copy past the previous uh historical summaries from capella when we are transitioned to yeah so uh let's uh issues in the stock transition test currently in the release I will coach last Friday so we will

have a either affix or regular release this week to fix it so just if if client things didn't pass it it's because of it's probably because of this issue could you point to which exactly the tests should not pass because we also found that some doesn't pass uh yeah sure um okay thanks anything else on that okay then I think the last one uh the

last actual open issue uh was uh the sidecar uh without blobs for range requests which um isn't really like a consensus a critical change but um I saw there was some conversation on this last week um not sure we quite got to a solution any updates there I think I mean I was the main one pushing back on a slightly different behavior um it seems like Mophie agreed generally all the comments that the symmetries asymmetry is bound regardless if we make

this symmetric um but I think that he and I are generally agreed uh and Tara Anthony is the other one with a strong opinion here I'm not sure um I don't have a strong opinion I I tend to agree with any of this and uh unfortunately this is just a behavior definitely right now since it wasn't clarified so I think it will be good to clarify it and I do think clients needs more work on your side great dignity in general just because like I don't think rate limiting is part of this batch so everyone kind of does it differently and right now we're treating uh zero blob they are actually like a full blob the client gets penalized by requesting a

lot of those so yeah we need more clarification on that as well gotcha do you want to revise this PR to uh the alternative behavior and also put a note about uh clients should not consider empty sidecars as part of their rate limit strategy or something yeah yeah I can do that sorry I forgot this is my PR so yeah I would do it oh goodness

um okay cool and then um we can review this and uh honestly like we can probably merge this tomorrow and get it out with the fixed release that we need to get out on the the fourth time MD stuff awesome sounds good to me nice so I think those were the only open 444 issues uh at least I was aware of is there anything else that people are sort of tracking or have opened um that would uh yeah that basically uh would would stop us from freezing the spec it's not

um then yeah I think if we can get this uh this merged in uh like this last one version the fix on the test and then we'll have a solid spec to work off for interrupt and the next devnet yeah that's pretty good yeah yeah lots of these calls and async stuff they get they get here but yeah no we're in a good spot for this spec uh definite three uh do any client teams want to share updates on on where

they're at and um if they've made any kind of significant progress in the in the last week I think for a prism side we kind of move forward with that and forward already so we have been passing the latest bad test well there's also a bug which will fix the bug as well just like shall we mentioned so I think last call we clarify the scope of the mf4 which is we'll rebase everything on top of capella and that has been reflected on the sweat test so yeah I think we are very excited and ready to get that defined for started I don't think there's much value in maintaining definitely just because that's not gonna for the interrupt week that's not what

we're talking for so I think my regimentation is due to death there for as soon as possible and I do like to see like more clients like bootstrap that for just for that factory it's unfortunately personal timing during holidays and it was all in prison submitting blogs and then I think one of the feedback would definitely three is that you have more multiple clients are different blogs and the blog so yeah that's feedback from RN okay um we can definitely do that so basically uh Danny and I are working on the the milestones for for interrupt and I think we can make devnet 4 a part of that which would just be basically using this

upcoming spec release um that we'll have in a couple days um and trying to get all the clients on that acting as both block producers and and uh just just regular nodes does that make sense to everyone just to clarify for the net for we'll be having SSD routes for the transactions right that's a great one I no sure so do you know going on the EO side that will be patched because it's I think from for I

get for Roboto it's pretty easy you just cherry pick it right but like I guess like how do we align the timeline does it take a week like a few weeks for that on ethereum dear side we are we are ready with SSD roots of the transactions I mean it should be easy patch right yeah in that case it sounds great to me too yeah uh Polo with the SSC route for transactions do you also mean to change the roots of the receipts and the withdrawals no no this is only for uh EIP for four

transactions so basically signing the transaction so basically getting the transaction hash Oh you mean the transaction and yeah that's different sorry for the confusion right so it has nothing to do with the other routes conversation yeah and what do the the root standardization might have an impact on is going to have an impact on poor because of that functionality but that we'll cross that road when we get there and what do the El prototypes do right now

get has been updated to use um serialize instead of ash tree root per the the spec updates that I checked in yesterday um yeah another mine can do the same but we would wait for at least some scope definition for if cash update will be included it is not a problem for us I mean hopefully it's like a two-line change for for most implementations it's pretty simple yeah ethereum.js is already updated to use serial the SSC serialized too we did that a couple days ago so

I mean it's it was a one-line change for us does any client have an issue if we go that route like can we just make the decision to use that for definite four just to confirm I understand what we're saying is this the Roberto PR number 6245 that we're talking about or something else not sure I remember the pr number but uh what What's the title of it uh fixed blob transaction hash to use SSD serialized yeah yeah wait oh yeah the one that said

clarifying rationalized Rob transaction hash computations we have it was the one we just talked about earlier yeah that was the issue that was the issue name that got closed and there's a couple PR's in there that are now submitted great great okay so let's go forward with that for Dev bit four um especially because it's already uh I believe merged in the EIP so yeah yeah so then for devnet4 we'll basically use the EIP of like masters of the the latest commit and then um the upcoming uh the upcoming uh spec

release on the CL side which ha uh which will have the two uh pending PRS that we we just discussed earlier yep sweet um anyone want to give updates on the implementation so we sort of skipped ahead to Dev that far I agreed we're going to move to that um and and um have that be the two layers flex but um just generally in terms of implementation any client teams have updates they want to share I can check your Lighthouse so we were able to sync devnet3 um and now we're working on doing the capella rebase um and trying to pass the spec tests

um yeah and devnet for we're hoping that we'll be able to produce blocks and also we'd like to be online during the transition so similar to things of internship um other than that we're working on like improving how we handle blobs in our database and um how we handle the trusted setup so it's a more internal improvements as well as like getting up to speed with um I've met before but yeah I think we're in good shape uh followed star we are already we already we based on kapila and we are ready for devnet4 and we pass all the

spec tests except the one that I escalated but apart from everything from that we are good great update for from taku here uh we are already on acapella um and what we are working currently is mostly block production and seeing process that is just started um so yeah uh needs still some time to actually join a devnet test but yeah this is progressing

I've been continuing to work on Aragon I think it's mostly there I haven't run any interop tests yet but the bulk of the implementation is complete I just um uh finished up a couple PRS still need to get reviewed and submitted for the uh external transaction pool but I'm hoping by the time the um Workshop comes around I'll have it interrupt nice Nimbus uh maybe a quick update on Nimbus so Nimbus has um made a lot of progress through the holidays uh where actually let me paste there's a tracking issue for anyone who cares um basically we're at the point where we have blob storage uh peer-to-peer the rpcs implemented I'm working right now

on uh finishing off sync most of that is done and then there's the engine API that's implemented but not wired in so um I'm hoping that that's all going to be complete this week and then that would leave us or leave me next week to uh to figure out how to get onto devnet 3 and and make sure that this is in a working shape before in a row um for ethereum JS we were able to sync devnet 3 over the holidays um paired with lodestar I'm I haven't gone back to trying to pair ethereum Jazz with either prism or White House I may try and pick that up kind of

prepping for the workshop but um a couple weeks but we are able to able to sync devnet 3 with lodestar and um we I haven't I haven't integrated us into the interoc repo just because it's I'm not super skilled with Docker and all that jazz but I've written comparable tests to all of the interop tests and within our own test suite and we we can pass all those spec tests locally um I'm basically just adapted them into our typescript testing framework just to run them on a kind of local pair so um I think I would say that we're equivalent you know kind of devnet 3 complete as it were in terms of minor op nice

well another mind is what seems to be completely different three implementation we tested with get and the roster and the reason and testing with that helps going quite okay we need a little effort to align with before [Music] described and we will choose this week and well this great thanks for the update um I think Basu and Geth might be the

two only ones left oh I mean I've been continuing to maintain guests um yeah I'm I think uh I mean Terrence reported an issue yesterday that I need to look into I'm not not sure there's anything else that needs to be done there um I've been focusing mostly on airing on lately got it I think it's in good shape question again do we have like a single like an individual in the Gap team

that's going to take this over the line my understanding is it's Peter but I haven't heard from him yet yeah I think I think a lot of the get folks are uh quite in the weeds with the withdrawals testing right now um I know Marius and and Peter had both spent some time on this in the past um so yeah I think I think interrupt probably makes sense um I doubt in the next week I mean if it had like if if they end up being more available than sure um but my feeling is like

yeah they'll probably be focused on that for the next week or so yeah yeah I think I have the same struggle with the uh Aragon team I'm um Julio has been um um I've been asking him some questions but but otherwise I could use more involvement from someone from the Aragon team if anyone's on the call awesome yeah uh Proto um I was another impression that Peter was working on 44 transaction pool um I'm not sure if the Prototype is still using like the old transaction pool or if that's worked from Peters integrated but it might be worth looking into oh no I wasn't aware that I'll have to take a

look at it we're still using the old transaction tool should be fine for now but that's something we want to sort out during interrupt and does he have a PR in progress for this is that something I could look at um I'm not aware of any PR but we should ask okay thanks uh Justin 's in a similar State as Geth we're hoping to accelerate that this week though and um potentially participate in devnet four um I think at the moment I will be pulling a contact for that oh I did have one question for devonet4

that I know is not implemented in Geth right now and that's the don't announce blob transactions um I do have a PR which I've been holding off on because it wasn't supposed to be part of devnet 3. I assume that will do that for devnet 4. um should I get that submitted this is a text pool issue that's a Proto reminding me of this where for blob transactions we're we're not supposed to uh broadcast them only announce I'm not sure if any other client devs have have implemented that yet it's a Neo thing um we have an ethereum JS and I've run

tests local I mean where we uh here again I haven't tested it with Geth per se but I have tested it between multiple you know 300.s clients and validate that we only we don't broadcast the transactions just the hashes I mean so that is implemented for ethereum Js cool so I I would propose we try to do that for devnet for um I'll get it and get it's not in yet it's just it's an unsubmitted VR but I can get it in yeah I would plus one trying or doing that for definite four it feels like a new Behavior that's worth us like running through ions

later yeah yeah it's pretty straightforward it should be pretty straightforward for most implementations as well yeah I think and I think it makes sense to think of devnet4 as you know potentially the last or like you know a Dev net on which we have like finalish implementations um that we could then either if we want to launch a new public test net like we did with kinsugi or you know eventually move to test Nets like um there might be an extra one there but I I think we should bring in all the functionality we expect to have on Main net so that yeah if if it turns out to be like a long-standing thing uh before public test notes then it's it's working as expected yeah items just on client implementations

um next up I want to chat about testing oh sorry please Jesse oh I I just wanna make sure my understanding here it looks like other than maybe Basu all teams are currently on track to participate in devnet for like fully basically with a full implementation does that sound right to folks I'm just looking at my notes I want to make sure I understand that's what I got as well and marginal obviously Aragon and Geth like Roberto's kind of uh yeah working on those but um do you mean yeah El clients or old clients all clients

yeah um not 100 sure on our side depends by how it plays out this how we progress and think implementation this week so yeah maybe by the end of the week this week we could have a better yeah better ideas and I think yeah our our goal with like interop is by the end of that week um so basically you know January what is it 27th give or take um having all the client teams on a devnet um would be kind of the the minimum I I would be happy if we get everyone running there that's great and then I

think The Next Step Beyond that is like we can actually run some stress tests on that that net spam it um and you know everybody makes it through the rough environment on the devnet that would be that'd be ideal um so I don't yeah I think it's we're attracted pretty well for for that yeah yeah it's okay for them for them yeah it seems like that that we should uh have the ability to join at the moment is just a matter of uh we have a clear path for for arriving there just confirmation that arise this week and next week is that like a similar situation for for you all

uh sure I'm not I'm not feeling super confident about right right now at the moment and I'll have a much more detailed and um confidence inspiring update in a week but uh tagging us is the one person not ready to participate in devnet 4 is fair sounds good um and yeah next week we'll have kind of our last call before uh before interrupt so um we'll get like a an updated status also I I'm sorry for being the hype man repeatedly but that's awesome you guys are you know doing your best

and I'm confident that we'll get you there but that all almost all the clients are like fully ready to go for interrupt like has this ever happened before you go for a release that's went out I don't know I'm super fired up about it no yeah we're in a pretty good spot it's never happened for sure on the next Fork right like it's still worth remembering like there is still withdrawals that has to happen before all of this so being like sort of ready for the next thing I think this is this is probably a first yeah before we jump into testing so we

mentioned the interop repo a couple times um and Roberto you said in the chat like it's uh it's it's a bit behind and um people should kind of hold off for now so I guess I'm curious to understand there because I know we have some some good testing uh testing there what what should be the plan with that should we still kind of try to get every client team to to open a PR against that does it provide like a good testing suite for that um does it make more sense to potentially like move to something else like like whether that's Hive or or uh or spec tests yeah so I'm not a testing expert all I know and I hadn't been playing with the

interrupt Reaper lately because if it had my heads down on me in the Aragon system um but I tried to use it yesterday and and couldn't get anywhere and I have another person looking into it as well and he's kind of stuck as well so it seems to have suffered a little bit of rot I guess um so I I don't have a plan yet I don't know if someone else does but all I know is it doesn't seem to be in very good shape so but I think I think it's a good idea that we do have that repo and then I think the tests in it are good they're solid they're pretty basic but you know if we can't pass those tests then we have bigger problems um there might be more than we can do but we should at least get that back

into shape I think and I intend to spend a little bit of time on that this week got it and I wonder is it maybe worth looking at the test Suites there and like exporting them to some other tool like Hive or or does it make sense yeah we'll defer to a testing expert on that I I I've never used Hive so yeah I don't know if there's anyone on the call who's used both the interoperate bow and hive uh I think I can comment but like Murphy is out uh this week I think so he would be like the best person to ask um regarding Hive Hive currently is in a spot where just about has

um support for capella I'm working on the changes in the libraries it also supports the latest for it for first pack nice um combined you could run a test notes in Hive just like you do for capella and previous Forks and then it's a matter of translating these IDs from the intro prepa to Hive to say spam some transactions or to do these type of things and given that a lot of it is already written in go that may be easy to put offer now there it's more difficult is that for this type of early stage testing I would recommend

like testing approaches that are less containerized element things that are like easily connected to a debugger or something like that whereas Hive is not really built around that so it still recommends like polishing like a simple minimal repository where you can run something just a few clients locally to to test the changes and then around the interrupt I hope you have like a live test now to test against instant got it okay so let's get uh offline with with Mophie once uh once he's back around and and see what he thinks about that as well um but I think okay it makes sense to try and

maintain uh the interruptly build perhaps a bit longer um yeah and maybe figure out how we bring it into a good spot for for um so that we have that and then the devnet that people can then join does that make sense exactly yeah and so I guess yeah and you you sort of started covering Hive I know we discussed this last time as well but beyond what you just said anything else you wanted to share in terms of updates there's still some PR about metrics which needs review it's more of a nice to have for not really looking forward for for work um the main blocker for 444 or like the

changes to bootstrap into like a foreign now technically if we change the configuration we could just start at the previous work and then have a longer running test that transitions into the 44 mods I'm not sure if others tried starting test stats starting with a Ford for big instance or after I done something like this where you skip through the transition we have dot tried that but I think my recommendation is whatever withdraw capella is doing we should follow suit

because that's working already and I do think they have to try from Kerry they have triple strapping Genesis broad balance tricks so I think we can at least do that or we can we can also try bootstrapping from 4a4 Pro I don't think that's that big of a difference but it would be nice to test the upgrade path and that is Capella to 4844 I agree it's I'm mostly thinking about the the beacon State part with 44 so we have like a faster feedback cycle sometimes you just want to restart that's not really really frequently and then doing the transition or other gun might take some time

but otherwise yes we should go for the transition foremost yeah we can definitely support bootstrapping for foreign we can reduce the test Cycles yeah so Mario has some open PR also against Hive and I don't think he's on the call anything else uh people want to bring up with regards to testing

and then uh I know we discussed the pre-compile benchmarking last time it seemed like we were sort of converging on uh 55 or 60k gas price for that uh does anyone have any updates uh from from Berlin okay so and I guess we can keep things as is I would not change the gas price for devnet 4. um but what we can do is like once we do have devnet4 we'll like it will have implant implementations across all the clients we can do kind of one more round of benchmarking and um make sure we're we're uh we're still like roughly the right spot and potentially changed it the gas price

um so I don't think we should block anything after that net for on that and then uh with regards to the big block testing um Giorgio said in the chats this morning that he'll get back on it uh this week um I don't know that there's any one else on the call who would want to give a quick update on that okay and then I guess maybe the last thing before we wrap up uh Carl I know the kcg ceremony is supposed to go live Friday any updates you want to share here about that

uh yeah sure uh kcg ceremony should be going live on Friday uh that's all uh very exciting um I encourage everyone here to to please participate um it's also very easy to write your own implementation so if you'd like to do that you also like please go ahead and if you feel like testing it out you can have a look at ceremony.etherium.org it's a test version that's that's good that's there yeah anything else anybody want to chat about before we wrap up one other thing I should add to that is uh we also have uh Grants open for

people who'd like to write their own implementation or do fun crazy uh entropy generation things um they haven't been enough I want to throw things in a volcano or uh I want to use some crazy source of entropy applications yet so I'll drop a link in the chat if anyone's got any fun ideas okay anything else before we oh please yeah one other totally unrelated thing is worrying I guess related someone to KGG stuff do we need to be doing anything on the like kcg implementation in terms of like kicking off audits or like you know further hardening those

libraries I feel like that's something that could be a long hole um so just curious how we're thinking about that so we do have an audit scheduled for ckgz and go kcg with the sigma Prime team who reviewed some of the ceremony stuff and has some BLS expertise and that is scheduled for March I believe so people are working on um kind of doing a lot of cleanups on those repos additional testing and some internal auditing so some of our security Folks at the UI for spending some time looking at those so that's the path for those libraries at least awesome exactly what I wanted to hear

you guys are already on it love to hear it thank you there was some concern around Go kcg performance and sort of like the allocations is that something that someone is going to work on are we good with the way it is I'm not caught up on it so I think uh my understanding is that it's just switching the back end like if if we use the connect backend instead of whatever it's using now then it's going to be quite competitive or even slightly better than blst on performance

so I think that works out there all right thanks as Solus you have your hand up yeah so for our rust kcg project we are used to proceeding with polarizations and you have a way to export the CPI in exactly the same way as cqcg so it's possible to to compile a standalone binary that has all the polarization uh all the things that needs to paralyze the uh like a rayon and other

libraries together so so essentially it's possible to uh to just replace uh the ckcg binary with uh with this rustic ECG binary and have a parallelized version uh that also use the USD uh UCC back-end so I was wondering is would it be suitable for benchmarks because I see that there are people that benchmarking pre-compiles to determinate gas prices and so on and this and the parallelized parallelized version works at least in some places works much faster so would

it be usable because I mean the good thing as I said it's very easy to uh to replace uh this binary with exactly implementation if you are using already using the Bindings that are ckcg report so for for gas pricing only one thing only the profarification is relevant and so I don't think parallelization helps much there it's just appearing it's necessary

yeah but I I checked a bit the algorithm my I was a bit surprised that that based on the number of blobs uh it uh I expected that uh no no yeah this is not what I'm no no it's not the plot verification it's the point verification I see I see so for blob verification there is no uh this not involved in any way okay not in the gas because that's uh that's yes that that's uh that's not an OP code oh okay okay then it's clear so so at least for for this pre-compile uh benchmarking I think uh it will not help in in any way because most of the speed

actually happens by paralyzing this uh multiple Bobby related finger right so which client is planning to use rust kcg so for Grenada we are planning to use it but otherwise I don't know I mean we are as I said foreignix right so I mean just like one thing we

are not currently we don't have an audit scheduled for rust kg right so if it's uh it if it's for like used for clients that's supposed to be ready for production and doesn't have an alternative like can't easily also just compile with ckcg then we need to think what we are going to do yeah I think this is so a bit tricky question because of uh of a different status of Miranda but yeah I mean my message is it was more for people that that may be interested in paralyzed

version okay good yeah uh cksg has some primitive parallelization as well for some things yeah yeah is any other clients planning to use rust kc2 I know theory of JS certainly is we're looking at um well I'm assuming the rest cases I'm sure that that's the same one that kev's working on or not because we're going to compile it to log them so since we want to build a run in browser um just because of our implementation and so um but here again we're not a production grade client our code is but I mean

but at the same time our transaction Library which is used in a lot of places and people want to use that in browser you know we want that to be considered production grade maybe so um we may want to consider trying to get the rust version implemented unless someone is better than me at compiling Casey Judah was them because I don't know anything so you can't compile Stephen you can I just don't know how to do it I see it is good enough correctly using the yes yeah so for Lighthouse we are currently using the dust bindings for ckcg uh we haven't yet tried trust KCT but uh like in in Lighthouse sits we

have like the kcg code in Lighthouse is like sort of not very implementation dependent so we can uh we can replace like the dust bindings for ckcg with Russia kcg and try it out but like I think we'll get a little more uh confidence if the library itself is audited because C because it is going to be audited and might be a little more we might be a little more confident in using if it's audited as don't have any insight into the auditing

portion of sink piece so we have to like ask around about that but okay so that's yeah let's let's discuss this uh offline but yeah uh we can we can definitely look into it and give come back with an update uh next next week thank you any any final things people want to discuss before we we wrap this up okay well thanks everyone um talk to you all next week and I will see most of you and interrupt two weeks from there

bye guys thanks everyone