Filecoin“幸运值”概念解读：如何优化让自己幸运加倍？

在各类浏览器上我们可以看到，节点的“幸运值”直接关系到这一周期内的爆块数量，幸运值越高节点的收益就越多。但是“幸运”之名让这一数值看起来就像是一种完全随机的概率指标，在很多Filecoin矿工朋友的心中都存有一个疑问，究竟有没有什么手段可以提升“幸运值”呢？

作为全网领先的Filecoin集群整体解决方案，我们对“幸运值”进行了为期不短的深入研究。接下来，就让小编我为大家揭开“幸运值”神秘的面纱，详细的介绍一下要如何操作才可以提升幸运值吧。

01 什么是幸运值

幸运值是矿工节点在一定周期内实际出块数量与该周期理论出块数量的比值。实际出块数量即节点在一定周期内，以其有效算力在Filecoin主网中获得的出块奖励。与其相对的理论出块数量则是指“周期内节点有效算力在全网算力中的占比”与“周期内全网出块奖励”的乘积。

依据目前全网情况举例，Filecoin全网在24小时内的出块数量为14400个，全网算力为3Eib.节点A的算力为ib，即全网算力的1/1000，那么他的理论奖励即为0.001*14400=14.4个块。以14.4为幸运值*的分界线，若A节点实际出块数量高于14.4，则我们称之为幸运值高（高于*）；反之，则称之为幸运值低（低于*）。

▇有效算力与实际出块奖励▇

矿工获取出块奖励需要经历3个环节

PART 1：每轮挖矿周期（epoch）开始后，矿工从主网其他节点接收上一轮的**区块消息广播。当到达一个特定的接收截止时间时，矿工在已经接收到的区块消息中，根据权重选择一个TipSet作为主链，然后基于该主链计算出块权。出块权的计算参数包括主链TipSet中的随机数，以及矿工当前的有效算力与全网有效算力的比重。从统计意义上说，矿工的有效算力与全网有效算力的占比越大，矿工获得出块权的概率就越大。

PART 2：如果矿工在主链上获得出块权，矿工就会进入WinningPoSt环节。系统会根据链上获取的抽查参数，去寻找需要抽取的扇区，以及扇区内某段随机的数据。

PART 3：抽取数据后，节点需要进行一次简单的运算，算出结果并把结果广播出去，该广播被主网认可后，即可获取出块奖励。

需要注意的是，WinningPoSt及计算环节中的任何一个步骤都不能出错，且需要在30秒之内完成。如果在进行任一步骤时出现机器故障，离线或运算错误等问题，或完成时间超过30秒，都会导致出块失败。

综合上述内容来看，矿工的实际出块数量决定于四个因素：

1、有效算力有效算力决定了矿工获得出块权的概率。从长期来看，节点获得的出块权占比趋近于其有效算力与全网有效算力的比重。

2、幸运值由于爆块权的获得依赖于主链的随机数，而随机数在较短的周期（比如24小时）内是有比较大的随机性的，因此，矿工在较短周期内幸运值明显高于或者低于*是正常的，不必担心。

3、存储和计算性能矿工获得爆块权后，需要在30s内完成存储抽查和证明计算，并且把区块广播给其他节点，才能成功爆块。如果未完成，矿工即便手握出块权也拿不到区块奖励。

4、网络延迟如果网络延迟比较大，那么在截止期到来时，矿工有可能还没接收到全部的主链区块消息，如果矿工基于不完整的主链进行爆块计算，那么也会被其他节点拒绝，导致爆块失败。另外一种情况是，矿工基于正确的主链并且成功完成了存储抽查和证明计算，但是由于网络延迟大，区块没有被即时广播到其他节点，导致爆块失败。

依然以上文中节点A为例子，依据全网算力占比，节点A24小时的出块权应为14.4次，但是某日其“运气”爆棚，因为“押中”随机数获得了28次爆块权，但是由于在其中15次WinningPoSt中机器出现异常，节点A最终仅获得了13个爆块，其幸运值最终也仅为13/14.4约90.28%。

02 如何提高幸运值

矿工的”运气”取决于其碰上随机数的次数，既然是“随机”，那么在一个较长的时间周期内，节点获得的出块权占比将无限趋近于有效算力在全网算力的占比，“运气”对幸运值的影响可以说是比较小的。所以为了确保相对较高的幸运值，提升WinningPoSt的成功率是唯一的手段。

因此，使用以下手段可以让集群顺利通过WinningPoSt，最终确保“一出块权一出块奖励”。

①良好的网络状态，顺畅的网络传输可以确保节点的计算结果第一时间被广播到Filecoin网络上，缩短出块奖励获取时间，同时还能维持节点与区块高度的同步，避免广播时出现异常。对于有条件的矿工，建议使用BGP(边界**协议)网络来搭设Filecoin集群。

②**的存储读写速度，获得出块权后，需要抽取扇区数据。因存储硬件或软件异常导致的读写不稳定及读取速度缓慢会使数据抽取失败，直接导致无法出块。

③强大的运算能力，WinningPoSt时间极短，而运算超时也将导致无法获得出块奖励，除了足够配置的硬件外，算法方面的优化也极其重要。可以针对WinningPoSt的计算进行了大量代码层面的优化，较大程度上缩减了整个计算的所需时间，这样从根本上杜绝了因为计算超时导致的出块奖励丢失。