All Core Devs - Consensus #124

Transcript

[Music] [Applause]

h for

e time

J

Danny Ryan: okay we should be live welcome to all C dev's consensus layer call one24 this is issue 922 in the PM repo light schedule it seems but we shall see uh we'll quickly talk about denb status testing Etc a server side event being discussed uh for the block and I think how it changes INB and then open discussion from there let's go ahead and get started denb uh General testing and devet updates I think I saw new client

pair syncing

Barnabas Busa: yes uh so devet 12 is now onboarded all the different clients and all the different client combinations and we currently have prism thinking to the Head uh we didn't want to enable checkpoint thing for that because we wanted to go through a genis thing uh just to be able to make sure that genis thing still works uh we have uh enabled M for most of the different CLS except for prism at this point and uh everything seems to be on track

Danny Ryan: cool so um there's just one

instance of prism or was that many

Barnabas Busa: so this morning I have added all instances yesterday we added one with gu but now it's with all the different

a

Danny Ryan: cool and other than MB are we kind of putting the test not through the ringer is it moderately kind of just stable functionality right now

Parithosh Jayanthi: a little bit of stable functionality for now um there was this one Lighthouse bug with uh me for local payloads that's beenin fixed and just patched I think like an hour ago um besides that there seems to be an issue with um one bzu

node we're not particularly sure how it got to the state but um it's trying to convert an invalid block to a valid one um so maybe someone from bz can have a look at that one

Danny Ryan: what do you mean by convert

sorry as it question goad

Justin Florentine: no I was just agreeing with Danny that's a good question this is BAS Su team here I'd like to hear more

Barnabas Busa: uh we have put all the error messages in our chat

Justin Florentine: I've got those thank you

Parithosh Jayanthi: uh with tldr there was uh could not persist world for root hash for a

certain block and then I think B tried doing that like twice and then I guess the note restarted but at that point uh teu then says cannot change node validity from valid to invalid sorry from yeah from valid to invalid and then TECO get stuck as well

Barnabas Busa: we started another s in a totally different machine with the same uh pair also on arm and uh it passed by that uh block so it might be just some corrupted DP element

Parithosh Jayanthi: yeah could be that's why we're still not sure how we got that node into that state

Barnabas Busa: um we used to have blobber running on it and Lighthouse

validator so it's a bit different than what you would normally have

Danny Ryan: are we purposely sending bad blocks or not

Parithosh Jayanthi: uh not yet we need an updated uh B we don't have one yet

Barnabas Busa: is anyone from prison can confirm that we should be good to go with the shadow Fork

Terence Tsao: yeah we can try it we the only thing I did not test is the Builder path for the proposal but given that there's not much change since the last um since

the last commit I think we should be fine there but do let me know if you see an issue at the same time I I will also monitor the setup

Danny Ryan: yeah Terence it might be nice to have some color on you know is this prism sying and but needs a lot of work or is this like prism getting close to what youall feel like is stable and you know might need some iteration but isn't

Terence Tsao: wait I'm sorry um is there a sinking issue

or no

Danny Ryan: no sorry I just meant like prism the the thing that we currently have on testnet is that like prism is working but there's a lot of kind of

productionizing doesn't need

Terence Tsao: yeah yeah no so right now we're missing the only thing we're missing is basically bad feeling blob and some and then more verification check on the on the sinking path the sinking to head but other than that it's pretty production nice

Danny Ryan: yeah cool any other questions or discussion points on the devnet any other testing related

discussion points

Mario Vega: I haven't run the hi uh test for prison but I will do as soon as possible and just report but I think we can go ahead and prepare for the shell Fork if I find anything I will res it immediately

Danny Ryan: cool yeah anything testing a devet related other than

okay uh dline did raise two points it looks like the former is merge which is

adding proposer slashing and a tester slashing to the server side event um so D line we don't need to discuss that right

dapplion: yeah first point issue 376 it's close so I think that's fine if there is any objection just do on the pr itself so let's go for Point number two yeah cool issue 349 this was originally raised by paros so the context here is them and we're not sure if other consumers are using the SSE events for timing data they and we are aware that this is not ideal but that's the best

they can do at the moment when we add blocks to the mix if the event is emitted after importing that means waiting for all the blobs so now the data would be heavily distorted so the discussion is around should we change the event definition such that it is emitted after CIP validation or at some timing data or if anyone else wants to provide any other option for timing data via server sen events that's the context

H yeah okay

Danny Ryan: just to clarify when we add blobs the point at which we would admit

this event might be delayed even more because where the dependencies on the network and so it deviates further from when you actually receive the block on Gossip which is a valuable piece of information

