基于区块链的可公开验证分布式云存储系统

doi ：10.3969/j.issn.1671-1122.2019.03.007

基于区块链的可公开验证分布式云存储系统

-----------------------黑一鸣，刘建伟，张宗洋，喻辉------------------------(北京航空航天大学网络空间安全学院，北京100191)

摘要：大数据时代，用户将有价值的数据上传云端以实现资源共享，这对云存储服

务的安全性和可靠性提出了更高要求。目前云存储服务通过分布式存储来保证数据安全性，但云端数据仍集中于存储服务商，且完整性验证基于第三方。此外，传统云存储模式依赖 于服务商的设备，没有充分利用用户闲置存储。文章基于区块链共识机制及其去中心化等特 点提出一种分布式存储系统。该系统设置奖励机制促使全网节点参与数据存储服务，提高 全网存储空间利用率，并引入智能合约保证数据服务交易公平。相比于现有基于区块链的 分布式存储系统，文章系统的存储证明简洁高效，可实现链上链下相结合的数据查询和数 据完整性公开验证，并保证了链下微支付的公平性。安全性分析和合约测试实验表明，文 章系统能实现公平的数据存储、查询和完整性公开验证。

关键词：分布式云存储；区块链；智能合约；公平支付；公开验证

中图分类号：TP309文献标识码：A文章编号：1671-1122 (2019) 03-0052-09

中文引用格式：黑一鸣，刘建伟，张宗洋，等.基于区块链的可公开验证分布式云存储系统[J].信息网络安全，

2019, 19 (3) ： 52-60.

英文引用格式：HEI Yiming, LIU Jianwei, ZHANG Zangyang, et al. Blockchain-based Distributed Cloud Storage

System with Public Verification^. Netinfo Security, 2019,19(3): 52-60.

Blockchain-based Distributed Cloud Storage System with

Public Verification

HEI Yiming, LIU Jianwei, ZHANG Zongyang, YU Hui

(School of Cyber Science and Technology, Beihang University9 Beijing 100191, China)

Abstract: Valuable data are uploaded to the cloud for sharing by users in the age of

big data, which requires more secure and reliable cloud storage services. At present, cloud

storage service guarantees data security through distributed storage, but cloud data is still concentrated in storage service providers, and data integrity verification depends on third party. In addition, the traditional cloud storage mode relies on the equipments of service providers and does not make full use of the idle storage space of users. This paper proposes a distributed storage system based on blockchain consensus mechanism and its characteristic of decentralization. The system establishes incentive mechanism to encourage all network

收稿日期：2018-12-12

基金项目：国家重点研发计划[2017YFB1400702]; “十三五”国家密码发展基金[MMJJ20180215]作者简介：黑一鸣（1994一），男，山东，硕士研究生，主要研究方向为区块链应用；刘建伟（19—），男，山东，教授，博士，主要研究 方向为网络与信息安全、通信网络安全和密码学；张宗洋（1984—），男，山东，讲师，博士，主要研究方向为公钥密码学和区块链；喻辉 (1994一），男，北京，硕士研究生，主要研究方向为区块链和数字货币。通信作者：张宗洋 zongyangzhang @buaa.edu.cn

52

nodes to participate in data storage services, improves the utilization of network storage space, and introduces smart contracts to ensure fairness of data services. Comparing with other blockchain-based distributed storage systems, the storage proof of the proposed system is concise and efficient, which can realize the on-chain and off-chain data retrieval and public data integrity verification, and can ensure the fairness of off-chain micro-payment. The security analysis and contract test results show that the system can achieve fair data storage, retrieval and public integrity verification.

Key words: distributed cloud storage; blockchain; smart contract; feir payment; public verification

o引言

分布式云存储是云计算m的关键领域。近年来， 云存储服务暴露出很多问题。2015年9月，AWS云服 务宕机[2],造成大量网站瘫痪。2017年3月，AWS云存 储系统再次宕机[3],造成雅虎邮箱、YouTube等服务无 法访问。同样在2017年3月，微软云服务Azure出现 全球性故障'导致用户无法更新数据。用户亟需更 加安全可靠的分布式云存储系统。

传统分布式云存储系统的代表有GFS[5]和HDFS [6]0 它们是由少数大型存储服务商设计提供的，若存储服 务商是恶意的，则釣者利益会受损。现有数据完整性 雜旅包括釣者麵和第三方雜[7]〇为减轻数据 所有者负担，常采用第三方验证方式。2009年，WANG[8] 等人提出基于第三方的云存储可公开藤E方案;2011年，

方案，使用时空证明[_作为存储激励机制，采用zk-

SNARKs[21]技术保证数据完整性可公开验证，运算量 极大。以上方案都基于微支付通道进行交易，但没有 措施保证公平性。

本文借鉴当前基于区块链的分布式云存储系统设 计思想提出新的方案。本文方案将数据存储到节点本 地存储空间而非直接存储到区块；设置了基于智能合 约的奖惩措施，促使全网节点有动力、公平地参与数 据存储交易；利用微支付通道提高查询交易效率；使 用基于默克尔树1111的高效存储证明；支持链上链下结 合的数据查询。本文主要贡献为：

1)

利用智能合约保证微支付通道的完全公平，提

升系统判罚时效性。

2)

