【Filecoin源码仓库全解析】第四章：存储需求方（用户）的配置操作_IPFS星鉴网的专栏文章_微信文章

本章，我们将重点介绍存储需求方（用户）的配置操作，并反过来验证第三章中存储矿工后续挖取新块的过程，帮助大家融会贯通，并在工程上验证整个挖矿行为的生命周期。

4.1 存储需求方（用户）

我们在 3.2章节中，描述了Filecoin体系下的各个身份和角色，其中，存储客户（Storage clients）定位为想存储数据的需求方用户，也是Filecon所期望构建的双边市场中十分重要的一环，类比滴滴打车的乘车者。

Filecoin存储市场（上帝）将以公开透明的方式，搭建一个被记录在链上的订单池，供所有存储需求方（客户）选择和匹配存储提供方（矿工）。

4.2 导入数据资源并获取CID

在Filecoin存储网络之上，我们需要先将所存数据导入自身Filecoin节点客户端，并按照与IPFS很类似（应该是复用了）的处理流程进行了文件切片、散列处理和DAG建立，并生成子文件索引和内容ID（即：CID，在 2.2章详细介绍过）。

4.2.1 导入文本

echo "Hi my name is jialesoho"> jialesoho.txt

export CID=`go-filecoin client import ./jialesoho.txt`

# 反向验证是否成功导入
go-filecoin client cat $CID

4.2.2 导入图片

export CID=`go-filecoin client import ~/Desktop/your_test_img.jpg`

go-filecoin client cat $CID > image.png && open image.png

4.2.3 导入视频

export CID=`go-filecoin client import ~/Desktop/your_test_video.mp4`

4.3 查看Ask订单池

在 3.5章节中，我们模拟了矿工角色，并成功发送了ask订单至Filecoin存储市场之中，这里，我们再启动一台机器模拟用户节点，对全网的Ask订单池进行查询，并根据存储端（矿工）报价选择交易对象：

go-filecoin client list-asks --enc=json | jq

执行上述命令，遍历订单池后，会得到形如下方的json对象，解释一下每个字段意义：

{
  "Miner": "fcqllepeqmcq9qnjff3rqfaz02ks8dvmandx4sa2d",//矿工ID
  "Price": "2.5",//价格，单位FIL/byte/block
  "Expiry": 588,//多少区块高度后订单过期
  "ID": 0,//同一个矿工ID可能具备多个Ask订单，用ID区分
  "Error": null//
}

如果需要在终端中依赖矿工ID来进行 control+F 快速选定，建议直接键入 go-filecoin client list-asks

4.4 选订存储协议

当我们在Ask订单池上选定好 心仪的订单和矿工ID 后，便可通过如下指令签约了：

go-filecoin client propose-storage-deal

miner：心仪的矿工ID信息
data：4.2中所存数据的CID信息
ask：同一个矿工ID可能具备多个Ask订单，此数据在订单池中可查
duration：持续存储所经历的区块个数（平均30s一个新块产生，一天有效期大约需2880个新块）

注意：

因为是自己给自己灌数据，所以小编测试使用的是自己搭建的存储矿工节点，minerID：fcqllepeqmcq9qnjff3rqfaz02ks8dvmandx4sa2d，对应节点名称：jialesohoHK
小编资源有限，尽量保证这台机器（还是友商好心赞助的）能稳定在线，并将本节点所获取的所有Mock FIL收益用以长期创建Ask订单，便于大家可以直接接入测试，不需要再自己模拟一个存储端（矿工）机器了（经济下行，能帮大家省一些是一些）。

如下图所示，若选定存储协议成功，将直接更新订单状态为 accepted ，并返回 DealID 。

问题与勘误

如上图所示，大部分朋友可能会遇到：

Error: error creating payment: context deadline exceeded

这边小编复现了这个场景，并针对这个问题，和一些热心的读者交流（感谢詹总，东方风来、chinmusic），分析了一些可能造成的原因和解决方案，大家可以对号入座试试：

