Before enlisting the support of a staking platform to secure your validator in Eth2, it is first important to consider the fundamental security parameters surrounding your Eth2 validator and private keys. Given that the Proof of Stake protocol in Eth2 requires validators to be consistently online, security vulnerabilities exist that may effect your potential to earn rewards and avoid penalties.
At Blox, we aim to provide our users with the most secure and easy to use non-custodial Eth staking solution. There are a variety of different ways that a staking service may manage their users’ private keys, and we have stopped at nothing to ensure that our method is completely trustless and secure.
In this post, we will take a look at the type of keys generated in Eth2, their inherent security vulnerabilities and the different ways to secure them in a multi-user staking environment.
Eth2 & Hot Keys
Eth2 requires generating 2 sets of key pairs, using BLS12-381 keys. The 2 key pairs are withdrawal keys and validator keys.
A withdrawal key, as the name suggests, is a key used to withdraw or transfer staked ETH from one account to another. As transfers are not yet available in Phase 0, this key and its functionality are not yet active.
The validator key is used to sign duties randomly assigned to a validator by the blockchain; these duties get updated every epoch (6.5 minutes). As a result, a validator key must be online at all times in order to perform its signing duties, effectively making it a hot key.
Eth2 is one of the first “dApps” that requires a hot key; most other dApps/DeFi services require the user to occasionally connect their hardware wallet to execute a transaction; otherwise, the signing key is kept in cold storage.
The Problem with Hot Keys in Eth2
The requirement of being online at all times poses connectivity and security challenges for Eth2 validators.
Hot Key Connectivity Challenges
Connectivity-wise, a validator key must consistently be linked to a validator, the Beacon Chain and Eth1. Loss of connectivity may lead to financial penalties.
In normal circumstances, validators that are offline are only penalized for ETH that they would have received as rewards for participation; however, these penalties can extend to larger sums of staked ETH if downtime is more frequent.
Hot Key Security Challenges
A hot wallet that holds private keys is by definition more susceptible to security risks than a cold wallet, as it is reachable via internet connection.
As an example, if a hacker gains access to an Eth2 validator private key, they can hijack that validator and demand ransom for not engaging in ‘slashable’ events; such as, maliciously proposing or attesting emerging blocks more than once but with different signature parameters.
Penalties for such slashable events can range from ~1.5 ETH to one’s entire stake, depending on how many other validators participate in the event. This is a protocol level mechanism that is designed to exponentially increase the penalty for collective attacks on the network and is an important feature to consider when selecting a (multi-user) staking service.
As pictured below, in a multi-user, centralized environment (such as a custodial staking service), the potential of incurring high individual penalties for slashing events is shockingly higher as compared to the equivalent penalties that would be incurred in a trustless/decentralized staking implementation (such as a truly non-custodial staking service):
Needless to say, when selecting a staking service, it is not only imperative to consider the level of security surrounding one’s private keys but also how the service manages its user keys as a whole.
So, what solutions exist for securing hot validator keys in a multi-user environment?
The Most Common Eth2 Hot Key Securing Solution
The most common solution, at time of writing, is encrypted files generated by the different Eth2 Beacon Chain implementation teams. The gist is to generate a mnemonic phrase (that the user must backup and keep safe) as well as validator keys; encrypt them on disk and then have them stored on a server where the validator client is running.
This is a very cumbersome way of managing keys and securing them becomes very difficult, especially in a multi-user environment.
Luckily, Prysm, the leading node implementation now supports a method known as a ‘remote signing wallet,’ a way of storing private keys independently from a validator. This is the most secure solution currently available.
Remote Signing Eth2 Hot Key Securing Solution
A remote signing wallet is essentially a wallet that holds private validator keys which are processed on a remote server that signs tasks assigned to the validator. It’s a new way of implementing advanced signing architecture.
With Prysm for example, a remote signing implementation should implement the below two methods over gRPC:
This allows for the complete separation of one’s private keys from their validator duties. In a multi-validator implementation, user private keys can be stored in a decentralized fashion away from a validator.
Blox KeyVault Solution: Secure Eth2 Remote Signing Staking Service
Blox KeyVault is a project that combines an open-source Desktop app and a specially developed Hashicorp Vault plugin which work together to securely set up an Eth2 remote signer on the user’s cloud provider account. It manages the creation of new validators, keys and more.
The architecture takes inspiration from leading hardware wallet manufacturers (Trezor, Ledger) by having a Desktop app which acts as the admin portal for the user and a secure module that holds sensitive keys.
As seen in the diagram below, there is a secure separation between user-managed sensitive data held in a personal KeyVault and the infrastructure required to perform the various duties required of an Eth2 validator.
KeyVault User Installation
Setting up a remote signing wallet that works with an Eth2 node can be a demanding task, which requires constant monitoring and maintenance. After all, Eth2 validators are required not only to ‘put at stake’ a significant amount of ETH in advance but also to perform network duties at all times.
To simplify this process, Blox KeyVault setup is automated with a dedicated installation procedure that deploys the user’s remote signer in any cloud service provider the user selects (and on premise in the future), directly from the Desktop app.
Here is an overview of the installation steps:
- Create Remote Instance
- Enable Secure Connections
- Install KeyVault Instance Remotely
- Update Server Storage
- Sync KeyVault with Blox
By the end of the installation, the user, via the Blox Desktop app, will have installed a complete, operational remote signing wallet. Estimated installation time: 5-10 minutes!
KeyVault Technical Installation Overview
During KeyVault installation, the following secret keys are stored and encrypted on the user’s local machine. The most important key to backup is the seed, the other keys can be re-created by a new installation if necessary:
- KeyVault Root Access Token – Used as the root user credentials for Hashicorp Vault and KeyVault. Allows admin operations.
- KeyVault Unseal Token – Hashicorp Vault and KeyVault use disk encryption for all information. For normal operations, the unseal token must unlock KeyVault in order to be able to sign.
- SSH Keys – For the machine on which KeyVault was installed (if the user is using AWS, the EC2 SSH keys)
- Wallet Seed (if not generated on a hardware wallet)
It’s important to note that at no point does Blox have access to the installation process or the sensitive keys generated. This is a crucial parameter in line with Blox’s vision of providing its users with the world’s first, truly non-custodial Eth2 staking experience.
KeyVault Signing
After KeyVault is installed and the user deposits the required 32 ETH to become a validator, KeyVault is ready to start executing Eth2 duties and earning rewards for the user.
There are 2 basic signing requests that KeyVault will need to sign: slot attestation and slot proposal. For a more detailed explanation of each, check out our blog post.
KeyVault Slashing Protection: Completely Trustless & Secure
A key element for Eth2 validator signing operations is to make sure KeyVault does not sign a request that could lead to the user being slashed. To that end, Blox KeyVault includes slashing protection.
KeyVault maintains a local database that holds all past signed attestations and proposals. If a new request violates protocol rules and could get the user slashed, KeyVault will not sign it.
It’s important to note that the ultimate signing decision is made by the particular installed KeyVault instance run on the user’s machine and NOT by Blox in a centralized fashion.
This ensures that Blox is completely trustless. Blox users never have to worry about exponential slashing penalties as Blox offers a 100% non-custodial, decentralized staking solution. Your private keys are privately protected in your own instance of KeyVault powered by HashiCorp Vault, a lead player in sensitive data management.
More From Blox
For more info about validators, Eth2, staking & more, check out our other Blog Posts and FAQs!
To stay connected, register to our Beta Waitlist and join us on Discord.
Team Blox
