EIP-4844 Implementers Call #16

Transcript

foreign okay hey everyone uh implementers call number 16 for 444 a couple things today uh we had a new CL spec um we should continue this discussion that happened on our Courthouse around zero block transactions um the free the blobs PR got merged uh which was another big one and then uh George has an update on the kzg library and then as always we can discuss General client testing updates um if there's anything else people want to bring you up I either put it in a chat here or on the agenda and we can cover those as well um well yeah I guess to start uh maybe

quickly uh I don't think Xiao weighs on but Danny do you want to give a quick update on the new CL spec yeah so the primary here is the free the blobs led by yasik um took quite a bit of iteration to get that in a good spot but we're very happy with it now um it's one of those things that you know we don't have networking tests as we write the specs so if something seems off when you're reading it it might be like a typo or just some miscommunication so like please read it with act device um there's some cryptography modifications which uh George can get into and then the I think the other breaking change is the excess data gas field now is at the end of the execution payload which is

just a encoding format change um to map nicer to how we like to expand our trees um other than that nothing crazy enjoy thank you um anyone have questions comments on the and the spread test is out so anyone can test it nice yeah and the the um Beacon apis need an update for signing blob side cars um independent of the block so that that is a very active PR up right now and I think we'll probably talk about it on uh Thursday do you have a link to the pr uh if you

can post it in the chat yeah thanks anything else the specs okay uh next up uh so actually one I had a question Danny I'm just curious how are you feeling about the spec in terms of like-heartedness and Readiness um production running in this perspective yeah on the consensus layer side I'm feeling pretty good I think the there's a the biggest question right now is if the engine API needs to change for any of the mempool stuff and I I'm a strong no on that but that's another debate um the consensual respect's good um I I think we'll spend some time in the next few weeks like deepening our

tests and do some iterative releases with some additional test vectors but um things look pretty good you know I I think the maybe George should chime in as well uh maybe George can give us the updates on what happened with the kzg stuff and how the kcg specs are in association with what we just released um okay if this is the time to do this uh so right so along with the pr that phrased The Blob on the like consensus networking stuff we also managed a PR that does the um related cryptography changes which is basically moving away from the

aggregated proofs and doing isolated proofs for each blob so that PR completely kills everything that has to do with aggregated proofs and basically now we we can verify blobs with individual proofs and we can also batch verified blobs in their proofs for a bit faster verification so that got merged on the spec and do you have a link to the pr hmm okay thanks Justin but I guess okay so and after we merge the spec stuff we started working on this on the

um Library side uh I can speak about the ckcg side so we got that implemented and merged so right now um the base code of ckcg uh implements this new uh spec um and now basically we're working on the bindings um I think Python golang and Java bindings have been updated but there is still work to be done on the like C sharp node.js and rust bindings I think in particular um um we I don't know if Dan is here than

Kaufman but uh there is a a bunch of stuff that need to be done on the node.js side for the bindings in ckcg I think done is the person doing that and also uh I think Alexei will be revising the c-sharp bindings um in the next days according to what he said on GitHub but all in all I think the idea is that um we're kind of like closing down on the base kcg code I think there is like two more issues that need to be resolved that are kind of minor and then the idea is to start like you know uh finalizing the base kcg code and start

working on the bindings more uh where to be honest I think like The Binding situation because it has been happening a bit more ad hoc and decentralized like the individual client teams have been doing it on their own I think uh the bindings situation will need to be uh improved over the coming weeks uh in particular you know like some bindings are doing some checks and some other bindings are not doing these checks and like there is a bit of inconsistency because we haven't quite established rules and conventions of what needs to happen so over the next weeks we will be kind of like figuring

out exactly what the bindings need to do uh on a high level and then we will be we will need help from the client teams to implement this uh more specific logic to each of the bindings um so yeah like I don't have I don't have the guidelines yet or exactly what will need to happen but um this week and the next week we will be working on this and we will be informing uh the client teams uh on what needs to be done but yeah uh if you are working on the bindings uh please expect to

have some work to do on them over the next weeks uh this is the summary I think it was a bit too much but if you have any questions let me know it wasn't too much thanks for sharing uh any question from the client teams or anyone else in summary if client teams are you know gonna have these code paths ready in a week week and a half or will the the cryptography library and bindings are ready as well the bindings physically what say it again please are the The Binding like if people are ready to run

this stuff in a week and a half the cryptography will be ready as well right so okay yeah okay but uh yeah so three out of six bindings have been merged and they are ready to be used the other three uh have not been married yet but I imagine that they can be merged in some form uh in the next yes six days or whatever and after that they will need to be improved and revised thank you but we can merge an initial version in the beginning so people can have things to play with but we we expect people to help us with strengthening them um sorry yes no no if you have any

