Eth2/Lighthouse update

Transcript

hey guys my name is mehdi i'm actually surprised that a few people are here like a handful of people considering vitalik is giving his talk in 10 minutes so thanks thanks for being here i'm a co-founder and director of sigma prime we are an information security consultancy uh mostly based out of new south wales in australia um i'm gonna talk about lighthouse and ethereum proof of stake we can't no longer refer to it as easter as you guys know so yeah the idea is just to give you guys an overview of what we've done over the last few months and where we're headed uh and hopefully i can leave some time for some questions if any of you guys have any um yeah cool so i mentioned this before we uh we performed security assessments um

throughout the entire blockchain stack i'd say we work a lot on ethereum as you can imagine um some of our clients are listed below of a synthetics chain link and a bunch of people i'm sure you've heard of but i'm not here to talk about infosec i'm here to talk about lighthouse and eth2 so lighthouse is our little baby the rust implementation of the ethereum proof of stake protocol um it's been around since july 2018 i think the first commit is from july 2018 it's written in rust as i said it's free and open source must highlight this considering that not necessarily all clients are open source these days um and it's heavily focused on security as you can imagine considering the

dna of the company we've spent a lot of time optimizing it for performance as well so it's fairly fast um so i'm sure a bunch of you most of you know that we have four production clients these days so lighthouse a little baby written in rust nimbus written in nim developed and maintained by our friends at status prism um written by prismatic labs in go and teku written in java and developed by consensus so unless you've been living in a cave for the past few months you probably know that we've launched on december 1st quite successfully i must say and yeah it's been going pretty pretty well so far

i've put together a few uh metrics that might be of interest we have about 195 000 validators i think everyone roughly has made about um every validator has made about two ether i think these days um and the yield that you would expect to generate from uh staking on the beacon chain is around six percent started much higher of course and then the more valid data we have well the data we have sorry the less rewards we get so about 90 to 93 000 ether have been generated by the protocol which is pretty cool to see the participation rate is pretty exceptional 99.4 percent so those two uh everyone who's been running their

validators just out of curiosity anyone's staking on e3 here yeah cool anyone's running lighthouse hectic well played uh awesome so those were cool metrics these aren't as cool um we got 140 to 46 slashing sorry since the start of the beacon chain so um as you probably are well aware of uh the protocol essentially slashes um allows you to slash validators that are performing their duties properly so if you can prove that there is indeed an equivocation in either a double proposal or a wrong vote wrong attestation the protocol

essentially rewards you gives you some of that um ether some of that stake and slashes the valley data so most of them if not all of them i think i'm only aware of one case where we didn't actually wear the slashed validator was like a hobbyist someone who was actually you know running its validator for me to some home pc i think and wasn't extremely careful and what happened to them was that they actually run the same process twice so yeah the slashing protection didn't really help there and unfortunately they got slashed but everyone else so 99 or 98 of the slashed incidents are due to custom redundancy setups right so a

bunch of people are like okay i'm going to customize my setup and i just want to really have the best uptime possible right so i'm just going to have this very complicated set of hosts that will have dedicated sort of failovers and things like that and no just just don't do that just avoid doing that it is definitely not worth the risk and we've had one main net incident as you probably may have heard of it was a few months ago and for about 18 epochs one client was offline meaning that for 18 epochs one client was not able to propose blocks so thank god we have you know three other clients so

the network did not really suffer much from that which is good so client diversity is is great and this is what we strive for um but um yeah something to kind of be aware of this is why we had a big call to the community to be like okay guys don't all run the same client okay this is very important we all have a responsibility when it comes to client diversity um yeah so i want to spend some time talking about what we've done with lighthouse with the lighthouse team over the last few months so a lot of people can be like okay you guys launched the beacon chain what what did you guys do after that um we've been working um and we've added beta windows support for our users so we'd not recommend running that on

mainnet yet but if you have a windows host and would like to take a crack at validating on one of the test nets feel free to please raise any bugs that you may find on our github repository that'd be much appreciated the other great feature that uh landed a few months ago was something paul has been working on for a while which is a massive drastic reduction in our memory usage that was highly appreciated by the community especially for people running lighthouse on raspberry pi's and other constraint devices he's he's done an amazing work researching the actual memory allocators and really understanding how that works at a very very low level

