Storj白皮書v3最全面解讀，Docker創始人的加入能否扳倒AWS S3

Storj新發了白皮書v3，地址是：https://storj.io/storjv3.pdf

這次白皮書一共有90頁，看完還真要費不少時間。如果你沒有時間看，可以看一下我這篇快速技術解讀。

上次Storj發佈白皮書v2的時候，是 2016年12月15日；這次v3版白皮書的發佈時間，是2018年11月，距離上次發佈白皮書時隔2年時間。

這次白皮書V3相對於白皮書v2來說，務實了很多，給我的整體感覺是：解密了不少實現的細節。全篇白皮書在說Storj去中心化存儲的架構細節，區塊鏈部分依然提到的很少。

看了Storj的白皮書之後，大致可以明確幾點：

• Storj 依然是ERC20通證，它沒有將存儲數據寫入區塊鏈，寫入區塊鏈是隻有資產，簡單地說，就是“錢”。因爲白皮書V3很少提到區塊鏈的內容，所以預計Storj的ERC20狀態還會持續很久。
• Storj仍然採用中心化記賬，每個月“發工資”的形式。工資就是Storj的ERC20的通證。
• 白皮書V2裏面的農場主，在白皮書V3全部改成了存儲節點。這也能感受到Storj採用了去區塊鏈化的路線，Storj變得更靠近傳統古典項目，對標AWS S3。
• 國內不少“礦圈”的人，抱怨在Storj上面種田沒有收益，白皮書v3做了揭祕，說明了原因，後面我會詳細解釋。（Storj上的種田，就類似於FileCoin上挖礦。）

下面我完整地解讀一下Storj。

Storj歷史

Storj 歷史上幾個重要的時間點：

2014年7月，Storj項目首次亮相，並且做了第一次通證的衆籌，籌集了910個比特幣，當時的價值是50萬美金。後面經過差不多2年的開發，終於在2016年4月上線了Beta版；2016年底，發佈了Storj的第二版白皮書。2017年2月-7月，又發起了一次衆籌，這次相當於ICO，這次籌集了價值3000萬美金左右。2018年3月，Docker的創始人兼CEO, Ben Golub, 加入了Storj擔任新CEO。最後就是在不久前發佈了這篇白皮書v3。

Storj設計原則

這次白皮書V3裏面，首先提到的就是設計原則。設計原則有以下幾個關鍵詞：安全與隱私；去中心化；市場和經濟；AWS S3 兼；耐用率, 硬件故障, 和 流失；延遲；帶寬；對象大小；拜占庭容錯；局部協作。

解讀出以下幾點重要信息：

1. 可以看出“安全和隱私”是Storj設計的第一原則。其他原則如果與這個原則衝突，都按照這條原則來執行。

基於這個第一原則，數據必須在進入Storj網絡之前完成加密，而且加密算法是可插拔的，也就是可以使用不同加密算法加密。

2. 要想辦法降低維護成本和帶寬消耗。

3. Storj白皮書V3首次提出了 AWS S3的兼容。這樣開發者就能快速將之前基於ASW S3編寫的程序移植到Storj上。對中國開發者來說，兼容了AWS S3，就兼容了阿里雲OSS。

這次Storj支持了AWS S3的7個最核心的API。Bucket(Create, Delete, List), Object(Get, Put, Delete, List)。

4. Storj定義了一系列的Qos，特別關注了延遲。之前在Storj社區有人反饋：把數據存入Storj網絡有時需要幾個小時。現在看起來，Storj很關注這些反饋意見了。當然，除了延遲外，還定義了一個非常重要的參數：耐用性。耐用性是保證數據不丟失的概率，即使在大量硬件故障或者大量存儲節點離線後，數據不丟失的概率。耐用性，一般是用9的數量來衡量的。如99.99%, 就是4個9的耐用性，表示有萬分之一的數據可能會丟失。

5. Storj白皮書v3完整講述了Storj的經濟體系。一共設計了4個角色: 終端用戶, 存儲節點運營商, 需求供應商, 網絡運營商(現在是Storj Labs)。

