All Core Devs - Consensus #121

Transcript

[Music] Jesus

[Applause] w

for

Danny Ryan: okay

welcome to Alward dev's sens layer call 121 this is issue 898 the PM refill uh a couple ZB items um which will probably have some things that Ripple into how we discuss testet plans um and then a an item around SSD spec from yasc okay uh if you haven't been following the repo or for the discussion uh that's been a bit in Discord um we've onone back and forth on the proper way to do blob side cars um or at least ever since the split um there was an

additional signature put on the side cars by the proposer that serves as um at least the reduction of the Dos condition of the Dos ability to essentially just the proposer um there's always kind of Laten concerns around if this was sufficient if we needed slashing additions on this new message type um if this could increase the ability to do view splits um and timing splits and and short-term forks and and reorgs and me and all sorts of stuff um and the stream the stream hasn't started uh interesting

I am streaming give me one second let see if I can see if my stream key is off or something

are you stream to call what

Danny Ryan: no apparently my green key is also being used on the testing call so it went to the wrong call yeah Danon interrupt testing is live um okay we'll rename that sorry everyone okay back to the Soliloquy on

lob side curve hey man I don't know that's my key someone reused my key um Okay cool so uh we went back and forth on this um this has also kind of created uh tough gossip conditions uh where you're trying to remember what you've seen uh but also conditionally upon have you seen the block um or not when you're making the decisions on the gosip network um I believe that most of the issues that we've seen on the dev Nets um in the past six to eight weeks have been in relation to complexities around handling these

messages when to invalidate them how to invalidate them what to premise those invalidations upon um so we're talking uh with some of the prism guys one night who were not pleased with the design and and even tossing around potentially recoupling um and Franchesco I woke up to Franchesco saying well why don't we just send around the block cutter and a and a proof um which I think once that was said allowed most people said oh yeah that's a better design you don't need to open up the VC for an additional signature uh you those messages you cannot send redundant versions of those messages

duplicate versions of those messages with different blobs or commitments if unless you're willing to get slashed um and you don't have this uh potential race condition where you might have the side car and not the block or at least the block cutter um so you don't really have like conditional the same type of conditional gossip conditions um so we have a pier up I believe L put it up 3531 that we've all been going back and forth on iterating on um I have asked for any Nays in relation to this um and there's been a little bit of discussion but it doesn't seem like any outright Nays um I believe this will largely be the removal of code from clients um and

especially in a what proved to be a pretty complex Hot Spot I'm getting right um obviously there are implications here in terms of relationship to getting Deb out in relationship to what devnet 11 12 you know look like and when they are um but it also from my assessment looks like a much it it could actually be the same time to main net because this is simpler to get right and we're not going to have as bug ridden Dev nuts um it's also almost certainly going to give us a safer main net um because it's a simpler and more easy to get

correct specification um so I guess first of all I'd like to hear are there any uh anyone against moving this forward getting this into the spec ASAP likely doing a release in the next 24 hours um and kind of recalibrating uh the software and evets from there um and then assuming after we have that conversation we can get into the um there a couple of little final points in design that I'd like to just make sure we're Onre um okay but again I've heard we've heard positive generally from everyone

I'd like to hear if there's any any negative please voice now okay cool and there's a PLL request up for the Builder specs and there's a PLL request up for the beacon API um if that is in your domain of review please please take a look at those okay um I know there was in chatter in other places maybe you know worth having the conversation of why did it take this long to figure a better design out um

and let's have maybe have that conversation but let's let's get through what we need to get through today first um this the the simple answer is well we hadn't talked to Franchesco or Franchesco hadn't truly parsed what we were doing and hadn't had the idea but uh maybe there's a better answer than that um Okay cool so there are a couple of hending items here Mikel looks like we're like deriving a depth parameter but then not really using it and we need we should probably simplify and remove that depth parameter is there any M did I get that right

Mikhail Kalinin: yeah I just think that if we don't use this constant uh I mean like in deriving the depth um yeah then we probably don't need it or if we have this you know this perimet defined so we have to we should probably use it instead of you know comp Computing the depth from G index and I think that sway said that she's agree with that um yeah so we can just make an adjustment I think it's a small thing really it's kind of like more uh yeah it's more aesthetic side of things rather than yeah it's a small you know mly to small discrepancy so I would not like we

can fix it in a separate PR whatever

