IPFS(DRAFT 3) 中文版白皮书
借助google翻譯加自己理解做了調(diào)整，個人在有道筆記上做記錄，現(xiàn)分享出來，有翻譯或理解不準確的，可以一起交流
個人有道筆記鏈接
IPFS - Content Addressed, Versioned, P2P File System(DRAFT 3)
Juan Benet
juan@benet.ai
摘要 ABSTRACT
IPFS（星際文件系統(tǒng)，星際文件系統(tǒng)）是點對點分布式系統(tǒng)，追求連接所有相同文件系統(tǒng)的計算設(shè)備。在某些方面，IPFS類似于Web，但是IPFS可以被認為是一個單一的BitTorrent Swarm，使用Git倉庫進行交換對象。換句話說，IPFS使用內(nèi)容尋址超鏈接，提供了高效的基于內(nèi)容的地址區(qū)塊存儲模型。這形成了一個通用的MerkleDAG，它可以構(gòu)建版本文件系統(tǒng)，區(qū)塊鏈，甚至一個永恒的網(wǎng)站的數(shù)據(jù)結(jié)構(gòu).IPFS由一個分布式哈希表（分布式散列表，DHT），一個去中心化的區(qū)塊交換，一個自證明命名空間（一個自我認證的命名空間）.IPFS沒有單點故障，其中的節(jié)點也不需要互相信任。
1.介紹 INTRODUCTION
在構(gòu)建全球分布式文件系統(tǒng)上已經(jīng)進行過一些嘗試。一些系統(tǒng)相當成功，而另外一些則完全失敗了。在這些學術(shù)理論嘗試中，AFS獲得了廣泛的成功，直到目前還在使用。另外的一些，則沒有獲得一樣的成功。在理論研究之外，大多數(shù)成功的系統(tǒng)是適用于大媒體數(shù)據(jù)（音頻和視頻）的P2P文件共享系統(tǒng)的應(yīng)用。最著名的有，Napster，KaZaA和BitTorrent，其中BitTorrent部署了大量文件分布式系統(tǒng)，有超過1億的并發(fā)用戶。即使今天，BitTorrent維持了大量的部署，每天有超過1000萬的節(jié)點數(shù)。這些應(yīng)用比理論文件系統(tǒng)有更多的用戶和文件發(fā)布。盡管如此，這些應(yīng)用并沒有設(shè)計成一個基礎(chǔ)設(shè)施，以此為基礎(chǔ)建立擴展。然而，也有一些成功的改變，非通用的文件系統(tǒng)已經(jīng)出現(xiàn)，提供了全球化、低延時、去中心發(fā)布。
可能對于大多數(shù)已存在的用戶場景Http已經(jīng)是一個足夠好的系統(tǒng)。到目前為止，HTTP是有史以來最成功的“文件的分布式系統(tǒng)”。與瀏覽器相結(jié)合，HTTP產(chǎn)生了巨大的技術(shù)和社會影響。它已成為通過互聯(lián)網(wǎng)傳輸文件的事實上的方式。然而，它未能利用過去十五年發(fā)明的數(shù)十種出色的文件分發(fā)技術(shù)。從某個視角，演進Web基礎(chǔ)設(shè)施幾乎是不可能的，因為涉及大量向后兼容性限制和大量團體在現(xiàn)有模型上的投入。但從另一個角度來看，自HTTP出現(xiàn)以來，新的協(xié)議已經(jīng)出現(xiàn)并得到了廣泛的應(yīng)用。缺少的是升級設(shè)計：增強當前的HTTP Web，并在不降低用戶體驗的情況下引入新功能。
業(yè)界已經(jīng)開始使用HTTP了很長時間，因為移動小文件相對便宜，即使對于擁有大量流量的小型組織也是如此。但我們正在進入一個新的數(shù)據(jù)分發(fā)時代，面臨著新的挑戰(zhàn)：（a）托管和分發(fā)PB級數(shù)據(jù)集，（b）跨組織計算大數(shù)據(jù)，（c）高容量高清晰度按需或?qū)崟r媒體流，（d）大規(guī)模數(shù)據(jù)集的版本化和鏈接，（e）防止重要文件的意外消失等。其中許多可歸結(jié)為大量數(shù)據(jù)，可隨處訪問?！笆荜P(guān)鍵功能和帶寬問題的壓力，我們已經(jīng)使用不同的數(shù)據(jù)分發(fā)協(xié)議放棄了HTTP。下一步是將它們作為Web本身的一部分。
正交于高效的數(shù)據(jù)分發(fā)，版本控制系統(tǒng)已設(shè)法開發(fā)重要的數(shù)據(jù)協(xié)作工作流程。Git是分布式源代碼版本控制系統(tǒng)，它開發(fā)了許多有用的方法來建模和實現(xiàn)分布式數(shù)據(jù)操作。Git工具鏈提供了多種版本控制功能，大型文件分發(fā)系統(tǒng)嚴重缺乏。受Git啟發(fā)的新解決方案正在出現(xiàn)，例如Camlistore[？]，一個個人文件存儲系統(tǒng)，以及Dat [？]一個數(shù)據(jù)協(xié)作工具鏈和數(shù)據(jù)集包管理器。Git已經(jīng)影響了分布式文件系統(tǒng)設(shè)計[9]，因為其內(nèi)容為Merkle DAG數(shù)據(jù)模型提供了強大的文件分發(fā)策略。還有待探索的是，這種數(shù)據(jù)結(jié)構(gòu)如何影響面向高吞吐量的文件系統(tǒng)的設(shè)計，以及它如何升級Web本身。
本文介紹了IPFS，一種新穎的P2P版本控制文件系統(tǒng)，旨在協(xié)調(diào)這些問題。IPFS綜合了許多過去成功系統(tǒng)的學習經(jīng)驗。仔細的以界面為中心的集成產(chǎn)生的系統(tǒng)大于其各部分的總和。IPFS的核心原則是將所有數(shù)據(jù)建模為同一Merkle DAG的一部分。
這篇文章介紹了IPFS，一個P2P版本控制文件系統(tǒng)的新想法力圖解決這些問題。IPFS綜合學習了過去的一些成功的系統(tǒng)?；诮涌诰o密的集成產(chǎn)生的系統(tǒng)比各個部分的簡單相加更強大。IPFFS的中心原則是把所有數(shù)據(jù)改造成同一個Merkle DAG的一部分。
2. 背景 BACKGROUND
這章節(jié)回顧了構(gòu)成IPFS的成功P2P系統(tǒng)的重要特性。
2.1 分布式哈希表 Distribution Hash Tables，DHT
DHTs廣泛適用于P2P系統(tǒng)的元數(shù)據(jù)的調(diào)整及維護。例如，BitTorrent MainlineDHT記錄了torrent swarm的節(jié)點集
2.1.1 Kademlia DHT
Kademlia是受歡迎的DHT，提供了：
1.在大網(wǎng)絡(luò)中高效查詢：查詢節(jié)點的平均效率log2(n).（例如，對于1000萬節(jié)點的網(wǎng)絡(luò)只需要20跳）
2.低協(xié)調(diào)開銷：優(yōu)化了發(fā)送給其他節(jié)點的控制信息的數(shù)量
3.通過優(yōu)選長期存在的節(jié)點來阻止大量攻擊
4.廣泛應(yīng)用于P2P應(yīng)用中，包括Guntella和BitTorrent，超過2000萬節(jié)點的組網(wǎng)。
2.1.2 Coral DSHT
雖然有些P2P文件系統(tǒng)直接在DHTs中存儲數(shù)據(jù)塊，這個”浪費存儲和寬帶，因為原本并不需要的數(shù)據(jù)必須被存儲在節(jié)點上”。Coral DSHT通過三種特別重要的方式擴展了Kademlia：
1.Kademlia根據(jù)離key“最近”距離（使用XOR-distance）的節(jié)點ids中存儲數(shù)據(jù)，這沒有考慮應(yīng)用數(shù)據(jù)的位置，忽略了擁有這些數(shù)據(jù)的“遠”節(jié)點，同時不管他們是否需要而強制“最近”節(jié)點來存儲。這浪費了有效存儲和寬帶。相反，Coral存儲能存儲這些數(shù)據(jù)塊的節(jié)點的地址。
2.Coral將DHT API從get_value(key)改成get_any_values(key)(DSHT中的“sloppy”)。Coral用戶僅需要一個正常運行的節(jié)點，而不需要整個列表。作為回報，Coral分發(fā)值的子集到“nearest”節(jié)點，避免熱點（當一個鍵值受歡迎時，使周邊所有nearest節(jié)點超負載）
3.還有，Coral依賴于區(qū)域和大小組成DSHTs的各個層級（稱為clusters）。這使節(jié)點優(yōu)先在自己的區(qū)域內(nèi)查詢節(jié)點，“查找臨近的數(shù)據(jù)，而不是查找距離節(jié)點”，這極大減少查找的延時。
2.1.3 S/Kademlia DHT
S/Kademlia為了阻止惡意攻擊擴展了Kademlia，在兩種特別重要的方面：
1.S/Kademlia提供了保護NodeID生成及阻止女巫攻擊的方案。要求節(jié)點產(chǎn)生PKI鍵值對，從中獲得標識符，并且相互簽名。其中的一個方案POW提高了女巫攻擊的成本。
2.S/Kademlia節(jié)點通過獨立的路徑查詢值，就是為了確保誠實節(jié)點能夠在網(wǎng)絡(luò)中存在大量惡意節(jié)點時能夠互相連接。即使在一半惡意節(jié)點時，S/Kademlia也可以獲得85%的成功率。
2.2 塊交換Block Exchanges-BitTorrent
BitTorrent是一個相當成功的P2P文件共享系統(tǒng)，成功的協(xié)調(diào)不信任節(jié)點（swarms）之間的網(wǎng)絡(luò)，互相合作分發(fā)文件片段。從BitTorrent及其生態(tài)系統(tǒng)的關(guān)鍵特性中，ipfs得到的啟發(fā)包括:
1. BitTorrent的數(shù)據(jù)交換協(xié)議采用類似于tit-for-tat策略，獎勵相互貢獻的節(jié)點，懲罰那些只獲取他人的節(jié)點的資源。
2. BitTorrent節(jié)點跟蹤文件的可用性，優(yōu)先發(fā)送最稀有的碎片。 這會減輕種子負擔，使非種子節(jié)點能夠相互交易。
3. BitTorrent的標準tit-for-tat相對容易受到一些強占帶寬共享策略的影響。PropShare是一種不同的對等帶寬分配策略，可以更好地抵制強占策略，并提高群體的性能。
2.3 版本控制系統(tǒng) Version Control Systems-Git
版本控制系統(tǒng)提供了模型文件的工具，可以隨時間變化并有效地分發(fā)不同的版本。流行的版本控制系統(tǒng)Git提供了一個強大的Merkle DAG(Merkle Directed Acyclic Graph- 類似于但比MerkleTree更通用的結(jié)構(gòu)。重復(fù)數(shù)據(jù)刪除，不需要平衡，非葉節(jié)點包含數(shù)據(jù)。)對象模型，以分布式友好的方式捕獲文件系統(tǒng)樹的變化。
1.不可變對象表示文件（blob），目錄（tree）和更改（commit）。
2.對象通過其內(nèi)容的hast加密方式進行內(nèi)容尋址。
3.鏈接其他嵌入的對象，形成Merkle DAG。 這提供了許多有用的完整性和工作流屬性
4.大多數(shù)版本控制元數(shù)據(jù)（branches，tags等）只是指針引用，因此創(chuàng)建和更新成本低廉。
5.版本更改僅更新引用或添加對象。
6.將版本更改分發(fā)給其他用戶只是傳輸對象和更新遠程引用。
2.4 自證明文件系統(tǒng) Self-Certified Filesystems-SFS
SFS提出了兩個的引人注目的實現(xiàn)：（a）分布式信任鏈和（b）平等共享全局命名空間。SFS引入了一種構(gòu)建SelfCertified Filesystems的技術(shù)：使用以下方案尋址遠程文件系統(tǒng)
/sfs/<Location>:<HostID>這里的Location是服務(wù)器網(wǎng)絡(luò)地址，同時
HostID = hash(public_key || Location)因此，SFS文件系統(tǒng)的名稱證明了他的服務(wù)器。用戶可以驗證服務(wù)器提供的公鑰，協(xié)商共享密鑰并保護所有流量。所有SFS實例共享一個全局命名空間，其中名稱分配是加密的，而不是任何集中式主體的把控。
3. IPFS設(shè)計
IPFS是一個分布式文件系統(tǒng)，它綜合了以前的對等系統(tǒng)的成功思想，包括DHT，BitTorrent，Git和SFS。IPFS的貢獻在于將經(jīng)過驗證的技術(shù)簡化，發(fā)展和整合到一個整體的系統(tǒng)中，大于其各部分的總和。IPFS提供了一個用于編寫和部署應(yīng)用程序的新平臺，以及一個用于分發(fā)和版本化大數(shù)據(jù)的新系統(tǒng)。 IPFS甚至可以改進網(wǎng)絡(luò)本身。
IPFS是點對點的; 沒有節(jié)點是特權(quán)。 IPFS節(jié)點將IPFS對象存儲在本地存儲中。節(jié)點間相互連接和轉(zhuǎn)移對象。 這些對象可以表示為文件和其他數(shù)據(jù)結(jié)構(gòu)。 IPFS協(xié)議分為一堆不同功能的子協(xié)議：
1.身份 - 管理節(jié)點身份生成和驗證。見3.1節(jié)。
2.網(wǎng)絡(luò) - 管理與其他節(jié)點的連接，使用各種底層網(wǎng)絡(luò)協(xié)議?？膳渲?。見3.2節(jié)。
3.路由 - 維護信息以定位特定的節(jié)點和對象。響應(yīng)本地和遠程查詢。默認為DHT，可替換。見3.3節(jié)。
4.交換 - 一種新的塊交換協(xié)議（BitSwap），用于管理有效的塊分發(fā)。模仿市場，弱激勵數(shù)據(jù)復(fù)制。交易策略可替換。在3.4節(jié)中描述。
5.對象 - 帶有鏈接的內(nèi)容尋址不可變對象的MerkleDAG。用于表示任意數(shù)據(jù)結(jié)構(gòu)，例如文件層次結(jié)構(gòu)和通信系統(tǒng)。在3.5節(jié)中描述。
6.文件 - 受Git啟發(fā)的版本化文件系統(tǒng)層次結(jié)構(gòu)。見3.6節(jié)。
7.命名 - 自我認證的可變名稱系統(tǒng)。在3.7節(jié)中描述。
這些子系統(tǒng)不是獨立的;它們是集成的并融合的。盡管如此，從下到上構(gòu)建協(xié)議棧，分別描述它們是有益的。
注意：下面的數(shù)據(jù)結(jié)構(gòu)和函數(shù)在Go語法中指定。
3.1身份 Identities
節(jié)點通過NodeId來標識，NodeId是公鑰的加密哈希，使用S/Kademlia的靜態(tài)加密拼圖創(chuàng)建。 節(jié)點存儲其公鑰和私鑰（使用密碼加密）。用戶可以在每次發(fā)布時自由地設(shè)置“新”節(jié)點標識，但是會丟失累積的網(wǎng)絡(luò)收益。 被激勵節(jié)點保持不變。
type NodeId Multihash type Multihash []byte // self-describing cryptographic hash digest type PublicKey []byte type PrivateKey []byte // self-describing keys type Node struct { NodeId NodeID PubKey PublicKey PriKey PrivateKey }基于S/Kademlia方式產(chǎn)生的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)第一次連接時，節(jié)點相互交換公鑰，并且校驗：hash(other.PublicKey)==other.NodeId.如果不是，連接終止。
關(guān)于加密函數(shù)的注意事項：
IPFS不是將系統(tǒng)鎖定到一組特定的函數(shù)選擇，而是支持自描述值。散列摘要值以multihash格式存儲，其中包括指定所使用的散列函數(shù)的短標頭和以字節(jié)為單位的摘要長度。 例如：
這允許系統(tǒng)（a）為用例選擇最佳功能（例如，更強的安全性和更快的性能），以及（b）隨著功能選擇的改變而發(fā)展。 自描述值允許兼容地使用不同的參數(shù)選擇。
3.2 Network
IPFS節(jié)點與網(wǎng)絡(luò)中的數(shù)百個其他節(jié)點定期通信，可能跨越廣泛的互聯(lián)網(wǎng)。 IPFS網(wǎng)絡(luò)堆棧功能：
?傳輸：IPFS可以使用任何傳輸協(xié)議，最適合WebRTC數(shù)據(jù)通道[？]（用于瀏覽器連接）或uTP（LEDBAT [14]）。
?可靠性：如果底層網(wǎng)絡(luò)不提供IPFS，IPFS可以使用uTP（LEDBAT [14]）或SCTP [15]提供可靠性。
?連接性：IPFS還使用ICE NAT遍歷技術(shù)[13]。
?完整性：可選擇使用哈希校驗和檢查消息的完整性。
?真實性：可選擇使用帶有發(fā)件人公鑰的HMAC檢查郵件的真實性。
3.2.1 節(jié)點尋址注意事項
IPFS可以使用任何網(wǎng)絡(luò); 它不依賴或假設(shè)訪問IP。這允許IPFS用于覆蓋網(wǎng)絡(luò)。IPFS將地址存儲為multiaddr的字節(jié)字符串，供底層網(wǎng)絡(luò)使用。 multiaddr提供了一種表達地址及其協(xié)議的方法，包括對封裝的支持。 例如：
# 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 Routing
IPFS節(jié)點需要路由系統(tǒng)，該路由系統(tǒng)可以找到（a）其他Peer的網(wǎng)絡(luò)地址，以及（b）可以為特定對象提供服務(wù)的Peer。 IPFS使用基于S/Kademlia和Coral的DSHT，2.1中討論了這個。對象的大小和IPFS的使用模式類似于Coral和Mainline 因此IPFS DHT根據(jù)它們的大小對存儲的值進行區(qū)分。對于值小（等于或小于1KB）的情況直接存儲在DHT上。對于更大的值，DHT存儲引用，它們是可以提供塊服務(wù)的對等體的NodeId。
此DSHT的接口如下：
注意：不同的用例將要求實質(zhì)上不同的路由系統(tǒng)（例如，寬網(wǎng)絡(luò)中的DHT，本地網(wǎng)絡(luò)中的靜態(tài)HT）。 因此，可以交換IPFS路由系統(tǒng)以滿足用戶的需求。 只要滿足上面的接口，系統(tǒng)的其余部分將繼續(xù)運行。
3.4 區(qū)塊交換-BitSwap Protocol
在IPFS中，通過使用BitTorrent啟發(fā)的協(xié)議：BitSwap，與peers交換塊來進行數(shù)據(jù)分發(fā)。與BitTorrent一樣，BitSwap節(jié)點正在尋求獲得一組塊（want_list），并在交換中提供另一組塊（have_list）。與BitTorrent不同，BitSwap不僅限于一個torrent中的塊。BitSwap作為一個持久的市場運行，節(jié)點可以獲取所需的塊，無論這些塊是哪些文件的一部分。 這些塊可能來自文件系統(tǒng)中完全不相關(guān)的文件。 節(jié)點聚集在一起交易市場。
雖然交易系統(tǒng)的概念意味著可以創(chuàng)建虛擬貨幣，但這需要全球分類賬來跟蹤貨幣的所有權(quán)和轉(zhuǎn)移。這可以作為BitSwap策略實現(xiàn)，并將在未來的論文中進行探討。
在基本情況下，BitSwap節(jié)點必須以塊的形式相互提供直接值。當跨節(jié)點的塊分布是互補的時，也就是說它們具有對方想要的內(nèi)容，這非常有效。通常情況并非如此。在某些情況下，節(jié)點必須適用于其塊。如果一個節(jié)點沒有其peer想要的東西（或根本沒有），它會尋找其peer想要的部分，其優(yōu)先級低于節(jié)點自己想要的優(yōu)先級。這激勵節(jié)點緩存和傳播稀有部分，即使他們不直接對它們感興趣。
3.4.1 BitSwap Credit
協(xié)議還必須激勵節(jié)點在不需要任何特定內(nèi)容時做種子，因為它們可能有其他節(jié)點所需的塊。因此，BitSwap節(jié)點積極地向其Peer發(fā)送塊，期望償還債務(wù)。 但必須防范水蛭（永不共享的免費加載節(jié)點）。 一個簡單的信用類系統(tǒng)解決了這個問題：
1.Peers跟蹤其他節(jié)點的收支（以字節(jié)驗證）。
2.根據(jù)債務(wù)增加而下降的函數(shù)，peer在概率上向債務(wù)peer發(fā)送區(qū)塊。
請注意，如果節(jié)點決定不發(fā)送給對等方，則該節(jié)點隨后會忽略該Peer以獲取ignore_cooldown超時。這可以防止發(fā)件人通過引起更多的骰子來嘗試游戲概率。 （默認BitSwap為10秒）。
3.4.2 BitSwap Strategy
BitSwap Peers可能采用的不同策略會對整個交易所的表現(xiàn)產(chǎn)生了截然不同的影響。在BitTorrent中，雖然指定了標準策略（tit-for-tat），但也已經(jīng)實施了各種其他策略，從BitTyrant（共享最不可能），到BitThief（利用漏洞，永不分享），到PropShare（按比例分享）。 BitSwap Peers可以類似地實施一系列策略（良好和惡意）。 那么，功能的選擇應(yīng)該旨在：
1.最大化節(jié)點和整個交易所的交易表現(xiàn)
2.阻止貪圖者利用和降低交換
3.對其他未知策略有效并具有抵抗力
4.對受信任的peers寬容
對這些戰(zhàn)略空間的探索是未來的工作。 在實踐中起作用的一個功能選擇是一個sigmoid，由債務(wù)比例縮放：
讓節(jié)點與其對等體之間的負債比率為：
正如您在圖1中所看到的，當節(jié)點的負債率超過既定信用額度的兩倍時，此功能會迅速下降。
debt ratio是衡量信任度的指標：對先前已成功交換大量數(shù)據(jù)的節(jié)點之間的債務(wù)寬容，對未知的不可信節(jié)點無情。 這（a）提供了對創(chuàng)建大量新節(jié)點（sybill攻擊）的攻擊者的抵抗，（b）保護以前成功的交換關(guān)系，即使其中一個節(jié)點暫時無法提供價值，以及（c）最終關(guān)閉已經(jīng)惡化關(guān)系，直到他們改善。
3.4.3 BitSwap Ledger
BitSwap節(jié)點使分類賬記錄與其他節(jié)點的轉(zhuǎn)賬。這允許節(jié)點跟蹤歷史記錄并避免篡改。激活連接時，BitSwap節(jié)點會交換其分類帳信息。 如果它不完全匹配，則從破壞或丟失的信用或債務(wù)開始重新初始化分類帳。惡意節(jié)點有可能故意丟失分類賬本，從而達到消除債務(wù)的目的。節(jié)點不太可能產(chǎn)生足夠的債務(wù)以保證也會失去應(yīng)計信任;但是合作伙伴節(jié)點可以自由地將其視為不當行為，并且拒絕交易。
type Ledger struct { owner NodeId partner NodeId bytes_sent int bytes_recv int timestamp Timestamp }節(jié)點可以自由保留分類帳歷史記錄，但不是必須的正確操作。只有當前分類帳條目才有用。節(jié)點也可以根據(jù)需要隨意收集分類賬，從較不實用的分類賬開始：舊的（peers可能不再存在）和小。
3.4.4 BitSwap Specification
BitSwap節(jié)點遵循一個簡單協(xié)議
// 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); }節(jié)點連接的全生命周期框架：
1.Open: 達成一致后，Peers發(fā)送Ledgers
2.Sending：peers 交換want_lists 和Blocks
3.Close：Peers關(guān)閉連接
4.Ignored：（特別的）如果一個節(jié)點的策略是避免發(fā)送，該Peer被忽略（在超時周期內(nèi)）
當連接時，節(jié)點使用Ledger初始化連接，該Ledger可以是從過去的連接存儲的，也可以是新的連接。 然后，將帶有Ledger的Open消息發(fā)送給Peer。
收到Open消息后，Peer選擇是否激活連接。如果根據(jù)接收方的Ledger，發(fā)送方不是可信代理（傳輸?shù)陀诹?#xff0c;或大量未償還債務(wù)），接收方可以選擇忽略該請求。這應(yīng)該通過ignore_cooldown超時以概率方式完成，以便糾正錯誤并阻止攻擊者。 如果激活連接，接收器將使用本地版本的Ledger初始化Peer對象并設(shè)置last_seen時間戳。然后，它將收到的Ledger與自己的Ledger進行比較。如果它們完全匹配，則連接已打開。如果它們不匹配，則對等方創(chuàng)建一個新的歸零分類帳并發(fā)送它。
當連接打開時，節(jié)點廣播他們的want_list到所有連接的peers。完成這部分工作必須滿足（a)打開連接，（b）在一個隨機周期超時后，（c)在want_list發(fā)生改變，以及（d)在接收到一個新區(qū)塊后。
在接收到want_list后，節(jié)點做好存儲。然后校驗是否存在想要的區(qū)塊。如果有，依據(jù)BitSwap Strategy發(fā)送出去。
發(fā)送塊很簡單。 節(jié)點只是傳輸數(shù)據(jù)塊。在接收到所有數(shù)據(jù)后，接收器計算Multihash校驗和以驗證它是否與預(yù)期數(shù)據(jù)匹配，并返回確認。在完成正確傳輸塊之后，接收器將塊從need_list移動到have_list，并且接收方和發(fā)送方都更新其分類賬以反映傳輸?shù)母郊幼止?jié)。 如果傳輸驗證失敗，則發(fā)送方發(fā)生故障或攻擊接收方。接收方可以自由拒絕進一步的交易。請注意， BitSwap期望在可靠的傳輸通道上運行，因此傳輸錯誤–這可能會導(dǎo)致對誠實發(fā)件人的錯誤處罰–預(yù)計會在將數(shù)據(jù)提供給BitSwap之前被捕獲.
Peer.close(Bool)close的最后參數(shù)表明拆除連接的意圖是否是發(fā)送者。如果為false，接收方可以選擇立即重新打開連接。這避免了過早關(guān)閉。應(yīng)在兩種情況下關(guān)閉對等連接：
?silence_wait超時已過期，但未收到來自對等方的任何消息（默認BitSwap使用30秒）。該節(jié)點發(fā)出Peer.close（false）。
?節(jié)點正在退出，BitSwap正在關(guān)閉。在這種情況下，節(jié)點發(fā)出Peer.close（true）。
收到消息后，收件人和發(fā)件人都會拆除連接，清除存儲的任何狀態(tài)。如果有用的話，可以存儲Ledger以供將來使用。
注意事項：
?應(yīng)忽略非活動連接上的Non-open消息。在send_block消息的情況下，接收器可以檢查塊以查看是否所需并且正確，如果是這樣，請使用它。無論如何，所有這些無序消息都會觸發(fā)來自接收器的close(flase)消息以強制重新初始化連接。
Object Merkle DAG
DHT和BitSwap允許IPFS形成一個龐大的P2P系統(tǒng)，用于快速、穩(wěn)健地存儲和分發(fā)區(qū)塊。 除此之外，IPFS還構(gòu)建了一個MerkleDAG，一個有向無環(huán)圖，其中對象之間的鏈接是嵌入源中的目標的加密哈希。這是Git數(shù)據(jù)結(jié)構(gòu)的概括。 MerkleDAGs為IPFS提供了許多有用的屬性，包括：
1.內(nèi)容尋址：所有內(nèi)容由其多哈校驗的唯一標識，包括鏈接。
2.防篡改：所有內(nèi)容都通過校驗和進行驗證。 如果數(shù)據(jù)被篡改或損壞，IPFS會檢測到它。
3.重復(fù)數(shù)據(jù)刪除：包含完全相同內(nèi)容的所有對象都相同，并且只存儲一次。這對于索引對象（例如gittrees和commits）或數(shù)據(jù)的公共部分特別有用。
IPFS對象格式是：
IPFS Merkle DAG是一種非常靈活的數(shù)據(jù)存儲方式。唯一的要求是對象引用是（a）內(nèi)容尋址，（b）以上述格式編碼。 IPFS授予應(yīng)用程序?qū)?shù)據(jù)字段的完全控制權(quán);應(yīng)用程序可以使用他們選擇的任何自定義數(shù)據(jù)格式，IPFS可能無法理解。單獨的對象內(nèi)鏈接表允許IPFS：
·在對象中列出所有對象引用，例如：
·解析查找字符串路徑，例如foo/bar/baz。給定一個對象，IPFS將第一個路徑組件解析為對象鏈接表中的哈希，獲取第二個對象，并使用下一個組件重復(fù)上述操作。因此，無論數(shù)據(jù)格式是什么，字符串路徑都可以遍歷Merkle DAG。
·解析遞歸引用的所有對象：
原始數(shù)據(jù)字段和公共鏈接結(jié)構(gòu)是在IPFS之上構(gòu)造任意數(shù)據(jù)結(jié)構(gòu)的必要組件。雖然很容易看出Git對象模型如何適合這個DAG，但請考慮以下其他潛在的數(shù)據(jù)結(jié)構(gòu)：（a）鍵值存儲（b）傳統(tǒng)關(guān)系數(shù)據(jù)庫（c）Linked Data triple storesLinked Data triple stores（d）鏈接文檔發(fā)布系統(tǒng)linked document publishing systems（e）鏈接通信平臺（f）加密貨幣區(qū)塊鏈。 這些都可以在IPFS Merkle DAG之上建模，它允許任何這些系統(tǒng)使用IPFS作為更復(fù)雜應(yīng)用程序的傳輸協(xié)議。
3.5.1 Paths
可以使用字符串路徑API遍歷IPFS對象。路徑可以像在傳統(tǒng)UNIX文件系統(tǒng)和Web中一樣工作。 Merkle DAG鏈接使其易于遍歷。 請注意，IPFS中的完整路徑具有以下形式：
# format /ipfs/<hash-of-object>/<name-path-to-object> # example /ipfs/XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x/foo.txt/ipfs前綴允許在標準安裝點安裝到現(xiàn)有系統(tǒng)而不會發(fā)生沖突（安裝點名稱當然是可配置的）。 第二個路徑組件（首先在IPFS中）是對象的哈希。情況總是如此，因為沒有全局根。根對象有個不可能的任務(wù)：將處理分布式（并且可能是斷開連接的）環(huán)境中的數(shù)百萬個對象的一致性的。相反，我們使用內(nèi)容尋址來模擬根。 所有對象始終可以通過哈希訪問。 注意這意味著在路徑/bar/baz中給出三個對象，所有人都可以訪問最后一個對象：
/ipfs/<hash-of-foo>/bar/baz /ipfs/<hash-of-bar>/baz /ipfs/<hash-of-baz>3.5.2 本地對象Local Objects
IPFS客戶端需要一些本地存儲和一個外部系統(tǒng)，用于存儲和檢索IPFS管理的對象的本地原始數(shù)據(jù)。存儲類型取決于節(jié)點的用例。在大多數(shù)情況下，這只是磁盤空間的一部分（由本機文件系統(tǒng)管理，由kv存儲系統(tǒng)，如leveldb，或直接由IPFS客戶端管理）。在其他情況下，例如非持久性緩存，此存儲只是RAM的一部分。
最終，IPFS中可用的所有塊都在某個節(jié)點的本地存儲中。當用戶請求對象時，至少可以臨時找到，下載和存儲它們。 這為此后的一些可配置時間提供了快速查找。
3.5.3 對象固定 Object Pinning
希望確保特定對象生存的節(jié)點可以通過固定對象來實現(xiàn)。 這可確保對象保留在節(jié)點的本地存儲中。 固定可以遞歸完成，也可以固定所有鏈接的后代對象。 然后指向的所有對象都存儲在本地。 這對于保存文件（包括引用）特別有用。這也使IPFS成為一個永久鏈接的Web，而對象可以確保他們指向的其他對象是存在的。
3.5.4 發(fā)布對象 Publishing Objects
IPFS是全球分布的。 它旨在允許數(shù)百萬用戶的文件一起共存。具有內(nèi)容哈希尋址的DHT允許以公平，安全和完全分布的方式發(fā)布對象。 任何人都可以通過簡單地將其鍵添加到DHT，把自己加入到Peers，并向其他用戶提供對象的路徑來發(fā)布對象。 請注意，對象本質(zhì)上是不可變的，就像在Git中一樣。新版本的哈希值不同，因此是新對象。 跟蹤版本是其他版本控制對象的工作。
3.5.5 Object-level Cryptography
IPFS可以處理對象級加密操作。加密或簽名的對象包裝在一個特殊的幀中，允許加密或驗證原始字節(jié)。
type EncryptedObject struct { Object []bytes // raw object data encrypted Tag []bytes // optional tag for encryption groups } type SignedObject struct { Object []bytes // raw object data signed Signature []bytes // hmac signature PublicKey []multihash // multihash identifying key }加密操作會更改對象的哈希值，從而定義不同的對象。IPFS自動驗證簽名，并可以使用用戶指定的密鑰鏈解密數(shù)據(jù)。 加密對象的鏈接也受到保護，沒有解密密鑰就無法進行遍歷?？梢栽谝粋€密鑰下加密父對象，子對象在另一個密鑰下加密或不加密。這可以確保鏈接共享對象的安全。
3.6 Files
IPFS還定義了一組對象，用于在MerkleDAG之上對版本化文件系統(tǒng)進行建模。這個對象模型類似于Git：
1. block：可變大小的數(shù)據(jù)塊。
2. list：塊或其他列表的集合。
3. tree：區(qū)塊，列表或其他樹的集合。
4. commit：某棵樹的版本歷史中的快照。
我希望完全使用Git對象格式，但不得不離開以介紹在分布式文件系統(tǒng)中有用的某些功能，即（a）快速查找大小（對象中添加了聚合字節(jié)大小），（b）大文件重復(fù)數(shù)據(jù)刪除（添加列表對象），以及（c）將commits嵌入到樹中。盡管如此，IPFS文件對象與Git足夠相似，可以實現(xiàn)兩者之間的轉(zhuǎn)換。此外，可以引入轉(zhuǎn)換一組Git對象而不會丟失任何信息（unix文件權(quán)限等）。
注意：下面的文件對象格式使用JSON。請注意，雖然ipfs包含導(dǎo)入/導(dǎo)出到JSON，但此結(jié)構(gòu)實際上是使用protobufs進行二進制編碼，
3.6.1 File Object: blob
blob對象包含可尋址的數(shù)據(jù)單元，并使用文件表示。 IPFS塊類似于Git blob或文件系統(tǒng)數(shù)據(jù)塊。它們存儲用戶的數(shù)據(jù)。 請注意，IPFS文件可以由lists和blobs表示。 Blob沒有鏈接。
{ "data": "some data here", // blobs have no links }3.6.2 File Object: list
list對象表示由多個IPFS blob組成的大型或去重文件。 列表包含有序的blob或列表對象序列。
從某種意義上說，IPFS列表的功能類似于帶有間接塊的文件系統(tǒng)文件。由于列表可以包含其他列表，因此可以使用包括鏈接列表和平衡樹的拓撲。同一節(jié)點出現(xiàn)在多個位置的定向圖允許文件內(nèi)部去重。 當然，循環(huán)是不可能的，因為哈希尋址強制執(zhí)行。
3.6.3 File Object: tree
IPFS中的tree對象類似于Git中的tree對象：它表示一個目錄，一個哈希名稱的映射。哈希引用blobs，lists，其他trees或commits。 請注意，Merkle DAG已經(jīng)實現(xiàn)了傳統(tǒng)路徑命名。
{ "data": ["blob", "list", "blob"], // trees have an array of object types as data "links": [ { "hash": "XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x", "name": "less", "size": 189458 }, { "hash": "XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5", "name": "script", "size": 19441 }, { "hash": "XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z", "name": "template", "size": 5286 } // trees do have names ] }3.6.4 File Object: commit
IPFS中的commit對象表示任何對象的版本歷史的快照。 它類似于Git，但可以指向任何類型的對象。 它還鏈接到作者對象。
{ "data": { "type": "tree", "date": "2014-09-20 12:44:06Z", "message": "This is a commit message." }, "links": [ { "hash": "XLa1qMBKiSEEDhojb9FFZ4tEvLf7FEQdhdU", "name": "parent", "size": 25309 }, { "hash": "XLGw74KAy9junbh28x7ccWov9inu1Vo7pnX", "name": "object", "size": 5198 }, { "hash": "XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm", "name": "author", "size": 109 } ] }3.6.5 Version control
commit對象表示一個對象的版本歷史的特定快照。兩個不同commit的對象（和子對象）的對比，透露了文件系統(tǒng)的兩個版本之間的差異。只要單個commit和它引用的所有子對象可以訪問，就可以檢索所有先前版本，并且可以瀏覽文件系統(tǒng)變更的完整歷史記錄。這不屬于MerkleDAG對象模型。IPFS用戶可以使用Git版本控制工具的全部功能。 對象模型兼容，但不相同?？梢?#xff08;a）構(gòu)建一個修改過的Git工具版本以適用于IPFS對象圖，（b）構(gòu)建一個掛載的FUSE文件系統(tǒng)，將IPFS樹掛載為Git倉庫，將Git文件系統(tǒng)讀/寫轉(zhuǎn)換為IPFS格式。
3.6.6 Filesystem Paths
正如我們在Merkle DAG部分中看到的那樣，可以使用字符串路徑API遍歷IPFS對象。IPFS文件對象的設(shè)計使IPFS掛載在UNIX文件系統(tǒng)上更簡單。為了將tree表示為目錄，tree下沒有數(shù)據(jù)。并且commits可以表示為目錄，也可以完全隱藏在文件系統(tǒng)中。
3.6.7 Splitting Files into Lists and Blob
版本控制和分發(fā)大型文件的主要挑戰(zhàn)之一是找到將它們拆分為獨立塊的正確方法。IPFS提供以下備選方案，而不是假設(shè)它可以適用每一種類型的文件：
（a）在LBFS中使用Rabin指紋來選擇合適的塊邊界。
（b）使用rsync滾動校驗和算法來檢測版本之間已更改的塊。
（c）允許用戶針對特定文件自定義塊分割函數(shù)。
3.6.8 Path Lookup Performance
基于路徑訪問來遍歷對象圖。檢索某個對象需要先在DHT中查找key，連接到peer及誒單并檢索其塊。 這是相當大的開銷，特別是在查找包含許多組件的路徑時。 這可以通過以下方式減輕：
?tree caching：由于所有對象都是散列尋址的，因此可以無限期地緩存它們。此外，tree往往很小，因此IPFS優(yōu)先考慮將它們緩存在blob上。
?flattened tree：對于任何給定的tree，可以構(gòu)造一個特殊的flattenedTree來列出從樹可到達的所有對象。 flattened tree中的命名實際上是從原始樹分開的帶有斜杠的。
Figure 2-Sample Object Graph
例如，上面的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: Naming and Mutable State
到目前為止，IPFS堆棧形成了p2p塊交換，構(gòu)建了內(nèi)容尋址的對象DAG。它用于發(fā)布和檢索不可變對象。 它甚至可以跟蹤這些對象的版本歷史記錄。但是，缺少一個關(guān)鍵組件：可變命名。沒有它，新內(nèi)容的所有通信必須在外帶發(fā)送IPFS鏈接。 需要的是在同一路徑上檢索可變狀態(tài)的某種方法。 值得說明的原因(如果最終需要可變數(shù)據(jù)),我們努力建立一個不可變的Merkle DAG。 考慮從Merkle DAG中放棄IPFS的屬性：對象可以（a）通過其哈希檢索，（b）檢查完整性，（c）鏈接到其他人，以及（d）無限緩存。
在某種意義上：Objects are permanent
這些是高性能分布式系統(tǒng)的關(guān)鍵屬性，其中數(shù)據(jù)在網(wǎng)絡(luò)鏈路上移動的成本很高。對象內(nèi)容尋址通過以下方式構(gòu)建Web：（a）顯著的帶寬優(yōu)化，（b）不可信內(nèi)容服務(wù)，（c）永久鏈接，以及（d）對任何對象及其引用進行完全永久備份的能力。
Merkle DAG，不可變的內(nèi)容尋址對象，以及Naming，指向MerkleDAG的可變指針，采用了在許多成功的分布式系統(tǒng)中使用的二分法。 這些包括Git版本控制系統(tǒng)，其不可變對象和可變引用; 和Plan9[？]，UNIX的分布式繼承者，具有可變的Fossil [？]和不可變的Venti [？]文件系統(tǒng)。 LBFS [？]也使用可變索引和不可變塊。
3.7.1 Self-Certified Names
使用SFS的命名方案[12,11]為我們提供了一種在密碼學全局命名空間中構(gòu)造可自變的自認證名稱的方法。 IPFS的方案如下：
1.回想一下IPFS中：NodeId = hash(node.PubKey)
2.我們分配每一個用戶一個可變命名空間：/ipns/
3.用戶可以將對象發(fā)布到此路徑，并用私鑰簽名，比如說：
/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/
4.當其他用戶檢索對象時，他們可以檢查簽名是否與公鑰和NodeId匹配。這驗證了用戶發(fā)布的Object的真實性，實現(xiàn)了可變的狀態(tài)回溯。
請注意以下細節(jié)：
?ipns（InterPlanetary NameSpace）單獨的前綴是為程序和人類讀者建立一個易于識別的可變和不可變路徑之間的區(qū)別。
?因為這不是內(nèi)容尋址對象，所以發(fā)布它依賴于IPFS中唯一可變的狀態(tài)分發(fā)系統(tǒng)，即路由系統(tǒng)。 該過程是（1）將對象發(fā)布為常規(guī)不可變IPFS對象，（2）在路由系統(tǒng)上將其散列作為元數(shù)據(jù)值發(fā)布：
routing.setValue(NodeId, )
?發(fā)布的Object中的任何鏈接都充當命名空間中的子名稱：
/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/
/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/docs
/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/docs/ipfs
?建議發(fā)布commit對象或具有版本歷史記錄的其他對象，以便客戶端可以找到舊名稱。這留給了用戶選項(并不強制)。
請注意，當用戶發(fā)布此Object時，無法以相同的方式再發(fā)布它
3.7.2 Human Friendly Names
雖然IPNS確實是一種分配和重新分配名稱的方式，但它不是非常用戶友好，因為它將長哈希值暴露為名稱，這是眾所周知難以記住的。 這些適用于URL，但不適用于多種離線傳輸。 因此，IPFS通過以下技術(shù)提高了IPNS的用戶友好性。
Peer Links
在SFS的鼓勵下，用戶可以將其他用戶的對象直接鏈接到他們自己的對象（命名空間，主頁等）。這樣做的好處是還可以創(chuàng)建信任網(wǎng)（并支持舊的證書頒發(fā)機構(gòu)模型）：
DNS TXT IPNS Records.
如果/ipns/是一個有效的域名,IPFS在DNS TXT記錄表中查找Key的ipns。IPFS將該值解釋為對象哈希或另一個IPNS路徑：
Proquint可發(fā)音標識符 Proquint Pronounceable Identifiers
一直有將二進制編碼成可發(fā)音單詞的方案。 IPNS支持Proquint [？]。 從而：
名稱縮短服務(wù)。Name Shortening Services.
必然會出現(xiàn)提供名稱縮短服務(wù)，為用戶提供名稱空間。 這類似于我們今天看到的DNS和Web URL：
3.8 Using IPFS
IPFS旨在以多種不同方式使用。 以下是我將要介紹的一些用例：
1.作為已掛載的全局文件系統(tǒng)，在/ipfs和/ipns下。
2.作為已安裝的個人同步文件夾，可自動發(fā)布，發(fā)布和備份任何寫入。
3.作為加密文件或數(shù)據(jù)共享系統(tǒng)。
4.作為所有軟件的版本化軟件包管理器。
5.作為虛擬機的根文件系統(tǒng)。
6.作為VM的引導(dǎo)文件系統(tǒng)（在管理程序下）。
7.作為數(shù)據(jù)庫：應(yīng)用程序可以直接寫入MerkleDAG數(shù)據(jù)模型，并獲得IPFS提供的所有版本控制，緩存和分發(fā)。
8.作為鏈接（和加密）通信平臺。
9.作為完整性檢查CDN的大文件（沒有SSL）。
10.作為加密的CDN。
11.在網(wǎng)頁上，作為網(wǎng)絡(luò)CDN。
12.作為一個新的永久網(wǎng)絡(luò)，鏈接不會消失。
IPFS實現(xiàn)目標：
（a）在您自己的應(yīng)用程序中導(dǎo)入的IPFS庫。
（b）直接操縱對象的命令行工具。
（c）使用FUSE [？]或作為內(nèi)核模塊安裝的文件系統(tǒng)。
4. 將來 THE FUTURE
IPFS背后的思想是學術(shù)界和開源領(lǐng)域數(shù)十年成功的分布式系統(tǒng)研究的產(chǎn)物。IPFS綜合了迄今為止最成功系統(tǒng)中的許多最佳創(chuàng)意。 除了BitSwap這是一種新穎的協(xié)議之外，IPFS的主要貢獻在于系統(tǒng)的耦合和設(shè)計的綜合。
IPFS是對新的分散式互聯(lián)網(wǎng)基礎(chǔ)設(shè)施的雄心勃勃的愿景，可以在其上構(gòu)建許多不同類型的應(yīng)用程序。 至少，它可以用作全局，已安裝，版本化的文件系統(tǒng)和命名空間，或者用作下一代文件共享系統(tǒng)。 在最好的情況下，它可以將網(wǎng)絡(luò)推向新的視野，在那里發(fā)布有價值的信息并不會將其托管在發(fā)布者身上，而是在那些感興趣的人身上，用戶可以信任他們收到的內(nèi)容而不信任他們從中收到的Peers，以及舊的 但重要的文件不會丟失。 期待IPFS將我們帶入永恒網(wǎng)絡(luò)。
借助google翻譯加自己理解做了調(diào)整，個人在有道筆記上做記錄，現(xiàn)分享出來，有翻譯或理解不準確的，可以一起交流
http://note.youdao.com/noteshare?id=c21f3c58a286fa1d8429a6cb6ee09821&sub=EE1C5448B7DC4622B2B93E98D19EB1B3
總結(jié)
以上是生活随笔為你收集整理的IPFS(DRAFT 3) 中文版白皮书的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 前端学习（2516）：传值和引用
- 下一篇： 前端学习（2755）：配置tabber其