改变了现有相关系统中存储者按时提交存储

WANG[9]等人提出改进方案，可实现数据动态批量验证; 2013年,YANG和提出基于隐私保护的安全动态 验证协议。以上方案都存在数据验证中心化问题。

2008年，中本聪提出比特币网络I11]，用区块链技 术[12]解决了中心化问题。区块链技术也促进了去中心 化的分布式云存储系统的变革，智能合约[13]和微支付 通道間等区块链技术开始融入新型云存储系统中。智 能合约能保证数字化承诺公开执行，微支付通道可提 高交易效率。当前基于区块链的云存储项目有Storj[15]、

证明的方式，只有当用户在链上问询后才返回存储证 明，减少不必要的证明操作。

3)

基于以太坊平台设计并实现了存储和查询阶段

的智能合约，将存储押金和存储能力动态关联，保证 了存储者服务声明的可靠性。

4)

规定了智能合约生存期，给出合约销毁后的押

金公平分配方案，并根据合约测试结果提出数据分块 建议。

文章组织结构为：第1章给出文章符号和函数定 义，并介绍相关的区块链背景知识；第2章详述基于 区块链的可公开验证分布式云存储系统的结构和工作 流程；第3章给出方案的安全性分析；第4章展示方 案在以太坊测试链上的实验结果和与相关系统的性能 对比；第5章总结全文并提出下一步工作重点。

Sia[16i和FilecoW1' Stoij采用可检索证明机制保证数 据完整性和可用性，但该方案只由用户验证数据且无 内置智能合约。Sia使用M-of-N签名方案保证公平数 据服务，但需定时提交并保存存储证明，这使得链上 数据过多。此外，以上两种方案无服务押金概念，服 务者可任意声称服务能力。Filecoin是基于IPFS™的

53

2019年第3期、

1背景知识

1.1符号和函数定义

为阐述方便，规定方案参与者为用户(User-A)、 存储者(Server-B)和矿工。表1为符号定义。

表1符号定义

符号

含义

(Flag

pki,ski)合约类型标识/的公私钥对M

待存数据（常为密文）Rm

M的默克尔树根Ntobx.

数据分块最大索引

C-SER服务合约

C-STO

雜合约

A-DDserva-if

的服务合约账户地址ADDsiare存储合约账户地址2fauild合约创建时间Taene存储服务提供时长

JVserve

存储空间Price-unit存储市场单价Contact-i

的联系方式PGietvt

存储服务押金Troild

服务合约有效期

PGataie存储押金PGtotal存储合约余额^Gcheck用户查询押金RCataie

存储记录y单块数据查询费

?i

首次查询某块数据的查询费Ttrana存储合约押金转账时限2store数据存储时长

Tcet

存储证明返回时限

C

挑战值

Ccfstoie-c

c

对应的存储证明

本文方案使用了哈希函数和数字签 名方案设〃办}。其中，

成)<-^ygen(lA)，

