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%不可能的。（在这里坐等打脸） 那不通过流量给过出块奖励，挖矿挖个啥，难道挖了个寂寞？其实也不是，挖的是流量费，即数据的请求节点向服务节点支付流量费，所以节点的收益来源于其他节点给的流量费。 那这样也有问题，流量费是后支付还是先支付？ 如果是后支付，请求节点会不会拿了数据后不支付流量费？ 如果是先支付，服务节点会不会拿了流量费不给数据？ 为了解决这个问题，可以采用逐步支付的机制，即服务节点每传输一段数据（比如说1M），等待请求节点回一个收据（或者叫支票），如果你不回支票给我，那我后面就不传数据给你，并且把你拉入黑名单，这样服务节点即使损失，也就损失一小部分流量费。而请求节点作恶多了，全网就没有节点会答理他了，也是因小失大。通过这样的方式可以实现流量的计费。 但是上述方案有一个总是，一段数据设置成多大比较合适？如果设置的比较小，比如是1MB，如果100Mbps的网络节点，每秒都需要产生一个收据，全网假如几十万节点，这个收据（支票）的数据量巨大无比，根本不可能处理的过来。如果设置的比较大，那请求节点可能会逃费。 这个问题就需要可合并的收据（支票），swarm里没有做这个事，会不会有问题？目前测试网12万个节点已经很堵了（别忘了测试网的流量应该很小哦），未来主网上，应该问题会更重。 这些收据（支票）提交给链上，链上根据收据的签名和目标，将相应的代币从数据的请求者节点转移到服务者节点，这个是通过智能合约来实现的。 因此，我们可以得到以下几个结论： 1、Swarm挖矿没有出块奖励，是节点之间的流量费互传； 2、节点能够收到的流量费的上限与带宽有关，带宽越高，流量费上限越高； 3、节点能够传输的流量还受限于节点的系统瓶颈，而在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随机读写性能。 因此我们可以得到如下的结论： 1、使用机械硬盘作存储，还在上面跑多个节点是扯淡的，没知识没文化的无脑方案； 2、每个SSD硬盘可以支持大约1Gbps的带宽（片段信息的管理也需要用掉一部分的磁盘IO）； 通过前面的原理描述，文件片段被自动推送到不同的节点，而读取时，自动从不同的节点上读取数据，因此自然推理，是不是多个节点就能收到更多的文件片段数据，被读取的概率更大一些，从而获得更多的收益？ 答案是肯定的，因此我们可以在一台物理节点上尽可能地跑多个节点，从而获得更多的收益，当然就别使用HDD的，使用HDD跑再多也没有用。 这时候，我们需要考虑另外系统的瓶颈了：CPU。当节点跑得起多，CPU需求就越高，不同的CPU的性能不同，此处就无法给出定量的数据了。 因此，我们可以得到另外一个结论： 当使用SSD，网络带宽足够的情况下，运行更多的节点将会带来更多的收益。 实际上，当跑多个节点，比如说5个以上的时候，明明带宽没满，磁盘IO也满了，这个是由于代码本身没有做优化导致的。至于该怎么优化，后续文章再详细讨论。
