IPFS - 可快速索引的版本化的點(diǎn)對(duì)點(diǎn)文件系統(tǒng)

作者： Juan Benet (juan@benet.ai)
譯者： 郭光華(gavin@8btc.com)

摘要

星際文件系統(tǒng)是一種點(diǎn)對(duì)點(diǎn)的分布式文件系統(tǒng)， 旨在連接所有有相同的文件系統(tǒng)的計(jì)算機(jī)設(shè)備。在某些方面， IPFS類似于web, 但web 是中心化的，而IPFS是一個(gè)單一的Bittorrent 群集， 用git 倉(cāng)庫(kù)分布式存儲(chǔ)。換句話說(shuō)， IPFS 提供了高吞吐量的內(nèi)容尋址塊存儲(chǔ)模型， 具有內(nèi)容尋址的超鏈接。這形成了一個(gè)廣義的Merkle DAG 數(shù)據(jù)結(jié)構(gòu)，可以用這個(gè)數(shù)據(jù)結(jié)構(gòu)構(gòu)建版本文件系統(tǒng)，區(qū)塊鏈，甚至是永久性網(wǎng)站。。IPFS 結(jié)合了分布式哈希表， 帶有激勵(lì)機(jī)制的塊交換和自我認(rèn)證命名空間。IPFS 沒(méi)有單故障點(diǎn)， 節(jié)點(diǎn)不需要相互信任。

1. 介紹

在全球分布式文件系統(tǒng)這領(lǐng)域， 已經(jīng)有許多人的嘗試。一些系統(tǒng)已經(jīng)取得了重大的成功， 而很多卻完全失敗了。在學(xué)術(shù)嘗試中， AFS【6】就是成功的例子，如今已經(jīng)得到廣泛的應(yīng)用， 然而，其他的【7， ？】卻沒(méi)有得到相同的結(jié)果。在學(xué)術(shù)界之外，應(yīng)用最廣泛的是面向音視頻媒體的點(diǎn)對(duì)點(diǎn)文件共享系統(tǒng)。 最值得注意的是， Napster, KaZaA 和BitTorrent[2]部署的文件分發(fā)系統(tǒng)支持1億用戶的同時(shí)在線。即使在今天， BitTorrent 也維持著每天千萬(wàn)節(jié)點(diǎn)的活躍數(shù)。 基于這些學(xué)術(shù)文件系統(tǒng)理論而實(shí)現(xiàn)的應(yīng)用程序有很多的用戶量， 然而，這些系統(tǒng)理論是在應(yīng)用層，而沒(méi)有放在基礎(chǔ)層。以致沒(méi)有出現(xiàn)通用的文件系統(tǒng)基礎(chǔ)框架， 給全球提供低延遲的分發(fā)。

也許是因?yàn)镠TTP這樣“足夠好“的系統(tǒng)已經(jīng)存在。到目前為止，HTTP已經(jīng)作為“分布式文件系統(tǒng)“的協(xié)議，并且已經(jīng)大量部署，再與瀏覽器相結(jié)合，具有巨大的技術(shù)和社會(huì)影響力。在現(xiàn)在， 它已經(jīng)成為互聯(lián)網(wǎng)傳輸文件的事實(shí)標(biāo)準(zhǔn)。然而，他沒(méi)有采用最近15年的發(fā)明的數(shù)十種先進(jìn)的文件分發(fā)技術(shù)。 從一方面講， 由于向后兼容的限制 和 當(dāng)前新模式的投入， 不斷發(fā)展http web 的基礎(chǔ)設(shè)施幾乎是不可能的。但從一個(gè)角度看， 從http 出現(xiàn)以來(lái)， 已經(jīng)有許多新協(xié)議出現(xiàn)并被廣泛使用。升級(jí)http協(xié)議雖然能引入新功能和加強(qiáng)當(dāng)前http協(xié)議，但會(huì)降低用戶的體驗(yàn)。

有些行業(yè)已經(jīng)擺脫使用HTTP 這么久， 因?yàn)橐苿?dòng)小文件相對(duì)便宜，即使對(duì)擁有大流量的小組織也是如此。但是，隨著新的挑戰(zhàn)，我們正在進(jìn)入數(shù)據(jù)分發(fā)的新紀(jì)元。

• （a）托管和分發(fā)PB級(jí)數(shù)據(jù)集，
• （b）跨組織的大數(shù)據(jù)計(jì)算，
• （c）大批量的高清晰度按需或?qū)崟r(shí)媒體流，
• （d）大規(guī)模數(shù)據(jù)集的版本化和鏈接，
• （e）防止意外丟失重要文件等。其中許多可以歸結(jié)為“大量數(shù)據(jù)，無(wú)處不在”。由于關(guān)鍵功能和帶寬問(wèn)題，我們已經(jīng)為不同的數(shù)據(jù)放棄了HTTP 分銷協(xié)議。下一步是使它們成為web自己的一部分。

正交于有效的數(shù)據(jù)分發(fā)，版本控制系統(tǒng)，已經(jīng)設(shè)法開(kāi)發(fā)重要的數(shù)據(jù)協(xié)作工作流程。Git是分布式源代碼版本控制系統(tǒng)，開(kāi)發(fā)了許多有用的方法來(lái)建模和實(shí)現(xiàn)分布式數(shù)據(jù)操作。Git工具鏈提供了靈活的版本控制功能，這正是大量的文件分發(fā)系統(tǒng)所嚴(yán)重缺乏的。由Git啟發(fā)的新解決方案正在出現(xiàn)，如Camlistore [？]，個(gè)人文件存儲(chǔ)系統(tǒng)，Dat [？]數(shù)據(jù)協(xié)作工具鏈和數(shù)據(jù)集包管理器。Git已經(jīng)影響了分布式文件系統(tǒng)設(shè)計(jì)[9]，因?yàn)槠鋬?nèi)容涉及到Merkle DAG數(shù)據(jù)模型，能夠?qū)崿F(xiàn)強(qiáng)大的文件分發(fā)策略。還有待探討的是，這種數(shù)據(jù)結(jié)構(gòu)如何影響面向高吞吐量的文件系統(tǒng)的設(shè)計(jì)，以及如何升級(jí)Web本身。

本文介紹了IPFS，一種新穎的對(duì)等版本控制的文件系統(tǒng)，旨在調(diào)和這些問(wèn)題。 IPFS綜合了許多以前成功的系統(tǒng)的優(yōu)點(diǎn)。 IPFS產(chǎn)生了突出的效果， 甚至比參考的這些系統(tǒng)的總和還要好。IPFS的核心原則是將所有數(shù)據(jù)建模為同一Merkle DAG的一部分。

2.1 分布式哈希表(DHT)

分布式散列表（DHT）被廣泛用于協(xié)調(diào)和維護(hù)關(guān)于對(duì)等系統(tǒng)的元數(shù)據(jù)。比如，MainlineDHT 是一個(gè)去中心化哈希表，他可追蹤查找所有的對(duì)等節(jié)點(diǎn)。

2.1.1 Kademlia DHT

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

• 1.通過(guò)大量網(wǎng)絡(luò)進(jìn)行高效查詢：查詢平均聯(lián)系人O(log2N)節(jié)點(diǎn)。 （例如，20跳10萬(wàn)個(gè)節(jié)點(diǎn)的網(wǎng)絡(luò)）
• 2.低協(xié)調(diào)開(kāi)銷：優(yōu)化數(shù)量的控制消息發(fā)送到其他節(jié)點(diǎn)。
• 3.抵抗各種攻擊，喜歡長(zhǎng)壽節(jié)點(diǎn)。
• 4.在對(duì)等應(yīng)用中廣泛使用，包括Gnutella和BitTorrent，形成了超過(guò)2000萬(wàn)個(gè)節(jié)點(diǎn)的網(wǎng)絡(luò)[16]。

2.1.2 Coral DSHT

雖然一些對(duì)等文件系統(tǒng)直接在DHT中存儲(chǔ)數(shù)據(jù)塊，這種“數(shù)據(jù)存儲(chǔ)在不需要的節(jié)點(diǎn)會(huì)亂費(fèi)存儲(chǔ)和帶寬”[5]。Coral DSHT擴(kuò)展了Kademlia三個(gè)特別重要的方式：

