一、概述

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

閱讀本文需要讀者

• 了解網(wǎng)絡編程

• 了解分布式存儲

• 了解基本的區(qū)塊鏈知識

?

二、什么是IPFS？

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

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

1.???首先它是一個FS（文件系統(tǒng)）

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

既然是文件系統(tǒng)， 那它和普通的文件系統(tǒng)有什么區(qū)別呢？ 有以下幾點區(qū)別：

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

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

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

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

• 內(nèi)容尋址: 使用hash ID來唯一識別一個數(shù)據(jù)塊的內(nèi)容

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

• 去重: 由于內(nèi)容相同的數(shù)據(jù)塊哈希是相同的，可以很容去掉重復的數(shù)據(jù)，節(jié)省存儲空間

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

KAD 最精妙之處就是使用XOR 來計算ID 之間的距離，并且統(tǒng)一了節(jié)點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的數(shù)據(jù)塊分發(fā)到與之距離較近的網(wǎng)絡節(jié)點中，達到分布式存儲的目的。?

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

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

?

三、IPFS的系統(tǒng)架構

我們先看一下IPFS的系統(tǒng)架構圖， 分為5層：

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

• 第二層為merkledag， IPFS 內(nèi)部的邏輯數(shù)據(jù)結構；

• 第三層為exchange, 節(jié)點之間block data的交換協(xié)議；

• 第四層為routing, 主要實現(xiàn)節(jié)點尋址和對象尋址；

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

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

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

• libp2p解決的是數(shù)據(jù)如何傳輸?shù)膯栴}。

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

IPLD

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

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

• merkle link 代表dag 中的邊

• merkel-dag 有向無環(huán)圖

• merkle-path 訪問dag節(jié)點的類似unix path的路徑

• IPLD data model 基于json 的數(shù)據(jù)模型

• IPLD serialized format 序列化格式

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

圍繞這些定義它實現(xiàn)了下面幾個components

• CID 內(nèi)容ID

• data model 數(shù)據(jù)模型

• serialization format 序列化格式

• tools & libraries 工具和庫

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

• IPLD transformation 對dag 進行轉換計算

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

?

?multihash

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

這種設計的最大好處是非常方便升級，一旦有一天我們使用的hash 函數(shù)不再安全了， 或者發(fā)現(xiàn)了更好的hash 函數(shù)，我們可以很方便的升級系統(tǒng)。

?

?multiaddr

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

multibase

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

multicodec

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

?multistream

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

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

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

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

• multibase 一直為 base58btc

• multicodec 一直為 protobuf-mdag

• version 一直為 CIDv0

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

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

• multibase

• version

• multicodec

• multihash?

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

?

數(shù)據(jù)如何傳輸呢？

接下來我們介紹libP2P， 看看數(shù)據(jù)是如何傳輸?shù)摹ibP2P 是個模塊化的網(wǎng)絡協(xié)議棧。

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

獲取目標服務器地址

和目標服務器建立連接

握手協(xié)議

傳輸數(shù)據(jù)

關閉連接

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

?

架構圖

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

• Peer Routing

• Swarm (傳輸和連接)

• Distributed Record Store

• Discovery?

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

?

Peer Routing

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

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

更新路由表的流程如下：

除了KAD routing 之外， IPFS 也實現(xiàn)了MDNS routing, 主要用來在局域網(wǎng)內(nèi)發(fā)現(xiàn)節(jié)點, 這個功能相對比較獨立， 由于用到了多播地址， 在一些公有云部署環(huán)境中可能無法工作。

?

Swarm（傳輸和連接）

swarm 定義了以下接口：

• transport 網(wǎng)絡傳輸層的接口

• connection 處理網(wǎng)絡連接的接口

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

下面我們重點看下是如何動態(tài)協(xié)商stream protocol 的，整個流程如下：

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

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

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

?

Distributed Record Store

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

?

Discovery

目前系統(tǒng)支持3種發(fā)現(xiàn)方式， 分別是：

• bootstrap 通過配置的啟動節(jié)點發(fā)現(xiàn)其他的節(jié)點

• random walk 通過查詢隨機生成的peerID， 從而發(fā)現(xiàn)新的節(jié)點

• mdns 通過multicast 發(fā)現(xiàn)局域網(wǎng)內(nèi)的節(jié)點

?

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

?

從下到上分為5個層次:

• 最底層為傳輸層， 主要封裝各種協(xié)議， 比如TCP，SCTP， BLE， TOR 等網(wǎng)絡協(xié)議

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

• 連接層上面是stream 層， 實現(xiàn)了stream的多路復用

• stream層上面是路由層

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

?

四、總結

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

• ?IPLD 主要用來定義數(shù)據(jù)， 給數(shù)據(jù)建模

• ?libP2P 解決數(shù)據(jù)傳輸問題

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

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

總結

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。