EIP-4844 Implementers Call #19

Transcript

everybody okay uh so welcome everyone to our 19th uh 444 call um so uh Mophie had a spec update to discuss but uh I guess at a higher level just to put this in context last time um we talked about uh wanting to get the chappella releases out and and kind of use that as uh uh Foundation to build the future devnets uh for Ford for for on and and potentially chat about uh you know if those 444 devnets should just become the dencoon devnets and whatnot um so I think that's probably the main thing to chat about today uh beyond the

specific spec issue uh if there's anything else obviously we could always go over that part that's sort of but I had um but yeah let's scale into it I guess Mophie uh you posted this uh PR to the EIP that adds uh some checks uh do you want to give some quick context about it yeah sure um it's a pretty straightforward uh track this is just an admission in the EIP we're not validating the access data gas and um our tip to Marriott bring this up um so when it's possible to provide a block with an invalid Access Data gas but all the other

block headers and transactions are valid and that block gets accepted prior to this PR um now this just fixes that such that um that field is also unchecked it correctly got it anyone have thoughts on this yeah I mean to me it seems like a oversight yeah it would be bad not to have this yeah I I agree um okay uh so I guess uh we can get this merge into the the EIP

um we probably just need the author to approve that PR okay um yeah so I guess next up um yeah I'd be curious to hear from the different client teams so now that we have the chappella releases out um I know there's been some progress as well uh I saw Andrew you were sort of looking at this in the chat last week uh on the report for poor implementations um I guess you know where the client teams generally feel in terms of Readiness does it make sense to you know start targeting uh devnet launch that's built on top of shapella um in the next couple weeks um yeah any teams have thoughts about that yeah I can give a quick update on the

prism side so we have been working on the implementation mostly on the free the blobs um mechanism because that's the one that has been teaching the longest so um on some latest so we have we can do local test net between prism and Geth and then we can spam the blobs processor blobs we have a blobs by root of implemented and tested blobs by range is also implementing and tested so we are working on this whole initial sync mechanism such as we can sync from Genesis to the latest head and that's what we're working on so I think after that it's done we're pretty close to like a multi-client devnet we don't have

backspeo yet that's something that we were working on but I don't think that is the blocker so right now our main blogger is getting the initial sync into word so I I do think Target in a few weeks is fairly reasonable thank you any other teams have updates yeah both load store and tmgs are ready and can do a multi-client and basically we already are learning devnet locally with ethereum JS Android combo uh so for Lighthouse we're at the point where we're trying to get something working locally but we're not quite there yet

um we have a couple like sort of features we're still working on one of which is like making our caching smarter more practical and bad cases um and then also we're working on like the mechanic of like single block or blob lookups in different scenarios if you miss them in Gossip or if you're getting something via RPC but not everything um so yeah I think we're like close to having something working but we're not quite there what do you think um I guess for a devnet um multi-client devnet what what is the reasonable timeline for you guys um I think for us

like two weeks I feel like we could get something running yeah but I guess the further back it is the better our implementation will be yeah right and this would definitely be well I know it's not the first devnet but call it the first post chapel and not the last right so um the the first free to blobs dead man I got yes yes yeah so now we won't be perfect but yeah so forgets basically we've we've not even started looking into it uh because uh

Mophie and Roberto have have been doing such great work um Peter has been working on the on the blog pool on the transaction pool for for blobs and I think that noted a pretty nice implementation uh but yeah so I've been working on the on on SSC library with um uh what's his name sorry Casey from uh from uh the the prison team yes and um that also looks kind of good now uh

so yeah we're doing like we we kind of have to prerequisites down and we should um get someone on for it for for soonish let's let's put it like that but until then we we will still like yeah it's it's great that we have the implementation by uh but uh Roberto and Mophie um and we will probably build on that at some point nice does Peter plan to uh put some sort of write-up around the transaction pool design when it's done I know because he had the he had the one

from Austria which was like all the constraints and like things to sell for it would be nice if uh what's the the implementation is done he could have this sort of uh all the solutions or like ways get his approached the problems uh yes so in his PR he has a kind of a um like a brain dump okay ideas I can link to that yeah if you have the period I'd be awesome there it is thank you

and um or it might be I might have I think I've sent a an old version okay yeah because there's no comments in this oh yeah there are no comments it's uh you know it's a comment in the in the code oh okay got it this one should be here anyway but uh yeah okay I was I was already on the latest version but uh basically it's a comment in the code uh in the blog pool line 128.

yeah this is like 150 lines of comments uh which explains some of the ideas oh awesome do we so I we've had discussions around this before around whether this stuff belongs in the spec or not kind of these layer zero types of things um exactly what we're doing with transaction pool rules um and another thing I think is the um do we add data gas field to the um transaction receipt are these the kinds

