All Core Devs - Consensus #129

Transcript

[Music] J

[Applause] w

all right welcome to allore dubs consensus layer call one29 this is issue 973 and the PM REO uh first off we're going to discuss anything related to the NAB Cancun dun um which is happening within the week from now uh then a few things up on Electra and a number of uh things related to what looks like apis and testing um and then a quick discussion of women ethereum

protocol let's get started DB uh this is happening on the 13th that is Wednesday today is Thursday so six days um I believe morning us actually I had a reminder thank you Tim for bringing that up I believe Saturday night Sunday morning in the US at least uh we're doing the the daylight saving time thing be aware um almost all of these types of calls uh the AC ACD and the breakouts are usually denominated in UTC which does not change so it's 7 A.M for me right now the next

version of this call next week will be at 8: a.m um for me the rest of the world changes at slightly different times so just be aware that we're kind of going through that phase okay uh yeah so so main night launch on 13th uh we'll have a call the next day obviously if anything goes wrong we'll have calls before then um but we can debrief that on the next ACD are there anything is there anything we need to discuss before them anything related to testing any um unexpected releases any further staple things we've seen on devn Nets anything you want to bring

up I do see Terren will have a release today slash tomorrow um a recommended upgrade uh related to improvements Lighthouse also has a release being cut for Monday I believe so got onar I did see a zoom Link in the Discord from thatt um so I didn't drop it but if it's not there please somebody add it Chris hey Chris here from flash buts just wanted to say that our stack is so far stable there have been no changes in

the last week or so me boost v17 was taged last week really with v29 W from three weeks ago the Builder is still an active branch that we are merging this week I just wanted to note that on our main net relay we are on is seeing about 20% of validators using the latest me boost version and about 60 or 70% sticking on the v1.6 version that is not then compatible so it's probably would be good to give a shout out to proposers to upgrade to the latest we boost version because otherwise things won't

work got it at least you wouldn't get access to the external network on that yeah absolutely and that could be just a function of people not having upgraded yet um Tim or anyone uh aware of some monitoring tools do we have any perspective on the amount of uh nodes that have upgraded I checked yesterday for node so the best place for the CL seems to be metrica um I I'm pulling up the link I'll post it in the the dashboard um oh and since I checked on Monday Monday we were at 26% it seems we're at 51% now so um lots of last minute folks

uh upgrading and then the um best place for um El node was ethernet uh but you have to update three different filters so um I'll find the number and and put it in the chat once I I've gone through the filter ether nodes right not ether ether Nets ether noes is like is is basically deprecated it seem it still has it has stats about who's supporting the merge um so got you uh and then the one thing the one thing we do not have that I'll give a shout out to is I didn't find a great uh validator weighted dashboard for updates so somebody listening to this wants to

build this um something tracking the actual validator nodes rather than only the like than all the nodes on the network that would be that would be great it's non-trivial to do that it's not probably impossible yeah consider we we're starting from nothing so like anything is probably an improvement on that I think relays can tell us at least about all validators that are not locally building which is already quite a bit great okay so does I mean the those numbers aren't shocking to me uh a week out and seeing kind of that movement from 20 to 50% um if you're out there

update your node assuming that you want to go through this um yeah anything else on Dan just W up from my side at flash we are going to be on standby of course and available and the round and we are trying to work with all the other real as well that they have people on deck and that everything is going smoothly and if not that there is counter measures that are Deployable quickly okay and just to Echo the chat it does look like there's seem like most of the

consensus client seems to not all have you know a recommended update on on stability um nothing critical and that's only critical updates on the EF blog post are going to be added to avoid any any sort of confusion um but obviously keep an eye out on Discord and mailing lists and things if your fa Point anything else related to the upgrade next week cool here we

go onto Electra EIP 7549 um onchain aggregation this is a um iteration on top of something that has been green lit for Electra um to further allow change the data structure allow for onchain aggregation I think this is really nice to have um I believe we've touched on this in the call M is this just kind of Sanity checking that we do want to do the spec update or or what um actually I shared a document uh which reasons about the um parameters uh for Max attestations and Max attester sashings I see um and also uh it do this document does some um complexity

