区块链存储的问题和挑战
分布式存储峰会于2019年8月23日在柏林召开，大会聚集了IPFS、Sia、Storj、ethereum swarm、Arweave、Filecoin等区块链存储领域的所有主流项目，可以说是一次难得的盛会。
本文是根据Jacob Eberhardt在大会开幕演讲的内容整理而成。解读配上图片，再加上原有内容的思考深度和内容范围（从数据存储到数据库），相信会给读者带来一些启发思考。
内容分为两部分，第一部分的内容是去中心化存储。
存储可以被理解为一种记忆力，一种对可检索数据的记忆力。具体来说，就是存储文件，也就是存储不可解释的数据块。
一个最简单的例子是客户端把数据存储在本地文件系统中，这种方案具有一些风险：
本地文件系统成为单点故障
当其他客户端请求数据时，本地文件系统成为瓶颈
客户端本身要负责数据的安全
由于本地存储的局限，中心化存储的方案被提出，这种方案可以是远程，也可以是本地。一个单一存储提供方通过API封装存储细节，客户端通过存储提供方的API执行CRUD操作，如上图所示。
在这种中心化存储方案中，系统中存在一些角色：
客户端：通过连接服务器端下载和上传，比如上图中的Uploader和Downloader。
服务器端：也就是存储提供方，用简单的API封装存储细节。
中心化存储的一个典型案例是亚马逊的S3。从中可以看出中心化存储的一些特性：
11个9的可用性
22美元/每TB/每月
客户端加密和服务器端加密
通过增加硬件实现近似线性的容量扩展
复杂的后端系统，简单的API
可信读写：可用性、持久性和安全性
经济激励亚马逊行为合规
而去中心化存储的架构是一个客户端可以连接到多个服务器端（存储提供方）。
在去中心化存储的系统中，没有客户端和服务器，只有节点和对等节点：
节点：也就是中心化存储中的客户端，但也可以提供存储服务，比如上图中的Uploader、Downloader和Storage Provider。
对等节点：也就是中心化存储中的服务器端，但可以是多个存储提供方，这些存储提供方不仅可以提供存储服务，也可以上传和下载数据。如上图所示。
类似去中心化存储架构的系统已经存在，比如2001年的Bittorrent和2015年的IPFS：
Bittorrent是一个点对点的文件共享网络，torrrent文件包含校验和以及到追踪节点的链接（追踪节点可以转发到种子节点）。
IPFS是一个内容寻址的点对点的去中心化文件系统，用户自己决定是否绑定文件和缓存在本地。
Bittorrent和IPFS是典型的缺乏激励的去中心化存储系统，也就是说，完全的去中心化，但是缺乏激励。在这样的系统中，对等节点可以在任意的时间关机，文件因此而丢失，客户节点的请求也可能被拒绝，以及期待对称的参与模型（比如对等节点水蛭吸血问题和搭便车问题）。总之，在这样的系统中，没有可用性、持久性和性能的保证。
区块链存储的提出解决了去中心化存储系统缺乏激励的问题，其实，区块链存储也可以理解为带有激励的去中心化存储，其基本模型如上图所示。由于在每一次具体存储操作的场景中，对等节点之间的操作依然存在客户端和服务器模型，因此上图使用客户端的标识，客户端和服务器端之间的箭头是双向的。
在这样的系统中，使用加密经济协议来保证存储系统所需的属性，并使用区块链来支撑这些协议。在设计区块链存储系统时，有两个不同目标需要考虑：
为终端用户设计的去中心化存储服务：在客户端和存储提供方之间建立存储合约，客户端根据特定的存储时间间隔和SLA支付费用。
永久数据归档：协议保证没有数据永久存储，不会丢失。
在中心化存储中存在的挑战，在区块链存储中依然存在，这里主要是指非激励系统：
加密经济协议需要保证：持久性、可用性、开销、...
非激励系统的特定挑战：安全、扩展性、性能、用户体验、...
为简单起见，可以把加密经济协议称为区块链存储的协议部分，把非激励系统称为区块链存储部分。
持久性是指数据永久存在的概率。在存储提供方故障的情况下，数据也不能丢失。传统方法是采用复制方案和纠删码方案，是否有其他的方案来保持持久性吗？
可用性是系统被调用时，成功响应的概率。在存储提供方故障的情况下，数据也可以访问。这里有一些挑战：
在不检索数据的前提下，如何保证数据的可用性？
如何定义SLA？
数据检索的开销：检索之前支付费用和加密经济学的支付通道协议。
能够实现11个9的可用性吗？有这样的需求吗？
协议部分的一个挑战主要是针对持久性和可用性的攻击：
女巫攻击：存储提供方伪造多个存储身份，也就是说实际上只存储一份拷贝，却可以得到多份数据存储费用。
外包攻击：存储提供方声称自己存储了数据而实际上没有存储，只是在客户端请求数据时，临时从其他存储提供方快速检索数据。
生成攻击：存储提供方声称存储了大量数据而实际上没有存储，只是在客户端请求数据时，临时用程序快速生成数据。生成攻击对filecoin这样依赖大量数据存储的激励层攻击危险程度更高。
另外一个问题：如何保证一个数据副本是一个独立副本？
激励部分的一个挑战主要是：
如何可靠的检测恶意参与者？客户端请求数据，存储提供方提供数据，但客户声称它从来没有得到数据。
如何选择激励引擎？区块链或者其他引擎？这里需要在信任和性能之间权衡。
如何保证协议是正确工作的？博弈理论证明和基于激励的证据。
如何设计激励方案？
协议部分的另外一个挑战是开销。
中心化存储中免费的东西，在加密经济协议中产生额外的开销，比如区块链的交易费和协调开销
中心化存储的大型存储提供商很少，市场上是否有足够的竞争者？
利用已有的硬件：终端用户未使用的存储空间以及极低的编辑成本
如何与今天的存储价格竞争？
存储部分的一个挑战是安全。
大型存储提供商拥有很多安全专家。如何保护去中心化存储提供商？主要的风险有哪些？数据丢失？数据窃取？DDoS攻击？
密钥管理：服务端无需加密（在客户端加密），客户端如何管理密钥？密钥有丢失风险，是否需要密钥恢复过程？
加密是默认选项？存储提供方是不可信的，加密的数据又如何分享？
存储部分的一个挑战是扩展性。
中心化存储可以线性扩展。去中心化存储能否实现线性扩展？阻碍去中心化存储线性扩展的瓶颈在哪里？区块链？
中心化存储可以处理PB级数据。去中心化存储目前存了多少数据？理论限制是多少？随着数据量的增多，哪些存储属性会下降？比如延迟属性？
存储部分的一个挑战是性能。
延迟。中心化存储可以快速连接到互联网的骨干网，那么去中心化存储系统呢？我们能够控制数据存储的物理位置来满足延迟需求吗？云存储可以让数据靠近应用来降低延迟，在去中心化存储中可以应用同样的方案吗？
吞吐量。中心化存储提供商通常在服务交付之前重新绑定API背后的数据，去中心化存储系统中是否可以通过并行数据块检索和客户端重绑定来提高延迟吗？
存储部分的一个挑战是用户体验。中心化存储通常简化为API，那么对于去中心化存储来说：
在用户使用系统之前需要做哪些事情？同步区块链？申请一个tocken？安装一个钱包？
存储的文件如何嵌入的应用中？网站？DAPP？
其他一些问题：
区块链和存储系统在多大程度上紧密耦合在一起？比如filecoin中时空证明，以太坊中的swarm？
参与其中是否涉及到法律问题？存储提供方存储了客户上传的非法数据怎么办？如何合规？如何兼容DGPR?
数据如何更新？数据更新时，重新和所有数据副本协商？还是存储为一个新文件？存储为新文件是一个巨大的开销！
存储领域另外一个重大的挑战是数据库系统。
从去中心化存储到去中心化数据库系统，还有很长的路走。
结构化可更改数据：必须可以更新，接口更复杂，不仅仅是CRUD。
激励协议在保证处理的正确性，通过校验和来保证完整性是不够的。
查询支持：分布式join和schema的逆正则化。
对比于传统数据系统，系统设计受限于CAP理论。参考阅读《CAP理论与分布式系统设计》。
总之，2007年，P2P文件共享占用互联网50%的带宽，2018年，Bittorrent的下载流量占用了互联网的3%。去中心化是对所有终端用户有价值？还是去中心化解决方案在某些方面比中心化方案更好？比如更便宜或更安全？
以上，是Jacob Eberhardt分享的主要内容。上述很多问题直接作为当天各个panel的话题索引，各个项目的回答并没有给出完美的答案，相信这些问题仍然是未来几年各个项目的研究方向。
关联阅读：
《比特币的学术谱系》
区块链精灵
“
One cannot simply sprinkle Blockchain dust on any use case to make a delicious meal of it.
人们不能简单地在任何一个用例上撒上区块链佐料来制作美味的食物。
”