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