Stafi 经济白皮书

Author : Liam

1 背景

到如今,已经没有人敢否认,Proof of Stake(PoS)是当前的主流共识之一,当前PoS的广泛接受程度不言而喻。从2012年开始,在不同团队努力下发展的近8年时间里,诸多的技术难题逐步被攻克,无利害攻击(Nothing at Stake),长程攻击(Long range Attack)等等,到2018年,PoS共识趋于成熟,同年6月份,以EOS和Tezos为代表PoS(类PoS)项目开始上线,标志着新一代的PoS共识开始登上舞台。在接下来发展的2年时间中,PoS迎来了黄金发展期,2020年新型公链的代表——Polkadot,Near,Solana以及Celo等,无一不例外的都采用了PoS。

激励和安全一直都是PoS共识中最受关注的的两个问题,PoS设计中以安全为主导的激励区别于PoW,Staking带来了新的激励方式,同时也创造出了新的商业模式(Staking金融——Staking Finance),围绕Staking为激励手段展开的金融应用开始被广泛采用,其发展随着区块链整体的进步变得日新月异。不得不说,Staking已经变成了当前PoS项目中最重要的设计之一,它既带来了新的体验,也带来了新的问题,特别是基于安全设计的用户体验。

Stafi主要解决目前Staking Finance中的Token流动性问题,激励通常被设计为对Token Staking的奖励,而Staking的过程其实就是参与共识的过程,参与共识需要稳定和安全,而锁定Staking Token则是发展过程中出现的对应机制。这个锁定呈现一定的周期性,是获得激励的前提,这带来的问题就是,在当今不成熟的Token交易市场下,激烈波动可能会导致的锁定资产的贬值,锁定的Staking Token并不能及时对市场做出反应,导致资产损失,在这种情况下,系统的激励往往无法覆盖损失的成本。

Stafi协议被创造出来,使得Staking token在获得激励的同时,在市场上交易变得可能。Stafi创造了一套独有的Staking Contracts,让Staking Token能通过Staking合约同时具备以上的两种能力,帮助用户通过Staking可以获得更多可能性,这也是Stafi协议最主要解决的问题。

2 介绍

Stafi协议用Substrate组件创建,采用NPoS共识(Nominated Proof-of-Stake),通过在上层创建Staking合约与不同公链通信,完成Staking过程。合约并不改变原有公链的Staking流程,而是在原Staking过程中扮演者账本的角色,通过合约进行Staking的Token将会被记录在合约中,最终锁定在原链上。

维护整个Stafi协议,需要验证人(Stafi Validator,简称SV)和特殊验证人(Stafi Special Validator,简称SSV)的参与,验证人负责整个协议的安全,特殊验证人负责所有Staking合约的安全。协议对验证人的选举和协议对验证人的激励显得尤为重要,具体的选举和激励会在第三章中描述。

FIS是Stafi的原生通证,FIS行使3个主要作用,燃料、Staking和价值捕获。

  • FIS是系统的燃料,防止协议中出现大量的垃圾信息,FIS的费用收取会被分配给验证人和国库,分配比例可以通过参数调整。

  • Stafi采用NPoS共识,借鉴了Polkadot的激励底层,基于安全设定,按照FIS的Staking占比来调整激励曲线,实现网络安全和长期发展。

  • FIS行使Stafi协议价值捕捉的作用(主要是提供rToken流动性带来的价值)。Stafi的Staking 合约除了向Staker提供Staking服务之外,还提供流动性的支持,Stafi协议会对使用用户收取服务费来赋予网络价值。价值的体现会在第5章中描述。

rToken(reward Token)是分发给Staking token持有人的替代性凭证,Staking token会在原链上被锁定,而锁定关系会被记录在Staking合约中,rToken是Staking合约的唯一认证凭证,持有者可以通过rToken实现对合约的关系修改,执行增加委托,赎回原Token等操作,同时持有rToken还能获得Staking Token产生的奖励,具体说明会在第4章中描述。

整体上,可以将Stafi协议看成是一个资产底层协议,通过rToken,协议可以将StakingToken解放并重新释放到交易市场当中,Stafi协议通过提供流行性获得收益,收益将通过回购销毁的方式赋予原生Token价值。该价值链涉及到多个模块的相互工作,下面会从具体方面来进行介绍。

