【Filecoin源码仓库全解析】第三章（下）：存储提供方（矿工）的配置操做

很差意思，这篇加了点八卦：

原本是不太想说这事的，从18年看到如今，很多见圈里的朋友和友商互相吐槽乃至攻击...最近还闹得比较大。这里说两句：区块链存储在中国是一个刚诞生的新兴领域，探索阶段有错误是常态，至少你们都愿意把脸放下地在盘活这个行业。

今天小编看到一句很深入的话：强者互持，弱者互撕，但愿你们能意识到：由于同行者，你的存在和你所作的事情才有意义...

欢迎你们来到第三章的下篇，通过前章 【Filecoin源码仓库全解析】第三章（上）：存储提供方（矿工）的配置操做的内容阅读后，咱们应该能会对Filecoin存储市场机制和市场中的各角色职能有了更深入的认知，而且能够配置自身节点角色，成为存储提供方（矿工），参与挖矿了。

上一篇，咱们讲解了如何在工程上申请存储矿工角色，本篇，咱们将深度剖析存储矿工对象的源码结构，方便你们从根本上理解矿工的事务，并对一次挖矿的生命周期作一个总结。

3.6 存储矿工对象剖析

首先，咱们来深度剖析一个存储矿工对象的源码结构，这样便于你们从根本上理解矿工的事务。

3.6.1 StorageMinerActor

咱们在链上成功注册一个新的矿工身份后，Filecoin存储市场Actor（上帝）将调用CreateMiner()方法为咱们生成一个新的存储矿工实例对象（StorageMinerActor），并返回其地址，这个新的实例对象结构以下：