(T—nSZg(滅，A〇，{的祀，为/從卜设，砂(<7,

1.2智能合约和以太坊

智能合约是区块链上的代码，能在满足触发条件 时自动执行。其部署后不能随意修改，使得数字化承 诺能按约执行間。

当前主流智能合约系统有以太坊t22]、codiuSP3]和

hyperiedger124]。其中，以太坊是最活跃的公有链项目，

它提供去中心化的虚拟机处理合约,是图灵完备的系统。

以太坊智能合约的运行原理如图1所示。首先， 以太坊客户端发送调用合约消息给以太坊节点；然后， 以太坊节点将消息输入本地以太坊虚拟机的合约中，按 合约规则执行消息得到结果；最后，以太坊节点互相

对比验证运算结果，达成共识后将结果记录至区块链。

图1以太坊智能合约运行原理

1.3微支付通道

微支付通道的思想是将大量微支付交易汇总为一笔 麟交易后再向链上提交[14]。利用微支付通道能有效降 低翅成本，提纖率。假设Alice是服务者，Bob是用 户，则常用微支付通道的工作流程为：

1) Bob创建锁定交易，将》份服务费转到某地址, 只有输入双方签名后才能解锁该费用。

2) Bob创建赎回交易让Alice签名，交易内容是 经过时间r后把《份费用退给Bob。Alice签名后,Bob 将两笔交易发到全网。

3) Alice开始提供服务，当工作报酬达到1份的费 用时,Bob创建并签名新的赎回交易给Alice,该交易 要求支付1份费用给Alice、/J-1份费用给Bob。Alice继 续工作,Bob^f应创藤的赎回交易来增加支付给Alice 的报酬，签名并錄给Alice〇

4)

在锁定时间r范围内,Alice将其认同的交易签

名发到全网。

5) 矿工验证包含双重签名的交易，若验证成功，使交易

在上述方案中，存在两个问题：1)该过程为先服 务后付费,Bob可在获得最后一次服务后拒绝付费；2) 若Bob缴纳押金后Alice不诚实提供服务，Bob要等

则

时间r后才能赎回押金，时效性较差。

2分布式云存储系统构造

本文方案的区块链结构类似于以太坊。本文方案 的服务费分为存储服务费和矿工服务费。存储服务费 分为存储费和查询费，这两笔费用视市场情况灵活定 价；矿工服务费为生成区块的奖励。

2.1合约构造

本文方案包含存储者(Server-B)用于声明其服务 能力（存储时间和空间）的服务合约和保证 数据交易公平的存储合约(C-_。

主要参数有合约类型标识(F細)、存储

服务押金O

U

、合约创建时间(TUi)、Server-B声

称的存储服务提供时长(r_)和Server-B的联系方 式(Conto^-5)。C-5E/?由Server-B生成并提交。考虑 到存储市场单价及Server-B可提供存储 空间(AU™)的波动性，同时为避免Server-B无条件 地伪造存储能力，本文方案规定Server-B要隐式声明 队™，即该值要通过凡en^PGWrv^T^rreXfWce-MWiO计 算获得。另外，为避免永久存在于区块链中， 本文方案要求统一 C-5EK的有效期(U

合约到期

后立即失效，剩余押金退还给C-哪的制定者。

C-5TO的构造参数有合约类型标识(脚)、存储押 金(PG^)、用户查询押金(PG^t)、合约创建时间(Kuiid)、 存储合约押金转账时限(D

、存储证明返回时限(rcer)、

待存数据(M)的默克尔树根(i?M)和数据分块最大索引 (AUO。C-5TO伪代码如下：

while(7Ws is vaild) //在押金转账允许时间内 if(PGtl)tai>=PG— //若押金符合约定 while(7k〇reisvaild) //在存储时间范围内

if(receiveAs^:Jh?/w_L^r*v4) //接收User-A的询问

MiCertijy_from_Server-B.time<=Tc^) //^User-A§

忍的证明时间内

true) //检验

存储证明有效性

then continue

else transfer PGstore to User-A else transfer PGstOTe to User-A if(receive

//接收双重签名交易

success) //判断签

名有效性

then validate the Ttrans

if (〖transfer PGstore to User-A) //存储行为诚实 then transfer PGstore and 7\\ to Server-B elsetransfer to User-A

else

refund尸Gt〇tai //合约无效并退款给参与者

2.2存储证明

存储证明是存储者向用户证明其所存数据完整性 的证据。本文方案的存储证明(CerstoreJ包括以挑战 值咖eN且WTSUx)作为索引的数据块M以及M到

的路径上的哈希值集合。以AUx等于8为例，对 该8个数据块进行默克尔树生成运算间，得到如图2 所示结构。在假定挑战值c为6的情况下，存储证明 就是图2中标灰色的数据集合〇

本文方案在存储合约中保存了全网矿工可 以在不存储M的情况下运行合约，验证

的

有

效性。对的验证分为3个方面:1)检验返回 证明是否超时。2)检测挑战值c X彼的索引是否合法。3)结合证明数据计算并判断结果是否等于例 如，基于上述挑战值c为6的假设，计算你辦/叫丨