3 激励

Substrate集成了共识机制——BABE+GRANDPA,BABE决定出块选择,GRANGDPA决定出块的最终确定性。在出块选择中,Stafi采用选举的方式,验证人通过Staking FIS或者接受Staked FIS的提名,获得出块权重。新的块通过GRANDPA共识确定后,超过当前2/3权重的Staked FIS投票的链,成为最终链,其中最新块的出块者得到出块奖励。

3.1 验证人(Stafi Validator,简称SV)

3.1.1选举Election

任何想要参与网络,提供安全保护的人都有机会成为验证人。通过运行节点,获得Stake提名,就有机会成为验证人。Stake可以通过自己Staking或者是Staker提名而来,最终依靠总体Stake的拥有数量来决定当选机会。

网络初期,为了保证网络安全和稳定,Stafi将开放一定数量的验证人位置,Stake拥有数量排名在确定数量之前的验证人进入到共识选择范围,在网络逐渐达到稳定之后,Stafi协议会通过链上投票的方式,决定是否要扩大验证人数量。

Stafi协议把一定数量的块进行切分,6s左右一个块,一个epoch 1小时,一个Era=24个epoch=1天,每个era进行下一个era的选举,每一个块槽可以有多个出块人,共识机制通过VRF算法选出出块人,当一个块槽(Slot)有多个块产生的时候,最先达到更大范围网络的块为最终块,该出块人可以获得奖励。

3.1.2 退选

一个Era中,已经选举上的SV执行正常的出块和投票,当SV并不能按要求完成任务时,SV将会被退选,并在下个选举周期不能参选。触发退选的条件有以下

  • SV产生作恶行为,被系统Slash,该SV同时被退选,其名下的提名会根据算法自动优化分配

  • SV在一个Era中,无响应/不在线情况超过一定比例时,具体体现在丢块数比例占比,会被退选,其名下的提名会根据算法自动优化分配。

被退选期间,其名下的提名不产生收益。

3.1.3 奖励Reward

在Stafi的NPoS设计中,SV以下三个类型的行为可以获得奖励

  1. 出块(未引用叔块的块)

  2. 叔块出块(引用了之前未被引用过的叔块的块)

  3. 子块出块(引用了叔块的块)

为了保证出块,每个出块人通过VRF算法选出,同时,为了防止选出的出块人不出块,共识还会提前按照Round-Robin的算法选出后补出块人。这样的处理方式能保证每个块槽能正常出块,但是也会使得同一个块槽有多个块产生,此时通过GRANDPA确定的块为最终块,其他的块为叔块,叔块的子块同时也会得到奖励,但是奖励会相对少。

无论是最终块,叔块还是子块,验证人在合法范围中做了相等的工作,所以单个块对验证人的奖励是均等的,同时在NPoS的设计中,每个验证人被赋予相同的选举权重(Voting Power),无论其接受的提名Stake有多少,每个验证人被选上的概率是一样的。当然,Stake的多少决定了你是否能进入验证人集合。

出块机会被平均分配给验证人,这意味着奖励分配和Stake权重并没有直接的关系。很多项目设计的PoS共识中,出块机会和Stake权重成正比,即更多Stake拥有获得更多奖励的机会,从目前运行的项目来看,Stake有向头部集中的趋势,前10名的验证人一般可以占据50%以上的Stake率,NPoS的设计可以很好的避免此类问题,奖励机会均等可以让Stake的分布更加均衡,更加去中心化,目前NPoS共识正在Kusama网络中验证。

对于提名人来说,提名给越少Stake的验证人,可以获得更多的奖励,相反,则得到更少的奖励。单位FIS的提名在提名少的验证人身上可以获得更丰厚的回报,但是,提名少的验证人可能会出现一些问题,比如长期掉线,或者技术不过关,也可能是因为名气较小,节点业务才刚刚开始,这些不确定性是提名者需要注意的。

为了更好的分发奖励,Stafi以一个epoch为周期记录页每个验证人的奖励,同时,以一个Era为计算奖励周期,验证人可以在一个Era结束后领取(Claim)奖励。领取奖励后,协议会根据Stake的比例给提名人自动分发奖励(警告,奖励如果在84个Era内不被领取,奖励将会被销毁,所以需要验证人提前领取奖励)。

