Dencun Interop Testing #34

Transcript

okay I think most folks who are going to join are going to join and we're already recording so let's go ahead and get started welcome to the denune interupt testing call number 34 a couple things on the agenda first off let's chat about deut 10 are there any new updates or developments since we spoke last week on the devet yeah so we've been running like a series of experiments on demet 10 um the latest one has a latency analysis over here so what we did was on the first

version we just have that had that 10 um nothing crazy on it just targeting like three blobs um after we did that we ran the stress test and the stress test included um targeting like six blobs all the time collected as much data as we could then we had the blobber that was sending invalid blobs through a percentage of the network and on Friday we turn that off and then we switch a different mode that the blob ah Hadad which is add a delay of roughly 2 seconds to to roughly 10% of the blobs on the network before gossip and then the latency analysis is the result of that one um it seems like

everything's mostly stable there's clearly edge cases um and I think yeah enrio said he also found something in um in teu and that tends to happen if there's a higher latency for the last blob before the epoch transition so it also makes sense that that doesn't happen very often which could be an explanation for some of these unnatural spikes that we see in the graphs um but but yeah that's mostly what we have on devet 10 cool uh thanks for that does anybody have any questions or thoughts on the

analysis that was done or any client teams want to share any insights oh uh one more thing to add we got the Mev workflow set up on Deet 10 I think every single CL has proposed a at least one slot with a blob on with me on devet 10 um there is an issue that we're still actively debugging with Tac on Nimbus and the relay we're yet to figure out why but yeah I think other than that we're mostly good on on Mev

great we were gonna launch def 11 today but uh because of the new consensus spe change we might postpone that yeah that's kind of what we wanted I guess it'll be a part of the discussion and then we can talk about what the devet cycle should look after that discussion maybe yeah that makes sense to me yeah we leave devet 10 up until probably tomorrow or if you guys can think of other scenarios or data that we want to collect then let us know and we'll do do our best to get that done by tomorrow um and yeah one other tiny thing is the guys from ethereum on arm also took part in testing this time and their arm testing basically shows the same numbers

that we found on our arm testing which is also good news in the future we don't have to bother them um but yeah basically blobs and arm is fine we didn't run any validators but we plan to run validators on D 11 on arm also sweet any questions or comments for clients teams on the analysis any further questions or comments on devet

10 okay next up on the agenda is to chat about this consensus specs PR add bside car inclusion proof doeses somebody here feel comfortable giving an overview on that yeah I can give a small update or summary um so essentially the way that we are doing this before like currently is kind of reflecting um how we handle the attestation goip um and yeah what that basically means is

that you get like all these ball side cars and it's not immediately clear for example if like this message is an equivocation and this change basically puts the sign beacon block header in the side car as well so now you get slashing security and yeah I think everyone is pretty much in agreement that this is the right direction to move in uh does anyone have any questions or feel differently one thing I would add is that I um started um implementing it over the weekend and um yeah I will say besides I I guess as we do more testing

right thanks to thanks to of the blobber testing that we realize um there is some concern with equivocation blobs because they come for free and there could be splitting attack with a with with with the fortres with that and they just a bunch of unknowns moving forward right and this prevents that aside from that is that it does make the API interactions much cleaner and this both Beacon API and the Builder API because you no longer have to sign blob it also makes the validator client implementation easier we don't have to implement um a different endpoint for the web resigner so that's also a plus so I think overall it's a really big

Improvement because it basically it basically enables a cinical on the client side I also agree and think that this is a good uh addition because uh again there is lot of blocks or content handling that is sort of a Cod spaghetti we have out there and this will totally get rid of that as well as uh it makes sense to link the blobs with the block yeah um so the previously a couple of calls ago I brought up like an edge

case that have like bricked import on Lighthouse and had to do with like essentially constructing a blob side car where um your block route doesn't actually contain the kyg commitments that you claim it contains but then you can like propagate these across the network and I can tell whether they're valid or not um but you can't do that anymore if we include the block header so on top of like elmed or like adding the um equivocation penalty it's also we making like this construction of uh inconsistent blob side cars um like you

can immediately identify it's invalid um so that's another big plus for this change um and with regard to like all the apis like they are all cleaner but I will say like they are all going to have to be changed so that is going to take like a bit of time and coordination so that is the the drawback of making this change but I think it's worth doing anyways yeah I agree because it just makes everything a lot simpler so it's easier to get right and also yeah basically just makes the whole CS of security much

better uh in the pr was mentioned there was some conses too because this was considered before as well and was not adopted so I would like to hear what were the conses I think the people who would possibly be against this are not on the call so that's a little tricky was this specific um idea of having the header with the proof proposed before CU I mainly just remembered the discussion about