• 1.Kademlia在ids為“最近”（使用XOR-distance）的關(guān)鍵節(jié)點(diǎn)中存儲(chǔ)值。這不考 慮應(yīng)用程序數(shù)據(jù)的局部性，忽略“遠(yuǎn)”可能已經(jīng)擁有數(shù)據(jù)的節(jié)點(diǎn)，并強(qiáng)制“最近”節(jié)點(diǎn)存儲(chǔ)它，無(wú)論它們是否需要。這浪費(fèi)了大量的存儲(chǔ)和帶寬。相反，Coral 存儲(chǔ)了地址， 該地址的對(duì)等節(jié)點(diǎn)可以提供相應(yīng)的數(shù)據(jù)塊。
• 2.Coral將DHT API從get_value(key)換成了get_any_values(key)（DSHT中的“sloppy”）中。這仍然是因?yàn)镃oral用戶只需要一個(gè)（工作）的對(duì)等體，而不是完整的列表。作為回報(bào)，Coral可以僅將子集分配到“最近”的節(jié)點(diǎn)，避免熱點(diǎn)（當(dāng)密鑰變得流行時(shí)，重載所有最近的節(jié)點(diǎn)）。
• 3.另外，Coral根據(jù)區(qū)域和大小組織了一個(gè)稱為群集的獨(dú)立DSHT層次結(jié)構(gòu)。這使得節(jié)點(diǎn)首先查詢其區(qū)域中的對(duì)等體，“查找附近的數(shù)據(jù)而不查詢遠(yuǎn)程節(jié)點(diǎn)”[5]并大大減少查找的延遲。

2.1.3 S/Kademlia DHT

S/Kademlia[1] 擴(kuò)展了Kademlia, 用于防止惡意的攻擊。有如下兩方面的方法：

1.S/Kad 提供了方案來(lái)保證NodeId的生成已經(jīng)防止Sybill攻擊。它需要節(jié)點(diǎn)產(chǎn)生PKI公私鑰對(duì)。從中導(dǎo)出他們的身份，并彼此間簽名。一個(gè)方案使用POW工作量證明，使得生成Sybills成本高昂。

2.S/Kad 節(jié)點(diǎn)在不相交的路徑上查找直， 即使網(wǎng)絡(luò)中存在大量的不誠(chéng)實(shí)節(jié)點(diǎn)，也能確保誠(chéng)實(shí)節(jié)點(diǎn)可以互相鏈接。即使網(wǎng)絡(luò)中存在一半的不誠(chéng)實(shí)節(jié)點(diǎn)，S/Kad 也能達(dá)到85%的成功率。

2.2 塊交換 - BitTorrent

BitTorrent[3] 是一個(gè)廣泛成功應(yīng)用的點(diǎn)對(duì)點(diǎn)共享文件系統(tǒng)，它可以在存在不信任的對(duì)等節(jié)點(diǎn)（群集）的協(xié)作網(wǎng)絡(luò)中分發(fā)各自的文件數(shù)據(jù)片。從BitTorrent和它的生態(tài)系統(tǒng)的關(guān)鍵特征， IPFS得到啟示如下：

• 1.BitTorrent的數(shù)據(jù)交換協(xié)議使用了一種bit-for-tat的激勵(lì)策略， 可以獎(jiǎng)勵(lì)對(duì)其他方面做貢獻(xiàn)的節(jié)點(diǎn)，懲罰只榨取對(duì)方資源的節(jié)點(diǎn)。
• 2.BitTorrent對(duì)等體跟蹤文件的可用性，優(yōu)先發(fā)送稀有片段。這減輕了seeds節(jié)點(diǎn)的負(fù)擔(dān)， 讓non-seeds節(jié)點(diǎn)有能力互相交易。
• 3.對(duì)于一些剝削帶寬共享策略， BitTorrent的標(biāo)準(zhǔn)tit-for-tat策略是非常脆弱的。 然而，PropShare[8]是一種不同的對(duì)等帶寬分配策略， 可以更好的抵制剝削戰(zhàn)略， 提高群集的表現(xiàn)。

2.3. 版本控制系統(tǒng)- Git

版本控制系統(tǒng)提供了對(duì)隨時(shí)間變化的文件進(jìn)行建模的設(shè)施，并有效地分發(fā)不同的版本。流行版本控制系統(tǒng)Git提供了強(qiáng)大的Merkle DAG對(duì)象模型，以分布式友好的方式捕獲對(duì)文件系統(tǒng)樹(shù)的更改。

• 1.不可更改的對(duì)象表示文件（blob），目錄（樹(shù)）和更改（提交）。
• 2.通過(guò)加密hash對(duì)象的內(nèi)容，讓對(duì)象可尋址。
• 3.鏈接到其他對(duì)象是嵌入的，形成一個(gè)Merkle DAG。這提供了很多有用的完整和work-flow屬性。
• 4.很多版本元數(shù)據(jù)（分支，標(biāo)示等等）都只是指針引用，因此創(chuàng)建和更新的代價(jià)都小。
• 5.版本改變只是更新引用或者添加對(duì)象。
• 6.分布式版本改變對(duì)其他用戶而言只是轉(zhuǎn)移對(duì)象和更新遠(yuǎn)程引用。

2.4 自我認(rèn)證認(rèn)文件系統(tǒng)-SFS

SFS [ 12，11 ]提出了兩個(gè)引人注目的實(shí)現(xiàn)（a）分布式信任鏈，和（b）平等共享的全局命名空間。SFS引入了一種自我建構(gòu)技術(shù)—注冊(cè)文件：尋址遠(yuǎn)程文件系統(tǒng)使用以下格式：

1 2 3

/sfs/<Location>:<HostID> Location:代表的是服務(wù)網(wǎng)絡(luò)地方 HostID = hash(public_key || Location)

因此SFS文件系統(tǒng)的名字認(rèn)證了它的服務(wù)，用戶可以通過(guò)服務(wù)提供的公鑰來(lái)驗(yàn)證，協(xié)商一個(gè)共享的私鑰，保證所有的通信。所有的SFS實(shí)例都共享了一個(gè)全局的命名空間，這個(gè)命名空間的名稱分配是加密的，不被任何中心化的body控制。

3. IPFS設(shè)計(jì)

IPFS是一個(gè)分布式文件系統(tǒng)，它綜合了以前的對(duì)等系統(tǒng)的成功想法，包括DHT，BitTorrent，Git和SFS。 IPFS的貢獻(xiàn)是簡(jiǎn)化，發(fā)展和將成熟的技術(shù)連接成一個(gè)單一的內(nèi)聚系統(tǒng)，大于其部分的總和。 IPFS提供了編寫(xiě)和部署應(yīng)用程序的新平臺(tái)，以及一個(gè)新的分發(fā)系統(tǒng)版本化大數(shù)據(jù)。 IPFS甚至可以演進(jìn)網(wǎng)絡(luò)本身。
IPFS是點(diǎn)對(duì)點(diǎn)的;沒(méi)有節(jié)點(diǎn)是特權(quán)的。 IPFS節(jié)點(diǎn)將IPFS對(duì)象存儲(chǔ)在本地存儲(chǔ)中。節(jié)點(diǎn)彼此連接并傳輸對(duì)象。這些對(duì)象表示文件和其他數(shù)據(jù)結(jié)構(gòu)。 IPFS協(xié)議分為一組負(fù)責(zé)不同功能的子協(xié)議：
1. 身份 - 管理節(jié)點(diǎn)身份生成和驗(yàn)證。描述在3.1節(jié)。
2.網(wǎng)絡(luò) - 管理與其他對(duì)等體的連接，使用各種底層網(wǎng)絡(luò)協(xié)議。可配置的。詳見(jiàn)3.2節(jié)。
3.路由 - 維護(hù)信息以定位特定的對(duì)等體和對(duì)象。響應(yīng)本地和遠(yuǎn)程查詢。默認(rèn)為DH??T，但可更換。在3.3節(jié)描述。
4.交換 - 一種支持有效塊分配的新型塊交換協(xié)議（BitSwap）。模擬市場(chǎng)，弱化數(shù)據(jù)復(fù)制。貿(mào)易策略可替換。描述在3.4節(jié)。
5.對(duì)象 - 具有鏈接的內(nèi)容尋址不可更改對(duì)象的Merkle DAG。用于表示任意數(shù)據(jù)結(jié)構(gòu)，例如文件層次和通信系統(tǒng)。詳見(jiàn)第3.5節(jié)。
6.文件 - 由Git啟發(fā)的版本化文件系統(tǒng)層次結(jié)構(gòu)。詳見(jiàn)3.6節(jié)。
7.命名 - 自我認(rèn)證的可變名稱系統(tǒng)。詳見(jiàn)3.7節(jié)。
這些子系統(tǒng)不是獨(dú)立的;它們是集成在一起，互相利用各自的屬性。但是，分開(kāi)描述它們是有用的，從下到上構(gòu)建協(xié)議棧。符號(hào)：Go語(yǔ)言中指定了以下數(shù)據(jù)結(jié)構(gòu)和功能

