EIP-4844 Implementers Call #17

Transcript

foreign okay um welcome to uh 4844 call number 17 uh so we didn't have one last week for Denver um so it probably makes sense to spend most of this just sharing any updates um any opening questions that people are looking at um there wasn't anything specific added on the agenda um why do we start the calls at half past um gives me an extra half hour of sleep in the morning you know Marius it's it's nice um I have a call that ends right when it starts so you know some people have weird weird

time-induced call yeah so yeah okay um on the spec side I know there's been a lot of talks uh it's kind of specs and implementation now about handling decoupled blobs um so that seems like something that's worth going over um and then beyond that General client updates but if there's anything else people want to cover um you can post on the agenda or in the chat um but maybe to kick off does anyone does anyone want to give a quick update on uh decoupled blobs um and uh I think gajinder are you able to call yes you had the pr up uh last Friday

oh sir okay yeah that's just updated the EIP basically to match uh Freedom blobs right yep yep so I have the pier up and uh for Lord star uh I'm almost uh I have passed up the entire flow and I'm trying to make sure that I can run it locally so I'm able to so uh produce the blob gossipate sign it so one confusion that I have right now is what is the exact signing floor that should be there because uh I mean there is a discussion going on on the signing flow PR on the beacon apis that whether the flow should be sticky

or not in terms of uh for a particular proposal when a validator is proposing so in the current flow we have a signing of the blinded blobside car which sort of binds the validator to a particular Beaker node in for a given proposal and so there the confusion is whether we are going with that particular flow or we are thinking of signing a full blobside card which can which basically will enable validator to not to be binded to a particular beaconont does anyone have

thoughts on the assignment flow yes we introduced the the blindness flow just for supporting Builder flow actually and then we realized that there is a nice side effect that we can reduce traffic between VC and BN by not sending an entire execution payload and now this applies also to blobs but the side effect of that is that when you don't send everything to the VC then the DC needs to hit the same BN that has produced everything which then in in big deployments where you want to have maybe

failover capabilities you you have that prevented in the in a full uh Builder flow where where the the block has been fully prepared by an external relayer it doesn't really applies because then multiple BN will then end up interacting with the same relayer but uh there are some weird situation where the BN decided to fall back on the local execution layer build block and then just continuing the blinded flow and you are forced in any case to hand to end up going the same vegan node because this

is the only one that has the local produce blocks so a tldr is that do we want to have the opportunity to have um remove stickiness between VC and BN or we recently give up there we don't care and in the build in the block production flow we always assume that VC talks every every time with the same VM I guess

yeah does anyone have any other thoughts on this now or does it make sense to just continue that conversation on the pr directly it seems like uh it was recently active there as well um I mean the only thing I would say is like uh Enrico sort of mentioned this but his problem doesn't really exist if you are Outsourcing the Builder it only exists in like a fallback scenario there and since most people are using the like an outsourced Builder and like long term if we plan to have like a separation of

um block building versus production then um maybe it makes sense maybe it's like less of an issue to go with the blinded by default um but that's not to say I'm like um I feel super strong about that because I do like that validators some of them currently don't Outsource block building so I don't know I wouldn't want to like that well this doesn't preclude not Outsourcing block building this precludes if you don't Outsource block building and you want to do load balancing failover on other Beacon nodes which you know that's one a small subset and

two not it's not like a crazy requirement to have a beacon node that is producing the block be the one to broadcast the signatures but um I mean I get I get that we're cutting out that design if we do this yeah I mean I would be interested to hear about like uh like any existing load balancing things that might have issues with this like would this be an issue with like a test into whatever vouch um stuff like that yeah I think vouch is probably the primary design here but um just using this okay and I guess can we just get

feedback from vouch on this yeah we should at least make Jim aware of it because I know he he didn't want to have the non-blinded blocks as well in the past okay so for all the all intents and purposes I am assuming that we are going with the blinded uh sidecar signing flow yeah I think this makes sense to me yeah another question I had on that PR was um whether we want to like when we publish

these signed blobs to the beacon node do we want to publish them individually or as like a batch I currently had it as like individual Productions just because you can broadcast your model right away but I'm not sure if I don't have opinions on those So currently the counter would be sorry currently I'm implementing as individual so I mean I think individual is just fine the individual is probably fine I think the only thing that you gain by keeping them coupled here in this API is you

know avoiding having to think about any sort of race conditions between the various things you know for example if somebody wants to code that they're not broadcasting X unless they have y already um you you don't have that issue similarly like you might want your VC um you know if there are some sort of reputation issues you're worried about it's the only sign blobs that you have the block for and so kind of like having these things coupled might make sense but I don't feel very strongly here yeah another thing that I see here is that we do past four blobs and then and the post the Imposter blocks block and when we post