type StorageMinerActor interface {
    //矿工向存储市场发送订单的方法。
    AddAsk(price TokenAmount, expiry uint64) AskID
    //提交扇区的方法。
    CommitSector(commD, commR, commRStar []byte, proof SealProof) SectorID
    //用于向链上提交时空证实的方法，证实矿工已实际存储了其声称的文件。
    SubmitPoSt(p PoSt, faults []FailureSet, recovered SectorSet, doneSet SectorSet)
    // 容许矿工为网络提供更多存储空间的方法
    IncreasePledge(addspace Integer)
    // 若缺少复制证实证据，将用此方法惩罚矿工
    SlashStorageFault()

复制代码

3.6.2 StorageMinerState

存储矿工会有本身的链上状态，仅在建立新区块时更新，并全网同步可追溯，能够理解为这是Filecoin网络为矿工们所维护的一组状态帐本：

type StorageMinerState struct {
    //Owner 是拥有此矿工节点的帐户地址
    Owner Address
    
    //Worker 是此矿工节点的工做帐号地址
    Worker Address
    
    //PeerID 是应该用于链接这个矿工节点的libp2p对等身份
    PeerID peer.ID
    
    //PublicKey是矿工用于对区块进行签名的密钥的公共部分
    PublicKey PublicKey
    
    //PledgeBytes是此矿工提供给网络的空间量
    PledgeBytes BytesAmount
    
    //被锁定的抵押金额
    Collateral TokenAmount
    
    //当前抵押金额
    ActiveCollateral TokenAmount
    
    //未提取的抵押金额
    DePledgedCollateral TokenAmount
    
    //提取抵押币的时间
    DePledgeTime BlockHeight
    
    //Sectors 扇区集合
    Sectors SectorSet
    
    //提交PoSt证实的扇区
    ProvingSet SectorSet
    
    //在上一次PoSt提交期间状态变动为“完成”的一组扇区。
    NextDoneSet SectorSet
    
    //矿工所拥有的算力算量
    Power BytesAmount
}

复制代码

3.6.3 Owner与Worker

存储矿工角色有两个不一样的地址:

• 一个是Worker：负责完成全部事务活动，参与Ask订单、提交证实，提交新扇区等。
• 另外一个是Owner：地址是建立矿工的地址，支付抵押品，并得到出块奖励。

小编认为须要这样区别和设计的缘由归结为八个字：各司其职，安全第一。

例如：Owner适合冷存密钥，安全级别更高，Worker常迁移和变动，安全级别更低。

以下图所示，咱们能够在~./filecoin/config.json下分别获取到worker和Owner的地址数据：

• Worker => minerAddress
• Owner => defaultAddress

注意：查询Ask订单，选择交易时必定注意用worker地址来检索

3.7 存储矿工的生命周期

画了一个脑海中的草图，方便你们理解和记忆：

如图所示，存储矿工的生命线主要有四条：

• 存储交易
• 建立区块
• 中止挖矿
• 失责惩罚（WIP）

下面依次来介绍其生命周期中的这几个过程：

3.7.1 存储交易

Step1：操做节点参与链上身份注册，提交抵押与存储容量，成为一个存储矿工

Step2：建立Ask订单，与用户节点交易。

Step3：密封数据并提交复制证实（PoRep）于链上，更新订单状态，完成交易，并开启PoSt证实周期（证实期是矿工必须向网络提交空间时间证实的固定时间。）

备注：这块内容能够继续深挖，后面有时间考虑单开一章节：与FilecoinProof相关

Step4：存储矿工收集证实集合，建立PoSt，计算ProveStorage和StoragePower（算力）。

备注：在证实期内，证实集会始终保持一致。在此期间系统增长的任何扇区都将顺延至下一个证实期内。

Step5：当矿工完成他们的PoSt时，调用SubmitPoSt将其提交给网络，并伴随区块更新同步状态。

3.7.2 建立区块

当经历完存储交易的过程后，存储矿工已经具有了参与建立区块节点的竞选了，选票的生成逻辑以下所示：

//这块函数体内部逻辑官方提示将改动，就不一一解析了

func IsTicketAWinner(t Ticket, minersPower, totalPower Integer) bool {
    return ToFloat(sha256.Sum(ticket)) * totalPower < minersPower
}

pTipSet := getHeaviestTipSet()

smallestTicket := selectSmallestTicket(pTipSet)

var tickets []Signature
baseTicket := smallestTicket
for {
   
    challenge := sha256.Sum(baseTicket.Bytes())

    postCount := estimator.GetPostCount(chain, pTipSet)

    proof := post.Prove(storage, challenge, postCount)

    ticket := minerPrivKey.Sign(sha256.Sum(proof.Bytes()))
    tickets = append(tickets, ticket)

    totalPower := getTotalPower(pTipSet)
    ourPower := getMinerPower(pTipSet, minerID)

    if IsTicketAWinner(ticket, ourPower, totalPower) {

        return tickets
    } else {

        baseTicket = ticket
    }
}
复制代码

同时，为了防止女巫攻击，选票须要被其余节点验证，同时，自身也将验证其余节点的选票：

//这块函数体内部逻辑官方提示将改动，就不一一解析了
func VerifyTicket(b Block) error {

    curTicket := selectSmallestTicket(b.Parents)

    for _, ticket := range b.Tickets {
        challenge := sha256.Sum(curTicket)
        if !VerifyProof(b.Proof, b.Miner, challenge) {
            return "Proof failed to validate"
        }
        pubk := getPublicKeyForMiner(b.Miner)
        if !pubk.VerifySignature(ticket, sha256.Sum(b.Proof.Bytes())) {
            return "Ticket was not a valid signature over the proof"
        }
        curTicket = ticket

    }
    state := getStateTree(b.Parents)
    minersPower := state.getPowerForMiner(b.Miner)
    totalPower := state.getTotalPower()
    if !IsTicketAWinner(curTicket, minersPower, totalPower) {
       return "Ticket was not a winning ticket"
    }
    return nil
}
复制代码

建立区块以前，首先要赢得选票，令全部对等节点之间达成一致。这里涉及到预期（Expected Consensus）共识，简而言之：

是Filecoin基于拜占庭容错基础上的改进版，策略是每一轮里选举出来一名或者多名存储矿工来建立新的区块，赢选票的可能性和矿工已分配的存储（即与上文中ProveStorage、StoragePower强相关） 成比例。

备注：这块内容也能够继续深挖，后面有时间考虑单开一章节：与Expected Consensus相关

当你侥幸得到一张优胜选票时，将建立新块，结构体以下所示：

//这块函数体内部逻辑官方提示TODO，应该后期改动会比较大

type Block struct {

    Parents []*cid.Cid

    Tickets []Signature

    Proof post.Proof

    Ticket Signature

    MsgRoot *cid.Cid

    ReceiptsRoot *cid.Cid

    StateRoot *cid.Cid

    BlockSig Signature
}

复制代码

当完成区块建立以后，随之而来的是丰厚的上帝奖励（FIL分发），具体的分发策略也处于WIP状态，目前测试网阶段是1000FIL/Block。

3.7.3 中止挖矿

若是须要中止采矿，矿工必须履行完全部存储订单（即：名下全部Ask订单状态为Poster），并在PoSt提交期间将其从证实集中删除。

以后，可经过客户端指令调用DePledge()来取回他们的抵押品，并中止挖矿进程。

备注：此过程也会参与链上操做。

3.7.4 失责惩罚（WIP）

若是矿工因未能按时提交PoSt而被slashed，他们将失去全部抵押品。

备注：官方仍在Work in Process之中，须要更多社区的建议和讨论，目前设置了多种保险和从新验证机制，可见Filecoin也很是重视矿工的利益。

参考文献：

• github.com/filecoin-pr…

• github.com/filecoin-pr…

---

本章是一个基础铺垫，深挖了底层的原理，这是为了让咱们对Filecoin系统的理解，不光只停留在工程指令集的操做上面。

咱们将在下一章《【Filecoin源码仓库全解析】第四章（下）：存储需求方的配置操做》中重点介绍存储需求方（用户）的配置操做，并反过来验证第三章中存储矿工后续挖取新块的过程，帮助你们融会贯通，并在工程上验证整个挖矿行为的生命周期。

联系做者：

本人从业经验有限，难免有不足之处，欢迎指正和更多讨论，可私信微信公众号：jialesoho，或者加我微信：daijiale6239，若是以为对您有帮助，能够帮点击好看推广和打赏支持噢，感激涕零！

（识别图中二维码，关注嘉乐SOHO微信公众号）