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

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.