Horcrux

Screenshots

Problem Statement

This project demonstrates a prototype enhancement of a piece of core software underpinning the beaconchain.Problem StatementA human who runs infrastructure to validate the beaconchain backs up their keys to a single 24-word mnemonic. This presents certain risks for those humans who provide the stake and the infrastructure to run the beaconchain.Current SituationThe current implementation of the staking-deposit-cli allows Validators to back up the seed used to generate their Validator keys, onto a single 24-word mnemonic.

Solution

Implementation DetailsThis project incorporates a Shamir Secret Sharing scheme to the staking-deposit-cli. This allows a Validator to choose to create a backup consisting ofNmnemonic shares, where a threshold numberT(<N) shares are required to generate keys.The shares that are generated are then each converted to 24-word mnemonic phrases. The user writes down both the mnemonics and their corresponding index. We can reconstruct our master key with any T-subset of these mnemonic phrases.Shamir Secret Sharing SchemeThis scheme allows secret information to be shared between, for example, 3 "shares".In this case, if an attacker has access to 1 share, they have 0% of the information to allow them to recover the secret If an attacker has access to 2 shares or more, they have 100% of the information and are able to recover the secret.Such schemes are used to secure information by distributing shares geographically.Validator Experience ResearchUX support was provided at different levels :Get to know our audience by interviewing network validators operating on the Beaconchain in an effort to understand their pain points and challenges.Provide usability feedback and recommendations on the solution being implemented by the rest of the team.Essential takeaways from our exchanges with validators :(please note that due to the small amount of interviewees (4), our results might not reflect the full user spectrum)The higher the sums involved, the higher the stress or even paranoia around loss, theft, destruction, or any other risk factors.Regardless of technical skills, sums at stake imply consequent responsibilities and little margin for errors.Each user handles the risk inherent to private keys according to their personal preferences: cold storage, air gapping, hardware wallets, encrypted storage, combinations of the latter… yet admitting the lack of an ideal solution.Retaining ownership and control of private keys is primordial.A readily available tool, alleviating the risk around private key management would be more than welcome, provided low efforts of implementation and ease of use.Overall, exchanges were extremely insightful and it is also worth mentioning some of the other topics touched upon that could be solved subsequently:Submission control before validating a transaction to stake ETHTransmission of private keys/related funds in the event of passing of the ownerA big thank you to those who kindly gave some of their time to exchange with us 🙂Usability recommendations :Provide user guidance throughout the process.Maintain proximity with the existing codebaseFocus the user on one task at the timeEnable error preventionGive feedback upon successful task completionTeamUshana Bandyopadhyay - ImplementationMatt Beton - ImplementationChloe George - User Experience ResearchJialin Li - ImplementationChris Hobcroft - Producer