3.1 身份

節(jié)點(diǎn)由NodeId標(biāo)識(shí)，這是使用S / Kademlia的靜態(tài)加密難題[1]創(chuàng)建的公鑰的密碼散列。節(jié)點(diǎn)存儲(chǔ)其公私鑰（用密碼加密）。用戶可以在每次啟動(dòng)時(shí)自由地設(shè)置一個(gè)“新”節(jié)點(diǎn)身份，盡管這會(huì)損失積累的網(wǎng)絡(luò)利益。激勵(lì)節(jié)點(diǎn)保持不變。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

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)

首次連接時(shí)，對(duì)等體交換公鑰，并檢查：hash（other.PublicKey）等于other.NodeId。如果沒(méi)有，則連接被終止
關(guān)于加密函數(shù)的注意事項(xiàng)：
IPFS不是將系統(tǒng)鎖定到一組特定的功能選擇，而是支持自我描述的值。哈希摘要值以多重哈希格式存儲(chǔ)，其包括指定使用的哈希函數(shù)的頭和以字節(jié)為單位的摘要長(zhǎng)度。例如：

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

這允許系統(tǒng)

• （a）選擇最佳功能用例（例如，更強(qiáng)的安全性與更快的性能），
• （b）隨著功能選擇的變化而演變。自描述值允許兼容使用不同的參數(shù)選擇。

3.2 網(wǎng)絡(luò)

IPFS節(jié)點(diǎn)與數(shù)百個(gè)其他節(jié)點(diǎn)進(jìn)行定期通信網(wǎng)絡(luò)中的節(jié)點(diǎn)，可能跨越廣域網(wǎng)絡(luò)。IPFS網(wǎng)絡(luò)堆棧功能：

• 傳輸層： IPFS可以使用任何傳輸協(xié)議，并且最適合WebRTC DataChannels [？]（用于瀏覽器連接）或uTP（LEDBAT [14]）。
• 可靠性： 如果底層網(wǎng)絡(luò)不提供可靠性，IPFS可使用uTP（LEDBAT [14]）或SCTP [15]來(lái)提供??可靠性。
• 可連接性：IPFS還可以使用ICE NAT穿墻打洞技術(shù)[13]。
• 完整性：可以使用哈希校驗(yàn)和來(lái)檢查郵件的完整性。
• 可驗(yàn)證性：可以使用發(fā)送者的公鑰使用HMAC來(lái)檢查消息的真實(shí)性。

3.2.1對(duì)等節(jié)點(diǎn)尋址注意事項(xiàng)：

IPFS可以使用任何網(wǎng)絡(luò); 但它不承擔(dān)對(duì)IP的獲取以及不直接依賴于ip層。這允許在覆蓋網(wǎng)絡(luò)中使用IPFS。
IPFS將地址存儲(chǔ)為多層地址，這個(gè)多層地址是由字節(jié)字符串組成的， 以便于給底層網(wǎng)絡(luò)使用。多層地址提供了一種方式來(lái)表示地址及其協(xié)議，可以封裝成好解析的格式。例如：

1 2 3 4

# 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節(jié)點(diǎn)需要一個(gè)路由系統(tǒng)， 這個(gè)路由系統(tǒng)可用于查找：

• （a）其他同伴的網(wǎng)絡(luò)地址，
• （b）專門(mén)用于服務(wù)特定對(duì)象的對(duì)等節(jié)點(diǎn)。

IPFS使用基于S / Kademlia和Coral的DSHT，在2.1節(jié)中具體介紹過(guò)。在對(duì)象大小和使用模式方面， IPFS 類似于Coral[5] 和Mainline[16], 因此，IPFS DHT根據(jù)其大小對(duì)存儲(chǔ)的值進(jìn)行區(qū)分。小的值（等于或小于1KB）直接存儲(chǔ)在DHT上。對(duì)于更大的值，DHT只存儲(chǔ)值索引，這個(gè)索引就是一個(gè)對(duì)等節(jié)點(diǎn)的NodeId, 該對(duì)等節(jié)點(diǎn)可以提供對(duì)該類型的值的具體服務(wù)。
DSHT的接口如下：

1 2 3 4 5 6 7