the block the API return code 200 actually means that the beacon hole has successfully imported the block which also means that if you do everything in parallel the the block publishing to respect that needs to wait all the other blobs to be uh sent and then the blocking part actually makes make through and can very verify everything with the blobs and then import the block it's kind of adding um some some extra interaction with these three four five potentially uh post

to the bigger node yeah we publishing them individually means we started to change the meaning of like the 202 versus 204 error code or sorry response codes for import because 202 means like published to gossip without importing to the beacon chain and now we're essentially doing that for everything until we get like the fifth message so that's like a a quirk with publishing them individually so the way a lot is implementing it is that the validator basically make shows that it has the block and the blobs

before signing and but once it publishes it in parallel Beacon out really does not wait to make sure that data availability availability checks passes uh while gossiping but it sort of make sure that all the block and blobs are available before importing it locally um I guess one thing to clarify is that are we just requesting um blind blobside card to sign if we are doing that then we probably want to also

change the or update the consensus back to specify that right because the consensus back for the honest validators still says that we're signing the full blob side card I don't I don't think I would actually Elevate that the consensus spec I mean validator doesn't know anything about like outsourced building developer the validity respect doesn't know anything about the separation of Beacon node and validator client and like by signing a blinded object you're also signing the outer object and you know anytime a validator is signing a blinded object you need to make sure that there's like adequate data there that it can do its

safety checks like for example the slot um for any slash message but I it seems like a leakage of the API and practical engineering considerations into the validator spec if we go that way yeah that makes sense do we have enough to try to hammer out this issue this PR before Thursday or do we need to chat about it more here

I mean it sounds like we can keep it how it is I guess um the one thing that's I think is still weird is the response codes but I think we can figure that out on the pr probably what would you say so just real quick the gain for doing split is that you can immediately start broadcasting when you get and then when you get the blobs in the beginning is that that's the main reason that we want to do this yeah but we're also if we're gleaning into the blinded you know we're not actually

transferring that much data between the two so I'm not sure if that's like an appreciable game yeah but nonetheless I mean I I'm on board with combining them for the sake of Simplicity if other people are also cool with that I think combining is a good idea yeah I guess I I'm having trouble seeing what the complexity we're buying like what we're buying with the complexity of Separation especially if they're blinded um but I I'm not deep enough yeah I still I I think as well that having them combined if we go to the blinded definitely simplify the handling

of the API okay I can update that in the pr then um I guess otherwise let's take it to your PR after you do the changes and try to get this done for either final discussion on Thursday or just merge by Thursday thanks for keeping that moving Sean okay uh next up Roberto uh you had a comment about SSD

um so there's been a couple breakout calls yes I'm I'm just wondering if there's any other kind of like complexity like this around the the decoupling that's worth discussing um I I know it seems like not not but I'm just seeing if there's any other design stuff on decoupage yeah we're kind of logging on I think there's one thing um that was I've seen discussed in some chats around um like local heuristics on when you start requesting missing information so like say I got I got the block which you might get the block before you get any blobs you know do you immediately uh request you like wait some portions of

the slot before you request because you expect in the normal case to just get them on gossip and not need to do direct requests so I think those with like design consideration of like which heuristics you use under which conditions and at which points into the slot time to begin doing requests and so I don't think there's a right answer here but it's just something for people to be considering um maybe maybe there's some other thoughts here but that's the main other other point of design that uh but um I I also at home that that's also not like a blocker for the next uh death

net that's something that it will probably take us a while to figure out what's the perfect balance in terms of like going to when to uh requests versus going to wait so yeah I mean I think in the initial version which is gonna wait like a patiently from the gossip hoping we get it and if we don't get it maybe just request ones at the two second Mark and just be done with it but yeah definitely um for the final product it will be a lot more do um thoughtful than that so yeah yeah and um this isn't mate this isn't something that would make it into the

spec um these are like local design decisions so I agree with you James yeah this isn't a blocker cool uh yeah I was just gonna say so it sounds like there's like guidance of waiting patiently and then getting requesting at the two second Mark do we want to communicate that out to anyone now at least for this initial phase um I think everyone's kind of like has this as a known design consideration and that it's they're going to tune it over time but I

I don't know where else we might want to write that down yeah and there's like the telegram group on this as well so it feels like conversation is happening about it sounds good anything else before it says Z uh yeah on the network on the yield side for the transaction uh network uh container so this is the pr

