Performant Eth validator key management

Transcript

[Music] [Applause] testing testing yeah hello hey um so today I want to talk to you about keys um specifically I will tell you about Eve stacking Smith that's our key generation tool that we built and open sourced earlier this year and along the way I also kind of want to demystify ethereum keys and whatever is involved in the whole if you're invalid it's a life cycle um a quick quick introduction about

myself I'm Jennifer I'm engineering manager of our stagging product Opus and I work for chorus one whereas taking provider and we run validators for over 50 networks and I would say it's taking is kind of a thing and most recently we launched Opus as I said it's a validate as a service taking API and we also build a queued portal I'll show you some screenshots and it's kind of targeted for institution rails and we want to roll it out for retail as well um but let me first tell you why we decided to build our own key generation tool

so very early on um when we started working on automating our validator infrastructure and we turned to other tools that we found open source so the most famous one is the staking deposits here line um it's a really cool CLI targeted at solar stickers and so you can use it for generating keys and deposit data but there was a couple of things that didn't work out for us especially when creating keys on a larger scale um so those points were like we found it a bit difficult to like integrate and package the CLI in our rust backend um what does taking CLI also does it's um basically it outputs the private Keys

as an encrypted format the so-called keystore and writes those files on disk and that wasn't super suitable to a use case so basically we forked the project made some customizations and in this process we found that it was like sometimes challenging to Upstream the changes coming from the open source project as I mentioned like because the staking deposits here I wrote this file on disk it was slowing down our key generation process a little bit and it would have required us to make some infrastructure work around to in to ensure security so in one of our company white hackathons the ethereum team actually decided to tackle this problem and we created an MVP to improve our key

generation process and this was the birth of each taking sniff um now let me dive a little bit more into the kind of improvements that we found so the next slide will get a little nerdy So to avoid uh kind of heavy lifting and to avoid having to write everything from scratch we're interfacing a lighthouse account manager so Lighthouse is an ethereum ethereum consensus client it's also written in Rust and open source so that was really convenient for us to use and the account manager is basically a binary that you can use to generate your keys so essentially we optimized it in such a way that all the operations are done in memory and the key material is never written on file on the file system

we use Eve stacking Smith basically as a library in a rust back end so that basically reduce code complexity by a lot for us and as I mentioned before as taking deposit CLI what it does um when it generates your private key it outputs it as an encrypted format the so-called key store um and already mentioned like it's not really suitable for our use case and we kind of noticed that by avoiding to generating this keystore we actually like sped up the key the whole key generation process by 98 percent um so that was a major kind of performance Improvement for us um now I said already like we we use if taking Smith as a library in a rust back

end you can also choose to use it as a CLI um and if you really need um to have a key store generated um of course if second Smith also does that for you um and during development we actually found some tiny Improvement you can make by default there's taking deposit CLI will use a key derivation function which is called Script and that's super secure now we found if you use a different key generation function which is called pbqdf2 you can optimize a little bit for Speed and I know like everything in software engineering everything is a trade-off so if you want to have more security you can you can choose script if you want to optimize for Speed you

can use a different key derivation function so earlier this year we published a Blog article you can find it on our website if you want further information about Eve staking Smith also the project is open source we accept PRS so if you have any feedback also you can reach out to me on on Twitter um yeah I think one also takeaway I had from this whole project is we do a couple of hackathons um like company-wide hackathons in a year and if you have talented engineers in your company I would sometimes give them the freedom to work on something that's outside of the roadmap because I'm always amazed what really comes out of these hackathons again one of these was Eve staking Smith and I'm super

happy because um yeah it improved a lot for us for a validator infrastructure now this was kind of like an introduction to Eve second Smith and what I kind of want to do now is walk you through the life cycle of the ethereum validator and then kind of zoom in um where all the keys are generated and what you actually do with those keys so this is kind of like an overview um and again I will jump into each of these steps to give you more details now the first step of course is the key generation you can't have a validator without keys and the second step is actually this famous deposit that you have to make it's a you have to pay 32 if per validator

and when you make this deposit I think by now you all know the validator doesn't become active straight away this queue there's a validator queue that you join it has famously become quite long uh we'll dive into this as well a little bit um but then once your validator goes past this queue and it's active and it has to perform some duties so this Duties are if you perform them well you get some rewards and finally I'm not sure why you would want to but you could exit your validator um so if if you do that you get your basically your deposit back now um let's jump into the use case where you want to create a validator so you could use Opus our platform and and then you just couldn't you just go there

you connect your wallet you have to have at least 32 if and and some for gas and what you do you provide our backends with two addresses the first important address is the withdrawal address so this is where you will receive your reward and it's also where you will receive your deposit back and the second address that you provide is the fee recipient and that's where you get your priority fees and Mev Rewards now you've connected your wallets and you click the button confirm a mistake and there's quite a lot that happens in the background right so this is where if stacking Smith comes into play so he's taking Smith will generate all the key material and deposit data let's first look into the keys

