EIP-4844 Implementers Call #20

Transcript

foreign I guess let's get started and see if people join in oh okay it's recording already so I'll just trim the video um okay I Welcome to our 20th uh 4844 call I'll post the agenda and the chat right here um there were a couple small specs issues that uh I think people wanted to bring up in the context of launching the next devnet um so it probably makes sense to start just going over all of those and then uh once we've done that we can talk about

the different status of the implementations as well as um when and how we want to launch a devnet okay a couple people just joined as we're getting started uh so yeah I added all the the things in agenda um so prono just wanted to highlight there's been a small change uh by Mikhail in like an error code um it's literally just a one not even a one line change one value change anyone just have thoughts comments on that okay let's switch forward to me yeah I

mean like yeah sorry sorry yeah oh no no please go ahead yeah yeah it's just an alignment uh from my understanding that the error code has been changed and yeah so that's accidentally accidentally joined the portal call because at the same time sorry glad yourselves to come over here I saw Piper there and was like oh Portal's gonna integrate for it before um yeah good timing we literally just got started okay sorry Mikhail you were saying uh the

yeah so it's just the error code change um and I think you're saying like why it was uh it was changed there was a discrepancy between the um this bag form of extension and yeah because there was a change at some point in time uh realigned the error codes with I don't remember why but that's still yeah okay so cool um yeah any other comments on that okay Next Step then uh actually uh Mikhail

this was uh your suggestion um so basically you mentioned you know merging get pedal V3 and get blobs in bundle V1 I guess I'd be curious to hear from folks uh you know if we want to do this in the context of the next devnet or um if we if this is maybe something we want to do after that definite um and maybe Mikhail you could just give like a bit of background on why we'd want to do that yeah sure so a bit of a background when uh baseball extension was introduced the get blocks uh bundle was separate because it was easier to prototype and

spec out in addition to get payload uh so it it uh it makes sense for a prototype and all this kind of stuff but uh since we're heading to towards the um checking out the engine API changes for Cancun this question should be this is one of the outstanding questions that we need to resolve and flcl the name has raised this question in the Discord recently and I thought that that's a perfect momentum to discuss it uh with their client developers whether

we want to keep them separate or we want to merge these two because this is basically the same build process that from which we are obtaining the payload and the blobs so this is a one-to-one relation between the payload and blobs and at the first glance it seems like there is no sense to keep them separate so the get payload basically can return both but maybe um yeah developers has different opinion have different opinion on that and yeah I was just going to bring this for discussion uh we don't need to decide this for next couple of devnets probably or three devnets but we will have to decide it soon

um in order to you know spec it out and have to have it tested if we want to get the merged more extensively tested got it thanks does anyone have any thoughts on this from the fine teams uh I don't see the use of having them separate so I'm good with merging it yeah I guess yeah does anyone want to advocate for keeping them separate okay I guess in that case then yeah let's you know open a PR to merge them I

wouldn't probably include that in the next devnet unless people feel strongly that we should so we don't have to like rework that as well but does that make sense to people is it is it a significant reworking I guess seems like it's fairly Limited in scope but um on entirely sure I assume you're removing an API and passing some parameters that were previously passed in the removed API and the new one but maybe just something I'm missing does anyone feel strongly whether it

should or should not go in the next Maybe not next didn't it but yeah it could be done quite soon yeah I think my preference is probably to my preference would probably be to just um not include it in the next devnet and uh have the pr open for it so that we can start doing like multi-client testing as soon as possible but yeah weekly held opinion now yeah I mean

I guess the hope is this would be a more longer live devnet um but to more the more changes like this oh minimizes that right minimum is the chance of that so oh got it yeah yeah the longer living because most probably we'll have more clients joining in maybe in the next definite and it would be nice that can be the longer living oh she's saying yeah then at five we might not have everybody but then at six we likely will yep hopefully okay in that case I think yeah that seems reasonable to me or you know

