DVT Mega Clusters
We tend to treat all DVT clusters as equal but in reality different setups lead to different results and properties.
We can analyze DVT clusters by 4 major categories:
- Cluster Size —clusters can vary in size, usually following the 3f+1 function for fault tolerance. Larger clusters, can in some cases, present better fault tolerance and robustness
- Node location— an umbrella term for an array of location based parameters (physical, regulatory, data center, etc)
- Correlation — measures how correlated are nodes within the cluster, from very correlated (same entity running 4 nodes in a single data center) to non-correlated (4 independent entities running nodes in different self build data centers). Correlation can also measure things like client diversity.
- Decentralization — measures the influence a single entity can have on SSV or ethereum if it fails. Big entities can have significant effect, choosing smaller operators for a cluster makes the cluster more “decentralized”
Types of Clusters
The All-in-one Cluster
A cluster setup up by a single entity controlling all nodes (supports various cluster sizes), in a single data center, potentially running a single EL/CL node.
This type of setup is probably the least desired use of DVT as it cancels out many of its benefits.
Is it worst than legacy setups (VC<>CL)? Not entirely as it still offers some advantages around independent node upgrades and occasional node failures.
The Many-by-one Cluster
A cluster setup up by a single entity controlling all nodes, in multiple independent data centers, each node running an independent EL/CL node.
This type of cluster starts to harness the potential of DVT infrastructure, despite all operators controlled by the same entity.
Using different data centers reduces a lot of risks and creates a much more robust infrastructure.
Nodes running, independently, in different data centers are/ have:
- different EL/CL nodes (client diversity)
- use different cloud providers
- less susceptible to human error
- easily upgradable
- easier to setup and leverage DKG
- more robust and secure
The Many-by-many Cluster
A cluster setup up by multiple independent whitelisted entities, in multiple independent data centers, each node running an independent EL/CL node.
This type of setup is an improvement on the Many-by-one setup as independence of entities creates a much more robust/ fault tolerant/ censorship resistant setup.
Human errors or even malicious activity are not likely to harm or even degrade the performance of the validator in this type of setup.
The permissionless Cluster
A cluster setup similar to the many-to-many setup but with completely permissionless operator set, anyone can join any cluster. There is no advantage to well known or branded operators.
This type of setup is the pinnacle of DVT usage, the beneficial setup for SSV users and ethereum as a whole.
Factors influencing cluster setups
Complexity — more advance, decentralized, setups require some dev/ devops work which might not always be available. It’s easier and faster to find the minimal setup needed for using SSV
Regulation — some setups require strict regulatory conditioning which might result in severe limitations. Regulation might dictate where a node needs to run, by who, etc.
Revenue — introducing more node operators into the same cluster might require paying them fees, reducing revenue for other node operators
Mega Clusters
Many of the validators on the beacon chain are run by professional node operators. Many of them operate as part of big LST/LRT protocols, creating business and technical ties that can potentially create correlated vulnerabilities.
There is a natural tendency for bigger node operators to run All-in-one or Many-by-one clusters as shown in the diagram below.
Mega clusters are a way to transition all-in-one/ many-by-one cluster setups to be many-by-many or even completely permissionless, further decentralizing big node operator without compromising their requirements, revenue and regulatory constraints.
Mega clusters are the re-allocation of nodes by an entity to other entities as part of a multi (mega) cluster setup. Done as part of a group, the end result is the formation of many-by-many clusters to be used by each participating entity.
Forming Mega Clusters
Coordinating a mega cluster can take place in various ways: manual, scripts and even a dedicated smart contract.
The common parameters for all formations are:
- A validator registering white listed address for each entity, shared with the other entities
- Determine the capacity C for the mega cluster (# of validators)
- Calculate the number of operators to generate by each entity |O| = C/O_max (the maximum number of validators per operator, defined in the SSV contracts)
After the parameters above are set, all entities follow those steps:
Step 1 — each entity creates a unique ethereum validator registering address and shares it with the other entities
Step 2–each individual entity, create 4 nodes (just as it did before)
Step 3— each of the nodes, of each of the entities, sets as the white listed address 1 unique entity (using the addresses generated in step 1)
Step 4— each entity, using its generated ethereum address, can now register validators up to the cluster’s capacity
Coordinating the creation of a mega cluster can happen in various ways, both on and off chain.
On-chain mega cluster contract can enforce specific setup parameters, prevent future changes and facilitate trust and simplicity (e.g. registering multiple operators in 1 transaction).
Any on-chain contract will require some off-chain script to generate operator keys.
Mega clusters can be created completely off-chain as well. A leader creates a mega cluster configuration file and shares it with all the other entities. Each entity will run a dedicated script using the config file to complete the process.
With off-chain mega cluster creation there are a few moving pieces but more coordination and trust are required.