of things we put in a spec or do we put them somewhere else like the data guess in the receipts that needs to be put in respect uh the transaction pool not in my opinion um and it's I think it's it's always better to have for these kind of things that are very like dos critical uh it's kind of good to have multiple different implementations so for for for example we had this issue on on girly recently that we were uh getting those get was getting those

um but because Netherland doesn't have these like doesn't handle future transactions in the same way we do um like it didn't didn't really matter to them so uh having having yeah more more like different implementations of the of the transaction pool really makes sense to me I agree and disagree with the statement from how our transaction pool evolved it was a lot different than gaffes in the beginning in terms of rules maybe internal like workings is very uh is uh was still different but in terms of the

rules but the rules evolved very similar to gef and the one thing that Mary is mentioning is the one place that we were more strict um but overall uh from because of security and performance reasons uh our transaction pools actually uh converts to just to have more similar rules than get implementation just from the Practical reasons and so we can like think that we can do blobs differently but in the end probably Common Sense would would put us on very similar paths does from experience yeah I guess my concern is you know

clients need to know what the expectations are right around submitting transactions I mean maybe blobs are unique enough that you know people are sophisticated enough to figure out the quirks of different clients but that was my main concern yeah so at least if we have the code well documented like I mean you know the Netherland team can obviously read the comments in the Geth PR um but it's true that we don't have a yeah we don't have somewhere for those those like non-consensus design uh Docs Maris anything else on guests

uh no any other teams have updates that's the one to share um yeah on the nimba side I think roughly tracking what um what lighthouse describe schedule wise I think um I think in a couple of weeks seems seems feasible basically a lot of stuff is kind of backed up going into PR's this week um the free developed implementation is is mostly done but still needs to to get submitted and merged so I think uh yeah a couple of weeks ish seems within the realm of possibility

yeah an updates from Taco as well we are working on different streams now and I'm parallel and um mostly on the orchestration between yeah the gossip blobs and you know cups and the arrival of the block um also in the API signing flows so there are still plenty of work and make everything glued together and do some internal tests so yeah two weeks seems to be tight at the moment so uh yeah maybe if we can't join the

first version we will join the second one uh for Aragon thanks to Roberto we have a draft implementation but um we have only started looking at the changes understanding of the changes and we've started merging them but not like the entire PR in one go uh we we started merging at piecemeal and it will take us some time to take take in all the changes yeah and Andrew I'll I'll do my best to get it merged with Upstream this week it's it's probably diverse because I

haven't touched it in quite some time but um I'm gonna I'm planning I'm planning again on that super thank you oh yeah please yeah we'll be careful to join what the export solution and improve it in the future but we're already basically this thanks uh Fabio yes uh ambassador's side we are at devonet 4 feature level at the point so um we need to check what we need to do after

my understanding is that from the execution engine side the number of changes is smaller I have to say if we can Target two weeks uh depends on the priorities of the team that we are working on at the moment there are some stability and new features in development so it's hard to say if we can hit that weak Target at the moment need to check with the team any other client team

think that was everyone okay and so um Mophie has a comment in the chat about the next step that should be long running um so basically uh I assume we probably aren't going to make any major spec changes obviously if we do we can we can reassess from there but like yeah it does seem like uh the spec is is in a pretty stable spot um so I agree that that's probably what makes sense to do is to Target uh you know the the specs um assuming mophie's change uh goes in with some minor change

um and then potentially aim to get the first death net with like a subset of clients in the next two weeks I don't know if it's possible before the next one of these calls or maybe right after obviously we have the fork on my net scheduled a few days before the exit these calls but I think that you know if by the next one of these we could be in a spot where if we haven't already launched the next devnet we we are ready to um ideally we have like more than one El and more than one cl just to make sure that uh multi-client stuff works um it seems like on the CL side it should be possible on the El potentially if we're not running off uh

I mean potentially we can get you know death and uh met Aragon running off the the branches uh but uh it won't be running off of Master but yeah I think if we had like a free double lobs devnet with two plus EOS and CLS would be in the spot where um we can have something stable gradually add more clients to it and and keep it running does that does that make sense to people oh yeah ethereum.js I could join that's right yeah so oh that would actually be great yeah so one one non-roberto and Mophie implementation as well on the El side dish and I guess okay so yeah from like

ethereum JS uh oh none yeah yeah ethereum JS uh Jeff Aragon um and and I guess uh prism and potentially uh lozar what's like the quickest we could launch this stuff and that's do you think um is this something we can do you know in the next week or so are there still some changes that we need to merge in or rebate like air uh Roberto you mentioned you need to rebase Aragon yeah what do we think is like a reasonable Target for yeah I mean I think I can get it done this week um so maybe next week is a reasonable Target if we just want those clients that that seem to be reasonably ready for it anyway

