What's new in Eth2 - 28 January 2022 with Ben Edgington and superphiz
What's New in Eth2 · January 2022 · 1:01:32
Teku client lead Ben Edgington joins EthStaker educator Superphiz for a rundown of consensus-layer development as Ethereum inches toward the Merge, translating client-team progress and research updates into terms stakers can act on. The conversation keeps a running focus on client diversity and validator readiness rather than treating the upgrade as a single fixed date.
Speakers
Topics
From What's New in Eth2, hosted by Eth Staker.
Transcript
hello everyone i'm superfiz uh i come from the east staker community and i'm here with my good friend ben edgington hey everybody it's great to see you again fizz and good to be trying this new thing yeah so ben does a bi-weekly newsletter called what's new in heath 2. um and i'm sure we'll talk about the name at some point but um the newsletter is all of the the kind of updates and errata that you would not necessarily get from the eth2 ecosystem unless you knew where to look and as much as i enjoy ben's newsletter i i wanted to sort of uh see if we can improve the reach um and give people
more of an audio format as we near the merge um and i reached out to ben and ben said oh yeah yeah so um this is really exciting for both of us we we don't know how it's going to work out it's not scripted um it's not even formatted we're going to hang out essentially for an hour and talk about the january 28 2022 edition of what's new in east 2 um and i'm going to learn a lot about what's on ben's mind and i hope that in your time with us you learn a little bit too cool cool uh thanks fizz for the introduction so this is edition uh 83 86 edition 86 of what's new in eth2 i've
been doing this for for quite a while and i don't know maybe sometimes feels maybe it could get into a bit of a rut or you know focus too much um and not look broadly enough or whatever so it's good to try something new and uh yeah let's talk it over we're gonna start your focus always seems appropriate i love that like um i i know you know it can shrink and grow but you always seem to keep that uh the core focus on our progress toward um a better ethereum so i do love that about your newsletter uh the plan that we discussed is i'm kind of just gonna scroll through ben's newsletter and mention topics as i see them and uh he's essentially gonna just
chat about what his thought was when writing that um in some cases it will add more context and in other cases it's just going to be more or less the same thing that the newsletter already says um first vitalik was on up only so i guess did you watch it uh yeah i listened to the the whole thing out on one of my daily walks and it was entertaining um you know vitalik is is a great um interviewee and the up only guys um i've only come across them quite recently last few months you know um but uh yeah they're fun to listen to it was uh it was a broad wide-ranging interview and uh yeah it's worth a listen if you want a bit of entertainment
yeah i haven't caught it uh i do know my friend blemboshi or nolan is a huge fan of kobe um but i only listened to i listened to the tetra node episode i i haven't heard this one i will based on your recommendation i'll pull that up and so moving on the beacon chain uh let's see we've got 288k active validators can you tell me uh puremont crater testnet kind of land what's what you're seeing there uh so on the uh prada test net it's quite similar to the the mainnet um but you know participation is is lower just because people aren't so committed to their
validators right it's a test net there's no real value at stake so people come and go they tend to abandon their their nodes once they finish doing whatever they want to do rather than exiting nicely so participation is about i think 85 did i write um yep which is fine you know it finalizes it works it proposes blocks but it's just not quite as as smooth as as it might be um so i've had some you know one interesting thing is in the kind of teku support forums and i should say for context if anyone doesn't know i'm product owner of teku client uh that's just broader context so i'm i'm most familiar with that we get people you know i set up my node on prada and it's uh attestation
efficiency is is you know only like 80 and i look at it and actually you're doing really well you're still voting and uh uh yeah on main you know it's 99 plus but on i'm proud to um the the effectiveness score from beacon chain tends to drop dramatically and scares people a bit yeah sorry go on i was going to say that the chain needs 66 percent of validators to finalize and uh obviously mainnet runs at about 99.2 percent uh and so it's not uncommon to see a test net running somewhere between 66 and 99 percent yeah and i think um just coming back to maine i think that 99 plus sometimes up
to 99.6 or 0.8 participation well exceeds our expectations when we started this thing um and it has been running beautifully um people are really taking care of their notes they care about their stakes and um yeah it's terrific something i'd like to talk about at some point like the question of being who who is running these notes um because we obviously at some point i've been under the impression that it was a lot of individuals running the notes and now we're learning uh more and more that um exchanges and and other operators are running large conglomerates uh that's just something that that maybe some point i'd like to
dig into with you yeah yeah i don't have a huge insight into that there are various sources of stats around um beacon chain has um a sort of staking pool monitor but it can only identify about a third of the um the operators out there so some of the larger ones um and uh large staking operations are often quite stealthy they prefer not to be um identifiable for for whatever opsec reasons uh and it's quite hard to distinguish them from individual stakers so no nobody really knows i mean this is this is one of the intriguing things yeah and so to add on to that we um we
have kind of a new a new personality uh ox and viz or invisible symbol um who has been working diligently to connect uh these large operations with the validators that they run um and i'm not i'm not clear on his method but uh any time that we that i've uh tracked back the quality checks out so um i'm really so he has shared some data with michael sproul and they're connecting that uh so that we can share more of that with the community get a better picture of um of how that that diversity is working out yeah i think transparency is is key this is this is good and uh the data's out
there um the i i'm loving the twitter um the daily twitter update on incidents at the uh major staking um and so forth um haven't been so much lately but uh there's been a couple of good updates on outages and auditors at some of the staking operations uh i don't know who's running that maybe you do but it's it's really good i've had some offline contact with him um i don't recall his name as a matter of fact i tried to tag that account this morning because um rocketpool had its first slashing and i i was uh i tagged eth2rect and i wanted to tag that account as well but i at the moment i couldn't recall um i couldn't recall the name of it but yeah that's a very
valuable resource i really love it so thanks whoever's doing that sorry you know for anyone who's listening ben and i haven't done this and we haven't planned it so we don't really know how much we're going to be on topic versus off topic but i think we're both committed to just sort of enjoying the process so um i hope you enjoy it as well we'll see what happens um what was this uh insecura i didn't i didn't uh get too deep into that yes this is a really interesting project by uh yatzik from the uh status team the nimbus team um and so piermont's test net is basically deprecated um we're not
maintaining it anymore teku's already exited uh lighthouse has exited um so it's it's become yeah we're not encouraging anybody to set up new validators on it so it's somehow a playground if people want to try wacky experiments so um what uh yatsek's done is create a long range attack on on the network so he's um got some validators which have created a fork they've kind of gone back in time uh voted for a different reality um and have created a a fork of the piermont network um basically as a proof of concept and then
he's looking at ways in which new joiners to the network can be duped into joining the wrong chain so that they will see the wrong chain history the one that he controls not the one which is you know the majority or um consensus uh the reality as as it were and you know this is a a well-known attack the long-range attack theoretically speaking it's sort of a little bit similar to a 51 percent attack but but has subtle differences um on proof of work that 51 attack creates an alternative reality but the the rules of the game in proof of work are that when your 51 attack succeeds everyone switches to that chain
you don't have two alternate realities you just have the one and everyone has to switch over because of the heaviest chain rule whereas in proof of stake you can have these two parallel realities controlled by different validator sets and and we have this whole thing about weak subjectivity that's the key word if you want to sort of look up um how we deal with it or plan to deal with it in in eth2 um weak subjectivity is is is the thing and yeah it'll yeah we can do a lecture on that sometime but um that that's the thing so um yeah really interesting um exploration by yes i mean to see this kind of theoretical idea actually carried out in
practice is brilliant his conclusion is it's not that easy to pull off and it's i think fairly easy to defend against and you can defend against being duped by such an attack but um nonetheless it's it's not just theory it's a real thing it sounds like the value here is if if we can learn how to dupe people into joining the fake chain we also gain the knowledge of how to um bring our onboard new validators onto the correct chain so we learned both sides of the of the spectrum yeah and it's a good reminder to us that you know we need the infrastructure in place to support uh the weak
subjectivity that we um that we plan to um you know is is a defense against this attack so we need a way for new joiners to the network to gain um be very confident that they have the right chain so they can you know perhaps we can have a um decentralized way to gather checkpoints from um upstanding members of the community like you know beacon chain or ethereum foundation or whatever you can go around you can gather whatever number of checkpoints you you you feel would satisfy you and then you make sure you only join the chain that has that checkpoint in it the the next thing is something that's
that's really exciting to me um and i'm i'm going to issue your caveat on your behalf um ben is product owner at tecu and because of that he's very careful um to uh talk about client diversity in what you would call a safe way because it could very easily come across that ben is saying um hey everyone leave the super majority client and join teku and so i want to recognize that that position for him that when he's talking about client diversity i know that he's not only promoting his product he is promoting the health of the network and i he has very valuable thoughts about the overall network health he's
not just trying to convince you to uh switch to techy which you should so yeah um yeah but i i love this section what are your overall thoughts on client diversity right now yeah um yeah thank you for the caveat and uh i would be extremely uncomfortable if techyou had more than say 25 or 30 of network you know the sweet spot is like 25 at the moment or yeah 20 to 25 depending on you know where the load star is considered kind of production ready so i would i was scared i mean so we got this number from michael sproul's uh analysis which is probably the most accurate number we can get on actual validator distribution so that's
where where is the stake in the system and i think it's 68 point something percent of the stake is on prism run uh infrastructure um according to his analysis and and the the error bar seemed quite small at least for prism on that and 68 is above the magic number of 66 it means that if there's a consensus bug in prism that immediately gets finalized i mean within 13 minutes that's finalized we've got no opportunity at all to remedy that so we have a bug baked into ethereum forever at that point and depending on the bug might be something trivial or it might be something severe like you know the bitcoin inflation bug
imagine you know creating a couple of trillion uh ether and not being able to roll it back i mean it's um it would be messy and the question is what what do we do in this circumstance do all the other clients are doing the right thing but they're on a different chain do we replicate the bug in those get them to join the prism chain and then kind of have some sort of hard fork to undo whatever happened might be feasible might not be very unfair to the minority clients um you know the people who were doing the right thing uh or we do we say no rules are rules we stick to the spec you know the ones that behaved in accordance with the spec are correct
um and um they may be the minority maybe 32 percent but of the validators not necessarily of the rest of the infrastructure i mean you know if infure is running teku which it is you know teca will be following the correct chain so all the daps and so on that and services that rely on infuria will be on a different chain from the incorrect chain so it's a mess right it's big mess um and the problem is if you we want to get the prism validators that have forked off on back onto the correct chain you can't do it because they're finalized the wrong chain so by definition getting them back on the right chain is a slashable offense all they can do is exit at that point and stop validating um in reality
they're not going to accept a social consensus that means that they upgrade to a client that then slashes them they're going to say i'm sorry we're not going to do that we're going to stay on our chain and at that point they are the super majority they they control um a significant portion of they control enough of the chain that they can set the rules at that point um yep uh yeah depending on you know whether exchanges and whether infrastructure follows or not and yeah honestly uh i was around in dow fork days you were around in dalfog days and this is gonna make that look like an afternoon at the beach i mean you know there's no happy ending yeah exactly it's just horrible
all every consequence is is unpleasant i i just want to avoid that situation which means you know there's an imperative on everybody to get the proportion of validators on the majority client um ideally below 33 you know that's the nirvana but um but certainly below 66 percent and yeah it's also self-interest as well if you are running the majority client you run more risk risk of loss and risk of severe consequences in a in in such an event on the good side um there are encouraging signs around i mean i think people are finally starting to take this
a little bit more seriously so the astonishing thing is for the first year we started the beacon chain with prison with about 70 and we know that because there was a weekend when they stopped producing blocks every prism client stopped producing blocks we missed 70 percent of the blocks so we that was near the beginning um and now a year later we're still at 70 ish nearly nothing's changed the network's grown by 10 times and yet you know nothing's trying to kind of felt like we felt like you know well people are recognizing this and and you know the trend is going to change people are going to to recognize the need to update their and
kind of you know this year on we've realized no one has done that like nothing has changed and so i love hearing you talk about like you know there are we are hearing sprinkles of optimistic news but i don't trust any of it like until until michael sproul says we are we are below this threshold i i just i i don't trust what anyone tweets or write to dms about uh and i'll be specific we're talking about three exchanges uh coinbase uh kraken and binance who uh essentially run full prism shops um with you know 30 40 50 000 validators uh we're hearing
rumors that they're talking about changing but until we actually see that on the chain i i don't believe it at all i want to see it yeah that's fair and um yeah i mean i think solo stakers are in a in an awkward position um i i really think that this is mostly incumbent on the on the large operations to to get with the program but they've got the resources to um to to make a change and two or three as you say large operators making a change will will make a material difference you know we'll potentially rescue the situation solo stakers you may wish to de-risk your position by swapping to another client but you know i don't want to make
anyone feel guilty you'll feel that i feel they must i think newstakers should definitely choose a non-majority client um but you know if you're an existing prism staker you know don't panic if you feel confident change but otherwise um you know this is this is not necessarily your issue to solve if if you are running one validator and you expended all of your resources and you did your best to get that one validator running and it's running prism please stay where you are you're okay um we're not talking to people running one validator right now we're talking to uh for example the one exchange who runs 50 000 validators on prism and could today change one quarter of their
validators and correct this entire problem um if they chose to so yeah we definitely i i have been guilty of this in the past i've been guilty of of promoting this message to home validators that you have to change it took me a while to recognize that your efforts are better spent helping all of us change uh the exchanges rather than focusing on your one validator and trying to make a huge difference it's good and it's symbolic but it won't really change the tide so fair message yeah great we also have uh slash dot info i think um and slash dot info
is is a product that goes over this kind of slashing stuff and then gives guides um to switch if you want to um clientdiversity.org is another one yeah i didn't um i didn't include info i nearly did but i i just the way the numbers are presented just didn't sit quite right with me so i i'd like to see a bit more work done on on how how the numbers and risks are sort of um presented i've i felt that it didn't reflect that a normal level is maybe 25 each per client um and you know the risk bars seemed a bit wrong so i didn't include that one consciously yeah that's right i'll share that um that feedback um that met the developer
of that is someone who's um contributing to client diversity in in the in with the intention of participating in the uh east taker grants round um that will hopefully begin in february it's been delayed a little bit um but that that is fair feedback uh if yeah it's gonna take a little more but i'll we'll pass on that for now latest merge spec that's a big one well this is a minor one actually but it's a a minor yeah sorry yeah it's a it's an update right so um it is a breaking change technically the main thing is around this engine api so this is the way that the consensus
client talks to the execution client or in old lingo e2 client speaks to the eth1 client um there were some you know as we um thrashed this out on on the test nets and the way um we have this optimistic sync thing going on whereby um because it's quite heavyweight validating eth1 blocks we try to do it as little as as we can so the the beacon client sort of optimistically syncs up with what it believes is is the right chain but that's unvalidated it doesn't know that the blocks in that chain that it's optimistically synced up are valid so it then needs to go back and and and validate the blocks in the chain once it
believes it's found the correct head of the chain and some of the semantics around the expectations on the eth1 client the execution clients in the old interface just meant it was doing more work than than it needed to do so we've um changed it up a bit and just changed some of the the spec and um it should uh just make things smoother breaking change we need to update the clients that means kinsuki will be um stopped that's the current merge net um in till three weeks i guess and we will start a new test net with the new spec which is hopefully the final spec we'll see um
uh and there was some confusion about the naming i don't know if you saw that on twitter [Laughter] tim's original uh article around it i got this like you know 20 minutes before i i pushed uh press send on on what's you need to do i saw his article and thought oh it's got the new net info so i included that hastily um he'd put the name as clin uh i transcribed it as klim with an m it turns out after calling it milk i don't know or link i don't know any permutation works right it turns out after uh some twitter debate that the intention was kiln as in for firing bricks which is great because if if you get the
idea behind katsugi then kiln is also it's a natural extension so um the confusion won't be long-lived so not um so yes there's an insight in into my process of putting this thing together scrambling at the last moment but yeah kiln it is uh and we'll start that in a couple of weeks once the clients have incorporated the latest um changes to the spec it's mid-february is the target for that is that correct yeah i don't you know i don't talk about dates in the future anymore um hey this is a it's a topic later but um you know one of my roles is to prepare people on the test net like when
you know when developed is not a fair question it's not fair but uh preparing to run test nets that there is some validity to that preparation for people who you know can expect to run a test at a given time yeah are your best guess couple of weeks mid february yep since we're end of january um but uh yeah we don't have a a date deadline uh for doing that um there and just to shield a um consensus thing we're doing a uh webinar it's in what's new neath two it's gonna be uh uh my colleague adrian on the teku side and i think gary schulte in on the basu side so next wednesday we're doing on the
verge of the merge her webinar to how to run tecumbesu as a as a merged client on the um test net or if we have the uh kiln test net by then i guess we'll do it on that does gary work for basu now yep okay i i i know him as suburban dad but i didn't i didn't recognize him making the transition into a client team so good for him um yes and thank you for sharing that webinar when uh i my mind spiraled off into suburban dead when is that webinar next wednesday 9th of february at 4 pm utc which is gmt um and there's a sign up page i mean
you'll have to go to ether2.news to get the link great and i will also look forward to sharing that on whatever assets i have cool so we talked about kiln i don't think that it's it's prob that we're gonna have a hugely productive conversation if we try to talk about about timing of of the merge um there there was a lively discussion on the was it the implementer's call or maybe all core devs uh anyway so there's a general
kind of consensus that the first potential target will be in early june i think it's i think it's worth covering the the kind of the parameters face it you know what what are the constraints and what what are the um the aims of the conversation so and you know you have two points of view right i mean the typical product manager or project manager kind of has a deadline you know for whatever reason that deadline is is there and kind of tries to um fit things in to meet that deadline and and we're kind of we we have a a deadline which is this difficulty bomb um which was reset in the last hard fork on each one
and pushed back the expectation is that somewhere around mid july that will start becoming a nuisance it will slow down uh the ethereum chain um the block time will will grow to 30 seconds and and and beyond um and it will just become even harder to transact yeah yeah ideally in an ideal world you know that's a that's always been the forcing function for proof of stake right i mean for all these years all the times we've pushed it back it's funny because it's always it's always not it's never enough time like it's no matter how much time is given it's still like oh we needed another month it seems inevitable yep yep so um so in an ideal world you know all things um working perfectly it would be great
to hit a merge date of late june or early july the bomb is gone forever and we're on proof of stake and you know we can we can forget about that and we have a bright future ahead um from and you know that's all nice and you can kind of order the steps until we get there and you know on a on your gantt chart it looks okay but on the other side you kind of got the client devs who've got to write this stuff and um they tend to have a slightly different view of the world which is more kind of risk-based um and uh are much more aware of the uncertainties you know um we don't have a final spec we have a candidate now um but but we don't know that it's the one um we
haven't even implemented that candidate yet um and we know there's a huge amount of testing and experience says things go wrong um and you know the happy flow is is rare i think we had a little bit of pushback from from devs um on the call just to say a slight reluctance to commit to that timeline um is aspirational but you know they they want to be a bit more cautious about it so we need a we need a fullback what happens if we don't hit that of you know we we have some issue we need to fix it takes three four weeks it sets us back we can't get it out by early july um what what kind of fallback can what can
we have and you know fundamentally we'll need to do and eat one fork and push back the the bomb again um so we talked a bit about different ways that could be organized and and so on how's it look um i don't know it's it's so it's really hard to judge from here for me the the thing is i i'm used to this development cycle and ethereum like it i'm very okay with it i i get to think the way that things work people confuse when i say that i'm excited about a june target that i think it's happening in june i don't think it's happening i don't expect anyone to think it's happening at you what excites me is that we have a target now because
you know for for years and years it has been you know well it's at some point in the future we don't know maybe 22 21 and 2022 we don't know um so actually setting any target gives us the the feeling of being closer than we've been in the past it doesn't matter what that target is and that's that's really where i'm at yeah that's fair um looking kid looking forward to christmas i get it um yeah i i like to kind of draw a distinction between planning targets and and deadlines and people often hear deadlines we are fully committed to this day if we don't hit it it's a failure uh that's not what we do planning targets however are useful
because they help you just to order events order test nets and things and just helps you to gauge whether you're slipping and find the reasons for that and so on so i mean as an example altair you know that the the fork we did on the beacon chain uh a while back that was originally slated for late june if i recall correctly and ended up happening in october and there was no single event that um pushed it back it was just death by a thousand cuts i mean not death but you know delay by delay by a week here two weeks there just a little shift just late decision making and it just went out and out and out um and we didn't set a sort of planning
target for that we didn't put the sort of project management apparatus around it and so we we didn't really notice i mean suddenly one day it was like three months late and i'm like okay i think there's a desire to avoid that as well um it's difficult for casual observers who see any date so if i put if i you know tweet that the tar the first target for the merge is june 2022. uh people many people immediately jump to well what what day in 2020 or what day in june and i'm like whoa whoa whoa it's not that kind of target it just means that we're getting closer to the goal that's it's the thing that i just want
people to understand that a target is great but it's not a date it's not it doesn't mean it's going to happen in june it means that everyone is coordinating efforts to to try to line things up for that date or that month and that's that's exciting in itself like that's all it has to be is just a goal i'm happy with that yeah me too and uh i think um merge 2022 is is pretty much nailed on i mean you know it's going to take some huge disaster for us not to deliberately careful what you say sir this is a theory of you're talking about that's i it makes me think back to uh
vitalik's original serenity uh i think it was going to be 2015 maybe it's been a while so i guess peritosh and marius have a oh oh this is the the shadow fork um that's very interesting that yeah this is this is a really fascinating uh project that perry and marius kind of kind of did on the on the side as it were just their own initiative as i understand it so they took the gurley network which is a proof of authority network um it's if you join one of the ethereum the uh e3 test nets you'll stake on gurley and
there's quite a lot of activity on it one way or another and they basically made a copy of the entire network so a copy of the state um of it but also the memple so all transactions from the gurley network in future are are relayed over to the the shadow fork so effectively it's a duplicate of gurley running alongside it but running the the proof of stake protocol so um and what that gives us is a um a real world sort of uh transaction flow to um uh test the the proof of stake network against
and the apparatus that they've used to do this could could be um applied to the mainnet um so that at some stage i mean it's heavier to do it takes a day to sync up and and so on so it's not quite so easy to spin up but um in principle uh we can shadowful the main net and basically run the whole of current ethereum on a um proof of stake system just running kind of in in the background and see all the transactions and so forth so um this is brilliant uh there it's not perfect because the sort of the because the transactions are relayed across the mempool will be a little bit different uh you know just because nodes see the network slightly differently and eventually the states will diverge and
transactions will start becoming invalid so sort of thing you want to restart every every week or two just to sort of keep them uh in sync but uh yeah it's going to provide a really really good test for the um for the clients and the and the whole proof of stake system yeah that's i i can't wait to do this on uh shadow main net i i think that will just be a really fun opportunity it will be for all intents and purposes really executing the merge um on just a version of of mainnet that we're not that's not mainnet so that that's wildly exciting do we
i guess it's hard to know do you think this will always be a developer thing or do you think that we'll actually end up running community test nets using the shadow fork of either one idea do you have an idea yeah i don't know how that works i mean because you bridge across the existing e1 transactions you don't you don't want your test note transaction to be valid on ethereum because otherwise you know yeah that's right if you're identical yeah so you want to rather than kind of shadow fork you want to actually fork it and make the fork independent if you're going to do that um that might be in road map i don't know to be honest it would be good to test yeah for sure we i mean we definitely need to test
something at that scale um yeah i look forward to that um so rocket pool um how many times a day do i say rocket pool i don't know a lot so close to one percent of all validators uh yeah you took an issue with something they said here the second largest ethereum staking provider which maybe they they meant a smaller kind of subsection uh because they they are saying they're second to lido but we all we know that uh there are many uh centralized exchanges uh obviously coinbase kraken finance bitcoin swiss um who are significantly larger
but still it's notable they're making progress yeah yeah i'm uh impressed uh so far with with rocketpool and uh yeah getting to uh almost one percent of network in how many weeks is it 11 weeks is uh it's good going so yeah all power to them i i love it i think decentralized staking is um it's super valuable i mean i think this is really a game-changer yeah i'll be honest i i thought that after launch i would migrate to something else like have an another passion project uh but as in fact like my passion for rocky pool is just increase as i
you know get more involved so um that's cool uh dvt uh with two implementations of dvt being ssv by blocks and obama yeah dvt is not uh it's not deep vein thrombosis it's um it's distributed validated technology so this is used to be called secret shared validators which is a which is such a weird name it doesn't really tell you anything about it distributed validated technology is um is better uh and so one of the fascinating things about the ethereum 2 protocol is that it's had baked into it from the start this idea you can do multi-party compute so
you can instead of running one node you can run say three nodes or four nodes that act as one node and and collaborate each holding their own private key and that's um future iterations of the spec also include this property so it's been designed with with this in mind and that really gives you resilience and robustness um and the ability so to run different clients so you could run four different clients as one node if one starts misbehaving the others just vote it out or vote it down um you have a threshold signature scheme um and it protects you against network forks it
protects you against client failures uh downtime helps you with maintenance um and you can do it all trustlessly so we could run a a network you know where you're running a a node and i'm running a node and a couple of others running a node and we're all staking but uh on this distributed system but it's acting as one node uh and we don't have to trust each other it's it's a trustless um setup so it's uh yeah it's beautiful mathematically and it's actually you know coming to fruition i mean we have these implementations now um that you mentioned i run into uh quite quite a few people who say you know fizz why don't you push dvt more um
and for me the reality is most of the people who come to east acre um have have already staked like if they have 32 east they've already stayed they're looking for solutions for staking with less than 32 ether which is something that dvt doesn't really solve but as far as like an anti-slashing kind technology i think it's it's really valuable yeah i my focus really would be on getting uh more of these decentralized pools that allow people with less than 32 ether to stake i know dvt is going to happen it's just a matter of time it is a valuable resource
yeah yeah it's kind of a layer in the infrastructure below that is it's um yeah kind of um shared staking infrastructure but you you still need to build the the shares staking solution on top of that um east wizard it's great to hear you mention that um shout out to remy roy from steakhouse um yeah there's all sorts of quiet work being done on tooling the steakhouse thing is is great i join when i can the the the regular calls they they do which is not often um but uh yeah there's uh good stuff going on um with that and sterium and a bunch of other stuff that that i mentioned
at the bottom just around making it easier to run these these clients and as a client implementer this makes me really happy right because you know people sort of want to have shiny front ends and things and you know where where's the teku web interface and the pro if we built your web interface it would hurt your eyes i promise you i take it and yeah i'm really happy to do the back end work to enable it if somebody tells us what they need to do it but um you know in terms of making a a client agnostic web interface that's worked much better done by people in the community who have expertise and uh can
you make it unified and manageable for all the clients so i'm i'm really happy to see these um uh solutions around that facilitate spinning up nodes and so forth and swapping nodes one of the things we've done recently is um this was um promoted initially by dap lion from the low star team who used to work for that mode i think and then picked up by james he from the prism team which is a common key management interface that all the clients are now supporting we've just released ours for teku and it just means that front end tools can now have a unified experience for moving keys between clients or managing
the keys and the tooling doesn't have to handle five different schemes for doing it there's just there's just one way and uh that's a great example of how things can work yeah i uh both daplaian and james he have been really uh supportive of this client diversity goal like i um you said something that really got me been it's the first time i've really thought about it this way um i have wanted you to develop a front end for teku but you sort of said something like your work is implementing like that is your focus and that's an extremely valuable goal we shouldn't also give you
uh side responsibilities and say hey do this too because that that's not that's not your target we recognize like the steakhouse community the independent developer community there's a lot of opportunity for them to come in and and do something pick up maybe some of the slack that that isn't your focus because what you're doing what the implement implementation teams are doing is the most valuable work in the community it's not our place to give you more it's it's our place to appreciate what you've done yeah that's part of it is and you know there's core stuff which which we're focused on and we don't have unlimited resources unfortunately um but there's
also this sort of idea that um we want to be kind of agnostic to the final solution and you know there can be there's no reason why uh dap node should have the same front end as stereo moment and they may wish to do it differently in order to um you know differentiate themselves um and the other thing is we don't want to kind of duplicate what prism's done because but if we don't duplicate what they've done then that just has another problem we have an unfamiliar interface and so on so i i think generally in terms of separation of responsibilities you know drawing a line we can put in the low level interface and then others can build
as many front ends on that as they like i i just just works as a separation of concerns really see in the future and that um i look for in individual stakers to be less concerned about the client they're running um so much so that tecu prison white house and nimbus are sort of abstracted away um not not a negative way just that you know the job can be done by any of the four and our target is diversity not in choice um and really i look forward to that being engineered so well that people can configure a device online get it and plug it in and it sticks with
whatever client is is there it doesn't have to be a random file but just uh simplify the process so that we're not so focused on what client you're running we're more focused on are you staking successfully so that's just my goal yeah and kudos for rocket pool for kind of making that kind of real in their environment but i did i didn't want to say it because i obviously i say rocky pool 95 times a day but they have done a great job they they have a randomizer in their installer now that will choose a random client uh and if it happens to be the majority client it will say hey are you sure you want to do the majority client do you want to try again so um i i do appreciate their contributions
do you want to get down to kind of research stuff a couple of interesting things yeah that's where i get i i'm going to follow your lead i get a little you know i'm i'm i'm a community member i see the research and i'm like i don't understand all of that so yeah tell me what's interesting to you yeah well i'm kind of skimming the surface a bit uh on this i have to say i mean the latest proposals and these the first one is really out there so this is vitalik with 16 second finality um and uh some ideas very conceptual at the moment he freely admits this is years away but um we have the information available on on chain you
know the the validator setup um we have enough information in the votes to very quickly reach finality which means that we have a state that will never be reverted so you could send money to an exchange or send you know ether to an exchange uh and within 16 seconds they would you know for sure that that would never be reverted um and um that that's final so you don't have to wait for whatever 15 block confirmations or whatever it is these days um it's you know and it makes it practical for sort of payments in person and that kind of thing nobody's going to hang around for 16 minutes or whatever 13 minutes or whatever it is now to get their coffee which was used to be the dream of
bitcoin like send them a bitcoin transaction and wait 10 minutes before you collect your coffee yes sir and that wasn't a dig that's just the way history used to like how we used to imagine it so uh so fast finalities definitely um uh interesting and useful question is how to achieve it and uh there are vitalities there are a number of ways to to attack this um and it's all about the the overhead of the traffic on the network because you've got to analyze the votes from all of the participants so somehow you've got to either make it easier to count the votes and you know verify the signatures or you've got to reduce the number of votes somehow he looks at both uh reducing the number of votes is
interesting so at the moment we have this thing that to revert finality would cost um a third of the ethereum stakes so you've got to have two thirds of validators voting for one block one checkpoint and two thirds voting for a different checkpoint so the minimum one-third are voted for both and they get slashed currently um that would be three million ether the cost of reverting finality now that that's pretty high right i mean you know we could probably have a lower threshold for that depending on what we're securing um so he has a little in his article he has a sort of internal ef um poll on what what's you know what
ought to be the cost of reverting finality which is quite interesting um and so potentially we could have fewer validators voting at any stage which would reduce the overhead and allow us to achieve finality quicker so there's stuff like that so very interesting long way away potentially but but maybe doable i just learned before we do research next week or next two weeks from now i i need to to carefully read the research so i can so i can be with you because i like i i get some of it but um fast finality seems it's a little out of reach for me right now i mean so
in some ways i'm writing for different audiences kind of when i when i do this what's unique 2 started out three and a half years ago as a very technical thing basically for my team um the tekku team um i was writing for them just so that they you know take for away from them the burden of keeping up with the spec changes which were just insane and keeping up with whatever the latest things were and it was quite in in the nuts and bolts of of what was going on over time i've sort of grown an audience but also raised the level so it's not nearly so in the nuts and bolts anymore um and in the research stuff i was kind of trying to highlight a few things but not you've made it so much more consumable like um i'm i'm
more able to consume the entire article now than i might have maybe it's because i've had more exposure to it than in the beginning when i would listen to the calls read the article and still not know what was going on yeah i would over time i've added a lot more narrative i mean it's one of the things i talked to evan venice a lot and andrew cut up and you know i don't want to replicate what they do in um week in ethereum they do their thing i don't want to be an alternative to that i don't want to kind of copy what they're doing i'm trying to do something different here i'm adding a lot more narrative over time i've added more opinion which is fun and um trying to unpack some of the media stuff
a bit more so um hopefully people appreciate that i i kind of enjoy writing it so um though yeah when it gets to midnight on friday and i still haven't finished i do get a bit kind of tiff stressed out yeah um so i'm gonna take another swing at this one can you tell me about secret non-single leader election yeah so definitely not um not without notice um this thing about validator anonymity so one way of attacking the chain is we know ahead of time who is the proposer of a block in the next two in the next epoch so we know who the next 32 block proposers are and if you know their ip address if you somehow can de-anonymize
them which is not impossible then um you could ddos them and you could just stop the the chain producing blocks um so that that's unpleasant so how can we avoid that so one option is that the the only the validator knows itself when it's its turn to propose a block so i'm slated for um block you know three billion um for that slot and i uh only i know ahead of time that it's my slot and the rest of the network doesn't find out until afterwards and so the the attacker doesn't have any notice and various proposals involving snarks and zero knowledge proofs and other mechanisms fairly complicated have been
put forward to do this and and i talk about whisk here which is one vitalik at the moment we have this model where there's exactly one proposal per slot and if you don't show up to do your duty then it's an empty slot so vitalik sort of done a thought experiment of what if we relax that constraint if we allow multiple proposals per slot and then we can um it's much easier we already have mechanisms uh to select a subset of the validators um to uh which we use when we aggregate attestations and things we just reuse that so we we select on average five sometimes it might be three sometimes it might be seven uh occasionally it will
be zero but very rarely um and they propose a block in a slot and then you've got questions about how do you handle having multiple blocks in the slot which is a different problem but maybe easier to solve um so uh that's um yeah so that that's that one in my mind i i have vdf as the solution for that is is vdf is that is that mothballed research or is that still uh yeah yeah solves a different issue i think which is around quality of the randomness available to us so at the moment we have quite good randomness in protocol but it's not
perfect it's slightly biasable so um but if you want really good randomness then the gold standard is this verifiable delay function thing um justin drake has been working on it um i i haven't heard much about it lately either i my interpretation or my understanding was that it it allowed for essentially anonymous block proposers that that could be revealed later um but again i'm showing my my my weakness yeah i'm a bit hazy on it to be honest mate so let's move on good idea um let's see alex stokes uh oh uh withdrawal from the beacon chain
um yep progress um so there's work to do on on both sides we need um a withdrawal mechanism on the beacon chain side uh so that uh we can signal that the validator balances to be converted into real eth and then we need on the execution side we need to create that eat out of nothing you know we need to make sure that the validator balance on the beacon chain goes to zero and the account on the execution side is credited with with that balance or if we just allow we if we allow withdrawals of just rewards and keep the stake then equivalently we need that so how does the execution layer become aware of this
uh we need to change the evm make it aware of the beacon chain so something happens on the beacon chain and then the evm can become aware of it so we encode the state root of the the beacon chain in the evm make an opcode for it um and this this makes effectively ethereum self-aware i mean i don't scare anyone here it's not it can now prove things about itself like the state of the beacon chain is accessible not just the validator balances but everything is accessible to the evm and you can make proofs about things that are happening on the beacon chain in in the evm which is fascinating to think through the kind of
possibilities so it initially allows withdrawals to happen but you know in future there could be other things going on here i think from the layman's perspective uh you know people are looking forward to the merge a lot of people are under the the misperception that the merge means that uh deposited ether will be unlocked but what people may not realize is that tooling hasn't been written yet um the the withdrawal tooling hasn't been written and so after the merge the next uh area of develop will be um like you said this awareness between each one of e2 so that withdrawals are possible and of course that is shanghai which is the the final step in
implementing um proof of stake and at that time withdrawals will be uh available did i say any of that correctly yeah get ready for when withdrawal i mean you know when mergers getting a bit tired 2028 come on i mean let's let's no let's not i was gonna say let's be honest it's not gonna be xxx but i will i won't uh don't play that game yet we'll give it a few weeks let me see regular calls anybody who's looking can check out these i'll zip through them really quick so the implementer's call was 27th of january we've pretty much talked about the same things that are relevant there
yeah steakhouse had a call on january 19th so those are historical upcoming is what's important um wednesday february 9th on the verge of the merge oh this is what you were referencing yeah that's what i mentioned earlier yeah so and the other one is the merge community call number three which um tim boco and i think um trent vanessa are hosting which is basically for any users of ethereum who are concerned about the merge to get an update on where they stand uh what's going to be happening ask any questions you can go to the github issue and ask questions ahead of time and that i think will be on the ethereum foundation youtube i don't have any
further coordinates for it than that but there's a github issue with the agenda and so on i look forward to sharing those more um also february 7th is uh an e-staker day we're planning to release more of this client diversity data so that we can have a coordinated push to to kind of focus our efforts in the right direction because for so long we've sort of shot in the dark about uh who needs to improve client diversity but we plan to maybe coordinate and target that effort a little more beginning february 7th so fantastic so that's next monday right yes
something like that so ben i i think i like it i don't know how do you feel yeah i feel i could talk for another couple of hours you uh i think maybe not maybe maybe we spare our listeners if anything i'm gonna wrap it up throw it on youtube um we'll get two views and we'll call it a success oh yes sir i look forward to that sweet advertising revenue advertising revenue are you talking about is there something i'm supposed to know are you getting that money um all right i thanks again and i hope we can do it again soon uh maybe the
next monday of uh after your next letter does that sound like uh yes sir sounds good to me thank you for uh suggesting this really appreciate it and yeah happy staking thanks for your time