近期火爆的Swarm是什麼？其代幣Bzz怎麼樣？

Swarm是以前以太坊上的一個點對點全球化檔案系統，是目前為止和IPFS對標的唯二的P2P全球化檔案系統。今年2月份收到了6百萬刀的天使投資，原來是準備發BI了。

SWARM是個啥

技術總是繁瑣的，我儘量簡單點。

雜湊運算雜湊運算是一系列演算法的總稱，反正就是對一段資料進行處理，得到一個固定大小（一般是32位元組）的結果，這個結果稱為雜湊值 。 並且原始資料不同，得到相同雜湊值的概率非常非常非常小，這樣的過程稱為雜湊運算。雜湊運算其實是讓一個固定長度，相對短的資料來表徵一個任意長度的資料。

內容地址任意的一段資料，對資料內容進行一次雜湊運算的結果（雜湊值），可以稱為這個資料的內容地址。這個稱謂的來源是因為地址是由內容決定的。

分散式雜湊表每個節點裝置，同樣有一個地址，這個地址的來源可以一段隨機數的雜湊值，一旦生成，節點的地址就不變。 這裡可以看到節點地址和內容地址是同類型的，這個稱為節點與資料「同構」。

既然都是32位元組的資料，我們就可以計算兩個地址之間的「距離」，這個距離是「邏輯距離」和實際的物理位置無關。計算距離可以有多種演算法，最常用的是異或。我們這裡為了方便理解，可以理解為兩個地址值相減，相減的結果越小，地址就越近。

有了內容地址和邏輯距離的概念，我們可以這樣實現分散式雜湊表：

任何的資料，在全網中都可以推送到離其內容地址邏輯距離最近的節點上。

這個推送的實現過程可以簡化為一句話：

當節點收到資料時，在所連線的鄰近節點中，尋找與這個資料的內容地址更近的節點，然後推送給這些節點。資料的讀取過程也可以簡化為一句話：

當節點收到資料讀取請求時，首先看自身有沒有快取內容地址所對應的資料，如果有，直接取出返回給請求者；如果沒有在所連線的鄰近節點中，尋找與內址地址更近的節點，把資料讀取請求轉發給這些節點。上述的簡單方案就可以實現資料的推送和讀取。實際的實現中，需要考慮很多異常因素，我們此處不表。

Swarm與IPFS對比Swarm其實不是儲存系統，而是流量分發系統。為什麼這麼說呢？我們先看一下IPFS系統。

IPFS是儲存系統，當檔案儲存到IPFS節點A上時，IPFS會把檔案的資訊推送到全網某個地方，後續有其他節點B需要資料時，從該節點獲取該檔案的檔案資訊。這個檔案資訊中包含檔案所在的節點，因此B就知道了檔案在A這裡，因此B試圖與A連線，從A讀取檔案資料。當節點B讀取了檔案資料後，同樣把自身有的這個檔案（或是檔案中某個片斷）的資訊推送到全網某個地方。 後續當節點C需要讀取檔案時，從全網中找到A和B都有這個檔案資料，然後試圖連線這兩個節點（A和B）讀取檔案資料，顯然隨著檔案被讀取次數的增加，檔案在網路中擴散的越多，讀取速度也越快，但是在初期速度非常慢，甚至有可能讀不到（假設A和B都在內網裡），因此IPFS系統裡有網路穿透的概念，此處不多描述。

在SWARM中，檔案按照4KB大小的片段切割形成一個金字塔結構。然後按照演算法將每個片段不斷推向某個地方，在推送的過程中，所有的中間節點都會快取一份資料。

當需要讀取該檔案時，首先從某個地方讀取到這個檔案的根，然後從根中讀取不同的檔案片段資訊，然後根據不同的片段從網路中不同的地方讀取出相應的內容。

從上述可以明顯看到，資料一旦被提交到swarm網路，會被自動切分並且分散推送到全網的不同節點，而在ipfs網路中，這個資料如果沒有人讀取是不會被擴散的。

swarm的方式可能會提高資料的讀取效能，但是資料會被自動推送到不需要儲存資料的節點上，浪費寶貴的儲存和頻寬，這個是IPFS裡明確避免的。

反正有得必有失，有失必有得，通過自動擴散，資料內容自動傳播到網路中的不同節點以備讀取，所以我稱其為內容分發系統。

IPFS和Swarm各有其缺陷和優點，那能不能綜合兩者呢？這個是我們正在做的事情，以後有機會再寫文章。

SWARM挖礦分析

從上述原理就可以看出來，Swarm更注重的是流量，而流量傳輸有一個問題：

流量的傳輸內容和大小，只有傳輸的雙方知道，鏈上其他節點不知道。

其實資料的儲存也是一樣，資料的儲存正確與否，大小多少也是隻有儲存的需求者和提供者知道，要想讓其他人知道怎麼辦？需要使用零知識證明，Filecoin就是實現了這個零知識證明，此處按下不表。

流量傳輸的這個問題導致另外一個問題：

由於流量傳輸的內容和大小，其他節點不知道，因此鏈上不能使用這個流量的大小作為算力。大家知道，區塊鏈裡面的算力是出塊的依據，即節點算力佔全網算力的比例就是節點出塊的概率，這樣才是公平的出塊機制。流量不能作為算力就意味著不能通過流量進行出塊獎勵。

因此SWARM無法實現僅基於流量的區塊鏈系統，即流量必須依賴於另外一條主鏈。

