激励在区块链上完成，分为epoch和slot两类周期。每个阶段中，激励合约和重节点需要配合完成不同工作：
- GEN：
- 激励合约生成存储挑战随机数并发布在链上；
- 重节点收到该存储挑战随机数后，将本地保存的文件片生成存储证明（一棵merkle树），并将树根提交到激励合约，提交树根后才能参与奖励。如果重节点存储的文件片很多，来不及在第一个slot的GEN内生成包含所有文件片的存储证明，可以先提交包含一部分存储文件片的存储证明根，后续在该epoch内任意slot的UPDATE阶段更新存储证明根，存储证明中包含的文件片越多，获得激励的几率越高。不同epoch间的存储挑战随机数不同，因此每个epoch内，重节点都需要重新生成存储证明并提交到激励合约。
- COLLECT：
- 激励合约生成并发布开奖随机数，开奖随机数为256bit，与CID中文件hash部分长度相同。
- 官方可信重节点将根据开奖随机数和当前网络中的有效文件片检索出最佳CID，发布到链上。
- 重节点收到最佳CID值时，检索当前存储证明树中是否存在该CID，如果存在，则向激励合约报告。请注意重节点需在COLLECT阶段提交该CID，如果超时未提交，则该重节点可能会丧失本次奖励机会。
- 激励合约收到不同重节报告后，计算其权重并保存。
- ANNOUNCE：
- 激励合约按圈中抽取获奖者
- 获奖重节点向激励合约发送SV证明，来证明本地确实有保存该文件片源文件。
- UPDATE：
- 激励合约验证SV证明，实施奖励或惩罚。激励合约会将获奖者记录在链上，并允许其提款。
- 如果获奖重节点没有提供有效SV证明，或提交的SV证明无效，则说明该重节点作弊或离线。此时需对其惩罚，惩罚方案是不允许其参加本epoch和下个epoch的激励。如果某重节点多次被惩罚，则说明其有作恶行为或网络能力不足，监管委员会会发起将其驱逐出重节点网络的投票。
3.1.3.4 存储证明
提供存储证明的目的有两个：
- 存在性证明，就是证明IPFS节点确实在本地保存了文件片，而不是只存储了CID，也不是在被检查到的时候才从IPFS网络中临时拉取文件片；
- 有效性证明，就是证明中奖文件片是存储在IPFS网络上的有效文件片（有真实的用户），而不是随机生成的无效文件片。
这两个目的分别用存在性证明和有效性证明的SV证明实现，在ANNOUNCE阶段被提交到激励合约中并验证。
(1) 存在性证明
proofLeaf是存储证明树的叶子节点，使用节点pidHash，由存储证明随机数和文件块的rowdata生成。因此IPFS节点必须本地有存储文件片内容才能生成，只存储CID是生成不了的。而且也不能拷贝其他节点的证明。对于多个节点共享存储池的方案，只能提高其成本，无法避免。其中存储证明随机数即GEN阶段公布的storeChallenge，该随机数在一个epoch中是不变的，而在各个epoch间是不同的。如下为proofLeaf的计算方法，其中Hash()函数采用sha256。
每个本地存储的文件片都会生成proofLeaf，所有proofLeaf组成merkle树即为存储证明树，树根即为存在性证明。下图为存储证明树的结构：
SPV证明（Simplified Payment Verification）源自比特币，SV（Simplified Verification ）借鉴了其方法，旨在使用较短的数据量来证明某个CID对应的proofLeaf确实存在于存储证明中。存在性证明的SV证明包含proofLeaf和其存储证明根的SPV证明。该SV证明在ANNOUNCE阶段被生成，并提交到激励合约验证。需要分别验证proofLeaf和SPV证明的有效性。其中SPV证明的验证不再赘述。主要描述对proofLeaf的验证。proofLeaf是pid和Hash(storeChallenge+rowdata)两部分合起来的hash，pid可以从重节点账户获取。storeChallenge是激励合约中发出的，可以方便获取。困难的是rowdata的获取，海峡链有部署官方可信的IPFS节点，这些节点是公开的、固定的。