ft，辱

6)丨阿，并判断结果与是否相等。

2.3方案流程

本文方案分为数据存储、数据查询和存储合约失 效3个执行阶段。

55

2019年第3期、

2.3.1数据存储

数据存储过程如图3所示，主要包括交易双方匹配 (步骤1)〜步骤3))和存储合约制定与发布（步骤4)〜 步骤7))。

图3数据存储过程

具体步骤如下：

1)

Server-B制定服务合约(C-5EK),并将其发至

全网节点。矿工打包并部署到链上。Server-B 将PGserve转人vlDAerve-B以隐式声明其可提供的AUve。

2) User-A在区块链上查询服务合约以获取所需的服务。

3)

假定User-A认为Server-B声明的存储时间及空 间#^期，则娜C-哪中声明的联系诚(。福-5) 在链下与Server-B建立连接。

4) User-A将M切分为A:个等大的数据块{M，

Mi, •••, Mk

}〇5) User-A把所有分块、分块索引发送给Server-B， 再给Server-B发送一个随机挑战值C〇

6) Server-B 相应返回 Cers ore-ct

〇

7) User-A验证Cer—并在验证通过后制定C-STO。

User-A 计算

将 C-57D 和

发送给Server-B。若Server-B同意该合约，计算

Ssix^SigHsksfiashiC-SrO%

将 a

SID

、Ssio-a 称 Ssio-b 发

布到网络。

c-sro发布完成后，就进人存储合约生效阶段。

合约生效需要两个步骤：

1)矿工验证合约。矿工计算

STO)» 和 妙(&^，7/〇认(0^7<9)» 志过， 矿工将该c-則部署到区块；否则，矿工丢弃该c-sra

56

2) User-A和Server-B向合约转账。在C-5TO部署

完成后，User-A和Server-B向^Dstore提交等额押金转 账。若在内押金成功转入，则C-S7D生效,User-A 将数据与存储者的对应关系记录到你_;否则，所有 押金退还,C-S7D无效。

2.3.2数据查询

数据查询采用链上链下相结合的方式，数据查询 过程如图4所示。

__________2)建立连接

User-A''^—^

假设User-A要查询Server-B存储的数据M，步 骤如下：

1)

User-A根据存储记录(Ttestore)获取Server-B的联系卞式(Contact-B、〇2) User-A与Server-B建立链下连接，链下数据传 输可細HTTP协议或IPFS协议。

3)

建立并使用链下微支付通道，微支付通道运

行流程如图5所示。

(2)锁定费用朽，发送待查数据分块索引

(3)索引对应的数据分块

User-A

(1)将況y作为

⑷用户对 “(f-l)y给Server-B，(AT-l-〇y给User-A”

PGcheck转账到

的交易签名和新的数据分块索引 （6)对最后一笔交易签名，

ADDstoTt

------------------------------------------►作为存储合约的输入

(5)索引对应的数据分块 提交到全网

图5链下微支付通道运行流程