analysis and uh reasons about potential edge cases uh where this this kind of like um this kind of onchain um aggregation uh which is more more tied onchain aggregation than we had before can have some adverse effects where we have like Network Aggregates with overlap and indices we could easily include them um yeah we can easily include them now but uh it will be um like more tough um to includ them after this change and yeah and also yeah it there is like one small proposal at

the end of this document that I've shared so I don't know if we want to go over this document or just keep it there uh for people to read read it offline but uh that plan already Incorporated uh the first part of this doc that we have passed through uh during the last call uh incorporated into the um EIP PR um yeah and I think for this PR uh we should leave leave it for a few days uh keep keep it just keep it there um and if there no opposition merg it do you have a concrete recommendation

that comes out of your analysis that you'd like to point out just in term of the parameterization yeah parameterization is like uh for Max stations uh with this like tide on chain aggregation uh we should have eight eight Max adist stations eight adist stations at Marx in Block um it increases the capacity of of the Block in terms of how many uh different uh attesting how many different views that Val is attested to uh we we can incorporate So currently we can incorporate two views in into a block uh assuming that committees are voting for you know for more or less the

same views uh and uh for yeah and and um this uh parameter uh increases the capacity but it does not increase the block size so we can leverage on a tight aggregation it can save us more space uh to include to incorporate more views on chain into one block and uh yeah uh was a fair comment that uh we'll have to include more um so onchain Aggregates will include uh potentially include more um bits uh aggregation bits it means that uh if we use uh if we generate a slashing event out of uh this uh quite

dense um on chain aggregate um the number of uh FID dator index indices in the tester slashing will increase significantly uh uh increasing the complexity of tester slashing so there can so what we can do is set just ma tester slash to one this is the only option we have um and yeah um there is a section in this doc about this session right um did you do an analysis on on whether with one in these types of actual Network fault cases that uh you know a a high enough number could

be included before the exit Q is run out because that was kind of the analysis on on two in the past yeah so there is like imperfect aggregation uh section in the doc um and what's what's yeah indeed like uh uh we what there are two cases uh where there are many different Fortress views um which is kind of like uh this proposal improves the status quo the other one is that where we can get many uh Network Aggregates uh with overlapping indices but uh they are quite you know overlapping in two or

three bits or whatever small number of bits um and uh yeah uh there is a proposal to you know which allows toate those overlapped indices so yeah a bit of analysis is done on that as well okay great um this is this is awesome this is very needed um Can how about we leave this at at this point with your state recommendation people can dig into the analysis and um we can Surface this and in the spec um andone else to chime in on if they disagree can do

so I have a few comments ition yeah so I guess I read through it I am a huge fan of um Mel's changes and I'm not speaking for my team just I think the team seem to review it but I can say a few things so from the state transition side I think it's fairly low risk those should be fairly covered by the spat test so I have high confidence on those and on the on this validator site there are two sites of changes right the first so the first side of change is the proposal side that you're redesigning your your attestation packing algorithm and given the validator doesn't have a sp test today um this were this will require more testing and monitoring and then on

the and then on the second change is on the aggregated side and this is where being and this is where the document hasn't mentioned much today and I think we need to add that to the documentation that say today if you have 10 aggregators with the same slot before you need to sign 10 message and to and then with this change you you only need to send one message and because of this you probably need some bigon API changes and such that today I think bigon node has this um kind of like a stus design so I think that part will probably need more thinking on how to um change the be API and validator interation to solve that so yeah just just some

feedback thanks Terence uh by the way uh one question if I may um I don't know um I don't know how slasher software is implemented uh in terms of database schema but if Slasher in general has you know access to network Aggregates so it stores the network kind of like an aggregate of single committees uh than the in general case in most of the cases where we are

slashing one or two validators uh will not have this huge complexity because yeah if if the slash EV if a tester slash is great from two Network Aggregates uh the SL slashing complexity data complexity will be the same as today um the complexity only increases if you know we use the onchain aggregate um and we use um it to slash just one validator because we'll have to include all validators attested in a slot uh into the message

got it um any other comments on this before this surfaces as a PR to parameter changes and um I guess further work on some of these other components again take a look at the analysis um and when there's a PR up chime in if you disagree with the pration thank you MC okay um ancar you wanted to give some