including the blobs with the block combining them together okay I guess we don't have those people yeah I mean it would be good to hear what the cons are I mean I will say that I think the original thought here about separating this from the original block propagation was this idea that it would make it a bit more forward compatible with another data

availability standl solution so you wouldn't need to modify the block the be block propagation at all if you were to then add you know full DK shardan at a later point and I think that having a separate message here and having the blobs proof doesn't really affect the normal beacon block propagation that much anyway so it continues to adhere to that principle that that we were trying to design for but if this was was thought previously it would yeah it would be nice to hear what people thought negatively about it back then so maybe by the end of the day those people somebody could ping those people and have them share their thoughts I know we heard from I think three consensus

clients did teu or Nimbus thumbs up this also okay yeah I think there was just like a little bit of reservation from nimus but I'm I'm not sure they like thumbs down or anything I just haven't heard much feedback yeah I think te is in support of it okay it seems like it's pretty overwhelming support and if the main downside is that this is going to take a little bit of time to get implemented and update all the apis I think it's the cost we have to pay for doing doing the

the robust thing so I think Danny will wait until the end of the day to see if there's any additional questions or concerns and try and cut the spec with the update in it yeah pce cannot hear you if you're speaking uh all right pus

just pop in here whenever you get your mic working again any other thoughts on this otherwise we can talk about devet planning going forward well can we talk about just like just I think like the beacon API and the Builder API are probably the most critical path here they will take the longest to back out and perhaps the longest to implement as well so do we have like owners in those area and besides that we should also alert the relayer as well I'm not sure when the next MB boost code is but yeah they also I suspect a lot of like most of the

changes will be on their end because now they have to add this inclusion proof to The Blob side card which before they were just kind of like they don't have they don't have to do much but now they have to do slightly more so they should be alerted as well so I can take care of the Builder specs updates and if let's see uh I think the relay specs are fine and yeah I mean there's a little bit more that the relay will have to do but also I think this is like such a big Improvement at the CL that it's just going to happen and it's really not that much extra work

I think I have a microphone now uh so I can clarify a little bit hello so so the the this this thing of mentioning danrad just came up with a private conversation of myself and yac and uh he mentioned that this was thought of uh so since I am just a third person and I wasn't there in the first conversation I was just paying either thatr or Y can just clarify this if there's any reservation as for the Relay uh I I do expect that this change is going to take us in a in a position it's going to put us in a position that is slightly more complicated perhaps because we're going to need to test with them so as of today we only make one block we can make it in

parallel and we make only one object that we build and we may or may not use it with a builder and we can just quickly swap a payload and put it in that blinded block with this change I think the path with the relayer is going to be quite different we're going to send back the sign header and then the relayer suspect is going to build those side cards The Blob side cards so clients will have to keep track of a bunch of objects on your local payload you're going to have to have your locally built side cards with their own proofs that you might never use because the Builder is going to send you those

anyway but still just to be prepared you need to like start building a bunch of things in parallel that we currently don't do uh so I think this this is going to take some time to so I'm just Echo what echoing what everyone is is is saying this going to take a long time actually to to produce but it's a very good change sorry I don't think I quite understood what the difficulty on the relay side was it the way I understand it is that you're saying that the seals would have to be building proofs that they wouldn't normally be doing right now well so yeah so typically what you do is you build a block locally and you wait for the Builder's block at the same

time and you typically you just ditch your local block that you just use to compare values to compare whether or not it's better for you to use it or not but typically you just ditch your local your local block uh now we're going to have to be building the local block and proofs for the blog transactions that our local blocks might use and just keep this and also build this uh send assigned header to the relay and then the relay is going to have be responsible for building the side cards uh so there's many more objects that are going to be like having to be built in parallel that we currently don't

do and is the concern processing or is the concern just implementation and comp it's just it's just complexity of implementation and testing I me we're going to have to have a lot of unit tests and a lot of like hype test it's going to be work for everyone and I think everyone here agrees that in in the long term it might take us one more more but in the long term this is a much better place to be but CL can also build the proofs for the Builder site cars and basically send it over to the Builder so Builder doesn't really has to do anything well that's that's kind of hard right because you don't have the blocks so I mean if the so that's going to require one extra round of of

communication The Bu the CL doesn't have the blobs for the Builder's payload so what's going to have to happen I suspect that the best the best way here is to rely on the relay to build those proofs because the relay doesn't want to have one extra round neither with the builder nor with the the proposer and since we are relying on relaying on the Builder to do this then I'm I'm sorry on on the relay to do this then I suspect that this is going to put us in a precarious situation where we need the relay to be ready to be testing this which is something that is been bugging us on every PK uh but Builder can still uh give the blinded side cars uh like how they doing

