SSV.network

Validators split their validator private keys into key shares using Shamir Secret Sharing and encrypt them for use by a set of operators. These operators use the key shares to propose blocks or make attestations on behalf of the validator. However, if an individual or group of operators possesses the "quorum" number of key shares, they can recover the validator's private key and make unilateral decisions that may lead to slashing. It is important to note that an operator may obtain multiple key shares in two ways: by registering as an operator multiple times when setting up a new cluster or by colluding with others who have registered as operators and sharing key shares with one another. If a cluster contains colluding operators, they can act maliciously and cause a slashing event by using their key shares to make decisions on behalf of the validator. To prevent such malicious activity, validators should carefully select trusted, high-performing, and decentralized operators for their clusters. It is critical to communicate this risk to validators and emphasize the importance of proper operator selection and monitoring. It is also important to note that Ethereum 2 validators have a signing key and a withdrawal key, and only the signing key is provided to operators, which prevents colluding operators from withdrawing the validator's staked ETH.

All externally callable functions in the following contracts are callable by anyone as they do not employ any kind of access controls: 1. `SSVClusters.sol`. 1. `SSVDAO.sol`. 1. `SSVOperators.sol`. Direct calls to these functions circumvent the access controls performed in contract `SSVNetwork.sol`. However, performing direct calls will lead to uncontrolled storage reads/writes (`SSVStorage.load()` and `SSVStorageProtocol.load()` will be relative to the called contract and not `SSVNetwork.sol`, which holds the correct global state) and no path of exploitation was found during the audit.