update on the feedback and discussion around uh the proposal for Chang brought up yeah um everyone I hope can understand me it's a little bit noisy here yeah sounds reasonable okay sure yeah I just wanted to give a a quick update so basically we we published the PO posts the one kind of General post where we think the St economics should grow in the in the in the long term and then a specific proposal kind of intermediary proposal for two weeks ago andoun CBC last time already um just to quick update Bally we we had some kind Community feedback um it's basic been

mixed feedback some some people kind of followed the reasoning and agree that would be a good idea there was some some um people skeptical we in the proc but addressing that kind of hopefully also in the future have to have some extra more like boil down crisp to the point kind of explain us on this so so this be an ongoing process just one one concern that was raised and I want to briefly address is that the kind of the timing for Electra and that of course an issue in change would be significant kind of change to to ethereum um we were very much thinking that um because of there such a small change last time I like the Proto that that would be like literally two L change the

post adjustment forra that we could add this basically very late in in into the F process so um say assuming we we're targeting something like an October four then we were thinking that we can make like a final go no go decision on on this specific e in say June July and just to to to maximize kind of the time for Community conversation around this um so yeah I just want to basically stress that point that this is not not a decision that we're trying to p through here like on a one or two month timeline um yeah other than that I think again it's it's more going to be an ongoing conversation um of course if there if people have had to look at the write ups and have kind questions that we could ask now or like a we could have

now on this call then be happy to but otherwise yeah again just want something yeah thank you I was goingon to take issue with your death with uh the claim of very late and say how about not so late but um the the summer notion that you been clarified with I think is is not unreasonable uh thanks for the update any any questions for Oncor okay thank you um one of the

lingering discussion points in a lecture that I do I think there's an eagerness to make a go go noce not go decision um soon is is around inclusion list um and there was a breakout room and there's definitely a group working on some R&D to better understand complexity uh Mike you an update yeah hey everyone um so yeah just kind of catching up on everything post eth Denver and I think it could make sense to have another breakout room to just kind of continue circling in on the exact um you know features of the design there's there's been like a lot of back

and forth in the Discord Channel and that's bridged into telegram so um definitely take a look there if you're curious I thought it would make sense maybe to do the breakout room after the hard workk um and I thought maybe next Friday you know during this slot could potentially make sense because it's after the next alev execution ler call so yeah that's that's kind of it um happy to continue helping answer questions if people have them and I guess the the Discord channel is probably the right place to engage with discussion I can give a general update on where like the specification is at right so today I think the spec is at

the sh always op repo so I think moving forward is probably better to move it to the official ethereum report because now I think SPC is probably like 75% ready and then in terms of all the components I think right now uh validator on this validator and execution API are the ones that's um under specified um rest of them are in pretty good shape thank you

any other comments on inclusion this um normally I think breakout rooms are often on days that are not Thursday and 2 pm UTC but that's not a rule I think it's totally fine to do it after the extra s call if people want um oh sorry I Friday like the day after during that slot yeah all right cool um let's go for that I don't I don't see any issue all right anything else on

Electra um I've talked to a number of people that are uh I guess more willing to check Max CB um than has been sort of indicated in previous calls um like we've pretty much prototyped it in Lighthouse there's still work that needs to be done on the spec but it doesn't actually seem like a significant amount of work and given that validator set size is a bit of a ticking time bomb and we have you know this proposed issuance um adjustment and issuance changes are always contentious

so it's no guarantee that the community would accept such a thing especially like I'm pretty sure that would have significant ramifications on say the rocket pole token for example so you could expect they would push back we already had Leo kind of indicating but we just have no idea how the communic how the community is going to accept issuance changes so if they don't like it then really the only thing we can do is Max EB um and while the spec needs work um just just writing like um so far from what we've seen trying to implement the a proof of concept in Lighthouse it's it hasn't been a significant amount of work so I'm

wondering if anyone like like I I haven't heard yet people push back on this and so the major push back has come from prism's claim of of complexity in their code base um which is potentially related to design decisions but I couldn't speak to it too much more okay I suppose we can continue I mean if if anyone in the call want to offer any from the prison team wants to push back but I I can also just get in touch with them later yeah and I surface that

information now as Neil the coffin just says that that I believe has been the primary re okay well yeah and I will note that um at least a couple members from a couple different client teams that are not prison do Echo they're supporting CH and just to put it out there like I don't anticipate a lot of push back from the execution side either like this it would require partial withdrawals from the execution side but like if they've already agreed to do

