The DKG Protocol and SafeStake
To initialize and securely generate public and private keys, a Distributed Key Generation (DKG) protocol is an essential component of threshold cryptosystems. This protocol is based on Shamir’s Secret Sharing (SSS) concept, which is a key distribution algorithm that divides a secret into sections known as shares. Unfortunately, the SSS concept, in and of itself, presents a fundamental weakness for blockchain protocols.
The weakness is the distributor’s knowledge of the initial secret, creating vulnerability points for malicious actors, allowing them the opportunity to gain access to the private keys needed to withdraw funds from staking protocols.
DKG to the Rescue
Distributed Key Generation (DKG) solves the issue by making it necessary for n parties to cryptographically sign and verify signatures by generating a public and secret key pair that none of the parties has full knowledge of, only some part.
Here, each operator holds a share of the key and makes a secret exchange with the other operators in the committee. By adding up the actions of these key share exchanges, the secret can be discovered and a signature can be successfully built without any one operator or individual ever knowing the full secret or being able to reconstruct it on their own..
The final line (in yellow) that DKG will be using for secret sharing is the sum of all three lines (random secret Za, Zb, Zc) that distributes its shares across the network.
DKG achieves this functionality by allowing each node operator to contribute to the key being arbitrary.
Since no single node knows all the secrets Za, Zb, and Zc, and the yellow line was never physically constructed, no single operator can ever learn the validator’s private key.
How SafeStake uses DKG
SafeStake is a decentralized staking framework and protocol that maximizes staker rewards by keeping validators secure and online to perform Ethereum proof-of-stake consensus (ETH2.0) duties.
SafeStake splits a validator key into shares and distributes them over several nodes run by independent operators to achieve high levels of security and fault tolerance.
For this purpose, a non-interactive threshold signature scheme is used for operators to collectively sign a message without needing direct communication between them to generate the signature t actions.
Each dealer (operator) creates a deal and publishes it without interacting with other participants. Each receiver can verify whether a deal is correct without interaction with other participants. And, given an agreed set of verified deals, the receivers can derive a public key for the BLS signature scheme and retrieve their shares of the secret signing key.
However, because there is still the possibility that a malicious actor could compromise the number of signers necessary to breach the BLS signature scheme, SafeStake utilizes a threshold signature without a trusted dealer.
By eliminating the trusted dealer, SafeStake removes a potential point of failure that can be seen with other staking protocols. It effectively eliminates the possibility that a validator’s rewards can be stolen by any entity.
We refer to this as a ‘threshold signature scheme without a trusted dealer.’
Because Ethereum’s Beacon Chain allows multiple deposits for a single validator public key, it does not verify that they all have the same withdrawal credentials. This can allow a malicious actor that has access to the validator’s private key to specify the withdrawal credentials for the validator.
With DKG, SafeStake arranges the threshold signature scheme validation private key to prevent any single entity from holding it.
The goal of DKG is to agree on an accepted secret/public key pair and share the secret key among a set of n participants. Only a subset of t+1≤n parties can use or reveal the generated secret key, while t collaborating parties cannot learn any information about it.
In contrast to traditional Shamir Secret Sharing scheme, DKG protocols do not rely on a (trusted) dealer to generate, know, and distribute the secret key, avoiding this single failure point. Instead, the key pair is generated using multi-party computation (MPC) that does not allow a single party to learn the shared secret.
MPC takes a set of x parties and locally generates one key share on each device, ensuring that the entire key never exists on any system at any time, securing keys at an unprecedented level and making theft significantly more difficult. In addition, it specifies a subset y out of x parties that must sign the transaction for it to be executed. This allows several parties to be corrupt while the system successfully executes and approves valid transactions.
How DKG Shields SafeStake mini-pools
Since SafeStake uses an 8 ETH mini-pool deposit to trigger staking for Ethereum 2.0 with less than 32 ETH, the DKG protocol is started by an ‘initializer,’ or those operators who are willing to stake 8 ETH.
Running the DKG protocol allows the public/private key pairs to be sett up for the threshold signing scheme without a trusted dealer. This key pair forms the validation key for ETH 2.0 staking.
SafeStake decentralizes the validation key and prevents any operator from determining the execution layer address and taking over the mini-pool contract funds, priority fees, and MEV extraction.
The use of DKG and other security measures, initializers staking 8 of their own ETH, and requiring at least two of the remaining three operators in the committee to be members of the ParaState DAOs are some of the advantages of using SafeStakefor secure and trustless staking.
About ParaState
ParaState takes Ethereum chain support to the next level by using WasmEdge. We develop and execute high-speed smart contracts with built-in Ethereum compatibility (EVM and EWASM) and interoperability in next-level programming languages like Rust, C ++, and Golang.
ParaState is contributing to Ethereum Proof-of-Stake by introducing a new tech stack called SafeStake, a trust-minimized middle layer that promotes decentralized ETH 2.0 staking. SafeStake is the first staking pool to implement distributed validator technology (DVT). It is written in Rust and uses HotStuff consensus and Threshold Signature architecture to provide robust security and reliability for validators securing the Ethereum network.