6. 定義了Object的大小，最小爲4M。如果大小不到4M，會按照4M收費，這樣鼓勵存入大點的文件。

7. 存儲節點一般歸爲3類：

• 拜占庭節點：有主觀意願作惡的節點。
• 利他節點：拋開不可避免的硬件故障，完全遵守規則並且無私地給他人奉獻的好節點。
• 理性節點：在遵守規則的前提，追求自己利潤最大化的節點。

8. 爲了達到整體的規模最大，局部協議的最小化協調是Storj非常提倡的。

角色

Storj的系統中有以下這些角色：

• 客戶端：在網絡中上傳和下載數據的用戶或應用程序
• 節點的類型:
• 存儲節點: 用於存儲數據，獲得收益
• Uplinks節點：用於實現庫libuplink，並希望存儲和檢索數據的任何應用程序或服務。 預計此類節點不會像其他兩類一樣保持在線狀態，並且相對輕量。
• Libuplink（一個庫）
• Gateway（網關）
• Uplink CLI（控制檯命令）
• **衛星節點: **用於緩存節點地址，存儲對象元數據，維護存儲節點信譽，聚合計費數據，支付存儲節點，執行審計和修復，以及管理授權和用戶帳戶。

用戶擁有帳戶並信任特定的衛星節點。任何用戶都可以運行他們自己的衛星節點，Storj希望許多用戶選擇使用其他衛星節點，避免操作複雜。有了衛星節點，Storj整體架構就非常靈活。

注意：中國不少自媒體，我就不點名，宣稱Storj採用了天上的衛星傳輸技術，因爲白皮書裏面寫了Satellite。其實衛星節點根本就不是天上的衛星，而是分佈式系統中一個角色。

框架

Storj的設計，框架內的都將執行以下操作：存儲數據; 檢索數據; 維護數據; 支付費用。

獨立的模塊有：存儲節點；P2P的通訊和發現；冗餘；元數據；加密；審計和信譽；數據修復；支付。

存儲節點

存儲節點的作用是存儲和返回數據。選擇存儲節點以基於各種標中和評估：ping時間，延遲，吞吐量，帶寬上限，足夠的磁盤空間，地理位置，正常運行時間，準確響應審計的歷史記錄等等。這點和傳統P2P項目選擇節點的方式非常接近。

• 可以存儲具有特定TTL到期的片段，其中期望在到期之後刪除數據。
• 存儲節點必須另外跟蹤已簽名的帶寬分配，以便發送到衛星節點以後進行結算和支付。
• TTL和帶寬分配都存儲在SQLite數據庫中。
• 存儲節點可以選擇使用哪些衛星節點。 如果它們使用多個衛星節點（默認行爲），那麼付款可能來自不同的付款時間表上的多個來源。
• 未通過隨機審覈的存儲節點將從池中刪除，可能會損失託管中的資金以支付額外費用，並且將來只會收到付款。
• 存儲節點將支持三種方法：get，put和delete。 每種方法都將採用分片ID，衛星節點ID，來自相關衛星節點實例的簽名以及帶寬分配。
• 存儲節點將允許管理員在過去30天內配置允許的最大磁盤空間和每個Satellite的帶寬使用量。

P2P的通訊和發現

網絡上的所有節點都通過一個標準兒協議通信。這個協議支持以下幾點：

• P2P的可達性，即使面對防火牆和NAT。這需要STUN，UPnP，NAT-PMP等技術。
• 提供S/Kademlia中的身份驗證，其中每個參與者以加密方式證明與其通話節點的身份，以免中間人攻擊。
• 提供完全隱私，默認情況下所有通信都是私密的。
• 可以在我們選擇的對等通信協議之上構建各種重疊網絡覆蓋，例如Chord，Pastry或Kademlia，以提供發現服務。

冗餘

