Simple DVT module management

# Simple DVT module management <iframe width="100%" height="512" src="https://miro.com/app/embed/uXjVMrbZfwc=/?pres=1&frameId=3458764562609023602&embedId=278518565327" frameborder="0" scrolling="no" allow="fullscreen; clipboard-read; clipboard-write" allowfullscreen></iframe> ## Actors ### Module committee multisig The multisig committee expected to be formed by Obol, SSV and Lido folks. The committee agree on the changes to be made to the module state and start one of the EasyTrack (ET) motions. These motions can only be started from the multisig address. Expected operations place to ET motions: - Adding new clusters - Activating and deactivating existing clusters - Changing cluster properties: name, reward address - `MANAGE_SIGNING_KEYS` role management ### Cluster A cluster is a group of node operators that run distributed validators. Since the curated module contract, which is planned to be used for DVT, was not originally intended to have clusters, the clusters will be stored in the contract state as node operators. Details about which node operators form a cluster will not be available in the module state. Within a cluster, there are two roles that require an address for management: reward collection and key management. These roles can be assigned to one address or two separate addresses. #### Cluster committee multisig Each cluster is expected to have a gnosis safe multisig consisting of the operators of that cluster. This address shall have (at least) the role required for key management, with the below expected responsibilities: - Add new keys - Remove unused keys - Start motion to increase the staking limit #### Reward address The reward address is used to receive rewards for the performance of the cluster's active validators. For the reward address, the multisig or a separate smart contract can be used. This address is supposed to be Multisig or a separate smart contract that will accumulate rewards, which can be distributed through the splitter contract by calling the distribution method. ## Cluster life cycle ### Adding an cluster The module multisig committee comes to consensus and starts the ET motion of adding a new cluster. The motion transaction is formed by one of the participants through ET UI https://easytrack.lido.fi/, the rest of the participants check it and sign it. If there is no objections from LDO holders, after 3 days the motion is enacted and the cluster appears in the module. ### Key submission The cluster multisig participants agree on readiness to launch a new pack of validators, perform a DKG ceremony where distributed validator keys and deposit data are generated. Then one of the participants forms a transaction to submit the deposit data to the Simple DVT contract. Transaction is formed via operators UI https://operators.lido.fi/ where validity of key signature and absence of duplicates among all modules is checked. The participants verify the correctness of the keys in the transaction and sign the transaction ### Key vetting After loading the keys, the cluster multisig committee makes sure that the keys appear in the UI https://operators.lido.fi/, are valid and have no duplicates, then one of the participants forms a transaction to raise the staking limits via ET UI https://easytrack.lido.fi/. The participants verify the new amount of vetted keys and sign the transaction. If there is no objections from LDO holders, after 3 days the motion is enacted and the keys are marked as vetted. ### Deposit When there are enough undeposited user eth in the Lido buffer to make a deposit, the bot triggers a secure deposit transaction to a specific module, depending on the target share of modules and the current number of active validators in them. Then the deposit is distributed among clusters depending on the number of active validators in each cluster and vetted key availability. Deposited keys are marked as used keys. ### Validator active state Validator works and gets rewarded daily with the Accounting Oracle report. Rewards are distributed in proportion to the number of active validators (used - exited keys) on the third phase of the Oracle report. Rewards are distributed by minting new shares to the reward address. In case a multisig cluster is specified as a reward address, the rewards are distributed among the participants by agreement. If the splitter contract is specified as the reward address, the rewards are distributed automatically among the participants by calling the distribution method. ### Validator exit A validator can be requested to exit via the Validator Exit Bus. It's assumed that the cluster runs Ejector https://github.com/lidofinance/validator-ejector/ with pre-signed messages to exit validators or this is handled at the network level as in the case of Obol. If the cluster did not exit validators in time (currently this value = 4 days from the request), it's marked as penalized and only receives 50% of the rewards. ### Deactivating In emergency cases where a cluster is malicious, such as a front-run attempt, the module multisig committee can start an ET motion to deactivate the cluster. A deactivated cluster receives no rewards and no new stake. ## Controversial issues ### Target limit Should we provide the ability for the module committee to set the target limit to operators via ET motion? Right now there is no dedicated role for this in the module contract, only a generic `STAKING_ROUTER_ROLE`. Granting such a role to ET increases the risks. ### Deposits pause Do we want to grant the possibility of pausing module deposits on Gateseal? Now the DSM guardians can pause deposits in case of a front-run detection, but there is no such option for unexpected scenarios. We can use one of the guardian private keys in such scenarious, but this would not be a legitimate use. I would suggest explicitly assigning `STAKING_MODULE_PAUSE_ROLE` role to a Gateseal contract and nominating a committee multisig. ### Operators deactivating Rare scenario, probably should only be called from the Aragon voting.