All Core Devs - Consensus #58

Transcript

[Music] [Music] [Music] [Applause]

[Music] so

so [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

okay live stream should be switched

Danny Ryan: over if you are on the chat and want to let me know that you can hear us that'd be great okay here we are call 58. this is the agenda and we'll start with client updates then we'll talk about uh upgrade one hard fork one the unnamed thing that hopefully we can name soon uh then talk about the fate of pyrmont and or a new testnet and then go into research updates spec discussion and some closing remarks so let's go ahead and get started with client updates we

can start

with prism today hey guys terence here so for the last two weeks the biggest improvement breakthrough that we made is that we made a significant improvement to the stashing protection bookstore time um raul actually wrote a pretty good uh blog post about that i posted to the chat you guys can take a look on that other than that we updated the go ethereum dependency so this no longer cause prism to have ipv4 addresses in ipv6 map addresses for discovery packages we also implemented more e2 api methods so that uh we're almost done there we started halfway one planning so that's very exciting

and other than that we made some minor logging and the code improvements and that's it from us thank you great thank you terence and go with taku hi everyone this is jem from tecu uh i hope you can i hope you're gonna hear me all right uh we've been migrating static constants and spec related logic into our new version spec package as a prep for the upcoming hard fork uh we've been testing out level db as a replacement for rocks db because we had memory growth issues with rocks tv uh one of our main boot node enr's change it's been updated in the e2 clients repo

and we added the ability to add additional validators without restarting taco and with all the time required to load validated keys at startup that's about it from our end cool thank you jim nimbus

Danny Ryan: oh no we could hear you before the call started on me and now we can't okay moving on um lighthouse

hey everyone um so i guess over the last two weeks

the main points are that we've added support for queuing and processing blocks which arrive early um so we can we were previously kind of ignoring them having issues processing them so we queue them up and process them on time we realized that the slashing protection database was kind of growing quite large so we've added pruning to that um we prune every 512 e blocks now uh we've pushed three releases which include faster gossip verification times and a number of different bug fixes and we're still analyzing the cause of attestations with incorrect head votes which seems to be happening across all different kinds of clients um it's clear that it's due to

blocks being propagated late but the exact cause um we still haven't quite figured out so we're going to continue researching that um and we've released uh um a development update recently blog post that's pretty much it from us great thank you uh mommy do you want to give your audio a try no dice let's

Danny Ryan: go on to lodestar for now

Cayman Nava: hello uh past few weeks uh we've been adding all the uh tentative hard fork one

uh configuration and sse types along with just the prototypical phase one types getting uh everything refactored to allow for separate kind of namespaced variables we've also been working on prototyping multi-proof support and attaching that to sse or sse library and both of those should be landed in our next uh next release we're going to release on monday

this upcoming monday great looks like zahiri just joined us do one of y'all want to give us an imbus

update audio fill let's see okay we're gonna move on for now um uh yeah mommy uh let me let me know if

we should move on and chat but i think we're gonna move on for now and if we fix audio we can fix audio um okay so yesterday evening great mommy shared a release with some notes i'll share it in the chat perfect

Danny Ryan: um i wrote down the very very high level things that need to happen um with hard fork one which i guess one of the things that i didn't listen there is to name it and we'll talk about that right after we are still scrambling to get a pre-release done um the pre-release

we want at least all of the consensus item and items in place and there's still some some ongoing work there um that initial pre-release so that test factors can be worked on iteratively proto has done a little bit of work on uh doing some fork choice work in zernity uh so we have a little bit of kind of feedback loop there but if pretty much high level items are get these consensus prelace uh and vectors out uh iterate on pre-releases there if if necessary based on client team feedback and then do a what we call full pre-release which has uh all of the networking and validator specs um filled in which are being worked on in tandem right now so that might not be a disjoint process

at that point um things are done enough that people can work on test nets iterative there if there's additional feedback then from there kind of like we did on mainnet launch i expect private kind of transient single client test nets likely testing just hard fork one features from genesis and then testing uh forking the net partially through at some fork epoch then we will begin collaborating with each other doing some private transient multi-client test nets uh doing the same sequence of events testing both the features in isolation and testing through

a forking mechanism at an epoch um those we might spend one out to be public or semi-public but paramount or whatever is piermont will serve as our our public test net um and so after we've gone through all those after we've done a number of uh iterative pre-releases as necessary we'll do a mainnet release that will include a fork epoch chosen for piermont and mainnet and we will yell at everyone to update their notes um no big surprises in this list i just wanted to write it down um and we will iterate and expand on it if it it behooves us to add more detail there and i might toss that into like two opm

uh behind that there's a link to a lot of ongoing work that many people on my team are working on and some of you have contributed to which is working on getting last features written and tested and a number of other things like fork tests uh actually like fork epoch tests as well as fork choice tests which always working on um so there's a lot of activity there i thought we'd be at a pre-release by about today and we're not and i apologize but we're

we're on it um any thoughts or questions on any of that okay have you got um any updates danny

on what uh timing you might have in mind we've said kind of mid-year um is that kind of firming up or um what's the latest yeah i mean i guess i'm hesitant to put like a i think the target would be june uh mid-year but the i i don't want to put an exact obviously date on it until as we get pre-releases out and engineering beginning to be in the works and um all that said i you know i i want you all to make the decision so based off of the work as it comes in uh and your understanding of the work at hand we can make a decision there there is a uh

let's see there's a eth1 fork in april and there's an eth1 fork that will happen very likely by the end of july due to the difficulty bomb so it's probably best if we don't do it right at the same time uh and staggered a bit but um and it's also best if we have this process done by the time london is done in july so that we can put the metal metal on some collaborative work after so that's kind of the thinking there cool

Ben Edgington: that sounds good as a as a planning goal so that just helps to to plan thanks

absolutely great

Danny Ryan: um okay

anything else on that i know that we are the biggest bottleneck right now and uh we're putting putting a lot of work in so we will

unblock soon

Jacek Sieka: i think one may be interesting thing to think about for hard work one is to use that as a car update for when we have to support thinking not from genesis yeah absolutely right because i think clients now if you look at 1.0 like even if clients were to release um even if all clients fully supported

not sinking from genesis state starting today right we kind of still have to support all the 1.0 clients that were really previously and not forced them to upgrade

Danny Ryan: right so that's a good point to kind of change some of the networking assumptions

so i mean hard forkline is a good spot to change those assumptions because everybody has to update at that point yeah

Danny Ryan: i very much agree

um and

Danny Ryan: maybe we should spend a little bit of time pondering if there's any other coordination points that are good to slip in there for example not that there's anything to do but like if if we were to rename a field in the enr

or something like that uh this would also be it would be a good point a good place to do it it was a good coordination point okay yeah i'll keep that in mind as i'm thinking about some of the other things going on here and if anyone has some other things that we've been talking about are like nice to do and aren't necessarily part of a hard fork but would be a nice to coordinate on

let me know if you come to if you think about anything there okay um i'd like to is paul honor here no um

there's one thing that i do want to talk about and this actually we can talk about this in spec uh let's talk about naming uh well patricio is here um xiaowei

Danny Ryan: can you give us the context on progress and naming and also introduce our friend patricio

Hsiao-Wei Wang: yes hi so about the naming thing of the future major upgrades as well as the hot fox two weeks ago i opened an issue to collect ideas and thanks to all the proposals and the emoji givers we've got like 42 proposals so here's the summary of all candidates

and from this the primary emoji signals uh we can see that the is two different developer slopers love the star name things it's proposed by our community friend edison ayom and it got like over 20 positive emojis while the second place got like seven emojis uh so i assume that the is to build like it a lot because the uh the emojis are on our easter pm repository and in the meanwhile our is stakeholder community friend

patricio uh he's here and he's also from the pub the proof of attendance protocol offers to help us on the naming thing vote on pop.vote so i invite patricia here to give us a short intro to their solution and after that i hope we can discuss or even decide if we want to have a community election um pop that vote or go with the standard things so even if we don't use pop double this time it could be useful in the future anyway yeah so any question before i hand

over to patricio

thank you shower um hello everyone um thank you very much for your attention so i'm patricio um i helped facilitate the events and activities of the historic community um we've been growing this community for many months now and it's been going very well um we are very happy to be this sort of bridge between the the actual development and and the stakers and the enthusiast community and and to make the community feel closer to the research and and to the implementations

uh we do some some activities um like when we issued the nft that proved that someone was part of the institution assist blog and some others and and using these tools mainly from poa but there are many others we have the ability to do this new kind of appalling things and another collaborative mechanics that weren't possible before so so when we saw then the naming issue on github we thought that it was this was a perfect match um not particularly for the naming thing because i don't think uh the naming is important i don't think anyone is too concerned about the naming thing

but it's a nice opportunity to test out um this this concept that we have available that that could um very much help uh decentralize governance creating this super low cost non-binding um uh results for for community questions so uh what we proposed and i'm going to put on the chat a little link that answers a couple questions um what we proposed is polling the people running validators uh it's a data set of approximately two thousand people genesis validators uh we could do with

those that were a bit later but but for now options it seems to be uh the lowest hanging fruit so the idea is that uh using this data set of 2000 nfts um we could allow people to express their opinion on matters in this case the naming but it could be anywhere and and the thing is very low effort because it doesn't use gas it uses off-chain signatures um the interface doesn't require any technical ability it's all a front-end app that people use with metamask or with their mobile wallets or whatever they use um it's been tried before

it has worked um it's somewhat civil resistant which is the main the main challenge the core value proposition of this product boat which i forgot to link so i'm going to link on the chat as well the core value proposition is that you can have this super low effort polling system uh with somewhat reliable civilization guarantees because it's highly unlikely that someone can attack the boat by creating clones because you have to have put uh 50 000 worth of dollars on ether uh on noaa's numbers and and even if you

attack the boat like by splitting your validators or doing something somewhat malicious like that you can't still really get an outside uh an outside weight on the boat because it's still a lot of people and and from what we've seen based on on chain activity not many people apparently have distributed their boats so we believe that this is a very nice tool to use maybe not for the naming although something that nobody seems to have mentioned because this leader overlap between research development and app development but the synthetics project which is like a top three uh d5 project around has been using the exact same naming

convention like like brightest stars or something for like two years now and and they have used lots of time so there would be overlap i understand that it is not it's not really a main concern because it's a dividable and this is freedom two but it's still um what i would propose and and this is three of any one responsibility we would do this inside its taker without requiring anyone to do anything besides voting and maybe helping with promoting the vote what we do proposes to do is power poll let the people express their opinion in this non-binding manner and and if we see that there's an overwhelming interest on a different naming convention maybe we consider

or or maybe they validate um these suspended what that was already proposed or or we find something else on top of that if there's anything that feels contentious or looks like it might be useful to get community input on we are very happy to help facilitating this and running this thing um we are planning on making the product much better so so voting gets easier and running pulse is easier and and we keep working on on this tooling for decentralized communities um it can be argued that one of the reasons why some protocol development not necessarily based layer but some other

protocols one of the reasons why they aren't more decentralized it's because it's quite hard to get community input in a reliable manner and so i i think that's the main concepts i wanted to share i very much appreciate the opportunity and and i look forward to to see how we could collaborate whether it's with the naming convention on anything else in the future thank you great thank you patricio um and i will say if if there's a sentiment to just go with star names another thing that we could potentially do is because they're planning on being in

alphabetical order the first one would be a we could we could vote on which a star to do um if there's you know an overwhelming sentiment of this group to already want to go with stars which might be a good compromise um does anybody have strong they're excited they're not either way um you can let xiaowei know offline if you don't want to express that opinion here um and i'd say probably in the next 24 hours we're gonna make a call on this one or the other because we need to get a name out um but i will let it open for discussion if anybody wants to chime

in and also if people have questions for patricio about poet poet vote um intuition on distribution of poeps all that kind of stuff um by all means yeah one last comment um i i guess we can make a 24 hour lasting poll to see which kind of attention we get because also if people don't bother to vote with their nfts then this is pointless so unless anyone has any concern and it's permissionless so it's not that we could stop anyone doing this but we may run a pulse just to confirm that all people are happy with stars maybe even instead of offering people options we shall say are people have

been using this convention and and if we get over overwhelming support then i guess there's something to discuss and then we can do the one like which one is starting with an au one um i guess nobody will oppose this yeah okay thank you very much that sounds good to me um um yeah one thing quickly i'd like to voice um opinion against the idea of voting for every name because i worry it says president that we're going to have to vote for every hard fork name from here on and i worry that sort of encumbers us or slows us down for something i think we could just resolve on github or in different bands so i'm not not commenting on the idea of voting for

stars or whatever the overall system is but just specifically against naming gotcha i mean there's also the there's the what was it petersburg every once in a while there's a fork where um you have to name very quickly yeah exactly okay patricia why don't you do some sort of community sentiment poll um and and we can kind of go from there and i i would assume based off of the silence and that's quite an assumption that people are kind of okay with stars here i think

some of the other names uh charlie brings up a good point about world of warcraft zones um likely illegal i don't know i'm not a lawyer um but yeah cool but yeah if you want to do some sort of community sentiment poll in the next 24 hours would be great yeah yeah that that's a plan and i think kyle's point makes sense too um we weren't thinking of making this like a super cold sleep the main point of this is making it easier and cheaper so yeah we wouldn't put anything cumbersome we start with that and see how it goes okay great thank you very much patricio for that and all the sticker work that you do

Danny Ryan: okay anything else on naming before we

move on

okay so piermont piermont

Danny Ryan: load um the number of validators on piramont i believe mainnet is uh catching up with it relatively quickly um and if pyrmont does not have a relatively full queue from here on out at least for the next chunk of time as long as the main net queue is is full um then it may not will exceed the load of paramount and we will lose we won't have like a nice testing zone for for load testing before we hit certain load uh

thresholds on mainnet with respect to validator set size so um there's both proto and preston brought this up in different contexts that it's probably time to either grow piermont or start fresh with something new a different test net the problem with growing pyrmont is yes we could toss 50 000 validators in the queue uh but then we've degraded quality of service for users to test things uh to actually get validators on mir pyrmont so if we were to grow paramount we needed to do it in a little bit more nuanced fashion as in keep the queue relatively full on a daily basis but not

overly full so that users that show up you know have one or two day delay to get on this can probably be scripted up relatively easily and those keys shared amongst people uh but then there's just kind of an ongoing um maintenance and management to ensure that teams have these keys uh running and and deposits are made the alternative and this is not it's mutually exclusive uh we could do both um is to start another test not where we run most of the validators and started at a higher number started 200 000 so 250 000 um that has a little bit maybe less guarantee of quality of service keep paramount going as is

um so i don't i don't feel very strongly i'd like some kind of engineering input because each of these paths would have different amounts of overhead i think that the problem is a problem i think we do need to have a higher load test now with respect to validator count than mainnet but that's about all

i have so does anyone uh preston proto you were the ones that originally brought this to my attention um do either of you have any any comments or anyone else yes so um i think we're already kind of past the point where growing per month is like really effective because we

cannot grow it faster than maynet at this point the churn rate is the same so you end up you end up adding a maximum amount of validators will only ever be 10 or 20 000 validators but the first current difference bigger than may not which is not like a nice margin to do testing releases and all that then an actual problem occurs so i'm kind of in favor of new testament or some alternative to get a lot more federators in right and

Danny Ryan: an alternative would be to do some sort of fork

but that would require a lot more coordination and higher chance of failure

or forking i guess forking the um q constant and maybe some of the other constants hey um person here i think that we should uh seriously consider a second test net with with a much larger scale so that we're we have a large lead time on main net because if we as you said if we maxing out the queue now in pyramid we're only what 15 20 000 validators ahead of mainnet

if even that much so it'd be nice to have many months of lead time on the validator size so we can work out those uh bottlenecks before they become a real issue and at um at prismatic we would be happy to implement something where we send deposits on a a frequent basis but never exceeding the queue size of 50 so that way if somebody wanted to join um the quality of service of pyramid would not be too degraded you would only wait uh 12 hours at most to get processed to the queue uh instead of dumping like all 50 000 at once we would be right fine with implementing something

to to keep puremont going at least to stay ahead of mainnet

Danny Ryan: yeah because another goal is even if paramount's not way ahead of mainnet it should be at least at parity for people testing their setups um okay i'm i'm convinced uh who wants to take the lead on setting up a new testament i can knock on aphro's door to see if he has interest there um he can do probably some of the work but ultimately there will be some work on client teams

hands

Jacek Sieka: i mean i would just mention that if two

deposits are kind of slowing down

Danny Ryan: yeah i agree i i think that though it is still likely that in the 12 24 month time horizon that we do get to um pretty high pretty substantial validator counts um but yeah i think that what is the queue three days long now

Justin Drake: so my estimate is that coinbase will add roughly 1 million

if

Danny Ryan: where do you get that

estimate

Justin Drake: basically just by looking at the amount

of if under custody in the cold wallet of coinbase and comparing that to

other exchanges like kraken and and looking at the proportion of uh of i think we shouldn't like i mean i think that it could be very different than what you expect like basically it could be yeah yeah so it does not support uh trading i think the stakeh and i think coinbase might from what i've read kraken does support i believe uh didn't look like me from the home i would imagine an exchange would by default

uh but i i haven't gone and looked at their product offering well because they they said like when i looked at it it sounded like your ethos knocked up when you stake on kraken like they made specific references that it might take several years until it becomes available again interesting yeah

Danny Ryan: so you would say maybe there's even a higher number coming

Dankrad Feist: i think it just depends

i think this extrapolation is very

Justin Drake: so i just checked they do have um a new token which they actually have two new tokens one called e2 and one called ev2.s

dot s is the one that's taking from understanding one without the dot s is kind of unstaked uh and both are derivative and tradable

your right isn't exited yes that would be my my assumption it's got a pretty great discount i might go to answer your question it seems like uh eth that is entered and exited and i don't know why there's much of a market for that i mean on stage if might be for example any if that you have on top of the 32 kind of the uh the trading of rewards

but also when you exit yeah yeah i could see the trading rewards well okay you can simply see it as like i mean

Dankrad Feist: you can basically create a basket of two different kinds of assets like with the unstaked if you basically don't uh don't take the staking risk but you also don't get the rewards

right yeah yeah so even if even if if the is staked you can still create a separate asset that simply counts as a phenomenal balance of one right okay i don't know if that's your bedroom

yeah it doesn't have to be like a number of pounds there's no reason to make it exit yeah um okay that aside so that's what thirty thousand validators if they do a million eighth um a hundred thousand dollars if they do three million um i i agree the queue is slowing down but i i think that it's probably valuable getting ahead of it and having a test net with at least 200 000 or 250 000.

um um micah

Micah Zoltu: why do we care about that the queue is slow

um on a test net if you're trying to get in and test your setup and we put in you know a month worth of uh validators into the queue and the queue on mainnet is two days somebody might forego adequate testing on the test net and just jump into mainnet because they don't want to wait a month um so it's it's probably good to at least have the queue not be too much longer than on mainnet sorry so coinbase is going to be the stuff we're talking about though is

mainnet right sure sorry main net we're talking about there's two different things we're talking about queue lengths with respect to test nets and quality of service on people being able to kind of test their setup and then we're also talking about the fact that the number of valid although the queue length has slowed down on main net meaning the validator said it's not growing as much as it was originally there is a large exchange that is about to offer a new product which could all of a sudden make q times go up a lot meaning the q times we don't care about the valid the validator set might start growing largely again because of that product offering from coinbase okay um and

the having piermont grow by a hundred thousand validators might not be necessary today if uh the the amount that maine net is growing is is much smaller today uh but that might be disrupted by coinbase okay

Danny Ryan: i still think we should do a second

test net um let's organize outside the call who wants to name it just joking okay um what was that

how good is the tooling around people setting up their own private test nets i guess something like a one click turnkey deploy like where i can set up a you know test net for myself or is it something that's currently more sophisticated um double crease what's the what's the current status of scripts here do they work are they broken so it's a lot more complicated than i'd like it to be uh especially when you're talking about multiple clients maybe a custom genesis it will not be like the normal process if you want to start something with 200 000 validators uh like doing it once for the per month

testnet was already a big thing making that many transactions to have it be the same contract but like for new testament i think we should just kick start with like a state filled with the validators we need so that would be different and then like likely we wanted to be integrated in clients from the get go to really make it easy for people to actually run nodes clients do support custom configuration that is doable and scriptable yeah i do think we need to like for the real thing we need to be we need to revisit some things to really

make it work reason i was asking just because to address the problem of encouraging people to test first um there's two options one a public test that you can join and to make it very very easy for people to create their own test nuts i was curious how far away the second one is it sounds like far enough away is probably worth creating a second test that public one yeah i think so you're also not going to be able to run a realistic 200 000 validator test that on your local computer although uh some more sophisticated players i.e coinbase might want to run such

chestnuts

Danny Ryan: okay let's move on um research updates uh i don't know if y'all saw there was in the there was a stateless call in which docker and vitalik talked in more depth about verbal trees which is pretty cool not immediately relevant to our work uh but impacting potentially how state trees are constructed in each one and the application layer check that out i don't know if the video is public but if you want to check out the video i have a link um any other research updates

um um i have like the update on the merge side yeah so um there is the document let me put it on the chat this is actually the beacon chain stack um updated begin change stack including the executable begin chain proposal um so the goal is to start moving this document to the eat this back repository at the like end of the next week so for those who are interested in doing some review and passes on it you're very welcome and just leave the

comments in this document um so a few words uh about updates uh with regard to what was uh announced during the r d workshop because this dock already has been like published before um one of the updates is that it's it became independent from the if one f2 communication protocol those functions that like produces the execution part of the beacon block and inserts it into the [Music] application where chain are abstracted so um and

also um this spec tries this version like tries to address the confusion [Music] of the terms of if one and its two terms in the context of the merge because like there is no like if one and it do um around the merge uh like in in in one um in one setup uh when we speak about if one we mean the um like application layer application network and application state and when we speak about these two women the like the consensus or the beacon chain stuff so um i also encourage people to start using this kind of terms like the

consensus layer and the application layer um the idea behind starting to move it to the specs repositories to make it like they execu make it executable and publish some basic test vectors so people will be able to start to implement it so yep and continue to work on on some on some other uh specs uh like more probably uh to that touch the application layer the chain history and state downloading and other stuff so any questions comments on that

reach me out great michael so yeah that document shared is going to make its way and speak spec repo maybe towards the end of next week or at least work will begin on that um if you have some fundamental things to discuss or any iterative work um on that in the next week let us know otherwise it'll kind of enter into the normal pr issue development and you can chime in there any other questions from mikhail or on the merge in general i just looked at the pyramid block

explorer i had it up on my computer and i looked at it and i saw there was 83 participation and i thought that 15 of mainnet validators dropped off but that was not the case anyway my heart skipped a beat um any other research updates um aside from virgo trees i've i i also have that post up on his research about a yeah a proposal for how state expiry could work and have fewer resurrection conflict issues and then some than the existing proposals so feel free to check that out as well

yeah small questions regarding the vocal trees as i understand we will rather have we will either have them um within the merge or after right not before um i don't know i mean there's definitely people in favor of doing whatever needs to be done before right i mean for one there's still probably some debate and technical vetting on them in general but uh the it probably just depends on relative progress uh if the merge is ready and vertical trees aren't then probably just do the merge but if um if they're kind of competing for both being ready at the same time um

then we'll figure out what to prioritize but i don't know we probably wouldn't do them simultaneously uh i could be convinced otherwise but it it's probably not a prudent decision to do both of those large things at the same time yeah yeah then like the other question which is probably more correct one what is the intuition behind the timeline of the oracle trees like the six months year or whatever i mean i think purely from the cryptographic engineering like they can be implemented in a few months but it's all the stuff

around them that needs to happen that like lets me think we are talking about more than 12 months as in do it after the merge right it could be soon after the match because it is very systemic to how clients work and are structured today at the state tree structure yeah um yeah and i mean there's lots of stuff like getting transaction witnesses figuring out how to sing and stuff like that like i mean that's well you can do the you can do the vocal tree merge without going stateless yes so that's not i agree so that that's that can probably be done quite a bit

sooner if we if we wanted to do that yes do you um i mean we're kind of we're past there's like you use them as we are doing like the hexay trees now and update them but not bother with the witnesses then then that's doable more feasible yeah um yeah okay any other questions on purple trees okay other research updates other questions about

research i know there's between content commitments and vertical trees and the merge there's a lot of relatively new and interesting things going on okay we will move on spec discussion um something that i did and i'll i'll take this offline i just i'd request um there's this pr by vitalik that does um it changes it such that in in when there are empty epoch transitions which is a

potential dos vector today um the primary load on anti-hawk transitions is only happens every 64 epochs and so it reduces the the load by a factor of 64. it also does a proactive per validator uh leak tracking so that uh something that we saw on test nets a number of times was you have a leak that is happening you get back to that finality point and all of a sudden the leak tracking is is done and if you start leaking to epochs from now you're kind of started over in terms of the magnitude of the leak and so there's a per validator leak

tracking there too um justin has also done a bunch of work to clean that up i'm working on reviewing his pr that pr to merge things in um i did get some review from terence with got general thumbs up there and i got a little bit of review from paul he said he's going to dig deeper and he was not as interested in this feature and thought the complexity was not worth it so i i would encourage um so that's two teams if a member from a couple other teams can take a look at this thing this is one of the last uh features and last bits of work that we're doing on consensus side for hard fork one um so i would ask for you to uh take a look

and weigh in on this um i will also i asked i gave paul a little bit more context on why the pr exists and he's gonna dig a little bit deeper so uh there is a pr by vitalik i'm working on this merge from justin hopefully we can get that done today and we'll have kind of the cleanest pr to look at so i'll i'll drop a link to y'all when i get that done um and i ask you again for a little bit of feedback is that two one nine two danny uh penalties actives and exits only at 64 epoch boundary yes and then the the cleanup one is something something at justin drake

which is one of the more recent ones two one two okay sorry i didn't have the links up right got it great yeah so i mean the the the core of what is happening is in that uh in terms of in 2 192 the like its features are there so if you want to think about the features uh there's a without two two one two that's also useful okay any other things uh talk about on on spec's side like i said um myself and many other people on our team are spending a lot of time on this uh we're not where we wanted to be on the pre-release yet but we're

getting there soon okay and anything else anyone wanted to discuss today open discussion closing remarks okay great thank you everyone uh we'll talk to you very soon thank you patricia for joining us eager to see how uh the community poll goes in the next

day or so um and we'll have another call in two weeks otherwise talk to you soon on the internet bye guys thanks danny thanks so much [Music] [Music]

[Music] [Music] [Music] [Applause]

[Music] so

[Music] [Music] [Music] [Music]

[Music] [Music] do [Music] [Music]

so [Music] [Music] [Music]

[Music] [Applause] [Music] so

[Music] [Music] [Music]

[Music] [Music] [Music] you

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