IPFS(中文白皮書)

時間 2019-11-07

標籤 ipfs 中文白皮書简体版

原文原文鏈接

IPFS(中文白皮書)

2017-05-28node

IPFS - 可快速索引的版本化的點對點文件系統（草稿3）

做者： Juan Benet (juan@benet.ai)
譯者： 郭光華(gavin@8btc.com)，https://gguoss.github.io/2017/05/28/ipfs/git

摘要

星際文件系統是一種點對點的分佈式文件系統，旨在鏈接全部有相同的文件系統的計算機設備。在某些方面， IPFS相似於web, 但web 是中心化的，而IPFS是一個單一的Bittorrent 羣集，用git 倉庫分佈式存儲。換句話說， IPFS 提供了高吞吐量的內容尋址塊存儲模型，具備內容尋址的超連接。這造成了一個廣義的Merkle DAG 數據結構，能夠用這個數據結構構建版本文件系統，區塊鏈，甚至是永久性網站。。IPFS 結合了分佈式哈希表，帶有激勵機制的塊交換和自我認證命名空間。IPFS 沒有單故障點，節點不須要相互信任。github

1. 介紹

在全球分佈式文件系統這領域，已經有許多人的嘗試。一些系統已經取得了重大的成功，而不少卻徹底失敗了。在學術嘗試中， AFS【6】就是成功的例子，現在已經獲得普遍的應用，然而，其餘的【7，？】卻沒有獲得相同的結果。在學術界以外，應用最普遍的是面向音視頻媒體的點對點文件共享系統。最值得注意的是， Napster, KaZaA 和BitTorrent[2]部署的文件分發系統支持1億用戶的同時在線。即便在今天， BitTorrent 也維持着天天千萬節點的活躍數。基於這些學術文件系統理論而實現的應用程序有不少的用戶量，然而，這些系統理論是在應用層，而沒有放在基礎層。以至沒有出現通用的文件系統基礎框架，給全球提供低延遲的分發。
也許是由於HTTP這樣「足夠好「的系統已經存在。到目前爲止，HTTP已經做爲「分佈式文件系統「的協議，而且已經大量部署，再與瀏覽器相結合，具備巨大的技術和社會影響力。在如今，它已經成爲互聯網傳輸文件的事實標準。然而，他沒有采用最近15年的發明的數十種先進的文件分發技術。從一方面講，因爲向後兼容的限制和當前新模式的投入，不斷髮展http web 的基礎設施幾乎是不可能的。但從一個角度看，從http 出現以來，已經有許多新協議出現並被普遍使用。升級http協議雖然能引入新功能和增強當前http協議，但會下降用戶的體驗。
有些行業已經擺脫使用HTTP 這麼久，由於移動小文件相對便宜，即便對擁有大流量的小組織也是如此。可是，隨着新的挑戰，咱們正在進入數據分發的新紀元。web

（a）託管和分發PB級數據集，
（b）跨組織的大數據計算，
（c）大批量的高清晰度按需或實時媒體流，
（d）大規模數據集的版本化和連接，
（e）防止意外丟失重要文件等。其中許多能夠歸結爲「大量數據，無處不在」。

因爲關鍵功能和帶寬問題，咱們已經爲不一樣的數據放棄了HTTP 分銷協議。下一步是使它們成爲web本身的一部分。正交於有效的數據分發，版本控制系統，已經設法開發重要的數據協做工做流程。算法

Git是分佈式源代碼版本控制系統，開發了許多有用的方法來建模和實現分佈式數據操做。Git工具鏈提供了靈活的版本控制功能，這正是大量的文件分發系統所嚴重缺少的。由Git啓發的新解決方案正在出現，如Camlistore [？]，我的文件存儲系統，Dat [？]數據協做工具鏈和數據集包管理器。Git已經影響了分佈式文件系統設計[9]，由於其內容涉及到Merkle DAG數據模型，可以實現強大的文件分發策略。還有待探討的是，這種數據結構如何影響面向高吞吐量的文件系統的設計，以及如何升級Web自己。
本文介紹了IPFS，一種新穎的對等版本控制的文件系統，旨在調和這些問題。 IPFS綜合了許多之前成功的系統的優勢。 IPFS產生了突出的效果，甚至比參考的這些系統的總和還要好。IPFS的核心原則是將全部數據建模爲同一Merkle DAG的一部分。數據庫

2. 背景

本節回顧了IPFS所採用成功的點對點系統技術的重要屬性。數組

2.1 分佈式哈希表(DHT)

分佈式散列表（DHT）被普遍用於協調和維護關於對等系統的元數據。好比，MainlineDHT 是一個去中心化哈希表，他可追蹤查找全部的對等節點。瀏覽器

2.1.1 KADEMLIA DHT

Kademlia[10] 是受歡迎的DHT, 它提供：緩存

1.經過大量網絡進行高效查詢：查詢平均聯繫人O(log2N)節點。（例如，20跳10萬個節點的網絡）
2.低協調開銷：優化數量的控制消息發送到其餘節點。
3.抵抗各類攻擊，喜歡長壽節點。
4.在對等應用中普遍使用，包括Gnutella和BitTorrent，造成了超過2000萬個節點的網絡[16]。

2.1.2 CORAL DSHT

雖然一些對等文件系統直接在DHT中存儲數據塊，這種「數據存儲在不須要的節點會亂費存儲和帶寬」[5]。Coral DSHT擴展了Kademlia三個特別重要的方式：安全

