特殊验证人（SSV）
SSV(特殊验证人)
SSV，即Stafi Specail Validator，则是SV中选拔出的一部分具有特殊职责的验证者。SV当中满足一定门槛条件的有机会被选拔进入SSV预选池，系统再通过随机参数，选拔出最终的SSV群组。
当用户发起质押时，SSV需要验证原链上的交易状态，确保用户在原链上的资产被转移到了多签账户；当用户发起赎回时，SSV需要共同操作多签账户，将资产转移给用户在原链的账户，并验证转移成功。为实现这两个职能，SSV会被要求运行SC支持项目的轻节点，此程序会被写入整个SSV客户端，自动执行验证。
SSV的数量
特殊验证人SSV的数量根据部署的SC确定，每部署一个新的SC都需要有一批新的SSV来管理，具体的SSV数量需要根据SC管理的资产额来分配，满足安全的需要。
SV和SSV的关系
SSV是从满足一定们的SV中产生，所以如果要成为SSV，必须首先已经是SV。当然，如果您是SV，并且满足门槛条件，也仍然有权力不成为SSV。
SV成为SSV的门槛条件包括：
①FIS的抵押量（包括委托量和自抵押量）达到门槛值
②FIS抵押量当中自抵押量占的比例达到门槛值
③成为SV的时间达到门槛值
④作为SV期间在线率达到门槛值
⑤作为SV期间，无Slash记录
⑥已部署SSV的相关服务程序
满足门槛条件，则有资格进入SSV预选池，需要经系统随机挑选后才能成为下一个Era的SSV，为了保证链的安全，每个Era的SSV都会重新选拔。
SSV的选拔过程
SSV的选举从SV中产生，已经成为SV的验证人可以通过部署SSV服务，注册成为SSV，系统根据注册SV的委托量，在线率，自抵押比例等情况，选举SV成为SSV，注册成功的SV将进入SSV候选池，候选池中的SSV会在线上轮换或者是新Staking合约部署的时候参与选举，选举成功后即可以参与到SSV的工作中。
在每个Era，SSV选拔开始前，被选中的SSV进入候选池后，被选中的概率和委托量有正相关关系，另外，SSV中的抵押资产来自于SV，但是相对于SV，SSV有更高的自抵押占比要求。
SSV的轮换分为两种，一种是定期轮换，一种是紧急情况下的轮换，两种方案均以满足资产的安全性需要。定期轮换的作用是保证SSV的活性，同时让奖励尽量均匀的覆盖候选池中的SSV，而紧急情况下的轮换主要发生在签名人数接近阈值时，假设每轮签名需要M中N个人签名数量，但实际签名人数S接近或者等于（M-N）时，系统会紧急调换未提供签名的SSV，以保证签名人数的活性。无论是定期轮换还是紧急情况下的轮换，每次轮换会产生新的SSV，旧有的SSV会被轮换到预选池，等待下个周期的选举，在预选池的SSV因为没有提供服务，将无法获得部分奖励。
SSV的退选
一个Era中，已经选举上的SSV执行正常的签名工作，当SSV并不能按要求完成任务时，SSV将会被退选，并在下个选举周期不能参选。触发退选的条件有以下
1、SSV产生作恶行为，被系统Slash，该SSV同时被退选，无法参与下周期选举
2、SSV在一个Era中，不签名或者提供错误签名的数量超过一定比例时，该SSV会会被退选。
被退选后如何重新参与进来？是不是过了一个固定时间就可以重新参与进来？（下下个Era可以重新注册进来）
SSV的轮换
SSV小组会以Era为周期轮换，也就是说，每轮选拔出来的SSV小组，任期只有一个Era。轮换机制，使得成为SSV的机会尽可能覆盖候选SSV，有助于做到无论那些SSV"执政"，都有足够多的“在野”SSV。
足够多的“在野”SSV,对系统安全有着积极的作用。一来降低了每轮的SSV的重复率，因此降低了SSV作恶的可能性。二来保证系统始终有足够的SSV储备来维持系统工作，当系统因部署新合约而需要更多SSV，或者当前的SSV因取消质押，下线，履职不到位，违规而不再具备资格时，能及时有候补SSV补充进来。
SSV的奖励
SSV的职责，主要包括参与多重签名，RPC，Oracle服务。对SSV的奖励独立于SV之外，为了维护SC安全，多签签名对合约起到增删改查的作用，而RPC则为Staking流程提供了可靠的支持，另外，Stafi协议中基于喂价的StakingDrop也需要SSV运行Oracle进行支持。在目前的协议当中，Stafi对SSV的主要激励行为主要有两种：一种是多签服务，一种是RPC服务。所以目前的奖励公式为：
奖励原则和出块类似，多劳多得，按量奖励。其中，多签服务中，以签名次数为奖励来计Era point，而在RPC服务中，以服务被调用的次数来计数。在一个Era中，Stafi协议会设置对应服务的计数，初始设置的计数如下：
类型 | 签名 | RPC调用 |
Era point | 20 | 2 |
单个SSV在一个Era中获得的奖励，可以通过计算该Era中所有SSV的签名和RPC调用的情况，得到该SSV提供服务情况的占比，从而得到该SSV该Era中的奖励情况。奖励的分配周期为1个Era，奖励的数量根据服务使用情况来定。
在Stafi协议初期，为了尽可能的招募到足够多的SSV，奖励上采用一种比较平稳的过渡方式，当SSV的数量并没有达到理想的数量时，合约安全性有较大隐患，适当加大激励吸引SSV是有必要的，但为了防止少部分人将拿走大部分的奖励，造成增发压力，所以需要把奖励分发设置在一个合理水平。在并没有太多数据支持的情况下，过渡时期将由基金会主导奖励的具体分发，通过计数情况判断，同时设置上限来减少增发压力，多出来的奖励将会流通到国库中（Protocol Treasure）以用作他用。当平稳过渡到合理数量水平后，奖励将通过算法优化，自动发放给SSV，实现激励的全自动化。
SSV-Slash
和前文中的Staking-Slash不同，本段主要讲的是针对SSV不当行为的Slash
对于SSV的惩罚行为有两种（主要针对多签服务），第一种是签名阶段，不提供签名；第二种是签名阶段，提供错误的签名。两种签名问题的表现其实是一致的，即在N/M的多签系统中，签名人数很可能无法达到该阈值N，导致无法完成用户的请求。对于不提供签名或者签名错误的SSV，需施以Slash惩罚。
在多签签名阶段，SSV需要签名帮助系统执行相关任务（包括用户操作，线上轮换等），不提供签名服务一般表现为掉线/未响应，在一个Era中未执行签名，而且也没有发送心跳检测的被认为是未响应，如果此时该行为没有执行退出策略，将被Slash。另外，在多签签名阶段，SSV在签名服务中提供了错误的签名，错误签名不能被系统承认，系统会对多次提供签名错误的SSV给予退选和Slash的处理。
Stafi协议在多签系统中设置了阈值，小于阈值会对Staking合约资产产生危害，所以在通常情况下，Slash和退选是一起发生的，主要规则如下
当未签名或者提供错误签名的SSV数量小于门限值的2/3时，SSV被Slash的比例较小，不退选；
当未签名或者提供错误签名的SSV数量大于等于门限值的2/3，小于门限值时，系SSV被Slash的比例较大，下个Era会被退选；
系统会Slash两种签名问题，因为不提供签名和提供错误的签名对系统的危害一样，所以它们拥有同样的Slash公式
其中，n是总的验证人数量，k为未提供或者提供错误签名的SSV数量，
假设n=21,签名阈值是12，
当k <= 2, Slash的比例为0
当k = 3, Slash的比例为0.002
当k = 4, Slash的比例为0.00814
当k = 5, Slash的比例为0.01836
...
当k = 8, 结果为0.07346
当k >= 9, 结果为 0.1
总体来说，当未提供或者提供错误签名的SSV>2时，就开始罚没SSV的抵押金了，Slash的比例最小为0，最大值为0.1，随着k值变大，结果变大接近0.1。
Last updated