cool [Music] so I can cut the images on the latest code I don't know prison Terence do you have a feel for if this is something like a week from now yeah yeah no I think we'll probably need like another week after that so maybe two weeks but yeah like I said more than if you're free to even start with dollars you can just I think for us we're fine gossiping blobs but we might

have issue initial thinking so yeah I I so obviously between one week to two weeks sounds reasonable okay so how about we try and obviously it's going to be like a Easter weekend this weekend so some people I suspect might be away uh a bit more than uh otherwise but why don't we aim for like early next week to try and start uh setting this up so uh this week uh we can we can do the changes to Aragon uh kind of you know uh yeah get the the yells in good shape and then maybe early next week we try to launch this see how it goes throughout the week and then uh on our next call on

our next call if we can have an attempt to launch the devnet uh whether it's successful or not I think that'll be good in the best case you know we have a couple clients running next to each other and and others can congratulate join in in the worst case uh there's something that would work and we'll have time to debug it but I I think that's intrusionable cool um and obviously we'll have the CL call in Bell cordoves if there's the other uh awkward deaths if there's anything that uh yeah that pops up before our next four four call I think that's pretty much all I had anything else that people wanted to discuss

um what was the verdict on data gas in the receipt there was some discussion in the chat um oh it should be yeah should we just add that to our clients and not worry about putting it in the spec um Proto I guess you had some comments there I didn't quite understand if you were taking a position it was pretty clear it could just be metadata something not affecting consensus yeah it's definitely not affecting consensus that's why I was curious whether it belongs in the spec or not they should be yeah in the execution apis would it be there will be in the execution apis then if we decide it's useful yes or the other

received fields that are considered metal data yeah yeah this is Andrew from Etheridge when we erased this issue way back with the during Austria that that was where we decided to put it was in the uh execution API and I just haven't gotten to actually opening the pr against the the apis on it yet so I can I started that a while back and then got sidetracked with other stuff so I can Circle back to that and try to get that and then um in the API get a PR open against the execution name guys I think we talked about we wanted to bring it up to the the execution all core devs call before we do any like like I think Tim is that's my recollections yes I think we can definitely open the prsap it's good to mention that Donald

cordov's just so as you people know it's there I think the thing we should do as well once we have that PR that's probably a good opportunity uh I don't know if the execution apis can be linked and eips quite yet but I know they wanted to do it at some point uh so that would probably be a good opportunity to once we have this PR up uh we can potentially add it to the EIP itself so we can mention in the EIP itself that you know the changes that the the receipts are tracked uh are tracked there okay I'll I'll try to get a PR I mean I think I think I already even had even written it up and I just haven't ever pushed it to the I'll try to get a PR up today or tomorrow and then I'll as I

remember I'll drop a note in the uh in the starting channel on ether r d and can figure out how you want to go from anything else foreign did we want to shoot for any transaction pool specific Canal service goals for our devnet or uh should we just let figure that out later what do you have in what do you have in mind in terms of goals so I posted let me let me look it up I posted um

uh in the East magicians Forum I've made a couple proposals based on the discussions from the workshop um I'm trying to look it up because I can't remember exactly what it was oh yeah here we go the lab holding transactions should only be replaced by blog transactions consuming animals yes um and then there can only be one blob containing transaction per account um that protects against two specific denial of service vectors I mean I I can go ahead and Implement them in in gath and Aragon at least um others can take it or leave it I suppose

yeah I think it would be good actually to have it drafted if you have the time to have the job to implementation like run it in the devnet and see do we like if we if we send a bunch of spam transactions or you know in another case that we see bugs or or you know any kind of unexpected issues based on that um and obviously we can we can revert the change without working the definite if we see issues but I yeah I agree we said we should try that then it makes sense to do it yeah cool I'll do my best to get that yeah yeah and I mean similarly if if we're ready to launch a devnet then we're just waiting on that we can not just definitely pull out it and do the

transaction for change upgrade the nodes and see uh See after but yeah I think I think it makes sense the anger dropped yeah prototype implementation anything else so okay then I guess we can wrap up and I think we did discuss this I think a call or two ago like how useful these calls

are if like we've moved to like dencoon um I feel like they're probably still useful for at least in a little while so I would keep or like two week four eight four four Cadence at least I don't know for the next call or two and we can always like drop them after that but it seems like as we're setting up the stev Nets and and kind of working through the initial implementations probably makes sense to have a bit more focused time on this but um I suspect in the next couple months as we're like fully into this as part of dencoon maybe they're not as relevant so um yeah at least the next one or two I think are probably important to keep yeah for sure I don't think yeah definitely your next one if we're trying to get it yeah yeah yeah yeah yeah for

sure that excellent and I suspect we'll probably want one or two after that as well you know once we have like the early death notes and and yeah um what what do you think the timeline is for the next Fork I mean I can't remember actually Czar but I'm just curious if there's been any discussion around that I I I don't know I think the biggest question is uh so like obviously the the like the work of doing 444 and then is there like what else comes alongside it I think on the LaSalle cordevs there was a pretty strong desire at least on the El side to not add anything that would like significantly delay so for example it seemed like for SSD we're probably leaning towards doing like not doing