potentially the explains that join will also have bugs which require us to recite the Deathmatch um obviously you always hope this isn't the case but um practice seems possible so um yeah let's open the pr for this and not have it in scope as part of development five yeah and then obviously if anyone not on this call has issues with the change they can they can leave those comments on the pr oud um yeah anything else on this um otherwise uh you had three PRS you wanted to highlight

uh regarding devnet 5 we can maybe just go through each of them to make sure everyone's on the same page the first one is a PR you've made to the execution apis yep yes so I guess it could crack up yeah yeah so actually uh the first we had the result of the EIP uh update PR which basically add proofs to uh the transaction wrapper uh so basically on the front of the serialized transaction and since now the proofs are available to El so that they can just be passed to the

CL through uh get blobs API call and which is basically the second API and the third API so these two are sort of part of devnet 5 specs but it would be nice that you know if this can be reviewed and merged because uh there are some renamings in in the EIP for it for for PR 6610 so it might lead to some renamings on the execution API for for blobs bundle and uh the third PR is about uh blob signing points and points which

basically extend the current endpoints to provide and publish oh I think I think we lost yeah I can't hear a minute okay yeah did I hear him right but these are all in scope for um Mophie is that your understanding uh yeah they're they're in scope what's the implementation status in death is it to do

yeah to do but it shouldn't be um a large change Fels yell I'm not sure what the actual name is uh oh actually okay yeah yeah okay I will place tonight so next thing so the question was uh Isabel is about blob's bundle in weapon which may include now Bruce according to the suggestion right just wanted to know why we have hidden these proofs uh previously there as a

useful metal on sales side this is the question uh so on the CL side once we get the bundle from execution layer we just run up verify proof batch to verify everything is in order uh that's where the proofs and commitments get used and post that thus signing and Publishing flow happens I see but how did it work before I mean we did not first proof right to you so we can we can generate proof since

commitments and Globs are there but I I mean it's sort of feels ugly to me doing this on the CL side because not really is required I mean you don't require to generate commitments or to see that you can just push the bundle to the verification function and be done with it okay does it make it more secure the proof matches I mean if we send proofs wasn't it less secure previously don't think there are any changes in security guarantees because if uh if does the setup is same

then it doesn't really matter I mean you should get the same proof um quick question so I think we had something like this before free the blobs where the proofs regenerated on the scale side and I recall we got rid of it because of the additional time to compute the proofs and we wanted to minimize the time for Block building on the El so I guess my question here is uh is it still a concern like Computing those proofs on the El side would it take would it necessarily lengthen the time to build the blocks

so the proofs on the El side are coming through transaction wrapper layer because that's what the EIP for it for for PR 6610 propose proposes it basically earlier there was an aggregate proof but now the update on the uh PR is on the EIP is that the proofs will come bundle in the serialized transaction so there is no need to compute for compute on El side as well gotcha okay that makes sense yeah the main issue before was the aggregate proof of computation that was pretty expensive okay cool so we as a execution layer said we do not need to

um to verify proofs what we need or we still need it sorry I didn't get the question uh do we still need to verify person on execution on their side at all we can just send it to consensus layer after this update and will spend less time on transaction with her location in memory pool I mean if it's part of specs then

El could basically probably skip check checking the proof but since the transactions would be broadcasted or at least the hashes would be broadcasted to other be host I don't basically suggest that proof not be checked only yes okay any other comments on this I guess is this something we'd want to

add for V5 does anyone disagree with that are we still talking about the third the third of these three or is this a different issue oh sorry I oh yes the third in the full list I thought you meant the third of this of uh there's three PRS so adding the proofs to blobs Bond will be one got it and I guess I don't know if we are

um moving kind of merging get payload V3 with it for the next devnet it seems like it's reasonable to just also include that in like devnet6 rather than devnet uh five so that we're not actually changing blobs bundle V1 but I don't know if anyone feels differently or I I thought I this sort of seems like a requirement if we're including the coupled blobs to devnet5 then don't we also need to add the proofs to the blobs bundle endpoint okay yeah yeah yeah it would definitely

