写作背景
本人即将开始三年的计算机硕士学涯，目前研究方向是区块链与云存储的结合。在学习中了解到Storj Labs这家公司已经推出了比较完整的、以区块链为核心技术的分布式云存储服务：Storj。在对其进行一番研究之后，现将学习成果进行输出，一是为了巩固所学，二是为了交流和共享。欢迎一切批评指正～
-------------------------------------------------------------------------------------------
在了解细节之前我们先来看看：Storj到底是什么？
Storj协议创造了一个用于建立和执行点对点的存储合约的分布式网络。允许网络中的节点进行合约协商，数据传输，完整性及可用性验证，数据检索，支付。
Storj是一个私有云提供商。但与我们所熟知的云服务不同的是，Storj实现了完全的去中心化——它基于点对点协议；同时，Storj利用时下热门的区块链技术来保障数据的完整性和保密性。总而言之，Storj是基于区块链技术和点对点协议的安全的私有云服务。
引用Storj Labs 公司联合创始人兼首席执行官/首席技术官 ShawnWilkinson 的话：
Storj 的核心目标，就是要改善传统的云存储服务，让用户重新掌握设备和数据的“控制权”。去中心化，意味着 Storj 没有中央服务器，此外由于采用了客户端加密技术，只有终端用户可以访问解密文件和密钥，极大地提升了文件安全性。
本文主要理论来源是Storj自家的白皮书。由于Storj本身体系架构十分复杂，本文仅着眼于其中区块链与云存储结合的部分。下面我们开始“剥洋葱”。
我们知道，使用区块链的一个大前提是基于去中心化的p2p网络，Storj就是这样一种网络。在这个网络中有两类节点，clients和farmers，前者存放文件到“云”，后者出租自己闲置的磁盘空间，成为“云”的一部分。p2p的网络有两个核心问题：云存储上数据的安全性，以及p2p网络如何实现共识。Storj借助区块链技术来满足这两点需求。
1. Proofs of retrievability机制
这个机制旨在验证数据在远端的完整性和可用性。由文件所有者发起的每一次验证称为“audit”，或称“heartbeat”。验证过程利用到了merkletree以及merkle proofs。
Step1 构建Merkle tree
先来了解文中定义的两个概念，Shards和Salts。
Shards
待存储的文件内容我们称为明文，对明文进行AES256-CTR加密得到密文，加密密钥只有文件所有者知道，实现了所有者对文件内容的完全控制。再将密文切割成等长的块，每一个块我们称为一个“shard ”。块的大小建议为8的倍数，如8MB，32MB。
Salts
为了能够证明数据块在远端的存在性和数据完整性，数据所有者会生成一串随机数，随机数个数与shard个数相等，称为“salts”，用s表示，s(s0, s1, …… sn-1)。
构建merkle tree的过程如下：
第一步，即图中最后一行，我们将随机生成的salt和sharding过程得到的shard一一拼接。
第二步，即图中倒数第二行，我们将“SALT+DATA”进行哈希，得到merkle tree的准叶子结点"PRE_LEAVES"。
第三步，pre-leaves再进行一次哈希得到merkle tree的叶子结点“LEAVES”。
构建出的merkle tree的树根会作为metadata存储在transaction中，transaction存储在区块链中，因此merkle root是公开且不可篡改的，这在验证过程中会有重要作用。
Step2 上传
client不仅要把加密的文件块shards发送给farmers储存，同时还要将merkle leaves一并发送；同时，clients会存储随机数列salts，merkle root和树高。
Step3 验证
第一步，client将file_hash及某一个salt值发送给farmer来证明自己对文件的持有权：farmer根据file_hash定位到文件，用收到的salt值与所存的每一个shard拼接并计算，若计算结果能够与所存的某个leave值对应上，即能证明对方的确持有该文件块。
第二步，farmer将merkle proof发送给client证明文件保存完好；
第三步，client用收到的merkle proof计算出merkle root，若计算结果与区块链中所存merkle root值一致，即验证成功。
2. 共识机制
对于第二个需求，即p2p网络中的共识机制，又是如何实现的呢？
区块链结构
由于比特币区块链对transaction中所存metadata的格式要求较为严格，Storj并没有使用比特币区块链，而是使用了Florincoin区块链。其transaction中的metadata如下：
file_hash即由SHA-256得到的一串256位的文件哈希，用于文件的存在性证明（proof-of-existence）；data location即文件块在远端存放的位置；merkle root刚刚已经讲到。
实现共识
==未完待续==