談到區塊鏈和分布式計算，最重要的是共識算法(整個網絡如何達成一致的決策)和智能合約(實現我們在中心化世界中日常使用的應用)。但是，談及日常應用程序，這些屬性還不足以支持當今世界的需求。如果我們只依靠上述這兩項，就難以想象像在 Netflix 上那樣觀賞喜愛的電影或電視劇、像在臉書上那樣存儲或分享值得紀念的視頻或照片，或在區塊鏈上玩喜愛的在線游戲(如 DOTA)。

我們缺少一個強大、安全和去中心化的內容存儲以及分發系統，服務于當今的應用程序。

下面，我們將探索和評估一些***的分布式存儲平臺。

本文為系列文中的《上》篇，主要介紹 Swarm 和 IPFS。系列文的《中》及《下》篇將分別介紹 Sia 和 Storj 以及 MaidSafe。

1.Swarm

 

 

狀態：活躍

說明：

Swarm 是分布式存儲平臺和內容分發服務，是以太坊 web3 棧的本地基礎層服務。Swarm 的主要目標是提供充分分散和冗余存儲的以太坊公共記錄，尤其是存儲和分發 DApp 的代碼和數據以及區塊鏈數據。從經濟角度來看，它允許參與者有效匯集他們的存儲容量和帶寬資源，以給網絡的所有參與者提供這些服務，同時接受以太坊的激勵。

目標

Swarm 更廣泛的目標，是為去中心化的 web 應用程序(DApp)開發人員提供基礎設施服務，特別是：消息傳遞、數據流、點對點記賬、可變資源更新、存儲保險、監管掃描和修復、支付渠道和數據庫服務。

從終端用戶的角度來看，Swarm 和萬維網的差別不大，除了上傳不托管在特定的服務器上。Swarm 提供了一個點到點的存儲和服務解決方案，它具有 DDos 抗性、零停機、容錯和審查及自我維持的特性，它內置了激勵系統，通過點對點記賬，允許用戶為交易資源進行支付。Swarm 旨在和以太坊的 devp2p 多協議網絡層以及以太坊區塊鏈進行深度集成，以進行域名解析(利用 ENS)、服務支付和內容可用性保證。

請注意： 為了解析 ENS 域名，Swarm 節點必須要連接到以太坊區塊鏈上(主網或測試網)。

概述