should include the decoupled knobs and sorry I didn't realize this was a must-have basically to if we were to do so yeah then if this is required if this yeah this is required uh to decouple the blobs and I think we should make this this change yeah at least that's my understanding uh maybe uh have any thoughts here I mean yeah basically it saves the completion both on the outside and cl side so I guess we can do this okay and if we are doing this then is this still like back to the previous

issue do we still say like should we also merge get paid on V3 and they get blobs bundle at the same time like are we gonna you know waste time by separating those two changes or should we is it I assume it's much easier to just add the proof so but yeah I don't know how do people feel about that I mean on the field side the change would not really be a big deal I mean it should be a couple of hours if everything else is in place so I am okay if we can merge it even for definite five the guy Ginger which one were you talking about the ice in the second I assume Virginia the

execution API yeah emerging with the payload to get payload and get below three oh okay so okay so you're saying it's only a few hours of work to merge get paid out and get blobs bundled is that correct yeah I mean on the sales side yes okay on even on the outside because El would be caching all that data anyway so it can just return the full uh uh content uh in the get payload three okay so yeah I don't oh I don't think

it's a big deal for the El side um but I don't know I'm wondering these other Yale clients that have opinions strong or is it or or not so strong on this before we slate it for dead net 5. do we have like a usually Terence is pretty clued in I don't know if he's in the call looks like it might not be no he he's not he so basically but he says that um they have a local devnet running uh with multiple prism nodes they're ready to join a multi-client devnet so I assume in terms of just like if this is just a few hours of work uh it shouldn't they're not they're not

delayed or they're not behind in any way um yeah um okay so yeah so do we include it or not yeah I'm I don't know enough about the CL side just to have a strong opinion yes CLT is relatively easy as well I mean I don't see any challenges okay let's tentatively include it I guess we can always yeah get rid of it turns out to be too much we will run it by uh Terence and a few other folks I guess to confirm yeah and and yeah and to be clear so we're tentatively including both changes so merging get the payload V3 and get blobs bundle V1 um and I don't know that we have this

ER for that quite yet um and then we would also include the proofs as part of The Blob sponges so we would need yeah yeah so we just yeah perfect so we just need a spec for uh the get panel V3 and get lost window V1 merge okay anything else on that um your next TR that you mentioned there is the update to 4844 to decouple the blobs I assume

this simply reflects the functionality that was already merged on this CL side is that correct uh so basically yeah it changes the network wrapper uh to have proofs instead of aggregate proof and there are there are a few renaming renamings of cases G two commitments uh nothing more than that um any yeah any thoughts comments on so I and and I assume we should just merge this and there's like still some comments on the VR but like yeah we merge this it's effectively part of that five already

yeah I think this this is already implemented I believe yeah anyway correct me if I'm wrong yeah that's right okay uh and then last one of the PRS you brought up uh there is uh the blob signing endpoint uh let me post this in the chat as well here yeah do you want to give some quick background that one yeah yeah so this is sort of internal communication between uh Beacon note and validator how to sign the block and blobs uh so basically what it really does is uh that uh it extends

the current produce and publish API endpoints for the network to include to sort of use block contents rather than the block block contents are basically Block Plus blobs Sidecar and uh so this is basically internal communication between how we can order a validator how to sign it and it's sort of optional in the sense that if there are no cross not slash related Communications which we generally don't test for Android app Nets then it is sort of an optional thing but since we are uh we are trying to uh we are going this way I mean it could be an optional

uh requirement to sort of push it push the implementation forward anyone have thoughts on this I'm not sure yeah this one yeah has anyone reviewed this basically um so load star has implemented it so and plus one for this yeah and I guess

yeah this this doesn't change consensus or anything so like it's fine if load star has it but like not prism correct yeah this is optional uh internal communication between big and not and validator yeah Tech Will already started implementing that one it's not completed yet but we are going to be compatible with the this PR oud okay so I'd say um I mean we can probably merge the pr in relatively soon I see there's like a huge thread of comments so obviously kind of want those resolved but