1.Kademlia在ids爲「最近」（使用XOR-distance）的關鍵節點中存儲值。這不考慮應用程序數據的局部性，忽略「遠」可能已經擁有數據的節點，並強制「最近」節點存儲它，不管它們是否須要。這浪費了大量的存儲和帶寬。相反，Coral 存儲了地址，該地址的對等節點能夠提供相應的數據塊。
2.Coral將DHT API從get_value(key)換成了get_any_values(key)（DSHT中的「sloppy」）中。這仍然是由於Coral用戶只須要一個（工做）的對等體，而不是完整的列表。做爲回報，Coral能夠僅將子集分配到「最近」的節點，避免熱點（當密鑰變得流行時，重載全部最近的節點）。
3.另外，Coral根據區域和大小組織了一個稱爲羣集的獨立DSHT層次結構。這使得節點首先查詢其區域中的對等體，「查找附近的數據而不查詢遠程節點」[5]並大大減小查找的延遲。
2.1.3 S/KADEMLIA DHT
S/Kademlia[1] 擴展了Kademlia, 用於防止惡意的攻擊。有以下兩方面的方法：
1.S/Kad 提供了方案來保證NodeId的生成已經防止Sybill攻擊。它須要節點產生PKI公私鑰對。從中導出他們的身份，並彼此間簽名。一個方案使用POW工做量證實，使得生成Sybills成本高昂。
2.S/Kad 節點在不相交的路徑上查找直，即便網絡中存在大量的不誠實節點，也能確保誠實節點能夠互相連接。即便網絡中存在一半的不誠實節點，S/Kad 也能達到85%的成功率。
2.2 塊交換 - BitTorrent
BitTorrent[3] 是一個普遍成功應用的點對點共享文件系統，它能夠在存在不信任的對等節點（羣集）的協做網絡中分發各自的文件數據片。從BitTorrent和它的生態系統的關鍵特徵， IPFS獲得啓示以下：
1.BitTorrent的數據交換協議使用了一種bit-for-tat的激勵策略，能夠獎勵對其餘方面作貢獻的節點，懲罰只榨取對方資源的節點。
2.BitTorrent對等體跟蹤文件的可用性，優先發送稀有片斷。這減輕了seeds節點的負擔，讓non-seeds節點有能力互相交易。
3.對於一些剝削帶寬共享策略， BitTorrent的標準tit-for-tat策略是很是脆弱的。然而，PropShare[8]是一種不一樣的對等帶寬分配策略，能夠更好的抵制剝削戰略，提升羣集的表現。
2.3. 版本控制系統- Git
版本控制系統提供了對隨時間變化的文件進行建模的設施，並有效地分發不一樣的版本。流行版本控制系統Git提供了強大的Merkle DAG對象模型，以分佈式友好的方式捕獲對文件系統樹的更改。
1.不可更改的對象表示文件（blob），目錄（樹）和更改（提交）。
2.經過加密hash對象的內容，讓對象可尋址。
3.連接到其餘對象是嵌入的，造成一個Merkle DAG。這提供了不少有用的完整和work-flow屬性。
4.不少版本元數據（分支，標示等等）都只是指針引用，所以建立和更新的代價都小。
5.版本改變只是更新引用或者添加對象。
6.分佈式版本改變對其餘用戶而言只是轉移對象和更新遠程引用。

2.4 自我認證認文件系統-SFS

SFS [ 12，11 ]提出了兩個引人注目的實現（a）分佈式信任鏈，和（b）平等共享的全局命名空間。SFS引入了一種自我建構技術—註冊文件：尋址遠程文件系統使用如下格式：
1

2

3
/sfs/<Location>:<HostID>

Location:表明的是服務網絡地方

HostID = hash(public_key || Location)
所以SFS文件系統的名字認證了它的服務，用戶能夠經過服務提供的公鑰來驗證，協商一個共享的私鑰，保證全部的通訊。全部的SFS實例都共享了一個全局的命名空間，這個命名空間的名稱分配是加密的，不被任何中心化的body控制。

3. IPFS設計

IPFS是一個分佈式文件系統，它綜合了之前的對等系統的成功想法，包括DHT，BitTorrent，Git和SFS。 IPFS的貢獻是簡化，發展和將成熟的技術鏈接成一個單一的內聚系統，大於其部分的總和。 IPFS提供了編寫和部署應用程序的新平臺，以及一個新的分發系統版本化大數據。 IPFS甚至能夠演進網絡自己。
IPFS是點對點的;沒有節點是特權的。 IPFS節點將IPFS對象存儲在本地存儲中。節點彼此鏈接並傳輸對象。這些對象表示文件和其餘數據結構。 IPFS協議分爲一組負責不一樣功能的子協議：
1. 身份 - 管理節點身份生成和驗證。描述在3.1節。
2.網絡 - 管理與其餘對等體的鏈接，使用各類底層網絡協議。可配置的。詳見3.2節。
3.路由 - 維護信息以定位特定的對等體和對象。響應本地和遠程查詢。默認爲DHT，但可更換。在3.3節描述。
4.交換 - 一種支持有效塊分配的新型塊交換協議（BitSwap）。模擬市場，弱化數據複製。貿易策略可替換。描述在3.4節。
5.對象 - 具備連接的內容尋址不可更改對象的Merkle DAG。用於表示任意數據結構，例如文件層次和通訊系統。詳見第3.5節。
6.文件 - 由Git啓發的版本化文件系統層次結構。詳見3.6節。
7.命名 - 自我認證的可變名稱系統。詳見3.7節。
這些子系統不是獨立的;它們是集成在一塊兒，互相利用各自的屬性。可是，分開描述它們是有用的，從下到上構建協議棧。符號：Go語言中指定了如下數據結構和功能

3.1 身份

節點由NodeId標識，這是使用S / Kademlia的靜態加密難題[1]建立的公鑰的密碼散列。節點存儲其公私鑰（用密碼加密）。用戶能夠在每次啓動時自由地設置一個「新」節點身份，儘管這會損失積累的網絡利益。激勵節點保持不變。

type NodeId Multihash

type Multihash []byte // 自描述加密哈希摘要

type PublicKey []byte

type PrivateKey []byte // 自描述的私鑰