Danny Ryan: all right well let's just fix it there get it done uh poas do you mean that even if the spec does not define the depth you're not going to amly compute it for regardless but do you even in that case do you think the spec should have that constant okay I'm having trouble person you don't allow me to unmute but um this seems like a personal problem um

okay cool uh regardless I think that chwe agrees um cool um I guess regardless we shouldn't have the Conant that were not being used so let's go and um clean it up one way or the other okay um M was that was that the the LA your final lingering point or is there anything else

Mikhail Kalinin: was just yeah there there are there is another constant there is a parameter that defines depth and there is the constant that Define G index so

and this constant is just used for computing the depth like it's not like actually not Computing it but just in the comment uh which explains how the depth was computed so I think that this can be removed I don't know um yeah because we're Computing these G index uh during the run time using the function I know what clients will do actually probably they will as B said define this constant in the code anyway then it makes sense probably to leave it in this back

Danny Ryan: okay um so you're this this is kind of the secondary question is should we dynamically compute the G index or should we Define it up in in the

constants right

Mikhail Kalinin: yeah

yeah um I'm

Danny Ryan: I guess all these questions are athetic questions um I I don't feel very strongly um I think it's kind of nice to be able to talk about independently but um matters too much I guess let's both make sure we're we clean up both of these and in at least a consistent way I I see that you're unmuted the only thing I can do to you is mute right now

oh now I I'm muted oh

thanks

Danny Ryan: you got anything is there okay um these are both aesthetic cleanups let's just make sure that uh they were moderately consistent and um Casey had one more well first of all Casey did point out that we must uh and this is definitely an oversight we must link The Blob to the kgd commitment to so that the blob inherits the consistency of the signature of the block header um so super good call on that otherwise anyone can mutate these messages on the P2P and they'd still be valid um so that's in

there uh he did bring up one more discussion point on uh if you're doing a side car by range or side car by rout check that you should also verify this consistency um and that is accurate um I guess if you're putting things into your like verification pipeline uh you will do so but an early uh kicking out of bad messages is probably a good call um well on the buy root requests you like have the block and so I wouldn't put like a must or even should on the calling of this Merle proof because you can just look and see if it's correct um

but nonetheless I think we could add on both of them to do a consistency check um so I'll take a look at that right after this call

um one

Mikhail Kalinin: one question here is will the clients use the blob site cars by root by wrench um like without a block without having a block is this supposed to

Enrico Del Fante: yeah I think we we we do uh so if we are kind of um haven't seen anything um so we actually try to get blocks and blocks to get blocks and blobs together and ask for everything

even without knowing the blocks so we know that at some point the the pier will only return the blob the blocks the blobs that are in the block but we don't know in advance the the corresonding block

Danny Ryan: yeah it's like you definitely can paralize by range if you're syncing um and then make sure that both streams kind of match up to each other the other is um I guess these cases where you see a random route in maybe you're recovering the block but you also might want to recover other messages in relation to it

Enrico Del Fante: um yeah it's definitely applied only to to to BU root I say the by range should be

different

Mikhail Kalinin: yeah if if if this these two RP calls I used sendal on to blocks like not complimentary to blocks then it's probably worth verifying validating the signature because after this will have a block header in the blob site car so this request will return block headers as well and yeah right so the proposer signature needs to be verified as well it depends of course on the use case

Danny Ryan: yeah well and and and the um kind of implicit is anytime you get one of these side cars and you've either gotten another side car with the same

header or you've already gotten the block when it says verify the signature you also just know that you verified the signature before um if it looks the same but uh I let me do a pass on both of those and just make sure that we're tightened up and consistent um both in relation to discussing the proposer signature as well as the consistency of the commitments in relation to the one

yeah I just want to clarify one thing like you can obviously verify that the commitments you know apply to the the

the blob without checking the proof but it's more that you you would have a side card propagate one way but not the other so it's more of like a network view split concern I don't know how big of a concern that is that's why I brought it up

Danny Ryan: I see I see see so you're saying the same mess like you could if you're not actually verifying that mercel proof someone could be sending you like a totally different message because they could just have junk in the uh and and that would have not propagated on gossip but would have propagated in the root and then all of a sudden in relation to message IDs and stuff you have totally different messages coming in

even though they're valid

okay yeah in the proof yeah yeah yeah yeah

Danny Ryan: yeah it's probably worth making sure that's just missum Terence