⑴User-A将W作为尸G=heck转账到v4Z)At〇re。(2) User-A锁定价值为y的查询费（将该查询费记 为幻并发送待查的数据分块索引。K的锁定方式是：在

U

范围内，若Server-B诚实地提供了所有查询服务,

则Server-B获得该费用；否则，该费用退还给User-A0

(3) ^锁定后，Server-B返回索引对应的数据分块 给 User-A。

当有新的查询时,User-A要创建新的交易，交 3安全性分析

易的内容是累加查询费给Server-B,并将剩余的PGm

1) “双存”问题

给User-A ; User-A将新的交易发送至Server-B0例如，

存储者声称提供某存储，但却将该空间提供给多

第/次查询时,User-A对交易“(i-l)y给Server-B, (AT-1-吹

(4)

给User-A”签名后发送给Server-B0

(5) 收到签名交易后,Server-BX^J■应发送一份数

据分块给User-A。

(6) 在内，Server-B对其最终认可的一笔交

易（记为签名，将和双重签名发到全网

矿工调用合约，验证交易双方对Dea/的签名。若验

证通过，则生效，查询付费完成。

以上是本文方案利用链下微支付通道正常进行数

据查询的过程。但若User-A通过以上方式查询合法索

引W对应的M/,而Server-B没有返回相应数据，则

User-A可向对应C-5TO提交挑战值要求Server-B

给出存储证明。若Server-B在L内向C-OTO提交了

正确的存储证明，则保持有效状态；否则，合

约失效，Server-B将八转给User-A〇若Server-B能诚

实响应所有查询请求（包括User-A只存储数据但不向

Server-B查询数据的情况)，则待达到后,C-S710

自动将7i转给Server-B。

2.3.3存储合约失效

存储合约(C-S7D)失效分为两种情况：过期失 效和期间失效。过期失效是指达到I

后,User-A或

Server-B都可以调用合约的销毁函数销毁合约。期间

失效是指存储者的恶意行为导致合约在rstore内失效。

dO

失齡涉及的余额分配方案如下：

1) 针对合约过期失效倩况，说明在Sore内Server-B

的所有服务行为都诚实。这时将八和^仏^ 转给Server-B,然后自动销毁。

2)

针对合约期间失效情况，说明交易过程有恶意

行为。这时C-S7D将'和/^^转给User-A。为保 证恶意行为之前的查询费用生效,C-S7D仍接收并验 证Server-B提交的£>ea/和其对应的双重签名，待达到 7；咖后，

自动销毁。

人，以赚得更多存储服务费。本文方案中，存储者的

存储能力和其在服务合约中的押金是通过

智能合约的代码关联的，智能合约的执行采用分布式

一致算法，保证了存储者的存储能力是基于共识、公

开可见的，用户不会与存储能力不足的存储者建立存

储合约(C-测。

2) 微支付不公平问题

在传统微支付方案中，要求先服务再付费，这样

恶意用户可在查询到最后一块数据后拒绝付费给存储

者。本文方案中，预先锁定了第一笔查询费，只有

在存储者诚实地完成服务期内的所有工作（存储和查

询）后，这笔查询费才会转给存储者；否则，超时后

这笔查询费会返还给用户。

3) 伪造存储空间问题

存储者意图通过声称超过其实际的存储能力的

行为而获利，他向C-SE/?转人其声称的存储能力对应

的押金（存储能力根据押金隐式声称)，通过这种方

式保证其有足够的钱来支付c-sro的押金。但是，即

使存储者能向c-sm转人足够押金，对于其假冒的 存储交易仍不能给出有效的存储证明，这样他会损失

中的押金。4) 拒绝服务问题

用户和存储者达成c-sro,但用户请求查询后 存储者拒绝返回数据，这分为两种情况：一种是达成

CJ7D后，存储者就将用户存储的数据扔掉；另一种

是存储者存了数据但故意拒绝服务。对于第一种情况,

存储者会因无法给出存储证明而损失押金。第二种情 况又分为两种子情况：一种是存储者任何时候都不给 出数据，这样存储者会直接损失押金而无收益；另一 种是直到用户在链上广播查询时存储者才给出存储证 明，这会导致存储者额外缴纳矿工服务费。