按照规定的奖励类型,每个验证人可以在出块后获得奖励,每种类型的块对应的奖励计数为

类型

出块

叔块

子块

奖励计数

20

2

1

假设验证人为v,在一个Era e中出块数量为n,叔块数量为s,子块数量为x,该验证人在该e中得到的总奖励计数r为

re=20n+2s+xr_{e} = 20n+2s+x

假设验证人集合有100人,即{ },那么e中,所有验证人的总奖励计数R为

Re=r1+r2+r3+...+r100=v=1100rvR_e = r_1+r_2+r_3+...+r_100=\sum_{v=1}^{100}r_v

进一步可得

Re=v=1100(20nv+2sv+xv)R_e=\sum_{v=1}^{100}(20n_v+2s_v+x_v)

如果此时Stake率为50%,通胀率为10%,那么可以算出e的总奖励(具体计算可以查看3.3章)为

PNPoSeP^e_{NPoS}

那么可以算出单个验证人在e得到的奖励为

rvneRePNPoSe\frac{r^e_{v_n}}{R_e}P^e_{NPoS}

扣除验证人的手续费后,提名人可以获得剩余奖励中属于自己比例的部分。

3.1.4 Slash

Slash是针对验证人在共识中产生“非法”行为的惩罚,此类型为可能造成共识不稳定,系统崩溃等问题。对于此类问题,NPoS共识通过“罚没”抵押金的方式对产生“非法”行为的验证人进行惩罚。和奖励计算一样,惩罚的计算每个Era计算一次。惩罚的类型和方式如下。

  1. 离线/未响应

如果验证人在一个Era中不出块也不发送心跳信号,那么该验证人会被判断为离线/未响应。当离线/未响应节点数较多时,为了保证系统问题,系统会开始罚没一部分Staked的代币(包括验证人和提名人)为了防止错扣,我们设置以下公式

min((3(k(n/10+1)))/n,1)0.07min((3*(k-(n/10+1)))/n,1)*0.07

其中,n是总的验证人数量,k为离线验证人数量,注意当k - (n / 10 + 1) < 0的时候,惩罚金额0。假设一共有100个验证人,n=100

假设n=100,

当k=1~11,Slash的比例为0;

当k=12,Slash的比例为 0.03 * 0.07 = 0.0021

当k=21,Slash的比例为 0.3 * 0.07 = 0.021

当k=31,Slash的比例为 0.6 * 0.07 = 0.042

当k=41,Slash的比例为 0.9 * 0.07 = 0.063

当k=51,Slash的比例为 1*0.07=0.07

总体来说,Slash的比例最小为0,最大为7%,当所有节点中少于10%离线时,单个节点离线或者没有响应是不会被slash的,当1/3节点同时离线的时候,Slash比例接近5%。

  1. 双签

在出块阶段(Babe共识)和投票阶段(Grandpa共识),为了保证共识安全,在单个轮次不同链上投票,或者是在同一个块槽生成两个新区块,都会被认定为作恶。惩罚公式如下

min((3k/n)2,1)min((3k/n)^2,1)

其中,n为验证人数量,k为一个Era内混乱或者无效投票的验证人数量。

假设n=100

当k=1,Slash的比例为0.03 * 0.03 = 0.0009

当k=10,Slash的比例为 0.09

当k=21,Slash的比例为 0.3969

当k=31,Slash的比例为 0.81

当k=41,Slash的比例为 1

当k=51,Slash的比例为 1

总体来说,Slash比例最大的是1,也就是验证人有可能会被罚没100%的Stake,而且双签的惩罚要比离线的惩罚严重,只有1个人发生了双签都会被惩罚。

3.2 特殊验证人(Stafi Special Validator,简称SSV)

特殊验证人的设计是为了保证Staking合约的安全。Staking合约记录了原链资产和rToken的关联关系,其安全性极其重要。Staking合约最基础的底层是一个链上的多签账号,不同Staking链的合约或者多签有差异,所以在实现方式上有所不同。

SSV的选举和服务独立于SV,因为安全需要,需要设置特殊的服务,主要包括签名,RPC,Oracle服务,其中Stafi启动阶段,主要是签名和RPC服务,也是激励的主要行为。针对SSV的激励同样独立于SV的之外,所以SSV提名人即可以获得SV的奖励,也可以同时获得SSV的奖励。

