一、概述

IPFS 和區塊鏈有著非常緊密的聯系， 隨著區塊鏈的不斷發展，對數據的存儲需求也越來越高， 由于性能和成本的限制，現有的區塊鏈設計方案大部分都選擇了把較大的數據存儲在鏈外，通過對數據進行加密， 哈希運算等手段來防止數據被篡改， 在區塊鏈上只引用所存數據的hash 值, 從而滿足業務對數據的存儲需求。 本文從IPFS 的底層設計出發， 結合源代碼， 分析了IPFS 的一些技術細節。 由于IPFS還在不斷更新中， 文中引用的部分可能和最新代碼有所出入。

閱讀本文需要讀者

• 了解網絡編程

• 了解分布式存儲

• 了解基本的區塊鏈知識

?

二、什么是IPFS？

維基百科上是這樣解釋的：是一個旨在創建持久且分布式存儲和共享文件的網絡傳輸協議。

上面的解釋稍顯晦澀， 我的理解是：

1.???首先它是一個FS（文件系統）

2.???其次它支持點對點傳輸

既然是文件系統， 那它和普通的文件系統有什么區別呢？ 有以下幾點區別：

• 存儲方式:?它是分布式存儲的, 為了方便傳輸，文件被切分成多個block, 每個block 通過hash運算得到唯一的ID， 方便在網絡中進行識別和去重。 考慮到傳輸效率， 同一個block 可能有多個copy, 分別存儲在不同的網絡節點上。

• 內容尋址方式：?每個block都有唯一的ID，我們只需要根據節點的ID 就可以獲取到它所對應的block。

那么問題來了，?既然文件被切分成了多個block，如何組織這些block 數據，組成邏輯上的文件呢??在IFPS中采用的merkledag, 下面是 merkledag的一個示意圖：

簡單來說， 就是2種數據結構merkle?和DAG（有向無環圖）的結合， 通過這種邏輯結構， 可以滿足：

• 內容尋址: 使用hash ID來唯一識別一個數據塊的內容

• 防篡改: 可以方便的檢查哈希值來確認數據是否被篡改

• 去重: 由于內容相同的數據塊哈希是相同的，可以很容去掉重復的數據，節省存儲空間

確定了數據模型后， 接下來要做的事：?如何把數據分發到不同的網絡節點上， 達到分布式存儲和共享的目的？?我們先思考一下， 通過網絡，比如HTTP， 訪問某個文件的步驟，首先我們要知道存儲這個文件的服務器地址， 然后我們需要知道這個文件對應的ID， 比如文件名。前者我們可以抽象成網絡節點尋址， 后者我們抽象成文件對象尋址； 在IPFS中， 這兩種尋址方式使用了相同的算法，?KAD, 介紹KAD算法的文章很多，這里不贅述， 只簡單說明一下核心思想：

KAD 最精妙之處就是使用XOR 來計算ID 之間的距離，并且統一了節點ID 和 對象ID的尋址方式。?采用 XOR（按比特異或操作）算法計算 key 之間的“距離”。?

這種做法使得它具備了類似于“幾何距離”的某些特性（下面用 ⊕ 表示 XOR）

• (A ⊕ B) == (B ⊕ A) XOR 符合“交換律”，具備對稱性。

• (A ⊕ A) == 0 反身性，自身距離為零

• (A ⊕ B) > 0 【不同】的兩個 key 之間的距離必大于零

• (A ⊕ B) + (B ⊕ C) >= (A ⊕ C) 三角不等式

通過KAD算法，IPFS 把不同ID的數據塊分發到與之距離較近的網絡節點中，達到分布式存儲的目的。?

通過IPFS獲取文件時，只需要根據merkledag, 按圖索驥，根據每個block的ID, 通過KAD算法從相應網絡節點中下載block數據， 最后驗證是否數據完整， 完成拼接即可。

下面我們再從技術實現的角度做更深入的介紹。

?

三、IPFS的系統架構

我們先看一下IPFS的系統架構圖， 分為5層：

• 一層為naming， 基于PKI的一個命名空間；

• 第二層為merkledag， IPFS 內部的邏輯數據結構；