yeah I I guess this is sort of orthogonal to devnet5 so we don't really have to diminish it or if the specs yeah does that make sense yeah that makes sense I I currently had it marked as optional and the definite spec okay yeah yeah then let's just leave it there like yeah so people have the information but okay so I guess the recap um and I'll post your spec actually Mophie thank you um so for the devnet 5 uh we have the yeah uh that obviously decouples the

blobs blocks which is the transaction type and the El built on top is Shanghai no zero block transactions and change the transaction type as well we couple the blobs and then on the engine API we're adding the proofs to blobs bundle V1 and I guess the other thing we would make is we would merge blobs bundle if you want and get paid on V3 so that's I think the only thing that's not quite in the spec uh as of right now and then the beacon API add this optional PR we just mentioned does this make sense to people as a general spec for devnet 5.

so let's yeah let's move forward for that just literally one bullet point to change uh on on what it looks like and yeah curious to hear from the different client teams where uh where they're at uh Karen said you know they're ready to join a multi-client devnet basically ASAP uh Lighthouse said in the chat uh or in the comments sorry that um they probably need another week or two um and uh yeah load star seems ready as well it seems um I don't know if there's any other client themes or if anyone on those teams wants to expand um yeah uh Nimbus sorry yeah yeah it's Henry nimbers here I'd say probably in

the lighthouse time range I'm wrapping up um so we have sync working I'm wrapping up gossip and fetching fetching missing blobs doing gossip Etc that's that's probably the last PR is going up today or tomorrow for that and then there'll be some tying up loose ends and stuff so I'm guessing another week to two yeah on the stack of side yeah more on the two weeks time frame hopefully we're still doing some some work on the storage side plus yeah working on the on the import flow yet and the API as mentioned before

we're doing we are implementing uh to be compatible with the PR but it's not completed yet so still working progress hopefully I will join you later after the dev Note 5 launch thank you anyone from the El side another mind his previous book implemented and just needs to like a week to align with these new items

um Roberto how about guess and uh and or Aragon yeah so um Aragon and guests I think are approximately in the same state so uh which is pretty pretty up to date um yeah other than those pairs that we've just a few PRS that we've discussed today which we should be able to fairly easily add so it seems like this oh please I should caveat that with Aragon has not been extensively tested recently I just completed a a bunch of Updates this weekend um have not run any tests but at least uh got the Upstream merged and some recent changes implemented nice and there's a comment uh from there

that uh ethereum JS should also be able to join them um so it seems like we probably have like half the clients at least give or take and and obviously you know there's going to be a couple uh a couple days of uh just implementing the the last changes that we we agreed on today but yeah is it realistic to try and stand up the devnet before the CL call this Thursday and that if we run into any issues doing that um that we can't sort of debug async we can cover it there that gives us like three days I would say probably not

maybe like next Monday or Tuesday would be a better date what do you think what do you think is like the blocker like yeah I guess you know yeah what do you see is there anything specific you feel like we need to figure out this week or is it just implementing the stuff we just discussed um it's implementing them and um just the availability of doves here to um to do the interop in particular fair enough so I guess then

in that case maybe and I say a couple like thumbs up on the screen in that case what uh I would maybe do is um let's you know check in on this in a few days on the CL call as well and aim for something you know or early next week uh going live yeah does that make sense to people yeah sounds good cool okay and um and I guess on I guess similar note I would definitely keep a 4844 only call two weeks from now as well um and we can use that to sort of coordinate whether we want to um shut down devnet5 move to that net six and whatnot

uh Lucas uh so I have a question about Forex for for testing so one thing is the death net but I uh have a question what's the plan for Hive tests are they being developed are they like still being postponed or what's what's that band yeah we have Mario on the car yeah yeah we're still working on that we started with the reference test for the execution of their clients and we have done those almost ready um but yeah for the ndn API and all that we still have to work on it and yeah we have them I mean we have to start this week so probably next week we'll have

something to test uh the changes on high um any other questions on the devnets schedule testing or whatnot uh I have a query uh with regard to the CL side spec test I think uh it's still using that transaction prefix as zero we're looking around we're working on a release right now should be out by tomorrow with zero three I suggest using that for that's

