Rationalizing DVT Cluster Formation
The below is a NON binding, aimed for discussion purposes only
DVT revolves around the concept of clusters, a group of node operators working together to operate an ethereum validator, each holding a share of the validator key.
A DVT network is a network of DVT clusters in which nodes are interconnected, participating each in multiple clusters and forming a robust P2P network.
In SSV, cluster and operator registration are done via a set of dedicated ethereum contracts.
SSV contracts were designed with 3 goals in mind: zero coordination, data availability and settlement.
Zero Coordination
A DVT cluster should be created with zero manual/ off chain coordination; minimizing trusted setups, enabling lightning fast cluster formation, on-chain automic registration and reducing manual/ human errors.
This aspect of DVT networks is a huge advancement in usability and robustness versus DVT implementations requiring manual coordination.
Zero coordination makes it easy to setup clusters, re-use code, change cluster formations, re-use configurations and above all troubleshooting issues and fixing them on the fly.
Data Availability
A DVT node needs to know which clusters it’s assigned to, immediately update changes and be sure it always signs messages for relevant clusters only!
The above requires some data to be synched by each node, when creating new clusters or changing existing ones.
With the centering of ethereum’s roadmap around rollups, data availability became a major point of interest.
Data availability is an overarching term for data writing and accessibility in a distributed network setting.
SSV uses ethereum itself as a data availability and synchronization layer for all nodes. It offers an easy to use (and relatively cheap) way for all nodes to “know” which clusters are formed, discover other nodes, change cluster formations and make sure that data stays available at all times.
SSV currently uses calldata for cluster formation which will become 5X cheaper with EIP-4488
Settlement
Permissionless cluster formation with public nodes can’t happen without on-chain settlement. SSV contracts help by integrating a payment settlement layer enshrined in the protocol itself.
Cluster formation
Cluster formation usually takes the following steps: selection pool, clustering and fee management.
Selection Pool
There is some set of operators from which a cluster can be formed.
The set can be as big as to include all existing (private and public) operators or as narrow as a whitelist of carefully selected (and trusted) operators.
The conditions/ requirements to be included in the selection pool are up to the individual staker/ developer.
SSV has formed a verified operators(VO) pool, a group of highly experienced companies and service providers in the staking industry.
The VO is managed by a DAO nominated committee that periodically reviews new and existing members.
Each staking application on SSV can create its own selection pool: collateralized, home stakers, institutions, etc.
Clustering
Refers to how to select 3f+1 operators from the selection pool and form a cluster. This can be varied and managed in various ways. From completely centralized and static, through centralized (transparent) and dynamic to completely permissionless.
SSV, with its zero coordination clustering, enables each staking application to define how to setup clusters. It can even be done in permissionless contract-to-contract setup.
Fee management
It’s impossible to foresee all different ways to manage fees, different payment schedules, tokens, etc.
For that reason, public operators on SSV can charge SSV directly in-protocol. Private operators can set their fee to zero and manage fee outside the SSV protocol which opens up endless possibilities for developers.
Fee Abstraction
A future improvement on the above is the idea that any token can be used to pay any operator within the protocol.
By abstracting what token is used to pay the fee, while keeping the fee settlement mechanism as is, we can facilitate endless use cases built on SSV (think of creating custom fee tokens that represent a basket of other tokens in a contract).
Operators will indicate in which fee tokens they are willing to get paid in (USDC, ETH, feeToken, etc.). When forming a cluster, a specific fee token will be set by the user that will be used through the life of the validator.
Operators can even set zero fee and settle outside the protocol if they wish to.