歡迎大家來到第五章，經過前章 《【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) <-chan pstore.PeerInfo
}
5.6 命令列操作
目前V0版本的節點客戶端設計整合關於檢索市場協議的三個命令列功能操作（但是小編親測的客戶端Demo，在工程上實現與設計有一些出入），這三個功能分別是：
5.6.1 透過CID檢索資料內容
USAGE
filecoin retr get <piece-cid> - Retrieve a piece from a miner.
SYNOPSIS
filecoin retr get [--price=<amt>] [--miner=<peerID>] [--] <piece-cid>
ARGUMENTS
<piece-cid> - 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 <piece-cid> - Print a list of miners who have the given piece.
SYNOPSIS
filecoin retr lookup [--sort=<sorttype>] [--] <piece-cid>
ARGUMENTS
<piece-cid>... - Content ID of piece to find.
OPTIONS
--sort string - Output sorting scheme.
5.6.3 透過礦工ID查詢該檢索礦工的資訊
USAGE
filecoin retr query <minerID> [<piece-cid>] - Query the given retrieval miner.
SYNOPSIS
filecoin retr query [--] <miner-id> [<piece-cid>]
ARGUMENTS
<miner-id> - ID of miner to query.
[<piece-cid>] - Optional cid of piece to query for.
5.6.4 案例
我們試著檢索查詢一下，於 第四章4.2節 中所匯入併成功被儲存的文字資料 QmRxRSrZgFfRc...7s1o 來試試：
當儲存訂單的狀態變為posted時，就可以進行被儲存資料的檢索響應了，需要礦工worker地址和對應資料CID資訊：
go-filecoin retrieval-client retrieve-piece <minerAddress> <CID>
此過程有一定網路時延，查詢成功效果如下圖所示：
至此，無論從定位職能，還是從設計原理，還是從工程操作角度，我們應該對目前的Filecoin檢索市場都有了更加深入的瞭解。
我們將在下一章《【Filecoin原始碼倉庫全解析】第六章：如何組建多節點礦工叢集》中介紹如何在一臺機器上構建多節點的方案。
參考文獻：
https://github.com/filecoin-project/specs/blob/master/retrieval-market.md
https://github.com/filecoin-project/specs/blob/master/payments.md
往期系列文章回顧：
【Filecoin原始碼倉庫全解析】第一章：搭建Filecoin測試節點
【Filecoin原始碼倉庫全解析】第二章：如何建立賬戶錢包並獲取FIL Mock代幣
【Filecoin原始碼倉庫全解析】第三章（上）：儲存提供方（礦工）的配置操作
【Filecoin原始碼倉庫全解析】第三章（下）：儲存提供方（礦工）的配置操作