also in relation to the head of the EIP so I think we should use that and the tests will be ready tomorrow as yeah yeah we should definitely use uh type three okay anything else on the devnet on or testing you okay in that case uh Danny you mentioned uh you had a point around uh the mempool and the payload yeah so this came up in Edelweiss

essentially Peter would like to have the quality of Service Such that Upon A reorg any type 3 transactions could be put back into the mempool um so that users have the same experience they have with normal transactions today um and he and I spoke and so to to make that happen you have to essentially break the barrier between execution layer a bit more um and on new payload give the blobs the execution there so that they can have them around in the event of a reorg uh to rebuild the transactions the full transactions um we had spoken Peter and I that maybe actually to not break that uh barrier

not change the engine API what you can actually do is anything that's come through the mempool you have the blobs and so you can provide that quality of service to users to have them reinserted but essentially if you bypass them and pull you don't have a guarantee to get back in because the condensed layer doesn't give them the execution there and that would not require the new payload change um I thought that we were kind of in agreement on that I took a look at Peter's slides from a talk in Tokyo the other day where it implied otherwise I just wanted to surface this as a design point to the group that like we this this does seem like an unknown Point

um as to whether uh we agree that there should be a change here whether the change would happen uh whether Peter's assuming it will happen that kind of stuff so s beyond that evil can obviously weigh in their opinions here uh but we probably need to have this conversation somewhere otherwise I think the conversation if we don't concertably have it is going to like happen in four or six weeks um and still be a debate that's you know a break from change um Danny could you please repeat the alternative uh where we are not passing blobs back to El uh whether El stores

them or what happens right so essentially you want El or you might want a world in which El has all of the blobs in relation to transactions that made it on chain such that when you do a reor you can rebuild those transactions and put them in the pool to do so if on new payload CL inserted those transactions then they would have them for guaranteed you know even things that bypass the mempool they'd have those blobs available and they could prune them um you know after finality or something like that uh the alternative is instead of the guarantee being all

blob transactions can be rebuilt on a reorg if you just have it all blob transactions that hit the mempool can be built and you don't need to change new payload because El will have whatever it got from the mempool they can choose to Cache those blogs for X period of time or until finality to be able to handle rebuilds on reorg but that that essentially means that anything that hit the mempool can have this quality of service if you bypass the mempool tough luck you need to bypass the mempool again to reinsert I I do think that this strategy not changing new payload not inserting and only being able to have this quality of service to the mempool is very

reasonable especially when you think about full sharding designs when it will it would be impossible for everything to hit them in pool um so it's not necessarily even a quality service that can be that's reasonable to consider but um does that make sense yeah thanks for yeah thanks for sharing yeah so cool cool I I think it at least makes sense for me um this the this alternative one I I apologize I was looking at Peter's slides and listening to you at the same time so maybe this is just me uh having missed something yet but it seems as for

Peter slides that he's saying that you can't reorg external blobs and then it seemed like you were saying that this is fine if you know you basically can only reorg what's been in the mempool so I guess maybe yeah you can remember anything it's a matter of what gets hit back into the middle um I believe at like the last maybe third or second to last slide Peter mentions essentially that you insert the solution is to insert blobs via new payload oh okay got it and so he's saying that like uh okay I guess I just read that differently than you I think okay I see what you mean sorry anyways

am I reading it are we reading it the same name well I'm gonna go and listen to the talk to make sure yeah yeah but the way I read this is like the blob transactions are not fully bundled in a block we are existing block will be unable to resurrect blobs Beacon clients must provide the blogs in the new API calls it reads like a sort of like it's like maybe this has to happen but I'm curious yeah okay that was my I that was the intent one of the intended designs the end of Edelweiss but I thought maybe we had landed on compromise but now I'm I think that we necessarily haven't necessarily so I just want to Bubble it up as a discussion point and to not accidentally leave this sitting for six more weeks