type IPFSRouting interface { FindPeer(node NodeId) // 獲取特定NodeId的網(wǎng)絡(luò)地址。 SetValue(key []bytes, value []bytes) // 往DHT存儲(chǔ)一個(gè)小的元數(shù)據(jù)。 GetValue(key []bytes) // 從DHT獲取元數(shù)據(jù)。 ProvideValue(key Multihash) // 聲明這個(gè)節(jié)點(diǎn)可一個(gè)提供一個(gè)大的數(shù)據(jù)。 FindValuePeers(key Multihash, min int) // 獲取服務(wù)于該大數(shù)據(jù)的節(jié)點(diǎn)。 }

注意：不同的用例將要求基本不同的路由系統(tǒng)（例如廣域網(wǎng)中使用DHT，局域網(wǎng)中使用靜態(tài)HT）。因此，IPFS路由系統(tǒng)可以根據(jù)用戶的需求替換的。只要使用上面的接口就可以了，系統(tǒng)都能繼續(xù)正常運(yùn)行。

3.4塊交換 - BitSwap協(xié)議

IPFS 中的BitSwap協(xié)議受到BitTorrent 的啟發(fā)，通過(guò)對(duì)等節(jié)點(diǎn)間交換數(shù)據(jù)塊來(lái)分發(fā)數(shù)據(jù)的。像BT一樣， 每個(gè)對(duì)等節(jié)點(diǎn)在下載的同時(shí)不斷向其他對(duì)等節(jié)點(diǎn)上傳已下載的數(shù)據(jù)。和BT協(xié)議不同的是， BitSwap 不局限于一個(gè)torrent文件中的數(shù)據(jù)塊。BitSwap 協(xié)議中存在一個(gè)永久的市場(chǎng)。 這個(gè)市場(chǎng)包括各個(gè)節(jié)點(diǎn)想要獲取的所有塊數(shù)據(jù)。而不管這些塊是哪些如.torrent文件中的一部分。這些快數(shù)據(jù)可能來(lái)自文件系統(tǒng)中完全不相關(guān)的文件。 這個(gè)市場(chǎng)是由所有的節(jié)點(diǎn)組成的。

雖然易貨系統(tǒng)的概念意味著可以創(chuàng)建虛擬貨幣，但這將需要一個(gè)全局分類賬本來(lái)跟蹤貨幣的所有權(quán)和轉(zhuǎn)移。這可以實(shí)施為BitSwap策略，并將在未來(lái)的論文中探討。

在基本情況下，BitSwap節(jié)點(diǎn)必須以塊的形式彼此提供直接的值。只有當(dāng)跨節(jié)點(diǎn)的塊的分布是互補(bǔ)的時(shí)候，各取所需的時(shí)候，這才會(huì)工作的很好。 通常情況并非如此，在某些情況下，節(jié)點(diǎn)必須為自己的塊而工作。 在節(jié)點(diǎn)沒(méi)有其對(duì)等節(jié)點(diǎn)所需的（或根本沒(méi)有的）情況下，它會(huì)更低的優(yōu)先級(jí)去尋找對(duì)等節(jié)點(diǎn)想要的塊。這會(huì)激勵(lì)節(jié)點(diǎn)去緩存和傳播稀有片段， 即使節(jié)點(diǎn)對(duì)這些片段不感興趣。

3.4.1 - BitSwap 信用

這個(gè)協(xié)議必須帶有激勵(lì)機(jī)制， 去激勵(lì)節(jié)點(diǎn)去seed 其他節(jié)點(diǎn)所需要的塊，而它們本身是不需要這些塊的。 因此， BitSwap的節(jié)點(diǎn)很積極去給對(duì)端節(jié)點(diǎn)發(fā)送塊，期待獲得報(bào)酬。但必須防止水蛭攻擊（空負(fù)載節(jié)點(diǎn)從不共享塊），一個(gè)簡(jiǎn)單的類似信用的系統(tǒng)解決了這些問(wèn)題：

• 1， 對(duì)等節(jié)點(diǎn)間會(huì)追蹤他們的平衡（通過(guò)字節(jié)認(rèn)證的方式）。
• 2， 隨著債務(wù)增加而概率降低，對(duì)等者概率的向債務(wù)人發(fā)送塊。

注意的是，如果節(jié)點(diǎn)決定不發(fā)送到對(duì)等體，節(jié)點(diǎn)隨后忽略對(duì)等體的ignore_cooldown超時(shí)。 這樣可以防止發(fā)送者嘗試多次發(fā)送（洪水攻擊） （BitSwap默認(rèn)是10秒）。

3.4.2 BitSwap的策略

BitSwap 對(duì)等節(jié)點(diǎn)采用很多不同的策略，這些策略對(duì)整個(gè)數(shù)據(jù)塊的交換執(zhí)行力產(chǎn)生了不同的巨大影響。在BT 中， 標(biāo)準(zhǔn)策略是明確規(guī)定的（tit-for-tat），其他不同的策略也已經(jīng)被實(shí)施，從BitTyrant [8]（盡可能分享）到BitThief [8]（利用一個(gè)漏洞，從不共享），到PropShare [8]（按比例分享）。BitSwap 對(duì)等體可以類似地實(shí)現(xiàn)一系列的策略（良好和惡意）。對(duì)于功能的選擇，應(yīng)該瞄準(zhǔn)：

• 1.為整個(gè)交易和節(jié)點(diǎn)最大化交易能力。
• 2.為了防止空負(fù)載節(jié)點(diǎn)利用和損害交易。
• 3.高效抵制未知策略。
• 4.對(duì)可信任的對(duì)等節(jié)點(diǎn)更寬容。

探索這些策略的空白是未來(lái)的事情。在實(shí)踐中使用的一個(gè)選擇性功能是sigmoid，根據(jù)負(fù)債比例進(jìn)行縮放：
讓負(fù)債比例在一個(gè)節(jié)點(diǎn)和它對(duì)等節(jié)點(diǎn)之間：

1	r = bytes_sent / bytes_recv + 1

根據(jù)r，發(fā)送到負(fù)債節(jié)點(diǎn)的概率為：

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

?

正如你看到的圖片1，當(dāng)節(jié)點(diǎn)負(fù)債比例超過(guò)節(jié)點(diǎn)已建立信貸的兩倍，發(fā)送到負(fù)債節(jié)點(diǎn)的概率就會(huì)急速下降。

圖片1 當(dāng)r增加時(shí)發(fā)送的概率

負(fù)債比是信任的衡量標(biāo)準(zhǔn)：對(duì)于之前成功的互換過(guò)很多數(shù)據(jù)的節(jié)點(diǎn)會(huì)寬容債務(wù)，而對(duì)不信任不了解的節(jié)點(diǎn)會(huì)嚴(yán)格很多。這個(gè)(a)給與那些創(chuàng)造很多節(jié)點(diǎn)的攻擊者（sybill 攻擊）一個(gè)障礙。(b)保護(hù)了之前成功交易節(jié)點(diǎn)之間的關(guān)系，即使這個(gè)節(jié)點(diǎn)暫時(shí)無(wú)法提供數(shù)據(jù)。(c)最終阻塞那些關(guān)系已經(jīng)惡化的節(jié)點(diǎn)之間的通信，直到他們被再次證明。

3.4.3 BitSwap 賬本

BitSwap節(jié)點(diǎn)保存了一個(gè)記錄與所有其他節(jié)點(diǎn)之間交易的賬本。這個(gè)可以讓節(jié)點(diǎn)追蹤歷史記錄以及避免被篡改。當(dāng)激活了一個(gè)鏈接，BitSwap節(jié)點(diǎn)就會(huì)互換它們賬本信息。如果這些賬本信息并不完全相同，分類賬本將會(huì)重新初始化， 那些應(yīng)計(jì)信貸和債務(wù)會(huì)丟失。 惡意節(jié)點(diǎn)會(huì)有意去失去“這些“賬本， 從而期望清除自己的債務(wù)。節(jié)點(diǎn)是不太可能在失去了應(yīng)計(jì)信托的情況下還能累積足夠的債務(wù)去授權(quán)認(rèn)證?；锇楣?jié)點(diǎn)可以自由的將其視為不當(dāng)行為， 拒絕交易。

1 2 3 4 5 6 7

type Ledger struct { owner NodeId partner NodeId bytes_sent int bytes_recv int timestamp Timestamp }

節(jié)點(diǎn)可以自由的保留分布式賬本歷史，這不需要正確的操作，因?yàn)橹挥挟?dāng)前的分類賬本條目是有用的。節(jié)點(diǎn)也可以根據(jù)需要自由收集分布式帳本，從不太有用的分布式帳開(kāi)始：老（其他對(duì)等節(jié)點(diǎn)可能不存在）和小。

3.4.4 BitSwap 詳解

BitSwap 節(jié)點(diǎn)有以下簡(jiǎn)單的協(xié)議。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

// 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); }

?

對(duì)等連接的生命周期草圖：

• 1.Open: 對(duì)等節(jié)點(diǎn)間發(fā)送ledgers 直到他們同意。
• 2.Sending: 對(duì)等節(jié)點(diǎn)間交換want_lists 和blocks。
• 3.Close: 對(duì)等節(jié)點(diǎn)斷開(kāi)鏈接。
• 4.Ignored: （特殊）對(duì)等體被忽略（等待時(shí)間的超時(shí)）如果節(jié)點(diǎn)采用防止發(fā)送策略。
  Peer.open(NodeId, Ledger).
  當(dāng)發(fā)生鏈接的時(shí)候，節(jié)點(diǎn)會(huì)初始化鏈接的賬本，要么保存一個(gè)份鏈接過(guò)去的賬本，要么創(chuàng)建一個(gè)新的被清零的賬本。然后，發(fā)送一個(gè)攜帶賬本的open信息給對(duì)等節(jié)點(diǎn)。
  接收到一個(gè)open信息之后，對(duì)等節(jié)點(diǎn)可以選擇是否接受此鏈接。如果，根據(jù)接收者的賬本，發(fā)送者是一個(gè)不可信的代理（傳輸?shù)陀诹慊蛘哂泻艽蟮奈磧斶€的債務(wù)），接收者可能會(huì)選擇忽略這個(gè)請(qǐng)求。忽略請(qǐng)求是ignore_cooldown超時(shí)來(lái)概率性實(shí)現(xiàn)的，為了讓錯(cuò)誤能夠有時(shí)間改正和攻擊者被挫敗。
  如果鏈接成功，接收者用本地賬本來(lái)初始化一個(gè)Peer對(duì)象以及設(shè)置last_seen時(shí)間戳。然后，它會(huì)將接受到的賬本與自己的賬本進(jìn)行比較。如果兩個(gè)賬本完全一樣，那么這個(gè)鏈接就被Open，如果賬本并不完全一致，那么此節(jié)點(diǎn)會(huì)創(chuàng)建一個(gè)新的被清零的賬本并且會(huì)發(fā)送此賬本。
  Peer.send_want_list(WantList)
  當(dāng)鏈接已經(jīng)Open的時(shí)候，節(jié)點(diǎn)會(huì)廣發(fā)它們的want_list給所有已經(jīng)鏈接的對(duì)等節(jié)點(diǎn)。這個(gè)是在(a)open鏈接后(b)隨機(jī)間歇超時(shí)后(c)want_list改變后(d)接收到一個(gè)新的塊之后完成的。
  當(dāng)接收到一個(gè)want_list之后，節(jié)點(diǎn)會(huì)存儲(chǔ)它。然后，會(huì)檢查自己是否擁有任何它想要的塊。如果有，會(huì)根據(jù)上面提到的BitSwap策略來(lái)將want_list所需要的塊發(fā)送出去。
  Peer.send_block(Block)
  發(fā)送一個(gè)塊是直接了當(dāng)?shù)?。?jié)點(diǎn)只是傳輸數(shù)據(jù)塊。當(dāng)接收到了所有數(shù)據(jù)的時(shí)候，接收者會(huì)計(jì)算多重hash校驗(yàn)和來(lái)驗(yàn)證它是否是自己所需數(shù)據(jù)，然后發(fā)送確認(rèn)信息。
  在完成一個(gè)正確的塊傳輸之后，接受者會(huì)將此塊從need_list一到have_list,最后接收者和發(fā)送者都會(huì)更新它們的賬本來(lái)反映出傳輸?shù)念~外數(shù)據(jù)字節(jié)數(shù)。
  如果一個(gè)傳輸驗(yàn)證失敗了，發(fā)送者要么會(huì)出故障要么會(huì)攻擊接收者，接收者可以選擇拒絕后面的交易。注意，BitSwap是期望能夠在一個(gè)可靠的傳輸通道上進(jìn)行操作的，所以傳輸錯(cuò)誤（可能會(huì)引起一個(gè)對(duì)誠(chéng)實(shí)發(fā)送者錯(cuò)誤的懲罰）是期望在數(shù)據(jù)發(fā)送給BitSwap之前能夠被捕捉到。
  Peer.close(Bool)
  傳給close最后的一個(gè)參數(shù)，代表close鏈接是否是發(fā)送者的意愿。如果參數(shù)值為false,接收者可能會(huì)立即重新open鏈接，這避免鏈過(guò)早的close鏈接。
  一個(gè)對(duì)等節(jié)點(diǎn)close鏈接發(fā)生在下面兩種情況下：