so is taking Smith uses some Randomness to generate an unpredictable seat and converts it into a 24 word mnemonic phrase and this is not something we've we've made up and this is according to the paper 39 standard and then from this mnemonic you can actually in theory generate multiple multiple keys right and this actually this mnemonic phrase you want to also store safely because you can use it to regenerate the keys if they get lost now based on the seeds we generate a BLS public private signing key pair BLS is a cryptographic signature scheme which was introduced with the move to approval stake and has some really neat properties that will explore further

down the line now it's called signing key because this key will sign off any validated Duty that you perform and we'll also look into this a little bit um so first look at the prime sorry the public key so this is basically the identity of your validator so if you're looking for your validator on the beacon chain you will always use the public key now I won't go into basically um there's public private key encryption a lot but there's something I want to highlight because it gives us some really neat properties um okay so I'll walk you through this early if you have your private key it is like white key on the top and you sign a

message you output a signature and then someone else can go through this verification process so given the public key that everyone can find on the beacon chain the message and the signature it's really easy to verify that the public key signed exactly that message so the cool fail the good cool thing that we get here is that we verify that the message wasn't tampered with and we also verified that the sender signed exactly that message now um I already said before one kind of important input that we receive is are the like withdrawal credentials so essentially this is the address you provide us and then whenever you want to

exit your validator you will get the deposit back there and this is also the address where you get your rewards of course if this address is wrong um there's basically nothing you can do um and something you maybe see here like we generated a designing key and you provide us with the virtual key so that means you with the withdrawal key have ownership of the stake that you put in and we own the signing key and store it safely that means we can manage the stake for you and essentially this is how such a long custodial staking service event possible now um that we have both basically both keys we can generate this deposit data um of 32 if

and in The Next Step so basically when this whole process is ready your like Opus will open up your wallets and then you will sign a transaction and basically this is a transaction to the if deposit contract and this is now the step where we register this validator let me zoom in a little bit what is what this deposit data really means so um essentially we need to tell the ethereum network that we want to run a validator so the first thing you see here is our public key again I said the public keys are the identity of our validator the second one is the withdrawal credentials again now we need to basically register validate and say if this is exited this is what where I want to um first have my rewards and then

also my deposit back and at the Fret field now this is the interesting one this is what where I walked you through how the signature process works so what we're doing here essentially is where the message that we're signing is the public key and of draw credentials and we're signing this with the private key so what's really interesting here is and in this like deposit registration process and we're proving ownership of this public key on registration and this is to avoid um that anyone can like pick any any public key um now the last field essentially the deposited the route um Roots you'll find them a lot on the beacon chain they're kind of a cryptographic digest um just know for in this field and it's

important to verify correctness of the inputs now if you kind of like look at this on a higher level so this process actually has three important functions for us so it offers a simple resistance and because if validators running a validator was for free um people like attackers could flood the network right um we also provide accountability because we're registering uh validator with the public key and we're signing it with the private signing key um we're basically providing accountability and then thirdly it aligns incentives right um if I pay my deposit I also want to protect this deposit so I want to make sure

um the valid data runs well and performs the studio so I get rewards so if I misbehave this validator would get slashed now let's come to the interesting part once we once we made the deposit successfully um everything is picked up by by the ethereum network and the validator now joins the activation queue I already teased a little bit it has become more famous this day because with the rising demand of ethereum staking also the size of the queue increased there is a good reason to have such a cue right the reason is we want to have we want to ensure stability in a valid data set instead of letting validators come in and out this would really like

create a lot of instability and the way the ethereum network deals with it is their so-called churn limit the churn limit is basically the amount of validators that are allowed to join the queue per epoch now um as you can see I took the screenshot two days ago I think it's like at the moment it should be around 36 days and from the point of deposit until your validator becomes active so um if you want to run a validator this is really annoying um because it's quite a long time so you could say hey let's just increase the churn limit um but the downside here of course is um there is also risk that there are also risks involved with just increasing

the value data set like a really big value data set could re could kind of like lead to like a risk of reorgs there's also a heavy load on the validator client we recently saw ethereum having some like finality issues and this was also kind of due to having a lot of activations coming in so you really need to be careful which kind of configuration you're tweaking um and there there's a lot of talks um right now how to deal with the valid data set in the long run you want want to reduce the size of the sets and not having grow infinitely but this is a completely out of talk that I won't get into

now in The Next Step um while we're waiting and we can actually set up the validator infrastructure since the move of pro to proof of stake what you need is basically you need to run an execution client and a consensus client I won't get into too much detail here my colleague and I we gave a workshop at Defcon last year where we basically walked through the whole ethereum consensus protocol and then also like run a demo how you can spin up a validator on test net there's also actually if you watch closely a block art there will be a Blog article but my colleague Maxim Coolidge who will also he's writing about kind of the key management also the risks involved of running a validator as well as how we