70002 then partial withdrawals are like not a lot of additional complexity as far as I can tell um so just saying I wouldn't anticipate a lot of push back yeah I believe on the 70002 component um the complexity would likely almost entirely surface in the smart contract which gets to be written once um so it's kind of mask complexity poos I just have a technical question U I don't want to repeat this thing of like the complexity uh but I I had one comment on the pr which is this issue that we we choose a random bite to to

decide the shuffling and I wonder if this is just not uh not as small enough when we increase the effective balance perhaps we need to change in the Shuffling from one bite to a larger yeah we had we had someone looking into this um I we didn't got a conclusion if it was super necessary not um in my VI the detail we can we can run the numbers later and see we have to bump it or not

um if that satisfies it I would just like to in general raise a voice against the idea of using client um client complexity today to determine the future of a useful feature um I think as like all of our clients are now at the stage where we have a well working test setup with wether working spec tests and so so like a broadly useful feature I believe should lead to architectural changes in clients that are fairly safe to implement regardless it might be a

bit of work but it's a lot less work than it used to be and changes tend to be almost mechanical uh for many features thank you okay um given the proximity to interop May and uh some of these outstanding things in discussion electure I I would

encourage us to attempt to make pretty firm decisions on both these proposals in two weeks um I know that's not an easy thing to do given competing views here uh but let's surface both of these in two weeks and do what we can uh sorry I want to add I understand the complexity pushbacks but I see with with what we mentioned last time with the leading PCS to I guess prism and anyone else that's

concerned about complexity please let us know exactly what what's concerning to you and I will be willing to do a do or basically help you guys figure out if we have found this complexity or how that differs to you so yeah let's chat Asing but we can translate our findings to you guys and see if we can alleviate the concerns thank you other Electra

items further comments forther discussion points okay yeah um those that are in favor of either of these proposals inclusion this xxb um certainly the onus is on you to uh do the work have the communications dig into details um to

try to push things one way or the other general research spec discussion uh Barnabas is a couple of points um ke manager API cation bar yeah hi guys so this past weeks I've been looking into uh enabling key manager API on the validator noes on kosis so we can start testing basic API calls uh using this and I realized that every client had a different implementation for authentication for these end points which makes it a bit problematic to add it to CIS

nicely so it would be good if this could be speced out uh same way as we SPC out the JWT secret for uh communication between the El and cl I'm not sure what uh the different c teams think of this where do the JWT spec live again um I thought it was execution spe maybe it's in the execution apis in the engine spec folder this would likely live in the beacon apis spec repo I I I think it should live in the

key manager API repo or yeah most likely in the key manager API would be the best place for this I have the most problematic thing is that every client is maybe handling um certificate uh in different ways because at least for for Tech we want to have https by default enable so you need to specify key store and you have to create a key store and then to spin up https and then you can have the um yeah authentication on top of it

so maybe every clients have different way of creating those key stories certificates stuff like that I'm not necessarily pushing towards one or the other uh I would just like to see a slender implementation across the board so and I think https certification creation is a pretty standard thing to do so it's not Java specific or or go specific or anything so authentication should be able to be a standard thing so do you want to flush out a dock

or a PR there to make the design space conversation a bit more concrete you probably have a better view of the different design decisions across clients than anyone else here yeah sure any other comments to Barnabas before we move on all Next Step also from barnabus mixed validator client Beacon node testing as we all know there is a standard API um that is utilized but I think more often than not people have a

single auditor client connected to it partner with the same client um but barnabus wants to know is it expected that these should work cross and should they put effort into testing we fix any bugs that people report above all because uh we've seen a lot of people that run two Pon nodes and then some of them run different C in the we note so it's unexpected behavior that this should just work with every client

combination I think it's the desired Behavior oh it's desired Behavior okay yeah I I would say the prism's validator client is still not ready um but I on the standard API uh um yeah Val validated client on on the standard API uh because it's still it's still using um grpc behind the scenes there there is a uh rest option um but it's still being cleaned up um yeah we're we're making steps forward that I mean so

