The highly anticipated Eth2 transforms Ethereum’s current Proof of Work consensus protocol into a Proof of Stake consensus protocol, in order to achieve higher energy efficiency, higher level of decentralization and hence higher network security. Eth2 requires a validator to be online 24/7 to perform its network duties, otherwise the validator faces risks of seeing part of their staked tokens (32 ETH each) being slashed. SSV.network endeavours to help validators achieve robustness and fault tolerance in their operations.
SSV’s solution includes a secure multip-party computation (MPC) layer to handle the distribution of validator keys and the signing of blocks. In this proposal, we aim to develop a complete MPC solution which extends the basic signing functionality in SSV’s current implementation and it achieves the following objectives:
- The KeyShares shall be stored in a distributed way instead of being stored in a central place during operations.
- Signing process must not reveal the original private keys.
- The solution has to be able to easily integrate with the existing PoS network and it has to support third party extension.
- It has to be modular and easily integrated with SSV’s overall solution.
All the operators in the network collaborate with each other to custody the keys (in the form of KeyShares) and produce the threshold signatures for the validators. The MPC layer sits on top of the SSV network, leveraging SSV’s existing P2P network for operators to transmit the messages involved in the MPC processes and exposing APIs for the SSV main protocol to access the MPC functionalities. At a high level, the MPC layer consists of mainly three protocols, namely the Distributed Key Generation (DKG) protocol, the Resharing protocol (i.e. redistribution of the KeyShares to a new group) and the Signing protocol. Each of these modules may have variations to support various use cases.
In SSV’s current design, operator and validator information is registered in a registry smart contract. The KeyShares for the selected operators are generated from the signing key supplied by the validator during onboarding. And the KeyShares are encrypted for the respective operators and are stored in the registry smart contract. This may be sufficient when the Merge hasn’t happened and the validator cannot change their signing keys.
Going forward, to support more flexible use cases (especially after the Merge), we propose an SSV-DKG protocol, which handles the key generation by the SSV network. In SSV-DKG protocol, the validator will select its set of operators and the selected operators come together to generate their KeyShares.
The DKG is built on top of verifiable secret sharing (VSS) but eliminates the need for a trusted party. Its correctness and privacy are guaranteed by homomorphic encryption. In this way, a signing key is generated for a validator jointly by the operators. But the signing keys are not known to anyone including all the operators even though they can make use of their respective KeyShares to participate in producing the signature for the validator. Besides being used for Signing, KeyShares are also used for Resharing.
The core process is based on [GG20] and described below:
In SSV’s current design, the redistribution of KeyShares is initiated by validators from the smart contract. What happens is essentially the validator (who knows its own signing key) creates a new set of KeyShares and encrypts them for the respective members of the new operator set.
However, this requires a validator to closely monitor the performance of the operators. A possible improvement is to leverage the secure Resharing protocol whereby the redistribution of KeyShares can be handled by the existing operators without the involvement of the validator. Together with the DKG protocol where the signing key is not known to anyone (not even the validator), the Resharing protocol can help in the event where there’s addition or removal of operators, or if some component of the underlying infrastructure is corrupted. As the protocol only involves the operators, the process can be automated and is transparent to the validator.
The Resharing process is described below:
The signing protocol is based on BLS threshold digital signature. It requires the participation of any m or more of the total n operators of a validator. Each operator generates a signature using their respective KeyShares and any of the m+ operators can choose m valid signature shares and aggregate them to construct the final signature corresponding to the validator’s signing key.
As the current SSV codebase already contains the implementation of the Signing protocol, our core development work will be around the DKG and Resharing protocols. We will create a separate open-source repository to host the code for the core logics which will be developed as a library in Rust along with a Golang wrapper using CGO. The integration and relevant changes required in the SSV protocol will be done in a fork of the existing SSV repository.
We chose to implement the first version in Rust as the development team has existing MPC libraries in Rust which can be used to this project. To implement it in Rust will give us shorter time to market as well as better code quality and security. Subsequent to the first implementation in Rust, the code can be ported to Golang by the team or by the community.
We aim to deliver the first beta version in 4 months after inception.
We are thrilled about the potential of SSV as an infrastructure to ETH staking and dedicated to develop and improve a secure MPC solution into SSV protocol. We propose a compensation plan with two components to align the long term interest of SSV and x-matrix labs:
Development fee to deliver first beta version of MPC and integrate it with the existing SSV testnet/ mainnet: 200,000 USD (in stablecoins or Ethereum)
- 30% upon agreed technical specifications
- 40% upon MPC working as proposed
- 20% after integrated with current SSV code
The project will be carried out by x-matrix labs - a team jointly formed by RockX (a professional staking provider and participant in SSV testnet, www.rockx.com) and a group of developers specializing in protocol development since 2016. The team is experienced in building mining pools, MPC wallets and zkp solutions (particularly in Filecoin network). We would like to leverage our expertise and experience in MPC to contribute to the SSV network.
[GG20] Rosario Gennaro and Steven Goldfeder. One round threshold ECDSA with identifiable abort. Cryptology ePrint Archive, Report 2020/540, 2020. https://eprint.iacr.org/ 2020/540