questions this is a good time and maybe I will have something else to say as well I have a question are there like General like spare tests for this type of bindings so therefore they can be across tests across different languages that's a very timely question that sounds uh Justin you want to talk about this or you want to do it uh I mean can we talk about it together um I would like to implement spec test right the test that more closely aligns like the spec tests So currently these are just like Json files uh yeah I mean I would like to implement test for each function success failure a

whole bunch of different failure tasks yes tests you're right so to say a bit more on this topic which I think is part of the whole um like thing I said before of that over the next weeks who will need to be strengthening the the bindings is that apart from all these guidelines that we need to set up we need to also set up some sort of pipeline for this testing thing uh we had the similar pipeline for the BLS libraries like there was like a a repository by Antonio that was producing tests and then these were consumed by the various libraries or whatever uh or bindings uh sorry uh

but um we don't have this yet for the kcg library we have some form of it uh Kev started working on it uh Justin has done some work on it but we kind of need to cut to to to to to formalize and and make it a bit more robust and and figure out the exact like format of this pack test so yeah there will need to be more work on this uh on this thing but we definitely need to to be able to do um Edge case testing on the various uh public methods could these tests go in the consensus specs question for negative gaming yeah I think they can live there like so

we used to have the standard blss built in the consensus specs recently they were moved out to an independent repo um I do think but that's because the iitfbl standard doesn't live in our specs it didn't really make sense for us to be like building those in there whereas these these crypto specs currently live in the spec and so I would probably advocate for writing a test generator within the specs themselves and have them build as part of our releases that'd be awesome um Xiao is very good at the test generator work um I can give a hand to Alex Stokes as well in terms of people that can't help you there so I I agree that having it done on the spec level would be uh very

nice I mean I think it's suitable to do so I think dunkrat kind of looked into this and he found out that Pi ACC is very slow and for the sizes we're talking about uh generating the test vectors takes too much time I guess and he was looking into using another BLS Library instead of Pi CC so we will have to fix that problem before we okay we've done test generation with Milagro as well within there so we can't use Milagro because it doesn't have the the group functions it only has a signature API sure I guess I say meaning there's a precedent of building another

libraries within that repo yeah yeah but we would have to integrate them so I believe Kev is or will soon be working on um getting the getting an API for uh Arc works and then we'll have it and that should be quite fast okay okay that that that's nice I I didn't know that so the idea then is that we can be writing the test vectors on the spec repo and those will be exported in some format that is yet to be decided and they will be loaded on the various libraries and hence we will be testing the libraries this way I think that that's great

quick question regarding golang do we do we use the golang bindings for um ckcg so we continue using the golang Proto dank sharding um dark package I guess which is what Geth is currently using I believe you should continue using go kcg okay great well any other questions or discussion items uh around the kzg libraries yeah the only other discussion I pinged

Dan Kaufman on The JavaScript bindings the node bindings one sad note is that Dan's going to be transitioning out of coinbase over the next few weeks um he's been there for six years and he's just ready to take a break and so I think we likely I pinged him it may be that he wants to stay in that minions path but I think likely we will probably want to shift that maintenance path to someone else and so I'm thinking maybe the lodestar team might be willing to take on these bindings because they're the primary consumer or the ethereum JS team I don't know if anyone from lodestar ethereum JS is here I mean this is Andrew from ethereum Jazz we're here I I have no capability to maintain I don't know anything I don't I

haven't written C sharp in 20 years or C is our seedless plus so I don't think I'd be able to maintain the body I could I could look into it um I'll talk with my rest of my team there I'll ask a gender if he's not on and he's he kind of sits on footload Star and I think he goes we can look at it um potentially but here again we're also looking to move to the rust kzg Library um so we can do a walls of implementation once once that's stabilized I know has sort of been working on that part along the way but we just haven't had a chance to integrate it yet so I mean we potentially could try and take it on but I I don't I don't feel confident to do it in my face on looking at the bindings

a little bit myself but um if need be we will yeah I think uh lion is already sort of looking into it from the load 13. and so I think most more or less will be able to take care of it awesome nice awesome anything else on the by means or libraries in general okay uh

and then I guess as we're on the consensus specs it probably makes sense to finish uh the map there was one more um one more change that recently got merged to free the blobs PR uh I know there was a lot of discussion on it over the past week I don't know if anyone wants to give a quick update there um in terms of the spec so that was the primary thing that made it into the spec release blobs are an independent blob side cars they're signed we need that Beacon apis uh thing merged so that the validator clients can have a standard way to do so um the simulation results look good and once there's an implementation in a lighthouse I believe pop is going to compare Lighthouse implementation of