uh I would say that in general it is it should be working it is working I know some teams are already um are already using the rest option and the there are have some issues but more or less it works so I would say that feel free to test the rest the the prison Val client with the rest flag uh with other beon notes and I would be happy to hear any feedback so actually um I would be really interested if this becomes a reality that we have a good uh test harness with different clients um

it would be a good way to check cross client com uh compatibility and everything so yeah um it's not 100% let's say as we would like it to be the rest one but it is working so yeah um and as you mentioned it the defa yeah the expected uh outcome is that it should just work out of the box if any combination doesn't work I would say there's a box somewhere so the expectation is that every combination should work okay yeah so any um any testing

you can do here I think would be really valuable any other comments for baras yeah if you're if you're writing anything that tries to do thing about this what there there are a few gaps in testing one is the rewards API and the other one is the consensus block value and the third is do ganger uh now liveness it's called in the API although those three are kind of under specified in my view um and all of them are also kind of intricate if if if if some beon note does them slightly differently we we'll

get a very bad outcome if we mix and match uh clients so it would be nice for example that uh you know there are comparisons of of these API between clients and the values that they actually return for a given and say head that's a great lead into uh Dustin's Next Issue which is generally the the treatment of specification of of where block rewards you surface in the The Beacon apis Dustin do you want to gson yeah uh yeah so there are and I I link here actually so people don't

have to go back to the GitHub uh track issue for their meeting link the gist here as as well okay so there are newly relatively new last several months to a year uh and not necessarily universally implemented yet a apis that involve either a new option in the case of produced block V3 or the rewards which is not universally implemented uh uh the idea of a consensus block value or the value of constituent parts of a consensus block um with in the case of the block rewards API and and this is what um yasek was I think part well explicitly partly

getting at is this is I I would say underspecified now I may have simply failed to find uh specification or documentation which exists but yeah the that I found and and in particular we we've had um discussions in the Nimbus team about how to interpret this and we're not sure so and and we think that if we're not sure perhaps that that there's not enough explicit guidance to ensure interoperability so so this ties into and is a little bit um not not it's it overlaps with the idea of what um s of testing for it and interoperability

testing in an empirical way but even if uh Barnabas say goes and and and tests things and turns out everybody magically agrees on how to interpret this that's sort of coincidental the specs do not specify enough to say this and the so I now that's sort of the broad thing and try to keep this relatively brief but to say the specific there's two basic categories and people can read in detail of this what I winked but one of them is the proposer index changes I mean there's various places in the um Beacon chain spec where it says you do this during block transition the proposer indexes balance changes that's at least I think by my Reading unambiguously part of this um reward value a consensus

reward value both Ro reward and and for produced Bo 3 that's I think probably uncontroversial I don't see how you can interpret it in any other way I think what's less clear is there's there's one view I think the the P level view of this of this uh perspective is the block value is the is the amount by which it the block changes the proposer balance period that that's and it's easy to state but it turns out to have a lot of sort of let's say complications or nuances um because you can imagine Epoch walks or I I describe some the self slashings or you know if if you're part of the sync committee ET ET so a lot of edge cases come up which and and there's

another perspective which says no the the block value is better viewed as even though it says it's consensus block value in the header of of produc block3 response it says it's something like the proposer rewards value which is to say it's even if there happens to be accidental integer aliasing on the validator index is equal or the um whistleblower index for slashing is equal to the proposer index well that's is that part of the uh block conest of the block reward so that's the question and and I mean again people can be the document I put up to you know a little some some more examples but the point is

that what I as yasek is saying I think all the clients need to agree um especially for produce block B3 because this is how validator clients are going to select um their their blocks now It ultimately doesn't matter enormously I mean I have my PR references I'm trying to present prevent sorry present this neutrally but um it doesn't matter enormously which one is chosen but people have to agree otherwise there's going to be a skew in in artificially in validated client choices yeah makes sense um I know that you're trying to present it um neutrally but do you have a perspective on the correct way to

specify this because ultimately we need to kind of surface an opinion here I think I think there's probably broad agreement that there is an ambiguity um yeah because that is clear I think the proposer index only one is the only I mean and here I want to be clear I'm speaking for me uh I think it's the only reasonable one um and I'm gonna I'll say that I won't you know without reservation I'm not going to you know you can find other people who disagree with me on this one but in particular I think the basic argument for me is along the lines of well uh it's it's if you swap out that proposer so so you can run a couple of sort different sort of thought well again a few sentences uh you can run the slot

