近期，市場上關(guān)于采用64G扇區(qū)進(jìn)行Filecoin挖礦的消息層出不窮，很多人都在關(guān)注這個(gè)方案對礦工的影響，而許多公司也都公布了自己的測試數(shù)據(jù)。那么“64G扇區(qū)”對于Filecoin市場究竟意味著什么？能否解決gas費(fèi)過高的困境？

本文將從64G扇區(qū)方案對密封gas費(fèi)、挖礦硬件和挖礦軟件三部分的影響進(jìn)行系統(tǒng)分析，和大家聊一聊關(guān)于64扇區(qū)封裝解決方案的那些事兒。

一、64G扇區(qū)對密封gas費(fèi)的影響

大家對64G扇區(qū)的熱情，主要來源于其減少gas消耗的效果，這和Filecoin進(jìn)行數(shù)據(jù)密封的過程有關(guān)。

密封一個(gè)扇區(qū)的過程需要經(jīng)歷從AddPiece到Proving的6個(gè)步驟，其中有PreCommitSector和ProveCommitSector兩條消息需要上鏈。如果采用32G扇區(qū)，想要獲取1T算力需要32個(gè)扇區(qū)，一共是64條消息上鏈；而如果采用了64G扇區(qū)，獲得1T算力僅需32條消息上鏈。

總結(jié)一下就如下表所示：

那么，是不是說密封同等算力的情況下，64G扇區(qū)會比32G扇區(qū)的gas費(fèi)剛好低50%呢？如果細(xì)究起來的話并非如此簡單，因?yàn)檫€存在一些其他影響因素。

在Filecoin中，每條消息上鏈所需要消耗的gas是由該消息的gas used參數(shù)決定的，而一條消息的gas used是由執(zhí)行該消息的計(jì)算量所決定的，這一點(diǎn)與Ethereum類似。所以在下表所示的24小時(shí)消息gas統(tǒng)計(jì)中，大家會看到不同類型消息的gas used存在巨大差異。

所以，和32G扇區(qū)相比，64G扇區(qū)能否降低gas？能降低多少？還需要具體分析，關(guān)鍵是看消息的gas?used的對比。

就PreCommitSector消息而言，主要是將扇區(qū)信息注冊到狀態(tài)樹中，無論32G扇區(qū)還是64G扇區(qū)，涉及的參數(shù)都是RegisteredProof等10個(gè)參數(shù)，所耗費(fèi)的虛擬機(jī)計(jì)算資源基本相同，因此單個(gè)扇區(qū)的gas used不會有太大差別。但單個(gè)64G扇區(qū)帶來的算力是32G的2倍，因此對于密封同樣算力的PreCommitSector消息gas費(fèi)，64G扇區(qū)將是32G扇區(qū)的50%左右。

而對于ProveCommitSector消息，是對PreCommit階段的工作結(jié)果進(jìn)行檢驗(yàn)，檢驗(yàn)方式是抽取一定的數(shù)據(jù)點(diǎn)，由全網(wǎng)礦工通過計(jì)算進(jìn)行結(jié)果確認(rèn)。其中，32G扇區(qū)和64G扇區(qū)抽取的數(shù)據(jù)檢查點(diǎn)數(shù)量是一樣都是10個(gè)，所以兩種扇區(qū)的ProveCommitSector消息執(zhí)行所消耗的虛擬機(jī)計(jì)算資源基本相同，gas used基本相同。換而言之，想要密封同樣算力，64G扇區(qū)的ProveCommitSector消息的gas費(fèi)是32G扇區(qū)的50%左右。

所以，總體上來看，密封64G的確可以降低gas支出。當(dāng)然，除了以上討論的要點(diǎn)外，還有其他一些因素同樣會對gas消耗產(chǎn)生一定的影響，例如，當(dāng)實(shí)時(shí)算力及上鏈消息數(shù)量有差異時(shí)，執(zhí)行消息時(shí)對bitfield的操作同樣會對gas產(chǎn)生影響。

那么，是不是可以據(jù)此判斷應(yīng)該選用64G扇區(qū)呢？關(guān)于這個(gè)問題，還需要考慮選用64G扇區(qū)對挖礦資源會有哪些影響。

?

二、64G扇區(qū)對挖礦硬件的影響

64G扇區(qū)比32G扇區(qū)的大小增大了1倍，但所需的挖礦資源與扇區(qū)大小卻不是全是簡單的線性關(guān)系。

1、在PreCommit?phase 1階段：