that sorts of updates uh the aggregate proof to proofs I mean if someone wants to give it a review so that's a PR 6610 yep okay we have some thumbs up anything else on the blobs um on the crypto Library maybe that is of Interest sure yes please um so I think right now

um most bindings I think all of The Binding supporting you uh kcg verification interface um we are on the process of like polishing most bindings I think there is very few remaining that haven't been um that that are not like fully there I think node needs a bit more tweaks um an interesting case is that the name bindings uh used to live outside of the kcg library for some reason but now we're pulling them inside the Library as well so both to get equal treatment in terms of polishing but also so that they

are integrated into the audit scope um and the area right now where uh there is another PR that slightly changes the cryptography interface uh on the consensus specs uh it's not very it it's kind of minor it just adds a few more um helpings into the computation of kcg proof so it makes it easier basically for consumers of the API um and we want to update the kcg library for this new interface and after that we hope that we're gonna start to ossify uh

the code base and just do polishing improvements and adding test factors um we have an audit in a month so we hope that over the next two weeks we can kind of finish all the major um changes and then for the last two weeks kind of freeze the whole code base so that's what's going on um there is still some work to be done on The Binding so if you were for a client team there might be some more work to be done but things are moving uh smoothly I think any other thoughts on the library I'm curious are the goal bindings ready

yet does is anyone um working on that um so Kev is working so okay when you say go buying things there is two ways to interpret this either you mean the go library that is written based on Arc or you mean the ckcg go bindings I think uh both go client both prism and Geth are gonna use the narc based library that is Kev is writing um and I think it has been updated to the new API uh uh as of a few days ago but I think Kev is

not here to confirm this but I'm pretty sure that it supports a new API but maybe you want to ask on the on the kcg channel just to be sure about this got it thanks hella oh yeah I'm here I don't know if you can hear me yes hello Kevin oh hey yeah so it supports the new API and not the one that's just about to be merged uh yes I remember my iPhone and not the one that's just about to be merged which returns multiple um things from compute kcg proof but that's uh sort of a trivial change so we can push through cool

uh there's a question by Alexi about spdx headers I I don't know what spdx is if that's a question for the kcg library yeah no no it's just a general question about ckg it's like common practice to input a line or two about license for the library uh spdx license is like a shortcut for sexual businesses I'm not sure I I understand the question

sorry does anyone yeah let me rephrase I mean uh seek is a jewel Library code so it does not include uh license information in Source codes right and so an spdx header adds the license information is that right yeah yeah it's uh two line comment uh which includes this information about what is license yeah uh yeah I mean if if ckcg doesn't have a software license I don't remember it now we should probably add something I'm not sure if there's a there's a license in

the report okay so spdx is some sort of metadata to expose that somewhere or something yeah I can post an example in before for um okay okay so there's no objections to having this it seems anything else on the library

um so next up uh yeah so Roberto you had a comment around SSD so there's been a couple calls already and we haven't quite landed on a final I believe design uh for SSD and you know whether or not we want to do more than just uh the 4844 changes as part of Cancun it seems like there's some appetite by client devs to do that but um yeah I don't know if is there anyone here with a strong opinion about SSD on the El side foreign yeah I don't know how many people have been following along um so we did a temperature check um I think

early on on whether we wanted a couple of this with with 4844 and it was kind of you know I guess some agreement that yeah we probably should because we're introducing a new transaction type and if we don't couple it now we're just going to introduce more technical debt um hold on a second my alarm's going on for some reason I'm sorry what that was yeah but I think uh it's it's been you know about a month since that last last temperature check um and we've been working out the details of what that change might look like and and I personally have been growing been growing growing a bit worried because the complexity seems to keep exploding um and you know I don't know the eip's are pretty large uh and pretty messy

um and I'm not sure they're done yet so I don't know if anyone else has been watching them but um yeah I just wanted to sort of get people's feeling for that so I guess my feeling is um I wouldn't change like in terms of like looking at like the next devnets and implementations I wouldn't want to make like significant changes to the transaction type unless we already agree like unless we agree to a decision for SSD before right

um so it probably makes sense to treat 4844 is like moving forward independently and then if we do agree to make like a lot a larger SSD overhaul in Cancun that might affect 444 but I assume it should be like a relatively contained change if we're just changing sort of the structure of the transaction um but I think trying to like keep both efforts in sync is probably the highest overhead and like least valuable thing like even if we decide to move to SSD and like the foreign presentations are a bit behind you know we can we can then just take time to like bring this up to speed