experiment in a couple directions one you swap out the proposer but it's otherwise the same block and and with the same um sync aggregations the same slashings it's a little weird I think that and unexpected that somehow because that that slashing would have happened anyway that sink aggregate penalty would have happened anyway it's a little accidental that it happens to be part of the a block proposed by that validator um so that's One Direction you can also keep that's keeping the proposer constant you could or so the keeping the um the non- proposer validator constant if you keep the uh proposer constant but then allow the non proposer validator to change and

you can say well there's two uh non valid proposer validators which missed their sync aggregate or syn committee contributions and at some point and and it's a little strange to treat them differently in some sense in terms of accounting purposes because one of them is it happens to be the proposer completely accidentally and one not and and indeed if you have a small enough validator set as some of the tests do and the consensus back tests uh you can be in the validator set the S committee rather two or three or four times and again does that it's just it's just kind of strange to me to yeah I guess yeah go ahead and I see that I I I I guess I I come back my counter argu

be like what is this used for this is used for a validator validator client maximizing their reward and and so and Andor penalty or minimizing or penalty so so like seeing two blocks and actually see seeing that one gives you to more Gua than the other due to some of these happen stance things which could be node specific because one might have certain messages that it include include or pack in a certain way the others that do not um you know from from a use case perspective it seems like I want to know that sure uh and in general validator

clients are free to choose other information if they want and there I would argue that it's still I think in favor of a cleaner split even for what you're describing between the proposer reward proper and having that be readily accessible and then having these these other bits of information which are also accessible like the the validator client when it sees even the sort of blinded blocks which is hide the transactions and such so so they don't they can make that decision already um can see oh well well this sync aggregate includes my contribution or doesn't include my contribution or and this is another reason I think that it's a to allow a certain flexibility to say

if you have a node or let's say you have a validator on a node that has a hundred uh validators on and at any given time one validator uh happens to get that block um but the other 99 like they may or may not have that that node probably should care let's say about its validators as a whole not just about the one validator which happens to be proposing and you know a validator client uh whether it's a beon do Val validator client and splitting this out allows uh that kind of flexibility on the part of large um or not even large even several like it's it's uh node or sorry several validator

notes okay so the optimization function isn't always just directly towards single proposer um in in many cases right so and the other thing that I would point out with regard to the optimization function is that it can be at least my suspicion is and I haven't rigorously looked at the math on this but that but I I did write this in the the note win as well is that I for for syn Aggregates it is probably the case that it makes sense to yes optimize the way you know if if you have a block being offered which doesn't have your sync contribution then that that should in fact be weighted there's no real

advantage in uh wetting that in if you have a slashing if you can get if you can be your own whistleblower on being slashed that's still to your advantage and my suspicion is that it's better Sor to your advantage meaning assuming some someone else is going to include the slashing so you might as well include it yourself is that the Assumption yes so if you can include the slashing in your block and be The Whistleblower well the slashing is already happened it will come in the next few BLS anyway even if there's a lot of slashings a mass slashing so my you and and so while I can't sort of sort of vigorously defend that right now

I again I haven't I will say that that kind of consideration certainly is is something that is um can come up um whistleblower for sure uh the others I don't know but um so and so it can be a little distorting to say well this block hurts me a lot I really really don't want this block yes but you would get the penalty next block anyway like it doesn't so I would argue for optimization purposes um it's still useful to be able to split this out and and of course look ultimately it's a symmetric argument you can say if if validator re clients can add this back in well validator re clients can take it out you can have the aggregate as it were you can have the

the combined version of this and then subtract as easily as ADD um so it's kind of a version of at that point I guess conceptual Clarity or sure I mean there's other arguments um okay are are there are there other opinions on the direction that should go in uh before someone makes a uh PR to to clarify the specification or um or do we need to kind of put this up in an issue for discussion but yeah any opinions and perspective yeah so I have an opinion um not a strong one but still so question is how much of a

discrepancy would there be in uh different client implementations if this is not specified you know that tightly and there might be some um some discrepancies between clients because if we talking about a Fugue for example then my question is does it really matter like wouldn't it be okay if different client Implement different clients R um just return the block value like within some Delta of each other instead of trying to specify every single small thing so that we make sure