• silence_wait超時(shí)已經(jīng)過(guò)期，并且沒(méi)有接收到來(lái)自于對(duì)等節(jié)點(diǎn)的任何信息（BitSwap默認(rèn)使用30秒），節(jié)點(diǎn)會(huì)發(fā)送Peer.close(false)。

在節(jié)點(diǎn)退出和BitSwap關(guān)閉的時(shí)候，節(jié)點(diǎn)會(huì)發(fā)送Peer.close(true).
接收到close消息之后，接收者和發(fā)送者會(huì)斷開(kāi)鏈接，清除所有被存儲(chǔ)的狀態(tài)。賬本可能會(huì)被保存下來(lái)為了以后的便利，當(dāng)然，只有在被認(rèn)為賬本以后會(huì)有用時(shí)才會(huì)被保存下來(lái)。
注意點(diǎn)：
非open信息在一個(gè)不活躍的連接上應(yīng)該是被忽略的。在發(fā)送send_block信息時(shí)，接收者應(yīng)該檢查這個(gè)塊，看它是否是自己所需的，并且是否是正確的，如果是，就使用此塊?？傊?#xff0c;所有不規(guī)則的信息都會(huì)讓接收者觸發(fā)一個(gè)close(false)信息并且強(qiáng)制性的重初始化此鏈接。

3.5 Merkle DAG對(duì)象

DHT和BitSwap允許IPFS構(gòu)造一個(gè)龐大的點(diǎn)對(duì)點(diǎn)系統(tǒng)用來(lái)快速穩(wěn)定的分發(fā)和存儲(chǔ)。最主要的是，IPFS建造了一個(gè)Merkle DAG,一個(gè)無(wú)回路有向圖，對(duì)象之間的links都是hash加密嵌入在源目標(biāo)中。這是Git數(shù)據(jù)結(jié)構(gòu)的一種推廣。Merkle DAGS給IPFS提供了很多有用的屬性，包括：

• 1.內(nèi)容可尋址：所有內(nèi)容都是被多重hash校驗(yàn)和來(lái)唯一識(shí)別的，包括links。
• 2.防止篡改：所有的內(nèi)容都用它的校驗(yàn)和來(lái)驗(yàn)證。如果數(shù)據(jù)被篡改或損壞，IPFS會(huì)檢測(cè)到。
• 3.重復(fù)數(shù)據(jù)刪除：所有的對(duì)象都擁有相同的內(nèi)容并只存儲(chǔ)一次。這對(duì)于索引對(duì)象非常有用，比如git的tree和commits，或者數(shù)據(jù)的公共部分。

IPFS對(duì)象的格式是：

1 2 3 4 5 6 7 8 9 10

type IPFSLink struct { Name string // 此link的別名 Hash Multihash // 目標(biāo)的加密hash Size int // 目標(biāo)總大小 } type IPFSObject struct { links []IPFSLink //links數(shù)組 data []byte //不透明內(nèi)容數(shù)據(jù) }

IPFS Merkle DAG是存儲(chǔ)數(shù)據(jù)非常靈活的一種方式。只要求對(duì)象引用是(a）內(nèi)容可尋址的，(b)用上面的格式編碼。IPFS允許應(yīng)用完全的掌控?cái)?shù)據(jù)域；應(yīng)用可以使用任何自定義格式的數(shù)據(jù)，即使數(shù)據(jù)IPFS都無(wú)法理解。單獨(dú)的內(nèi)部對(duì)象link表允許IPFS做：

• 用對(duì)象的形式列出所有對(duì)象引用，例如：

  1 2 3 4 5 6

  > ipfs ls /XLZ1625Jjn7SubMDgEyeaynFuR84ginqvzb XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x 189458 less XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5 19441 script XLF4hwVHsVuZ78FZK6fozf8Jj9WEURMbCX4 5286 template <object multihash> <object size> <link name>

• 解決字符串路經(jīng)查找，例如foo/bar/baz。給出一個(gè)對(duì)象，IPFS會(huì)解析第一個(gè)路經(jīng)成分進(jìn)行hash放入到對(duì)象的link表中，再獲取路徑的第二個(gè)組成部分，一直如此重復(fù)下去。因此，任何數(shù)據(jù)格式的字符串路經(jīng)都可以在Merkle DAG中使用。
  *遞歸性的解決所有對(duì)象引用：

  1 2 3 4 5 6

  > ipfs refs --recursive \ /XLZ1625Jjn7SubMDgEyeaynFuR84ginqvzb XLLxhdgJcXzLbtsLRL1twCHA2NrURp4H38s XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5 XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z

原始數(shù)據(jù)結(jié)構(gòu)公共link結(jié)構(gòu)是IPFS構(gòu)建任意數(shù)據(jù)結(jié)構(gòu)的必要組成部分?？梢院苋菀卓闯鯣it的對(duì)象模型是如何套用DAG的。一些其他潛在的數(shù)據(jù)結(jié)構(gòu)：

• (a)鍵值存儲(chǔ)
• (b)傳統(tǒng)關(guān)系型數(shù)據(jù)
• (c)數(shù)據(jù)三倍存儲(chǔ)
• (d) 文檔發(fā)布系統(tǒng)
• (e)通信平臺(tái)
• (f)加密貨幣區(qū)塊。
  這些系統(tǒng)都可以套用IPFS Merkle DAG，這使這些系統(tǒng)更復(fù)雜的應(yīng)用可以使用IPFS作為傳輸協(xié)議。

3.5.1 路經(jīng)

IPFS對(duì)象可以遍歷一個(gè)字符串路經(jīng)。路經(jīng)格式與傳統(tǒng)UNIX文件系統(tǒng)以及Web一致。Merkle DAG的links使遍歷變得很容易。全稱路經(jīng)在IPFS中的格式是：

1 2 3 4

*# 格式 /ipfs/<hash-of-object>/<name-path-to-object> *# 例子 /ipfs/XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x/foo.txt