• 第三層為exchange, 節點之間block data的交換協議；

• 第四層為routing, 主要實現節點尋址和對象尋址；

• 第五層為network, 封裝了P2P通訊的連接和傳輸部分。

站在數據的角度來看， 又可以分為2個大的模塊：

• IPLD（?InterPlanetary Linked Data） 主要用來定義數據， 給數據建模；

• libp2p解決的是數據如何傳輸的問題。

下面分別介紹IFPS 中的2個主要部分IPLD 和 libP2P。

IPLD

通過hash 值來實現內容尋址的方式在分布式計算領域得到了廣泛的應用， 比如區塊鏈， 再比如git repo。 雖然使用hash 連接數據的方式有相似之處， 但是底層數據結構并不能通用， IPFS 是個極具野心的項目， 為了讓這些不同領域之間的數據可互操作， 它定義了統一的數據模型IPLD， 通過它， 可以方便地訪問來自不同領域的數據。

前面已經介紹數據的邏輯結構是用merkledag表示的， 那么它是如何實現的呢？ 圍繞merkledag作為核心， 它定義了以下幾個概念：

• merkle link 代表dag 中的邊

• merkel-dag 有向無環圖

• merkle-path 訪問dag節點的類似unix path的路徑

• IPLD data model 基于json 的數據模型

• IPLD serialized format 序列化格式

• canonical 格式： 為了保證同樣的logic object 總是序列化為一個同樣的輸出， 而制定的確定性規則

圍繞這些定義它實現了下面幾個components

• CID 內容ID

• data model 數據模型

• serialization format 序列化格式

• tools & libraries 工具和庫

• IPLD selector 類似CSS 選擇器， 方便選取dag中的節點

• IPLD transformation 對dag 進行轉換計算

我們知道，數據是多樣性的，為了給不同的數據建模， 我們需要一種通用的數據格式， 通過它可以最大程度地兼容不同的數據， IPFS 中定義了一個抽象的集合，?multiformat, 包含multihash、multiaddr、multibase、multicodec、multistream幾個部分。

?

?multihash

自識別hash, 由3個部分組成，分別是：hash函數編碼、hash值的長度和hash內容， 下面是個簡單的例子：

這種設計的最大好處是非常方便升級，一旦有一天我們使用的hash 函數不再安全了， 或者發現了更好的hash 函數，我們可以很方便的升級系統。

?

?multiaddr

自描述地址格式，可以描述各種不同的地址

multibase

multibase 代表的是一種編碼格式， 方便把CID 編碼成不同的格式， 比如這里定義了2進制、8進制、10進制、16進制、也有我們熟悉的base58btc 和 base64編碼。

multicodec

mulcodec 代表的是自描述的編解碼， 其實是個table， 用1到2個字節定了數據內容的格式， 比如用字母z表示base58btc編碼， 0x50表示protobuf 等等。

?multistream

multistream 首先是個stream， 它利用multicodec，實現了自描述的功能， 下面是基于一個javascript 的例子； 先new 一個buffer 對象， 里面是json對象， 然后給它加一個前綴protobuf, 這樣這個multistream 就構造好了， 可以通過網絡傳輸。在解析時可以先取codec 前綴，然后移除前綴， 得到具體的數據內容。

結合上面的部分， 我們重點介紹一下CID。

CID 是IPFS分布式文件系統中標準的文件尋址格式，它集合了內容尋址、加密散列算法和自我描述的格式, 是IPLD 內部核心的識別符。目前有2個版本，CIDv0 和CIDv1。?

CIDv0是一個向后兼容的版本，其中:

• multibase 一直為 base58btc

• multicodec 一直為 protobuf-mdag

• version 一直為 CIDv0

• multihash 表示為cidv0 ::= <multihash-content-address>

為了更靈活的表述ID數據， 支持更多的格式， IPLD 定義了CIDv1，CIDv1由4個部分組成：

• multibase

• version

• multicodec

• multihash?