3.2.1 选举Election

特殊验证人SSV的数量根据部署的Staking合约确定,每部署一个新的Staking合约都需要有一批新的SSV来管理,具体的SSV数量需要根据Staking合约管理的资产额来分配,满足安全的需要。

SSV的选举从SV中产生,已经成为SV的验证人可以通过部署SSV服务,注册成为SSV,系统根据注册SV的委托量,在线率,自抵押比例等情况,选举SV成为SSV,注册成功的SV将进入SSV候选池,候选池中的SSV会在线上轮换或者是新Staking合约部署的时候参与选举,选举成功后即可以参与到SSV的工作中。

在每个SSV选举Era开始前,系统会根据SV的注册情况进行选择,提名较多的SV拥有更高的中签率,被选中的SSV进入候选池后,被选中的概率和提名Stake的数量成正比的关系,同时,能管理的资产也更多。另外,SSV中的抵押资产来自于SV,但是相对于SV,SSV有更高的自抵押占比要求,当发生Slash行为时,SSV本身将承担更高比例的罚没。

SSV的轮换分为两种,一种是定期轮换,一种是紧急情况下的轮换,两种方案均以满足资产的安全性需要。定期轮换的作用是保证SSV的活性,同时让奖励尽量均匀的覆盖候选池中的SSV,而紧急情况下的轮换主要发生在签名人数接近阈值时,假设每轮签名需要M中N个人签名数量,但实际签名人数S接近或者等于(M-N)时,系统会紧急调换未提供签名的SSV,以保证签名人数的活性。无论是定期轮换还是紧急情况下的轮换,每次轮换会产生新的SSV,旧有的SSV会被轮换到休息位,等待下个周期的选举,在休息位的SSV因为没有提供服务,将无法获得部分奖励。出于灵活性的要求,SSV的选举周期以Era为单位,具体的周期我们还在探索过程中,可通过线上治理参数。

3.2.2 退选

一个Era中,已经选举上的SSV执行正常的签名工作,当SSV并不能按要求完成任务时,SSV将会被退选,并在下个选举周期不能参选。触发退选的条件有以下

1、SSV产生作恶行为,被系统Slash,该SSV同时被退选,无法参与下周期选举

2、SSV在一个Era中,不签名或者提供错误签名的数量超过一定比例时,该SSV会会被退选。

被退选期间,没有被轮换的SSV签名不产生收益。

3.2.3 奖励Reward

对SSV的奖励独立于SV之外,为了维护Staking合约安全,多签签名对合约起到增删改查的作用,而RPC则为Staking流程提供了可靠的支持,另外,Stafi协议中基于喂价的StakingDrop也需要SSV运行Oracle进行支持。在目前的协议当中,Stafi对SSV的主要激励行为主要有两种:一种是多签服务,一种是RPC服务。

奖励原则和出块类似,多劳多得,按量奖励。其中,多签服务中,以签名次数为奖励来计数,而在RPC服务中,以服务被调用的次数来计数。在一个Era中,Stafi协议会设置对应服务的计数,初始设置的计数如下:

类型

签名

RPC调用

奖励计数

20

2

Tips:具体的多签技术和RPC调用计算方案,后续会在Stafi产品文档中详细介绍

单个SSV在一个Era中获得的奖励,可以通过计算该Era中所有SSV的签名和RPC调用的情况,得到该SSV提供服务情况的占比,从而得到该SSV该Era中的奖励情况。比如:假设Era e中,一个SSV参与签名50次,RPC调用1000次,那么此Era中,他得到的计数为3000,当前e中,总计数为300000,那么该SSV3000的计数占总体技术1%,那么他将得到SSV总奖励的1%。

奖励的分配周期为1个Era,奖励的数量根据服务使用情况来定。由于每年的通胀率是固定的,我们设定每个Era给SSV的奖励总量为:

PSSVe=PSignaturee+PRPCeP^e_{SSV}=P^e_{Signature}+P^e_{RPC}