and tweaking that to our purpose another great feature was the reduction in f1 calls so i think it was an 80 or 75 reduction in the actual f1 so obviously as you guys know we need a lighthouse node and a get node or an open ethereum node or whatever you guys run these days um and yeah mac's done an amazing job at reducing that meaning that you can actually now not that we recommend that but you can actually hit the infurera free tier um and you know just run your lighthouse valley data and hit infuriate without having to pay for it which is pretty cool um another great feature i think that the community really really enjoyed was the monitoring

with the beacon chain app so i think only prism and lighthouse support this at this stage but it essentially allows you to um yeah get notifications every time something goes wrong so if you're run out of disk space or if some re for some reason your cpu usage just like started spiking same for your memory usage you'll get a nice notification and you'll know that you probably need to do something another important feature i think which goes back to my point of not running custom redundancy setups is this the f1 node redundancy we allow you to provide a list of f1 nodes right and then we automatically lighthouse will automatically fail over so the first one

doesn't connect to the first one you can connect to the first one but you don't get the response that you want you automatically fall over to the second one and so on you can actually provide as many as you want i don't even know if there's a limit um i don't think there is but um yeah so don't don't run custom fancy weird setups just use this be much much safer you can do exactly the same thing with the beacon node as well so you have a validator client which is responsible for signing your attestations and blocks and whatnot and the beacon node which is the piece of software responsible for like the networking the state transitions et cetera et cetera so in case you were worried that your beakey node would potentially you know have have some issues you can provide a list of beacon nodes

and again we'll just fall over to the next one cool so that's what we've done so far and i was like to spend some time talking about what we're going to be doing and what we're working on today um this is a great graphic put together by trent thank you trent if you're seeing this uh you've probably seen this a lot during the last few days but it is an amazing um sort of illustrated road map i want to talk about the alte upgrade so we're going to be forking the beacon chain right this is gonna be quite interesting it's the first fork uh on the beacon chain um and the main feature um of this of this upcoming upgrade is the sync committees right so you

probably remember that when the research team put together the the e3 protocol one of the design goals was to make it very very friendly for like clients to sync obviously we didn't quite get the time to do it right during the first phase zero launch and this is what altair essentially brings to the table right we introduced a new set of duties and a new committee composed of 512 validators and those 512 validators essentially rotate every day or so 26 27 hours and they're responsible for signing block headers so that your like clients are essentially able to verify the the chain without you know syncing the entire

state this is going to be i think i believe a game changer for you know browsers uh embedded devices and other resource constraint hardware so that's one of the major features if not the major feature of the altair hard fork the next one is a reform of the accounting so the how we actually compute rewards and penalties um it's meant to be simpler we're the research team has intended for this to reduce the complexity of the spec and one of the things that i think is uh is pretty cool and to keep in mind is that we're now having the inactivity leak so

as you guys know when your validator is not performing you start losing money right but if we if we stop finalizing as a network we all start losing money and quite a lot of money but obviously if i'm online why should i be penalized the same way as if up you know as if another validator who's who's actually offline so this is what the per validator in activity leak introduces which is kind of more in my opinion a bit more fair in terms of of rewards and penalties so as i said we've added this sync committee um so it's a new duty for proposers sorry for validators and there's other like small tweaks that have been done as well when computing the the rewards um another change is the update to the

penalties so it's like i think ben eddington says that quite well it's time to take the training wheels off and um you know we're doubling the the actual slashing penalties so you can lose up to 0.5 ether we might double that again in the future and we're increasing the penalties for again fully inactive validators that now can lose up to 15 of their stake um it's going quite well we had a devnet a few days ago which went surprisingly smoothly um so we are hopefully expecting to fork the chain within the next few weeks uh i'd be surprised if you know this doesn't happen before

september probably way before that testing has increased thanks to the ef research team who's been putting together an amazing set of tests in the last beta we've had eight alpha versions one better version and we've revived the fuzzing project thanks to patrick who's here and we basically try to catch bugs in the state transition functions that don't have that much time to talk about fuzzing can refer to some great blog posts put together by the team uh to walk you through what we're doing there um one last thing that we are working on is weak subjectivity sync and this is a pretty exciting feature of the beacon chain

as of today if you want to sync the entire chain it will take you roughly a week i believe depending on which client you're using give or less more or less i think six or seven days with the weak subjectivity sync it's a completely different sync process you essentially start from a known trusted beacon state and you say okay i'm going to trust this i'm going to just compute the hash tree root of that compare it to what it's supposed to be and say okay now i have this trusted beacon state i'm going to sync up to the head and once i have all these slots synced i'm going to sync backwards and backfill previous blocks and all of a sudden it only takes you minutes to sync the chain instead of days um i believe