57

jN©TINFO SECURITY

技术研究

2019年第3期

5) 链上查询问题

恶意用户不使用链下微支付通道，通过只提交存 储挑战的方式获得想要的数据，以增加链上的数据量。 本文方案要求用户和存储者向链上提交挑战和存储证 明时，都需要向矿工缴纳服务费。如果采用链上查询 手段，相比于使用链下微支付通道，双方都需要花费

额外的矿工服务费。此外，本文方案中，每次收到存 储证明后，合约中保存的数据块不是累积存储的，这 样合约也不会因为链上查询次数过多而膨胀。

6) 非法挑战值问题

恶意用户向c-sro传入超过分块索引值范围的 挑战值C，使得存储者不能给出相应存储证明，从而 获得押金。本文方案中记录了数据块索引最 大值TSUx。矿工运行合约时，合约程序可以检测挑战 值的有效性，从而拒绝非法挑战值。

4实验分析 4.1性能测试

本节对合约进行性能测试。硬件环境为Intel(R)

Core(TM) i5-4200 CPU(2.3GHz), RAM 为 8GB。软件

环境为 geth-windows-amd-1.8.7 和 Ethereum-Wallet-

win-0-10-0,基于以太坊官方测试网络Rinkeby。网

络环境为实时，网速约11 Mbps。

合约使用Solidity语言编写。测试参数如表2所示。为测试需要，将

和L预设为500 s。

表2测试参数

C参数

取值单位

1.09KBC--SESTOR大大小小6.67KB

TtODt

500s

500PGJeer

ttore

s

0.5

ETH

1)合约部署时间

图6是对C-5E/?和c-sro两种合约部署时间的 5次测试结果，部署时间是指合约被打包进区块的用 时。表3为两种合约部署时间的均值及方差。由图6

可见，两种合约的部署时间都在30s以内且相差不大。 由表3可见，

的平均部署时长稍大于

58

这是由合约大小的差异导致的。的平均部署时

长虽然只有24s，但其方差较大。因此，用户和存储 者应给合约部署预留足够的时间。

CJER部署

■ C-STO部署

S/fe半輞垢

3

测试次数/次

图6合约部署时间测试结果 表3合约部署时间的均值和方差

参数

平均值

/S

方差

/s2

d

及部署时长2411.44C-5TO部署时长

27.5

1.96

2)合约调用时间

图7为存储调用合约核心函数所花时间的6次测 试结果。合约核心函数功能包括用户请求证明、向合 约转账、验证双重签名和更新默克尔树根。表4是图7 中对应测试结果的均值和方差。由图7可见，所有合约 核心函数调用时间都在45s以内。由表4可见，合约核 心函数调用时间的平均值在28s至35s之间。实验测试 过程中，调用合约核心函数用时最大值为42s。因此建 议交易双方以45s作为单次合约核心函数调用时长来协 商其他参数。

□用户请求证明

■向合约转账

□验证双重签名

niKff馱克尔树根

测试次数/次

图7合约调用时间测试结果

表4合约调用时间的均值和方差

参数

平均值/S方差/s2用户请求证明时长30.534.6向合约转账时长28.829.5验证双重签名时长34.525更新默克尔树根时长

31

11.9

3)存储证明验证时间

图8为测试数据块分别为1KB、2KB、4KB、6KB、 8KB、10KB时，验证存储证明所花时间的折线图，共 展示了4次实验结果。由图8可见，数据块大小在6KB 以下时，存储证明验证时长鉢稳定在50s以下；当数 据块大小超过8KB时，存储证明■时长呈指数增长； 当数据块达到10KB时，验证用时在260s至300s之间。 所以可认为数据块大小会影响存贩明的雜时间〇

a)第1次测试

b)第2次测试

c)第3次测试

N©TINFO SECURITY ：

4〇19年第3期

技术研究

—测试数据

UOMO,0*

2c

2s0Il,50<

单个数据块大小/KB

d)第4次测试

图8不同数据块大小对应的存储证明验证时间

