The first public ssv.network testnet was launched on April 7th, 2021. One of its purposes was to test the consensus mechanism</a > used to perform the duties of an Ethereum validator. On ssv.network, the validator key is split into 4 KeyShares and distributed among selected operators registered on the network. The operators use the libp2p framework as a communication layer to transmit messages to each other.
We are currently in the late stages of preparing for the release of testnet V2. The new testnet will feature a completely new network topology, which requires a hard fork. In this post, we will explore and compare the current and new network topologies, as well as the reason for the coming hard fork.
Current network topology
When a validator is created on the current ssv.network, a unique Validator subnet is dynamically created for it at the same time. And, an infinite number of validator subnets can be created to house an infinite number of unique validators on the network.
Each validator subnet is managed by a group of 4 operators, known as Committee operators, that hold validator KeyShares for purposes of performing validator duties. Committee operators use the validator subnets to communicate three types of messages to each other — Consensus messages, Decided messages, and Sync messages.
Consensus message — Messages between committee operators for the purposes of reaching consensus between validator nodes.
Decided message — Messages between committee operators containing signatures after consensus is reached.
Sync message — Messages between committee operators that contain the decided message and is used to sync operators with the last decided message for each validator on the network.
This current topology requires committee operators of a specific validator to be inter-connected, via the validator subnet. As such, operators that manage a large number of validators must maintain individual connections to each unique validator subnet.
The main disadvantages of the current topology are: network segregation, high amounts of network traffic, and operator connection management issues. In addition, if the operators managing a particular validator do not immediately locate each other on the correct validator subnet, that validator will become “stuck” until the operator committee members can all communicate directly with each other.
Existing network topology:
Each validator requires a unique subnet. Committee Operators are required to directly communicate in the subnet in order to operate a validator.</em >
ELI5 — Network topology generally refers to the way nodes communicate with each other. In the current ssv.network topology, each validator is assigned to a unique ‘subnet’. Subnets consist of a validator and the operators(nodes) that are managing it.
A good analogy would be a WhatsApp group; each validator that enters the network requires a new group(Subnet). Committee Operators are communicating in that group in order to operate a validator. In addition, every operator assigned to a specific subnet has to be connected to all of the other operators in the group.
Imagine having 1000 whatsapp groups you need to track and participate in. From a data management perspective it’s not very efficient. Doable, but unnecessary.
New network design (V2)
Consensus subnets — The subnets that are used to send/receive consensus messages.
In this version of ssv.network, validators are deterministically assigned to one of the 128 consensus subnets. Operators only subscribe to the consensus subnet(s) they need to based on the validator(s) they manage.
Decided subnet — The subnet that is used to send/receive decided messages. Operators subscribe to this subnet to sync updates on the last decided message for each validator on the network.
Also unlike the current network, where decided messages can only be synced by committee operators, having a ‘Decided subnet’ allows any operator on the network to be synced by any other operator. This will make the new network more decentralized than the previous version.
In addition, a finite number of Consensus subnets means that each subnet will have a large number of peers available to connect to. Therefore, operator committee members managing a particular validator no longer need to be directly connected to communicate. Instead, they only need to be connected to the particular subnet(s) that the validator(s) is on. This streamlined topology allows for indirect operator connections, via the 128 shared consensus subnets, and greatly reduces the number of necessary connections. This will reduce overall network traffic and result in faster data propagation over the network.
New network topology:
Operators connect to subnets directly or through peers. There are 128 subnets in total and one additional subnet for decided messages only.</em >
ELI5 — the updated network topology is a complete overhaul for ssv.network. Let’s go back to the previous ELI5 section WhatsApp example; instead of having a group created for each validator, we now have a limited number of “super groups”, or, ‘consensus subnets’(128) each holds a large number of validators.
Operators connect to consensus subnets directly or through other operators. This makes it unnecessary for Committee Operators to be directly connected. Bottom line, operators do not need to track so many groups and directly connect to each other in order to run a validator.
There is an additional subnet where all the decided messages are recorded. This helps nodes in the network to quickly get up to date with the network status and for existing nodes to easily query past activity. Think of it as having a few groups where you and your friends discuss where to go on a Friday night, there are LONG discussions and the place you all agreed on is eventually recorded in one ‘dedicated group’. Now a new friend is joining your circle, he or she can quickly go to the decided group to see what everyone was about in the last 10 years. No need to sort through all the endless back and forth, clean and simple.
Why a hard fork for ssv.network?
Changes in the ssv.network’s code leading to the new network design (V2) will result in nodes migrating to a new blockchain. Existing blockchain support will be discontinued by nodes running V2. This will create a permanent divergence from the current version of ssv.network. Operators running the current version will need to upgrade to the latest version to continue participating in the network.
When will the hard fork happen?
It is estimated that the hard fork will happen in mid-May 2022. The exact epoch will be published in the upcoming weeks. When the network reaches the fork epoch, operators will upgrade versions to work with the new network topology, switching from validator subnet subscriptions to consensus subnets. A detailed description can be found under the “Forks” section in the full spec</a >.