/ipfs前綴允許只要在掛載點(diǎn)不沖突(掛載點(diǎn)名稱當(dāng)然是可配置的)的情況下掛載到一個(gè)已存在的系統(tǒng)上。第二個(gè)路經(jīng)組成部分(第一個(gè)是IPFS)是一個(gè)對(duì)象的hash。通常都是這種情況，因?yàn)闆](méi)有全局的根。一個(gè)根對(duì)象可能會(huì)有一個(gè)不可能完成的任務(wù)，就是在分布式環(huán)境(可能還斷開(kāi)鏈接)中處理百萬(wàn)對(duì)象的一致性。因此，我們用地址可尋址來(lái)模擬根。通過(guò)的hash所有的對(duì)象都是可訪問(wèn)的。這意思是說(shuō)，給一個(gè)路經(jīng)對(duì)象/bar/baz，最后一個(gè)對(duì)象可以可以被所有的訪問(wèn)的：

1 2 3

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

3.5.2 本地對(duì)象

IPFS客戶端需要一個(gè)本地存儲(chǔ)器，一個(gè)外部系統(tǒng)可以為IPFS管理的對(duì)象存儲(chǔ)以及檢索本地原始數(shù)據(jù)。存儲(chǔ)器的類型根據(jù)節(jié)點(diǎn)使用案例不同而不同。在大多數(shù)情況下，這個(gè)存儲(chǔ)器只是硬盤(pán)空間的一部分（不是被本地的文件系統(tǒng)使用鍵值存儲(chǔ)如leveldb來(lái)管理，就是直接被IPFS客戶端管理），在其他的情況下，例如非持久性緩存，存儲(chǔ)器就是RAM的一部分。

最終，所有的塊在IPFS中都是能夠獲取的到的，塊都存儲(chǔ)在了一些節(jié)點(diǎn)的本地存儲(chǔ)器中。當(dāng)用戶請(qǐng)求一個(gè)對(duì)象時(shí)，這個(gè)對(duì)象會(huì)被查找到并下載下來(lái)存儲(chǔ)到本地，至少也是暫時(shí)的存儲(chǔ)在本地。這為一些可配置時(shí)間量提供了快速的查找。

3.5.3對(duì)象鎖定

希望確保特定對(duì)象生存的節(jié)點(diǎn)可以鎖定此對(duì)象。這保證此特定對(duì)象被保存在了節(jié)點(diǎn)的本地存儲(chǔ)器上。也可以遞歸的進(jìn)行鎖定所有相關(guān)的派生對(duì)象。這使所有被指定的對(duì)象都保存在本地存儲(chǔ)器上。這對(duì)長(zhǎng)久保存文件特別有用，包括引用。這也同樣讓IPFS成為一個(gè)links是永久的Web，且對(duì)象可以確保其他被指定對(duì)象的生存。

3.5.4 發(fā)布對(duì)象

IPFS是全球分布的。它設(shè)計(jì)為允許成千上萬(wàn)的用戶文件可以共同的存在的。DHT使用內(nèi)容哈希尋址技術(shù)，使發(fā)布對(duì)象是公平的，安全的，完全分布式的。任何人都可以發(fā)布對(duì)象，只需要將對(duì)象的key加入到DHT中，并且以對(duì)象是對(duì)等節(jié)點(diǎn)的方式加入進(jìn)去，然后把路徑給其他的用戶。要注意的是，對(duì)象本質(zhì)上是不可改變的，就像在Git中一樣。新版本的哈希值不同，因此是新對(duì)象。跟蹤版本則是額外版本對(duì)象的工作。

3.5.5 對(duì)象級(jí)別的加密

IPFS是具備可以處理對(duì)象級(jí)別加密操作的。一個(gè)已加密的或者已簽名的對(duì)象包裝在一個(gè)特殊的框架里，此框架允許加密和驗(yàn)證原始字節(jié)。

1 2 3 4 5 6 7 8

type EncryptedObject struct { Object []bytes // 已加密的原始對(duì)象數(shù)據(jù) Tag []bytes // 可選擇的加密標(biāo)識(shí) type SignedObject struct { Object []bytes // 已簽名的原始對(duì)象數(shù)據(jù) Signature []bytes // HMAC簽名 PublicKey []multihash // 多重哈希身份鍵值 }

加密操作改變了對(duì)象的哈希值，定義一個(gè)不同的新的對(duì)象。IPFS自動(dòng)的驗(yàn)證簽名以及使用用戶指定的鑰匙鏈解密數(shù)據(jù)。加密數(shù)據(jù)的links也同樣的被保護(hù)著，沒(méi)有解密秘鑰就無(wú)法遍歷對(duì)象。也存在著一種現(xiàn)象，可能父對(duì)象使用了一個(gè)秘鑰進(jìn)行了加密，而子對(duì)象使用了另一個(gè)秘鑰進(jìn)行加密或者根本沒(méi)有加密。這可以保證links共享對(duì)象安全。

3.6 文件

IPFS在Merkle DAG上還為模型化版本文件系統(tǒng)定義了一組對(duì)象。這個(gè)對(duì)象模型與Git比較相似：
Block：一個(gè)可變大小的數(shù)據(jù)塊
List：塊或者其他鏈表的集合
Tree：塊，鏈表，或者其他樹(shù)的集合
Commit：樹(shù)在版本歷史記錄中的一個(gè)快照
我原本希望使用與Git對(duì)象格式一致的模型，但那就必須要分開(kāi)來(lái)引進(jìn)在分布式文件系統(tǒng)中有用的某些特征，如

• (a)快速大小查找(總字節(jié)大小已經(jīng)加入到對(duì)象中)
• (b)大文件的重復(fù)刪除(添加到list對(duì)象)
• (c)commits嵌入到trees中。不過(guò)，IPFS文件對(duì)象與Git還是非常相近的，兩者之間進(jìn)行交流都是有可能的。而且，Git的一個(gè)系列的對(duì)象可以被引進(jìn)過(guò)來(lái)轉(zhuǎn)換都不會(huì)丟失任何的信息。（UNIX文件權(quán)限等等）。
  標(biāo)記：下面的文件對(duì)象格式使用JSON。注意，雖然IPFS包含了JSON的互相轉(zhuǎn)換，但是文件對(duì)象的結(jié)構(gòu)體還是使用protobufs的二進(jìn)制編碼。

3.6.1 文件對(duì)象：BLOB

blob對(duì)象代表一個(gè)文件且包含一個(gè)可尋址的數(shù)據(jù)單元，IPFS的blobs就像Git的blobs或者文件系統(tǒng)數(shù)據(jù)塊。它們存儲(chǔ)用戶的數(shù)據(jù)。需要留意的是IPFS文件可以使用lists或者blobs來(lái)表示。Blobs沒(méi)有l(wèi)inks。

1 2 3

{ "data": "some data here", // blobs無(wú)links }

3.6.2 文件對(duì)象: list

List對(duì)象代表著由幾個(gè)IPFS的blobs連接成的大文件或者重復(fù)數(shù)據(jù)刪除文件。Lists包含著有序的blob序列或list對(duì)象。從某種程度上而言，IPFS的list函數(shù)就像一個(gè)間接塊的文件系統(tǒng)。由于lists可以包含其他的lists，那么包含linked的鏈表和平衡樹(shù)的拓?fù)浣Y(jié)構(gòu)是有可能的。有向圖中相同的節(jié)點(diǎn)出現(xiàn)在多個(gè)不同地方允許在文件中重復(fù)數(shù)據(jù)刪除。當(dāng)然，循環(huán)是不可以能的，因?yàn)槭潜还ぶ窂?qiáng)制實(shí)行的。

1 2 3 4 5 6 7 8 9 10 11