下面给出数据分块方式的优化建议。设待存数据 为Z字节，将该数据分为)t块，每块数据的哈希值为 32字节。则本文方案存储证明的字节数为/(X,A)=X/A:+

log#x32)〇可求得，当*=X(ln2)/32时，存储证明数据

量最小，为32/ln2+321og2^ln2-160字节。通过上述方 法选择值可减少网络上的数据量。

由表4可知，向合约转账时长的平均值在30s以内。 由图8可知，存储证明的最长验证时间不超过300s。因 此細试开始，将U

L预设为500 s是合理的。

4.2性能对比

目前基于区块链的分布式存储方案有Filecoin、Sia 和Storj等。这3种方案都需要存储者定期向全网提 交存储证明，这会导致网络上的存储证明数据量巨大, 且对存储者的运算能力有一定要求。另外，这些方案 不具有公平的链下微支付通道。其中，Sia方案重点涉 及数据存储阶段，如果存储证明失效，其押金只会被 锁定，这种惩罚方式并没有给丢失文件的用户以合理

补偿。

本文方案相较上述方案有所改进，与上述方案的 性能对比见表5。本文方案涉及存储和查询两个阶段， 具有链下微支付公平、存储证明易于生成且数据量较 小等优点；本文方案合约框架固定、合约参数由存储 者和用户链下协商确定、参数设置的灵活性高且不会 给链上带来数据负担。此外，本文方案还支持合约的

合法修改和销毁。

59

nCtinfo security

技术研究

2019年第3期

表5基于区块链的分布式云存储方案性能对比

系统涉及碰合存储证明 数据合约存储时间 链下名称

阶段

约达成方式提交频率传输挖矿方式

机制可改性空间

公平

存储可定制性微支付Storj链下定期工作量查询HTTP证明

不明

不可定制无Sia存储链上定期IPFS工作量

证明可修改

不明无Filecoin

存储

査询链上定期IPFS

存储证明

不明

可定制无本文存储链下

不定期

IPFS 或 工作量

方案

査询

HTTP证明

可修改

可定制

有

5结束语

本文基于智能合约和微支付通道等区块链技术， 提出一种公平且可公开验证的分布式云存储系统方案。 本文方案设置了针对数据存储的奖惩措施，保证了存 储交易公平性。本文方案采用基于全网共识的数据完 整性验证机制，保证了存储交易可公开验证。另外，本 文方案还保证了链下微支付通道的公平性。但是本文 方案的工作效率受到以太坊平台的，且没有注重保 护用户数据的隐私性。因此，下一步将在本文方案的基 础上研究扩容技术和隐私保护方案。

（责编马珂）

参考文献：

[1] FAN Yundong, WU Xiaoping, SHI Xiong. Research on Access Control Model Based on the Trust Value Assessment of Cloud Computing[J]. Netinfo Security, 2016, 16 ( 7) ： 71—77.

范运东，吴晓平，石雄.基于信任值评估的云计算访问控制模型研 究[J]•信息网络安全，2016,16 ( 7) : 71-77.

[2] FIVEASH K. AWS outage knocks Amazon, Netflix,Tinder and IMDb in MEGA data collapse[EB/OL]. https://www.theregister. co.uk/2015/09/20/aws_database_outage/,2015—9—20.

[3] ZHANG Jinliang. Microsoft Azure Has Suffered a Massive Failure: It Has Now Been Restored[EB/OL].http://news.zol.com. cn/631/6315121. html, 2018-3-16.

张金梁.微软Azure遭遇大面积故障：目前已恢复[EB/OL].http://

news.zol.c— om.cn/631/6315121. html, 2018—3—16.

[4] SOHU. AWS S3 Cloud Services Disappear Inexplicably: Major Websites and Docker Have Been Tricked [EB/OL]. http://www. sohu.eom/a/1275265_465914, 2017-3-1.

搜狐.AWS S3云服务莫名消失：各大网站和Docker纷纷中招[EB/OL].

http://www.sohu.eom/a/1275265_465914,2017—3—1.