that it's you know exact that the results are exactly the same up to one way even I I'm just thinking how much work it is to make sure everyone aligns and how much discussion it will take versus you know we are just okay with having these values a little bit different maybe and um yeah and we're just fine with that I guess meaning the the common practi is if I see in blocks within some Delta I pick randomly well maybe you pick the one that you see that is the highest right but right but at that point at that point you might then the

interpretation of the spec becomes a heavy bias on which one would be the the block producer correct like if client a does it a slightly different way then 90 something per of the cases client a might just look more profitable when actually they might be the same right that's true okay yeah that's that's a good point the the other point here and and is that related and and potentially a little distinct but I would say but it's why is course kind of standardizing this

even though for prod block B3 people might think might have this argument that some some amount of um sloppiness is is is is okay um is that ideally it should match get Block rewards this is kind of why I brought them up together and my suspicion is that there are relatively few people although I don't know maybe who who are willing to have uh both of those be uh just kind of randomly variable and then so I would suspect the one is going to whichever and people might have different uh views on which one they care more about being precise but I said whichever that is that should probably kind of constrain

the Precision of the other as well uh sure uh po pus or I don't know somebody raising their hand okay uh yeah I want to make an argument that I don't strongly hold uh but anyways it's a Half Baked argument which is the consumer of this presumably is a client like vouch who's choosing between different Bon nodes which block to sign and and I feel like this is so specialized that that essentially there's no no any other one using this

or perhaps there some some other clients and some people the developing validator clients that are doing this but this is sort of like pushing us like having six different clients five different CL clients discussing on API getting to agreement what is what we need to specify getting to testing getting to spec test and taking our bandwidth for something that perhaps can be done Downstream I don't even understand why we even agreed into supporting this if the consumers are restricted I would would try to to study this market and try to see if if we can actually send this work to the people that are consuming these end points instead of

ourselves coding them without consistency between the BNS I don't know what what so so for one well you can you can get all the blocks and decide and compute this yourself right so if if I'm a CL if I a client that is that that I'm faced with core deps don't want to implement this in the beon then I can just get all the blogs and do the software that computes what is what I'm going to be getting yeah and you can you can pass in in indices and essentially do a diff on them yeah I'm not comfortable coding this for just a few consumers I mean if

if RPC providers are using such an endpoint then I'm happy but otherwise it's it seems like farfetched yeah so yeah you you need a state to compute this actually and that's the first point the second point is that the Nimbus VC supports this selecting between BNS based on profitability of the block and I believe Lighthouse does as well I wouldn't I would be surprised if they didn't because I think they support multiple BS and at that point you to ask yourself yeah exactly there's a l two of us supporting um selection of blocks and users will be

very um confused if randomly because they're using some particular client that client gets either more blocks or no blocks I mean this this was the whole impetus between behind produce blocks V3 that we would unify um block production value for both execution and consensus so that you could compare two blocks and potentially blinded blocks um and see which one is best for you and this is also way of like resolving the problem

of um me blocks if ever you happen to get a bad me block that that isn't profitable like obviously you're locally constructed block should be preferred um but what but like how much you gain is the sum actually of the consensus value and the Meb value and the transaction value or whatever it is right so I think this is just this is just really basic functionality that just makes sense to have if we envision a future in which there are multiple block sources and you need to compare them like it's that simple and that oh sorry and that's actually a

comment against or it's a difficulty when you want to compute the block value from attestations or your participation in in in Aggregates and in Sy committees because you don't get an eth value you get like you know a random number and then you can guess the e value but you can't really determine it without the full State because it depends on a whole bunch of things like the size of the active validator set and the active validator set depends on you know who's been slashed and like it's a mess Okay so yeah for the Nimbus

validator client and the lighthouse validator client uh you're presumably running a bunch of peon notes and hopefully you have access to one of those beon notes uh which is an Inus one or a lighthouse one and in that case you can just code yourself an endpoint that says here's the block tell me how much money does it give you but this is again something that you can do you have the state in this peon node and you don't need to have all Bon notes that you're connecting to giving you this value I I'm not saying that this is something that that I'm strongly against it's just that it's something that you can solve yourself without requiring support and agreement which is a hard part on all of these API discussions there's so always