Storj白皮書v2中就提到了冗餘，但那時採用的是簡單冗餘。Storj白皮書v3說明了簡單冗餘的缺陷，改用了糾刪冗餘。下面我想說下簡單冗餘和糾刪冗餘的優缺點。

簡單冗餘

在存儲系統的不同位置創建數據副本，這個副本和之前數據一模一樣。

• 通常爲2或3份，可根據風險等級進行配置
• 如果驅動器發生故障，則會在副本的另一個驅動器上重新創建數據
• CPU計算資源佔用更低 = 寫入性能更快
• 簡單恢復 = 更快的重建性能
• 需要2倍或更多的原始存儲空間和帶寬

糾刪編碼

基於奇偶校驗的保護技術

• 數據分成碎片並編碼
• 使用可配置數量的冗餘部件，且不用部件存儲在不同位置
• 比簡單冗餘消耗更少的存儲空間 - 適合廉價/深度存儲
• 允許存儲系統的兩個或多個元素髮生故障
• 奇偶校驗計算是消耗CPU計算資源的
• 會增加延遲，也可能會減慢生成，寫入和重建的速度

裏德-所羅門 糾刪碼

Storj使用的就是裏德-所羅門 糾刪編碼

• 如果用 (k,n) 糾刪碼編碼數據塊，則總共有n個糾刪片段，其中只需要任何k個就能完全恢復原始數據塊。
• 如果數據塊是s字節，則每個糾刪片段的大小大約是 s/k 字節。
• 當k = 1時，所有糾刪都是一樣的，這相當於複製。
• 1MB數據, 如果採用（10,16）糾刪碼，並且糾刪片段數量是0.1M，則總存儲數據就是 1.6MB。

上傳和下載

Storj並不是只要發現冗餘少了，馬上就增加冗餘，而是分了情況以確定是否增加冗餘。

• K：重建數據所需的最低要求
• M：最低安全值，相當於重建數據的安全緩衝
• O：最佳值，能夠應付節點波動的緩衝區
• N：長尾冗餘

K的含義是：如果可用冗餘的數量低於K，數據將丟失。簡單說，k就是生死線。

M的含義是：當衛星節點發現到可用冗餘的數量已經降至M以下，則它立即觸發修復機制，以確保我們總是保持K個或更多。簡單說，m就是安全線。

O是存儲的目標冗餘度。 這個值用於上傳和修復過程中，一旦O個分片完成了上傳，那麼多餘的k-n之間的分片將被取消。

因此，值N是超出目標冗餘度。

在Storj的設計中，未被確認信譽值的礦工，或者信譽值不高的礦工，就用於保存O到N之間的冗餘度，這部分是沒有收益的，直到任務足夠產生信譽值之後，才能獲得收益。簡單地說，不穩定或者性能不達標的存儲礦工是用於是存儲多餘的冗餘的，他們不能獲得收益。國內不少礦工抱怨Storj挖不到幣，說Storj不靠譜；其實不是Storj不靠譜，而是他自己不滿足Storj要求，不符合Storj的激勵機制。

耐用性

Storj白皮書v3仔細測算了耐用率。這個QoS指標非常重要。

Storj是在數學上是用泊松分佈對依賴時間的過程進行建模的。其中假設在給定的單位時間中觀察到事件。 因此，我們將耐用性建模爲Poisson分佈的累積分佈函數（CDF），其中平均數 lamda = pn，其中我們假設文件的片段每月會丟失。 爲了估計耐用性，我們假定CDF爲n-k，考慮一個月內文件中最多n-k個部分丟失的概率，並且文件仍然可以重建。 CDF公式如下：

$P(D)=e^{-\lambda}\sum_{i=0}^{n-k}\frac{\lambda^i}{i!}$

Storj做了如下假設：

p是糾刪副本的每月丟失率， Storj假設它是10%
n和k分別是糾刪算法參數
lamda就是泊松分佈的平均數，是p*n
Exp.factor就是冗餘的倍數

可以看到，Storj是能夠做到很好的月耐用性的。

但是，這個測算過程是有些問題的。