um whereas it's like if if the SSD sort of proposal changed just two or three times that we have to implement it three times that seems like the worst outcome and I don't know that like we we have consensus today on what we want to do more broadly with regards to SSE yeah I think that's fair and yeah it's definitely true there's not consensus over the solution right we have to um you know kind of single transaction version and then the multiple transaction version I think it's still open with over which one we'd go with I don't know if anyone disagrees with that but yeah I think we probably need a couple more weeks to like

settle the soc discussion yeah yeah okay I think that's fair so just keep keep things decoupled for now and if we decide a couple of them we'll pair it at that point but anyway if if folks haven't taken a look at that um I think it's worth forming an opinion on yeah so the type transaction channel is where it's happening in the Discord and Eaton has a couple uh sort of uh documents that he shared throughout that that show the different structure and um and I don't know that he has run the oh yes so he has run some some uh he has run some benchmarks on

the various designs I just linked them here yeah he comes a wonderful job the the doxies Creator or top-notch so they're ready to be looked at me yeah okay so that and okay um I'll reach out to Ethan after this call and and I think this is probably sufficient to make a decision on like the next all core devs but I'll check with him if there's anything that might be missing great thanks um any other spec related topics that people wanted to bring out um if not

any client updates I have one more thing I have one more thing I haven't heard it we haven't talked about the transaction pool at all today I'm just curious if anyone has update on that or um thoughts that is the ideas we discussed last time I put them in the youth magician's thread um it wasn't much I don't think there was any follow-up discussion so I'm going to assume that means they're not controversial and we can go ahead and add those uh but yeah I don't know if there's been any other talk all right yes I know the Gap team has thought a lot about the transaction pool

anything on the other side um no not really um we've been very busy uh doing some refractors to the overall gut code base and so I don't think anyone has really looked into um upcoming uh things yet um we're we're also working on a together with uh Casey from prison we're working on a SSC code generation

a tool and Library for um yeah generating SSC and so yeah this this is kind of a focus for us to to get those tools uh working as as soon as possible so that we can focus on other things um it's definitely like a priority for us but as I said we we have a lot of other stuff it's only for forgo Alexa is it uh very balanced to go or it's it may be like become cross-platform cross

language in theory it could be cross-platform but we're not planning to do that in the same sense I guess this kind of logistic client teams but any other teams have updates they wanted to share well in Netherlands We Didn't Start works on transactional um sorry it's eaten

here today no he's not uh that's unfortunate so I've been looking at the 644 test cases one thing I noticed um is that so I'm I'm kind of against the normalized type um in in general but this is like a different discussion um what I would like to see is uh more specialized transaction types in the future so for example not all transaction types need to have the access list um not all transaction types need to be able to deploy contracts and so having some test cases that that kind of reflect that

would be it would be great and this will my opinions show that the SSC Union is the um the the kind of the preferred the preferred SSC encoding if we want to go that route um I I'm not sure other people agree with with uh going that road but I think um it would be very nice to have more specialized uh transactions and not require every transaction type to support everything what specific just just so we can close the loop on that what specifically do

things are you saying folks might not agree with I'm just trying to figure out what the Delta is between what Roberto posted and what you're saying here I don't know if people agree with the assumption that transaction types should be more should be getting more specialized basically we just added fears and whenever we like created a new transaction types we included all of the previous Fields I'm not 100 sure what you're doing with the for it for four transactions but the way I see it it would be great to drop the

um uh trap the create mechanism from from for it for four transactions drop the access list from for transactions um yeah so basically drop the feature set that for it for four transactions can utilize but you still can run a executive contract code right and you need access list probably to make it cheaper on my room well no I don't think we need that um I don't think we I don't think uh so basically these blob transactions

are for specific contracts right and um access lists don't make anything cheaper they just let you prepay for gas so that um you can like it was introduced as a feature to unstuck contracts that we that we broke with guess cost increases this roll-up contracts for the blob transactions they aren't aren't deployed yet so we cannot have like we didn't break them before so I think it doesn't make sense to introduce this feature for these transactions and so it would make everything like it would make

the foil for transactions way cheaper way way smaller I think I think it's just like it's a feature that no one will ever use no one will ever send a for it for for transaction with an access list so why should we have it the same argument for no one will ever send a for it for four transactions and deploy a contract in the same in the same transaction right and you're saying that it's easier for clients to like deal with more restrictions at the transaction type than to try and have like a the same sort of template across

many transaction types right where like it's not a ton of overhead the ad restrictions the 4844 transactions yes okay um and then Mophie is saying optimism might deploy some contracts import but I guess the difference is like is it a must-have versus like something that could be you know interesting to do if it was there but I don't know Mophie like would this be like a blocker for optimism if the the like flexibility of four four

