# SSV(QBFT) Change Operator Set

It is recomended to suppot operator set change within a DVT setting like SSV for various reasons.
It presents challeges in continuity between set S to S'.

Challenges
* Slashing protection database - making sure S' members "copied" the slashing db from S
* Recognizing the switch point between S and S' and managing "Share" versioning
* [Weak-subjectivity](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/weak-subjectivity/#problems-ws-solves) - How does a side standing node can verify the entire chain of executed epochs

## Slashing Protection DataBase
SSV is built as a network with an already existing syncing ability from other nodes. S' could ask multiple random peers for the highest decided instance that S ever signed and used that for their slashing protection

## Share Versioning
When redistribuiting new shares for an existing validator (centralized and distribuited dealers) the new shares will not be compatbile with the old shares (that is S1,S2 and S'3 could not reconstruct a valid signature).
As long as >= 2f+1 of opearators are honest they will not decide and sign duties by mixing old and new operator sets.

A simple share version (along side the message) could be adopted so to know against which operator set the message should be validated against

# Weak-Subjectivity
An offline operator needs to validate past and future messages, how does it know which share version to use when?

Operator set change is an on-chain event, post merge ethereum blocks are validated by the validators so we can assume each block has a slot and epoch signature as well.
***A side node - What if there are multiple change operator set within the same block* **

### Using QBFT to Decide on when the switch happens
We can have set S decide on switching to set S' (specifying the share version, slashing data, etc) at a specific QBFT instance height H. Height H+1 will start with operator set S'.
This requires 2f+1 honest and online operators.

Issues
1. What if the switch takes time, how do we handle on chain fees?
2. < 2f+1 online operators (which is the reason why operators need to change) will not finalize the change

### Not Using QBFT
Another way to make the transition is by relaying on the execution client. Once Any operator parses a change operator event from the contract it will immediatley stop any running instance such that the last decdied instance by S will be H.
H+1 will start with S'.

This present an issue of consistency for QBFT as we can assume all operators parsed the event at the same time or even at all.
If >f operators are changed at once we could risk of deciding 2 different values at H+1.
S: {1,2,3,4}
S': {1,2,5,6}

Operators 1,5,6 parsed the change operators event on time and switched to S'
Operators 2,3,4 didn't parse the event and are stuck on S
We now have a split where both {1,5,6} and {2,3,4} could run in parallel, decided H+1 with different values and slash the validator.
***A remidy can be to limit change operators to <=f operators at most out of the original S***

Stopping an instance in the middle is another issue.
S: {1,2,3,4}
S': {1,2,3,5}

Operators 1,2,3,4 started H+1, in the middle a change operator happened and they've all shut down their intance without deciding.
Operator 3 managed to receive a quorum of commit msgs and to decide, the others couldn't.
Operators 1,2,5 start H+1 and decided on a different value that operator 3 has.

**Stopping a QBFT instance mid-way is not consistent nor safe!**