teku is the only client who has this running in production lighthouse is obviously working on it so his nimbus so his prism so expect this to happen to be supported in your favorite clients anytime soon um and obviously the merge so this is this is happening in the background as well um lots and lots of engineering work um has to be done on the execution client side so the geth open ethereum etc side of things but it's super exciting this is probably the reason why sigma prime got involved with e2 to begin with to you know say goodbye to these guys um yeah so as i said i really wanted to

make it short and sweet so that we have time for questions hopefully we have five or more minutes for questions so yeah hit me up [Applause] uh so as far as i understand uh after the merge there will be two clients running side by side is add1 engine and beacon chain a client so uh what's like the view uh of the next steps so are there any plans to

combine these clients into one into single process or uh yeah i just that's that's a great question no formal plans yet but the community really really wanted a quick merge so the quickest way of merging the two chains was to essentially have the two clients there is obviously almost uh almost a decade of history now with gethin they're able to deal with the execution side of things really well uh and obviously we have the consensus side covered but i wouldn't be surprised if in three five years time we essentially end up with one client um yeah we haven't really you know thought about this that far but uh it kind of makes sense it's just in terms of complexity if you

want something done quickly uh that was the really the shortest path to make it happen yeah that makes sense absolutely yeah so you absolutely write two two different uh processes so the f1 process and the f2 process or you know we should stop referring to these as f1 and f2 so the ethereum execution process and the ethereum consensus process will be running on the same machine even though it's not necessarily a strict requirement but i would strongly recommend running them on the same machine but uh yeah that's that's the current vision that's what we're currently working towards but um i think i think we got a point and

in a few few years time will be hopefully looking at you know unifying everything and having one single process thank you must welcome um i have a question in regards to your answer to his question sure you said that eventually probably there will be everyone will consolidate to one client but then doesn't that cause the same problem that you were saying that there was one client that didn't work for a while so it's better if we don't have somebody on one yeah good point i probably i wasn't clear enough what i meant was we'll be merging the execution and the consensus side okay right so perhaps lighthouse will be working and don't quote me on this i'm just speculating we'll be working closely with open ethereum because they're in rust as well so that we can come up with one

ethereum rust client okay and maybe prism and you know go ethereum will be doing the same thing right but client diversity has always been a priority and i think it will remain a top priority so within like teku and basu maybe exactly okay exactly go and sorry get and prism uh nim nimbus has already an eth1 client so it kind of makes sense for them to pad two okay and see how they can be merged into one single binary all right okay thanks yeah sorry first of all great job on lighthouse i really enjoy using it thank you thank you um do you actually support arm like officially or something because like on the release page there are no armed

binaries and i just like kind of built it myself for that yes is that a good idea or no it's fine we've got we've got plenty of people running around in lighthouse on armed devices on raspberry pi's and whatnot um we i don't think we have binaries distributed for that platform um that would be pretty nice okay guys feedback taken thank you and i hope you you also use the monitoring endpoint from the app absolutely nice it's been uh it's been great thanks for the great work done by you and your team on that one thanks a lot for your presentation is a remote bls signer a feature that

can be used right now is that ready yet no no okay no when when do you plan to okay so it's a good question we've been asked by multiple institutions for that feature and it's it's perhaps 90 ready it needs a lot more testing and i think the current plan is to have it as part of the either the next release or the following release it was meant to land in 1.4.0 but we prioritized the other features um it's just you know the lighthouse team is is until relatively small though decent so we're about 9 10 you know full-time software engineers working on this and

obviously between the merge altair phase zero support and whatnot it's uh it's sometimes difficult to address all the requirements that the community has but it is a strong one particularly from the institutions and we've heard them loud and clear and that's definitely something that will be will be shipping soon and regarding that feature the eip i think you submitted is that something which would be integrated in other clients that's not hopefully different yet they didn't agree um i don't think we've had much uh talks amongst ourselves to standardize that yet but as you probably saw we pushed we put together an eip

home and worked quite hard on this and put together an eip that kind of made sense and uh i believe we collected feedback from great people like martin and and other folks from the f1 world it's nothing crazy like it it's hard for me to believe that people wouldn't converge towards this standard because it just it kind of makes sense and it was very really really simple so that everyone could just have the same api but we haven't had those conversations yet to be quite honest thank you very much was welcome all right cool thanks guys thanks for

coming cheers you