这次白皮书一共有90页,看完还真要费不少时间。如果你没有时间看,可以看一下我这篇快速技术解读。
上次Storj发布白皮书v2的时候,是 2016年12月15日;这次v3版白皮书的发布时间,是2018年11月,距离上次发布白皮书时隔2年时间。
这次白皮书V3相对于白皮书v2来说,务实了很多,给我的整体感觉是:解密了不少实现的细节。全篇白皮书在说Storj去中心化存储的架构细节,区块链部分依然提到的很少。
看了Storj的白皮书之后,大致可以明确几点:
下面我完整地解读一下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 兼;耐用率, 硬件故障, 和 流失;延迟;带宽;对象大小;拜占庭容错;局部协作。
解读出以下几点重要信息:
可以看出“安全和隐私”是Storj设计的第一原则。其他原则如果与这个原则冲突,都按照这条原则来执行。
基于这个第一原则,数据必须在进入Storj网络之前完成加密,而且加密算法是可插拔的,也就是可以使用不同加密算法加密。
要想办法降低维护成本和带宽消耗。
Storj白皮书V3首次提出了 AWS S3的兼容。这样开发者就能快速将之前基于ASW S3编写的程序移植到Storj上。对中国开发者来说,兼容了AWS S3,就兼容了阿里云OSS。
这次Storj支持了AWS S3的7个最核心的API。Bucket(Create, Delete, List), Object(Get, Put, Delete, List)。
Storj定义了一系列的Qos,特别关注了延迟。之前在Storj社区有人反馈:把数据存入Storj网络有时需要几个小时。现在看起来,Storj很关注这些反馈意见了。当然,除了延迟外,还定义了一个非常重要的参数:耐用性。耐用性是保证数据不丢失的概率,即使在大量硬件故障或者大量存储节点离线后,数据不丢失的概率。耐用性,一般是用9的数量来衡量的。如99.99%, 就是4个9的耐用性,表示有万分之一的数据可能会丢失。
Storj白皮书v3完整讲述了Storj的经济体系。一共设计了4个角色: 终端用户, 存储节点运营商, 需求供应商, 网络运营商(现在是Storj Labs)。
定义了Object的大小,最小为4M。如果大小不到4M,会按照4M收费,这样鼓励存入大点的文件。
存储节点一般归为3类:
为了达到整体的规模最大,局部协议的最小化协调是Storj非常提倡的。
角色
Storj的系统中有以下这些角色:
用户拥有帐户并信任特定的卫星节点。任何用户都可以运行他们自己的卫星节点,Storj希望许多用户选择使用其他卫星节点,避免操作复杂。有了卫星节点,Storj整体架构就非常灵活。
注意:中国不少自媒体,我就不点名,宣称Storj采用了天上的卫星传输技术,因为白皮书里面写了Satellite。其实卫星节点根本就不是天上的卫星,而是分布式系统中一个角色。
框架
Storj的设计,框架内的都将执行以下操作:存储数据; 检索数据; 维护数据; 支付费用。
独立的模块有:存储节点;P2P的通讯和发现;冗余;元数据;加密;审计和信誉;数据修复;支付。
存储节点
存储节点的作用是存储和返回数据。选择存储节点以基于各种标中和评估:ping时间,延迟,吞吐量,带宽上限,足够的磁盘空间,地理位置,正常运行时间,准确响应审计的历史记录等等。这点和传统P2P项目选择节点的方式非常接近。
P2P的通讯和发现
网络上的所有节点都通过一个标准儿协议通信。这个协议支持以下几点:
冗余
Storj白皮书v2中就提到了冗余,但那时采用的是简单冗余。Storj白皮书v3说明了简单冗余的缺陷,改用了纠删冗余。下面我想说下简单冗余和纠删冗余的优缺点。
简单冗余
在存储系统的不同位置创建数据副本,这个副本和之前数据一模一样。
纠删编码
基于奇偶校验的保护技术
里德-所罗门 纠删码
Storj使用的就是里德-所罗门 纠删编码
上传和下载
Storj并不是只要发现冗余少了,马上就增加冗余,而是分了情况以确定是否增加冗余。
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公式如下:
Storj做了如下假设:
p是纠删副本的每月丢失率, Storj假设它是10%
n和k分别是纠删算法参数
lamda就是泊松分布的平均数,是p*n
Exp.factor就是冗余的倍数
可以看到,Storj是能够做到很好的月耐用性的。
但是,这个测算过程是有些问题的。
数据
这里定义了Storj的每个数据单位:
这就是Storj中的数据单元的示意图:
元数据
之前,Storj 白皮书V2中就简单提到了元数据,白皮书v3说明了元数据的细节。
加密
所有数据或元数据都将被加密。在数据离开源计算机之前,必须对数据进行加密。与AWS S3接口兼容的客户端库应该和 用户的应用程序在同一台计算机上运行。我们的加密选择是经过验证的加密。这是为了便于用户知道是否有数据被篡改。加密应使用可插拔机制,可以选择不同的加密算法。Storj采用BIP32的分层加密技术,这技术允许共享子树而不共享其父级,也就是允许共享某些文件而不共享其他文件。
应对每个文件使用不同的加密密钥,因为访问一个文件将导致访问所有文件的解密密钥。因此,Storj每个文件采用不同的密钥加密。数据以小批量条带为单位来加密,建议为4KB或更少。路径也是加密的。与BIP32一样,加密是分层的和确定的,并且每个路径组件都是单独加密的。
审计
审计只是用于确定节点稳定程度的机制。
存储节点信誉
要确定哪些文件需要修复,存储节点运行时间和总体健康状况是主要指标。根据每个节点的审计历史,建立一个信誉系统给定节点确定身份。存储节点信誉可以分为四个子系统。
数据修复
为了修复数据,Storj将通过从剩余部分的纠删码来恢复原始数据,然后重新生成丢失的部分,并将它们存储在新存储节点上。
支付
卫星节点
卫星节点:保存元数据的服务集合。网络用户将拥有特定卫星节点上的帐户,该实例将存储文件元数据,管理数据授权,跟踪存储节点的可靠性,在减少冗余时修复和维护数据,代表用户向存储节点付款。
注意,Storj中, 用户不是直接向存储节点付款的,而是用户先付款给卫星节点,然后卫星节点再付款给存储节点的。
这是put操作的图:
这是get操作的图:
授权
宽带分配
垃圾回收
Uplink
Uplink 就是Storj的软件中间层。
未来工作
Storj的白皮书V3中提到了他们未来要做什么事情。
总结
优点
缺点
我为什么写这篇文章
我的其他文章提到过,我设计和发起了PPIO存储公链项目,旨在给开发者提供去中心化的存储和分发网络,使得更便宜,更快,更隐私。虽然我设计的PPIO项目和Storj有些相似,但我写这篇文章是完全站在中立的角度写得。我认为去中心化存储相对于中心化存储(如AWS S3,GoogleCloud,Microsoft Axure)来说是个全新的赛道。而这个新赛道的发展,以及最终产生价值,都是需要大家共同探索的。我希望能够共同进步。
我在设计PP.IO的时候,我之前设计的很多想法和Storj刚发布的白皮书V3中提到的非常类似,包括兼容AWS S3,重视Qos,将去中心化存储和区块链系统视为2个独立的子模块,使用纠删副本,测算耐用率,设计了监督节点(类似Storj卫星节点的审计)。当然,PP.IO也有很多和Storj不一样地方,PP.IO有很多地方的设计比Storj要优秀得多,我后面会写文章来逐步说明。
PPIO的官网已经上线