coupled and decoupled just to kind of additionally validate our networking assessment um shouldn't be too many surprises I know a number of consensus layer devs um we're following that's back and commenting and and have their eyes on it but again there's if anything looks fishy um please open an issue open a PR we'll get attached cool okay anything else other comments on for different blogs if not um so yeah last week on the uh awkwardev's execution call we agreed to

ban zero blob transactions uh basically uh from from the the spec so not only in the mempool but uh also in protocol um and the the the reason for for this was uh basically trying to come up with a better transaction pool design and um not having to deal with blah blah type 5 transactions that make that easier um so that was kind of the extent of the conversation on uh awkward devs where we didn't necessarily uh discuss the transaction pool itself but we we sort of agreed to this design change um and I believe uh in the comments we

said uh ansgar's gonna put up a PR to this uh in the next few days um but given this I guess you know uh the people want to discuss the transaction pool uh in more detail um any questions or comments on the yeah on that spec change uh Now's the Time yeah I just shared a link um with some other ideas that have been thrown around um that I posted to the zero magicians um so I I I'm perfectly fine with with uh disallowing zero blog transactions but I think there was still concern over um ability to spam the transaction pool with multiple transactions containing

blobs so one of the ideas in there is to Simply um is around replacement um do we allow replacement of a you know multiple blob transactions with with one that doesn't have blobs or one that has less blobs probably should not allow that um and then there's another dos Avenue which is submitting a bunch of blob holding transactions from the same account with incrementing nunses but make it so that only the first one would actually succeed um and so that can be fixed by basically only allowing one blob transaction per account in the mempool so these seem like relatively easy things to implement

and I don't think they'd be too burdensome on clients um and I think they do address primary dos Avenues but maybe there are others and both of these also are transaction pool rules correct correct so yeah yeah yeah so so they don't require a consensus change um right yeah yeah I'm curious does anyone have strong opinions about this I agree they seem sensible yeah Alexi asked more details around why replacement is not cool uh it's simply because you can send the blob transaction everyone needs to validate it and then you can send a replacement

without that blob transaction and then you don't actually have to pay the costs for that you can repeatedly do that right so you can continually spam the transaction pool with those blob transactions and not actually have to end up paying anything for it any other questions or comments I mean there were more more strict proposals that had been brought up in the past such as only allowing one blob in a mempool at a time um obviously that'll provide a lot more protection against a knowledge service

however I think that might be a little too burdens among clients you'd have to start relying on Specialized builders for blob transactions and so on so I'm personally not a fan of that unless we're really continuing to be considering that these other rules are not going to get us where we need to get yeah I think there was definitely some concerns shared by other teams about like like proactively handing things off to builders if we don't have to um so my I don't know my feeling is like it probably makes sense to implement at least those two checks that you just mentioned um do some testing on it or at least you know continue the conversation with those in and see if we need any any more sort of

restrictive checks but those two seem like good starting points um and obviously not all clients have to implement them it's probably better if we if we soft agreed to do this but um yeah these are more recommendations I guess than anything else right yeah I don't know how we usually handle those in in these kinds of stacks but it still feels like we need to kind of make it somewhat formal I guess yeah this is the first time that like it I think has such a like broad impact where like 1559 had some extra degree of freedom but it was more about sorting than like full like the amount of transactions you

store yeah um Lucas you have your hand up yes so about transaction replacement I think we need to support transaction replacement of blob transactions but what we want what we probably want to do is to be able to replace blob transactions only with other blob transactions with some uh gas premium right right now there is I think 10 for normal transactions and Peter was proposing 100 for Block transactions because there might be like um a time of like Network ramping up rapidly and you might want to prioritize

your transaction so the the idea to replace it is good but uh it just has to be uh in a way that wouldn't allow for those factors correct yeah that's that's the idea yeah yeah though I though I propose just a 10 data guess I didn't suggest doubling it um I mean I suppose either is reasonable but yeah the idea is not to allow replacing with a smaller number of blobs than you previously had yeah ten percent is I I believe it's

what we use for for like regular transactions um assuming that's that's still the case I feel like we would probably want something higher for blob transactions like that seemed to be the the conversation in Austria so um whether that's like 100 or 25 or 50 um it feels like we should probably agree to just some higher value than 10 percent I don't know if anyone has strong opinions on the actual value I would go with 100 percent start so easy right and it's uh discourages people from doing that

