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