# 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为 $$ r\_{e} = 20n+2s+x $$ 假设验证人集合有100人，即{ }，那么e中，所有验证人的总奖励计数R为 $$ R\_e = r\_1+r\_2+r\_3+...+r\_100=\sum\_{v=1}^{100}r\_v $$ 进一步可得 $$ R\_e=\sum\_{v=1}^{100}(20n\_v+2s\_v+x\_v) $$ 如果此时Stake率为50%，通胀率为10%，那么可以算出e的总奖励（具体计算可以查看3.3章）为 $$ P^e\_{NPoS} $$ 那么可以算出单个验证人在e得到的奖励为 $$ \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.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) $$ 其中，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的奖励总量为： $$ P^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\*(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=\frac{年终Token数量-年初Token数量}{年初Token数量} $$ 在Stafi协议的设计中，通胀率构成主要有以下几个方面 $$ I=I\_{NPoS}-I\_{Slashing}-I\_{Tx-fee} $$ 其中 $$ I\_{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率没有达到理想值，多余的奖励将被流通到国库。 ![](https://lh5.googleusercontent.com/GFxu7CB4lEkYwXHt7UZGmoeAilE3Vz7_ibB-Q2v73KBuqewlSMKpuG23C1RH2SsO5qMh8YIYW_BxQoE-cyDZIxr7fR7b95RM1nJ8mtyukwCgQ6aoBDGQzlos_KOP8Jj6vmm9DQYp) 和服务调用有关系，包括多签签名服务和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（仅计算和带宽） $$ Gas\_{tx} = numberOfCPUinstructions(tx)+α\*lenthOf(tx) $$ 其中α是1个CPU指令和带宽之间的关系，一般设置为常数。 对于开发者或者用户而言，在发送交易前或者执行合约前能计算Gas使用量显得非常重要。在Gas模型中，一般通过两个参数来判断： * 一个区块中，Gas的最高限制量Gaslimit * 一个区块中，Gas的真实使用量Gasused 如果Gasused无限接近于GasLimit，那么就要适当提高Gaslimit，其对应着验证人所提供的计算等资源也需要相应提高，这需要伴随着更多的激励，才能达成。在具体的设计中： $$ GasFee\_{tx}'=GasFee\_{tx}\*β $$ 其中β是GasFee的动态调整参数，一般设置为常数，用以调整激励的适当度。 在Stafi协议中，tx的计算和Gas模型不太一样，但是大体上的逻辑是相似的，通过计算以下交易参数来计算交易费用： * 长度（Length）: 一笔交易的字节大小 * 时长（Time）: 处理数据存储所需时间 * 内存（Memory）: 处理交易所耗的内存大小 * 状态（State）:状态存储量大小 通过以上计算，可以得出处理一笔交易所需要的手续费。为了简化，我们定义Weight来代表时长和状态，可以得出 $$ 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期间所获得奖励的百分比： $$ Fee\_{liquidity}=α\*payout\_{stakingreward} $$ 其中α为手续费百分比参数。手续费参数可以通过链上治理进行动态调整，在协议初期，基金会会主导手续费调整，直到系统稳定后准备交给社区治理。 手续费可以通过Staking Token支付，也可以通过FIS支付，所有手续费会分配到一个公用池子中，池子中的收益主要有三个用途，其中，大部分会通过回购销毁FIS的方式，少部分会分配给基金会，早期还会有一部分分配给团队，用于支持早期Staking Contracts的开发。 回购销毁FIS的方式，可以赋予FIS持有者价值。另外，Stafi协议每年的通胀，会对整个协议造成一定的升值压力，而回购销毁是和通胀相反的操作，我们可以简单将Stafi协议理解为一个国家，当国家增发货币少于GDP增速时，整体经济体是往上走的，相反，整个国家处于严重的通货膨胀。在Stafi中，我们也可以简化Stafi的增值模型： $$ FIS\_ {burn} >FIS \_{inflation}→Createvalue $$ $$ FIS\_{burn} \