區塊鏈
挖礦,比特幣,EOS,以太坊

IPFS開發教程 – 可快速索引的版本化的點對點文件系統(3)

221

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。

3.6.2 文件對象: LIST

List對象代表著由幾個IPFS的blobs連接成的大文件或者重復數據刪除文件。Lists包含著有序的blob序列或list對象。從某種程度上而言,IPFS的list函數就像一個間接塊的文件系統。
由于lists可以包含其他的lists,那么包含linked的鏈表和平衡樹的拓撲結構是有可能的。有向圖中相同的節點出現在多個不同地方允許在文件中重復數據刪除。當然,循環是不可以能的,因為是被哈希尋址強制實行的。

3.6.3 文件對象:TREE
IPFS中的tree對象與Git中相似,它代表著一個目錄,一個名字到哈希值的映射。哈希值則表示著blobs,lists,其他的trees,或者commits。注意,傳統路徑的命名早已經被Merkle DAG實現了。

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如下:

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)將此對象的哈希值作為元數據的值發布到路由系統上:

發布的對象中任何links在命令空間中充當子名稱:

一般建議發布一個commit對象或者其他對象的時候,要使用歷史版本記錄,因為這樣就用戶就可以找到之前使用過的名字。不過由于這并不總是需要的,所以留個用戶自己選擇。
注意當用戶發布一個對象的時候,他不能使用相同的方式來發布對象。

3.7.2人類友好名稱
IPNS的確是一個分配和在分配名稱的好方法,但是對用戶卻不是十分友好的,因為它使用很長的哈希值作為名稱,眾所周知這樣的名稱很難被記住。IPNS足夠應付URLs,但對于很多線下的傳輸工作就沒有這么好用了。因此,IPFS使用下面的技術來增加IPNS的用戶友好度。
對等節點Links
被SFS所鼓舞,用戶可以直接將其他用戶的對象link到自己的對象上(命令空間,家目錄等等)。這有一個好處就是創建了一個可信任的Web(也支持老的真實性認證模型):


DNS TXT IPNS 記錄
如果/ipns/是一個有效的域名稱,IPFS會在DNS TXT記錄中查找關鍵的ipns。IPFS會將查找到的值翻譯為一個對象的哈希值或者另一個ipns的路徑:


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


縮短名稱服務
會涌現出很多服務器提供縮短名稱的服務,向用戶提供他們的命名空間。就像我們現在看到的DNS和Web的URLs:

3.8使用IPFS
IPFS設計為可以使用多種不同的方法來使用的,下面就是一些我將會繼續追求的使用方式:
1.作為一個掛載的全局文件系統,掛載在/ipfs和/ipns下2.作為一個掛載的個人同步文件夾,自動的進行版本管理,發布,以及備份任何的寫入3.作為一個加密的文件或者數據共享系統4.作為所有軟件的版本包管理者5.作為虛擬機器的根文件系統6.作為VM的啟動文件系統 (在管理程序下)7.作為一個數據庫:應用可以直接將數據寫入Merkle DAG數據模型中,獲取所有的版本,緩沖,以及IPFS提供的分配8.作為一個linked(和加密的)通信平臺9.作為一個為大文件的完整性檢查CDN(不使用SSL的情況下)10.作為一個加密的CDN11.在網頁上,作為一個web CDN12.作為一個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年

贊(0)

評論 搶沙發

  • 昵稱 (必填)
  • 郵箱 (必填)
  • 網址
p3试机号99