LOADING...
LOADING...
LOADING...
当前位置: 玩币族首页 > 区块链资讯 > 64G扇区能否突破Filecoin封装Gas费过高的困境?

64G扇区能否突破Filecoin封装Gas费过高的困境?

2021-02-02 IPFS百晓生 来源:区块链网络

近期,市场上关于采用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消耗是有意义的,但矿工在选择扇区规格时,还是需要综合考虑包括上述因素在内的诸多影响。

—-

编译者/作者:IPFS百晓生

玩币族申明:玩币族作为开放的资讯翻译/分享平台,所提供的所有资讯仅代表作者个人观点,与玩币族平台立场无关,且不构成任何投资理财建议。文章版权归原作者所有。

LOADING...
LOADING...