yes yeah I think I think there are also some opinions that perhaps we should just never rebuild these on reorgan just leave it up to the client um a few people right and right not not putting it in new payload leaves it a bit more like unopinionated like the client can rebuild them the ones that they saw but like this isn't a core requirement of the the software but once you put in a new payload it's obviously they still can only rebuild if they if they feel like it but you've just made the like you've broken the the abstraction of it and kind of implied more heavily like this is why we're doing that so my recollection is I don't think yeah

we ever yeah made this decision like we basically never made the decision to change new payload right correct yeah and I don't know if I don't think I did punt on it and I'm just worried that we're yeah we we're accidentally continuing depend on it yeah yeah but yeah it should be explicits it's like we want an explicit commitments to do nothing if we are actually doing nothing especially given that the person there is somebody who has very strong opinions about this um that is not in this call what what is Peter's opinion's opinion that we do do

the full rebuilding on every reorder and change the API to support it or is he okay with the rebuild if you can kind of a road that's my read of the slides I'm now uh I'm now speaking beyond what I yeah yeah but I this this seems like something we punted on and I just I don't want it to accidentally catch yourself guard yeah yeah okay yeah I think we should Loop in Peter and see if he still feels strongly when we're in there yeah so I think maybe the next step here is like yeah I can reach out to Peter and the gets team generally async and we can potentially cover this on the CL call um especially in the case where Peter's opinion is we should change this which

involves the CL much more yeah so I yeah okay so yeah I've made it out of that um yeah I mean fortunately Peter's working on a lot of those transaction pool Machinery kind of heads down right now I think it works fine the the fundamentals don't change too much if it's rebuilt if you can versus rebuild from new payload but yeah yeah let's uh let's pick him and make sure we actually understand his requests cool anything else on this uh one

um kind of idea um on that on that thing is probably CL can do something about it because Seattle will will keep blobs anyway and handling rewards when wrong is happening yeah may just leave some blobs on um I would just say just to know missed and the CL can feel the gaps but I don't think whether it's you know a good solution or not but it's just you know an alternative and it comes from the um consideration that CL will have all bundles um stored anyway so I don't know what

are the edge cases of that as well and what's the complexity will be are you suggesting that CL upon reorgs should have an endpoint to just give them or are you suggesting otherwise no I'm I'm suggesting that the L returns um transactions and some of those transactions will not have laws because El will assume that CL has blows for them and the CL will just you know with those blobs in place in so much cases it might not be the case and the transactions will be left without blobs that's potential issue is this

yeah I worry that like puts like a much more like stateful assumption between the two layers um yeah exactly but uh yeah but CL actually is responsible for where he walks right so it really works from one chain to the other uh yeah definitely that could batch cases and that so it yeah I guess like if you come online you come online at the point of the reorg you won't necessarily have it okay yeah probably so it is really um it makes sense to to have this strategy uh with those that are by passing mempool not

being included in three orgs so yeah sounds quite solid in terms of d a yeah my opinion is that's the simplest it keeps the abstraction there it doesn't put like on on uh it doesn't make any sort of like new assumptions that are hard to hold during full shorting my opinion is that CL is sort of anyway responsible for checking the data availability of the blocks and if CL is sending a payload to El through an F that's a new payload I think yes should assume that CL has made sure that the data is

available yeah and that's the Assumption it's just a matter of like do you want to hand them to the El as well for El to have this like minor utility on reords because CL can definitely provide them ecl needs it yeah certainly it's just a matter of I think worth if it's worth the complexity or worth the uh the load even [Music] yeah I I think your plan's good Tim I

think that yeah okay gather some information to continue the combo yeah and uh yeah we should have at least some we should at least know what Peter meant by Thursday's call well anything else anyone wanted to cover okay uh otherwise uh yeah let's definitely keep uh for it for four specific call in two weeks uh and see if we still need them after that but given all the stuff we have to do yeah give it all the stuff we have to do in the next two weeks probably makes

sense to just have a separate uh breakout for this but yeah I think we can wrap up for today thanks everyone and talk to you all soon thanks