type Node struct {

NodeId NodeID

PubKey PublicKey

PriKey PrivateKey

}

基於S / Kademlia的IPFS身份生成：

difficulty = <integer parameter>

n = Node{}

do {

n.PubKey, n.PrivKey = PKI.genKeyPair()

n.NodeId = hash(n.PubKey)

p = count_preceding_zero_bits(hash(n.NodeId))

} while (p < difficulty)

首次鏈接時，對等體交換公鑰，並檢查：hash（other.PublicKey）等於other.NodeId。若是沒有，則鏈接被終止
關於加密函數的注意事項：
IPFS不是將系統鎖定到一組特定的功能選擇，而是支持自我描述的值。哈希摘要值以多重哈希格式存儲，其包括指定使用的哈希函數的頭和以字節爲單位的摘要長度。例如：

1	<function code><digest length><digest bytes>

這容許系統

（a）選擇最佳功能用例（例如，更強的安全性與更快的性能），
（b）隨着功能選擇的變化而演變。自描述值容許兼容使用不一樣的參數選擇。
3.2 網絡
IPFS節點與數百個其餘節點進行按期通訊網絡中的節點，可能跨越廣域網絡。IPFS網絡堆棧功能：
傳輸層： IPFS可使用任何傳輸協議，而且最適合WebRTC DataChannels [？]（用於瀏覽器鏈接）或uTP（LEDBAT [14]）。
可靠性：若是底層網絡不提供可靠性，IPFS可以使用uTP（LEDBAT [14]）或SCTP [15]來提供可靠性。
可鏈接性：IPFS還可使用ICE NAT穿牆打洞技術[13]。
完整性：可使用哈希校驗和來檢查郵件的完整性。

可驗證性：可使用發送者的公鑰使用HMAC來檢查消息的真實性。

3.2.1對等節點尋址注意事項：

IPFS可使用任何網絡; 但它不承擔對IP的獲取以及不直接依賴於ip層。這容許在覆蓋網絡中使用IPFS。
IPFS將地址存儲爲多層地址，這個多層地址是由字節字符串組成的，以便於給底層網絡使用。多層地址提供了一種方式來表示地址及其協議，能夠封裝成好解析的格式。例如：

# an SCTP/IPv4 connection

/ip4/10.20.30.40/sctp/1234/

# an SCTP/IPv4 connection proxied over TCP/IPv4

/ip4/5.6.7.8/tcp/5678/ip4/1.2.3.4/sctp/1234/

3.3 路由

IPFS節點須要一個路由系統，這個路由系統可用於查找：

（a）其餘同伴的網絡地址，

（b）專門用於服務特定對象的對等節點。
IPFS使用基於S / Kademlia和Coral的DSHT，在2.1節中具體介紹過。在對象大小和使用模式方面， IPFS 相似於Coral[5] 和Mainline[16], 所以，IPFS DHT根據其大小對存儲的值進行區分。小的值（等於或小於1KB）直接存儲在DHT上。對於更大的值，DHT只存儲值索引，這個索引就是一個對等節點的NodeId, 該對等節點能夠提供對該類型的值的具體服務。
DSHT的接口以下：

type IPFSRouting interface {

FindPeer(node NodeId) // 獲取特定NodeId的網絡地址。

SetValue(key []bytes, value []bytes) // 往DHT存儲一個小的元數據。

GetValue(key []bytes) // 從DHT獲取元數據。

ProvideValue(key Multihash) // 聲明這個節點可一個提供一個大的數據。

FindValuePeers(key Multihash, min int) // 獲取服務於該大數據的節點。

}

注意：不一樣的用例將要求基本不一樣的路由系統（例如廣域網中使用DHT，局域網中使用靜態HT）。所以，IPFS路由系統能夠根據用戶的需求替換的。只要使用上面的接口就能夠了，系統都能繼續正常運行。

3.4塊交換 - BitSwap協議

IPFS 中的BitSwap協議受到BitTorrent 的啓發，經過對等節點間交換數據塊來分發數據的。像BT同樣，每一個對等節點在下載的同時不斷向其餘對等節點上傳已下載的數據。和BT協議不一樣的是， BitSwap 不侷限於一個torrent文件中的數據塊。BitSwap 協議中存在一個永久的市場。這個市場包括各個節點想要獲取的全部塊數據。而無論這些塊是哪些如.torrent文件中的一部分。這些快數據可能來自文件系統中徹底不相關的文件。這個市場是由全部的節點組成的。
雖然易貨系統的概念意味着能夠建立虛擬貨幣，但這將須要一個全局分類帳原本跟蹤貨幣的全部權和轉移。這能夠實施爲BitSwap策略，並將在將來的論文中探討。
在基本狀況下，BitSwap節點必須以塊的形式彼此提供直接的值。只有當跨節點的塊的分佈是互補的時候，各取所需的時候，這纔會工做的很好。一般狀況並不是如此，在某些狀況下，節點必須爲本身的塊而工做。在節點沒有其對等節點所需的（或根本沒有的）狀況下，它會更低的優先級去尋找對等節點想要的塊。這會激勵節點去緩存和傳播稀有片斷，即便節點對這些片斷不感興趣。

3.4.1 - BITSWAP 信用

這個協議必須帶有激勵機制，去激勵節點去seed 其餘節點所須要的塊，而它們自己是不須要這些塊的。所以， BitSwap的節點很積極去給對端節點發送塊，期待得到報酬。但必須防止水蛭攻擊（空負載節點從不共享塊），一個簡單的相似信用的系統解決了這些問題：