and just to be clear we're talking about bumping up the data gas 500 the max data Gap or no no no data gas fee right okay yeah yeah yes yes correct yes I think ideally you'd want to have the same kind of minimum increment for both the normal gas and the date I guess just keeps things simple like otherwise this this Edge case is what if one type of gas is only increased a little bit the other one is increased a lot I want to see decreased so ideally I know just to keep things simple I would type one when I left it the same um but I didn't

really have a good feel for whether 10 percent keeps that too much of a Dos Avenue open I don't know so a question about this what does this actually do for dust protection because you can like with eip1559 you can potentially bump your gas without paying anything actually paying anything more like not data gas right they think that's the Prairie where you no it's a 1559 tab mechanism but the the thing of course that you get is that then basically you guarantee inclusion in the next block so then yeah

that's right I just don't understand what dos protection gets because I can potentially ramp up like I can send 10 new transaction each time double it um without ever having any risk of actually paying that much because the fees are never going to get that high right and I mean my personal preference in general would be to not rely too much on these replacement rules and to rely more on per peer throttling of of um requesting new transactions I think that's much more robust as a mechanism okay so I guess

does it make sense to continue discussing the specific gas bump uh offline or yeah I think we yeah it feels like we need to discuss more because um yeah yeah I hadn't thought about that Avenue that since it's 1559 like pricing the bump doesn't necessarily discourage the dosing yeah so yeah let's continue that in the in the sharded data or the 444 testing Channel um and try to have agreement across like clients and research folk for for next week does that make sense um sorry I had another link open I guess

anything else on the mempool uh design if not any any other agenda item that people wanted to cover before we go to Just client updates and testing updates um let's do those then um any clients want to share uh updates yeah I can go first on the prism side we have been just hundred percent implementing the free the blobs PR because it's a it's a pretty big radical change so I assume that we're probably two to three weeks away from finishing

it then after that we probably will spend a single client devnet and depends on on other clients Readiness we can probably do a multi-client devnet option nice yeah I can go for Lighthouse uh same as prison we are working on the free free the blobs here basically and uh I uh like it's a considerable change for us as well and it will take I think quite a lot of time to like get it done to a definite stage uh two weeks sounds okay but like I don't think you can promise that and apart from that Sean has a PR uh word The Blob signing

endpoint that Danny linked earlier so if any one from the CL side wants to give give a loop that will be helpful Etc um it's from Taco we started working on the decoupling we started from the networking and we don't have a timeline now here it's the considerable amount of work so yeah we'll probably have more clear ideas in the next call or it will be progress

Luxor has also started working on the same and will the update to ckce library be available for the changes in the methods and when it will be available what what do you mean so basically the block validation methods have changed right so uh we'll need the library update when will that yeah yeah yeah so I mean which bindings do you care for uh not just

um okay yeah this is this is the um the most problematic one so far because it seems like Dan Kaufman was maintaining them but it might be not maintaining them anymore so [Music] so is the underlying Library yes of course the underlying library is is ready yes I mean I think what we will generally end up doing is merging uh something quickly like merging what we currently have on the bindings also for node.js but then you know so that people can have something

to experiment with and work on clients with and then we can we can over the next weeks improve that code and and and and and we will need help from the client devs to do so okay sounds good we can return yes yes I think I think you can expect the the node.js bindings to be merged this week yes but if you if you have if you if you can if you can review the pr that Justin just done on the chat that would definitely be uh very helpful okay sounds good we'll reach out to you on the same yeah thank you any other client updates

uh yes on this side we have joined devnet 4 last week and yes we are continuing following the spec update for another mindset it's still different for computer and we plan to update 6G bindings with some cacd updates and checks mentioned before and that's it waiting for your scope I mean the network live and we will

continue to this any other teams who spoke before never mind I missed that sorry uh we need an interview we have no updates but we plan to updates kcg the library painting the c-sharp and waiting for a new scope

that's it so I know sorry before yeah like yeah who spoke right before you I think it was I think it was ethereum JS right yeah yeah yeah we don't have any other we haven't done any additional I mean we've merged our our branch that the 4447 but um we were able to sync devnet for a couple weeks ago I haven't looked at it recently but we've not made any other changes yet I'm hoping to start working more on Rust kzg and that integration however this weekend next so um any other client team

um anything else people want to discuss before we wrap up I've already missed this but um since we're do we need to um update the EIP to enshrine the zero blob into the protocol yes uh Ansgar is going to put up a PR in the next couple days sweet okay yep okay well thanks everyone I talk to you

all on the CL call in a couple days and um yeah let's continue the conversation around the transaction pool design uh on the Discord until uh next week talk soon bye everyone thank you all right guys