transactions was reduced that yeah that's exactly what I'm saying like there might not be agreement about this this is yeah just my thesis that um I I kind of like these restrictions and um I kind of like yeah like not porting over features from that have been kind of hacky in other and other transaction types and would you be so say that we we

decided that like the 4844 transactions don't have access lists but they can still deploy contracts is that still like a net benefit in your perspective or is it more like we need to really narrow down the scope as much as possible to get the benefits because otherwise you still can't like discriminate too much based on it kind of depends on on like which road which route you want to like you want to approach this problem from I would rather say we're not doing anything and every feature has to be uh

uh has to be like well argued for for including it um or we can say we're doing everything and we we have to argue each feature to um to remove it uh if we want it removed um yeah the the the yeah the thing is like we're going to save a couple of of bytes maybe 20 bytes at most if we if we do it this way or 30 bytes at most um but if if you think about 1 billion transactions or I think we have like one

and a half or maybe two billion transactions on on mainnet right now um this it kind of adds up okay and I guess yeah I think we should try and bring this up on all core devs like next week so that's we can hopefully get to like a a decision like because it feels like yeah there's this higher level design decision you need to take and then everything else sort of flows from there so um if people can review that and I'll I'll post about it in the Discord as

well but if people can review that before like not even the not the acdec this week but like the week after that's all quarters um I think it would be good if we could get on the same page right then anything else people wanted to discuss if not I guess one question I would have is um so I understand you know we're about to ship Shanghai and teams are very focused on just getting that out right now

um but what I guess I'm curious what makes sense you know in the next Monday or so in terms of like Milestones or things we want to do for 444 uh considering that like you know getting Shanghai out on Main net is is the thing we're gonna have to do in like the next uh yeah the next four weeks or so um so shanghai's priority so most of our teams are focusing on that um besides that I am just implementing free the blobs decouple the blobs PR so after that's it done I will try to launch a prism local devnet to see how that goes and once that's done I will

let people know and hopefully by then we can maybe try the multi-client test now I guess the world client Readiness by then the better than once and once more clients ready we can probably do that net five so yeah that's my take anyone else have thoughts um oh yeah go ahead for that house we have like um a few people working on for it for four even while we're doing the capella stuff so um we still have a fair amount of work to do on the implementation before we

have something working but I think over the next month like yeah our goal is to get something working and also work on a local devnet and if that works like yeah interop oh sorry sorry go ahead sorry Tim I was just gonna turn up for them Nimbus um similar what I'm I'm continuing to work on 4844 uh and I've been I've been making progress on the decoupled blobs implementation so I you know I don't want to put a date but it's coming along and it it all leads to a much nicer implementation

um as a side benefit so I'm hopeful that uh yeah sometime this month I'll be able to pair up hopefully with whoever else is is ready yeah and the same for for Deco we we already started the the coupling PR uh there there have been also other type of uh work that he had to do we had to do internally so we are not currently on Full Speed there but we are planning to to get back um on on the decoupling and yeah it

makes sense to us to have um something by by the end of the month of the month to start playing with other clients yeah sounds reasonable for us too um if that's roughly the spot people are in as we're like shifting you know more of our Focus away from Shanghai as it's going to be done um does it make sense to move these calls to maybe like bi-weekly and we can check in like two weeks from now where the implementations are if if we feel like we're ready to like put a

multi-client together then we can do that in two weeks if not then um then I think if we were to put it together more like you know a month from now then we can also make sure that it's it's built off like the the the chappella releases So like um that you know we we can kind of basically go from like this being a 4844 devnet that maybe like the first dencoon multi-client devnet or something like yeah does that generally make sense to people it seems like it seems like over time this is basically going to become you know the main focus of the awkward X calls so um I want to make sure we're not just

yeah picking up people's time for no reason okay then yeah I guess in that case um I'll move the meetings to bi-weekly make sure that we cover the SSD uh topic on the next acde which is uh in like 10 days so that should hopefully give people enough time to review things um and then two weeks from today we can meet together check where the implementations are at um how Shanghai is going and uh kind of decide on whether we want to move to a multiple try and test that or wait another two weeks to do that um and I think there's a decent chance like the this definite five might just

be the first like dencoon death net and obviously you know we still have the Discord like and we don't have to block progress on these calls but I think it's it's still valuable to have them maybe just a bit more spaced out sweet um anything else anyone wanted to cover before we wrap up okay and it seems like we might have a load star never mind uh devnet being stood up in the next week or so

cool well yeah thanks everyone I talk to you soon and uh all of the calendar invites to make this uh by weekly thanks everyone thanks bye thank you bye thanks bye everyone