欢迎大家来到第五章,经过前章
《【Filecoin源码仓库全解析】第四章:存储需求方(用户)的配置操作》的内容阅读后,我们应该对存储需求方(用户)的配置操作有了系统的了解,并在实践中反过来验证了第三章中所描述的存储矿工挖取新块的过程以及整个的生命周期。

我们将在这一章《【Filecoin源码仓库全解析】第五章:检索市场及检索矿工》中介绍与存储市场并驾齐驱而又息息相关的检索市场,以及Filecoin体系中另一重要角色:检索服务(矿工)的基本配置操作。

5.1 检索市场

小编认为,检索市场协议在当下的互联网环境中,是非常非常关键,且有潜力的,这也是Filecoin体系设计中的一大亮点。

为什么这么说?

太远的就不追溯了,一起来看下,这两天发生在我们身边,与我们(公司或者个人)息息相关的事件:

事件一:3月2日23点55分阿里云出现大规模宕机故障

这种事这几年好像越来越频繁了,作为一个感同身受的企业客户(以下称为甲方),想吼一句:

如果有一次让你重新上谈判桌的机会,你愿意吗?

你可能会在谈判桌上看到一份这样的不平等协议:

甲方重金购置XXX服务器或者XXX对象存储服务之前,先冻结乙方一部分的抵押金,并同时委托其他方为甲方生成多副本数据冷存。

检索数据时,乙方出事了,宕机超过阈值了,甲方可无条件没收抵押金,还有一堆丙丁戊方抢在乙方之前,第一时间立即为您恢复副本数据,并继续提供实时检索服务。(小编猜测,Filecoin未公布的Repair Miner角色设定正是为了平衡这块:你不干,别人抢着干,抵押金会分给最先帮助修复的朋友)

说到这里:

是不是比差遣研发运维兄弟来得省心?

是不是比事后看阿里云脸色来获得理赔更值得推崇?

是不是更能保障甲方的利益?

不知道你怎么想,真有这种好协议,反正我是签定了…

你说巨头们会不会改?

我觉得短时间内(也可能是十几年)、体制难改革…

毕竟这是道人性题,和技术无关…

阿里云做不到,

百度云也做不到,

亚马逊应该根本不Care…

但把人性和市场经济研究透了的Filecoin,或许真做得到…

事件二:感谢0xDUDE让我们知道中国普通民众的明文聊天记录

情理之中,有数据black产的利益驱动,有实力的hacker们都很难淡定。

而且,以现在网民的平均素质,关于自身数据有多值钱这件事,大部分是意识不到的…

身处于目前互联网体制下的巨头们都建立在”网络中间商”的基础上,中间商赚的不仅是差价,还有大量的用户数据。

毕竟大部分投资人都比你精明,你就不好奇,那些年的补贴大战,大家究竟烧钱是为了争夺什么?领完红包的你,究竟是得了便宜,还是被人套路?

我们真的能够相信,中间商有意愿,有能力善待网民的数据?

至少我不相信,大部分”被害人”不相信,协议实验室更不相信…

不仅不信,还设计了IPFS+Filecoin这套体系,毕竟”请把你的脏手从我的隐私数据上拿开”这件事总归还是有人带头做的,而且,还做得这么认真且彻底…

Filecoin的检索市场则是其中最重要的一环:帮助数据确权和去中间商交易。

5.1.1 定位

看完慷慨激昂的,我们来点内涵的:

正如Star Li在
《Filecoin逻辑梳理及源代码导读》06小节所描述的一样,Filecoin在协议层目前设计的模块有:Hello协议,Storage协议以及Retrieval协议。

(PS:小编通读完一遍,觉得很棒,作者同样花费了很多心血研究Filecoin源码和架构,并为大家梳理好了其中最为重要的一些关键点,值得大家仔细阅读。)

Retrieval协议用以规范检索市场,负责文件检索读取等交易事务,与负责区块同步的Hello协议和之前详细介绍的Storage市场协议并驾齐驱,分别发挥不同的专属职能(与存储市场协议不同,检索市场协议的实时并发响应要求更高,参与链上的事务会更少)。

5.1.2 职能

Filecoin体系下的检索市场(Retrieval Marketing Protocol)是未来真正意义实现Web3.0目标的一个产品雏形。

Web3.0我理解为:消灭网络中间商,建造可信互联网基础设施,让用户真正拥有数据自主权,保障用户身份安全以及数据交易。

5.2 实现程度

需要注意的是,协议实验室目前在这块的开发进度还处于比较早期,优先级并不如其他模块,仅支持检索订单的正常交易和数据响应,版本号也因此暂设为0。

为了搭建一个完善的检索市场,已经部分实现的依赖功能有:

链下支付通道的Actor扩展

基于libp2p的检索服务

链上内容寻址接口

节点客户端的相关命令行操作

下面将分别介绍每个子模块的细节:

5.3 链下支付通道的Actor扩展

Filecoin的交易市场将承载大量的实时交易,因此,订单撮合和支付渠道被设计为链下事务,同时在未来,除了使用FIL作为支付媒介,还将使用比特币、以太坊等其他跨链支付方案作为支持。下面是支付通道的相关源码结构:

//通道ID
type ChannelID *big.Int
//区块高度
type BlockHeight *big.Int
//签名
type Signature []byte
//支付收据
type SpendVoucher struct {
  Channel ChannelID
  Amount *TokenAmount
  Sig Signature
}