{ "data": ["blob", "list", "blob"], //lists有一個(gè)對(duì)象類型的數(shù)組作為數(shù)據(jù) "links": [ { "hash": "XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x", "size": 189458 }, { "hash": "XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5", "size": 19441 }, { "hash": "XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z", "size": 5286 } //在links中l(wèi)ists是沒(méi)有名字的 ] }

3.6.3 文件對(duì)象：tree

IPFS中的tree對(duì)象與Git中相似，它代表著一個(gè)目錄，一個(gè)名字到哈希值的映射。哈希值則表示著blobs，lists，其他的trees，或者commits。注意，傳統(tǒng)路徑的命名早已經(jīng)被Merkle DAG實(shí)現(xiàn)了。

1 2 3 4 5 6 7 8 9 10 11

{ "data": ["blob", "list", "blob"],//trees有一個(gè)對(duì)象類型的數(shù)組作為數(shù)據(jù) "links": [ { "hash": "XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x", "name": "less", "size": 189458 }, { "hash": "XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5", "name": "script", "size": 19441 }, { "hash": "XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z", "name": "template", "size": 5286 }//trees是有名字的 ] }

3.6.4 文件對(duì)象：commit

IPFS中的commit對(duì)象代表任何對(duì)象在版本歷史記錄中的一個(gè)快照。與Git中類似，但是它能夠表示任何類型的對(duì)象。它同樣link著發(fā)起對(duì)象。

3.6.5 版本控制

Commit對(duì)象代表著一個(gè)對(duì)象在歷史版本中的一個(gè)特定快照。在兩個(gè)不同的commit中比較對(duì)象（和子對(duì)象）可以揭露出兩個(gè)不同版本文件系統(tǒng)的區(qū)別。只要commit和它所有子對(duì)象的引用是能夠被訪問(wèn)的，所有前版本是可獲取的，所有文件系統(tǒng)改變的全部歷史是可訪問(wèn)的，這就與Merkle DAG對(duì)象模型脫離開(kāi)來(lái)了。

Git版本控制工具的所有功能對(duì)于IPFS的用戶是可用的。對(duì)象模型不完全一致，但也是可兼容的。這可能

• (a)構(gòu)建一個(gè)Git工具版本改造成使用IPFS對(duì)象圖，
• (b)構(gòu)建一個(gè)掛載FUSE文件系統(tǒng)，掛載一個(gè)IPFS的tree作為Git的倉(cāng)庫(kù)，把Git文件系統(tǒng)的讀/寫(xiě)轉(zhuǎn)換為IPFS的格式。

3.6.6 文件系統(tǒng)路徑

如我們?cè)贛erkle DAG中看到的一樣，IPFS對(duì)象可以使用字符串路徑API來(lái)遍歷。IPFS文件對(duì)象是特意設(shè)計(jì)的，為了讓掛載IPFS到UNIX文件系統(tǒng)更加簡(jiǎn)單。文件對(duì)象限制trees沒(méi)有數(shù)據(jù)，為了使它們可以表示目錄。Commits可以以代表目錄的形式出現(xiàn)，也可以完全的隱藏在文件系統(tǒng)中。

3.6.7 將文件分隔成LISTS和BLOBS

版本控制和分發(fā)大文件其中一個(gè)最主要的挑戰(zhàn)是：找到一個(gè)正確的方法來(lái)將它們分隔成獨(dú)立的塊。與其認(rèn)為IPFS可以為每個(gè)不同類型的文件提供正確的分隔方法，不如說(shuō)IPFS提供了以下的幾個(gè)可選選擇：
就像在LIBFS[?]中一樣使用Rabin Fingerprints [?]來(lái)選擇一個(gè)比較合適的塊邊界。
使用rsync[?] rolling-checksum算法，來(lái)檢測(cè)塊在版本之間的改變。
允許用戶指定專為特定文件而調(diào)整的’快分隔’函數(shù)。

3.6.8路徑查找性能

基于路徑的訪問(wèn)需要遍歷對(duì)象圖。獲取每個(gè)對(duì)象要求在DHT中查找它們的key，連接到對(duì)等節(jié)點(diǎn)，然后獲取它的塊。這造成相當(dāng)大的開(kāi)銷，特別是查找的路徑由很多子路徑組成時(shí)。下面的方法可以減緩開(kāi)銷：

• tree緩存：由于所有的對(duì)象都是哈希尋址的，它們可以被無(wú)限的緩存。另外，trees一般比較小，所以比起blobs，IPFS會(huì)優(yōu)先緩存trees。
• flattened trees：對(duì)于任何tree，一個(gè)特殊的 flattened tree可以構(gòu)建一個(gè)鏈表，所有對(duì)象都可以從這個(gè)tree中訪問(wèn)得到。在flattened tree中名字就是一個(gè)從原始tree分離的路徑，用斜線分隔。
  例如，對(duì)于上面的ttt111的flattened tree如下：

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

  { "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：命名以及易變狀態(tài)

目前為止，IPFS桟形成了一個(gè)對(duì)等塊交換組成一個(gè)內(nèi)容可尋址的DAG對(duì)象。這提供了發(fā)布和獲取不可改變的對(duì)象。這甚至可以跟蹤這些對(duì)象的版本歷史記錄。但是，這里有一個(gè)關(guān)鍵成分遺漏了：易變的命名。沒(méi)有這個(gè)，發(fā)送IPFS的links，所有新內(nèi)容的通信肯定都會(huì)有所偏差?，F(xiàn)在所需就是能有某些方法可以獲取相同路徑的的易變狀態(tài)。

這值得詳述原因—如果最終易變數(shù)據(jù)是必須的—我們費(fèi)了很大的力氣構(gòu)建了一個(gè)不可改變的Merkle DAG。就當(dāng)做IPFS脫離了Merkle DAG的特征：對(duì)象可以

• (a)通過(guò)哈希值可以獲取
• (b)完整性的檢查
• (c)link其他的對(duì)象
• (d)無(wú)限緩存。從某種意義上說(shuō)：對(duì)象就是永恒的這些就是一個(gè)高性能分布式系統(tǒng)的關(guān)鍵特征，在此系統(tǒng)上跨網(wǎng)絡(luò)links之間移動(dòng)文件是非常昂貴的。對(duì)象內(nèi)容可尋址構(gòu)建了一個(gè)具有以下特點(diǎn)的Web，(a)優(yōu)秀的寬帶優(yōu)化(b)不受信任的內(nèi)容服務(wù)(c)永恒的links(d)能夠永久備任何對(duì)象以及它的引用。

不可變的內(nèi)容可尋址對(duì)象和命名的Merkle DAG， 可變指針指向Merkle DAG，實(shí)例化了一個(gè)出現(xiàn)在很多成功分布式系統(tǒng)中的二分法。這些系統(tǒng)包括Git的版本控制系統(tǒng)，使用不可變的對(duì)象和可變的引用；還有UNIX分布式的繼承者Plan9[?]文件系統(tǒng)，使用可變的Fossil和不可變的Venti[?]。LBFS[?]同樣使用可變的索引以及不可變的塊。

3.7.1 自我認(rèn)證名稱

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

• 1.回想一下在IPFS中：NodeId = hash(node.PubKey)
• 2.我們給每個(gè)用戶分配一個(gè)可變的命名空間，在此路徑下：/ipns/
• 3.一個(gè)用戶可以在此路徑下發(fā)布一個(gè)用自己私鑰簽名的對(duì)象，比如說(shuō)：/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/
• 4.當(dāng)其他用戶獲取對(duì)象時(shí)，他們可以檢測(cè)簽名是否與公鑰和NodeId匹配。這個(gè)驗(yàn)證了用戶發(fā)布對(duì)象的真實(shí)性，達(dá)到了可變狀態(tài)的獲取。

注意下面的細(xì)節(jié)：

• IPNS(InterPlanetary的命名空間)分開(kāi)前綴是在可變和不可變的路徑之間建立一個(gè)很容易辨認(rèn)的區(qū)別，為了程序也為了人類閱讀的便利。

• 因?yàn)檫@不是一個(gè)內(nèi)容可尋址的對(duì)象，所以發(fā)布它就要依靠IPFS中的唯一的可變狀態(tài)分配制度，路由系統(tǒng)。過(guò)程是(a)首先把此對(duì)象做一個(gè)常規(guī)的不可變IPFS的對(duì)象來(lái)發(fā)布(b)將此對(duì)象的哈希值作為元數(shù)據(jù)的值發(fā)布到路由系統(tǒng)上：

  1	routing.setValue(NodeId, <ns-object-hash>)

• 發(fā)布的對(duì)象中任何links在命令空間中充當(dāng)子名稱：

  1 2 3

  /ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/ /ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/docs /ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/docs/ipfs

• 一般建議發(fā)布一個(gè)commit對(duì)象或者其他對(duì)象的時(shí)候，要使用歷史版本記錄，因?yàn)檫@樣就用戶就可以找到之前使用過(guò)的名字。不過(guò)由于這并不總是需要的，所以留個(gè)用戶自己選擇。
  注意當(dāng)用戶發(fā)布一個(gè)對(duì)象的時(shí)候，他不能使用相同的方式來(lái)發(fā)布對(duì)象。

