IPFS - 可快速索引的版本化的点对点文件系统（草稿3）
摘要
星際文件系統(tǒng)是一種點對點的分布式文件系統(tǒng)， 旨在連接所有有相同的文件系統(tǒng)的計算機設備。在某些方面， IPFS類似于web, 但web 是中心化的，而IPFS是一個單一的Bittorrent 群集， 用git 倉庫分布式存儲。換句話說， IPFS 提供了高吞吐量的內(nèi)容尋址塊存儲模型， 具有內(nèi)容尋址的超鏈接。這形成了一個廣義的Merkle DAG 數(shù)據(jù)結(jié)構，可以用這個數(shù)據(jù)結(jié)構構建版本文件系統(tǒng)，區(qū)塊鏈，甚至是永久性網(wǎng)站。。IPFS 結(jié)合了分布式哈希表， 帶有激勵機制的塊交換和自我認證命名空間。IPFS 沒有單故障點， 節(jié)點不需要相互信任。
1. 介紹
在全球分布式文件系統(tǒng)這領域， 已經(jīng)有許多人的嘗試。一些系統(tǒng)已經(jīng)取得了重大的成功， 而很多卻完全失敗了。在學術嘗試中， AFS【6】就是成功的例子，如今已經(jīng)得到廣泛的應用， 然而，其他的【7， ？】卻沒有得到相同的結(jié)果。在學術界之外，應用最廣泛的是面向音視頻媒體的點對點文件共享系統(tǒng)。 最值得注意的是， Napster, KaZaA 和BitTorrent[2]部署的文件分發(fā)系統(tǒng)支持1億用戶的同時在線。即使在今天， BitTorrent 也維持著每天千萬節(jié)點的活躍數(shù)。 基于這些學術文件系統(tǒng)理論而實現(xiàn)的應用程序有很多的用戶量， 然而，這些系統(tǒng)理論是在應用層，而沒有放在基礎層。以致沒有出現(xiàn)通用的文件系統(tǒng)基礎框架， 給全球提供低延遲的分發(fā)。
也許是因為HTTP這樣“足夠好“的系統(tǒng)已經(jīng)存在。到目前為止，HTTP已經(jīng)作為“分布式文件系統(tǒng)“的協(xié)議，并且已經(jīng)大量部署，再與瀏覽器相結(jié)合，具有巨大的技術和社會影響力。在現(xiàn)在， 它已經(jīng)成為互聯(lián)網(wǎng)傳輸文件的事實標準。然而，他沒有采用最近15年的發(fā)明的數(shù)十種先進的文件分發(fā)技術。 從一方面講， 由于向后兼容的限制 和 當前新模式的投入， 不斷發(fā)展http web 的基礎設施幾乎是不可能的。但從一個角度看， 從http 出現(xiàn)以來， 已經(jīng)有許多新協(xié)議出現(xiàn)并被廣泛使用。升級http協(xié)議雖然能引入新功能和加強當前http協(xié)議，但會降低用戶的體驗。
有些行業(yè)已經(jīng)擺脫使用HTTP 這么久， 因為移動小文件相對便宜，即使對擁有大流量的小組織也是如此。但是，隨著新的挑戰(zhàn)，我們正在進入數(shù)據(jù)分發(fā)的新紀元。
- （a）托管和分發(fā)PB級數(shù)據(jù)集，
- （b）跨組織的大數(shù)據(jù)計算，
- （c）大批量的高清晰度按需或?qū)崟r媒體流，
- （d）大規(guī)模數(shù)據(jù)集的版本化和鏈接，
- （e）防止意外丟失重要文件等。其中許多可以歸結(jié)為“大量數(shù)據(jù)，無處不在”。由于關鍵功能和帶寬問題，我們已經(jīng)為不同的數(shù)據(jù)放棄了HTTP 分銷協(xié)議。下一步是使它們成為web自己的一部分。
正交于有效的數(shù)據(jù)分發(fā)，版本控制系統(tǒng)，已經(jīng)設法開發(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)設計[9]，因為其內(nèi)容涉及到Merkle DAG數(shù)據(jù)模型，能夠?qū)崿F(xiàn)強大的文件分發(fā)策略。還有待探討的是，這種數(shù)據(jù)結(jié)構如何影響面向高吞吐量的文件系統(tǒng)的設計，以及如何升級Web本身。
本文介紹了IPFS，一種新穎的對等版本控制的文件系統(tǒng)，旨在調(diào)和這些問題。 IPFS綜合了許多以前成功的系統(tǒng)的優(yōu)點。 IPFS產(chǎn)生了突出的效果， 甚至比參考的這些系統(tǒng)的總和還要好。IPFS的核心原則是將所有數(shù)據(jù)建模為同一Merkle DAG的一部分。2. 背景
本節(jié)回顧了IPFS所采用成功的點對點系統(tǒng)技術的重要屬性。2.1 分布式哈希表(DHT)
分布式散列表（DHT）被廣泛用于協(xié)調(diào)和維護關于對等系統(tǒng)的元數(shù)據(jù)。比如，MainlineDHT 是一個去中心化哈希表，他可追蹤查找所有的對等節(jié)點。2.1.1 KADEMLIA DHT
Kademlia[10] 是受歡迎的DHT, 它提供： - 1.通過大量網(wǎng)絡進行高效查詢：查詢平均聯(lián)系人O(log2N)節(jié)點。 （例如，20跳10萬個節(jié)點的網(wǎng)絡）
- 2.低協(xié)調(diào)開銷：優(yōu)化數(shù)量的控制消息發(fā)送到其他節(jié)點。
- 3.抵抗各種攻擊，喜歡長壽節(jié)點。
- 4.在對等應用中廣泛使用，包括Gnutella和BitTorrent，形成了超過2000萬個節(jié)點的網(wǎng)絡[16]。
2.1.2 CORAL DSHT
雖然一些對等文件系統(tǒng)直接在DHT中存儲數(shù)據(jù)塊，這種“數(shù)據(jù)存儲在不需要的節(jié)點會亂費存儲和帶寬”[5]。Coral DSHT擴展了Kademlia三個特別重要的方式：
- 1.Kademlia在ids為“最近”（使用XOR-distance）的關鍵節(jié)點中存儲值。這不考 慮應用程序數(shù)據(jù)的局部性，忽略“遠”可能已經(jīng)擁有數(shù)據(jù)的節(jié)點，并強制“最近”節(jié)點存儲它，無論它們是否需要。這浪費了大量的存儲和帶寬。相反，Coral 存儲了地址， 該地址的對等節(jié)點可以提供相應的數(shù)據(jù)塊。
- 2.Coral將DHT API從get_value(key)換成了get_any_values(key)（DSHT中的“sloppy”）中。這仍然是因為Coral用戶只需要一個（工作）的對等體，而不是完整的列表。作為回報，Coral可以僅將子集分配到“最近”的節(jié)點，避免熱點（當密鑰變得流行時，重載所有最近的節(jié)點）。
- 3.另外，Coral根據(jù)區(qū)域和大小組織了一個稱為群集的獨立DSHT層次結(jié)構。這使得節(jié)點首先查詢其區(qū)域中的對等體，“查找附近的數(shù)據(jù)而不查詢遠程節(jié)點”[5]并大大減少查找的延遲。
2.1.3 S/KADEMLIA DHT
S/Kademlia[1] 擴展了Kademlia, 用于防止惡意的攻擊。有如下兩方面的方法： - 1.S/Kad 提供了方案來保證NodeId的生成已經(jīng)防止Sybill攻擊。它需要節(jié)點產(chǎn)生PKI公私鑰對。從中導出他們的身份，并彼此間簽名。一個方案使用POW工作量證明，使得生成Sybills成本高昂。
- 2.S/Kad 節(jié)點在不相交的路徑上查找直， 即使網(wǎng)絡中存在大量的不誠實節(jié)點，也能確保誠實節(jié)點可以互相鏈接。即使網(wǎng)絡中存在一半的不誠實節(jié)點，S/Kad 也能達到85%的成功率。
2.2 塊交換 - BitTorrent
BitTorrent[3] 是一個廣泛成功應用的點對點共享文件系統(tǒng)，它可以在存在不信任的對等節(jié)點（群集）的協(xié)作網(wǎng)絡中分發(fā)各自的文件數(shù)據(jù)片。從BitTorrent和它的生態(tài)系統(tǒng)的關鍵特征， IPFS得到啟示如下： - 1.BitTorrent的數(shù)據(jù)交換協(xié)議使用了一種bit-for-tat的激勵策略， 可以獎勵對其他方面做貢獻的節(jié)點，懲罰只榨取對方資源的節(jié)點。
- 2.BitTorrent對等體跟蹤文件的可用性，優(yōu)先發(fā)送稀有片段。這減輕了seeds節(jié)點的負擔， 讓non-seeds節(jié)點有能力互相交易。
- 3.對于一些剝削帶寬共享策略， BitTorrent的標準tit-for-tat策略是非常脆弱的。 然而，PropShare[8]是一種不同的對等帶寬分配策略， 可以更好的抵制剝削戰(zhàn)略， 提高群集的表現(xiàn)。
2.3. 版本控制系統(tǒng)- Git
版本控制系統(tǒng)提供了對隨時間變化的文件進行建模的設施，并有效地分發(fā)不同的版本。流行版本控制系統(tǒng)Git提供了強大的Merkle DAG對象模型，以分布式友好的方式捕獲對文件系統(tǒng)樹的更改。 - 1.不可更改的對象表示文件（blob），目錄（樹）和更改（提交）。
- 2.通過加密hash對象的內(nèi)容，讓對象可尋址。
- 3.鏈接到其他對象是嵌入的，形成一個Merkle DAG。這提供了很多有用的完整和work-flow屬性。
- 4.很多版本元數(shù)據(jù)（分支，標示等等）都只是指針引用，因此創(chuàng)建和更新的代價都小。
- 5.版本改變只是更新引用或者添加對象。
-
6.分布式版本改變對其他用戶而言只是轉(zhuǎn)移對象和更新遠程引用。
2.4 自我認證認文件系統(tǒng)-SFS
SFS [ 12，11 ]提出了兩個引人注目的實現(xiàn)（a）分布式信任鏈，和（b）平等共享的全局命名空間。SFS引入了一種自我建構技術—注冊文件：尋址遠程文件系統(tǒng)使用以下格式：
1 2 3 /sfs/<Location>:<HostID> Location:代表的是服務網(wǎng)絡地方 HostID = hash(public_key || Location) 因此SFS文件系統(tǒng)的名字認證了它的服務，用戶可以通過服務提供的公鑰來驗證，協(xié)商一個共享的私鑰，保證所有的通信。所有的SFS實例都共享了一個全局的命名空間，這個命名空間的名稱分配是加密的，不被任何中心化的body控制。
3. IPFS設計
IPFS是一個分布式文件系統(tǒng)，它綜合了以前的對等系統(tǒng)的成功想法，包括DHT，BitTorrent，Git和SFS。 IPFS的貢獻是簡化，發(fā)展和將成熟的技術連接成一個單一的內(nèi)聚系統(tǒng)，大于其部分的總和。 IPFS提供了編寫和部署應用程序的新平臺，以及一個新的分發(fā)系統(tǒng)版本化大數(shù)據(jù)。 IPFS甚至可以演進網(wǎng)絡本身。
IPFS是點對點的;沒有節(jié)點是特權的。 IPFS節(jié)點將IPFS對象存儲在本地存儲中。節(jié)點彼此連接并傳輸對象。這些對象表示文件和其他數(shù)據(jù)結(jié)構。 IPFS協(xié)議分為一組負責不同功能的子協(xié)議：
1. 身份?- 管理節(jié)點身份生成和驗證。描述在3.1節(jié)。
2.網(wǎng)絡?- 管理與其他對等體的連接，使用各種底層網(wǎng)絡協(xié)議?？膳渲玫摹Ｔ斠?.2節(jié)。
3.路由?- 維護信息以定位特定的對等體和對象。響應本地和遠程查詢。默認為DH??T，但可更換。在3.3節(jié)描述。
4.交換?- 一種支持有效塊分配的新型塊交換協(xié)議（BitSwap）。模擬市場，弱化數(shù)據(jù)復制。貿(mào)易策略可替換。描述在3.4節(jié)。
5.對象?- 具有鏈接的內(nèi)容尋址不可更改對象的Merkle DAG。用于表示任意數(shù)據(jù)結(jié)構，例如文件層次和通信系統(tǒng)。詳見第3.5節(jié)。
6.文件?- 由Git啟發(fā)的版本化文件系統(tǒng)層次結(jié)構。詳見3.6節(jié)。
7.命名?- 自我認證的可變名稱系統(tǒng)。詳見3.7節(jié)。
這些子系統(tǒng)不是獨立的;它們是集成在一起，互相利用各自的屬性。但是，分開描述它們是有用的，從下到上構建協(xié)議棧。符號：Go語言中指定了以下數(shù)據(jù)結(jié)構和功能
3.1 身份
節(jié)點由NodeId標識，這是使用S / Kademlia的靜態(tài)加密難題[1]創(chuàng)建的公鑰的密碼散列。節(jié)點存儲其公私鑰（用密碼加密）。用戶可以在每次啟動時自由地設置一個“新”節(jié)點身份，盡管這會損失積累的網(wǎng)絡利益。激勵節(jié)點保持不變。
| 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) |
?
首次連接時，對等體交換公鑰，并檢查：hash（other.PublicKey）等于other.NodeId。如果沒有，則連接被終止
關于加密函數(shù)的注意事項：
IPFS不是將系統(tǒng)鎖定到一組特定的功能選擇，而是支持自我描述的值。哈希摘要值以多重哈希格式存儲，其包括指定使用的哈希函數(shù)的頭和以字節(jié)為單位的摘要長度。例如：
| 1 | <function code><digest length><digest bytes> |
?
這允許系統(tǒng)
- （a）選擇最佳功能用例（例如，更強的安全性與更快的性能），
- （b）隨著功能選擇的變化而演變。自描述值允許兼容使用不同的參數(shù)選擇。
3.2 網(wǎng)絡
IPFS節(jié)點與數(shù)百個其他節(jié)點進行定期通信網(wǎng)絡中的節(jié)點，可能跨越廣域網(wǎng)絡。IPFS網(wǎng)絡堆棧功能： - 傳輸層： IPFS可以使用任何傳輸協(xié)議，并且最適合WebRTC DataChannels [？]（用于瀏覽器連接）或uTP（LEDBAT [14]）。
- 可靠性： 如果底層網(wǎng)絡不提供可靠性，IPFS可使用uTP（LEDBAT [14]）或SCTP [15]來提供??可靠性。
- 可連接性：IPFS還可以使用ICE NAT穿墻打洞技術[13]。
- 完整性：可以使用哈希校驗和來檢查郵件的完整性。
- 可驗證性：可以使用發(fā)送者的公鑰使用HMAC來檢查消息的真實性。
3.2.1對等節(jié)點尋址注意事項：
IPFS可以使用任何網(wǎng)絡; 但它不承擔對IP的獲取以及不直接依賴于ip層。這允許在覆蓋網(wǎng)絡中使用IPFS。
IPFS將地址存儲為多層地址，這個多層地址是由字節(jié)字符串組成的， 以便于給底層網(wǎng)絡使用。多層地址提供了一種方式來表示地址及其協(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é)點需要一個路由系統(tǒng)， 這個路由系統(tǒng)可用于查找：
- （a）其他同伴的網(wǎng)絡地址，
- （b）專門用于服務特定對象的對等節(jié)點。
IPFS使用基于S / Kademlia和Coral的DSHT，在2.1節(jié)中具體介紹過。在對象大小和使用模式方面， IPFS 類似于Coral[5] 和Mainline[16], 因此，IPFS DHT根據(jù)其大小對存儲的值進行區(qū)分。小的值（等于或小于1KB）直接存儲在DHT上。對于更大的值，DHT只存儲值索引，這個索引就是一個對等節(jié)點的NodeId, 該對等節(jié)點可以提供對該類型的值的具體服務。
DSHT的接口如下：1 2 3 4 5 6 7 type IPFSRouting interface { FindPeer(node NodeId) // 獲取特定NodeId的網(wǎng)絡地址。 SetValue(key []bytes, value []bytes) // 往DHT存儲一個小的元數(shù)據(jù)。 GetValue(key []bytes) // 從DHT獲取元數(shù)據(jù)。 ProvideValue(key Multihash) // 聲明這個節(jié)點可一個提供一個大的數(shù)據(jù)。 FindValuePeers(key Multihash, min int) // 獲取服務于該大數(shù)據(jù)的節(jié)點。 }
注意：不同的用例將要求基本不同的路由系統(tǒng)（例如廣域網(wǎng)中使用DHT，局域網(wǎng)中使用靜態(tài)HT）。因此，IPFS路由系統(tǒng)可以根據(jù)用戶的需求替換的。只要使用上面的接口就可以了，系統(tǒng)都能繼續(xù)正常運行。
3.4塊交換 - BitSwap協(xié)議
IPFS 中的BitSwap協(xié)議受到BitTorrent 的啟發(fā)，通過對等節(jié)點間交換數(shù)據(jù)塊來分發(fā)數(shù)據(jù)的。像BT一樣， 每個對等節(jié)點在下載的同時不斷向其他對等節(jié)點上傳已下載的數(shù)據(jù)。和BT協(xié)議不同的是， BitSwap 不局限于一個torrent文件中的數(shù)據(jù)塊。BitSwap 協(xié)議中存在一個永久的市場。 這個市場包括各個節(jié)點想要獲取的所有塊數(shù)據(jù)。而不管這些塊是哪些如.torrent文件中的一部分。這些快數(shù)據(jù)可能來自文件系統(tǒng)中完全不相關的文件。 這個市場是由所有的節(jié)點組成的。
雖然易貨系統(tǒng)的概念意味著可以創(chuàng)建虛擬貨幣，但這將需要一個全局分類賬本來跟蹤貨幣的所有權和轉(zhuǎn)移。這可以實施為BitSwap策略，并將在未來的論文中探討。
在基本情況下，BitSwap節(jié)點必須以塊的形式彼此提供直接的值。只有當跨節(jié)點的塊的分布是互補的時候，各取所需的時候，這才會工作的很好。 通常情況并非如此，在某些情況下，節(jié)點必須為自己的塊而工作。 在節(jié)點沒有其對等節(jié)點所需的（或根本沒有的）情況下，它會更低的優(yōu)先級去尋找對等節(jié)點想要的塊。這會激勵節(jié)點去緩存和傳播稀有片段， 即使節(jié)點對這些片段不感興趣。
3.4.1 - BITSWAP 信用
這個協(xié)議必須帶有激勵機制， 去激勵節(jié)點去seed 其他節(jié)點所需要的塊，而它們本身是不需要這些塊的。 因此， BitSwap的節(jié)點很積極去給對端節(jié)點發(fā)送塊，期待獲得報酬。但必須防止水蛭攻擊（空負載節(jié)點從不共享塊），一個簡單的類似信用的系統(tǒng)解決了這些問題：
- 1， 對等節(jié)點間會追蹤他們的平衡（通過字節(jié)認證的方式）。
- 2， 隨著債務增加而概率降低，對等者概率的向債務人發(fā)送塊。
注意的是，如果節(jié)點決定不發(fā)送到對等體，節(jié)點隨后忽略對等體的ignore_cooldown超時。 這樣可以防止發(fā)送者嘗試多次發(fā)送（洪水攻擊） （BitSwap默認是10秒）。3.4.2 BITSWAP的策略
BitSwap 對等節(jié)點采用很多不同的策略，這些策略對整個數(shù)據(jù)塊的交換執(zhí)行力產(chǎn)生了不同的巨大影響。在BT 中， 標準策略是明確規(guī)定的（tit-for-tat），其他不同的策略也已經(jīng)被實施，從BitTyrant [8]（盡可能分享）到BitThief [8]（利用一個漏洞，從不共享），到PropShare [8]（按比例分享）。BitSwap 對等體可以類似地實現(xiàn)一系列的策略（良好和惡意）。對于功能的選擇，應該瞄準： - 1.為整個交易和節(jié)點最大化交易能力。
- 2.為了防止空負載節(jié)點利用和損害交易。
- 3.高效抵制未知策略。
- 4.對可信任的對等節(jié)點更寬容。
探索這些策略的空白是未來的事情。在實踐中使用的一個選擇性功能是sigmoid，根據(jù)負債比例進行縮放：
讓負債比例在一個節(jié)點和它對等節(jié)點之間：1 r = bytes_sent / bytes_recv + 1
根據(jù)r，發(fā)送到負債節(jié)點的概率為：
| 1 | P(send | r ) = 1 ? ( 1/ ( 1 + exp(6 ? 3r) ) ) |
?
正如你看到的圖片1，當節(jié)點負債比例超過節(jié)點已建立信貸的兩倍，發(fā)送到負債節(jié)點的概率就會急速下降。
圖片1 當r增加時發(fā)送的概率負債比是信任的衡量標準：對于之前成功的互換過很多數(shù)據(jù)的節(jié)點會寬容債務，而對不信任不了解的節(jié)點會嚴格很多。這個(a)給與那些創(chuàng)造很多節(jié)點的攻擊者（sybill 攻擊）一個障礙。(b)保護了之前成功交易節(jié)點之間的關系，即使這個節(jié)點暫時無法提供數(shù)據(jù)。(c)最終阻塞那些關系已經(jīng)惡化的節(jié)點之間的通信，直到他們被再次證明。
3.4.3 BITSWAP 賬本
BitSwap節(jié)點保存了一個記錄與所有其他節(jié)點之間交易的賬本。這個可以讓節(jié)點追蹤歷史記錄以及避免被篡改。當激活了一個鏈接，BitSwap節(jié)點就會互換它們賬本信息。如果這些賬本信息并不完全相同，分類賬本將會重新初始化， 那些應計信貸和債務會丟失。 惡意節(jié)點會有意去失去“這些“賬本， 從而期望清除自己的債務。節(jié)點是不太可能在失去了應計信托的情況下還能累積足夠的債務去授權認證?；锇楣?jié)點可以自由的將其視為不當行為， 拒絕交易。
| 1 2 3 4 5 6 7 | type Ledger struct { owner NodeId partner NodeId bytes_sent int bytes_recv int timestamp Timestamp } |
?
節(jié)點可以自由的保留分布式賬本歷史，這不需要正確的操作，因為只有當前的分類賬本條目是有用的。節(jié)點也可以根據(jù)需要自由收集分布式帳本，從不太有用的分布式帳開始：老（其他對等節(jié)點可能不存在）和小。
3.4.4 BITSWAP 詳解
BitSwap 節(jié)點有以下簡單的協(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); } |
?
對等連接的生命周期草圖：
- 1.Open: 對等節(jié)點間發(fā)送ledgers 直到他們同意。
- 2.Sending: 對等節(jié)點間交換want_lists 和blocks。
- 3.Close: 對等節(jié)點斷開鏈接。
- 4.Ignored: （特殊）對等體被忽略（等待時間的超時）如果節(jié)點采用防止發(fā)送策略。
Peer.open(NodeId, Ledger).
當發(fā)生鏈接的時候，節(jié)點會初始化鏈接的賬本，要么保存一個份鏈接過去的賬本，要么創(chuàng)建一個新的被清零的賬本。然后，發(fā)送一個攜帶賬本的open信息給對等節(jié)點。
接收到一個open信息之后，對等節(jié)點可以選擇是否接受此鏈接。如果，根據(jù)接收者的賬本，發(fā)送者是一個不可信的代理（傳輸?shù)陀诹慊蛘哂泻艽蟮奈磧斶€的債務），接收者可能會選擇忽略這個請求。忽略請求是ignore_cooldown超時來概率性實現(xiàn)的，為了讓錯誤能夠有時間改正和攻擊者被挫敗。
如果鏈接成功，接收者用本地賬本來初始化一個Peer對象以及設置last_seen時間戳。然后，它會將接受到的賬本與自己的賬本進行比較。如果兩個賬本完全一樣，那么這個鏈接就被Open，如果賬本并不完全一致，那么此節(jié)點會創(chuàng)建一個新的被清零的賬本并且會發(fā)送此賬本。
Peer.send_want_list(WantList)
當鏈接已經(jīng)Open的時候，節(jié)點會廣發(fā)它們的want_list給所有已經(jīng)鏈接的對等節(jié)點。這個是在(a)open鏈接后(b)隨機間歇超時后(c)want_list改變后(d)接收到一個新的塊之后完成的。
當接收到一個want_list之后，節(jié)點會存儲它。然后，會檢查自己是否擁有任何它想要的塊。如果有，會根據(jù)上面提到的BitSwap策略來將want_list所需要的塊發(fā)送出去。
Peer.send_block(Block)
發(fā)送一個塊是直接了當?shù)摹９?jié)點只是傳輸數(shù)據(jù)塊。當接收到了所有數(shù)據(jù)的時候，接收者會計算多重hash校驗和來驗證它是否是自己所需數(shù)據(jù)，然后發(fā)送確認信息。
在完成一個正確的塊傳輸之后，接受者會將此塊從need_list一到have_list,最后接收者和發(fā)送者都會更新它們的賬本來反映出傳輸?shù)念~外數(shù)據(jù)字節(jié)數(shù)。
如果一個傳輸驗證失敗了，發(fā)送者要么會出故障要么會攻擊接收者，接收者可以選擇拒絕后面的交易。注意，BitSwap是期望能夠在一個可靠的傳輸通道上進行操作的，所以傳輸錯誤（可能會引起一個對誠實發(fā)送者錯誤的懲罰）是期望在數(shù)據(jù)發(fā)送給BitSwap之前能夠被捕捉到。
Peer.close(Bool)
傳給close最后的一個參數(shù)，代表close鏈接是否是發(fā)送者的意愿。如果參數(shù)值為false,接收者可能會立即重新open鏈接，這避免鏈過早的close鏈接。
一個對等節(jié)點close鏈接發(fā)生在下面兩種情況下： - silence_wait超時已經(jīng)過期，并且沒有接收到來自于對等節(jié)點的任何信息（BitSwap默認使用30秒），節(jié)點會發(fā)送Peer.close(false)。
- 在節(jié)點退出和BitSwap關閉的時候，節(jié)點會發(fā)送Peer.close(true).
接收到close消息之后，接收者和發(fā)送者會斷開鏈接，清除所有被存儲的狀態(tài)。賬本可能會被保存下來為了以后的便利，當然，只有在被認為賬本以后會有用時才會被保存下來。
注意點：
非open信息在一個不活躍的連接上應該是被忽略的。在發(fā)送send_block信息時，接收者應該檢查這個塊，看它是否是自己所需的，并且是否是正確的，如果是，就使用此塊?？傊?#xff0c;所有不規(guī)則的信息都會讓接收者觸發(fā)一個close(false)信息并且強制性的重初始化此鏈接。3.5 Merkle DAG對象
DHT和BitSwap允許IPFS構造一個龐大的點對點系統(tǒng)用來快速穩(wěn)定的分發(fā)和存儲。最主要的是，IPFS建造了一個Merkle DAG,一個無回路有向圖，對象之間的links都是hash加密嵌入在源目標中。這是Git數(shù)據(jù)結(jié)構的一種推廣。Merkle DAGS給IPFS提供了很多有用的屬性，包括： - 1.內(nèi)容可尋址：所有內(nèi)容都是被多重hash校驗和來唯一識別的，包括links。
- 2.防止篡改：所有的內(nèi)容都用它的校驗和來驗證。如果數(shù)據(jù)被篡改或損壞，IPFS會檢測到。
- 3.重復數(shù)據(jù)刪除：所有的對象都擁有相同的內(nèi)容并只存儲一次。這對于索引對象非常有用，比如git的tree和commits，或者數(shù)據(jù)的公共部分。
IPFS對象的格式是：
| 1 2 3 4 5 6 7 8 9 10 | type IPFSLink struct { Name string // 此link的別名 Hash Multihash // 目標的加密hash Size int // 目標總大小 } type IPFSObject struct { links []IPFSLink //links數(shù)組 data []byte //不透明內(nèi)容數(shù)據(jù) } |
?
IPFS Merkle DAG是存儲數(shù)據(jù)非常靈活的一種方式。只要求對象引用是(a）內(nèi)容可尋址的，(b)用上面的格式編碼。IPFS允許應用完全的掌控數(shù)據(jù)域；應用可以使用任何自定義格式的數(shù)據(jù)，即使數(shù)據(jù)IPFS都無法理解。單獨的內(nèi)部對象link表允許IPFS做：
- 用對象的形式列出所有對象引用，例如：
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。給出一個對象，IPFS會解析第一個路經(jīng)成分進行hash放入到對象的link表中，再獲取路徑的第二個組成部分，一直如此重復下去。因此，任何數(shù)據(jù)格式的字符串路經(jīng)都可以在Merkle DAG中使用。
*遞歸性的解決所有對象引用：1 2 3 4 5 6 > ipfs refs --recursive \ /XLZ1625Jjn7SubMDgEyeaynFuR84ginqvzb XLLxhdgJcXzLbtsLRL1twCHA2NrURp4H38s XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5 XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z
原始數(shù)據(jù)結(jié)構公共link結(jié)構是IPFS構建任意數(shù)據(jù)結(jié)構的必要組成部分?？梢院苋菀卓闯鯣it的對象模型是如何套用DAG的。一些其他潛在的數(shù)據(jù)結(jié)構：
- (a)鍵值存儲
- (b)傳統(tǒng)關系型數(shù)據(jù)
- (c)數(shù)據(jù)三倍存儲
- (d) 文檔發(fā)布系統(tǒng)
- (e)通信平臺
- (f)加密貨幣區(qū)塊。
這些系統(tǒng)都可以套用IPFS Merkle DAG，這使這些系統(tǒng)更復雜的應用可以使用IPFS作為傳輸協(xié)議。
3.5.1 路經(jīng)
IPFS對象可以遍歷一個字符串路經(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前綴允許只要在掛載點不沖突(掛載點名稱當然是可配置的)的情況下掛載到一個已存在的系統(tǒng)上。第二個路經(jīng)組成部分(第一個是IPFS)是一個對象的hash。通常都是這種情況，因為沒有全局的根。一個根對象可能會有一個不可能完成的任務，就是在分布式環(huán)境(可能還斷開鏈接)中處理百萬對象的一致性。因此，我們用地址可尋址來模擬根。通過的hash所有的對象都是可訪問的。這意思是說，給一個路經(jīng)對象/bar/baz，最后一個對象可以可以被所有的訪問的：
| 1 2 3 | /ipfs/<hash-of-foo>/bar/baz /ipfs/<hash-of-bar>/baz /ipfs/<hash-of-baz> |
?
3.5.2 本地對象
IPFS客戶端需要一個本地存儲器，一個外部系統(tǒng)可以為IPFS管理的對象存儲以及檢索本地原始數(shù)據(jù)。存儲器的類型根據(jù)節(jié)點使用案例不同而不同。在大多數(shù)情況下，這個存儲器只是硬盤空間的一部分（不是被本地的文件系統(tǒng)使用鍵值存儲如leveldb來管理，就是直接被IPFS客戶端管理），在其他的情況下，例如非持久性緩存，存儲器就是RAM的一部分。
最終，所有的塊在IPFS中都是能夠獲取的到的，塊都存儲在了一些節(jié)點的本地存儲器中。當用戶請求一個對象時，這個對象會被查找到并下載下來存儲到本地，至少也是暫時的存儲在本地。這為一些可配置時間量提供了快速的查找。
3.5.3對象鎖定
希望確保特定對象生存的節(jié)點可以鎖定此對象。這保證此特定對象被保存在了節(jié)點的本地存儲器上。也可以遞歸的進行鎖定所有相關的派生對象。這使所有被指定的對象都保存在本地存儲器上。這對長久保存文件特別有用，包括引用。這也同樣讓IPFS成為一個links是永久的Web，且對象可以確保其他被指定對象的生存。
3.5.4 發(fā)布對象
IPFS是全球分布的。它設計為允許成千上萬的用戶文件可以共同的存在的。DHT使用內(nèi)容哈希尋址技術，使發(fā)布對象是公平的，安全的，完全分布式的。任何人都可以發(fā)布對象，只需要將對象的key加入到DHT中，并且以對象是對等節(jié)點的方式加入進去，然后把路徑給其他的用戶。要注意的是，對象本質(zhì)上是不可改變的，就像在Git中一樣。新版本的哈希值不同，因此是新對象。跟蹤版本則是額外版本對象的工作。
3.5.5 對象級別的加密
IPFS是具備可以處理對象級別加密操作的。一個已加密的或者已簽名的對象包裝在一個特殊的框架里，此框架允許加密和驗證原始字節(jié)。
| 1 2 3 4 5 6 7 8 | type EncryptedObject struct { Object []bytes // 已加密的原始對象數(shù)據(jù) Tag []bytes // 可選擇的加密標識 type SignedObject struct { Object []bytes // 已簽名的原始對象數(shù)據(jù) Signature []bytes // HMAC簽名 PublicKey []multihash // 多重哈希身份鍵值 } |
?
加密操作改變了對象的哈希值，定義一個不同的新的對象。IPFS自動的驗證簽名以及使用用戶指定的鑰匙鏈解密數(shù)據(jù)。加密數(shù)據(jù)的links也同樣的被保護著，沒有解密秘鑰就無法遍歷對象。也存在著一種現(xiàn)象，可能父對象使用了一個秘鑰進行了加密，而子對象使用了另一個秘鑰進行加密或者根本沒有加密。這可以保證links共享對象安全。
3.6 文件
IPFS在Merkle DAG上還為模型化版本文件系統(tǒng)定義了一組對象。這個對象模型與Git比較相似：
Block：一個可變大小的數(shù)據(jù)塊
List：塊或者其他鏈表的集合
Tree：塊，鏈表，或者其他樹的集合
Commit：樹在版本歷史記錄中的一個快照
我原本希望使用與Git對象格式一致的模型，但那就必須要分開來引進在分布式文件系統(tǒng)中有用的某些特征，如
- (a)快速大小查找(總字節(jié)大小已經(jīng)加入到對象中)
- (b)大文件的重復刪除(添加到list對象)
- (c)commits嵌入到trees中。不過，IPFS文件對象與Git還是非常相近的，兩者之間進行交流都是有可能的。而且，Git的一個系列的對象可以被引進過來轉(zhuǎn)換都不會丟失任何的信息。（UNIX文件權限等等）。
標記：下面的文件對象格式使用JSON。注意，雖然IPFS包含了JSON的互相轉(zhuǎn)換，但是文件對象的結(jié)構體還是使用protobufs的二進制編碼。3.6.1 文件對象：BLOB
blob對象代表一個文件且包含一個可尋址的數(shù)據(jù)單元，IPFS的blobs就像Git的blobs或者文件系統(tǒng)數(shù)據(jù)塊。它們存儲用戶的數(shù)據(jù)。需要留意的是IPFS文件可以使用lists或者blobs來表示。Blobs沒有l(wèi)inks。1 2 3 { "data": "some data here", // blobs無links }
3.6.2 文件對象: LIST
List對象代表著由幾個IPFS的blobs連接成的大文件或者重復數(shù)據(jù)刪除文件。Lists包含著有序的blob序列或list對象。從某種程度上而言，IPFS的list函數(shù)就像一個間接塊的文件系統(tǒng)。由于lists可以包含其他的lists，那么包含linked的鏈表和平衡樹的拓撲結(jié)構是有可能的。有向圖中相同的節(jié)點出現(xiàn)在多個不同地方允許在文件中重復數(shù)據(jù)刪除。當然，循環(huán)是不可以能的，因為是被哈希尋址強制實行的。
| 1 2 3 4 5 6 7 8 9 10 11 | { "data": ["blob", "list", "blob"], //lists有一個對象類型的數(shù)組作為數(shù)據(jù) "links": [ { "hash": "XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x", "size": 189458 }, { "hash": "XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5", "size": 19441 }, { "hash": "XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z", "size": 5286 } //在links中l(wèi)ists是沒有名字的 ] } |
?
3.6.3 文件對象：TREE
IPFS中的tree對象與Git中相似，它代表著一個目錄，一個名字到哈希值的映射。哈希值則表示著blobs，lists，其他的trees，或者commits。注意，傳統(tǒng)路徑的命名早已經(jīng)被Merkle DAG實現(xiàn)了。
| 1 2 3 4 5 6 7 8 9 10 11 | { "data": ["blob", "list", "blob"],//trees有一個對象類型的數(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 文件對象：COMMIT
IPFS中的commit對象代表任何對象在版本歷史記錄中的一個快照。與Git中類似，但是它能夠表示任何類型的對象。它同樣link著發(fā)起對象。
3.6.5 版本控制
Commit對象代表著一個對象在歷史版本中的一個特定快照。在兩個不同的commit中比較對象（和子對象）可以揭露出兩個不同版本文件系統(tǒng)的區(qū)別。只要commit和它所有子對象的引用是能夠被訪問的，所有前版本是可獲取的，所有文件系統(tǒng)改變的全部歷史是可訪問的，這就與Merkle DAG對象模型脫離開來了。
Git版本控制工具的所有功能對于IPFS的用戶是可用的。對象模型不完全一致，但也是可兼容的。這可能
- (a)構建一個Git工具版本改造成使用IPFS對象圖，
- (b)構建一個掛載FUSE文件系統(tǒng)，掛載一個IPFS的tree作為Git的倉庫，把Git文件系統(tǒng)的讀/寫轉(zhuǎn)換為IPFS的格式。
3.6.6 文件系統(tǒng)路徑
如我們在Merkle DAG中看到的一樣，IPFS對象可以使用字符串路徑API來遍歷。IPFS文件對象是特意設計的，為了讓掛載IPFS到UNIX文件系統(tǒng)更加簡單。文件對象限制trees沒有數(shù)據(jù)，為了使它們可以表示目錄。Commits可以以代表目錄的形式出現(xiàn)，也可以完全的隱藏在文件系統(tǒng)中。
3.6.7 將文件分隔成LISTS和BLOBS
版本控制和分發(fā)大文件其中一個最主要的挑戰(zhàn)是：找到一個正確的方法來將它們分隔成獨立的塊。與其認為IPFS可以為每個不同類型的文件提供正確的分隔方法，不如說IPFS提供了以下的幾個可選選擇：
就像在LIBFS[?]中一樣使用Rabin Fingerprints [?]來選擇一個比較合適的塊邊界。
使用rsync[?] rolling-checksum算法，來檢測塊在版本之間的改變。
允許用戶指定專為特定文件而調(diào)整的’快分隔’函數(shù)。
3.6.8路徑查找性能
基于路徑的訪問需要遍歷對象圖。獲取每個對象要求在DHT中查找它們的key，連接到對等節(jié)點，然后獲取它的塊。這造成相當大的開銷，特別是查找的路徑由很多子路徑組成時。下面的方法可以減緩開銷：
- tree緩存：由于所有的對象都是哈希尋址的，它們可以被無限的緩存。另外，trees一般比較小，所以比起blobs，IPFS會優(yōu)先緩存trees。
- flattened trees：對于任何tree，一個特殊的 flattened tree可以構建一個鏈表，所有對象都可以從這個tree中訪問得到。在flattened tree中名字就是一個從原始tree分離的路徑，用斜線分隔。
例如，對于上面的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桟形成了一個對等塊交換組成一個內(nèi)容可尋址的DAG對象。這提供了發(fā)布和獲取不可改變的對象。這甚至可以跟蹤這些對象的版本歷史記錄。但是，這里有一個關鍵成分遺漏了：易變的命名。沒有這個，發(fā)送IPFS的links，所有新內(nèi)容的通信肯定都會有所偏差。現(xiàn)在所需就是能有某些方法可以獲取相同路徑的的易變狀態(tài)。
這值得詳述原因—如果最終易變數(shù)據(jù)是必須的—我們費了很大的力氣構建了一個不可改變的Merkle DAG。就當做IPFS脫離了Merkle DAG的特征：對象可以
- (a)通過哈希值可以獲取
- (b)完整性的檢查
- (c)link其他的對象
- (d)無限緩存。從某種意義上說：
對象就是永恒的
這些就是一個高性能分布式系統(tǒng)的關鍵特征，在此系統(tǒng)上跨網(wǎng)絡links之間移動文件是非常昂貴的。對象內(nèi)容可尋址構建了一個具有以下特點的Web，(a)優(yōu)秀的寬帶優(yōu)化(b)不受信任的內(nèi)容服務(c)永恒的links(d)能夠永久備任何對象以及它的引用。
不可變的內(nèi)容可尋址對象和命名的Merkle DAG， 可變指針指向Merkle DAG，實例化了一個出現(xiàn)在很多成功分布式系統(tǒng)中的二分法。這些系統(tǒng)包括Git的版本控制系統(tǒng)，使用不可變的對象和可變的引用；還有UNIX分布式的繼承者Plan9[?]文件系統(tǒng)，使用可變的Fossil和不可變的Venti[?]。LBFS[?]同樣使用可變的索引以及不可變的塊。
3.7.1 自我認證名稱
使用SFS[12,11]中的命名方案，給我們提供了一個種可以構建自我認證名稱的方法，
在一個加密指定的全局命名空間中，這是可變的。IPFS的方案如下：
- 1.回想一下在IPFS中：NodeId = hash(node.PubKey)
- 2.我們給每個用戶分配一個可變的命名空間，在此路徑下：/ipns/
- 3.一個用戶可以在此路徑下發(fā)布一個用自己私鑰簽名的對象，比如說：/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/
- 4.當其他用戶獲取對象時，他們可以檢測簽名是否與公鑰和NodeId匹配。這個驗證了用戶發(fā)布對象的真實性，達到了可變狀態(tài)的獲取。
注意下面的細節(jié)：
- IPNS(InterPlanetary的命名空間)分開前綴是在可變和不可變的路徑之間建立一個很容易辨認的區(qū)別，為了程序也為了人類閱讀的便利。
-
因為這不是一個內(nèi)容可尋址的對象，所以發(fā)布它就要依靠IPFS中的唯一的可變狀態(tài)分配制度，路由系統(tǒng)。過程是(a)首先把此對象做一個常規(guī)的不可變IPFS的對象來發(fā)布(b)將此對象的哈希值作為元數(shù)據(jù)的值發(fā)布到路由系統(tǒng)上：
1 routing.setValue(NodeId, <ns-object-hash>) -
發(fā)布的對象中任何links在命令空間中充當子名稱：
1 2 3 /ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/ /ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/docs /ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/docs/ipfs -
一般建議發(fā)布一個commit對象或者其他對象的時候，要使用歷史版本記錄，因為這樣就用戶就可以找到之前使用過的名字。不過由于這并不總是需要的，所以留個用戶自己選擇。
注意當用戶發(fā)布一個對象的時候，他不能使用相同的方式來發(fā)布對象。
3.7.2人類友好名稱
IPNS的確是一個分配和在分配名稱的好方法，但是對用戶卻不是十分友好的，因為它使用很長的哈希值作為名稱，眾所周知這樣的名稱很難被記住。IPNS足夠應付URLs，但對于很多線下的傳輸工作就沒有這么好用了。因此，IPFS使用下面的技術來增加IPNS的用戶友好度。
對等節(jié)點Links
被SFS所鼓舞，用戶可以直接將其他用戶的對象link到自己的對象上（命令空間，家目錄等等）。這有一個好處就是創(chuàng)建了一個可信任的Web（也支持老的真實性認證模型）：
| 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 也可以訪問Bob /<eve-pk-hash/friends/alice/friends/bob # 訪問Verisign 認證域 /<verisign-pk-hash>/foo.com |
?
DNS TXT IPNS 記錄
如果/ipns/是一個有效的域名稱，IPFS會在DNS TXT記錄中查找關鍵的ipns。IPFS會將查找到的值翻譯為一個對象的哈希值或者另一個ipns的路徑：
| 1 2 3 4 | # DNS TXT 記錄 ipfs.benet.ai. TXT "ipfs=XLF2ipQ4jD3U ..." # 表現(xiàn)為符號鏈接 ln -s /ipns/XLF2ipQ4jD3U /ipns/fs.benet.ai |
?
Proquint 可讀的標識符
總是會有將二進制編碼翻譯成可讀文件的方法。IPNS則支持Proquint[?].。如下：
| 1 2 3 4 | # proquint語句 /ipns/dahih-dolij-sozuk-vosah-luvar-fuluh # 分解為相應的下面形式 /ipns/KhAwNprxYVxKqpDZ |
?
縮短名稱服務
會涌現(xiàn)出很多服務器提供縮短名稱的服務，向用戶提供他們的命名空間。就像我們現(xiàn)在看到的DNS和Web的URLs：
| 1 2 3 4 | # 用戶可以從下面獲取一個link /ipns/shorten.er/foobar # 然后放到自己的命名空間 /ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm |
?
3.8使用IPFS
IPFS設計為可以使用多種不同的方法來使用的，下面就是一些我將會繼續(xù)追求的使用方式：
- 1.作為一個掛載的全局文件系統(tǒng)，掛載在/ipfs和/ipns下
- 2.作為一個掛載的個人同步文件夾，自動的進行版本管理，發(fā)布，以及備份任何的寫入
- 3.作為一個加密的文件或者數(shù)據(jù)共享系統(tǒng)
- 4.作為所有軟件的版本包管理者
- 5.作為虛擬機器的根文件系統(tǒng)
- 6.作為VM的啟動文件系統(tǒng) (在管理程序下)
- 7.作為一個數(shù)據(jù)庫：應用可以直接將數(shù)據(jù)寫入Merkle DAG數(shù)據(jù)模型中，獲取所有的版本，緩沖，以及IPFS提供的分配
- 8.作為一個linked（和加密的）通信平臺
- 9.作為一個為大文件的完整性檢查CDN（不使用SSL的情況下）
- 10.作為一個加密的CDN
- 11.在網(wǎng)頁上，作為一個web CDN
- 12.作為一個links永遠存在新的永恒的Web
IPFS實現(xiàn)的目標： - (a)一個IPFS庫可以導出到你自己應用中使用
- (b)命令行工具可以直接操作對象
- (c)使用FUSE[?]或者內(nèi)核的模型掛載文件系統(tǒng)
4. 未來
IPFS的思想是幾十年成功的分布式系統(tǒng)的探索和開源的產(chǎn)物。IPFS綜合了很多迄今為止很成功的系統(tǒng)中優(yōu)秀的思想。除了BitSwap新協(xié)議之外，IPFS最大的特色就是系統(tǒng)的耦合以及設計的綜合性。
IPFS是去中心化網(wǎng)絡基礎設施的一個野心設想，很多不同類型的應用都可以建立在IPFS上。最低限度，它可以用來作為一個全局的，掛載性，版本控制文件系統(tǒng)和命名空間，或者作為下一代的文件共享系統(tǒng)。而最好的情況是，IPFS可以讓Web升級一個層次，當發(fā)布一個有價值的信息時，任何感興趣的人都可以進行發(fā)布而不會強迫性的必須只允許發(fā)布機構進行發(fā)布，用戶可以信任信息的內(nèi)容，信不信任信息的發(fā)送者都是無關緊要的，還有一個特點就是，一些重要但很老的文件也不會丟失。IPFS期待著帶我們進入到一個永恒Wdb的世界。5. 感謝
IPFS是一個很多很棒的主意以及系統(tǒng)的綜合體。沒有站在巨人的肩膀上，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頁，在《并發(fā)和分布式系統(tǒng)》中。IEEE，2007年。
[2].I. BitTorrent.Bittorrent和Attorrent軟件超過1億5000萬用戶里程碑，Jan。2012
[3].B. Cohen.激勵機制在bittorrent中建立了健壯性。在《對等系統(tǒng)經(jīng)濟研討會》中，第6卷，68-72頁，2003年。
[4].J. Dean and S. Ghemawat. Leveldb - 一個快速和輕量級鍵值存儲數(shù)據(jù)庫，谷歌提供，2011年。
[5].M. J. Freedman, E. Freudenthal, and D. Mazieres. Coral民主內(nèi)容發(fā)布。在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.分布式文件系統(tǒng)的規(guī)模和性能?！癆CM 電腦系統(tǒng)上的交易 （TOCS）” 6(1):51-81, 1988年
轉(zhuǎn)載于:https://www.cnblogs.com/405845829qq/p/10492001.html
總結(jié)
以上是生活随笔為你收集整理的IPFS - 可快速索引的版本化的点对点文件系统（草稿3）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 最近游戏更新 未整理 无图片 续
- 下一篇： linux环境编程apue,《UNIX环