1，對等節點間會追蹤他們的平衡（經過字節認證的方式）。
2，隨着債務增長而機率下降，對等者機率的向債務人發送塊。
注意的是，若是節點決定不發送到對等體，節點隨後忽略對等體的ignore_cooldown超時。這樣能夠防止發送者嘗試屢次發送（洪水攻擊）（BitSwap默認是10秒）。
3.4.2 BITSWAP的策略
BitSwap 對等節點採用不少不一樣的策略，這些策略對整個數據塊的交換執行力產生了不一樣的巨大影響。在BT 中，標準策略是明確規定的（tit-for-tat），其餘不一樣的策略也已經被實施，從BitTyrant [8]（儘量分享）到BitThief [8]（利用一個漏洞，從不共享），到PropShare [8]（按比例分享）。BitSwap 對等體能夠相似地實現一系列的策略（良好和惡意）。對於功能的選擇，應該瞄準：
1.爲整個交易和節點最大化交易能力。
2.爲了防止空負載節點利用和損害交易。
3.高效抵制未知策略。
4.對可信任的對等節點更寬容。
探索這些策略的空白是將來的事情。在實踐中使用的一個選擇性功能是sigmoid，根據負債比例進行縮放：
讓負債比例在一個節點和它對等節點之間：
1
r = bytes_sent / bytes_recv + 1

根據r，發送到負債節點的機率爲：

1	P(send \| r ) = 1 − ( 1/ ( 1 + exp(6 − 3r) ) )

正如你看到的圖片1，當節點負債比例超過節點已創建信貸的兩倍，發送到負債節點的機率就會急速降低。

圖片1  當r增長時發送的機率

負債比是信任的衡量標準：對於以前成功的互換過不少數據的節點會寬容債務，而對不信任不瞭解的節點會嚴格不少。這個(a)給與那些創造不少節點的攻擊者（sybill 攻擊）一個障礙。(b)保護了以前成功交易節點之間的關係，即便這個節點暫時沒法提供數據。(c)最終阻塞那些關係已經惡化的節點之間的通訊，直到他們被再次證實。

3.4.3 BITSWAP 帳本

BitSwap節點保存了一個記錄與全部其餘節點之間交易的帳本。這個可讓節點追蹤歷史記錄以及避免被篡改。當激活了一個連接，BitSwap節點就會互換它們帳本信息。若是這些帳本信息並不徹底相同，分類帳本將會從新初始化，那些應計信貸和債務會丟失。惡意節點會有意去失去「這些「帳本，從而指望清除本身的債務。節點是不太可能在失去了應計信託的狀況下還能累積足夠的債務去受權認證。夥伴節點能夠自由的將其視爲不當行爲，拒絕交易。

type Ledger struct {

owner NodeId

partner NodeId

bytes_sent int

bytes_recv int

timestamp Timestamp

}

節點能夠自由的保留分佈式帳本歷史，這不須要正確的操做，由於只有當前的分類帳本條目是有用的。節點也能夠根據須要自由收集分佈式賬本，從不太有用的分佈式賬開始：老（其餘對等節點可能不存在）和小。

3.4.4 BITSWAP 詳解

BitSwap 節點有如下簡單的協議。

// Additional state kept

type BitSwap struct {

ledgers map[NodeId]Ledger // Ledgers known to this node, inc inactive

active map[NodeId]Peer // currently open connections to other nodes

need_list []Multihash // checksums of blocks this node needs

have_list []Multihash // checksums of blocks this node has

}

type Peer struct {

nodeid NodeId

ledger Ledger // Ledger between the node and this peer

last_seen Timestamp // timestamp of last received message

want_list []Multihash // checksums of all blocks wanted by peer

// includes blocks wanted by peer's peers

}

// Protocol interface:

interface Peer {

open (nodeid : NodeId, ledger : Ledger);

send_want_list (want_list : WantList);

send_block(block: Block) -> (complete:Bool);

close(final: Bool);

}

對等鏈接的生命週期草圖：

1.Open: 對等節點間發送ledgers 直到他們贊成。
2.Sending: 對等節點間交換want_lists 和blocks。
3.Close: 對等節點斷開連接。
4.Ignored: （特殊）對等體被忽略（等待時間的超時）若是節點採用防止發送策略。
Peer.open(NodeId, Ledger).
當發生連接的時候，節點會初始化連接的帳本，要麼保存一個份連接過去的帳本，要麼建立一個新的被清零的帳本。而後，發送一個攜帶帳本的open信息給對等節點。
接收到一個open信息以後，對等節點能夠選擇是否接受此連接。若是，根據接收者的帳本，發送者是一個不可信的代理（傳輸低於零或者有很大的未償還的債務），接收者可能會選擇忽略這個請求。忽略請求是ignore_cooldown超時來機率性實現的，爲了讓錯誤可以有時間改正和攻擊者被挫敗。
若是連接成功，接收者用本地帳原本初始化一個Peer對象以及設置last_seen時間戳。而後，它會將接受到的帳本與本身的帳本進行比較。若是兩個帳本徹底同樣，那麼這個連接就被Open，若是帳本並不徹底一致，那麼此節點會建立一個新的被清零的帳本而且會發送此帳本。
Peer.send_want_list(WantList)
當連接已經Open的時候，節點會廣發它們的want_list給全部已經連接的對等節點。這個是在(a)open連接後(b)隨機間歇超時後(c)want_list改變後(d)接收到一個新的塊以後完成的。
當接收到一個want_list以後，節點會存儲它。而後，會檢查本身是否擁有任何它想要的塊。若是有，會根據上面提到的BitSwap策略來將want_list所須要的塊發送出去。
Peer.send_block(Block)
發送一個塊是直接了當的。節點只是傳輸數據塊。當接收到了全部數據的時候，接收者會計算多重hash校驗和來驗證它是不是本身所需數據，而後發送確認信息。
在完成一個正確的塊傳輸以後，接受者會將此塊從need_list一到have_list,最後接收者和發送者都會更新它們的帳原本反映出傳輸的額外數據字節數。
若是一個傳輸驗證失敗了，發送者要麼會出故障要麼會攻擊接收者，接收者能夠選擇拒絕後面的交易。注意，BitSwap是指望可以在一個可靠的傳輸通道上進行操做的，因此傳輸錯誤（可能會引發一個對誠實發送者錯誤的懲罰）是指望在數據發送給BitSwap以前可以被捕捉到。
Peer.close(Bool)
傳給close最後的一個參數，表明close連接是不是發送者的意願。若是參數值爲false,接收者可能會當即從新open連接，這避免鏈過早的close連接。
一個對等節點close連接發生在下面兩種狀況下：
silence_wait超時已通過期，而且沒有接收到來自於對等節點的任何信息（BitSwap默認使用30秒），節點會發送Peer.close(false)。
在節點退出和BitSwap關閉的時候，節點會發送Peer.close(true).
接收到close消息以後，接收者和發送者會斷開連接，清除全部被存儲的狀態。帳本可能會被保存下來爲了之後的便利，固然，只有在被認爲帳本之後會有用時纔會被保存下來。
注意點：
非open信息在一個不活躍的鏈接上應該是被忽略的。在發送send_block信息時，接收者應該檢查這個塊，看它是不是本身所需的，而且是不是正確的，若是是，就使用此塊。總之，全部不規則的信息都會讓接收者觸發一個close(false)信息而且強制性的重初始化此連接。
3.5 Merkle DAG對象
DHT和BitSwap容許IPFS構造一個龐大的點對點系統用來快速穩定的分發和存儲。最主要的是，IPFS建造了一個Merkle DAG,一個無迴路有向圖，對象之間的links都是hash加密嵌入在源目標中。這是Git數據結構的一種推廣。Merkle DAGS給IPFS提供了不少有用的屬性，包括：
1.內容可尋址：全部內容都是被多重hash校驗和來惟一識別的，包括links。
2.防止篡改：全部的內容都用它的校驗和來驗證。若是數據被篡改或損壞，IPFS會檢測到。
3.重複數據刪除：全部的對象都擁有相同的內容並只存儲一次。這對於索引對象很是有用，好比git的tree和commits，或者數據的公共部分。