get header right now right so that's that would be another way so that the Builder uh the the the Builder sends everything to the relay the relay could send the proposer everything for the proposer to propose but that's not going to work so I I think the right way of doing this is going to be as follows the Builder is going to send everything to the relay the relay is going to send the header to the proposer the proposer is going to return it back signed and then the Builder is going to assemble everything on broadcast I'm sorry this relay is going to assemble everything on broadcast yeah so poas uh like relay and proposer

can do this both at the same time in parallel so the kcg commitments are sent from relay to proposer because they need to make the block and then that's all they need to make the proofs so there's no like blocking on getting the Bobs from the relay or something like that it's really just a question of like I agree okay I don't think it'll be that bad I just wanted to add right we do this today already we we we we we basically build the local blobs and then we try to sign up Builder blobs both are happening in parallel and if the Builder bid is too low or or the override flag is enabled true then we'll switch to

broadcasting the local blob so that's not much difference from this perspective that yeah and instead of signing we can we can again just build the proofs for the Builder blobs and send them to the Builder when the time is to submit blinded block yeah definitely it's much better this thing that we're only signing one message now do we know who the beacon API owner is because I figured like majority of the changes will be on the beacon API side was that a you volunteering to be

the owner [Music] Terren I'm just kidding I Wasing someone's more competent yes do this uh I I can I can volunteers tribute to a make a PR at least all right you headed here first everyone um okay what what's the next steps I guess for putting all of this together I think let's just assume that this is

uh this change is accepted into the spec we'll give it to the end of the day and let Danny merge it but assuming that does happen where do we go from here what kind of Target are people feeling for getting back into the um devet cycle is this two one week two weeks I mean I think the first first thing is we have to like get the API changes up and like have discussions around those and then like once we agree on those we can Implement them so I feel like it's like at least a week

or two for the specs then a week or two for the implementation and then at that point like try to test it on devnet okay we have a I sort of agree because I mean the more important change and discussion that we seems to require will be on the Builder side and that is something I think is more contentious and has more design uh options if that's the case would we uh be okay with just getting rid of devet 10 because it's way too big to just have running for that long we can have devet 11 that's basically the exact same thing

um so not including any of the changes we spoke about just now um and then we can leave that running until we're ready that sound okay Dev Nets can still be used for latency kind of analysis and I don't think we don't we need a new devet for it so sounds good do you mean compared to devet 10 because I mean the main reason of getting devet getting rid of devet 10 is it's expensive yeah I mean if uh basically expenses can be brought down for DEET 11 I think we should go for it else let's continue with devet 10 and sort of get the latency thing also figured out yeah

sounds good uh we'll do that and just one more question is there any value in doing Shadow Fox at this time cuz that's also I mean it's again a a cost thing it's not an effort thing we can do a girly Shadow for this week if there's something to learn from it or would it be better to just wait for all of these changes and then do it later on I think we should try just one Shadow for okay so we'll do a girly Shadow for just using the exact devet 10 images yeah does it make sense to wait for the shadow Fork once this Bon API is merged

in like I I I would do it post Dev 11 there's not much Point doing it right now in my opinion I think we should do it even before definite 11 so as to get the familiarity with if there are any other uh you know issues out there looking yeah we'll get one up this week and let you guys know that okay so the timeline now is uh

tomorrow we going to shut down that at 10 and launch devet 11 that will be running for the next two or three weeks then have themet 12 to test out this new uh Bon API then uh probably reconsider timelines for girly Fork after that that seems to be the consensus right now we do have a consensus layer call this week on Thursday is there any chance that we can have some initial stabs of the spec ready to discuss in

that call uh I think so okay that would be good and I think yeah that would give us some time to discuss some questions and concerns synchronously and hopefully sometime early next week maybe get them merged in custom releases and then get people to start implementing them and we will just see on the next uh I guess yeah we'll just take a take it uh next week and see when we want to start targeting devet 12 but roughly thinking like on the order of two to three weeks from

now yeah Dev connect is in two weeks so we'll all be in a building that Tim will find and provide they will bring us food and water and we will be working on this I think okay is there any other things that we were hoping to discuss on this call it sounds like we're everybody's pretty Pro this modification to The Blob sidecar message again we'll wait till the end of the day and I

assume Danny's going to merge it but just to give the people who might be dissenting some time to share and try to have some specs ready for the Builder and the beacon API by Thursday to discuss cool we ask questions or comments before we wrap up okay thanks a lot everybody I'll talk to you on Thursday thank you bye bye see thank you thanks thank you

bye