在Stafi协议初期,为了尽可能的招募到足够多的SSV,奖励上采用一种比较平稳的过渡方式,当SSV的数量并没有达到理想的数量时,合约安全性有较大隐患,适当加大激励吸引SSV是有必要的,但为了防止少部分人将拿走大部分的奖励,造成增发压力,所以需要把奖励分发设置在一个合理水平。在并没有太多数据支持的情况下,过渡时期将由基金会主导奖励的具体分发,通过计数情况判断,同时设置上限来减少增发压力,多出来的奖励将会流通到国库中(Protocol Treasure)以用作他用。当平稳过渡到合理数量水平后,奖励将通过算法优化,自动发放给SSV,实现激励的全自动化。

3.2.3 Slash

对于SSV的惩罚行为有两种(主要针对多签服务),第一种是签名阶段,不提供签名;第二种是签名阶段,提供错误的签名。两种签名问题的表现其实是一致的,即在N/M的多签系统中,签名人数很可能无法达到该阈值N,对于不提供签名或者签名错误的SSV,其对Staking合约的安全有潜在的威胁。

在多签签名阶段,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。

  1. 通胀

针对SV和SSV的奖励来源于系统通胀,和比特币的Coinbase机制类似,Stafi协议在每个块都会产生新的FIS(过程称之为Coinstake),用以激励验证人和特殊验证人付出的计算和存储资源。通胀率的设置是一个经济学问题,按照历史演变和大量数据表明,现阶段的PoS项目年通胀率大概在5%~20之间。

通胀率的表达为:

I=TokenTokenTokenI=\frac{年终Token数量-年初Token数量}{年初Token数量}

在Stafi协议的设计中,通胀率构成主要有以下几个方面

I=INPoSISlashingITxfeeI=I_{NPoS}-I_{Slashing}-I_{Tx-fee}

其中

INPoS=ISV+ISSVI_{NPoS}=I_{SV}+I_{SSV}

为系统共识奖励,在Stafi中包括针对SV和SSV的奖励。Slash的FIS和交易手续费的FIS,都有一部分会分给举报人,一部分会补充到国库中,国库有销毁逻辑(具体可以查看第6章节)。

和Staking率有关系,不考虑其他影响因素,当Stake占越高时系统拥有更高的安全性,Stake越低时安全性相对减弱,高流动性代表着Token具有较低的流动性,在FIS的设计中,通胀率会根据Stake的占比动态调整通胀率,当Stake占比升高时,系统会减少激励,反之,Stake占比降低时会提高激励。在调整过程中,Stafi协议沿用了一个理想的Stake占比50%,即当Stake占比超过50%之后,激励将不再升高, 在2.5%~10%之间,激励曲线如下。第一年的增发率为10%,如果Staking率没有达到理想值,多余的奖励将被流通到国库。

和服务调用有关系,包括多签签名服务和RPC调用服务。Staking过程中,需要多次调用RPC和多签服务,为了支付服务所产生的费用,系统会给与每次调用奖励。初始设置中,协议规定固定增发x%作为服务调用的奖励,x的初始范围设定在【1,2】。

系统按照设定,奖励每笔调用,一个Era计算一次。当前Era中调用获得的奖励小于系统在该Era的增发,那么多出来的奖励将会被销毁。如果调用奖励超过系统在该Era的增发,那多单位调用所奖励的FIS也会相应减低。此策略会在主网上线后的1年时间里,动态调节,后通过线上治理的方式,由社区决定。

的通胀并不是确定的数字,在大部分人都是诚实的前提下,Stafi协议应该不会有太大量的Slash情况出现,严重事故发生的几率也比较小。现有PoS项目,发生过几起双签事故,但大多都是验证人失误导致,所以 对整体的通胀率影响不大。

的通胀也并不是确定的数字,依赖于Stafi网络的使用情况,特别是rToken的使用,目前并不能评估,但是整体上随着rToken的发展,对通胀是有一定的缩减作用的。

4 通证Tokens

4.1 FIS

FIS是Stafi协议的原生Token,FIS的初始发行量为1亿,每年有动态的增发,关系类似Dot和Polkadot,用于防止系统滥用和捕获价值。在Stafi中,FIS主要承担的具体作用是:

  1. Staking

参与Stafi共识的验证人需要Staking FIS才能进入到共识网络当中,提名人也需要Staking FIS才能提名验证人来获得激励。

  1. 交易手续费(Tx fee)