IPFS對象的格式是：

type IPFSLink struct {

Name string // 此link的別名

Hash Multihash // 目標的加密hash

Size int // 目標總大小

}

type IPFSObject struct {

links []IPFSLink //links數組

data []byte //不透明內容數據

}

IPFS Merkle DAG是存儲數據很是靈活的一種方式。只要求對象引用是(a）內容可尋址的，(b)用上面的格式編碼。IPFS容許應用徹底的掌控數據域；應用可使用任何自定義格式的數據，即便數據IPFS都沒法理解。單獨的內部對象link表容許IPFS作：

用對象的形式列出全部對象引用，例如：

> ipfs ls /XLZ1625Jjn7SubMDgEyeaynFuR84ginqvzb

XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x 189458 less

XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5 19441 script

XLF4hwVHsVuZ78FZK6fozf8Jj9WEURMbCX4 5286 template

解決字符串路經查找，例如foo/bar/baz。給出一個對象，IPFS會解析第一個路經成分進行hash放入到對象的link表中，再獲取路徑的第二個組成部分，一直如此重複下去。所以，任何數據格式的字符串路經均可以在Merkle DAG中使用。
*遞歸性的解決全部對象引用：

> ipfs refs --recursive \

/XLZ1625Jjn7SubMDgEyeaynFuR84ginqvzb

XLLxhdgJcXzLbtsLRL1twCHA2NrURp4H38s

XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x

XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5

XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z

原始數據結構公共link結構是IPFS構建任意數據結構的必要組成部分。能夠很容易看出Git的對象模型是如何套用DAG的。一些其餘潛在的數據結構：

(a)鍵值存儲
(b)傳統關係型數據
(c)數據三倍存儲
(d) 文檔發佈系統
(e)通訊平臺
(f)加密貨幣區塊。
這些系統均可以套用IPFS Merkle DAG，這使這些系統更復雜的應用可使用IPFS做爲傳輸協議。

3.5.1 路經

IPFS對象能夠遍歷一個字符串路經。路經格式與傳統UNIX文件系統以及Web一致。Merkle DAG的links使遍歷變得很容易。全稱路經在IPFS中的格式是：

*# 格式

/ipfs/<hash-of-object>/<name-path-to-object>

*# 例子

/ipfs/XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x/foo.txt

/ipfs前綴容許只要在掛載點不衝突(掛載點名稱固然是可配置的)的狀況下掛載到一個已存在的系統上。第二個路經組成部分(第一個是IPFS)是一個對象的hash。一般都是這種狀況，由於沒有全局的根。一個根對象可能會有一個不可能完成的任務，就是在分佈式環境(可能還斷開連接)中處理百萬對象的一致性。所以，咱們用地址可尋址來模擬根。經過的hash全部的對象都是可訪問的。這意思是說，給一個路經對象/bar/baz，最後一個對象能夠能夠被全部的訪問的：

/ipfs/<hash-of-foo>/bar/baz

/ipfs/<hash-of-bar>/baz

/ipfs/<hash-of-baz>

3.5.2 本地對象

IPFS客戶端須要一個本地存儲器，一個外部系統能夠爲IPFS管理的對象存儲以及檢索本地原始數據。存儲器的類型根據節點使用案例不一樣而不一樣。在大多數狀況下，這個存儲器只是硬盤空間的一部分（不是被本地的文件系統使用鍵值存儲如leveldb來管理，就是直接被IPFS客戶端管理），在其餘的狀況下，例如非持久性緩存，存儲器就是RAM的一部分。
最終，全部的塊在IPFS中都是可以獲取的到的，塊都存儲在了一些節點的本地存儲器中。當用戶請求一個對象時，這個對象會被查找到並下載下來存儲到本地，至少也是暫時的存儲在本地。這爲一些可配置時間量提供了快速的查找。

3.5.3對象鎖定

但願確保特定對象生存的節點能夠鎖定此對象。這保證此特定對象被保存在了節點的本地存儲器上。也能夠遞歸的進行鎖定全部相關的派生對象。這使全部被指定的對象都保存在本地存儲器上。這對長久保存文件特別有用，包括引用。這也一樣讓IPFS成爲一個links是永久的Web，且對象能夠確保其餘被指定對象的生存。

3.5.4 發佈對象

IPFS是全球分佈的。它設計爲容許成千上萬的用戶文件能夠共同的存在的。DHT使用內容哈希尋址技術，使發佈對象是公平的，安全的，徹底分佈式的。任何人均可以發佈對象，只須要將對象的key加入到DHT中，而且以對象是對等節點的方式加入進去，而後把路徑給其餘的用戶。要注意的是，對象本質上是不可改變的，就像在Git中同樣。新版本的哈希值不一樣，所以是新對象。跟蹤版本則是額外版本對象的工做。

3.5.5 對象級別的加密

IPFS是具有能夠處理對象級別加密操做的。一個已加密的或者已簽名的對象包裝在一個特殊的框架裏，此框架容許加密和驗證原始字節。

type EncryptedObject struct {

Object []bytes // 已加密的原始對象數據

Tag []bytes // 可選擇的加密標識

type SignedObject struct {

Object []bytes // 已簽名的原始對象數據

Signature []bytes // HMAC簽名

PublicKey []multihash // 多重哈希身份鍵值

}

加密操做改變了對象的哈希值，定義一個不一樣的新的對象。IPFS自動的驗證簽名以及使用用戶指定的鑰匙鏈解密數據。加密數據的links也一樣的被保護着，沒有解密祕鑰就沒法遍歷對象。也存在着一種現象，可能父對象使用了一個祕鑰進行了加密，而子對象使用了另外一個祕鑰進行加密或者根本沒有加密。這能夠保證links共享對象安全。

3.6 文件

IPFS在Merkle DAG上還爲模型化版本文件系統定義了一組對象。這個對象模型與Git比較類似：
Block：一個可變大小的數據塊
List：塊或者其餘鏈表的集合
Tree：塊，鏈表，或者其餘樹的集合
Commit：樹在版本歷史記錄中的一個快照
我本來但願使用與Git對象格式一致的模型，但那就必需要分開來引進在分佈式文件系統中有用的某些特徵，如

(a)快速大小查找(總字節大小已經加入到對象中)
(b)大文件的重複刪除(添加到list對象)
(c)commits嵌入到trees中。不過，IPFS文件對象與Git仍是很是相近的，二者之間進行交流都是有可能的。並且，Git的一個系列的對象能夠被引進過來轉換都不會丟失任何的信息。（UNIX文件權限等等）。
標記：下面的文件對象格式使用JSON。注意，雖然IPFS包含了JSON的互相轉換，可是文件對象的結構體仍是使用protobufs的二進制編碼。
3.6.1 文件對象：BLOB
blob對象表明一個文件且包含一個可尋址的數據單元，IPFS的blobs就像Git的blobs或者文件系統數據塊。它們存儲用戶的數據。須要留意的是IPFS文件可使用lists或者blobs來表示。Blobs沒有links。
1

2

3
{

"data": "some data here", // blobs無links

}

3.6.2 文件對象: LIST

List對象表明着由幾個IPFS的blobs鏈接成的大文件或者重複數據刪除文件。Lists包含着有序的blob序列或list對象。從某種程度上而言，IPFS的list函數就像一個間接塊的文件系統。因爲lists能夠包含其餘的lists，那麼包含linked的鏈表和平衡樹的拓撲結構是有可能的。有向圖中相同的節點出如今多個不一樣地方容許在文件中重複數據刪除。固然，循環是不能夠能的，由於是被哈希尋址強制實行的。

{

"data": ["blob", "list", "blob"], //lists有一個對象類型的數組做爲數據

"links": [

{ "hash": "XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x",

"size": 189458 },

{ "hash": "XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5",

"size": 19441 },

{ "hash": "XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z",

"size": 5286 } //在links中lists是沒有名字的

]

}

3.6.3 文件對象：TREE

IPFS中的tree對象與Git中類似，它表明着一個目錄，一個名字到哈希值的映射。哈希值則表示着blobs，lists，其餘的trees，或者commits。注意，傳統路徑的命名早已經被Merkle DAG實現了。

{

"data": ["blob", "list", "blob"],//trees有一個對象類型的數組做爲數據

"links": [

{ "hash": "XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x",

"name": "less", "size": 189458 },

{ "hash": "XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5",

"name": "script", "size": 19441 },

{ "hash": "XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z",

"name": "template", "size": 5286 }//trees是有名字的

]

}

3.6.4 文件對象：COMMIT

IPFS中的commit對象表明任何對象在版本歷史記錄中的一個快照。與Git中相似，可是它可以表示任何類型的對象。它一樣link着發起對象。

3.6.5 版本控制

Commit對象表明着一個對象在歷史版本中的一個特定快照。在兩個不一樣的commit中比較對象（和子對象）能夠揭露出兩個不一樣版本文件系統的區別。只要commit和它全部子對象的引用是可以被訪問的，全部前版本是可獲取的，全部文件系統改變的所有歷史是可訪問的，這就與Merkle DAG對象模型脫離開來了。

Git版本控制工具的全部功能對於IPFS的用戶是可用的。對象模型不徹底一致，但也是可兼容的。這可能

(a)構建一個Git工具版本改形成使用IPFS對象圖，
(b)構建一個掛載FUSE文件系統，掛載一個IPFS的tree做爲Git的倉庫，把Git文件系統的讀/寫轉換爲IPFS的格式。
3.6.6 文件系統路徑
如咱們在Merkle DAG中看到的同樣，IPFS對象可使用字符串路徑API來遍歷。IPFS文件對象是特地設計的，爲了讓掛載IPFS到UNIX文件系統更加簡單。文件對象限制trees沒有數據，爲了使它們能夠表示目錄。Commits能夠以表明目錄的形式出現，也能夠徹底的隱藏在文件系統中。

3.6.7 將文件分隔成LISTS和BLOBS

版本控制和分發大文件其中一個最主要的挑戰是：找到一個正確的方法來將它們分隔成獨立的塊。與其認爲IPFS能夠爲每一個不一樣類型的文件提供正確的分隔方法，不如說IPFS提供瞭如下的幾個可選選擇：
就像在LIBFS[?]中同樣使用Rabin Fingerprints [?]來選擇一個比較合適的塊邊界。
使用rsync[?] rolling-checksum算法，來檢測塊在版本之間的改變。
容許用戶指定專爲特定文件而調整的’快分隔’函數。

3.6.8路徑查找性能

基於路徑的訪問須要遍歷對象圖。獲取每一個對象要求在DHT中查找它們的key，鏈接到對等節點，而後獲取它的塊。這形成至關大的開銷，特別是查找的路徑由不少子路徑組成時。下面的方法能夠減緩開銷：

tree緩存：因爲全部的對象都是哈希尋址的，它們能夠被無限的緩存。另外，trees通常比較小，因此比起blobs，IPFS會優先緩存trees。

flattened trees：對於任何tree，一個特殊的 flattened tree能夠構建一個鏈表，全部對象均可以從這個tree中訪問獲得。在flattened tree中名字就是一個從原始tree分離的路徑，用斜線分隔。
例如，對於上面的ttt111的flattened tree以下：

{

"data":

["tree", "blob", "tree", "list", "blob" "blob"],

"links": [

{ "hash": "<ttt222-hash>", "size": 1234

"name": "ttt222-name" },

{ "hash": "<bbb111-hash>", "size": 123,

"name": "ttt222-name/bbb111-name" },

{ "hash": "<ttt333-hash>", "size": 3456,

"name": "ttt333-name" },

{ "hash": "<lll111-hash>", "size": 587,

"name": "ttt333-name/lll111-name"},

{ "hash": "<bbb222-hash>", "size": 22,

"name": "ttt333-name/lll111-name/bbb222-name" },

{ "hash": "<bbb222-hash>", "size": 22

"name": "bbb222-name" }

] }

3.7 IPNS：命名以及易變狀態

目前爲止，IPFS桟造成了一個對等塊交換組成一個內容可尋址的DAG對象。這提供了發佈和獲取不可改變的對象。這甚至能夠跟蹤這些對象的版本歷史記錄。可是，這裏有一個關鍵成分遺漏了：易變的命名。沒有這個，發送IPFS的links，全部新內容的通訊確定都會有所誤差。如今所需就是能有某些方法能夠獲取相同路徑的的易變狀態。
這值得詳述緣由—若是最終易變數據是必須的—咱們費了很大的力氣構建了一個不可改變的Merkle DAG。就當作IPFS脫離了Merkle DAG的特徵：對象能夠

(a)經過哈希值能夠獲取
(b)完整性的檢查
(c)link其餘的對象
(d)無限緩存。從某種意義上說：
對象就是永恆的
這些就是一個高性能分佈式系統的關鍵特徵，在此係統上跨網絡links之間移動文件是很是昂貴的。對象內容可尋址構建了一個具備如下特色的Web，(a)優秀的寬帶優化(b)不受信任的內容服務(c)永恆的links(d)可以永久備任何對象以及它的引用。

不可變的內容可尋址對象和命名的Merkle DAG，可變指針指向Merkle DAG，實例化了一個出如今不少成功分佈式系統中的二分法。這些系統包括Git的版本控制系統，使用不可變的對象和可變的引用；還有UNIX分佈式的繼承者Plan9[?]文件系統，使用可變的Fossil和不可變的Venti[?]。LBFS[?]一樣使用可變的索引以及不可變的塊。

3.7.1 自我認證名稱

使用SFS[12,11]中的命名方案，給咱們提供了一個種能夠構建自我認證名稱的方法，
在一個加密指定的全局命名空間中，這是可變的。IPFS的方案以下：

1.回想一下在IPFS中：NodeId = hash(node.PubKey)
2.咱們給每一個用戶分配一個可變的命名空間，在此路徑下：/ipns/
3.一個用戶能夠在此路徑下發佈一個用本身私鑰簽名的對象，好比說：/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/
4.當其餘用戶獲取對象時，他們能夠檢測簽名是否與公鑰和NodeId匹配。這個驗證了用戶發佈對象的真實性，達到了可變狀態的獲取。

注意下面的細節：

IPNS(InterPlanetary的命名空間)分開前綴是在可變和不可變的路徑之間創建一個很容易辨認的區別，爲了程序也爲了人類閱讀的便利。
由於這不是一個內容可尋址的對象，因此發佈它就要依靠IPFS中的惟一的可變狀態分配製度，路由系統。過程是(a)首先把此對象作一個常規的不可變IPFS的對象來發布(b)將此對象的哈希值做爲元數據的值發佈到路由系統上：
1
routing.setValue(NodeId, <ns-object-hash>)
發佈的對象中任何links在命令空間中充當子名稱：
1

2

3
/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/

/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/docs

/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/docs/ipfs
通常建議發佈一個commit對象或者其餘對象的時候，要使用歷史版本記錄，由於這樣就用戶就能夠找到以前使用過的名字。不過因爲這並不老是須要的，因此留個用戶本身選擇。
注意當用戶發佈一個對象的時候，他不能使用相同的方式來發布對象。

3.7.2人類友好名稱

IPNS的確是一個分配和在分配名稱的好方法，可是對用戶卻不是十分友好的，由於它使用很長的哈希值做爲名稱，衆所周知這樣的名稱很難被記住。IPNS足夠應付URLs，但對於不少線下的傳輸工做就沒有這麼好用了。所以，IPFS使用下面的技術來增長IPNS的用戶友好度。
對等節點Links
被SFS所鼓舞，用戶能夠直接將其餘用戶的對象link到本身的對象上（命令空間，家目錄等等）。這有一個好處就是建立了一個可信任的Web（也支持老的真實性認證模型）：

# Alice links 到Bob上

ipfs link /<alice-pk-hash>/friends/bob /<bob-pk-hash>

# Eve links 到Alice上

ipfs link /<eve-pk-hash/friends/alice /<alice-pk-hash>

# Eve 也能夠訪問Bob

/<eve-pk-hash/friends/alice/friends/bob

# 訪問Verisign 認證域

/<verisign-pk-hash>/foo.com

DNS TXT IPNS 記錄
若是/ipns/是一個有效的域名稱，IPFS會在DNS TXT記錄中查找關鍵的ipns。IPFS會將查找到的值翻譯爲一個對象的哈希值或者另外一個ipns的路徑：

# DNS TXT 記錄

ipfs.benet.ai. TXT "ipfs=XLF2ipQ4jD3U ..."

# 表現爲符號連接

ln -s /ipns/XLF2ipQ4jD3U /ipns/fs.benet.ai

Proquint 可讀的標識符
老是會有將二進制編碼翻譯成可讀文件的方法。IPNS則支持Proquint[?].。以下：

# proquint語句

/ipns/dahih-dolij-sozuk-vosah-luvar-fuluh

# 分解爲相應的下面形式

/ipns/KhAwNprxYVxKqpDZ

縮短名稱服務
會涌現出不少服務器提供縮短名稱的服務，向用戶提供他們的命名空間。就像咱們如今看到的DNS和Web的URLs：

# 用戶能夠從下面獲取一個link

/ipns/shorten.er/foobar

# 而後放到本身的命名空間

/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm

3.8使用IPFS

IPFS設計爲可使用多種不一樣的方法來使用的，下面就是一些我將會繼續追求的使用方式：

1.做爲一個掛載的全局文件系統，掛載在/ipfs和/ipns下
2.做爲一個掛載的我的同步文件夾，自動的進行版本管理，發佈，以及備份任何的寫入
3.做爲一個加密的文件或者數據共享系統
4.做爲全部軟件的版本包管理者
5.做爲虛擬機器的根文件系統
6.做爲VM的啓動文件系統 (在管理程序下)
7.做爲一個數據庫：應用能夠直接將數據寫入Merkle DAG數據模型中，獲取全部的版本，緩衝，以及IPFS提供的分配
8.做爲一個linked（和加密的）通訊平臺
9.做爲一個爲大文件的完整性檢查CDN（不使用SSL的狀況下）
10.做爲一個加密的CDN
11.在網頁上，做爲一個web CDN
12.做爲一個links永遠存在新的永恆的Web
IPFS實現的目標：
(a)一個IPFS庫能夠導出到你本身應用中使用
(b)命令行工具能夠直接操做對象
(c)使用FUSE[?]或者內核的模型掛載文件系統
4. 將來
IPFS的思想是幾十年成功的分佈式系統的探索和開源的產物。IPFS綜合了不少迄今爲止很成功的系統中優秀的思想。除了BitSwap新協議以外，IPFS最大的特點就是系統的耦合以及設計的綜合性。
IPFS是去中心化網絡基礎設施的一個野心設想，不少不一樣類型的應用均可以創建在IPFS上。最低限度，它能夠用來做爲一個全局的，掛載性，版本控制文件系統和命名空間，或者做爲下一代的文件共享系統。而最好的狀況是，IPFS可讓Web升級一個層次，當發佈一個有價值的信息時，任何感興趣的人均可以進行發佈而不會強迫性的必須只容許發佈機構進行發佈，用戶能夠信任信息的內容，信不信任信息的發送者都是可有可無的，還有一個特色就是，一些重要但很老的文件也不會丟失。IPFS期待着帶咱們進入到一個永恆Wdb的世界。
5. 感謝
IPFS是一個不少很棒的主意以及系統的綜合體。沒有站在巨人的肩膀上，IPFS也不可能勇於有一個這麼有野心的目標。我的感謝參與這些主意長期討論的人：David Dalrymple, Joe Zimmerman, and Ali Yahya，特別是：揭開Merkle DAG的整體架構(David, Joe),滾動哈希阻塞(David), s/kademlia sybill 保護(David, Ali)，特別感謝David Mazieres,爲他以前很是聰明的主意。
6.引用備忘錄

7.引用
[1].I. Baumgart and S. Mies. S/kademlia:一個安全的基於祕鑰路由的可行方法。2007年國際會議，第2卷，1-8頁，在《併發和分佈式系統》中。IEEE，2007年。 [2].I. BitTorrent.Bittorrent和Attorrent軟件超過1億5000萬用戶里程碑，Jan。2012 [3].B. Cohen.激勵機制在bittorrent中創建了健壯性。在《對等系統經濟研討會》中，第6卷，68-72頁，2003年。 [4].J. Dean and S. Ghemawat. Leveldb - 一個快速和輕量級鍵值存儲數據庫，谷歌提供，2011年。 [5].M. J. Freedman, E. Freudenthal, and D. Mazieres. Coral民主內容發佈。在NSDI中，第4卷，18-18頁，2004年。 [6].J. H. Howard, M. L. Kazar, S. G. Menees, D. A,Nichols, M. Satyanarayanan, R. N. Sidebotham, 以及M. J. West.分佈式文件系統的規模和性能。「ACM 電腦系統上的交易（TOCS）」 6(1):51-81, 1988年