在swarm中，主鏈依賴以太坊，目前使用的以太坊的測試鏈，官方號稱未來將基於以太坊主網，在這裡我可很明確地和大家說，這是99.99999999%不可能的。（在這裡坐等打臉）

那不通過流量給過出塊獎勵，挖礦挖個啥，難道挖了個寂寞？其實也不是，挖的是流量費，即資料的請求節點向服務節點支付流量費，所以節點的收益來源於其他節點給的流量費。

那這樣也有問題，流量費是後支付還是先支付？

如果是後支付，請求節點會不會拿了資料後不支付流量費？如果是先支付，服務節點會不會拿了流量費不給資料？為了解決這個問題，可以採用逐步支付的機制，即服務節點每傳輸一段資料（比如說1M），等待請求節點回一個收據（或者叫支票），如果你不回支票給我，那我後面就不傳資料給你，並且把你拉入黑名單，這樣服務節點即使損失，也就損失一小部分流量費。而請求節點作惡多了，全網就沒有節點會答理他了，也是因小失大。 通過這樣的方式可以實現流量的計費。

但是上述方案有一個總是，一段資料設定成多大比較合適？如果設定的比較小，比如是1MB，如果100Mbps的網路節點，每秒都需要產生一個收據，全網假如幾十萬節點，這個收據（支票）的資料量巨大無比，根本不可能處理的過來。如果設定的比較大，那請求節點可能會逃費。

這個問題就需要可合併的收據（支票），swarm裡沒有做這個事，會不會有問題？目前測試網12萬個節點已經很堵了（別忘了測試網的流量應該很小哦），未來主網上，應該問題會更重。

這些收據（支票）提交給鏈上，鏈上根據收據的簽名和目標，將相應的代幣從資料的請求者節點轉移到服務者節點，這個是通過智慧合約來實現的。

因此，我們可以得到以下幾個結論：

Swarm挖礦沒有出塊獎勵，是節點之間的流量費互傳；由於1，節點能夠收到的流量費的上限與頻寬有關，頻寬越高，流量費上限越高；另外，節點能夠傳輸的流量還受限於節點的系統瓶頸，而在swarm方案中，系統瓶頸是磁碟IO。根據上述2和3，可以推斷礦機的硬體需求和配置

SWARM礦機

由於FIL的前車之鑑，導致很多人以為SWARM也會象FIL那樣礦機要求在不停變，所以不敢推薦礦機方案，實現上SWARM和FIL是不一樣的。我們可以分析出SWARM的瓶頸以及配置方案。

SWARM中每個片段大小為4KB，資料儲存於磁碟上，因此資料的訪問能力受限於磁碟IO，我們可以根據磁碟的IOPS（每秒讀寫IO次數）效能計算出每一種磁碟的SWARM讀寫效能：

HDD硬碟： HDD硬碟的IOPS最高約為在76（7200轉）到166（15000轉）之間，因此讀寫效能在 (76~166)x4KB=300KB-664KB每秒！！ 如果折算成頻寬，就是一個3-6Mbps，也就是說，如果使用一個機械硬碟，即使在一臺機器上運行了再多的節點，使用了再多的頻寬，也只有最高3-6Mbps頻寬的收益上限。SSD： SSD的IOPS最高大約在4萬，因此讀寫效能的極限在40000x4KB = 160000KB = 160MB。折算成頻寬，大約在1.6Gbps。 同樣一臺機器上運行再多的節點，使用再多的頻寬，收益的上限是1.6Gbps!由於SWARM使用了4K片段，因此磁碟IO的讀寫效能就是標準的4K隨機讀寫效能，可以在網上查詢磁碟的4K隨機讀寫效能

因此我們可以得到如下的結論：

使用機械硬碟作儲存，還在上面跑多個節點是扯淡的，沒知識沒文化的無腦方案每個SSD硬碟可以支援大約1Gbps的頻寬（片段資訊的管理也需要用掉一部分的磁碟IO）.通過前面的原理描述，檔案片段被自動推送到不同的節點，而讀取時，自動從不同的節點上讀取資料，因此自然推理，是不是多個節點就能收到更多的檔案片段資料，被讀取的概率更大一些，從而獲得更多的收益？

答案是肯定的，因此我們可以在一臺物理節點上儘可能地跑多個節點，從而獲得更多的收益，當然就別使用HDD的，使用HDD跑再多也沒有用。這時候，我們需要考慮另外系統的瓶頸了：CPU。 當節點跑得起多，CPU需求就越高，不同的CPU的效能不同，此處就無法給出定量的資料了。

因此，我們可以得到另外一個結論：

當使用SSD，網路頻寬足夠的情況下，運行更多的節點將會帶來更多的收益。實際上，當跑多個節點，比如說5個以上的時候，明明頻寬沒滿，磁碟IO也滿了，這個是由於程式碼本身沒有做優化導致的。至於該怎麼優化，後續文章再詳細討論。

關於SWARM的未來

在我看來，SWARM是一個非常偉大的項目，在很多地方做出了有益的嘗試，但是目前的實現還未能夠到達滿足實際應用需求的程度。在可見的將來能夠落地取得大規模商用是幾乎不可能的，但是作為區塊鏈項目，是非常值得參與的。

目前的4KB大小的片段嚴重影響了系統的效能，改成和IPFS一樣的256K將會對效能有極大的提高。

瞭解更多資訊關注小編吧

文/星雲