为了防止网络被滥用,发起交易时,发起方需要向系统支付一定的FIS,才能获得计算资源,一定程度上禁止了无效交易。

  1. 链上治理

持有FIS可以参与Stafi协议参数的修改,投票协议升级和决定发展方向,任何人都可以想协议提交议案,持有FIS的持有者向协议投票,1FIS 1票。

  1. 捕获价值

Stafi协议的收益,将通过公开的市场操作,通过回购销毁FIS的方式,给FIS持有者以价值。

4.2 rToken(reward-Token)

rToken是Staker通过Staking合约Staking token后获得的有效凭证,比如Staking XTZ,用户可以获得rXTZ,Staking Atom,用户可以获得rAtom。rToken和Staking Token是1:1的数量关系,持有rToken可以获得Staking Token的激励,同时,rToken可以被当成Staking Token在市场上交易,交易后,奖励权和赎回权都会变更,由Staking 合约修改。

rToken没有数量限制,理论上等于接入PoS项目的Token总量,rToken被赎回时有销毁机制,总体上维持和Staking Token的统一。

4.1.1 作用

在Stafi协议中,rToken承担的具体作用是:

1.获得Staking奖励

rToken是Staking Token的映射,Staking Token获得的Staking奖励将会发到rToken的持有人身上。赎回期间rToken会被锁定,也不再拥有奖励的权益。

2.可交易

rToken可以被交易,交易后,其对应的激励权和赎回权都将变更。Stafi协议会推进在中心化交易所去中心化交易所上线rToken和对应Staking Token的交易对,为rToken提供交易流动性。

3.可赎回

rToken是Staking Token唯一的赎回凭证,持有rToken的人可以向Staking合约发起赎回,赎回过程不再拥有激励的权益,同时rToken会被锁定,待Staking token在原链解锁后,发送回用户账户。

4.1.2 分配Distribution

rToken持有者可以获得Staking Token的收益,同时也承担着Staking Token被原链Slash的风险,Staking Contracts负责监控Staking Token的奖励和Slash情况,当发现验证人发送奖励或者被Slash时,会自动修正记录。

rToken的转移不受限制,这会导致rToken对应的奖励和Slash修正,会受到跨链通信的延迟,修正记录可能无法对应原链的奖励数量,特别对于一些需要链下发送奖励的Staking Token,Staking Contracts无法准确记录到奖励的分配情况。同理,Slash情况也比较相似,但是因为Slash的是Staking Token本身,而不是奖励部分,这让Staking合约对Slash的处理变得更加谨慎。

对于rToken对应权利的分配,按照目前的研究成果,我们倾向于使用更加简单易懂的方式进行处理,通过对风险偏好的共同承担实现利益的最大化,而后,Stafi会接入更多的Staking项目,通过数据的监控,探索和原链更加相似的分配方式。

此外,引入外界的“帮助”可能有助于我们提高整个系统的抗风险能力,比如引入Slash保险,购买Slash保险的Staker可以在发生Slash时,免于财产损失。

后续,我们还会继续探索不同项目的奖励分发机制和Slash机制,定制化处理各类项目是一个阶段目标。现阶段,各类PoS项目设计趋向于相同,这让设计一套统一的分发机制变得可能。

5 手续费Fee

5.1 交易手续费(tx fee)

为了防止资源滥用,协议为每笔交易都设置了手续费,交易发起方需要在账户中保留少量的FIS才能发起交易。计算手续费的方式较为复杂,涉及到计算(CPU),带宽(Bandwidth)和存储(Storage)的计算,同时,因为交易的使用情况以及日新月异的科技发展,设计一套能动态调整当前手续费的机制变得极其重要。

以太坊等模型里面,一般使用Gas/Gas Fee的模型,通过计算每一笔交易所需要耗费的计算量,带宽以及存储来确定每一笔交易所需要支付的Gas Fee。在Stafi协议中,GasFee以FIS来结算。计算量和带宽的计算与存储计算不一样,一笔交易需要长期的存储在区块中,但计算量和带宽则是在发送时候一次性”结清“,所以在具体的计算中,计算量和带宽只需要计算1个CPU指令和通过线上发送的事务的大小(即带宽,单位为字节数),就可以得到当前交易所需消耗的Gas(仅计算和带宽)