1. 整個測算過程中，Stroj沒有考慮糾刪分片恢復的時間。如前面所說，Storj設計了K,M,O幾個參數，糾刪分片丟失後，是可以恢復的。
2. 計算的結果，得到的P只是月耐用性數據，而存儲業內一般用年耐用性作爲平臺的參數。AWS S3公佈的耐用性是年耐用性。
3. CDF公式是泊松分佈的擬合公式，CDF公式得到的是近似值，只有當p很小，n很大的的時候，才適用於CDF公式。而Storj的假設，p=0.1已經不小了，CDF公式得到的數字並不完全準確。Storj白皮書V3還計算k=1的情況（就是模擬簡單副本），這個k=1的計算出的數字偏差就比較大了。

數據

這裏定義了Storj的每個數據單位：

• 桶：存儲桶是由路徑標識的文件集合。每個文件在存儲桶中都有唯一的路徑。這和AWS S3中桶的定義一樣。
• 路徑：路徑是存儲桶中文件的唯一標識符。這和AWS S3中桶的定義一樣。除非另有要求，否則我們會在文件離開客戶計算機之前對其進行加密。
• 文件或對象：文件或對象是存儲的文件實體。這和AWS S3中對象的定義一樣。
• 擴展屬性：擴展屬性是與文件關聯的用戶定義的鍵/值字段。與其他文件元數據一樣，擴展屬性以加密方式存儲。
• 分段：分段表示單個字節數組，介於0和用戶可配置的最大段大小之間。
• 遠程分段：遠程分段是將分散在網絡上糾刪編碼。遠程段大於其所需的元數據，其中包括存儲數據的節點ID等信息。
• 內聯分段：內聯分段是一個足夠小的段，它所表示的數據大小少於遠程分段，需要跟蹤哪些節點具有相應的數據。在這些情況下，數據存儲爲“內聯”而不是存儲在節點上。
• 條帶：條帶是分段的進一步細分。條帶是固定數量的字節，用作加密和糾刪編碼邊界大小。糾刪編碼單獨發生在條帶，條帶也是執行審計的單位。
• 糾刪片段：當條帶被糾刪編碼時，它會生成多個分片，這就是糾刪片段。只需要一部分糾刪片段來恢復原始條帶。每個糾刪片段都有一個索引標識它是哪個糾刪片段。
• 分片：當遠程段的條帶被糾刪編碼爲糾刪片段時，具有相同索引的該遠程分段的糾刪片段被連接在一起，並且該連接的糾刪片段組被稱爲分片。第i個部分是來自該部分條帶的所有第三個糾刪片段的串聯。
• 指針 ：指針是一種數據結構，它包含內聯數據分段，或跟蹤遠程分段的各個存儲節點以及其他每個文件元數據。

這就是Storj中的數據單元的示意圖：

元數據

之前，Storj 白皮書V2中就簡單提到了元數據，白皮書v3說明了元數據的細節。

• 添加，編輯或刪除對象時，需要調整此元數據存儲系統中的一個或多個條目。
• 在這個元數據系統中可能會有大量的流失，並且在整個用戶羣中，元數據本身變化得相當大。
• Storj希望該平臺包含多個元數據存儲實現，用戶可以在其中進行選擇。
• Amazon S3兼容性，Put（在給定路徑上存儲元數據），Get（在給定路徑上檢索元數據），List（現有路徑的分頁，確定性列表）和Delete（刪除路徑）。

加密

所有數據或元數據都將被加密。在數據離開源計算機之前，必須對數據進行加密。與AWS S3接口兼容的客戶端庫應該和 用戶的應用程序在同一臺計算機上運行。我們的加密選擇是經過驗證的加密。這是爲了便於用戶知道是否有數據被篡改。加密應使用可插拔機制，可以選擇不同的加密算法。Storj採用BIP32的分層加密技術，這技術允許共享子樹而不共享其父級，也就是允許共享某些文件而不共享其他文件。

