We realize that security is one of the top priorities when dealing with decentralized, smart contract based DeFi products. In this article we want to explain what measures the Stkr protocols has in place to protect users’ funds.
Background
In the current version of Ethereum, users have only a single private key to access their funds whereas there are two different keys in the upcoming Ethereum 2.0:
- Validator public and private key pairs: The validator private keys are used to sign on-chain operations such as block proposals and attestations. Therefore, these keys have to be considered as hot wallet keys.
- Withdrawal public and private key pairs: The withdrawal private keys are required to move a validator balance which is expected to be in Ethereum 2.0 at the end of 2021. Hence, losing these keys means losing access to the validator balance.
If an individual is running their own node by staking 32 ETH, then they would own and manage these keys privately, just as they would own any other wallet keys.
But Stkr effectively allows many people to stake within the same Validator using our Micropool technology — which means the 32 ETH could consist of tokens from wallets belonging to as many as 64 different stakers (the minimum stake to participate in a Micropool is 0.5 ETH): amounting to 256 different keys per pool!
One of the key features of Stkr is to protect our staker’s original staked amount from any slashing by managing our Micropools dynamically.
There are two parts to this protection mechanism:
- All slashing comes out of the 2 ETH staked by the pool owner. We refer to this as the providers’ ‘insurance’.
- If the Insurance is depleted below a threshold amount, the second failsafe kicks in: stakers are moved to a new Micropool, run a more reliable provider.
The point of describing this again, is to highlight that in order to manage Micropools dynamically like this, Stkr currently requires all of the keys — but does not hold them as such!
So, the question now is, how is this done, and what security do we implement in order to make this as safe as possible?
Ankr’s distributed, trustless key management architecture
Ankr uses something called a ‘Threshold BLS Signature’ system.
A BLS digital signature is a cryptographic signature scheme which allows a user to verify that a signer is authentic.
Something really important to understand with BLS is that it’s possible to aggregate all types of primitives (secret keys, public keys, signatures) and the result is always another valid primitive.
For example, if you aggregate two secret keys, the result is a new valid secret key. If you aggregate the two corresponding public keys of the secret keys, the result is a new public key that matches the previously aggregated secret key’s public key.
A threshold signature is a way to create a cryptographic signature from a shared private key that uses a distributed set of participants. This is typically configured such that a ‘threshold’ of participants (e.g. 3-of-5) are required to create a signature. The security is defined that any less than this threshold number of participants learn nothing about the shared private key and cannot produce a signature.
So, we require multiple participants to manage the keys, and then by distributing the signing across multiple locations, we make attacking the system more difficult because a threshold of participants must be compromised to recover the shared key.
In Stkr, the signing is generated using this threshold system in such a way that the actual whole key is never known by any of the signers; each signer only possesses a fragment.
It works something like this:
Here we have a request for data being fired at the network of Threshold servers. Each server has access to a fragment of the data required, which it digitally signs and returns to the Requestor. Once the Requestor has received above a certain number of data fragments, it can assemble these into the fully formed required data. Not only that, any bad responses can be immediately detected and the sender of bad data can be locked out of the network, allowing investigation and remediation to take place.
Stkr is the first staking protocol which uses Threshold Key Management to prevent single-point-of-failure/attack.
In the case of the Withdrawal key, we add a further layer of security: instead of all being online, partial private keys (of the withdrawal key) are distributed on both online and offline servers. We do this so that, in the worst possible scenario, even if all the online servers were compromised simultaneously, the overall withdrawal keys would still not be able to obtained
In modern terms: funds will always be safu!
But there’s more…
Automatic Validator Migration
Stkr recognizes that there can never be enough security in place to protect our users.
Cast your mind back to the introduction where the Micropool management to prevent slashing was described: there’s another scenario relevant here. Imagine if validator keys were somehow stolen… then ordinarily, the culprits could act maliciously.
But with Stkr, the partial private keys of the validator keys are not stored on validators (where they ordinarily would be) but instead they’re stored on the Stkr Threshold servers.
This provides us with the flexibility to move validator signing keys very quickly from one validator to another. Stkr then actively monitors the servers and in the event of Stkr observing any unusual behavior, stakers are immediately migrated to a safe provider.
Threshold server ownership
One final point to make is that, if Ankr will ‘own’ all of the Threshold Servers, then this not only makes the key management network more vulnerable, but also from the users’ perspective requires significant trust. To address this, the Threshold Servers will not all be owned by Ankr.
We will actively encourage any Stkr partners who wish to heavily integrate Stkr into their own services to run their own Threshold Server too. This means that as Stkr grows, and evolves, the security system becomes organically stronger and increasingly decentralized!
Initially we are pleased to share that one of DeFi’s most popular platforms, Curve Finance will be running Threshold infrastructure with us, to ensure our Threshold network is not controlled by one single entity.
We will be announcing further Threshold Server owners later, as future Stkr partnerships are shared.
Conclusion
Hopefully this overview of some of our key management and security protocols have been implemented, has helped you to understand and appreciate the lengths that we have gone to, in order to secure all Stkr nodes, keys and funds.
Our entire security architecture, including our key management process, is currently undergoing an independent audit by an accredited external organization. We look forward to sharing the results of this with you all very soon!
Useful Stkr links
- Stkr official website
- Stkr teaser page
- Read the Stkr whitepaper here
- Stkr announcement article
- Interest form for providers, early stakers and governors
Follow Ankr on social media
- Ankr official website
- Ankr Twitter
- Ankr Telegram announcements
- Ankr Telegram English chat
- Ankr Telegram Node Support group
- Ankr LinkedIn profile
- Ankr Instagram