Gastx=numberOfCPUinstructions(tx)+αlenthOf(tx)Gas_{tx} = numberOfCPUinstructions(tx)+α*lenthOf(tx)

其中α是1个CPU指令和带宽之间的关系,一般设置为常数。

对于开发者或者用户而言,在发送交易前或者执行合约前能计算Gas使用量显得非常重要。在Gas模型中,一般通过两个参数来判断:

  • 一个区块中,Gas的最高限制量Gaslimit

  • 一个区块中,Gas的真实使用量Gasused

如果Gasused无限接近于GasLimit,那么就要适当提高Gaslimit,其对应着验证人所提供的计算等资源也需要相应提高,这需要伴随着更多的激励,才能达成。在具体的设计中:

GasFeetx=GasFeetxβGasFee_{tx}'=GasFee_{tx}*β

其中β是GasFee的动态调整参数,一般设置为常数,用以调整激励的适当度。

在Stafi协议中,tx的计算和Gas模型不太一样,但是大体上的逻辑是相似的,通过计算以下交易参数来计算交易费用:

  • 长度(Length): 一笔交易的字节大小

  • 时长(Time): 处理数据存储所需时间

  • 内存(Memory): 处理交易所耗的内存大小

  • 状态(State):状态存储量大小

通过以上计算,可以得出处理一笔交易所需要的手续费。为了简化,我们定义Weight来代表时长和状态,可以得出

Feetx=ctraffic(basefee+type(tx)lenthOf(tx))+weight(tx))Fee _{tx}=c_{traffic}∗(basefee+type(tx)∗lenthOf(tx))+weight(tx))

其中 是根据网络交易情况动态调整的参数,tpye(tx)是根据交易类型动态调整的参数。

总体来说,交易手续费涉及到多方面的问题,包括用户体验,开发者友好性,资源利用程度,还有验证人补偿等等,动态参数的调整需要根据网络情况进行调整,调整速度以一个区块为间隔,这借鉴了BTC的做法,矿工通过投票决定一些重要参数的设置,比如区块大小。

另外,Staf协议中对交易类型进行了划分,标注了不同交易类型的优先级,每个区块会预留空间给高优先级的交易,以保证重要交易类型能被打包进入区块,而如普通的转账等交易类型,需要通过设置手续费的高低,来“竞争”区块空间,一般情况下,验证人会选择手续费更高的交易优先打包进入区块。

协议所得的所有交易费,会通过一定的比例分发给验证人(SV)和国库(Treasure),比例的参数可以通过线上治理实现修改,国库如何利用这笔收益,会在第6章中具体讲到。

5.2 流动手续费Liquidity Fee

Staker通过Staking Contracts进行Staking,获得rToken,持有rToken期间,会获得原链提供的年化百分比的激励,不同的原链激励总量不一样,但方式相差无几。rToken代表了流动抵押资产的可能性,Staker可以选中持有rToken获得收益,也可以选中将rToken进行交易,一旦进行转移,那么rToken的权益将转移到买方手中,也意味着原来持有该rToken的Staker获得了Stafi提供的流动性,此时,Stafi协议会对该rToken在持有期间产生的奖励进行收取手续费,维持网络运行。

当rToken被转移或者使用rToken赎回原资产时,系统会进行收取手续费,收取的费用为Staking期间所获得奖励的百分比:

Feeliquidity=αpayoutstakingrewardFee_{liquidity}=α*payout_{stakingreward}

其中α为手续费百分比参数。手续费参数可以通过链上治理进行动态调整,在协议初期,基金会会主导手续费调整,直到系统稳定后准备交给社区治理。

手续费可以通过Staking Token支付,也可以通过FIS支付,所有手续费会分配到一个公用池子中,池子中的收益主要有三个用途,其中,大部分会通过回购销毁FIS的方式,少部分会分配给基金会,早期还会有一部分分配给团队,用于支持早期Staking Contracts的开发。

回购销毁FIS的方式,可以赋予FIS持有者价值。另外,Stafi协议每年的通胀,会对整个协议造成一定的升值压力,而回购销毁是和通胀相反的操作,我们可以简单将Stafi协议理解为一个国家,当国家增发货币少于GDP增速时,整体经济体是往上走的,相反,整个国家处于严重的通货膨胀。在Stafi中,我们也可以简化Stafi的增值模型:

