All Core Devs - Consensus #120
All Core Devs - Consensus · 19 Oct 2023 · 1:06:01
Ethereum consensus client teams and researchers meet on the All Core Devs Consensus call to coordinate protocol upgrades. This call covers Deneb, including a new spec release.
Speakers
- Danny Ryan
- Dankrad Feist
- Gajinder Singh
- Enrico Del Fante
- Potuz
- Mario Vega
- Parithosh Jayanthi
- Barnabas Busa
- Andrew Ashikhmin
Topics
From All Core Devs - Consensus, hosted by Ethereum Foundation.
Transcript
[Music] J
h [Applause] w
for all right should be
live
Danny Ryan: hello welcome to consensus layer call upward devs 120 this is issue 892 in the PM repo um I guess kind of as some of the last calls dominantly just kind of checking in on DB various things you know testing evet analysis um if there are other discussion points let me know when we get to the open discussion um okay so first of all I believe most since layers devs probably saw that there v140 beta3 is out um in that is the main net kcg configuration um which is
already baked into ckcg so I don't think it's a much of a change for you to be able to use it um as well as a an additional gossip condition that enrio uh found essentially weren't properly bounding The Blob index uh it allows us to prevent spam of totally invalid messages from being passed around the big shout out to Eno on that um I think other than that there are some additional tests maybe a risk update um but should be generally pretty pretty good and I believe that that uh configuration is to be used in devet 10
does devet 10 exist let's transition or any questions on the consensus uh specs release all right cool
um let's jump into debet update uh first of all does devet 10 exist what's this status
Barnabas Busa: uh so we are waiting when client rces and some PRS to be merged and we hoping to launch tomorrow currently the only uh image that we know that might work on D neton is prism no other uh e or CL team has reported that they have a working image or or a branch yeah we don't need
a full release just a branch that we can use that we can build
what was that
Potuz: are we supposed to use the new kcg setup for this
devet yes
Barnabas Busa: yes
Potuz: we so goand clients cannot unless we coordinate among a go kcg that it's not hasn't included these changes G and
prism
Danny Ryan: okay so it's not a an outer kind of comp configuration and has to be baked in to go
kcg
Potuz: it's a problem with the the the way
that we we have dependences uh G depends on go kcg and prison depends on G so the way this needs to be updated is gokg needs to First make the changes then G needs to point to a Master branch in gokg then brison needs to point to that and then go kg needs to make a release get needs to point to that release and then prison report needs to P to that oh man yeah we probably need to solve this this this is not maintainable any any change in go casg is a pain
Danny Ryan: yeah so I mean one of the one of the major intentions of debet 10 is to use that that setup so I guess we're blocked um we could
move forward and and add G and prism um but yeah
Andrew Ashikhmin: for Aron we also waiting on go kg release with the trusted setup
got
Gajinder Singh: on the Lota side and eum J side I will release the note bindings by tomorrow and try to integrate it but I think even uh even without all these we have the flag to run with a custom trusted setup right
Parithosh Jayanthi: yes so there kind of two blockers right
now for devet 10 um the first one's The Trusted setup and the second one is the issues we saw on devet 9 yesterday we can of course go ahead with devet 10 without acknowledging any of those issues that would just basically be devet n but bigger um or we could wait until we fix both of them and then start DEET 10 at the cost of time
Danny Ryan: these are the issues that Mario found in testing and then escalated to test in the uh testment environment right
Parithosh Jayanthi: yeah exactly
okay
Danny Ryan: um so these we know they would be hit if
we do send a certain series of uh bad and good blobs in relation to each other
yeah exactly
Parithosh Jayanthi: yeah exactly
Danny Ryan: uh Mario do you want to give us a cck on that please
Mario Vega: yeah of course um so basically um we are using the the new tool that we are using on hive um so this thing is like a a proxy that sits in between the Bon node and the validator Cent we set it up yesterday on a devet on a single client combination so every time that this client combination propos uh what it did was basically just received the unsigned uh block and blops from the Bon
node and then inside the the the the block and the blops but it also created an extra seemingly seemingly valid uh blob so the only difference between uh this blob and the correct blob is that the uh the kcg was correct the signature was correct everything seemed correct uh but it was broadcasted to to a different pair so basically one Pier had the correct block with the correct kcg signature and it can attest to the to the correct block and the other one received a a the this other incorrect block blob so what happened was when the block was eventually broadcasted the clients received the block and uh the
ones that received the incorrect block they were ignoring the correct blob um so at the end of the day um one uh one side of the of the of the recipients that didn't prune the incorrect blop from their uh database they were unable to follow the chain um the this tool was uh configured this way and it kept doing this every time uh there was a proposal from them so this was what we were seeing uh yesterday on the on devet and we have a hive test for this is reproducible so the clients can if they want uh just run this as many times as they want um the hype Des is very simple it does the same thing every
single slot uh over the course of a niok if there are too many missed slots the test will fail so they can immediately know if they have fixed or not the
D
Danny Ryan: this is really exciting that this is in hype now
enrio
Enrico Del Fante: um just to clarify you said that some clients have these blobs into database but I guess this is incorrect should be that might be more of cash right right so this is thing that we we discussed recently so you kind of poison the client cash and the client is not able to recover because it's not even
trying to look up by Route another time uh is this correct Mario
yeah I'm sorry my understanding was different
Mario Vega: um I I guess yeah I guess I guess that is correct is Cash is not database
Danny Ryan: it's persisted somewhere that prevents it from wanting to do the work again
yeah poto
Potuz: I just wanted to mention that this this abstraction is better for somewhere because in prison it is actually currently databased we're not using a
cach all right yeah
Danny Ryan: I mean and from the perspective of the test and where it gets with both both
are coherent and makes sense
Enrico Del Fante: I think I think te is is not uh is not affected by this we we fixed this recently and um basically we uh delete everything and if the next block Builds on top of uh the one that some of the network no seen as complete and good uh we do then a look up by route to from to everything so we're going to redownload block and blobs again and we should be able to follow
the chain with a bit a bit of
lag
Danny Ryan: that makes sense so you kind of protect yourself from doing way too much work in the single slot but then use additional signal to catch up um be I okay Mario do you have so now that we have this um additional ability to test both on the test net and inside of uh Hive do you have an updated list of what you intend to get there uh such that maybe some of the the devs here could take a look at it and and add or modify in in any case
Mario Vega: yeah of course I have a list of the test cases that we are um doing in hive which is basically
related to the possibilities of the of the blobber um there's a list of actions that the blobber can do and we can configure them in Hive and this is basically the same thing that we are running on the devet um I can share the list it's very simple um it's it's not very there are not that many slot actions at the moment but we can increase that if there are comments from the deps that stuff that you you guys want to test we can also include them um yeah I I will share the list
Danny Ryan: cool I'm again this is awesome to get some basic networking testing in hi enrio enrio is your hand up
oh sorry
sorry I was in mute
Enrico Del Fante: uh just want to also to to mention what we discussed uh during a nice conversation with Mario which is related to uh this latest thing that Mario was talking about um so is another condition in which uh a proposer actually so so the proposer if the block doesn't contain is not full of blobs so there is still room of one or two blobs there so he could play with this two additional slot kind of creating a blob that is invol valid and still
related to the to the block and and Slot with an index that doesn't match any commitment in the block so right technically the data is available because all the data that is required by the block is available but there's is has been seen by the node something additional that is incorrect because PCO is incorrect just because we saw a blob with an index that doesn't doesn't match to any commitment in the block so what we do and we do it on purpose but I'm not sure if it is a at the end is is a flow
in the client so we actually don't import the block
and that seems no just not
Dankrad Feist: yeah this is not necessary I think the block is the blob would not be available in that case because it hasn't been committed to in the block so the block
Danny Ryan: but the block has everything it needs so the block the you have to import the block otherwise that that's going to cause
I agree I agree
Dankrad Feist: I agree but I I would just want to respond to the concern that they get free data availability they don't no because because it's not provable there's nothing provable on chain that that data
was Avil
Danny Ryan: correct but it can be passed around
onp so it's purely
Dankrad Feist: so they get they get
like the proposer can like basically put some extra load on P top that is true but they don't get any benefit from this and I I believe and they get a slight down they get a slight downside um which is that their block is slightly less likely to confirm because they like increase they often risk because it's it uh it has competition with the other blobs so I don't see any reason why any I would do this
Danny Ryan: I don't think enrio is trying to make a claim that there's free data availability I think he's trying to make a claim they can induce load on the P2P and if we're if we're doing different import strategies on this it can cause the network split and it's
really important that we don't do different strategies on this and it's really important that we import even if you see invalid extraneous blobs uh because somebody could easily not have seen those and do the import
Dankrad Feist: right what you what you could do is not attest to such blocks that would be okay but yeah you should not like on a Noe level um you should not exclude them on from the pork Choice otherwise you risk a split
Enrico Del Fante: well I'm not saying that I'm not importing that anytime uh in the future I'm just saying that I'm not importing that in that moment so I'm going to import I'm going to test on the previous head but if the next block again uh Builds on top of it
then we just look up by root the data that we need and we actually not even realize that we an extra blob floating around because we are not even requesting for it I probably not
Dankrad Feist: but we would at that point verify that all the blocks that are blocks that are referred are available yeah I mean that seems okay but maybe too much complication
Danny Ryan: yeah a mixed strategy here is at least going to like cause some clients to be more profitable than others in relation to such an error um flash attack because some are gonna like it depends on kind of if you sit on the majority or not in terms of the attestation on whether it's going to come in or not like so it this is
probably something that should at least have a note in the spec
Enrico Del Fante: uh but I I think like there is also uh well assuming that there might be something malicious attached to this Behavior maybe there is no no no advantage to do that but if if te is the next proposal we're going to um reor the block that that's the thing
Danny Ryan: so if dep if it has if it has enough attestation you can't
Dankrad Feist: I would be much more careful with these things about re oring a block
because you are interfering in the fork Choice Rule and we don't want to normalize that so anything like that I feel like should actually be um an agreement that we all have like I have a similar feeling about the other uh like reor Glade blocks thing that it was a bit too hasty to just say it's okay if some clients do that like it seems to me like something that affects the fork choice is something that we really need to have a quite a strong agreement on that we're okay with that because otherwise anyone else will also think they can also interfere with the block Choice fog
choice in such ways and that's just not okay
okay but
Danny Ryan: um but to enrio enrio to your point this is this is much more dangerous for the the local client than even this other Fork choice rorg for for late blocks because you make yourself blind to the block and unaware of you know even the probability in relation to what you assume is going to happen in relation to the attestations you've seen yeah um by doing so so it and seems strictly worse than just having it in your view
Enrico Del Fante: yeah and moreover as we we we already know that probably we are the minority because we are probably the
only one that does this so uh if we know in advance these so could that much yeah there must be
right
Danny Ryan: right I do think that a note about um you know invalid invalid blobs side cars in beyond the you know index the highest index of the commitment in the block should not invalidate the block um I I think just an explicit note about that is probably pretty important such that anyone reading the spec doesn't accidentally put themselves in a forkable spot again you know barring knowing Network
distributions like not doing the import and then building upon uh what is prior and not having a view of attestations uh you know seems strictly just more dangerous than doing the import and knowing the knowledge should
Dankrad Feist: I also think this is much so I also think this is much less important than like say like the late block reor at least like there is a gain that the proposer gets from this which we kind of don't like which is why we do want to like we do kind of like pun punish
punishing them in some way here there is no gate there is a potential like slight load increase by a maximum of factor of two which we kind of say is like at least as a temporary load is okay anyway because that's just the Maxum of blobs um and so like the attack Vector seems very limited like basically oh yeah like noes band with requirements will go up not even by a factor of two um and yeah you don't really get any gains from that so like I would say do nothing is the best
Danny Ryan: I I think I I generally agree I I do think that I mean anything in the
play around additional blobs Andel these are just primarily like a vector for uh potential Network splits like sending invalid ones and valid ones at the same time sending ones in excess and potentially like having people consider their block differently like these are all these these all hinder your ability to get a block in but become strategies for for views
enrio
Enrico Del Fante: and just another side comment if this becomes something that we consider important should we consider to introduce flashable events um next work at this point
Dankrad Feist: that
would be the correct way if we actually concerned about it but it seems very excessive to me in terms of the extra risk it adds for the gain it provides here
Danny Ryan: the potential slash event becomes more valuable probably for sending conflicting blob commitments than sending these extraneous blobs sorry conflicting sending an a valid and an invalid one for index zero double sign right now you just kind of you have to you just have these like gossip conditions that try to do anti-ds we don't really have like a cryptoeconomic reaction to it because the consensus doesn't know anything about these side
cars I think it's certainly worth having the conversation
Dankrad Feist: if we can get both of these into one slashing condition then it would be preferable yes
Danny Ryan: well and if we were prioritizing the other
I
Dankrad Feist: I think slashing conditions are realistically very high cost though in terms of like how deep the changes are we have to touch the valid de L which we haven't really for a long time and like um what risks they add how that changes the um the cost benefit analysis for stakers and so on like it's a but yeah I mean it's not it's not out of the
question
Enrico Del Fante: I think the flashable condition have to be two because there are uh flashable condition comparing two blobs one blob with another blobs conflicting and one is comparing a blob that is inconsistent with the with the with the corresponding block so comparison between block and blobs and comparison between blobs
Danny Ryan: you could potentially both could potentially reduce to being inconsistent with the current block yeah but that's a bit different
Enrico Del Fante: right
right right
Dankrad Feist: so then then basically the cost of sending conflicting position commitments is not
sending a block which is like yeah a big opportunity cost
Danny Ryan: yeah like the d double double signing is also much easier to like make sure you're not doing in the context of a um validator client whereas like making sure your signing is correct in relation to something is much more uh difficult and likely for
Dankrad Feist: ER oh right I was thinking of going for the other one I was thinking of only having it with respect to them correct us with respect to the block
Danny Ryan: yeah but that's intuitively much more difficult thing for the small validator client to get correct yeah um I I think that
it's you know there there's there's some read on here on like slashing vers not and some some desire to do so and not it's certainly worthwhile exploration uh but I don't think it's something we need to continue on the conversation today uh certainly when we had these conversations in Austria and after around blob de coupling we did uh make the decision around uh using essentially our PTP anti-dos and peer scoring conditions to handle this uh obviously if we've gotten more information around some of the issues and concerns here we could escalate it to potentially do cryptoeconomic condition uh well you do get the block
eventually
Potuz: yeah I'm just talking about this thing of the peer scoring we cannot downcore the peer that is giving us these bad blobs because we haven't had got the block to check this so This is the real problem here that we have someone that is actively malicious and we cannot penalize it because when we find out that he was malicious we already lost who this guy was
Enrico Del Fante: well you you could also track uh the peer that's sending you but you could say you could receive things from two different peers so even if you track who is the sender of a given message then you end up in the same situation yeah
Danny Ryan: agree right okay so so in in two two
relations like the peer scoring um in a lot of scenarios is not possible but the anti conditions combined with the fact that it's not incentive compatible to get your block in is kind of what we're relying on here um you know if you send a bunch of these messages it's very likely you just increase the likelihood of orating your block um at the potential gain of of view splits and compounding uh things in relation to view spits for for gain so like that's that's kind of the tradeoff space here without adding a slashing condition um I can make an issue around this and
toss it in the Electra tracker and it's something that we could potentially talk about as we move into that conversation are people comfortable with that or is it something we need to continue to hammer on right now Mario
Mario Vega: yeah so um B do you you mention that you want this documented um where do you want for us to document this uh what What's the best place to to document this for you
Potuz: oh any place is fine I think we're all in Discord whatever you you put the few lines just to make sure that I understood the
problem correctly but it seems to me that tech one prism are acting exactly the same way and that also seems to me to be the incorrect way
Enrico Del Fante: yeah I think we can discuss on the issue that Denny is about to to open so we can maybe Define the thing
Danny Ryan: yeah so I'm I'm going to make an issue around the um the potential tradeoffs around you know the Doss conditions here and slashings for a future conversation I will make a PR about a note about uh not invalidating blocks if you see valid
invalid side cars in excess of the index in the block um in that PR we can talk about if we want more explicit guidance than that cool um and I'll share both on on Discord so people are aware once I pop them in there okay let me take a quick note about getting both of these cool D it might be worth at least
putting your thoughts in the chat in relation to PO recent question okay um so we do have devnet 9 currently we're moving marching towards devnet 10 with some of these known blockers and uh go Jinder you had uh some sort of analysis in relation to loar and devet 9 on Twitter the other day I didn't realize and so you put a comment up this morning um would you mind going through that and giving us some context
Gajinder Singh: yep so I basically last weekend
when uh the
Danny Ryan: do you want to share your screen um I guess once you get to that
point or share a link okay
thanks is it coming through
yes
Gajinder Singh: okay so over the uh weekend when uh blobs were being spammed in the devet 9 so I collected some uh data around gots arrivals of full Block Plus blobs so basically blocks having one blob two blob three blob four blob five five blocks having one blob two blob three blob four blob five six blobs and uh so this these timings are pre any uh validation done on them and what I did was basically then plotted a histogram and as well as uh the percentile scores and basically uh you know this
graph shows that how uh how drastically blob uh where the blob where there are six blobs in the block how drastically basically those uh arrival times are quite late uh so if we look at this metrix which is the percentile scores of how when the blob and blocks are fully available and uh so even though these numbers look small because uh there is no it takes no time to produce a block on Deet 9 because these are the only transactions that were being bundled over there so we can see that you know blob where blob is equal to six it takes it introduces
quite a large amount of latency and we can also assume that all these nodes are in the same data center so the uh that leny is still not facted in and basically this leads to uh KN projection
Dankrad Feist: what protection
Gajinder Singh: uh so I wait a second I not able to move this bar
is this is this are these
Dankrad Feist: um so this this is import times this is when the blog is actually recognized is there any
significant Delay from as having the seeing them on the network
yeah
Gajinder Singh: yeah so uh one second I'll just take you over the projections so these are uh The Blob projections that you know what I did was I took a lotra node for the main net and basically uh calculated its percentile scores for various arrivals of the block and uh the column that you see for blob is equal to zero those are uh the actual percentage scores that might not s saw
for using load stock and then I added the depths of the latency that I got there from with respect to the Baseline blobs is equal to zero to give an na projection so if I add the extra latency that has been introduced and if I look at this 95 percentile score
Dankrad Feist: what do you add it to what do you add your latency to
Gajinder Singh: I add my latency to the current uh latency of blocks that I see on my
note
Dankrad Feist: that doesn't seem like the correct thing to do though because like there are things happening concurrently here like these blocks are not it's not like once you're know it has done everything that it does now now they propagate the
blobs
Gajinder Singh: right but uh if we look at the uh so so what I have done is that these scores are with respect to the actual blobs latency that I that is observed on uh on devet 9 so blobs is equal to Zer is basically when you see a block with no blobs and if there is a significant diff between blobs is equal to Z and blobs is equal to 6 that means that increasing the number of blobs is adding to the latency
Enrico Del Fante: and this is pure Network latency this is not considering any validation
block import right
Gajinder Singh: correct
Dankrad Feist: wait how so that's what confus me that's what I just ask if this after um this this measures when you actually import like when your client actually says everything is is done now I have the block or is it when you saw them on the network
is the
Gajinder Singh: as soon as uh my not saw this and this is pre processing right so that's what I did basically I add did latency to the actual latency that my not is seeing and did a na projection
Dankrad Feist: I do not understand why the
blobs are arriving after the block then because we're propagating everything in parallel
so
Gajinder Singh: so blocks can arrive at or it's can arrive before or at any anywhere between or after I mean it's not really following a particular order but what I'm saying is that so blobs is equal to Z is the Baseline that I matching with the latency that I'm sitting I'm seeing on the main net today and whatever is the diff for example blobs equal to 6 minus blobs equal to 0 so whatever is a diff I added the diff so basically I added the extra latency introduced in my projections I
mean it's a name way to do it but that's what I did
Dankrad Feist: okay I like I would like to because something like I mean Ana already commented in the threat these are more than the main net latencies we saw from actually just adding extra data to the block so it feels like something can't be right about this granted
these are
Danny Ryan: these are 95 and 98%
Dankrad Feist: right I know I agree
which yeah yeah
Gajinder Singh: yeah so I mean some other client I'm I'm I I can't claim that this
analysis is comprehensive because obviously it has not been done over multiple nodes and multiple Network conditions but yeah some other client team can sort of
reverifying it would
Danny Ryan: definitely be valuable to get uh such data from another client I mean we did see with our main net experiments with you're using these kind of events some wide disparities across clients but uh yeah I also do I'm not 100% sure that like these tails are much different than what we saw on Main net because we do have you know tails in excess of you
know the 4 seconds but in in by and large in most cases seeing them pre four seconds
Dankrad Feist: we didn't see L drop adapations though which like if we saw this Beyond 4 seconds we would have seen like not at below 1 megab blocks right so it doesn't feel like this data can be correct it's my feeling I mean I'm happy to recheck what exactly I felt with on like what we get had there we still I think we can still find the dashboards but uh like I feel like the way also the way of computing this is overly pessimistic because it seems like
it makes the assumption that blobs are not propagated in parallel anyway
Gajinder Singh: I mean it's not really making that assumption because what it's doing is that it's actually comparing the data that the node is seeing on blocks blobs is equal to six and comparing it
Dankrad Feist: so what what what is the Baseline latency on this test net for blobs that are with zero block blocks with zero blobs what's the the Baseline latency because you said you normalized it to 0 seconds
yeah
Gajinder Singh: yeah so Baseline is present
in the data itself and I think one second so uh you get 95% within uh within half a second and then you get 98 percenti with 65 seconds
Dankrad Feist: right which is much slower than main net which you kind of have to take into account because like this time is still available on Main net to propagate blocks like if this is like I don't know two seconds or three I don't know what the exact number is on Main net then like during this time blobs can still propagate assuming mainnet is not
saturated with like in bandwidth
if you look I
Dankrad Feist: if you see what I mean the analysis that I have done on some of the main net blogs for example Lar missed on uh so I have done these kind of analysis and I see that you know generally uh the proposal uh is published after 2 second because uh by one and a half second you get block from either execution or from uh the me uh me itself and then basically you sign it and then you propagate it so by the time you end up propagating it's already more than two plus seconds and that is lots are not also shows that that is the latency that the lsar node is seeing on
the main net yeah so I mean whatever so right now in this particular definite 9 we can assume that all that time is squished to zero is squished to whatever blobs is equal to zero so whatever is the additional latency will definitely add up uh when the blobs will also surface on
Main net I mean this is I think
Dankrad Feist: I think I like I strongly disagree with that statement you cannot just add this when we're like explicitly doing things in parallel it's not like because that what you're saying is basically oh like currently blocks take 3 seconds to
propagate and now we're adding the blops and that's another like one second or something when in reality all of them start at time zero and yes the blocks takes longer and maybe the blocks take longer but they're still in parallel so you still can't add these things
Potuz: are you sure they start at second zero danr because most blocks come from the Builder and I don't know how the Builder path is going to be on disseminated blobs there's a big latency now in actually negotiating the with the builder so if the Builder actually is going to be starting to send the blobs later then I think your point is no longer valid
Dankrad Feist: that I agree with um and we can also like it might be possible that
are playing latency games already like I mean well we very likely know that some people are um but uh these are economically in incentivized so these people will if they see that now they're they're missing blocks because they're sending blocks late they will just have to like decrease their latency if it's that
Danny Ryan: and to be fair the difference
Dankrad Feist: technical negotiation process then I agree with you but it doesn't feel to me like that takes two seconds that seems very
unlik
Danny Ryan: might be some fixed latency added from there but that's not the same as the latency added from the parallelization of the the network dissemination
Gajinder Singh: yeah so towards that
argument where we are saying that you know the blobs should alive parallel but that is not something that we are seeing in devet 9 because there is a huge disparity in latency between blobs is equal to zero blocks and blobs is equal to six blocks so maybe we need to look at the clients or you know we need to look at the implementations where the blobs are not being transmitted in parallel or they are being transmitted one by one I think so it would be yes definitely nice whether a second client can sort of confirm my observations and uh it would be nice if all the blocks if there is a very little discrepancy between blobs is equal to Zer and blobs is equal to six column in definite 9 itself then I can sort of agree with you
that things will happen in parallel and it will not really add to a different latency number over there
Danny Ryan: uh I also I don't think D's point is that there won't be additional latency for full Gathering of information if you have you know three verse six but that it it shouldn't necessarily be like a a strict like lineary relationship
Dankrad Feist: yeah just adding it just seems overly pessimistic that's what I say
right
Gajinder Singh: right it might but we should basically do an experiment and sort of figure this out I think at least that
this experiment warrants at at most at least this much
Danny Ryan: I agree especially getting another client uh to gather similar data and for those that are gathering it to think about you know if the current presentation and extrapolations uh make sense or if we want to modify some of that
enrio
Enrico Del Fante: uh yeah currently te is not able to show the arrival time of the of the gossip message uh the actual one so we are adding a little bit of latency there but we are working on on on Gathering the exact arrival of the message down from the P2P layer I don't know if there some
other there are some other clients that are currently better showing this arrival times
Danny Ryan: and poan said he's going to try to gather some data on Lighthouse by tomorrow which is great are we still spamming blobs though in the same way on debet 9 or do we need to turn that back on for this data analysis data Gathering
Barnabas Busa: I don't think we have blobber running right now uh we turned it off because pris had the
Parithosh Jayanthi: no that that's not BL but we have Mario Mario's transaction flops by running all right
Dankrad Feist: is is prism still bored on
Danny Ryan: yes okay so probably be
good to get prism back into the fold so that
Parithosh Jayanthi: I just updated prism get once so I'll have look
Potuz: if you run that PR it should be it should be fine
Parithosh Jayanthi: yeah I just run it on Prison get one I'm validating if it's fine and if it is then out the rest of them
Terence Tsao: you also need to um resync the DB
I
Potuz: I don't think so because we never imported those blocks so it's going to remove the blocks from the DB
Terence Tsao: oh that's right yeah unless yeah yeah yeah but we need to do that for initial syncing right
Potuz: yeah that's probably
right I mean
Parithosh Jayanthi: you can ass itch into prism get one and have a look at let's do it
Terence Tsao: that sounds good I will look into this
Enrico Del Fante: another thing um te we we can still gather some data from te maybe are not super accurate but could be worth to have so when you run per this session if we can enable those famous logs maybe we can you can ping me and so I can grab all these uh logs and already have some tool Lings and scripts that crash uh crunch this data and uh put it in a a spreadsheet so we can do some analysis
on our side as well
Parithosh Jayanthi: yeah sure I can run that but in the meantime do have a look at the grafana dashboard here if it's something we can modify in the dashboard directly because we're listening to the event stream and we're adding how long block side cars are taken to propagate and how long the blob associated with the block has taken to propagate as seen by each of these
modes
Danny Ryan: okay um any amount of additional
data and additional perspective on how to parse this data would be super valuable I would uh recommend in the event that we do collect a bit more data to uh pop this on the acbe uh call for at least a quick look next week um if we do have additional data to look at because obviously safety of propagation of data in a relatively small environment um is very important um any other comments on blob data load in relation to Dev Nets or test Nets or main net before we move on today
great I think you goes in there um see so generally the big things to further talk about if anyone has anything or anything in relation to devnet anything in relation to testing anything in relation to the neb for today
Parithosh Jayanthi: just wanted to clarify the conditions for devet 10 right now do we just wait for the trusted setup file and as soon as everyone's updated that we roll out DEET 10 or do we want to wait for further changes on collecting data on D 9 or figuring out a slashing condition or whatever it is
Danny Ryan: no so definitely on um flashing
additions we're that is not part of the denb conversation currently as for um clarification around invalid uh blobs and excess of the index in Block um that will be like a probably small conversation in the specs repo that might modify a little bit of behavior in some of these extraneous scenarios but I I don't think we need to wait on that um I would want to see a fixed prism uh which it seems like we're on the border of having that um so I I would put the the main blockers on getting the the setup in place
everywhere and making sure Prism Works over the next like hour
Parithosh Jayanthi: sounds good
Barnabas Busa: order to have a lunch tomorrow for Dev 10 we would need to have working branches for most clients though is that something that we could get done uh probably by end of today so we can start tting tomorrow
Sean Anderson: uh yeah for Lighthouse we we can do that
Potuz: it looks that for prism is to be very easy like client already posted a branch With The Changes needed and our
changes are very small
Danny Ryan: okay can anyone not meet that
could all the client teams please leave a comment in interrupt regarding which branches we should use or which latest images we should use then we can start working on it tomorrow morning and possibly make a launch around noon or 1 p.m uh Central European Time
Andrew Ashikhmin: sorry a question about trusted setup because I mean we could have a an
Aron version without like without waiting for a go k KY G release but I would prefer go kyg released so that we can switch to a released version of go kg for for The Trusted setup
Potuz: I don't think go kcg can release uh I don't know if kav is here but he was explaining that uh if go kcg releases then it would break uh Gap until G actually points to the new changes
Andrew Ashikhmin: so there is some kind of weird like
infinite dependency between go g and
and guess
Potuz: so the problem is that goang is going to think that there no that they're breaking changes and it's going to pull uh and it's going to pull if if you update go kcg then with a release then if you download G it's goang is going to pull the new changes from go kcg and those are actually breaking how did it this this internal breaks
prison
Barnabas Busa: we had the other trusted set up how did that work I'm sorry we had a previously
working trusty setup that was not the real uh data and that did not break anything so how did
Potuz: yeah but the thing is the thing is that now these changes are actually breaking changes but goang since they're both pre version one goang will not recognize them as breaking changes and it will automatically update uh for a new release so anyone that downloads the G repo and tries to build is going to build a broken client G there's a channel I'll link a discussion in in the RNG and with an explanation from kevf
it sounds strange to me because in go
you typically like you can fix a specific version of your dependencies in go mode right so that that's I don't quite understand why why you can't do that with prism or
Potuz: yes you can but that's the thing that then we need to coordinate the three clients to actually have these changes
but does does go kg depend on on on gu or prism still okay
Potuz: no it's the other way
yeah
Danny Ryan: okay can we take any additional
particulars around this dependency issue uh outside of the call
yeah sure okay
Danny Ryan: anything else on denb today all right any other discussion points on anything today all right um get those images and
branches to Barnabas devops team and we'll keep moving thanks everyone talk to you soon
bye bye by thanks everyone everyone you
Speaker names adapted from ethereum/pm, CC BY-SA 3.0.