type PaymentBroker interface {
  //用以创建微支付通道
  CreateChannel(target Address, eol BlockHeight) ChannelID
  //用以更新微支付通道金额数量
  Update(channel ChannelID, amt *TokenAmount, sig Signature)
  //用以关闭微支付通道
  Close(channel ChannelID, amt *TokenAmount, sig Signature)
  //用以增加资金
  Extend(target Address, channel ChannelID, eol BlockHeight)
  //用以收回未使用的资金
  Reclaim(target Address, channel ChannelID)
}
// 生成收据信息
func MakeSpendVoucher(ch ChannelID, amt *TokenAmount, sk PrivateKey) *SpendVoucher {
  data := concatBytes(ch, amt)
  sig := sk.Sign(data)
  return &SpendVoucher{
    Channel: ch,
    Amount: amt,
    Sig: sig,
  }
}




5.4 基于libp2p的检索服务


第三章3.2节中,我们介绍了检索矿工(Retrieval miners)的角色和职能:比较像内容分发网络CDN的作用,负责“就近”检索和抓取数据,使得更快更好地把数据文件直接通过P2P链接,传输给需求方用户。

而在IPFS和Filecoin的体系下,不光大文件的传输,所有的协议通信基本都是通过P2P的方式。而这一切都被封装在libp2p模块之中,而libp2p的职责就是负责节点之前的网络发现,协议通信,数据传输和响应。

检索服务很大程度上也是依赖于libp2p的,在V0版本下的检索市场实现中,基于libp2p,新加了两个与业务强相关的服务功能:

1)基于libp2p的检索消息的响应特征

type RetDealProposal struct {
  //被检索数据的CID
  Ref Cid
  //支付金额
  Price TokenAmount
  //检索订单的支付通道
  Payment PaymentInfo
}
type ResponseStatus uint
const (
  Unset = ResponseStatus(iota)
  Accepted
  Rejected
  Error
)
type RetDealResponse struct {
  //响应体包括状态码和数据详细信息
  Status ResponseStatus
  Message string
}




2)基于libp2p的检索矿工报价查询响应特征

type RetQuery struct {
  //按数据CID信息进行查询请求
  Piece Cid
}
type RetQueryResponse struct {
  //响应体包括状态码和最低报价
  Status RetQueryStatus
  MinPrice TokenAmount
}
type RetQueryStatus uint
const (
  Unset = RetQueryStatus(iota)
  OK
  PieceUnavailable
)




5.5 链上内容寻址

内容寻址是延用了IPFS协议的设计思想,即我只关心我所要检索的内容,并不关心底层路由系统和网络链接,系统默认会以最优的线路和速度帮我获取。与现有HTTP路径寻址的方式呈现根本的不同,更具创新性。

Filecoin的检索市场也是使用内容寻址,并且会根据区块链上记录的信息来匹配对应存储了该内容的矿工ID集合(保证数据确权),然后解析成peerID和multiaddress,交给底层libp2p来负责网络路由和建立传输链接。接口定义如下:

type ChainContentRouting interface {
  FindProvidersAsync(ref Cid, count int)



5.6 命令行操作

目前V0版本的节点客户端设计集成关于检索市场协议的三个命令行功能操作(但是小编亲测的客户端Demo,在工程上实现与设计有一些出入),这三个功能分别是:

5.6.1 通过CID检索数据内容


USAGE
filecoin retr get  – Retrieve a piece from a miner.
SYNOPSIS
filecoin retr get [–price=] [–miner=] [–]
ARGUMENTS
  – Content ID of piece to retrieve.
OPTIONS
–price        string – Amount of filecoin to offer for this data.
–miner        string – Optional Peer ID of miner to connect to. (If unspecified, the chain routing service will be used)



5.6.2 根据CID查看被检索数据的所有检索报价


USAGE
filecoin retr lookup  – Print a list of miners who have the given piece.
SYNOPSIS
filecoin retr lookup [–sort=] [–]
ARGUMENTS
… – Content ID of piece to find.
OPTIONS
–sort        string – Output sorting scheme.



5.6.3 通过矿工ID查询该检索矿工的信息


USAGE
filecoin retr query  [] – Query the given retrieval miner.
SYNOPSIS
filecoin retr query [–]  []
ARGUMENTS
  – ID of miner to query.
[] – Optional cid of piece to query for.



5.6.4 案例

我们试着检索查询一下,于
第四章4.2节中所导入并成功被存储的文本数据QmRxRSrZgFfRc…7s1o来试试:

当存储订单的状态变为posted时,就可以进行被存储数据的检索响应了,需要矿工worker地址和对应数据CID信息:

go-filecoin retrieval-client retrieve-piece   


此过程有一定网络时延,查询成功效果如下图所示:

至此,无论从定位职能,还是从设计原理,还是从工程操作角度,我们应该对目前的Filecoin检索市场都有了更加深入的了解。

我们将在下一章《【Filecoin源码仓库全解析】第六章:如何组建多节点矿工集群》中介绍如何在一台机器上构建多节点的方案。


参考文献:


https://github.com/filecoin-project/specs/blob/master/retrieval-market.md

https://github.com/filecoin-project/specs/blob/master/payments.md