應對每個文件使用不同的加密密鑰，因爲訪問一個文件將導致訪問所有文件的解密密鑰。因此，Storj每個文件採用不同的密鑰加密。數據以小批量條帶爲單位來加密，建議爲4KB或更少。路徑也是加密的。與BIP32一樣，加密是分層的和確定的，並且每個路徑組件都是單獨加密的。

審計

審計只是用於確定節點穩定程度的機制。

• 審計員（如衛星節點）將向存儲節點發送挑戰並期望得到有效響應。
• 作爲HAIL系統，Storj使用糾刪編碼，一次讀取單個條帶作爲挑戰，然後驗證糾刪片段的響應。這使得Storj可以進行任意審計，在沒有預先生成挑戰的情況下。
• Storj要求所有存儲節點的糾刪片段是負責任的。然後，Storj在所有糾刪片段中運行Berlekamp-Welch算法[39,73]。當足夠的存儲節點返回正確的信息時，可以輕鬆識別任何錯誤，響應丟失。

存儲節點信譽

要確定哪些文件需要修復，存儲節點運行時間和總體健康狀況是主要指標。根據每個節點的審計歷史，建立一個信譽系統給定節點確定身份。存儲節點信譽可以分爲四個子系統。

1. 工作識別系統證明：要求對存儲節點運營商被投資的簡要證據， 通過時間，份額或資源。
2. 初始審查過程：慢慢允許節點加入網絡。
3. 過濾系統：它阻止不良存儲節點參與。
4. 優先系統：審計時收集的統計信息，將用於爲上傳好的存儲節點建立優先權。

數據修復

爲了修復數據，Storj將通過從剩餘部分的糾刪碼來恢復原始數據，然後重新生成丟失的部分，並將它們存儲在新存儲節點上。

支付

• 性能充足的存儲系統是無法等待區塊鏈緩慢操作的。
• Storj的框架反而更像遊戲理論模型，確保網絡中的參與者得到適當的激勵，以保持長期在線，從而理性地行動以獲得報酬。
• Storj框架中的存儲節點應限制他們與不信任的付款人接觸。
• 基於以太坊的STORJ ERC20通證作爲支付的默認機制，將來可以實施其他替代支付類型。

衛星節點

衛星節點：保存元數據的服務集合。網絡用戶將擁有特定衛星節點上的帳戶，該實例將存儲文件元數據，管理數據授權，跟蹤存儲節點的可靠性，在減少冗餘時修復和維護數據，代表用戶向存儲節點付款。

注意，Storj中， 用戶不是直接向存儲節點付款的，而是用戶先付款給衛星節點，然後衛星節點再付款給存儲節點的。

1. 衛星節點正在開發中，將作爲開源軟件發佈。任何個人或組織都可以運行自己的衛星節點以方便網絡訪問。
2. 從未向衛星節點提供未加密的數據，並且不保存加密密鑰。
3. 衛星節點實例由以下組件組成：

• 完整節點發現緩存
• 由加密路徑索引的每對象元數據數據庫
• 帳戶管理和授權系統
• 存儲節點信譽，統計信息和審覈系統
• 數據修復服務
• 存儲節點支付服務

這是put操作的圖：

這是get操作的圖：

授權

• 元數據操作將被授權。用戶將使用他們的衛星節點進行身份驗證，這將允許他們根據其授權配置訪問各種操作。
• 一旦通過衛星節點授權Uplink，衛星節點將批准對存儲節點的操作，包括帶寬分配。Uplink在使用存儲節點進行操作之前，必須從衛星節點檢索有效簽名。

寬帶分配

• 如果Uplink被授權用於請求，則衛星節點將只創建帶寬分配。在存儲操作開始時，Uplink可以將帶寬分配傳輸到存儲節點。存儲節點可以驗證衛星節點的簽名並執行所請求的操作，直到允許的帶寬用滿，存儲並稍後將帶寬分配發送到衛星節點以進行支付。
• 在Get操作的情況下，假設衛星節點簽名的帶寬分配允許最多x個字節。Uplink將通過發送一些少量（y字節）的受限分配開始，然後逐步再發送另一個分配，其中y越來越大，繼續發送，直到y增長到x。