your full SSC overhaul alongside uh for it for four there were some similar concerns about the eof although it's not clear exactly where like the consensus is gonna land there but definitely every time something big comes up it seems like the response is like you know will this significantly delay for it or four so so yeah I I don't think we have like a set date or anything like that yet but at least for my view it's like people are aligned on not adding some other kind of huge thing that would uh that would make it a big difference but hard to say beyond that yeah that was my impression from the calls as well I just was wondering if there have been other

things that I wasn't privy to so uh Alexa you have a question like what's the feedback from Altus what what do you mean in terms of the timeline in terms of the EIP itself in terms of yeah it seems like uh solution we are developing uh it requires like uh basically feedback from uh the main consumer and oh okay yeah yeah I see so so uh from the optimistic side uh obviously optimism has you know invested quite a lot in getting this to happen and and so as coinbase uh so I think and and we've gotten like really positive feedback from arbitrum as well

so I think from the optimistic role of side like they're all quite on board I think for ZK Road upside uh so you know this is usable by them so we've checked that like technically this this uh provides good uh you know scalability and but I think they might have like this might not be the number one thing they prioritize using as much as like optimistic rollups as soon as come out so I don't think any of the like ZK Roll-Ups have like an objection or or like incompatibility with this but um their roadmap just seems like potentially let's let's focused on like as soon as this is live we're gonna shift everything to it uh which is more the feeling I got from optimistic rollers

yeah it's a pretty easy change to adapt to um well we haven't done all the details but we've done an initial initial pack of starting them but yeah yeah and I think if there are especially I think this is modern as the UK side like if there are any that have problems then like now would be the time for them to sort of step up and and mention those but we have done some Outreach and like sent this to them several times in the past year and yeah there hasn't been anything that's come up it's like critical or blocking or anything like that I would say nothing critical from the

optional lab site so we are implementing the orbitron protocol but I do think like it's worth discussing more maybe not the scope because this is more implemented this is so it's worth discussing just like the data I guess essentially data gets like what per what what parameters to use and how often do we increase and decrease the percentage and then there is like uh um and there is like a research Thread about this and then option Labs have a research team looking at this problem we posted akaki posted his latest feedback so yeah we can bring any further discussion to this Research Forum but I think for Layer Two it's very important to figure out those Library meters

do you think we should discuss this on the CL call this week right I think like just I think like whoever was coming to come into the Research Forum I don't think like most of the awkward death call has the right um audiences right because the right audiences will be people from the people from the rig team and um representative representative from the very two teams as well and I do and then I don't think they mostly show up in this type of implemented yeah okay we can definitely try and like pass this along uh to get broader feedback in the next couple weeks from from l2s and

and the rig folks cool anything else Lexi asked um so there's no chance that things like blob size or kind of block will be changed I keep forgetting is our is our limits one two or two four right now uh two four two four yeah I would be extremely surprised if it got

changed to the upside uh I doubt that that would happen um I could see a world where like if we do some tests and whatnot then because there were uh I believe some networking tests that were run and that showed that like there was some uh some delays uh with with large call data blocks uh they weren't huge but they were kind of noticeable so like I think if there were to be a change it might be possible to go from like 2 4 to 1-2 but aside from that I I would be very surprised I don't know if anyone helps has thoughts on this

yeah I think I haven't heard any huge worries about the current numbers so yeah although having the only change that you know I think would make things a little simpler is to just say that there's one blob per transaction that kind of makes transaction pool issues management a little easier um but I'm not proposing that but it wouldn't surprise me if um it came up is all right so we've removed okay got it right so we've removed zero blob transactions but we can still have to blob transactions yeah yeah

or more yeah a little bit I mean like right you know if you have a transaction with you know three blobs versus two transactions with two blobs yeah is there a use case from layer twos to have more than one blob per transaction I guess if if the batch is bigger than like one 10 Fifth and one blob but that seems kind of weird because and then you can probably submit two transactions right so right yeah yeah actually yeah yeah but I don't know Frodo or parents like from do you have optimism side can you think of a a use case like that

oh optimism at least with the next slipkarts those supports arbitrary splitting of data between multiple different sections I think the building feature where multiple blobs are linked in a single transaction is something that's more useful to the ZK run-ups okay so yeah again like we should ask them for more feedback the Arnold was active in this this call okay yeah I'll try and see maybe if yeah we can get some uh ZK Roll-Ups people to uh look at the regular specs and

share any any feedback um we can wrap up uh talk to you all in two weeks and yeah let's try and stand up the devnet uh early next week we can use the the Discord to coordinate that great thanks see ya bye guys thank you hey guys