Development of DKG and resharing for SSV network

Proposals Grants
1

Background and Objectives

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:

  1. The KeyShares shall be stored in a distributed way instead of being stored in a central place during operations.
  2. Signing process must not reveal the original private keys.
  3. The solution has to be able to easily integrate with the existing PoS network and it has to support third party extension.
  4. It has to be modular and easily integrated with SSV’s overall solution.

Approach

Overview

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.

Distributed Key Generation Protocol

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:

964×376 53.9 KB

Resharing Protocol

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:

962×372 38.4 KB

Signing Protocol

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.

Project Plan

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.

Compensation

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)

  1. 30% upon agreed technical specifications
  2. 40% upon MPC working as proposed
  3. 20% after integrated with current SSV code

Team

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.

References

[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

12 Likes
2

This looks like a great job.

5 Likes
3

I think people don’t fully appreciate the importance of a DKG implementation for SSV, this is an enabler to many projects to use decentralized key generation to create decentralized staking services on top of SSV.
This is as important as arithmetic operations in solidity…

8 Likes
4

Just watched you guys’ talk on ssv youtube channel and I fully agree that dkg could bring benefits to ssv network. As Alon said, both teams should talk more to reach a consensus on the workflow and its deliveries. I look forward to seeing the proposal snapshot soon.

6 Likes
5

Not quite understand why DKG is needed. The validator knows the signing key anyway, and it maybe more “safer” for him to know the entire signing key?

I do think refreshing key shares is important.

6

DKG enables a distributed generation of validator keys between independent operators. It’s a must for use cases like decentralized staking pools

1 Like
7

That only makes sense that the validators do not want to manage the entire signing key, right?
The current method by splitting the signing key via Shamir Secret Sharing would be sufficient to prevent the operators from knowing information of the keys.

Btw, DKG and refreshing shares may do not need to use homomorphic encryptions (say Paillier), which could avoid expensive range proofs.

8

:vertical_traffic_light: Voting is now open:
ssv.network proposal: Development of DKG and resharing SSV (snapshot.org)

Every vote counts! :white_check_mark:
—Ben

1 Like
9

Yes, you are right. DKG/resharing doesn’t provide much value for current way of splitting the signing keys which are generated by validators. It’s more to provide the ability to support cases where validator doesn’t want to manage the signing key (especially after the Merge). It’s an enabler to the SSV ecosystem so that we can fully decouple the validators and operators but are still able to ensure the security of the keys. With this decoupling, new possibilities will be opened. For example, it allows SSV to more easily interoperate with other DeFi protocols as the validator doesn’t need to manage the keys and it gives us more flexibility in the governance and management of the operators to achieve better robustness and resilience in the operations.

About your second remark, Paillier encryption is not necessary for DKG and resharing.

10

That makes sense, thanks!

11

Hi all, we have been studying the SSV Network and conducting research at the background for the past weeks. We would like to provide an update from the initial proposal with more details on the implementation and timeline. Looking for comments from the community:

Validator Onboarding Workflow Change

1118×686 60.3 KB

The diagram depicts the pre-merge validator onboarding flow without DKG and with DKG.

Without DKG

Currently a validator needs to create a signing key and withdrawal key following the instructions on Ethereum Launchpad. By default, both keys are derived from the single set of mnemonics, users will receive a keystore containing the signing key as well as a signed deposit data. After that they need to make a deposit of 32 ETH along with the deposit data via the Launchpad. Finally, they need to go to the SSV app to select operators and split their signing keys for the selected operators. The selected operators will listen to the events resulting from validators actions and start to perform their duties for the new validators.

With DKG

With DKG, the required keys and deposit data will be generated in different ways. Users don’t need to manually generate the signing key. Instead they will send a Keygen request via the SSV app. This request can be bundled together with the operator set selection so that no separate steps are required. Once the request has been successfully submitted, the operators will automatically detect the request and perform the DKG protocol to generate the keys and create deposit data. The operators will register the encrypted shares in this case so that the shares could be recovered the same way as without DKG. One thing to note is that the withdrawal credential (i.e. hash of withdrawal key) has to be supplied by the user. Once the DKG is done, users can retrieve the deposit data from the SSV app and use it in Launchpad to deposit the staked Ethers. The pre-selected operators can start to perform their duties once the deposit has been made and no additional actions are required from the validator.

Although the flows are different for the two modes, they are compatible with each other. With the introduction of DKG, users have another option to generate the keys and in future some use cases will require users to opt for DKG. However, the existing flow and keys will continue to work without any actions required from the users.

Milestones

The project is planned to be completed in 20 weeks (roughly 4 months). We’ll run 10 two-week sprints. There are roughly 4 chunks of work and we set the following milestones:

Sprint 1 & 2 (ending 20th May): DKG adapted to Eth2 use case (BLS and deposit data)

Sprint 3 & 4 (ending 24th Jun): Integration of DKG with SSV network

Sprint 5 & 6 (ending 15th Jul): Add resharing functionality

Sprint 7 ~ 10 (ending 9th Sep): Iterations (optimation/tuning), code audit, documentation

7 Likes
12

I appreciate the transparency

13

We have completed the first phase of development to adapt BLS DKG for eth2 use cases. The demo code can be found here. The functionalities include:

  1. Keys can be generated with the BLS DKG code
  2. The keys can be used to sign for the deposit data
  3. The deposit data signed using the generated key can be correctly validated in Eth2 Launchpad

If you are interested, feel free to try out our demo scripts and here is a video recording of the demo.

4 Likes
14

Can we let smart contract to trigger Resharing and Exit by DKG? It will solve a big problem if we can, don’t need to wait 0x03 withdrawal credential.

15

@alonmuroch could you answer plz?

16

Hi Kenway, we already have a CLI application to trigger keygen and resharing (exit is being developed) between ssv operators. If I’m not wrong, what you’re asking is to trigger these actions through a smart contract. Happy to hear @alonmuroch thoughts on this!

17

Yes I’m asking is to trigger those actions though a smart contract, I read your docs and demos about DKG, very excellent work, if it can trigger those actions not only CLI but also smart contract should be great.

18

If it’s not happening now but it’s possible in the future, it’s still an awesome thing.

19

Exciting Update from RockX Team

Dear Community,

We are thrilled to announce that our team, in collaboration with the SSV team, has successfully completed the development of our Distributed Key Generation (DKG) CLI tool. This milestone marks a significant step forward in our project’s journey. There has been some changes, especially the decision to develop the solution as a separate CLI tool. These changes were approved by the grant committee. You can find a copy of the grant application here

Development and Testing

Our progress has been marked by a series of well-defined and strategic milestones, each contributing significantly to the development of our DKG tool.

Product Design and Specifications

  • We began with extensive research and evaluation of various DKG protocols, ultimately selecting the most promising one.
  • A proof of concept was developed to demonstrate the viability of the chosen protocol.
  • A SIP document was created to establish a clear, protocol-agnostic specification for our DKG tool.

Product Development

  • The development phase saw the creation of the Keygen protocol, complete with specific tests to ensure its functionality and robustness.
  • We then developed the Resharing protocol, again with dedicated Spec Tests to verify its performance.
  • A significant feature, the Blame and Timeout mechanism, was also developed, providing an additional layer of security and reliability, tested thoroughly for effectiveness.

Pre-Mainnet End-to-End Testing

  • Our approach included the development of a CLI tool, designed to integrate seamlessly with SSV’s validator creation flow.
  • We conducted rigorous internal end-to-end tests, covering the creation of validator keys using the RockX DKG CLI in conjunction with the SSV platform.
  • A KeySign protocol was incorporated into the SSV-Spec to enable signatures using validator keys.
  • We ensured that the KeyShares data output was aligned with the SSV-Keys tool.
  • Using the CLI tool, a joint testing phase was executed with volunteer SSV node operators 13, 24, 221, and 261. Special thanks to Eridian from SSV Grants committee for orchestrating this vital test to validate our tool’s performance in real-world scenarios. We also appreciate Massimo (from SSV), Yorick (CryptoManufaktur), and Marc (BlockShard) who helped in running the operator and DKG nodes for the testing

Each milestone has been a step forward in our journey, bringing us closer to a reliable, effective, and user-centric DKG tool. The collaboration with the SSV team has been instrumental in this process, ensuring that our tool meets technical expectations and aligns well with existing systems and workflows.

Upcoming Milestone

For our upcoming milestone, we’re excited to introduce a new feature that enables users to generate pre-signed exit messages, granting them enhanced control over their validator exit processes. Concurrently, we’re gearing up to expand this service’s reach by rolling it out to more community members on the testnet. This step is a precursor to our planned mainnet launch, where we aim to bring these advancements to a broader audience.

We want to extend our heartfelt thanks to the grant committee for their approval and support.

Warm regards,

The RockX Team

Additional Resources

Github Repo: https://github.com/RockX-SG/rockx-dkg-cli/tree/v0.2.13

DKG Demo: dkg_demo-v0.2.13.mov

Revised Grant Application: [External] RockX DKG - SSV Open Grant Application

2 Likes