Swarm 旨在給新的去中心化互聯網提供基礎層的基礎設施。Swarm 是點對點的節點網絡，通過彼此之間貢獻資源(存儲、消息轉發、支付處理)提供分布式數字服務。以太坊基金會運作 Swarm 測試網，可以用來以類似于以太坊測試網絡(ropsten)的方式測試功能。每個人都可以通過在自己的服務器、臺式機、筆記本電腦或移動設備上運行 Swarm 客戶節點加入到網絡中。請參閱 《Swarm 入門(https://swarm-guide.readthedocs.io/en/latest/gettingstarted.html#getting-started)》一文以了解操作方法。Swarm 客戶端是以太坊棧的一部分，參考實現是用 golang 編寫的，可以在 go-ethereum 存儲庫中找到它。目前在所有節點上運行的是 POC 0.3 版。

Swarm 提供 本地 HTTP 代理 API，DApp 或命令行工具可以用來和 Swarm 進行交互。像 消息傳遞 這樣的模塊只能基于 PRC-JSON API 才可使用。在測試網(testnet)上的基礎服務提供公共網關，用于輕松演示功能和允許免費的訪問，以便人們無需運行任何自己的節點即可嘗試 Swarm。

Swarm 是 devp2p 網絡的節點集合，其中的每個節點在同一個網絡 ID 上運行 bzz 協議套件。

Swarm 節點也可以連接到一個(或多個)以太坊區塊鏈上，以進行域名解析，并連接到一個以太坊區塊鏈進行帶寬和存儲補償。運行相同網絡 ID 的節點應該連接到相同的區塊鏈上以進行支付。Swarm 網絡由其網絡 ID 標識，該網絡 ID 是一個任意整數。

Swarm 允許上傳(upload)和消失(disappear)，這意味著任何節點可以只上傳內容給 Swarm，然后就可以下線。只要節點沒有丟失或變得不可用，該內容將仍舊可以訪問，這是因為有一個“同步”的過程，節點持續地在彼此之間傳遞可用數據。

公共網關

Swarm 提供本地 HTTP 代理 API，DApp 可以用來和 Swarm 進行交互。以太坊基金會在托管公共網關，該網關允許免費訪問，因此，人們甚至無需運行自己的節點即可嘗試 Swarm。

Swarm 公共網關可以在 http://swarm-gateways.net 上找到，上面一直都運行著***的 Swarm 穩定版。

目前，該網關只接受限制大小的上傳。將來，上傳到該網關的功能很可能完全消失。

上傳和下載

數據上傳內容由這些步驟組成：“上傳”內容到本地 Swarm 節點，接著本地 Swarm 節點用其在網絡中的對等點“同步”所生成的數據塊。同時，下載內容由這些步驟組成：本地 Swarm 節點查詢在網絡中的對等點以獲取相關的數據塊，然后在本地重組這些內容。

內容解析器：ENS

為了解析 ENS 名稱，Swarm 節點必須連接到以太坊區塊鏈(主網或測試網)。

ENS 是個系統，Swarm 用它來實現以人類可讀的名稱(如 theswarm.eth)引用內容。它的操作類似于 DNS 系統，把人類可讀的名稱轉換成機器標識符，在此，即你正在引用的內容的 Swarm 哈希。通過注冊一個名稱，并把它解析成網站的根清單的內容哈希值，用戶可以通過 URL(如 bzz://theswarm.eth/)訪問該網站。

目前，主流的瀏覽器(如 Chrome、Firefox 或 Safari)不支持 bzz 協議。目前，如果要通過這些瀏覽器訪問 bzz 協議，必須使用 HTTP 網關(如 https://swarm-gateways.net/bzz:/theswarm.eth/)或者使用支持 bzz 協議的瀏覽器(如 Mist)。

可變資源更新(Mutable Resource Updates)

可變資源更新是 Swarm POC3 上的一項 高度實驗性的功能 。它正在積極開發中，因此，有些東西可能會有變化。

我們在這份指南中已經了解到，當我們在 Swarm 中改變數據時，我們上傳的數據所返回的哈希值會以無法預料的方式變化。通過可變資源更新，Swarm 提供一種內置方式，可以對更改數據保持一個持久的標識符。

為了保持與更改數據有相同的指針，常用的方法是利用以太坊命名服務 ENS。但是，ENS 是一個鏈上功能，它限制了其他地方的功能：

• 每個 ENS 解析器的更新都需要 gas 才能進行。
• 更改數據不可能比挖出新區塊的速度更快。
• 正確的 ENS 解析方案要求始終同步到區塊鏈。

可變資源更新允許我們用非變量標識符來更改數據，無需使用 ENS。利用在創建資源時獲得的密鑰，可以像普通 Swarm 對象一樣引用可變資源。

如果同時使用 ENS 解析器合約和可變資源更新，只需要一個初始事務來注冊 MRU_MAINFEST_KEY。該密鑰將解析到資源的最近版本上(更新該資源不會改變該密鑰)。有 3 種和可變資源更新進行交互的方法：HTTP API、Golang API 和 Swarm CLI。

注意事項：

• 只有創建該資源的私鑰(地址)可以更新它。
• 在創建可變資源時，必須要提供的參數之一是預期的更新頻率。這表明該資源多快(以秒計算)被更新一次。盡管你可以以其他的速率更新該資源，但這么做會減慢索引該資源的處理過程。

Swarm 上的加密

在 POC 0.3 中引入了對稱加密技術，現在可以很容易隨 Swarm up 上傳命令一起使用對稱加密了。該加密機制是用來保護信息，并使得在處理任何 Swarm 節點時都不可讀分塊數據。

Swarm 使用 計數器模式加密技術 來加密和解密內容。當上傳內容到 Swarm 時，該上傳的數據被分為 4KB 大小的塊。這些塊都將用獨立的隨機生成的加密密鑰來編碼。這個加密過程在本地 Swarm 節點上發生，沒被加密的數據不與其他節點共享。單個塊(和整個內容)的引用將是編碼數據哈希值和加密密鑰的組合。這意味著引用將比標準無加密的 Swarm 引用長一些(不是 32 個字節，而是 64 個字節)。

當你的節點將你的內容的加密塊與其他節點同步時，它不與其他節點共享完整的引用(或任何方式的解密密鑰)。這意味著其他節點無法訪問你的原始數據，此外，它們也無法偵測到同步的塊是否經過加密。

檢索數據時，只在本地 Swarm 節點上將它解密。在整個檢索過程中，這些塊以加密的形式遍歷網絡，參與的對等節點無法解密它們。它們只在用于下載的 Swarm 節點上進行解密和重組。

注意事項：

• Swarm 支持加密。由于無法撤銷上傳，因此強烈建議不上傳未加密的敏感和私密數據。用戶應該避免上傳非法的、有爭議的或不道德的內容。
• Swarm 目前即支持加密也支持未加密的 swarm up 命令，通過使用 --encrypt 參數來標識。將來可能有變化。
• 加密功能是非確定性的(因為每個上傳請求生成的密鑰是隨機的)，API 的用戶不應該依賴結果的冪等性;這樣，在啟用加密的情況下，同樣的內容兩次上傳到 Swarm 所產生的引用是不同的。

PSS

PSS(Postal Service over Swarm，Swarm 上的 Postal 服務)是 Swarm 上的消息傳遞協議，具有強大的隱私功能。PSS API 通過在該 API Reference 中所描述的 JSON RPC 接口公開，我們在這里只解釋基本概念和功能。

PSS 仍然是個實驗性的功能，正在積極開發中，可從 Swarm 的 POC3 開始使用。預計有些事情會有所變化。

基礎知識

通過 PSS，可以發送消息給 Swarm 網絡上的任何節點。消息的路由方式和塊的檢索申請方式一樣。PSS 消息不使用塊哈希引用，而是在覆蓋地址空間中指定目標，與消息的有效負載無關。如果該目標是一個完整的覆蓋地址就可以將其描述為一個特定的節點，或者如果它只部分指定其一，則可以描述為鄰居。消息通過 DevP2P 對等連接使用 forwarding kademlia 算法進行轉發，forwarding kademlia 算法則通過使用 kademlia 路由的中繼節點之間的半***點對點 TCP 連接傳遞消息。在目標鄰居內，該消息利用 Gossip 進行廣播。

由于 PSS 消息是加密的，因此，最終收件人可以解密該消息。可以用非對稱或對稱加密方式進行加密。

消息有效負載通過接收節點分發給消息處理器，并通過 API 分發給訂閱用戶。

目前，PSS 不保證消息的訂購(盡***努力傳遞)，也不保證消息的傳遞(也即，不緩存和中繼給離線節點的消息)。

隱私功能

得益于端到端的加密，PSS 也適合私人通信。

PSS 使用了 forwarding kademlia 算法，對發送者進行匿名化處理。

利用部分尋址，pss 提供收件人匿名的可調范圍：目標鄰居越多，所顯示的預期收件人覆蓋地址的前綴越小，就越難識別真正的收件人。另一方面，由于暗路由(dark routing)效率低，因此在匿名性和消息傳遞延遲及帶寬(還有因此產生的成本)之間需要折衷，而這留給應用程序來選擇。

如果使用 Handshakes 模塊，則提供前向保密。

DApp 注意事項

敏感內容一定要加密!對于加密內容，上傳的數據是“受保護的”，也即，只有那些知道對根塊(文件的 Swarm 哈希值和加密密鑰)引用的人可以訪問該內容。因為發布該引用(在 ENS 上或用 MRU)需要一個額外步驟，只要用戶使用加密，就可以輕松地得到保護，防止粗心地發布。Swarm 會刪除沒有明確受到保護的內容，這是因為 Swarm 中限制了存儲容量，Swarm 最終會將這些節點轉到垃圾箱內 。

直到實施存儲保險(請參 閱路徑圖 以了解更多)之前，測試網不保證持久保存上傳的內容。所有參與的節點都被視為沒有任何義務的自愿服務，以其意愿刪除內容。這樣，在激勵系統運行之前，用戶在任何情況下都不應該將 Swarm 視作安全存儲介質。

Swarm 是 持久數據結構(Persistent Data Structure)，因此，在 Swarm 中沒有刪除或移除操作的概念。這是因為內容被傳播到被激勵服務它的 Swarm 節點。

2. IPFS

[[255016]]

 

狀態：活躍(這是一個激勵系統，“Filecoin”是不活躍的)

說明：

IPFS(Interplanetary File System，星際文件系統)，是點對點(peer-to-peer，簡稱 p2p)文件共享系統，旨在從根本上改變信息在全球范圍內的傳播方式。它跟 Swarm 有點類似，或者，我們也可以說 Swarm 跟 IPFS 有點類似。

IPFS 包含了通信協議和分布式系統的幾個創新，它們的組合產生了與眾不同的文件系統。因此，為了理解 IPFS 所要嘗試達到的廣度和深度，重要的是，理解使其變得可能的技術突破和所有它在嘗試解決的問題。

IPFS 自詡要取代 HTTP。那么，我們來看看如今互聯網的工作原理。

簡而言之，現在的互聯網是協議的集合，這些協議描述了數據是如何在整個網絡中移動的。隨著時間的推移，開發人員使用著不同的協議，并在該基礎設施上構建他們的應用程序。在這些協議中，其中一個是 Web 的骨架，即 HTTP 或超文本傳輸協議(HyperText Transfer Protocol)。它是由 Tim Berners-Lee 于 1991 年發明的。

HTTP 是請求 - 響應協議。客戶端(例如 web 瀏覽器)發送一個請求給外部服務器。該外部服務器隨后返回一個響應消息，例如，把谷歌的主頁返回給客戶端。這是位置尋址協議，這意味著，當在瀏覽器中鍵入 google.com 時，它被翻譯成某個谷歌服務器的 IP 地址，接著，該服務器啟動請求 - 響應周期。

HTTP 的問題

假設你正坐在課堂上，教授要求你訪問某個特定的網站。課堂上的每個學生都向該網站發出請求，并獲得響應。這意味著，完全相同的數據被單獨發送給課堂上的每個學生。如果有 100 個學生，那么就有 100 個請求和 100 個響應。很顯示，這不是最有效的方法。理想的話，這些學生將能夠利用他們的物理位置接近度以更有效地檢索他們所需的信息。

如果網絡通信線路有問題，那么 HTTP 也會出大問題，客戶端就無法連接服務器。如果 ISP 發生中斷、某個國家屏蔽了某些內容，或者，如果內容只是被刪除了或移走了，都會發生這樣的事情。在 HTTP web 上到處都有這些類型的斷連。

HTTP 基于位置的尋址模型鼓勵集中化。這便于信任少數擁有我們全部數據的應用程序，但是，因為這個原因，在 web 上的大量數據被浪費了。這也使得這些供應商對我們的信息負有巨大的責任以及擁有巨大的權力(比如臉書)。

HTTP 非常適合加載網站，但是，它不是設計用來傳輸大量的數據(像音頻和視頻文件)。這些缺陷可能使得像 Napster(音樂共享軟件)和 BitTorrent(電影及幾乎任何東西的共享軟件)這些文件共享系統的替代品出現并成功成為主流。

時間快進到 2018 年，按需高清視頻流和大數據正變得無處不在;我們繼續生產 / 消費越來越多的數據，同時開發越來越強大的計算機來處理它們。云計算中的重大進步有助于維持這種轉變，但是，用于分發所有這些數據的基礎設施基本沒有變化。

解決方案

IPFS 最初是由 Juan Benet 努力構建的系統，該系統可以快速移動版本化科學數據。它是經過互聯網技術(DHTs、Git 版本系統和 Bittorrent)綜合測試的綜合體。它創造了允許交換 IPFS 對象的 P2P Swarm 。所有的 IPFS 對象形成了加密身份認證的數據結構(Merkle DAG)，同時，該數據結構能夠用于構建很多其他數據結構。或者，換句話說，就是：

“IPFS 是個分布式文件系統，它旨在用同一個文件系統來連接所有的計算設備。在某些方面，這和 Web 最初的目標類似，但是，IPFS 事實上更類似于一個交換 Git 對象的 Bittorrent Swarm。IPFS 能夠成為互聯網新的重要子系統。如果構建正確，它能夠補充或取代 HTTP。它能夠補充或取代更多東西。這聽起來很瘋狂。沒錯，它的確很瘋狂。”

IPFS 本質上是版本化的文件系統，能夠接收文件并管理它們，也可以把它們存儲在某個地方，然后隨著時間的推移，跟蹤它們的版本。IPFS 也記錄了這些文件在網絡中的移動方式，因此，它也是個分布式文件系統。

IPFS 有管理數據和內容在網絡上移動方式的規則，本質上和 Bittorrent 類似。該文件系統層提供了非常有趣的屬性，如：

• 網站是完全分布式的。
• 網站沒有源服務器。
• 網站可以完全在客戶端的瀏覽器上運行。
• 網站不必和任何服務器有聯系。

我們來看看這些不同的技術突破是如何協同工作的。

分布式哈希表(Distributed Hash Tables)

哈希表 是一種數據結構，它以鍵 / 值對來存儲信息。在分布式哈希表(distributed hash tables，簡稱 DHT)中，數據分布在計算機網絡中，以便有效地協調以實現節點之間的有效訪問和查找。

DHT 的主要優點在于去中心化、容錯和可擴展性。節點無需中心協調，系統能夠可靠地運作，即使節點發生故障或下線，并且，DHT 能夠擴展以容納數百萬個節點。基于這些特性，使得 Swarm 比客戶端 - 服務器結構更具有彈性。

區塊交換(Block Exchanges)

流行的文件共享系統 Bittorrent 能夠成功地協調數百萬節點之間的數據傳輸，這是通過依靠創新的數據交換協議完成的，但是，這只限于種子生態系統。IPFS 實現了該協議的通用版本，稱為 BitSwap，作為任意類型的數據市場來運營。該市場是 Filecoin 的基礎，Filecoin 是構建于 IPFS 之上的 p2p 存儲市場。

Merkle DAG

Merkle DAG 是 Merkle 樹 和有向無環圖(Directed Acyclic Graph，簡稱 DAG)的混合體。Merkle 樹確保在 p2p 網絡上交換的數據塊是正確的、沒有受到損害的和未被修改的。這個驗證是利用 加密哈希 函數數據塊來完成的。這只是一個函數，接收輸入，計算出與輸入相應的一個***的字母數字字符串(哈希)。對于給定的哈希值，容易檢查輸入是否能得出同樣的值，但是，難以從哈希值推算出輸入。

單獨的數據塊被稱為“葉節點”，它們被哈希后，形成“非葉節點”。這些非葉節點然后能夠組合在一起進行哈希，直到所有的數據塊可以用單獨一個根哈希值表示。這是更簡單的概念化方法：

DAG 是一種無周期拓撲序列信息建模的方法。DAG 的一個簡單例子就是家族樹。Merkle DAG 基本上是個數據結構，其中哈希被用來在 DAG 中引用數據塊和對象。這創造了一些有用的功能：IPFS 上的所有內容能夠被唯一地標識，因為每個數據塊有***的哈希值。此外，數據是防篡改的，因為數據的更改會改變哈希值，如下圖所示：

IPFS 的核心原則是對生成的 Merkle DAG 上的所有數據建模。這種安全功能的重要性簡直難以用言語來形容。打個比方吧，該原則可以保護價值數萬億美元的資產，可見該想法有多么強大了吧。

版本控制系統

Merkle DAG 結構的另一個強大的功能是，它允許構建分布式版本控制系統(version control system，簡稱 VCS)。其典型的一個例子是 GitHub，它允許開發人員輕松地同時協作項目。GitHub 上的文件利用 Merkle DAG 存儲和版本化。它允許用戶獨立復制和編輯一個文件的多個版本，并進行存儲，稍后可以把編輯過的版本和原始文件合并。

IPFS 對數據對象使用類似的模型：只要對應于原始數據的對象和任何新版本都可以訪問時，就可以檢索整個文件歷史。鑒于數據塊通過網絡進行本地存儲，并可以***期緩存，這意味著，IPFS 對象能***存儲。

此外，IPFS 不依賴于對互聯網協議的訪問。數據可以分布在 覆蓋網絡 中，覆蓋網絡只是構建在另一個網絡上的網絡。這些功能值得注意，因為它們是抗審查網絡的 核心要素。它可以成為促進自由言論以對抗全球互聯網審查普及制度的工具，但是，我們也應該認識到不良行為者濫用言論的可能性。

自證明的文件系統

我們將要介紹的 IPFS 的***一個重要組成部分是自證明文件系統(Self-certifying File System，簡稱 SFS)。它是分布式文件系統，無需請求特殊權限進行數據交換。它是“自證明”的，因為提供給客戶端的數據是通過文件名來進行身份驗證的。結果就是能夠利用本地存儲的透明度安全地訪問遠程內容。

IPFS 以此概念為基礎，創建了星際命名空間(InterPlanetary Name Space，簡稱 IPNS)。它是個 SFS，使用 公鑰加密 以自證明通過網絡用戶發布的對象。我們之前提到，IPFS 上的所有對象可以唯一標識，但是，這也擴展到節點。網絡上的每個節點有一套公鑰、私鑰和節點 ID，節點 ID 是其公鑰的哈希值。因此，節點可以使用它們的私鑰來“簽署”它們發布的任何數據對象，并利用發件人的公鑰來驗證該數據的真實性。

以下是對關鍵 IPFS 組成部分的快速回顧：

• 通過分布式哈希表，節點可以存儲和共享數據，而無需中央協調
• IPNS 允許交換的數據立即進行預驗證，并使用公鑰密碼進行驗證。
• Merkle DAG 可實現唯一標識、防篡改和***存儲的數據

可以通過 ConsenSys 寫的 文章 來查看網絡中文件是如何被分發的更多細節(深入了解一下)。另外，還可以查看一下 IPFS 的 白皮書。

注意事項：

• 始終對敏感內容進行加密!對加密的內容，上傳的數據是“受保護的”，也即，只有知道對根哈希值(文件的根哈希值和加密密鑰)引用的人才能訪問內容。
• IPFS 是 持久性數據結構，因此，IPFS 中沒有刪除或移除操作的概念。這是因為內容被傳播到受激勵而服務于它的節點。
• 無法保證上傳的數據在網絡上持久地存在。所有參與節點應該被視為沒有正式義務的志愿服務，并且可以按照它們的意愿刪除內容。因此， 直到任何激勵系統(Filecoin)正常運行之前，用戶不應該在任何情況下，把 IPFS 視為安全存儲。

作者簡介

Vaibhav Saini 是 TowardsBlockchain 的聯合創始人，TowardsBlockchain 是麻省理工劍橋創新中心孵化的初創公司。他是一位高級區塊鏈開發人員，參與多個區塊鏈平臺的工作，其中包括：以太坊、Quorum、EOS、Nano、Hashgraph 以及 IOTA 等等。目前，他是德里 印度理工學院 二年級的學生。

閱讀英文原文：https://hackernoon.com/storagepedia-an-encyclopedia-of-5-blockchain-storage-platform-8aa13c630ace