FISburn>FISinflationCreatevalueFIS_ {burn} >FIS _{inflation}→Createvalue
FISburn<FISinfaltionLostvalueFIS_{burn} <FIS_{infaltion}→Lostvalue

在项目早期阶段,会出现销毁小于通胀的情况,这是合理的。早期项目属于开发和发展阶段,需要投入资金才能完善产品,当产品完善,用户使用数量上来,Stafi才能为Staker创造收益,又能捕获Staker使用Stafi提供的流动性的价值,这样,协议收益会逐步提高上来。

6 国库Protocol Treasure

为了满足协议的可持续发展和去中心化,Stafi设置了“国库”,用以激励为项目做出贡献的个人或者团队。国库的使用通过线上治理的进行审批,开发者可以向公众公示提案,投票通过的提案会获得国库激励。

在项目前期,国库的激励主要针对以下几个方面

  1. 开发新合约(Staking Contracts),比如为Stafi接入新的Staking合约

  2. 开发新协议,比如在Stafi上开发其他类型的抵押合成Token

  3. 开发rToken衍生品,比如开发基于rToken的抵押节点产品

国库的收入来源主要来自以下4个方面

protocolRewardt=protocolPct(feeliuidity+tx+rewardinflation+slash)protocolReward_t=protocolPct*(fee_{liuidity+tx}+reward_{inflation}+slash)
  1. 部分流动手续费:用户使用rToken获得流动性时,部分收取的手续费会流通到国库中。

  2. 部分交易手续费:交易手续费一部分会奖励给验证人,一部分会流通到国库中。

  3. 部分Slash所得:针对SV和SSV的Slash一部分会提交给报告人,一部分会流通到国库中。

  4. 部分Staking奖励:当Staking率没有达到理想值50%时,多余通胀的奖励会流通到国库中。

7 未来工作Future works

本篇经济白皮书主要是介绍了Stafi协议的激励,惩罚以及如何捕获价值,其中,涉及到特殊验证人的激励和惩罚部分,是独立于Substrate机制之外的,在设计过程中,会需要我们对项目的使用情况有一个较好的估算,但我们并不能很好的拿捏,因而选择了较为稳妥的方法,这并不智能,改善方法会通过后期的实践中,通过更多的数据来指导当前的机制设计。

同时,捕获价值是Stafi协议的一个重要机制,通过提供流动性,收取流动手续费的方式,将协议创造的价值回归到系统中,但是,回购销毁的方式,并不是一个完全去中心化的做法,作为一个去中心化的协议,完成自动或者线上投票实现的方式,将会是Stafi未来主要努力的一个方向。

rToken作为Stafi协议的衍生品,其承担的作为除了提供流动可能性之外,它还能发挥出更多的价值,首先,通过Stafi协议,大部分Staking token可以通过rToken流通到其他生态。其次,rToken作为一种新型资产,其被再次衍生的可能性很大。最后,rToken可以融入到现有Defi生态当中,充当抵押物,甚至是用于借贷,都是有可能的,但是rToken的再衍生也会带来新的问题,包括锚定稳定性,乐高Defi的组成风险问题等等,这些都是未来需要研究的方向。

关于rToken的另外一个问题就是权利分配,主要指奖励分发和Slash风险承担,因为各类PoS项目发送奖励的机制不同,也因为Staking Contracts和外链有交互延迟,导致权利分配并不一定能和原链保持100%的一致,甚至一些采用链下分配权利的项目,Staking合约在处理过程中比较难以确权,所以现阶段采取的大众共同承担风险偏好的方案,虽然说可以解决问题,但是并不理想,随着项目开发的深入,在这个方向上的优化值得花费更多的时间和精力。

未来,Stafi的发展方向将向着平台进发,实现抵押资产再衍生的阶段性目标。当然,除了Staking资产之外,任何抵押或者锁定中的资产都可以通过Stafi的Staking Contracts实现流通,新流通的Token可能与rToken的类型不一样,但是Stafi通过多种开发套件的开发,可以实现一个衍生资产平台的主要功能,满足资产多样化的要求。

期待Stafi的发展吧!