概述

IPFS - InterPlanetary File System 星際文件系統，是一個點對點的分布式文件存儲系統，IPFS的愿景是構建一個全世界的分布式網絡，用來替代傳統中心化的服務器模式，所有的IPFS節點組成一個分布式網絡，每個節點都可以存儲文件，用戶可以從IPFS構建的網絡中以DHT（Distributed Hash Table，分布式哈希表） 的方式獲取文件，從而實現了新一代的完全去中心化的網絡，旨在取代現有的萬維網。IPFS功能很豐富，包括DHT組網，文件存儲，Bitswap文件交換等功能。本文主要介紹IPFS的文件存儲原理，文件上傳到IPFS節點存儲時，節點會將文件分塊后進行存儲，每個文件以Merkle DAG（默克爾有向無環圖）的格式組織，而Merkle DAG的根哈希則用來表示該文件。本文將對IPFS存儲進行詳解，所述的IPFS的版本為v0.6.0。

CID

在介紹IPFS存儲文件的遠離之前，先介紹一個重要的標識——CID（Content-ID），CID是IPFS中用來表示內容的標識，可以用來表示一個文件，也可以用來表示一個文件塊。如下所示，CID是一個字符串，它主要由Version、Codec和Multihash三部分構成，Version目前分為v0和v1版本，v0版本的CID可以由V0Builder生成，v0版本的CID以Qm字符串開頭，v1版本的CID可以由V1Builder生成，v1版本的CID主要包含三個部分Codec，MhType和MhLength，其中Codec是表示內容的編碼類型，例如DagProtobuf（即protobuf格式），DagCBOR（即cbor格式）等，MhType是哈希算法，例如SHA2_256（默認的哈希算法），SHA2_512，SHA3_256，SHA3_512等等，MhLength是生成哈希的長度，默認用-1表示根據哈希算法確定長度。

IPFS組件介紹

IPFS用IpfsNode表示IPFS的節點，存儲相關組件的如下所示：

這些組件的關系如下圖所示，最上層是DAGService，它組合了BlockService組件，而BlockService組合了GCBlockstore組件，然后GCBlockstroe包含BaseBlocks和GCLocker兩個組件，最后BaseBlocks組合了最原始的blockstore組件。

接下來分別介紹這些組件的功能：

Pinning：固定CID的管理器，主要負責將文件或者文件塊（又叫Block）的CID固定，固定CID的塊不會被GC掉。上傳的文件最后的文件的CID都會被固定住，防止被GC。

Blockstore：GCBlockstore類型，組合Blockstore和GCLocker兩個組件。

BaseBlocks：原始的blockstore，提供了對Block的Get/Put/Has/DeleteBlock等操作。

GCLocker：用來鎖住blockstore，保護blockstore防止被GC影響。

Blocks：提供Block的服務，組合Blockstore組件，提供了GetBlock/GetBlocks、AddBlock/AddBlocks、DeleteBlock等操作。

DAG：IPFS的默克爾DAG的服務，組合BlockService組件，提供Get/GetMany，Add/AddMany，Remove/RemoveMany等操作。

文件存儲流程

文件上傳時將文件添加到IPFS的倉庫中，上傳的流程可以如下圖所示，生成默克爾DAG的結構，生成的結構有兩種Layout：balanced和trickle的。這里介紹默認的balanced結構，首先生成root作為根節點，然后將文件分割，默認按照256KB大小讀取一個chunk，生成葉子節點，依次生成node1，node2，root節點會有Link指向掛在root節點的葉子節點node1和node2。root節點下面能夠Link的葉子節點數量是有限的，IPFS中默認設置的是174個（定義的Link的總的大小是8KB，每個Link的大小是34 + 8 + 5【sha256 multihash + size + no name + protobuf framing】，默認的Link的個數為8192/47約等于174）。

如下圖所示，超過174個后則會新創建一個new root節點，并Link到old root，新的chunk作為node3（這里用node3簡約了，實際上是第175個節點）被new root直接Link。

當繼續有新的chunk添加時，則會生成node34作為node3和node4的父節點，node34含有兩個Link分別鏈接到node3和node4。

IPFS在init的時候會生成.ipfs目錄，如下圖所示，其中blocks則為文件塊存儲的目錄，datastore為leveldb數據庫，其中存儲了文件系統的根哈希等，存儲相關的配置關聯在.ipfs目錄下面的config文件。

經過上面的步驟，文件已經切塊并轉化成Merkle DAG的結構，接下來詳細介紹每個塊是如何進行存儲的流程。

如下圖所示，一個Block存儲時，首先由dagService（實現了DAGService接口）調用Add進行添加；

之后由blockService（實現了BlockService接口）調用AddBlock添加該Block；

再調用arccache的Put，arccache是對存儲的Block做arc策略的緩存；

再之后由VerifBS調用Put進行存儲，VerifyBS主要對CID的合法性進行校驗，合法則進行Put；

接著blockstore（實現了Blockstore接口）調用Put進行存儲，Put函數中會對CID進行轉化，調用dshelp的CidToDsKey方法將CID轉化成存儲的Key；

再接著調用keytransform.Datastore的Put，Put函數中會將前綴拼上，這時Key加上了前綴/blocks；

然后調用measure的Put函數，measure是對mount的封裝；

之后調用mount的Put函數，mount和IPFS的config配置文件中結構對應，根據key去查找對應的datastore，由于前綴是/blocks則可以找到對應的measure；

調用該measure的Put函數；

最后調用flatfs的Put函數，由Put函數調用doPut最終調用encode函數將完整的block寫入的目錄指定為/home/test/.ipfs/blocks/WD，其中WD來自于blocks/CIQFSQATUBIEIFDECKTNGHOKPOEE7WUPM5NNNSJCCDROMM6YHEKTWDY中的倒數第三第二個字符。這樣該Block則寫入了該目錄下面的文件中。

總結

IPFS文件存儲格式為默克爾DAG格式，每一層Links大小為174個，超過了則會重新調整。文件存儲過程中有多個Datastore進行了組合和封裝，每個Datastore功能比較單一，例如arccache只做Block的緩存，VerifBS只做CID的校驗，這樣做的好處是每個組件功能明確，不好的地方在于組合太多，調用深度太深，加上內部都是用interface，好幾個組件都實現了該interface，不便于閱讀。

IPFS的存儲模式面向互聯網用戶而設計，因為它的開放性，允許所有節點隨意接入，已接入IPFS網絡的節點可以自由查找內容，不適合直接用來作為企業的文件存儲服務。但其分布式存儲的特點，很容易進行存儲的動態擴容，可以通過結合節點認證機制和DHT查找內容的剝離，為企業的分布式存儲系統，另外配合區塊鏈技術，通過鏈上鏈下協同技術，很容易地解決鏈上存儲容量不足的問題。
責任編輯人：CC