dapplion: exactly so okay I can I can W up the discussion so far I think what what seems the easiest option is to emit the event after full import but attach a new property where it's a seene timestamp at where each client has perceived the

event it's not incredibly important for that definition of scene to be uniform across implementations because um at least you have the Bops they do correlation timings so as long as these timings are consistent within an implementation it's fine and this seems to satisfy all concerns

Danny Ryan: okay the alternative that you originally suggested was two separate events rather than bundling the timing into the previous event

dapplion: yeah so we could have an event after goip validation a second event after full blog import

Danny Ryan: but you you think the additional field is the better path right

now

dapplion: with the current requirements I think yes because it's not clear who really wants this blog gossip event except people timing data and if they can just get it from this one event then it seems simpler but both options would work

Danny Ryan: right yeah enri we can barely hear you uh it sounds

Enrico Del Fante: sorry maybe now it's better yeah um yeah I was thinking that adding

the time stamp in the in the in the data itself would be better for two reason one is one is that well this event can be can be can be uh served well with low low priority so it doesn't mean that when you receive on the other hand on the other side the the event itself it is their correct timing and also adding another event that says this is when I received the gossip this is when I imported it maybe is just an overkill for the use case that we are thinking about so maybe it's just easier to leave things like our now just adding uh the um the arrival the arrival

attribute

Danny Ryan: and is it is um I know you said there can be a little bit of inflation detail on that the definition that time stamp but will it be defined as gossip validation conditions have been completed or is there ambiguity on whether they could be pre-os that well

Enrico Del Fante: currently we we take all so the the arrival before the gossip validation so it's more it's closer to the the real message arriving over the wire but I don't know other clients

Danny Ryan: real quick and then we'll go to Sean dine do you do you intend to

specify if that's pre- or post executing the gossip conditions like immediately upon wire or otherwise or do we not care

dapplion: I'm not sure I'm on the fence I think whatever is easier for implementation to be honest I think for this use case it doesn't matter but it would be good to specify it yes

Danny Ryan: Sean

Sean Anderson: uh so maybe I miss this but if we're thinking of just submitting an event when we import a block would we then like not get any indication about what happened to gossip blocks that we

didn't import like some a block that filed consensus somewhere or wasn't available maybe like that would be a reason to maybe have two events

dapplion: right that's that would be the point of having the second event um there has not been demand for that we can add it but it's like a a bit of a scope grip for this specific issue

Danny Ryan: you could also put a May Adit upon block failure at any point in the pipeline um or must I don't see how it prudes in a failed

book

dapplion: I would say this event carries the idea that this block has been fully validated if you break that assumption at least you should indicate that done stream somehow

Danny Ryan: Sean does does Lighthouse emit inv valid blocks right now

Sean Anderson: um I'd have to check I I think yeah I don't know if we if we do emit events on Gossip box then that would mean we would potentially be emitting events on invalid box but

dapplion: I'm pretty certain at least you guys me the event at the end of the import so definitely not right

Enrico Del Fante: I think T has has recently added

an option to also emit the event um before import I might be wrong but I remember something like that but this is an option that needs to be enabled otherwise by default is emitted uh afterwards

Danny Ryan: are there any further comments on that do we have enough information to keep moving um with maybe a suggested PR at this point

dapplion: in my my view it seems we

should first figure out if there is a use case for Consumer of events to learn about invalid blocks if that's the case then maybe we should consider the two events or extending the event in that way otherwise seems that we should go for the time stamp property anyone opposing

Danny Ryan: does does valid SL invalid or valid true false property also satisfy this use case in the event that we wanted to have that use case

dapplion: as long as so if if we have a single event with valid property and the the time stamp yes that satisfies the original

issue I think that's that's all from me

Danny Ryan: all right thank you all right cool Sean added a couple things let's do um that PR 3561 first Sean if you want to give a quick explanation

Sean Anderson: yeah sure so I just noticed the gossam conditions for Globs sort of lead to some uh I guess like unexpected uh

consequences um I don't think it's like negative or anything it's just if you were for example using the beacon API with the broadcast validation of Gossip um it might be unexpected what messages were valid and invalid and the reason for that is because technically it's okay to gossip two blobs with different blob indices that have slash headers associated with them um so you're allowed to gossip those but you're not allowed to gossip them if they the same blob index um so initially I was thinking maybe it'd be easier to just sort of

disallow gossiping of any block or blob message that's like quote unquote it's flashable um but then Danny brought up the point that we don't necessarily like elsewhere we don't look between different message types to try to like cross validate what should be sent so what we could also do is just think about this um like slash ability within any blob index that would make it make somewhat more sense um and then yasik also brought up the point of we could instead just allow propagation of Slash like block blob