[5] GHEMAWAT S, GOBIOFF H, LEUNG S T. The Google File System[]]. Acm S^ops Operating Systems Review, 2003,37(5): 29—43.[6] SHVACHKO K, KUANG H, RADIA S, et al. The Hadoop Distributed File System[C]//IEEE. 2010 IEEE 26th Symposium on Mass Storage Systems and Technologies (MSST), May 3—7,2010,

60

Incline Village, NV, USA. NJ: IEEE, 2010: 1-10.

[7] WANG Yujue, WU Qianhong. A Survey on Cryptographic Technologies for Data Integrity Checking in Clouds [J]. Cyber Security, 2017, 2(3): 23-35.

王玉珏，伍前红.云存储完整性验证密码学技术研究进展〇].信息 安全学报，2017, 2(3): 23—35.

[8] WANG Qian, WANG Cong, LI Jin, et al. Enabling Public Verifiability and Data Dynamics for Storage Security in Cloud Computing[C]//ESORICS. The 14th European Conference on Research in Computer Security, September 21 — 23, 2009, Saint— Malo, France. Heidelberg: Springer—Verlag Berlin, 2009:355—370.[9] WANG Qian, WANG Cong, REN Kui, et al. Enabling Public Auditability and Data Dynamics for Storage Security in Cloud ComputmgQ]. IEEE Transactions on Parallel & Distributed Systems, 2011,22(5):847—859.[10] YANG Kan, JIA Xiaohua. An Efficient and Secure Dynamic Auditing Protocol for Data Storage in Cloud Computing[J]. IEEE Transactions on Parallel & Distributed Systems, 2013, 24(9):1717—1726.[11] NAKAMOTO S. Bitcoin: A Peer—to—Peer Electronic Cash System [EB/OL]. https://bitcoin.org/bitcoin.pdf, 2008—10—12.[12] XIE Hui, WANG Jian. Study on Block Chain Technology and Its ApplicationsjJ]. Netinfo Security, 2016,16 ( 9) ： 192—195.

谢辉，王健.区块链技术及其应用研究〇].信息网络安全,2016，16( 9):

192-195.

[13] SZABO N. Formalizing and Securing Relationships on Public Networks [EB/OL]. http://ojphi.org/ojs/index.php/fm/article/ view/8/469,2017-10-5.

[14] JOSEPH P, THADDEUS D. The Bitcoin Lightning Network: Scalable Off—chain Instant Payments [EB/OL].https://lightning, network/ligh—tning—network—paper.pdf,2015—9—15.

[15] WILKINSON S, BOSHEVSKI T. BRANDOF J, et al. Storj: A Peer—to—Peer Cloud Storage Network[EB/OL].https://s— torj.io/ storj.pdf,2017-11-12.

[16] VORICK D, CHAMPINE L. Sia: Simple Decentralized Storage [EB/OL]. https://sia.Tech/ sia.pdf,2018—1—13.

[17] Protocol Labs. Technical Report: Filecoin: A Decentralized Storage Network [EB/OL]. https://filecoin.io/,2018—2—20.

[18] BENET J. IPFS — Content Addressed, Versioned, P2P File System [EB/OL]. https://ipfs.io/,2017—

8—29.[19] ZHU Yan, WANG Huaixi, HU Zexing, et al. Zero—knowledge Proofs of R.etrievability[J]. Science China(Information Sciences), 2011, (8):1608-1617.

[20] Protocol Labs. Technical Report: Proof— of—Replication[EB/OL]. https://filecoin.io/,2018—3—10.

[21] BEN-SASSON E , CHIESA A , GENKIN D , et al. Snarks for C: Verifying Program Executions Succinctly and in Zero Knowledge[M]//Springer. Advances in Cryptology—CRYPTO 2013.Heidelberg rSpringer Berlin Heidelberg,2013:90—108.

[22] BUTERIN V. Ethereum[EB/OL]. https:// www.ethereum.org/, 2017-9-5.

[23] Codius .Codius[EB/OL]. https://cdius.org/,2018—4—6.

[24] Hyperledger.Hyperledger[EB/OL]. https://hyperledger—fabric. readthedocs.io/en/latest/,2018—4—6.