Proposal
Summary
This proposal outlines the upgrade for the ssv.network protocol and smart contracts for scaling permissioned operators, aiming to enhance their management and operational efficiency.
Motivation
Permissioned operators, also known as private operators, are currently restricted to authorizing a single address for validator registration. This limitation poses challenges such as serving only one client, incurring high operational costs, and difficulties in managing bulk operations and coordinating among different entities.
The proposed upgrade introduces new functionalities that enhance scalability and efficiency by enabling permissioned operators to manage multiple whitelisted addresses and perform bulk operations more effectively. It provides a flexible and dynamic approach to managing whitelisted addresses, both internally and externally, opening the gate for many more use cases and mitigating many limitations of the current design.
Mechanics
The steps necessary for the execution of this proposal can only be undertaken once the ssv.network DAO Multi-Sig committee has verified that an audit report for this update has been published at the ssv.network DAO github page.
The proposed upgrade includes the following functionalities:
- Enabling operators to set multiple whitelisted addresses per operator:
Operators will now have the ability to authorize multiple addresses for validator registration. This enhancement allows operators to serve multiple clients or stakeholders without the need for a separate operator for each client. By allowing multiple whitelisted addresses, operators can streamline their operations and improve cost-effectiveness.
- Enabling bulk operations for whitelisting addresses across multiple operators:
The upgrade introduces bulk operations support, enabling operators to manage whitelisting addresses for multiple operators in a single transaction. This significantly reduces the complexity and effort required for entities managing multiple operators and serving many clients.
- Separating management and status (public/private) of operators:
The new design decouples the management of whitelisted addresses from the operator’s public or private status. Operators can now independently manage their whitelisted addresses and their visibility status. This separation allows for greater flexibility in managing operator configurations and adapting to different operational needs.
- Dynamic management of whitelisted addresses through external contracts:
Operators can now delegate the management of whitelisted addresses to external contracts compliant with the whitelisting interface. This feature enables operators to implement custom logic (such as roles and permissions), for managing whitelisted addresses and fosters better coordination among entities serving the same clients, as they can now use a shared external contract for whitelisting.
Function Updates
These updates will introduce the following new functions:
- setOperatorWhitelists() - Sets multiple whitelisted addresses for multiple operators.
- removeOperatorWhitelists() - Removes multiple whitelisted addresses from multiple operators.
- setOperatorsWhitelistingContract() - Sets an external whitelisting contract for multiple operators.
- removeOperatorsWhitelistingContract() - Removes the whitelisting contract for multiple operators.
- setOperatorsPrivateUnchecked() - Sets operators as private without checking for any whitelisting address.
- setOperatorsPublicUnchecked() - Sets operators as public without removing any whitelisted addresses.
- isWhitelistingContract() - Checks if an address is a compliant whitelisting contract.
- isAddressWhitelistedInWhitelistingContract() - Checks if an address is whitelisted using an external whitelisting contract.
- getWhitelistedOperators() - Gets the list of operator IDs that have the given whitelisted address.
These updates will remove the following existing functions:
- setOperatorWhitelist() - The current functionality to whitelist an address and transition the operator from public to permissioned.
Smart contract designation
The improvement will become active once the ssv.network DAO Multi-Sig Committee executes updates to the ssvNetwork and ssvNetworkViews smart contracts and SSVClusters, SSVOperators, SSVDAO, SSVViews, and SSVOperatorsWhitelist (new) modules, upgrading them to v1.2.0.
-
ssvNetwork (
0xDD9BC35aE942eF0cFa76930954a156B3fF30a4E1) – The ssvNetwork smart contract represents a gateway contract to the ssv.network. It allows users to call functions of the smart contract and it allows users to interact with the ssv.network through a wallet address. The smart contract also contains the data on the state of the ssv.network. This contract points to the most updated ssv.network smart contracts, which is how it can be upgraded further. -
ssvNetworkViews (
0xafE830B6Ee262ba11cce5F32fDCd760FFE6a66e4) - Is a stateless contract that provides the functionality that enables users to read information about the network and its participants. -
SSVClusters module - Is a stateless contract that provides the logic needed for operating validators and clusters. It is used by the SSVNetwork contract to forward all the cluster-related calls to it.
-
SSVOperators module - Is a stateless contract that provides the logic needed for operating operators. It is used by the SSVNetwork contract to forward all the operator-related calls to it.
-
SSVDAO module - Is a stateless contract that provides the logic needed for managing protocol operations. It is used by the SSVNetwork contract to forward all the protocol-related calls to it.
-
SSVViews module - Is a stateless contract that provides the logic needed for querying network information. It is used by the SSVNetwork contract to forward all the informative calls to it.
-
SSVOperatorsWhitelist module - Is a stateless contract that provides the logic needed for managing operator whitelisted addresses. It is used by the SSVNetwork contract to forward all the whitelisting-related calls to it.
Voting is now underway!