特殊验证人(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服务。所以目前的奖励公式为:

PSSVe=PSignaturee+PRPCeP^e_{SSV}=P^e_{Signature}+P^e_{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公式

min(((3(kn/10))/n)2,1)0.1min(((3*(k-n/10))/n)^2,1)*0.1

其中,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。