SafeStake

It seems that DKG (Distributed Key Generation) has become a ‘sticking point’ for DVT (Distributed Validator Technology) solutions for ETH staking.The questions we’re hearing from the staking providers all seem to find their way back to DKG and private key security.Do you have DKG?How does it work?How are you keeping the private key secure?Some staking providers are demanding that DKG be in place prior to beginning testing with a DVT solution provider, while others don’t seem to fully understand DKG or grasp its importance.It also seems that the very concept of DKG is misunderstood by many. At SafeStake, we believe it’s time to provide some much needed information and clarification about DKG. So, let’s dive in and take a closer look at what DKG is (and isn’t), and remove the mystery surrounding it.<h2 id="header-0">What is DKG?</h2>There is a relatively common misconception of what DKG is. It often appears to be confused with the process that 1) splits a validator private key into encrypted shares; and 2) distributes those shares to the ‘operator committee,’ or multiple operator nodes that will manage the validator.And, it seems reasonable that this would, in fact, be the case. It is very easy to misinterpret ‘distributed key generation’ as referring to ‘the generation of keys to be distributed.’ However, this is exactly what DKG is not.DKG actually refers to the complex process of multiple distributed resources coming together to securely generate a validator private/public key pair. Distributed Key Generation &#61; the generation of a key by distributed resources (i.e.,pooled staking). If you weren’t quite grasping it before, hopefully you’ve got it now.So, DKG is both a concept that can be referred to when building a specific tech stack that achieves this goal, and the specific tech stack itself.<h2 id="header-1">DKG with and without a ‘trusted dealer’</h2>DKG (the concept) is characterized into two types:<ol><li>DKG with a ‘trusted dealer’</li><li>DKG without a ‘trusted dealer’</li></ol>To follow security best practices, DKG without a ‘trusted dealer’ should be implemented so that multiple parties can generate a public/private key pair without any of the parties ever having custody of the private key or knowledge of the secret that will be used to share it.DKG without a ‘trusted dealer’ is the method that SafeStake employs.When ‘DKG with a trusted dealer’ is utilized, it presents a significant security risk. For a very short period of time, the ‘trusted dealer,’ or the party that distributes the initial secret, has knowledge of the secret. This could allow the ‘trusted dealer’ to recreate the original key or a data signature equivalent one produced by the original to carry out malicious actions on behalf of the validator, leading to penalties, slashing, and loss of funds.Key features and benefits of SafeStake’s DKG:<ul><li>Smart Implementation — Based on the type of deposit (single or multi), DKG stays hidden or automatically kicks-in.</li><li>Built-in — Unlike other DVT protocols, SafeStake’s DKG is part of the protocol itself and requires no additional configuration on the part of network operators.</li><li>Fully Automatic — In Stage 2, the DKG protocol starts automatically when an initiator operator makes an 8 ETH deposit and a mini-pool is created.</li><li>No Trusted Dealer — Unlike DKG based on secret sharing alone, SafeStake’s DKG doesn’t require or utilize a trusted party to share the secret.</li><li>Superior Private Key Security — Now that the key shares represent the validator and attest on its behalf, the private key can be stored securely offline in cold storage. The SafeStake tech stack continually ensures that no single operator or bad actor can recreate the original validator private key or an equivalent data signature, eliminating points of failure in validator private key management and security.</li></ul><h2 id="header-2">The Logic Behind SafeStake’s DKG Implementation</h2>While we cannot speak about exactly how or why other DVT solutions, like Obol, SSV, and Diva Labs implement DKG, we can take some time to explain why and when DKG is necessary in the SafeStake ecosystem.With SafeStake, the following are true regarding DKG and private key security:<ol><li>DKG is not necessary to keep the private key secure when there is a single depositing entity creating a validator that will be managed by multiple operators.</li><li>DKG is necessary to keep the private key secure when there are multiple depositing entities creating a validator that will be managed by multiple operators.</li></ol>This answers the question of ‘when.’ Now, let’s explore more to learn about ‘why’ and ‘how.’In SafeStake Stage 1, the code supports 32 ETH deposits from single users. In this scenario, a single depositor creates a validator that will be managed by multiple operators. Here, the user generates and retains custody of the private key throughout the entire process.<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/6d97d089ae7e415186925e6a25424cd3.png" />The Stage 1 code works as follows, simply and elegantly, keeping the validator private key secure from the operators that will manage the validator:<ol><li>The user generates the validator private/public key pair.</li><li>The user deposits 32 ETH and waits for their new validator to become active on the Beacon Chain.</li><li>The user drags-and-drops their keystore file into the SafeStake browser Dapp.</li><li>The client-side browser splits the validator private key into encrypted shares and securely distributes them to the operators in the committee automatically. The private key never touches the SafeStake network.</li></ol><img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/1bea904d09ac4fe88ec87215b091a9f7.png" />*** No additional actions are required from the operators and the operator committee begins attesting on behalf of the validator.In SafeStake Stage 2, DKG becomes necessary as multiple depositors are creating a pooled validator. Now, the protocol must support the ability to trustlessly and securely generate a private/public key pair without any of the managing operators or depositors ever having custody of it or knowing the shared secret (i.e., without being a ‘trusted dealer’).Our Stage 2 code retains the simple and elegant UI/UX, but now implements DKG without a ‘trusted dealer’ to bring the operator committee together to generate the public/private key pair (instead of a single user), without any of them or the depositors having custody of the private key or knowing the shared secret.<ol><li>An ‘initiator’ operator makes an initial 8 ETH deposit to create a mini-pool and initiates the DKG protocol in the process. It is important to note that the initiator is not a ‘trusted dealer,’ and the creation of the mini-pool launches the protocol-level DKG.</li><li>The additional 24 ETH comes from multiple deposits in the liquidity staking pool to create a mini-pool validator.</li><li>The initiator chooses three additional operators to manage the validator, two of which must be from the available SafeStake DAO nodes, at the beginning. Later, once operator performance on mainnet has been established and Verified Operators have been vetted, they will be added to the list.</li><li>The SafeStake protocol now performs a DKG ceremony to generate the validator private/public key pair. None of the managing operators or depositors ever touches or has custody of the private key and the private key is never stored on the SafeStake network.</li><li>Once the key pair is generated, the SafeStake protocol uses a combination of secret sharing, MPC, and BLS threshold signing to split the private key into encrypted shares and automatically distribute them securely to the operators in the committee.</li></ol>*** No additional actions are required from the operators and the operator committee begins attesting on behalf of the mini-pool validator.After taking a closer look, it becomes clear that SafeStake’s implementation of DKG is based upon whether or not the validator is being created by a single depositor or multiple depositors. It is not dependent on the validator being managed by multiple operators, since this will always be the case for both.<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/04608ff9f4e04f57a2010706b68f7117.png" />How the SafeStake protocol handles pooled liquid staking with DVT<h2 id="header-3">An Ultra-Secure DKG Solution for Multiple Depositors</h2>As you now understand, the role of DKG is to make it possible for multiple entities to securely generate a validator private/public key pair. In the SafeStake ecosystem, this only becomes necessary when there are multiple depositors.In order to keep the private key and multiple deposits in a pooled validator completely secure from both the depositors and the managing operators, SafeStake implements DKG.As previously stated, we cannot speak for the other DVT solutions, but SafeStake does not require or use DKG to keep the validator private key secure from the managing operators when a single user deposit is concerned or when a user is importing an existing validator keystore file. This is true even if the validator keystore file represents a pooled validator running on a different staking network (i.e. <a href="https://youtu.be/UsvJszWgAAU" rel="noopener noreferrer nofollow">Blockswap/Stakewise</a>). That security is handled by a combination of secret sharing, MPC, and BLS threshold signing.<h2 id="header-4">How SafeStake’s DKG Works</h2>SafeStake’s DKG protocol is powered by a non-interactive BLS threshold signature scheme based on Shamir’s Secret Sharing that allows operators to collectively sign messages without the need for direct communication.However, a BLS threshold signature scheme based on Shamir’s Secret Sharing alone presents a specific weakness — for a very short time period, the initial secret distributor, or ‘trusted dealer,’ knows the secret. So, what happens when the dealer can’t be trusted?This vulnerability could allow malicious actors an opportunity, short as the window may be, to gain access to the shared secret, allowing them to recreate the private key or equivalent data signature for the purpose of stealing funds from the validator.To shield SafeStake from this vulnerability and prevent this from happening, the protocol employs DKG in a cutting-edge way, eliminating the need for a ‘trusted dealer.’This added layer of security in validator private key management is one of the fundamental differences between SafeStake and other DVT protocols.<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/157d12d20b9940bfa0f17c22a5d7903e.png" /><h2 id="header-5">Conclusion</h2>There you have it. It’s a lot of information to take in. Thank you for taking the time to read and learn more about DKG, why it is important, and SafeStake’s specific implementation.To summarize, DKG is often misunderstood. We explored what DKG is and what it is not. DKG is both the concept of multiple parties coming together to create a validator private/public key pair and the specific implementation of the technology that does it.We established that the ‘why,’ ‘when,’ and ‘how’ of implementing DKG should be important considerations for every DVT ETH staking solution.Then we took an in-depth look at the logic behind SafeStake’s use of DKG, based on the type of deposit (single or multi), and provided solid reasoning to support our implementation. We also explored how the SafeStake protocol keeps private keys secure for both types of deposits and the overall benefits it provides.Stay tuned for more exciting content and announcements from SafeStake coming soon!<h2 id="header-6">About SafeStake</h2>SafeStake is a trust-minimized middle layer that promotes decentralized ETH staking. It is the first Distributed Validator Technology (DVT) liquid staking protocol for Ethereum written entirely in Rust. SafeStake utilizes the HotStuff consensus protocol and an advanced BLS Threshold Signature architecture to provide the highest levels of security and reliability, so Ethereum validators can maximize their staking rewards.<a href="https://www.safestake.xyz/" rel="noopener noreferrer nofollow">Website</a> | <a href="https://medium.com/ethereum-on-steroids" rel="noopener noreferrer nofollow">Blog</a> | <a href="https://twitter.com/SafeStakeDVT" rel="noopener noreferrer nofollow">Twitter</a> | <a href="https://t.me/ParaState" rel="noopener noreferrer nofollow">Telegram</a> | <a href="https://discord.com/invite/zFS3Mnfpwj" rel="noopener noreferrer nofollow">Discord</a> | <a href="https://github.com/ParaState" rel="noopener noreferrer nofollow">Github</a>

How SafeStake Keeps Ethereum Validator Private Keys Secure

Table of Contents

SafeStake

Other articles published on Jun 27, 2023

Shido Staking Platform is now officially Launched!

Whales Accumulate UNI Amidst Market Volatility: A Deeper Look into Uniswap

Pepe Coin’s Rapid Rise and Predicted Fall: A Deep Dive

May The Force Be With Shiba Inu Drops 15%, While Predicted 12,000% Gamefi Coin Alex The Doge Over...

Bitcoin Holds Steady Around $30,500, Fueling Hopes for Institutional Demand

Cryptocurrency Statement From The Company That Manages $1.4 Trillion: "If This Happens, Cryptos W...

Join our free newsletter for daily crypto updates!