去中心化存储最主要解决以下几个问题：

多个矿工声称存储了一个数据的多个副本（多备份）的情况下，如何验证这多个矿工真的存储了多个副本，而不是只存储了一个，甚至一个都没有存储，只是在检查的时候从别的矿工获取；

如何验证矿工不仅仅是某一个时刻点存储了副本，而是一直存储这副本？

第二个问题相对来说比较简单，一个比较容易理解的方案是：不停的，随机发出挑战，要求矿工进行相应；filecoin的windowPost就是这样设计的。但很明显这样的设计有很大的缺点，那就是协议内部的windwoPost挑战交易占用了大量的网络交易带宽，从而降低了网络的实际TPS；同时让状态数据膨胀的比较厉害；

第二种比较优雅的解决方案是：矿工在争夺出块权时，扫描自己所有存储的副本以应对随机出块挑战，存储的副本越多，获取超过随机挑战的可能性越大，从而赢得出块权的概率越大；让争取出块权和检查数据一直在存储的两件时间融为一件事；像Autonomys Network就是采用这种更加先进的方案；

但是以上方案还没有回答一个比较重要的问题，那就是如何验证矿工对挑战的影响是否正确？验证的解决方案和第一个问题是紧密相关的；

为了解决第一个问题，很容易想到的一个方案就是，每个矿工存储的都是源数据的副本，而不是源数据，对于挑战的响应也都是基于副本数据，而不单单是源数据；

为了防止矿工只存储一份源数据，然后在每次挑战中，实时根据源数据来计算出副本并影响挑战（这样做就无法保证数据的多备份存储）；我们需要对于副本的生成在生成时间或者生成成本上进行限制；比如：让生成副本的时间比较长，从而超过了挑战响应的时间，或者响应比较慢，因而收到惩罚（抢不到出块权：autonomys或者直接被罚钱：filecoin）；如果增加计算设备的性能，实时计算副本以应对挑战在时效上也是可以的情况下，但是计算设备的性能增加所带来的成本如果大于存储副本的成本的话，也同样可以到达让理智的矿工存储多副本的目的（arweave的方案）；

从以上论述可以知道，生成副本的算法需要有两个特点：

生成速度慢；甚至不可以gpu加速或者asic加速；不然会导致整个网络也许只有几个源数据，但是却显示有非常多的存储；也可以说整个网络已经被攻破了；当年arweave好像就被gpu这样的方式攻破了；

验证非常快；不然整个网络的tps就会非常低；

为了保证封装（filecoin叫seal，autonomys叫plot， arweave叫packing）不可以用gpu或者asic加速，一般采用的方式都是增加随机性（randomX哈希算法）和利用内存密集型技术；

更具体的一些算法思路如下：

gpu在某些方面快的本质是利用了几万，甚至几十万并发能力；如果我们能找到一种算法限制并发的数量，就能让gpu无法比cpu更快；很容易想到的一个方法就是串行计算，比如：对某个数据进行hash一万次，每次hash的输出就是下一次hash的输入；这就保证了算法无法并行化，同时因为cpu的最高主频会比gpu更快，从而理智的矿工会选择cpu而不是gpu。

asic本身也是一种cpu芯片，只是只能专门做某些计算，而不是通用型的计算；为了防止封装用asic，我们可以对算法增加随机性，从而增加asic的设计难度，还可以增加算法对内存的使用量，做内存密集型的计算，减少对于主频（非计算密集型）的依赖，同样可以防止封装时大家来利用asic；

为了保证数据的可用性，封装数据的解封最好时快速的，这一点上面好像都做的不怎么样。不管是filecoin还是autonomys，封装时间和解封时间都是一样的；

但是autonomys可以对一个sector（1G）数据的部分（piece：1M）进行解封，从而使autonomys的数据可用性（解封后才能检索，才能使用）比filecoin好很多；

filecoin 一个sector（32G最小）的封装和解封时间都是2个小时以上，所以不可能用于热数据存储；

从上面的论述我们可以很容易做出一个简陋的算法：

把数据分成一个个小块chunk，然后得到小块的merkle树的root；

用矿工私钥对所有数据chunk加密一万次得到chunk-e；

对chunk-e和随机挑战做异或，然后hash；看hash值是否大于难度值；大于则抢的出块权；

提交chunk-e，chunk源数据，chunk的merkle proof；

用矿工公钥解密chunk-e一万次，得到chunk-d，查看chunk-d是否等于chunk源数据，并根据merkle proof和root进行验证保存的数据就是网络期望保存的数据；

因为不知道哪个chunk可以得到出块权（因为加密和hash的随机性），所以矿工需要对所有的chunk数据都公私钥加密，所以封装时间是耗时的；

但是验证只会对一个chunk进行解密，所以验证是迅速的；

这样就符合了我们对于封装算法的量大要求；

声明：本网站所有相关资料如有侵权请联系站长删除，资料仅供用户学习及研究之用，不构成任何投资建议！