SOTS #7: Rules of thumb for slashing

Transcript

01:05 - Welcome to EthStaker

hey superfits here uh november 17th 2020. i won't tell you this but this is my third start of this video um yeah anyway the last couple days i've been uh sharing with you all my vision for the eatstaker community um hopefully that's our shared vision uh but i want to get away from that just for a little while because really what we're here for is the technology of ethereum and while personally i feel like my biggest contributions are in building the community i also recognize that a lot of community building comes with

spreading valuable information and so what i've seen for the past few days are a lot of questions around uh slashing and you know what does slashing mean and how does it really work um and so i asked around a few people and um jim mcdonald who is from attestant offered to speak with me and jim is he's one of the people that is just amazing at breaking down complex concepts into simple language that i can understand and so he and i spoke for an hour today that call is posted on

02:15 - Jim McDonald breaks down slashing

eat staker on the youtube channel if you have some time i really encourage you to listen to it jim is um one of the most knowledgeable people i know regarding ethereum in general um he is responsible for a lot of the the keying as in the key management systems for ethereum two he also uh has a service called a testant that stakes for institutional holders um he also has created a staking system called vouch and dirk which you should really look into uh he's just a phenomenal person to speak with

and i want to share with you some of the things that he that came up in our discussion today so slashing is um essentially an event that occurs when a validator does something either purposefully or not purposefully that's perceived as malicious by the network and the network then responds by um penalizing that user and ejecting them from the network so you can be on either side of that equation you can be the validator who commits the mistake um or you can be the validator that uh runs a slasher and identifies a slashable activity and then submits it to the network or

03:15 - What is the definition of slashing?

submits it in a block proposal i feel like a lot of people know the basics if you don't know the basics um you really should check out the entire video with jim actually i think you should do that anyway because it's just it's a great video um but there are three things i'm always looking for uh what do i call them nuggets i guess kernels of truth uh rules of thumb i think i called them in this video and i have three of them that i'd like to share with you today uh and so these the first rule of thumb is um only ever store your keys on one machine the best way to prevent being

07:30 - A few kernels of truth to avoid slashing

slashed is for your validator keys to only ever run on one machine and then if you need to switch to another machine you take that one entirely offline um and then bring the new keys up on a new machine you should never run a hot backup of your validator keys this will result in a slashable offense so rule of thumb number one for slashing is only run your keys on one machine rule of thumb number two for slashing is if you're doing maintenance to your computer uh to your server wherever you're running your keys when you turn your when you stop your validator and turn it off wait 13 minutes before starting it back up and that is the time

for two ebox to pass 6.4 minutes each and that will ensure that you do not submit the same proposal twice or the same uh attestation twice uh and either of those offenses would be seen as a slashable offense now in all honesty the odds of that happening are low but we want to avoid low risks if we can and the rule of thumb number two to avoid that is to leave your validator off for 13 minutes between restarts and that will ensure that you don't uh accidentally submit either the same block proposal twice or

the same vote twice that will mean that you'll miss um an attestation and that's okay you're gonna lose a few pennies uh that's okay that's that's it's better to lose a few pennies than risk a a slashing event uh and the third uh kind of rule of thumb that i thought was really valuable that um when i when i spoke with jim was um yeah i had intended to run a slasher on the same server that i'm running my validator it's a beefy system and i think it will do fine but kind of what i learned is that my odds of catching a slashable offense on the main net um

may not really be worth the cost to hardware on my staking machine so if i'm running a slasher on my primary staking machine and that slasher it's very resource intensive occasionally misses me to um miss a an attestation or maybe it reduces my inclusion distance occasionally the likely reward that i might get if i ever caught a slashable offense is not going to make up for that loss so the third rule of thumb is if you're going to run a slasher run it on a separate machine than your validating machine that way

your validating machine is secure and stable and you can monitor its performance and upgrade hardware if you need to but you know that no matter what happens your uh your slasher is not going to interfere with the performance of your validator um and so there there's so much more that i learned about uh who can submit slashable offenses um really many slashers can submit uh slashable offenses to the open network to be included in the next block and that may be you you do not actually have to run a slasher to claim that slashable offense and if you do observe a slashable offense it's actually a low risk

that you'll be the one to include it in a block so much great information i really appreciate jim's time um and i hope you find a lot of this useful um yeah uh thanks for your time super fizz gone um see you all soon