mitigated in our infrastructure now key wise um what you need to know here when we set up the validators and basically we load the public private key pair into the validator configuration and also configure it a few recipient that was provided earlier so maybe you noticed also like if taking Smith doesn't actually generate this previous APN so this is something that we receive now um once a validator is active we can perform our validated duties and finally get some Rewards so I want to kind of like zoom in here again what are the validated duties and where do our keys get involved here so I've mentioned now a couple of times

the fee recipient um if you propose a block this is what everyone's really Keen about right um you will receive fevers uh Mev rewards and priority fees so priority fees are if you send a transaction you can add a tip so your transaction gets picked first um and when a validator proposes a Blog they're actually like signing this with a private signing key and due to the signature that is generated here the other validators can again know immediately which validator propose which block now um actually most of the rewards are accrued by the attestations so every Epoch every validator gets the

chance to basically share the view of the world so at the station serve as votes from validators so basically they vote for the most recent Justified block and the first block in the current Epoch and by combining all these at the stations um like all these votes from all participating validators the network can finally like reach consensus about the state of the blockchain now other stations are also propagated across the network and so if we propagated them individually there would be a lot of load on the network so there's something neat we can do um we're aggregating these attestations from validators and this is actually where these PLS signatures the

cryptographic signature scheme that we're using um comes in really handy so what we can do with PLS is we actually aggregate these signatures over the same message and and that could be thousands of signatures and these can actually be checked in just one verification operation um what's also really cool if we aggregate this signature it actually always stays the same size 96 bytes and this is really a massive gain in scalability and that's why the ethereum consensus is even feasible now due to the collection of all the signatures we can easily check which validator has published there at the station and obviously if you publish it

at the station then you receive a reward so another um basically another Duty that we have to fulfill is the sync committee that happens more rarely basically what you do if you're a member of the sync committee you continually you continuously sign a block header that is the new head of the chain at each sort now these were kind of introduced um so light clients can yeah quickly determine the head of the chain um but again this happens fairly rarely though I think like the rewards are quite favorable now um let's look at the other side of the coin what happens if you do not um perform your validator duties um so again like something that could

happen is you fail to propose your block so that leads to a lot of opportunity costs um now something more tragic like the big risk actually if you by accident run two validators with the same key in your that could be like due to the bug in your infrastructure this could lead to double signing and let me just kind of explain like basically um I already said if you propose a block you sign it if you propose two different blocks and you propagate them to the network you essentially um proposing two contradicting blocks and that could lead to double signing which leads to slashing so I think double signing has been has been talked about a lot actually one example I wanted to bring up is if you if you're

running Mev boost um essentially you're like Outsourcing the block building and the relayer usually forces you to sign a block and this is p this is so you give the relayer basically a commitment and the reason why this works is because if you now fell back to um your local block building and you signed a different block and propagate it to the network this essentially is then you would be double signing and that could lead to slashing so this is why this um this whole kind of chain at the moment works um similarly to the other stations you can be missing at the stations which is not super crucial like your validator can be there can be some downtime um but obviously what could also happen

if you're running a validator with the same key two validates with the same key and this could lead to double voting which is also a slashable event and now um on to like the Sig committee so there's actually no slashing involved but you could fail to fail to publish your designed head of the chain um so basically the same committee this means that we're really relying um on the sync committee being honest foreign the final like the end of the life cycle of our validator so that's actually like a question we receive a lot so now we're we're now making um it to the end of all the states so um what if you want to exit your

validate this because maybe you want to receive your deposit back um essentially what you have to do like very similar to kind of uh the previous pattern so maybe I think by now you kind of understand this process we need to sign um an exit message with and we sign it with a private signing key and then we publish it to the beacon chain essentially now question that we get a lot is um well what happens if like Opus API is down like how can I accept my validator um this is because course one owns the signing key now what you could do to kind of work around this problem is when you create your valid data you could already generate the signed Etc we could generate the sign exit transaction for

you um so this is like very sensitive information if someone gets hold of it they could just take it and publish it um onto the chain obviously you would still get your your withdrawal to your address but obviously with this long queue this is still painful if your validator exits if you don't want it to I'm not here you already see there's like a dependency on whoever is running your validator infrastructure and owns your signing key um there's actually a proposal um coming up by your by the Firm Foundation so they're proposing that this um exit message can actually also be signed by the referral key and if this is the case then non-custodial Services um kind of have you more independent

because that means that if you're a critical withdrawal key that you own you could sign this exit message and propagate it to the beacon node yourself um for me it basically means I can delete a bunch of codes and maybe I'll add a feature to Eve staking Smith where you can just generate design exit transaction and with your overflow key and uh yeah Happy Days you can exit your validator anytime now um I hope this was somewhat helpful for you um yeah again my name is Jennifer you can add me on like message me on Twitter at like message me on telegram if you have any more questions um yeah thanks a lot I'm also around [Applause]

thank you [Music]