messages because you're more likely to gossip to a node around a slasher in that case um and I think the final Point Danny brought up was we could sort of do like a hybrid thing where we're we propagate slash messages until like a slashing has been seen on Gossip um yeah that's that's the general tldrs

Danny Ryan: yeah my suggestion at the end is like you do want to reduce how you know how easily a message can be gossiped um you know from in to one hopefully uh

meaning like you want caches or something to make it difficult to send repeat you know in messages once you're willing to be slashed uh and so you know if you're instead monitoring for a slashing message in relation to the message then you know you can you can drop um and that can be either you created the slashing message if you have the faculty to do so or you've seen it because somebody else saw it and created message um what are the consequences of doing nothing here

Sean Anderson: I don't think there are

consequences I just personally found it confusing when I was like trying to implement the broadcast validation function in the beacon API you can is like you can have messages that are like you get messages to this end point with like all block blobs and the block so like that message can be slash but like you would still technically like publish all parts of it and return to2 so I thought that was weird but I don't think there's anything like uh any detriments apart from it being somewhat unexpected in my point of view I think my like personal preference I

guess would be to I don't think we have to make this these changes for Deb necessarily but uh at some point having like clear rules around how we should handle slashings and maybe allowing them to propagate further I think that'd be fetting

Danny Ryan: right I suppose there's also the option to upgrade this after DB launches with thinking about the analysis of does that put us at like Network partition risk if

someone's willing to spam SL messages um I guess my my preference would be if this is cure but leads to weird or confusing scenarios that we take a minute to think about how we want to do this kind of holistically uh rather than changing this back at this point but if it's insecure then I feel otherwise

Sean Anderson: yeah no I think that sounds good to me

Danny Ryan: okay I would propose maybe towards mid mid late January um if you or anyone else has like a a design they want to propose and

feel comfortable with um to pick it up then cool are there any other um further comments on this one before we move okay next up Sean uh I do not I don't want control message

Sean Anderson: yeah so I'm not super familiar with this change but I believe it can be used as like an optimization and gossip

to reduce the amplification factor I think it's because you can like tell modes not to send you a blocker app BL we've already seen for example um and I think both age and yasek have looked at this and then Anton uh raised it but I think we're waiting for consensus to merge it or and perhaps for it to be moved along a little bit more but I think it's something that's useful for DB and um people looking to implement it possible

Danny Ryan: yeah and this can also be kind

of upgraded transparently I believe I guess the problem here is if the P2P spec maintainers want it like bundled in a big one version one two um I guess even if it's merged sensitively we could potentially start using it uh and I believe if I remember correctly this helps more when they're large message sizes than smaller um meaning you're you're more likely to kind of reduce the amplification Factor if there's slower larger messages being sent around rather than tiny messages or maybe more like

attestations I feel like the assessment was that it wouldn't do much but it would do a lot for

for

Sean Anderson: I don't know enough to comment but I I think that is the case um on the pr it says this is reduces bandwidth by 30% seems pretty good

Danny Ryan: yeah I just left the comment that it looks good um I'll try to hit up vizo in a separate form as well um I mean at a certain point if we

want this we and we're blocked on Li PDD spec maintainers we're going to have to figure out a different path um so let's see if we can get this moved along in there and uh have the conversation on the next call if we cannot okay and M did Echo that it makes sense uh for large messages only thanks

Sean okay those are the only um items that we have on the agenda for today are there any other discussion points okay uh uh call schedule um next consensus layer call is in between Christmas and New Year's I will not be available I do not intend to host this call um I was thinking if there is demand for a call it could be labeled more of kind of like a testing and kind of devet check-in call if there's people that want to get on a call on that date um is there demand for

that let's see one heart emoji

Tim Beiko: we can also decide this so next week we should have uh award devs so on the 21st we can also decide this uh then um because this came up as well on the testing call Monday where the next testing call is on December 25th we're obviously going to cancel that so yeah I think if next week people feel like we should have something um yeah we we can make that a sort of combined call

Danny Ryan: very cool so if we do do something on that week it would be at the 2 pm UTC slot on Thursday um it would not be a a full all core devs but anyone that is working on dev Nets and

things on the holidays and wants to check in or or or chat about anything um we can make that decision in one week on whether we have haven't host that and even if uh the decision is no people can certainly jump on the Discord drop a call link or jump in some of the audio chats at that Okay cool so we will have acde in one week um and if there's any further things to figure out on calls we can do so then all right any other uh discussion

points for today great well uh talk to you all next week on acde and um you know enjoy the the end of the year take care

bye bye byebye thanks by

than

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