SSV is short for Stafi Specail Validator. It refers to some selected from SVs with special responsibilities. Among the SVs, those who meet certain thresholds have the opportunity to be selected into the SSV candidate pool, and the system then selects the final SSV group through randomly.
When a user initiates Staking, SSV needs to verify the transaction status on the original chain to ensure that the user's assets on the original chain have been transferred to the multi-signature account. And when the user initiates a redemption, SSVs needs to jointly operate the multi-signature account to transfer the assets to the user In the original chain account, and validate whether the transfer is completed. In order to realize these two functions, SSV will be required to run the light node of the projects that SC supports. This program will be written to the entire SSV client to automatically perform validation.
The number of SSVs needed is determined by SC deployed. Each newly-deployed SC will be needing some new SSVs to manage. As for specific numbers, it depends on the scale of asseets that SC manages to meet the need for security.
SSV are elected from SV. You must be a SV to become a SSV. Of course, if you are a SV, you must meet certain standards to become a SSV and you can refuse to be one.
The criteria for SV to become SSV include:
The amount of FIS Staked (including the amount of delegation and self-staking.
The proportion of self-staking amount in total FIS staking amount
How long have one been a SV
No Slash record
Service programs related to SSV that have been deployed that SV
When a SV meets all standards, it can be shortlisted in SSV candidate pool. It will be picked randomly by the system to be a SSV in the next Era. For the security of the chain, SSVs will be re-elected in each Era.
Once becoming a SSV, it cannot engage in consensus block-producing.
SSVs are elected from SVs, and the existing SVs can register as a SSV by deploying SSV services. The system will select SSVs from them according the amount of Stake, online rate, Stake ratio of itself, etc. Once a SV is registered successfully, it will enter the SSV candidate pool. All SSVs inside the pool will take turns or join in the election when a new Staking Contract is deployed.
Before the selection of SSVs starts in each era, the chance of being selected is proportionate to the amount of Stake for each candidate. Besides, the Staking assets of SSV comes from SV, but there is a higher demand for self-staking ratio for SSV.
There are two types of SSV rotation--regular rotation and emergency rotation. Both are designed to meet the security needs of assets. Regular rotation is to ensure the dynamity of SSV, and at the same time, to allow the reward to cover the SSV in the candidate pool as fairly as possible. Whereas the emergency rotation usually occurs when the number of signers is close to the limit. Let’s say each round, N out of M signers are needed, but the actual number of signers S is close to or equal to (M-N), the system will urgently replace incumbent SSVs that do not provide signatures. Through this, the activity of the number of signers is guaranteed. Whether it is a regular rotation or an emergency rotation, both will need new SSVs, and the ex-SSVs will take a rest, waiting for the next round of elections. SSVs that are resting will not be able to get any rewards. Due to the requirement of flexibility, SSV's election cycle takes 1 Era as one round.
Within 1 Era, elected SSVs will perform signing, but when a SSV cannot meet the demand required, it will be withdrawn and banned the right to participate in next round’s election. The conditions for a withdrawal are as follows:
When a SSV does evil, it will be Slashed by the system, and it will be withdrawn automatically. It cannot participate in the next round of election.
When a SSV wrongly or do not sign to a certain degree during an Era, it will be withdrawn.
The SSV team will rotate, 1 Era as one cycle. So SSVs selected in each round will have one Era term. The rotation mechanism evens each SSV's chance of being elected and guarantees there are enough out-of-office SSVs no matter which SSVs are "in power".
Sufficient out-of-office SSVs has a positive effect on system security. This reduces the repetition rate of SSV in each round, thus reducing the possibility of a SSV doing evil. Second, that ensures that the system always has enough back-up SSVs to maintain the system. When the system needs more SSVs to deploy new contracts, or the current SSVs are no longer qualified due to the cancellation of pledges, offline, and failure to perform their duties, violations of regulations , there will always be alternate SSVs in place.
The responsibilities of SSV mainly include participation in multi-signature, RPC, Oracle services.The reward for SSV is independent from that of SV. In order to maintain the security of the Staking Contract, multi-signatures engage in adding, deleting, modifying and monitoring the contract. On the other hand, RPC provides reliable support for the Staking process. In addition, StakingDrop in the Stafi protocol that is based on price-feed also requires SSV to operate Oracle for support. In the current agreement, Stafi has two main incentives for SSV: one is multi-signature service, and the other is RPC service. we set the total rewards given to SSV by each Era as:
The rewarding principle is similar to that of producing blocks--get more rewards for more work done. Regarding the multi-signature service, the number of times of signing is counted while in the RPC service, the number of times the service is called is counted. During 1 Era, Stafi protocol will set the corresponding service count, the initial set count is as follows:
The reward obtained by a single SSV in an Era is determined by the proportion of services provided by this SSV, which can be calculated by signatures and RPC calls of all SSVs in the Era. The reward distribution period is 1 Era, and the number of rewards depends on the service usage.
In the early stage of the Stafi Contract, in order to recruit as many SSVs as possible, a relatively smooth transition method of rewarding will be adopted. That is because when the number of SSVs does not reach the ideal number, there will be a grave risk in contract security. To attract SSVs by enlarging incentives is necessary, but in order to prevent a small number of people from taking most of the rewards, creating additional pressure for further issuance, it is necessary to set the reward distribution to a reasonable level. In the absence of abundant data support, the specific distribution of rewards will be led by the Foundation during the transition period. Meanwhile, a reward cap will be set to reduce the pressure for further issuance. The extra rewards will be transferred to Protocol Treasury for other purposes. After a smooth transition to a reasonable level, rewards will be optimized through algorithms and automatically distributed to SSVs to achieve full automation of motivation.
The Slash introduced in this part is targeted at SSV's misbehavior and is different to Staking-Slash introduced before.
There are two types of punishment actions for SSV (mainly for multi-signature services). The first will be executed when a SSV does not sign during the signature phase; the second when it provides wrong signatures. However what the SSV in both cases may look the same, which is, in the N/M multi-signature system, the number of signers may not reach the minimum N. For SSVs that do not provide signatures or give incorrect signatures, they pose a potential threat for the security of Staking contracts, and will be slashed.
In the multi-signature phase, a SSV’ signature will be needed to help the system perform various tasks (including enabling user’s operations, online rotation, etc.). When a SSV does not sign, generally, it is offline or unresponsive. If the signature is not provided in an Era and Heartbeat detection is not sent, a SSV is considered to be unresponsive. If the behavior does not implement the exit strategy at this time, it will be Slashed. In addition, in the multi-signature signature phase, if a SSV provides an incorrect signature, the signature cannot be recognized by the system. The SSV will be withdrawn or Slashed if that happens repeatedly.
Stafi Protocol sets a threshold in the multi-signature system. If the threshold is not met, the assets of a Staking Contract will be under threat. Therefore, Slash goes in tandem with the Withdrawal in most cases as follows:
When the number of SSVs that provide no signatures or incorrect signatures is smaller than 2/3 of the threshold, the proportion of SSVs that are Slash is small, and they will not be withdrawn;
When the number of SSVs that provide no signatures or incorrect signatures is bigger than 2/3 of the threshold, the proportion of SSVs that are Slash is big, and they will be withdrawn in the next Era;
The system will Slash SSVs that deliver the aforesaid 2 signature problems, because no signature is the same as incorrect signatures when it comes to the damage to the system. Therefore, the formula is the same for 2 scenarios:
n is the number of validators, k is the number of SSVs that provides no signature or wrong ones.
Assume n=21, and the signature threshold is 12,
When k < = 2, the proportion of Slash is 0.
When k = 3, the proportion of Slash is 0.002.
When k = 4, the proportion of Slash is 0.00814.
When k = 5, the proportion of Slash is 0.01836.
When k = 8, the result is 0.07346.
When k > = 9, the result is 0.1
Generally speaking, when the number of SSVs that provides no signature or wrong ones is bigger than 2, the security deposit of SSVs will be forfeited. The ratio of Slash is between 0 and 0.1, the bigger k is, the closer to 0.1.