Terence Tsao: yeah um So currently there it's sort of like a minor dog concern with The Blob carard in the event that you don't see the parent block you client may choose to insert that into a painting queue and process later when you get a when when you when you get a parent block so that part if you compare the Block versus the blog side card the block actually does the signature check before you do the parent check versus the blobs side card you you don't do

that you actually do the signature check after you do the parent check because of that right it's actually fairly easy for someone to constru blide car without valid signature and just kind of Doss um the Quee if today client implements that Quee yeah so that's something to watch for I I can I can leave a comment on the pr

Danny Ryan: okay and this is if you're reading the conditions sequentially you would prefer the parent sign the signature people before this conditional

Q

Terence Tsao: yeah just like how the block does it today

Danny Ryan: yeah all right cool yeah if you can drop a comment there so we don't miss it

Jacek Sieka: that said I don't think anybody

implements those rules in that order because the order in the spec is odd with regards to cost

Danny Ryan: we've talked about this before yeah there certainly there's an attempt to get the easy checks that invalidate things in relation to others before you do hard work in the order but uh obviously the real world assessment of that is probably different than as

spe rers

Jacek Sieka: yeah and there's a different there's another well it's not really a concern but um if you do ignores before rejects you might uh not dcore a client on what would have been a reject if you first ignore it

there also like little uh differences like that if you depending on the order of things

Danny Ryan: nonetheless I do agree the attempt to if someone can make you you do like an asymmetric work like filling up a queue if there's a condition that would prevent you from doing so having that before probably a better way to write it

Jacek Sieka: you know the Q should be able to deal with it otherwise you haven't predicted your

Q yeah

Danny Ryan: yeah fair but like do you want a proposer to be able to fill your queue

or do you want anyone to be able to fill queue

Jacek Sieka: depends on the other costs

Danny Ryan: okay all right well at least drop that comment in their terance so we can uh look at the configuration of that in relation other things um I believe that we can get this merge in the next few hours um and I believe that we can get a release out tomorrow cool all right any other comments on this

Alex Stokes: can

I ask one follow-up question since the relevant parties are here uh for the Builder specs so there is an open question uh essentially who computes these kcg inclusion proofs if you're going to a m relay the way the pr works that I linked right now um it has the relay compute them independently with the proposer instead pretty easily the beacon node could pass them along in the API does anyone have any preference here or see one way being better than the so I think it comes down to will the

beacon node want to compute these proofs sort of optimistically because it would essentially send them well actually no so if you send the block that's kind of a done deal so then the question is just is it easy enough to make those and then send them along as well and then the relay has less to do

Gajinder Singh: I would prefer that Beacon node compu the proof and Tes along

Alex Stokes: okay

Danny Ryan: any other preference here

Alex Stokes: yeah if anyone has any comments just take them to the pr I suppose

Danny Ryan: I guess one thing is like the

node is going to have that logic so that the node can locally build um so leveraging the utilization of that logic from the node might make sense

Alex Stokes: right like the Rel will still verify these proofs but it's like one less thing they have to compute and keep track of and maintain and debug and all this um I mean originally I made the pr with it you know where they're done independently just because it couples them less but it feels like it's better just St beon do it

Danny Ryan: what's the structure passing those brost between the beacon node and the relay like

Alex Stokes: they would just be stapled

onto the side line of beacon block

Danny Ryan: okay just and some ad hoc the ad hoc data structure they're not like actually trying to compute like utilize the network data structures okay

Alex Stokes: I don't see a reason to

Danny Ryan: actually may me feel a little bit differently about how it than I just said but um it seems weird to pass like a small portion of a what's going to end up being a message that the relay is going to have to like verify and package into a larger message anyway

when the relay has everything to just create the whole message the message being the side um but I I don't know I don't feel very

sh

Alex Stokes: yeah I mean the thinking is just give Reay when last thing to do because the beacon note already have this code it'll be tested debugged all that

than C just go bit I

Danny Ryan: all right um any other comments on this very cool uh anything else on this spec

change Andor things in relation to the spec change all right um there's a longstanding PR in which at least a couple of clients have implemented on my main net this is 3034 allow honest validators to reate blocks uh this has come up on discussion quite a many times it seems that the clients that have nothing with it are have not because they want to see it on uh in the spec um and there's been a push to clean up tests and other things in relation to it uh and so the question I I I also believe that on this call