1）检查是否FIL金额足够

用户子弹不够...自然无法支付订单...，请检查余额，或者不要传太大的数据，注意单价是按照 byte (FIL/byte/block)来计算。

2）检查矿工节点状态

确保矿工节点在线，且是mining状态。

3）检查P2P连接状态

Filecoin体系中，节点网络与IPFS节点网络拓扑类似，每一个节点的邻居集群是有限的，通过彼此的邻居来间接建立联系是很常见的，因此，很有可能矿工节点和用户节点彼此并不直接相连，而 需要吐槽的是，在测试网阶段，官方建议我们在确保矿工节点在线的同时，也需要直接将两个节点相连接 。

我们可以通过minerAddrsID来搜索矿工节点ID，并通过节点ID搜索其网络地址multiAddrs，并直接建立P2P连接操作如下：

export peerID=`go-filecoin addresss lookup minerID`

export multiAddrs=`go-filecoin swarm findpeer $peerID`

go-filecoin swarm connect $multiAddrs

注意：

目前测试网的出块收益是直接划到worker矿工账户下的 ，而我们看到，通过刚才上方描述的p2p连接过程，是可以通过worker矿工的minerAddrsID层层索引到对方节点的IP地址，这 对于收益方是存在相当大的安全隐患。

这不，官方这段时间就做了如下调整， 未来，将出块收益直接划到owner账户下 ，账户ID并不用暴露在交易市场中，提高了账户的安全性。

5）确保所存单份数据大小小于扇区容量

如果是devnet-user，小于单个扇区所分配的256MB即可。

6）清空消息池

go-filecoin mpool ls | xargs -L1 go-filecoin mpool rm

具体缘由可追踪此 issue：https://github.com/filecoin-project/go-filecoin/issues/1965

4.5 发送数据并建立微支付通道

当我们使用 go-filecoin client propose-storage-deal 接受订单后，用户节点将与存储端矿工节点 建立微支付传输通道（防止单点故障，尽可能保证双方权益） ，即：传输百分之多少的piece数据，才支付对应百分之多少的FIL金额，这种微支付过程相当于把 一手交钱一手交货这件事又做到了极致，拆分得更细小了 ，一直到最终整个文件传输完成。我们可以来看一下微支付中每个细分Payments的接口实现：

type Payments interface {
    //建立每个pieceID所对应的微支付事务
    Setup(target Address, piece Cid, value TokenAmount) ID
    //生成链上支付凭证
    MakeVouchers(id ID, start, end BlockHeight, count int) []Voucher
    //异常后恢复支付凭证
    RedeemVoucher(v Voucher, proof Proof)
}

同时， 为了防止女巫攻击，Filecoin中节点与节点之间的数据传输，也会使用到IPFS中的bitswap模块（信用分系统）来过滤恶意节点和作弊节点 。

之后，存储端矿工节点会在一定时间间隔（可配置，默认为120秒）自动启动密封（seal）过程，即：获取之前微支付通道中暂存区域的所有数据，并将其密封到矿工的承诺存储区域中。此时，订单状态将转为 staged 。注意，此过生成PoRep和PoSt的生成，比较耗存储端矿工机器资源：

在密封完成并且矿工在链上生成凭证信息后，订单状态将移至 posted 。

我们可以通过 go-filecoin client query-storage-deal 来查询订单状态，也可以通过 go-filecoin client payments 来查询这笔订单的链上凭证信息：

如下图所示：

4.6 在仪表盘中回看存储端状态

登录Filecoin网络仪表盘：

http://user.kittyhawk.wtf:8010/

由于在第一章中，我们对存储端矿工节点设置了心跳链接，存储端矿工节点的数据信息会不间断地同步至Filecoin全网监控仪表盘上：

【Filecoin源码仓库全解析】第四章：存储需求方（用户）的配置操作

正文