垃圾回收

• 每次刪除數據時，聯網和可訪問的存儲節點都會立即收到通知。
• 存儲節點有時會暫時不可用，並且會丟失刪除消息。在這些情況下，不需要的數據被視爲垃圾。

Uplink

Uplink 就是Storj的軟件中間層。

• 任何調用libuplink的軟件或服務，以爲了與衛星節點和存儲節點交互。
• Libuplink - libuplink是一個庫，提供對Storj網絡中存儲和檢索數據的訪問。
• 網關 - libuplink上的一個簡單服務層。我們的第一個網關是Amazon S3網關。
• Uplink CLI - 一個調用libuplink的命令行應用程序

未來工作

Storj的白皮書V3中提到了他們未來要做什麼事情。

• 熱門文件和內容分發。
• 如有必要，衛星節點可以臨時暫停訪問，增加文件在更多存儲節點上的冗餘，然後繼續允許訪問。
• 改善元數據的用戶體驗。
• 從長遠來看，我們計劃將衛星節點構建出平臺。我們希望通過可行的拜占庭容錯一致性算法完全取消對元數據的衛星控制。

總結

優點

1. 以產品和市場爲目標，Storj真正重視了服務質量QoS，真心希望將去中心化存儲落實到使用場景。
2. 非常注重安全和隱私，這是第一設計準則。
3. AWS S3兼容性，支持了AWS S3的幾個核心API。對開始者來說，這是一件好事。
4. 避免拜占庭分佈式共識，這樣就能大大提升效率。
5. 設計了冗餘細節，認真測算了耐用性，這是一個成熟的存儲系統中最重要Qos。
6. 設計元數據，並單獨對元數據做了處理。元數據不用於普通數據，是變化很頻繁的。
7. 審計和信譽，特別引入了信譽值，對整體經濟系統有積極的良性影響。

缺點

1. 非常依賴於糾刪技術，數據修復開銷非常大。
2. 依然很少提及區塊鏈技術，Storj對區塊鏈技術的考慮非常少，作爲一個做了4年多的項目，卻還是中心化的結算方式，有那麼點讓人失望。
3. 衛星節點是個非常集中的設計。除了存儲數據外，其他所有的事情都由它做完。
4. 每月支付，支付週期太長，對存儲節點來說不夠友好，特別是新存儲節點，得到的反饋很慢。
5. 帶寬分配，以字節爲單位，力度太低。
6. 很少考慮熱門文件和內容分發的情況。

我爲什麼寫這篇文章

我的其他文章提到過，我設計和發起了PPIO存儲公鏈項目，旨在給開發者提供去中心化的存儲和分發網絡，使得更便宜，更快，更隱私。雖然我設計的PPIO項目和Storj有些相似，但我寫這篇文章是完全站在中立的角度寫得。我認爲去中心化存儲相對於中心化存儲（如AWS S3，GoogleCloud，Microsoft Axure）來說是個全新的賽道。而這個新賽道的發展，以及最終產生價值，都是需要大家共同探索的。我希望能夠共同進步。

我在設計PP.IO的時候，我之前設計的很多想法和Storj剛發佈的白皮書V3中提到的非常類似，包括兼容AWS S3，重視Qos，將去中心化存儲和區塊鏈系統視爲2個獨立的子模塊，使用糾刪副本，測算耐用率，設計了監督節點（類似Storj衛星節點的審計）。當然，PP.IO也有很多和Storj不一樣地方，PP.IO有很多地方的設計比Storj要優秀得多，我後面會寫文章來逐步說明。大家可以關注PP.IO的官網 http://pp.io 。

我的郵箱是 [email protected]。如果有任何問題，歡迎聯繫我。

文章作者：Wayne Wong

轉載請註明出處

如果有關於PPIO的交流，可以通過下面的方式聯繫我：

加我微信，注意備註來源

wechat：omnigeeker