a lot of arguments and even they discuss about names if they should be capitalized or not so you can avoid all of this by coding it yourself in your own Endo uh well you know we have a produced block V three Endo it's actually the only end point that we have right now for producing blocks because the other two were deprecated so uh like this this is a discussion that should have been had when uh approving the V3 endpoint into the beacon API but that ship sailed and that V3 endpoint has this value so if we want to roll back on that we should release either

V4 um or UND deprecate V2 which never really was in production and I think V1 we can't even use it uh because it doesn't have the necessary functionality so we're in a bit of a bind here if we go down that route okay um I do think it makes sense for Dustin or someone to service a proposal on standardization especially given that V3 is the end point um and obviously we can always have a

discussion of uh deprecation if and and movement on to something else if this is actually something people don't want to support uh but it does seem like at least a few clients do Dustin can you move forward with the proposal yeah yeah I I I'll make um uh a PR I guess is a a beacon API because that's where both of these live they're they're both Beacon API in points so all right okay before we move on to open discussion any other spec research related

items yes p uh just a quick one uh I asked this question on on R&D I was hoping that if there are El devs that can confirm uh the question is about sending different fcus with with attributes and whether or not the E clients uh start building those blocks and continue updating those blocks uh this is not spec really specified in the engine API and but it seems that G and nethermind are supposed to continue building both blocks if we send them both fcus with with attributes uh if this can get

specified in the engine API this would make our life much easier when re organ late blocks So currently we need to like uh do yeah so it's it's a bunch of edge cases because we don't update our head when a block comes late uh but but if every client already implements this uh and allows for different fcus with different IDs at the same time then we could just simply import the block do everything as we do normally just update the head and just choose the right ID at the time of proposing it will make our code much simpler so take a look in this exe it's in the execution Dev channel in R&D thank you any comments on

that great any other research or spec items who does well anyways uh I just also wanted to point so you asked the question uh a couple of quots ago about epbs whether or not there could be a partial Builder safety I posted a a short note on it research I love if someone can can get feedback up to now I think Franchesco just replied something uh which is uh guaranteeing Builder safety and rear resistance up to a a custion between stakers having 20% of

their stake and there's some arguments there but i' like to hear some more feedback this is payload boosts PBS that's correct got it and I just I'll call out that um that also links to another post from a few days prior epbs design constraints which is something that on the breakout call was pretty high value so also please take a look at

that okay um anything else on spec research related discussion okay um Puja you have something to discuss yeah thank you Danny hello everyone I'm Puja ranan from the atdm cat hers I'm excited to be sharing about an inspiring initiative that's really close to our heart the women in ethereum protocol group also known as a wi this is a new working group in collaboration with the ethereum

foundation ethereum protocol fellowship and the ethereum cat H herders it's basically a movement towards uh inclusivity diversity in the ethereum blockchain development with the main goal to encourage and uh onboard more women developer for protocol development I'd like to thank uh Piper Mariam K Claus Timo Josh and many other from the ethereum space for their support during the launch event in ET City Denver last week and I'm also happy to announce the celebration of international women's day with wi so we are organizing an hourong webinar on March 8th at noon EST uh with

inspiring speakers from ethereum ecosystem including researcher product manager and fellows from the earlier cohort of etherum protocol Fellowship the invite link can be found on Twitter handle at w P team anyone listening to this announcement now or later in the recording if you or someone you know may be an aspiring ethereum protocol contributor please reach out to shy Wong ladona higin or me it is a collective effort that we want to bring the real change so let's collaborate learn and grow together

thank you thanks v um any questions or comments related to this effort great um I have an announcement uh starting April first I'm going to take some time off for three months uh this is a well Machine you won't even notice I'm Stokes Alex Stokes will chair the car call yes it is this is not an April Fool ship um Alex is gonna chare the

call uh Shia is going to be there providing some extra support and generally I think we should be a good spot so don't worry um if you have I'm going to try to be totally unplugged for a few months so if you have things uh that you want to talk about before then please get in touch with me um if you have things that you think you would need help with me during from me during that time frame I can help you now and I can make sure that you have the resources you need to get help and I'm gone so just hit me up if you have anything uh cool on that note let's close the call thanks everyone um happy upgrade this coming

week be exciting see guys thank you bye thanks by thank you by