能否突破Filecoin封装Gas费过高的困境？

近期，市场上关于采用64G扇区进行Filecoin挖矿的消息层出不穷，很多人都在关注这个方案对矿工的影响，而许多公司也都公布了自己的测试数据。那么“64G扇区”对于Filecoin市场究竟意味着什么？能否解决gas费过高的困境？

本文将从64G扇区方案对密封gas费、挖矿硬件和挖矿软件三部分的影响进行系统分析，和大家聊一聊关于64扇区封装解决方案的那些事儿。

一、64G扇区对密封gas费的影响

大家对64G扇区的热情，主要来源于其减少gas消耗的效果，这和Filecoin进行数据密封的过程有关。

密封一个扇区的过程需要经历从AddPiece到Proving的6个步骤，其中有PreCommitSector和ProveCommitSector两条消息需要上链。如果采用32G扇区，想要获取1T算力需要32个扇区，一共是64条消息上链；而如果采用了64G扇区，获得1T算力仅需32条消息上链。

总结一下就如下表所示：

那么，是不是说密封同等算力的情况下，64G扇区会比32G扇区的gas费刚好低50%呢？如果细究起来的话并非如此简单，因为还存在一些其他影响因素。

在Filecoin中，每条消息上链所需要消耗的gas是由该消息的gas used参数决定的，而一条消息的gas used是由执行该消息的计算量所决定的，这一点与Ethereum类似。所以在下表所示的24小时消息gas统计中，大家会看到不同类型消息的gas used存在巨大差异。

所以，和32G扇区相比，64G扇区能否降低gas？能降低多少？还需要具体分析，关键是看消息的gas used的对比。

就PreCommitSector消息而言，主要是将扇区信息注册到状态树中，无论32G扇区还是64G扇区，涉及的参数都是RegisteredProof等10个参数，所耗费的虚拟机计算资源基本相同，因此单个扇区的gas used不会有太大差别。但单个64G扇区带来的算力是32G的2倍，因此对于密封同样算力的PreCommitSector消息gas费，64G扇区将是32G扇区的50%左右。

而对于ProveCommitSector消息，是对PreCommit阶段的工作结果进行检验，检验方式是抽取一定的数据点，由全网矿工通过计算进行结果确认。其中，32G扇区和64G扇区抽取的数据检查点数量是一样都是10个，所以两种扇区的ProveCommitSector消息执行所消耗的虚拟机计算资源基本相同，gas used基本相同。换而言之，想要密封同样算力，64G扇区的ProveCommitSector消息的gas费是32G扇区的50%左右。

所以，总体上来看，密封64G的确可以降低gas支出。当然，除了以上讨论的要点外，还有其他一些因素同样会对gas消耗产生一定的影响，例如，当实时算力及上链消息数量有差异时，执行消息时对bitfield的操作同样会对gas产生影响。

那么，是不是可以据此判断应该选用64G扇区呢？关于这个问题，还需要考虑选用64G扇区对挖矿资源会有哪些影响。

二、64G扇区对挖矿硬件的影响

64G扇区比32G扇区的大小增大了1倍，但所需的挖矿资源与扇区大小却不是全是简单的线性关系。

1、在PreCommit phase 1阶段：

根据此处使用的Stacked DRG PoRep算法的参数设计，需要对扇区数据进行11层哈希计算，32G扇区每层有1G个数据节点，64G扇区每层有2G个数据节点，每一层计算都需要依赖到上一层的数据。因此，该阶段的64G扇区计算量会是32G扇区的两倍，这是CPU的计算负担，并且由于SDR算法的特性，整体的计算过程无法并发完成，因此同等频率下的一个64G扇区计算时间将是一个32G的2倍。但由于64G扇区带来的算力同样是32G扇区的2倍，因此在此阶段密封单位算力的CPU资源消耗依然是不变的。

另一方面，在完成此阶段的计算时，内存需要同时存下完整的2层数据，即完成一个扇区需要占用128G内存，这个大小的内存刚好可以容纳2个32G扇区同时进行计算，仅仅这么看似乎64G扇区所需消耗的内存资源也是不变的。但如果结合资源占用时间的因素一起考虑，则使用128G内存完成一份64G扇区PC1的时间足够同样大小的内存完成2轮32G扇区的PC1工作，每轮有2个扇区同时计算，因此32G扇区的算力增速会是64G扇区的2倍。

2、在PreCommit phase 2阶段：

此阶段需要先完成11层数据Column Hash计算，然后每0.125G个节点会按八叉树的结构形成层哈希树。由于每一列都是11个数据节点，因此在计算Column Hash时，64G扇区的列数是32G扇区的2倍，最终结果的节点数也是2倍。而32G扇区的哈希树是8棵，64G扇区的是16棵。因此本阶段64G扇区的计算量会是32G扇区的2倍。

3、在Commit phase 2阶段：

为了对数据密封结果进行验证，在C2阶段需要随机抽取数据点，并以信任设置阶段的电路进行计算。在目前的Filecoin共识机制下，无论是何种扇区规格，本阶段所采用的电路都是相同的，因此所抽取的数据点都是10个，因此32G扇区和64G扇区在C2阶段所消耗的计算资源是相同的。

小结：用原先适合于密封32G扇区的机器来密封64G扇区，若不更改配置，则单位时间密封的算力将下降50%；而P1阶段的内存增加一倍就可以使算力增速达到原先32G扇区的水平。

三、64G扇区对挖矿软件的影响

很长一段时间以来，各家矿商对于Filecoin挖矿软件部分的功夫主要下在2个方面：

• 任务调度；
• 算法优化。

对于64G扇区而言，在硬件资源匹配恰当的情况下，还需考虑其他一系列软件上的影响因素，而其中的任务调度就是一个看似简单、实则颇有关联的模块。

例如，在Filecoin扇区密封的过程中，需要从链上获取Ticket，但每个Ticket都有时效性，如果完成相关任务的时候Ticket已经失效了，那么就需要重做该环节的任务。64G扇区的诸多环节耗时都远长于32G扇区，因此需要对任务衔接进行更为精细的控制。如果使用的是官方代码中的调度模块，就非常容易遇到这个问题，导致部分扇区密封工作成果失效。

以上就是要和大家分享的关于64G扇区方案的一些观点。提示：从长期来看，64G扇区的方案对于降低密封过程的gas消耗是有意义的，但矿工在选择扇区规格时，还是需要综合考虑包括上述因素在内的诸多影响。

作者：柠萌；来自链得得内容开放平台“得得号”，本文仅代表作者观点，不代表链得得官方立场凡“得得号”文章，原创性和内容的真实性由投稿人保证，如果稿件因抄袭、作假等行为导致的法律后果，由投稿人本人负责得得号平台发布文章，如有侵权、违规及其他不当言论内容，请广大读者监督，一经证实，平台会立即下线。如遇文章内容问题，请发送至邮箱：linggeqi@chaindd.com