3.7.2人類友好名稱

IPNS的確是一個(gè)分配和在分配名稱的好方法，但是對(duì)用戶卻不是十分友好的，因?yàn)樗褂煤荛L(zhǎng)的哈希值作為名稱，眾所周知這樣的名稱很難被記住。IPNS足夠應(yīng)付URLs，但對(duì)于很多線下的傳輸工作就沒(méi)有這么好用了。因此，IPFS使用下面的技術(shù)來(lái)增加IPNS的用戶友好度。

對(duì)等節(jié)點(diǎn)Links被SFS所鼓舞，用戶可以直接將其他用戶的對(duì)象link到自己的對(duì)象上（命令空間，家目錄等等）。這有一個(gè)好處就是創(chuàng)建了一個(gè)可信任的Web（也支持老的真實(shí)性認(rèn)證模型）：

1 2 3 4 5 6 7 8

# 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 也可以訪問(wèn)Bob /<eve-pk-hash/friends/alice/friends/bob # 訪問(wèn)Verisign 認(rèn)證域 /<verisign-pk-hash>/foo.com

DNS TXT IPNS 記錄
如果/ipns/是一個(gè)有效的域名稱，IPFS會(huì)在DNS TXT記錄中查找關(guān)鍵的ipns。IPFS會(huì)將查找到的值翻譯為一個(gè)對(duì)象的哈希值或者另一個(gè)ipns的路徑：

1 2 3 4

# DNS TXT 記錄 ipfs.benet.ai. TXT "ipfs=XLF2ipQ4jD3U ..." # 表現(xiàn)為符號(hào)鏈接 ln -s /ipns/XLF2ipQ4jD3U /ipns/fs.benet.ai

Proquint 可讀的標(biāo)識(shí)符
總是會(huì)有將二進(jìn)制編碼翻譯成可讀文件的方法。IPNS則支持Proquint[?].。如下：

1 2 3 4

# proquint語(yǔ)句 /ipns/dahih-dolij-sozuk-vosah-luvar-fuluh # 分解為相應(yīng)的下面形式 /ipns/KhAwNprxYVxKqpDZ

縮短名稱服務(wù)
會(huì)涌現(xiàn)出很多服務(wù)器提供縮短名稱的服務(wù)，向用戶提供他們的命名空間。就像我們現(xiàn)在看到的DNS和Web的URLs：

1 2 3 4

# 用戶可以從下面獲取一個(gè)link /ipns/shorten.er/foobar # 然后放到自己的命名空間 /ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm

3.8使用IPFS

IPFS設(shè)計(jì)為可以使用多種不同的方法來(lái)使用的，下面就是一些我將會(huì)繼續(xù)追求的使用方式：

• 1.作為一個(gè)掛載的全局文件系統(tǒng)，掛載在/ipfs和/ipns下
• 2.作為一個(gè)掛載的個(gè)人同步文件夾，自動(dòng)的進(jìn)行版本管理，發(fā)布，以及備份任何的寫(xiě)入
• 3.作為一個(gè)加密的文件或者數(shù)據(jù)共享系統(tǒng)
• 4.作為所有軟件的版本包管理者
• 5.作為虛擬機(jī)器的根文件系統(tǒng)
• 6.作為VM的啟動(dòng)文件系統(tǒng) (在管理程序下)
• 7.作為一個(gè)數(shù)據(jù)庫(kù)：應(yīng)用可以直接將數(shù)據(jù)寫(xiě)入Merkle DAG數(shù)據(jù)模型中，獲取所有的版本，緩沖，以及IPFS提供的分配
• 8.作為一個(gè)linked（和加密的）通信平臺(tái)
• 9.作為一個(gè)為大文件的完整性檢查CDN（不使用SSL的情況下）
• 10.作為一個(gè)加密的CDN
• 11.在網(wǎng)頁(yè)上，作為一個(gè)web CDN
• 12.作為一個(gè)links永遠(yuǎn)存在新的永恒的Web
  IPFS實(shí)現(xiàn)的目標(biāo)：
• (a)一個(gè)IPFS庫(kù)可以導(dǎo)出到你自己應(yīng)用中使用
• (b)命令行工具可以直接操作對(duì)象
• (c)使用FUSE[?]或者內(nèi)核的模型掛載文件系統(tǒng)

4. 未來(lái)

IPFS的思想是幾十年成功的分布式系統(tǒng)的探索和開(kāi)源的產(chǎn)物。IPFS綜合了很多迄今為止很成功的系統(tǒng)中優(yōu)秀的思想。除了BitSwap新協(xié)議之外，IPFS最大的特色就是系統(tǒng)的耦合以及設(shè)計(jì)的綜合性。
IPFS是去中心化網(wǎng)絡(luò)基礎(chǔ)設(shè)施的一個(gè)野心設(shè)想，很多不同類型的應(yīng)用都可以建立在IPFS上。最低限度，它可以用來(lái)作為一個(gè)全局的，掛載性，版本控制文件系統(tǒng)和命名空間，或者作為下一代的文件共享系統(tǒng)。而最好的情況是，IPFS可以讓W(xué)eb升級(jí)一個(gè)層次，當(dāng)發(fā)布一個(gè)有價(jià)值的信息時(shí)，任何感興趣的人都可以進(jìn)行發(fā)布而不會(huì)強(qiáng)迫性的必須只允許發(fā)布機(jī)構(gòu)進(jìn)行發(fā)布，用戶可以信任信息的內(nèi)容，信不信任信息的發(fā)送者都是無(wú)關(guān)緊要的，還有一個(gè)特點(diǎn)就是，一些重要但很老的文件也不會(huì)丟失。IPFS期待著帶我們進(jìn)入到一個(gè)永恒Wdb的世界。

5. 感謝

IPFS是一個(gè)很多很棒的主意以及系統(tǒng)的綜合體。沒(méi)有站在巨人的肩膀上，IPFS也不可能敢于有一個(gè)這么有野心的目標(biāo)。個(gè)人感謝參與這些主意長(zhǎng)期討論的人：David Dalrymple, Joe Zimmerman, and Ali Yahya，特別是：揭開(kāi)Merkle DAG的總體架構(gòu)(David, Joe),滾動(dòng)哈希阻塞(David), s/kademlia sybill 保護(hù)(David, Ali)，特別感謝David Mazieres,為他之前非常聰明的主意。

6.引用備忘錄

7.引用

[1].I. Baumgart and S. Mies. S/kademlia:一個(gè)安全的基于秘鑰路由的可行方法。2007年國(guó)際會(huì)議，第2卷，1-8頁(yè)，在《并發(fā)和分布式系統(tǒng)》中。IEEE，2007年。
[2].I. BitTorrent.Bittorrent和Attorrent軟件超過(guò)1億5000萬(wàn)用戶里程碑，Jan。2012
[3].B. Cohen.激勵(lì)機(jī)制在bittorrent中建立了健壯性。在《對(duì)等系統(tǒng)經(jīng)濟(jì)研討會(huì)》中，第6卷，68-72頁(yè)，2003年。
[4].J. Dean and S. Ghemawat. Leveldb - 一個(gè)快速和輕量級(jí)鍵值存儲(chǔ)數(shù)據(jù)庫(kù)，谷歌提供，2011年。
[5].M. J. Freedman, E. Freudenthal, and D. Mazieres. Coral民主內(nèi)容發(fā)布。在NSDI中，第4卷，18-18頁(yè)，2004年。
[6].J. H. Howard, M. L. Kazar, S. G. Menees, D. A,Nichols, M. Satyanarayanan, R. N. Sidebotham, 以及M. J. West.分布式文件系統(tǒng)的規(guī)模和性能。“ACM 電腦系統(tǒng)上的交易 （TOCS）” 6(1):51-81, 1988年

總結(jié)

以上是生活随笔為你收集整理的IPFS星际文件系统(中文白皮书)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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