we've done a signal of like yes merge um I'm doing that one more time because it has been cleaned up and is in a ready to merge State um is anyone on a no merge relationship to this PR brow could not be here but also signal as the author um that he is ready and comfortable for this merge

Hsiao-Wei Wang: um I think I can push the minor

uh constant change like right now so we don't have to open another PR so just wait a couple minutes to make the CI pass

Danny Ryan: which I'm talking about the honest reor PR now

oh sorry sorry okay got you you're that that one yeah and H this looks it's in Finish point to me

Danny Ryan: cool and this is written as an

optional thing so it can also be a noop it doesn't have to be uh work

um we can at least give some room for discussion on DB test Nets Dev Nets um I don't have I've seen you know estimates of casual estimates of call it three

weeks to to rework um what's going on in the network layer in relation to the spec simplification um is that approximately the signal here uh that that approximately what people think um that we could maybe Target a debet in a few weeks but that we should probably just weekly be assessing Perry I'm not certain um if that

includes St connect week or excluding um I'd say regardless that we are going to be looking at revised estimates for that in the next uh couple calls okay cool any other discussion points around theb around Deb net around testing around uh anything before we move on

Parithosh Jayanthi: yeah uh just one thing we have DEET 11 up it's going to be around probably

till we launch a new one with the propos changes but if anyone wants to Target Target something with testing please target T 11 and curly Shadow for Zer should go live tomorrow so we'll also have some statistics on how long it takes to compute blocks and so on

Danny Ryan: great okay uh y you have a proposal up from September around uh bite type and

canonical Json mapping with an SSD this is pr3 3506 in the consistant specs repo uh do you want to give us the high level

Jacek Sieka: sure um so this is kind of an old PR it dates back I don't know maybe even around main I think um starting from the beginning like um when we were developing ssz it was kind of useful that we had Json so that humans could it um for ssz and then out of that we kind of built tests that were using Json

to uh verify that our ssz libraries were correct and we're kind of past that stage now but I thought it was useful to uh maintain this onetoone mapping between Json and ssz regardless um many binary protocols do uh protuff for example has a canonical mapping um and it's just convenient to document how we do it in the tests uh so that's basically what that PR does it documents how we encode ssz when we want to present it to predominantly humans um in Json in yaml and so

on um initially the pr um assumed that everybody thought that 8 byte 8bit integers and bytes are the same but then there were many Java developers and Json developers upset about that they really think that bytes are different from um 8bit integers so the new version of the pr doesn't change any of that uh it also doesn't change the one thing the one place where we actually use an 8bit number uh the participation flags of the debug State API which is mostly

unused uh there we have a Flags field I'd say that's a bite but for historical reasons that's an integer um so the latest revision of the pr it really only documents our existing practice it kind of takes all the a z type that we have it gives them a corresponding Json encoding and if somebody like the beacon apis spec wants to base their work of that we can drastically simplify the beacon API spec because right now what the beacon API spec does is that it declar is kind of a myriad of little types for every field every field has its own encoding and

that's just a mess uh this one and that that's because the beacon API spec is written such that it depends on the specific object types that we declare later on whereas if we have this canonical mapping if you're writing a Json library on top of your ssz library you don't have to consider specific types anymore you can just rely on these ore ssz types to fully Define um how to encode Json so think not that I necessarily agree but I've removed all points that anybody could disagree with so far that people

have disagreed with from the pr and I think in that version it shouldn't should be kind of a no-brainer to just put it into the spec and then whatever discussions we want to have over Bears um on the relative importance of the bite we can leave them for later that's it

Danny Ryan: any questions for y any

opposition all right I'm going to Ping Discord about this uh and try to get any final comments and then we can need a merch thanks

jie

Jacek Sieka: lovely to get this off my list I hope

cool

Danny Ryan: yeah I didn't I when I said it September I didn't look at the referenced PR that was from 2022 while ago the

original Let's help yic with his list step one little Indian step two just on mapping

Jacek Sieka: at this pace I'm going to have to find like a new like a new Hill to defend

Danny Ryan: I'm sure we can find something you okay uh that is all we have on the agenda for today uh any other discussion points before we close

okay thank you very much um we will work on getting a release out absolutely as soon as possible uh getting these final L points in um and thank you everyone Take Care

Alex Stokes: thank you

thank you by thank you recording

time than

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.