根據(jù)此處使用的Stacked DRG PoRep算法的參數(shù)設(shè)計(jì)，需要對扇區(qū)數(shù)據(jù)進(jìn)行11層哈希計(jì)算，32G扇區(qū)每層有1G個(gè)數(shù)據(jù)節(jié)點(diǎn)，64G扇區(qū)每層有2G個(gè)數(shù)據(jù)節(jié)點(diǎn)，每一層計(jì)算都需要依賴到上一層的數(shù)據(jù)。因此，該階段的64G扇區(qū)計(jì)算量會是32G扇區(qū)的兩倍，這是CPU的計(jì)算負(fù)擔(dān)，并且由于SDR算法的特性，整體的計(jì)算過程無法并發(fā)完成，因此同等頻率下的一個(gè)64G扇區(qū)計(jì)算時(shí)間將是一個(gè)32G的2倍。但由于64G扇區(qū)帶來的算力同樣是32G扇區(qū)的2倍，因此在此階段密封單位算力的CPU資源消耗依然是不變的。

另一方面，在完成此階段的計(jì)算時(shí)，內(nèi)存需要同時(shí)存下完整的2層數(shù)據(jù)，即完成一個(gè)扇區(qū)需要占用128G內(nèi)存，這個(gè)大小的內(nèi)存剛好可以容納2個(gè)32G扇區(qū)同時(shí)進(jìn)行計(jì)算，僅僅這么看似乎64G扇區(qū)所需消耗的內(nèi)存資源也是不變的。但如果結(jié)合資源占用時(shí)間的因素一起考慮，則使用128G內(nèi)存完成一份64G扇區(qū)PC1的時(shí)間足夠同樣大小的內(nèi)存完成2輪32G扇區(qū)的PC1工作，每輪有2個(gè)扇區(qū)同時(shí)計(jì)算，因此32G扇區(qū)的算力增速會是64G扇區(qū)的2倍。

2、在PreCommit?phase 2階段：

此階段需要先完成11層數(shù)據(jù)Column Hash計(jì)算，然后每0.125G個(gè)節(jié)點(diǎn)會按八叉樹的結(jié)構(gòu)形成層哈希樹。由于每一列都是11個(gè)數(shù)據(jù)節(jié)點(diǎn)，因此在計(jì)算Column Hash時(shí)，64G扇區(qū)的列數(shù)是32G扇區(qū)的2倍，最終結(jié)果的節(jié)點(diǎn)數(shù)也是2倍。而32G扇區(qū)的哈希樹是8棵，64G扇區(qū)的是16棵。因此本階段64G扇區(qū)的計(jì)算量會是32G扇區(qū)的2倍。

3、在Commit?phase 2階段：

為了對數(shù)據(jù)密封結(jié)果進(jìn)行驗(yàn)證，在C2階段需要隨機(jī)抽取數(shù)據(jù)點(diǎn)，并以信任設(shè)置階段的電路進(jìn)行計(jì)算。在目前的Filecoin共識機(jī)制下，無論是何種扇區(qū)規(guī)格，本階段所采用的電路都是相同的，因此所抽取的數(shù)據(jù)點(diǎn)都是10個(gè)，因此32G扇區(qū)和64G扇區(qū)在C2階段所消耗的計(jì)算資源是相同的。

小結(jié)：用原先適合于密封32G扇區(qū)的機(jī)器來密封64G扇區(qū)，若不更改配置，則單位時(shí)間密封的算力將下降50%；而P1階段的內(nèi)存增加一倍就可以使算力增速達(dá)到原先32G扇區(qū)的水平。

?

三、64G扇區(qū)對挖礦軟件的影響

很長一段時(shí)間以來，各家礦商對于Filecoin挖礦軟件部分的功夫主要下在2個(gè)方面：

? ? 任務(wù)調(diào)度；

? ? 算法優(yōu)化。

對于64G扇區(qū)而言，在硬件資源匹配恰當(dāng)?shù)那闆r下，還需考慮其他一系列軟件上的影響因素，而其中的任務(wù)調(diào)度就是一個(gè)看似簡單、實(shí)則頗有關(guān)聯(lián)的模塊。

例如，在Filecoin扇區(qū)密封的過程中，需要從鏈上獲取Ticket，但每個(gè)Ticket都有時(shí)效性，如果完成相關(guān)任務(wù)的時(shí)候Ticket已經(jīng)失效了，那么就需要重做該環(huán)節(jié)的任務(wù)。64G扇區(qū)的諸多環(huán)節(jié)耗時(shí)都遠(yuǎn)長于32G扇區(qū)，因此需要對任務(wù)銜接進(jìn)行更為精細(xì)的控制。如果使用的是官方代碼中的調(diào)度模塊，就非常容易遇到這個(gè)問題，導(dǎo)致部分扇區(qū)密封工作成果失效。

以上就是要和大家分享的關(guān)于64G扇區(qū)方案的一些觀點(diǎn)。提示：從長期來看，64G扇區(qū)的方案對于降低密封過程的gas消耗是有意義的，但礦工在選擇扇區(qū)規(guī)格時(shí)，還是需要綜合考慮包括上述因素在內(nèi)的諸多影響。