Add native Nimbus support for secret shared validator functionality

[zah]

Nimbus will implement a number of features inspired by the secret shared validators research, allowing sophisticated node operators such as staking pools to create highly available and secure setups that provide close to 100% uptime guarantee when deployed properly.

Risks faced by staking pools

Organizations such as staking pols that operate a large number of validators are exposed to a number of non-trivial risks:

1. Rogue employees

1.1. An employee with access to validator signing keys can use a DarkNet market to sell them anonymously to a criminal organization interested in blackmailing or sabotaging the staking pool (besides ransom, profit can be obtained through reputational harm and stock price manipulation).

1.2. A disgruntled employee may perform slashable actions as an act of vengeance against the staking pool.

1.3. Disgruntled or insufficiently competent employees may cause unacceptably long malfunctions and / or outages that cause substantial losses of income and / or client trust.

2. Malicious Infrastructure Providers

2.1. Authorised access by needed non-employees (e.g. hardware repairs technicians) might result in any of the mentioned above.

3. Hacking attacks

3.1 Hacking, spear phishing, fraud or unauthorised physical accesses (e.g. theft of hardware) might result in any of the mentioned above.

4. Infrastructure Failures

4.1. Grid power, Internet connectivity, natural or human-made disasters, etc might lead to unacceptably long outages.

How can these risks be mitigated?

All of these risks can be significantly reduced if the staking pool implements a key-splitting scheme for the validator signing keys, where each individual server stores only a portion of the validator key. This would permit:

• Splitting the sysadmin staff in sub-teams, so that a sub-team has access to only a portion of every key. If implemented correctly, this can ensure that no employee in the company has access to a complete validator signing key.

• Distributing portions of keys in several different data centers, possibly operated by different infrastructure providers and potentially using different internet backbone connections even when located in the same city. This makes it much less likely that a single infrastructure failure will prevent the company from performing its duties. It also makes it unlikely that a potential security breach will lead to obtaining more than a single portion of a key.

The Shamir Secret Sharing scheme can be applied to the BLS keys used in Ethereum and it's already on the way of being standardised and applied in projects such as Obol, Vouch, the SSV network and others. The scheme offers an effective single-roundtrip solution for creating threshold signatures. For example, if the validator keys are split in 5 pieces, with a threshold of 3, infrastructure failures can take off any 2 out of 5 distributed signing nodes without compromising the ability of the validator to create signatures. At the same time, a malicious entity will have to collect at least 3 pieces of a key in order to steal it. This will require compromising the security of 3 facilities instead of one that holds the entire key.

Generating the keys through an appropriate distributed algorithm ensures that no single computer holds more than one portion of the key even during its generation.

The most significant challenge for adopting this setup would be the necessary organization changes introducing tighter server access controls and administration sub-teams.

To facilitate this setup, Nimbus will add support for a new kind of remote keystore where each item is sent for signing to multiple web3signer instances and their signatures are combined into a final signature matching the public key of a validator which was created by combining the public keys of the individual web3signers.

In the future, we may leverage the trusted peer setup to eliminate the last remaining single point of failure in the system (the beacon node orchestrating the web3signer requests).

SSV Roadmap:

• Add support for distributed keystores.
  Support for distributed keystores with multiple remotes based on threshold signatures #3616

• Add support for converting an existing keystore into a distributed one.
  Add a ncli tool for converting a regular keystore into a distributed one #3634

• Document the functionality in the Nimbus guide.
  Document the Web3Signer setups (both regular and distributed) #3635

• Audit the implementation and recommend it for production use.

• Propose extensions to the Keymanager API for managing distributed keystores.

• Add built-in support for distributed key generation (currently available in Dirk).

• Implement support for running Nimbus fleets without a single point of failure (providing close to 100% uptime guarantee).