IPLD 是IPFS 的數據描述格式， 解決了如何定義數據的問題， 下面這張圖是結合源代碼整理的一份邏輯圖，我們可以看到上面是一些高級的接口， 比如file, mfs, fuse 等。 下面是數據結構的持久化部分，節點之間交換的內容是以block 為基礎的， 最下面就是物理存儲了。比如block 存儲在blocks 目錄， 其他節點之間的信息存儲在leveldb， 還有keystore, config 等。

?

數據如何傳輸呢？

接下來我們介紹libP2P， 看看數據是如何傳輸的。libP2P 是個模塊化的網絡協議棧。

做過socket編程的小伙伴應該都知道， 使用raw socket 編程傳輸數據的過程，無非就是以下幾個步驟：

獲取目標服務器地址

和目標服務器建立連接

握手協議

傳輸數據

關閉連接

libP2P 也是這樣，不過區別在于它把各個部分都模塊化了， 定義了通用的接口， 可以很方便的進行擴展。

?

架構圖

由以下幾個部分組成，分別是：

• Peer Routing

• Swarm (傳輸和連接)

• Distributed Record Store

• Discovery?

下面我們對它們做分別介紹, 我們先看關鍵的路由部分。

?

Peer Routing

libP2P定義了routing 接口，目前有2個實現，分別是KAD routing 和 MDNS routing, 擴展很容易， 只要按照接口實現相應的方法即可。

ipfs 中的節點路由表是通過維護多個K-BUCKET來實現的， 每次新增節點， 會計算節點ID 和自身節點ID 之間的common prefix, 根據這個公共前綴把節點加到對應的KBUCKET 中, KBUCKET 最大值為20， 當超出時，再進行拆分。

更新路由表的流程如下：

除了KAD routing 之外， IPFS 也實現了MDNS routing, 主要用來在局域網內發現節點, 這個功能相對比較獨立， 由于用到了多播地址， 在一些公有云部署環境中可能無法工作。

?

Swarm（傳輸和連接）

swarm 定義了以下接口：

• transport 網絡傳輸層的接口

• connection 處理網絡連接的接口

• stream multiplex 同一connection 復用多個stream的接口

下面我們重點看下是如何動態協商stream protocol 的，整個流程如下：

默認先通過multistream-select 完成握手

發起方嘗試使用某個協議， 接收方如果不接受， 再嘗試其他協議， 直到找到雙方都支持的協議或者協商失敗。

另外為了提高協商效率， 也提供了一個ls 消息， 用來查詢目標節點支持的全部協議。

?

Distributed Record Store

record 表示一個記錄， 可以用來存儲一個鍵值對，比如ipns name publish 就是發布一個objectId 綁定指定 node id 的record 到ipfs 網絡中， 這樣通過ipns 尋址時就會查找對應的record, 再解析到objectId, 實現尋址的功能。

?

Discovery

目前系統支持3種發現方式， 分別是：

• bootstrap 通過配置的啟動節點發現其他的節點

• random walk 通過查詢隨機生成的peerID， 從而發現新的節點

• mdns 通過multicast 發現局域網內的節點

?

最后總結一下源代碼中的邏輯模塊：

?

從下到上分為5個層次:

• 最底層為傳輸層， 主要封裝各種協議， 比如TCP，SCTP， BLE， TOR 等網絡協議

• 傳輸層上面封裝了連接層，實現連接管理和通知等功能

• 連接層上面是stream 層， 實現了stream的多路復用

• stream層上面是路由層

• 最上層是discovery, messaging以及record store 等

?

四、總結

本文從定義數據和傳輸數據的角度分別介紹了IPFS的2個主要模塊IPLD 和 libP2P：

• ?IPLD 主要用來定義數據， 給數據建模

• ?libP2P 解決數據傳輸問題

這兩部分相輔相成， 雖然都源自于IPFS項目，但是也可以獨立使用在其他項目中。

?
IPFS的遠景目標就是替換現在瀏覽器使用的 HTTP 協議， 目前項目還在迭代開發中， 一些功能也在不斷完善。為了解決數據的持久化問題， 引入了filecoin?激勵機制， 通過token激勵，讓更多的節點加入到網絡中來，從而提供更穩定的服務。

總結

以上是生活随笔為你收集整理的深入浅出下一代互联网基础IPFS的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。