正文

技术向 | 香港大学论文：一种针对去中心化存储隐私保证的轻量级链上审计

币友_Anthony2020-05-19 14:09:32

新冠疫情加快了我们的数字化进程，我们无法再像以前那样通过面对面频繁往来来加强信任，取而代之的是越来越多的利用密码学中Merkle树和零知识证明验证Verify来“信任”你与之交互的人或物。利用密码技术，我们用户可以验证我们存放数字资产的交易所的偿付能力，验证我们外包存储的数据安全和隐私，而不需要第三方审计意见。

显然，我们不太适应，但这就是数字化社会的一种转变，从Trust 到 Verify 的转变。

以下分享一章关于分布式存储系统的隐私安全审计协议。

Towards Privacy-assured and Lightweight On-chain Auditing of Decentralized Storage

针对去中心化存储隐私保证的轻量级链上审计

https://arxiv.org/pdf/2005.05531.pdf

Yuefeng Du∗‡, Huayi Duan∗‡, Anxin Zhou∗‡, Cong Wang∗‡, Man Ho Au†, and Qian Wang§ ∗City University of Hong Kong, Hong Kong; †The University of Hong Kong, Hong Kong ‡CityU University of Hong Kong Shenzhen Research Institute, China; §Wuhan University, China

摘要

针对云上的数据存储进行安全和隐私审计是一个很好的研究课题，但对于正在崛起的去中心化存储网络(Decentralized Storage Network, DSN)，一个十亿美元的市场，这是一个未知领域。将数据存储业务以完全去中心化的方式实现可用，区块链是个非常方便技术——以存储证明的形式记录和验证审计跟踪，并以此为基础，通过必要的争议解决来实施公平支付。

区块链上留有可审计的线索，提供了透明和公平的同时，但它也 1）牺牲了用户隐私，因为它们可能泄露有关被审计数据的信息；2）成本过高，消耗链上资源，验证成本很高。少数针对DSN的隐私审计提案并不能完全解决这些问题。

我们提出了一个DSN隐私审计解决方案，解决了链上隐私审计并保证了效率和成本，提案结合了同态线性认证与多项式承诺简洁证明，和sigma协议可证明隐私。该解决方案每次审核可向区块链写入288字节的验证，并产生恒定的验证成本。它可以维持长期运行，并轻松扩展到大量的以太坊用户。

一、导言

在过去的几十年里，云数据存储重塑了数据存储方式。虽然中心化集中式数据存储在蓬勃发展，但缺点是，这种模式对用户数据造成了新的安全和隐私威胁。中心云存储提供商可能会偷看甚至滥用用户数据，因为用户将自已的数据外包到中心实体公司存储时，就基本上会失去数据控制权。而且，在云时代，数据存储市场集中在少数几个供商手上，导致了市场垄断的现象严重。

但基于P2P的数据存储系统，如Bittorrent[1]和IPFS[2]，从21世纪初就为数据存储指明了另一个新的方向。虽然，P2P存储系统的鲁棒性和可靠性还可能是一个问题，它们也经常被滥用来进行盗版和非法内容的共享，原因在于，这个是无需许可，人人可参与的一个系统，对等节点可以自由地加入和离开，而不必担心对系统的的影响。

幸运的是，区块链技术[3]、[4]的腾飞已成定局，并在快速发展，使这样一个用激励驱动的去中心化云存储系统上存储个人数据成为可能。DSN存储提供商无法查看在用户端加密的数据内容, 因此用户将获得更强的安全保障。此外，该系统自然也提供了一个机会，可利用大量未被充分利用的存储空间，进一步造福于广大公众，而不仅仅局限于少数的中心云存储公司。

值得一提的是，这样一个区块链支持的分布式数据存储系统DSN不应被现有中心云存储的替代品，而应被视为对当前云存储服务的补充。我们甚至可以利用现有的中心云存储CDN基础设施，例如存放到中心云上（只要数据加密），以提供高质量的存储和数据检索服务。在这种以区块链为骨干激励系统的分布式存储系统下，我们设想提供一种有利于所有参与者的数据存储方案，特别是对于那些需要更强大安全保障的敏感数据用户和需要出租未被充分使用存储空间的存储提供商。

A、目标问题

我们来考虑这样一个场景：用户打算把他或她的照片集存储到云端。尽管用户并不完全信任像AWS这样的中心云存储服务提供商，但对于分布式去中心化的数据存储服务提供商，似乎更加不可靠。即使有一个强大的激励系统，可以惩罚不法分子，但用户可能永远不会发现数据是丢失或被非法利用，直到数据检索是才发现。另一方面，即使我们假设用户成功抓到了不法分子，区块链又如何协助解决这一纠纷，又有什么证据可以作为唯一和最终的判断标准？

总结核心问题，我们缺乏一个有效且低成本的数据存储审计系统，也缺乏一个公平的争议解决机制，以支持区块链的分布式去中心化存储。当然我们可以依赖于链外审计，但它引入了额外的信任假设，并最终要求区块链解决争议。因此，工作开始，假设所有审计工作都是使用链上功能进行的。

挑战。 设计和部署一个可行的原型具有以下挑战性。首先，我们必须处理隐私问题和区块链透明度之间的关系。根据GDPR[5]，[6]的最新解释，建议在区块链上限制个人数据（甚至加密）的数量，以防将来发生泄露。在使用区块链的审核情况下，向区块链提供不安全的证据可能会使对手有机会以野蛮的方式离线恢复原始数据内容。其次，除了隐私问题，另一个挑战是如何设计出证明简洁、验证快速的审计协议。考虑到区块链上的成本，这对系统的成本效益和扩展性都非常重要。

评论。 作为一个开始，我们关注个人和企业数据存档存储的具体应用。一旦数据被分发和存档，就不会有更多的数据更新。单是归档存储市场就有巨大的潜力，包括如文件收集归档和图像备份等使用场景。从另一个角度来看，大多数区块链支持的去中心化数据存储系统，如Storj[7]、Siacoin[8]、Filecoin[9]，都不支持动态数据更新。所以我们所建议的设计无疑具有可比性。

B、我们的贡献

我们是第一个针对去中心化数据存储DSN的链上隐私问题和链上效率问题的审计框架。具体来说，我们做出了以下贡献。

我们分析了分布式去中心化归档存储系统的当前做法，并确定了阻碍其进一步发展的关键问题。
我们为分布式去中心化存储系统提出了第一个具有链上隐私和效率的数据审计协议。在实现链上隐私的同时，我们将链上数据安全及隐私审计成本降低到$0.1每次审核。
我们进行全面的性能评估，以显示我们的设计实现了效率，并将能可靠和稳健地扩大到数千以太用户。

总而言之，我们的设计使去中心化归档存储审计在成本和效率方面与中心云存储解决方案相当。

二、背景

在本节中，我们将对现有的去中心化存储系统DSN设计进行深入分析。

表一：支持去中心化存储审计框架的相关特性的比较。

a 0设计未考虑该功能；O黑表示设计完全支持该功能；N/A表示不适用的功能；N/P表示可以支持但未指定该功能。

b类：按不同类别分类，P2P或以太坊兼容（EC）或比特币兼容（BC）或Altercoin（ALT）。我们认为基于以太坊的审计解决方案由于其通用智能合约的概念而更具普遍性；基于比特币的审计解决方案与以太坊平台兼容，但在区块链上可以完成的计算量非常有限；而Altercoin设计不能用于其他情况。

c审计模式：TTP代表可信第三方审计；BC代表区块链链上审计；PA代表私有链下审计；Filecoin声称数据所有者可以充当审计师[9]。

d存储保证：基于Merkle树的审计只能提供有限的存储保证，因为质询随机性最终会耗尽，证明者可能会重用质询块；利用递归复合SNARK[9]，Filecoin规避了上述问题；应用同态身份验证器的ZKCSP可以提供高质量的存储保证。

基于区块链技术的加密货币如比特币[3]和以太坊[4]能够以去中心化的方式支持存储审计。特别是，以太坊非常有用，因为它能够执行准图灵完整性的智能合约，但受限于Gas成本。更重要的是，由于智能合约具有自动执行和公开验证的特性，它已经成为中美法律领域的主要创新力量[10]、[11]。以太坊存储服务方案Swarm提出了去中心化模式下的存储审计概念。然而，考虑到智能合约的链上约束，它缺乏一个激励层，公平审计服务只能外包给可靠的第三方。

作为去中心化存储系统的主导力量，Storj提出了一个由中心审计员组成的审计框架，称为“satellites/卫星”[12]。然而，这些审计师的选择取决于他们的声誉。因此，整个系统建立在信誉上的，每个存储提供商的信誉由satellites/卫星审计员决定。问题是，卫星的影响作用可能导致串通，因此Storj的创始团队和关联合作的各方在维持甚至控制系统中的审计和支付交易。

Siacoin[8]是提出具有可公开验证的完全去中心化数据存储网络的先驱之一。在其结构中，存储提供商通过定期向区块链提交原始文件的一部分和文件的Merkle树中的相应散列来证明存储。然而，由于质询随机性的低熵，存储提供商可能被重复使用来证明，而不是诚实地发送生成的存储证明数据。

而Filecoin[9]提出了一个用户辅助的审计框架，提交给Filecoin区块链的证明达到了我们对链上完美数据隐私的要求，因为证明是用ZK-SNARK生成的，尽管Filecoin的初衷是利用可验证计算来压缩证明，但可信设置阶段和证明生成阶段的计算开销使得目前难以部署。

评论。 尽管我们已经指出了上述方案的缺点，Storj和Siacoin仍在积极研究和改进中。Filecoin仍在大量建设中，还是早期阶段。我们还考虑了保护链上隐私的ZK-SNARK框架的两个代表，即比特币的ZKCSP[13]和以太坊的Hawk[14]。

三、概述

在本节中，我们将提供背景信息、和我们的系统概述和对抗模型。

A、分散存储体系结构

如图1所示，去中心化分布式存储系统可分为两部分，一部分用于数据存储的基础设施，另一部分用于审计和激励。数据存储基础结构负责数据分块、数据加密、擦除编码、分布式网络等。简言之，要外包的数据首先被分块并由数据所有者在块级加密。此外，数据冗余还需要擦除编码[15]（奇偶校验块）。最后，数据所有者使用分布式哈希表[16]查找存储提供程序候选，并使用该表进行路由。

在我们的系统中，我们将数据加密和擦除编码应用于私有存档数据存储，并且我们强制数据所有者对数据加密。为了处理无法应用加密的公共存储，Filecoin利用了数据密封[9]和复制证明[17]，这在我们的设计中根本不需要。

在下面的演示中，为了简单起见，我们只考虑数据所有者和单个存储提供商之间的一对一映射。也就是说，我们假设一个简化的场景，其中数据所有者将所有数据存储在一个存储提供商中。而对于实际的开销估计，数据所有者可以自由地调整数据冗余级别和存储提供者的数量，导致总审计成本的线性增加可计算的。

B、系统概述

在我们的审计和激励机制的设计中，有三个主要角色，即数据所有者D，他请求对其加密数据进行去中心化分布式存储，并支付每一轮存储审核的费用；数据存储提供商S，他通过提供存储服务并配合存储审核来获得应得的利润；而专门负责审计工作的智能合约SC则忠实地向存储提供商提出挑战来审核数据被安全私隐地存储了，在A通过每一轮存储审核中验证响应证明，并相应地对存储提供商奖励诚实行为和惩罚不法行为。

存储合同谈判结束后，D、S先进行预处理，然后进行定期审核。为了公平性，要求双方在审计前提交保证金，智能合约负责解决D和S之间的所有潜在争议，并进一步全面控制审计和管理支付。

从本质上讲，我们认为D和S在经济上是两个理性的参与者，他们被充分激励以实现其回报的最大化。SC被塑造成一个公正的审计师，在D和S就外包数据达成一致后，负责审计，例如当审计开始时，智能合约从安全随机信标中提取随机性[18]，并为每一轮审计发出挑战。在收到S的响应后，智能合约执行其预先确定的合约逻辑，从而维持生态系统的平衡。我们强调审计频率应该适当设置（至少每隔几个小时），这样与审计间隔相比，区块链模型中的信息传播时间可以忽略不计。

C、对抗模式

首先，我们需要考虑激励措施的公平性。一方面，S不忠诚是很自然的。例如，它可以简单地丢弃数据以回收更多的存储空间以获得更多的利益；类似地，它可以巧妙地丢弃D很少访问的数据；它还可以隐藏数据丢失事件以维护其自身的声誉。另一方面，激励驱动的D也有不忠的可能。在极端情况下，D可能会为存储提供商生成不正确的元数据，使得审核总是有利于数据所有者的财务利益。但当假设经济行为主体是理性的，在面临经济处罚的情况下，我们排除了D和S的恶意行为的可能性。不过，在第VI-A节后面，我们将讨论防范此类攻击的可能对策。

我们还需要考虑针对连续审计跟踪的敌对行为。在诚实多数假设下，我们将区块链视为可信方，因为它是以完全透明的方式存储审计跟踪。由于透明性，链外对手可能在我们不知情的情况下，偷偷地观察链上审计跟踪并提取原始数据的知识。尽管这是一个看似很小的安全漏洞，但这种脆弱性很容易被利用，而且还可能被对手扩大，以发动更复杂的攻击。有关更多详细信息，请参阅我们在V-E中的完整分析。

四、 STRAWMAN 方案

我们提出的STRAWMAN 建议，重点是无缝集成审计与实现公平支付。我们利用一组标准的原语，同时提供链上隐私和效率。

A、原语

零知识证明可以验证特定语句的有效性，但不会泄露超出语句本身有效性的任何其他信息。实践性和通用性零知识证明系统使得他被广泛采用。零知识证明系统上的许多工具已经可以通过从高级语言实现通用编译器来支持任意计算。在所有零知识证明系统中，ZK-SNARK[21]、[22]是迄今为止最有用的结构。

B、基本实例

我们将基于Merkle树的审计协议封装在预先构建的ZK-SNARK电路中，以实现链上隐私和链上效率。我们首先假设ZK电路的可信设置已经完成，并输出证明密钥pk和验证密钥vk。在审计之前，D需要在要存储的数据中构造一个Merkle树，并获得Merkle根rt，该根rt可以公开访问。在S接收到D的数据之后，审计以质询响应协议的形式开始。

在合约期间，对于发出的每个质询R，D用伪随机函数找到质询块mi（Merkle树中的叶节点）。为了防止公开验证泄露数据信息，D利用已建立的ZK-SNARK电路和pk生成零知识证明prf。挑战的叶节点mi和相应的Merkle路径路径总是可以被证明而不泄漏语句之外的任何信息的。利用vk和challenge R，可以有效地验证产生的prf，同时保证链上隐私。

C、争议与公平

在审计之前的初始化阶段就有可能发生争议。在D部署了一个带有合同详细信息argmts、params（包含pk、vk和rt形式的元数据）的合约之后，S必须同意它们，然后合同才能继续。注意，D不能通过伪造参数和元数据来获得利润，因为参数和元数据是在ZK-SNARK电路的信任设置期间生成的，用于在要存储的数据上构造Merkle树。因此，在大多数情况下，S只是向智能合约发送一个确认信号，然后智能合约等待双方存入加密货币。在某些极端情况下，S可能会恶意终止合同，从而使D支付argmts、params和元数据的链上存储费用。在第VI-A节中，我们简要讨论了可能的对策。

定期审计阶段在存款之后立即开始时，更容易实现公平性。如果S提交可由vk验证的prf，S将从SC锁定的存款中获得小额付款；相反，如果prf不能由vk验证，D将获得小额付款。上述程序继续以预先确定的审计频率进行，直至合同最终到期。

D、限制

使用通用零知识证明的strawman/斯特劳曼解决方案很难部署，而且远不是最优的，因为链外过程（包括可信设置和证明生成阶段）中，会产生大量的开销。此外，挑战的随机性将被耗尽，之后的攻击者可以简单地利用重用进行挑战。鉴于通用ZK工具的局限性，我们设计了另一种审计方案。

五、我们的协议

通过一个简化的智能合约和基本实例，现在介绍我们协议的设计原理，及细节。

A、设计原理

由于通过直接使用通用的零知识证明系统，会产生了大量的链外开销。为了设计一个具有链上隐私及有效率的实用审计协议，并在此基础上考虑链下效率，我们转向使用公钥密码，更具体地说是同态线性认证器（the homomorphic linear authenticators, HLA）。详见第八节相关工作。

由于HLA封装了用于公共验证的公共同态认证器。对云存储审计的广泛研究[23]，[24]证明了其理论效率。然而，由于效率方面的考虑，尚未在实践中大规模部署。大多数设计都会给存储提供商带来相当长的预处理和额外存储的处理时间。尽管如[25]所述，虽然这种开销可以减轻，但它进一步导致证明大小的增加。为了提高效率，可以利用多项式承诺来降低存储开销和处理时间，而不必提高证明大小[26]，[27]。

直接应用基于HLA的非ZK版本审计协议的现实是非常危险的。我们证明了，潜在的对手可以利用链上证据中密封的“可提取知识”，进行攻击。因此，通过充分利用HLA的代数结构来隐藏数据的Sigma协议[28]，我们提出了同时实现链上隐私、链上效率和链下效率的协同设计。

B、审计详细信息

图3显示了智能合约和存储提供商之间的交互。我们的审计协议中使用了一个非对称双线性映射e:G1×G2→GT，其中G1是一个具有素数阶p的乘法循环群。让两个群生成器G1和G2从G1中随机选择，一个群生成器g从G2中随机选择，并指定一个随机oracle H:{0，1}∗→Zp。假设文件以F的形式存储，并以组元素的形式进一步分成n个数据块。然后，每个数据块集合可以构成数据块，以加速数据处理并节省额外的存储开销。形式上，F等价于块的集合{mi=（mi，0，··，mi，s-1）∈（Zp）s}d n s e i=0，其中我们使用dxe来表示大于或等于x的最小整数。注意，最后一个数据块可能需要填充。

六、安全性分析

在本节中，我们通过分析第三节中列出的安全保证的实现情况，简要评估了由智能合约实施的分布式归档存储安全审计协议的安全性。

A、存储正确性和公平性

我们已经详细说明了我们的安全存储审核协议的完整性，即正确的证明将始终通过验证，如第2.1节所示。因此，在审计期间，S的利益始终可以得到保护。

为了证明恶意S不能伪造损害D的利益的证据，我们首先给出了诚实S提交的审计证据可提取性的证明草图，本质上，不可伪造的问题可以转化为知识证明问题中的知识可提取性。更具体地说，给定两个有效的证明响应（σ1，y0 1，Ψ1，R1）和（σ2，y0 2，Ψ2，R2），除非对手能够打破CDH和q-BSDH假设[39]，否则以压倒性概率提取数据块的部分线性组合是可行的。

除了在理论上保证数据的可提取性外，指定k值以保证存储的数据不被篡改的高置信度仍然是至关重要的。之前的许多研究都分析了挑战组块数量k与存储置信水平之间的关系[40]。特别是，如果只有1%的数据被篡改，将k设置为300可以保证95%的D存储。在去中心化分布式档案储存的范例中，我们相信这个数量的挑战区块足以保护D的利益。鉴于以上对可提取性和储存保证的实际可信度的分析，我们有以下定理：

定理1。在给定q-BSDH假设的情况下，如果存储提供商没有保存数据文件的完整性，并且在随机oracle中被质询的块的数量足够大，则存储提供商无法生成使验证公式保持有效的证明。

在我们的威胁模型中，D和S理性的参与者。在实际部署中，一方可能仍然会以损害其他方利益的方式执行审核协议。例如，在初始化阶段，S是有可能向智能合约发送拒绝信号，并让S支付公钥的链存储成本。我们强调，在一个健壮的基于信誉的系统中，这种拒绝服务攻击对任何人都没有好处，但对自己都有坏处。使用类似的对策，也可以减轻其他攻击，如Sybil攻击[41]。

B、区块链上的数据隐私

在这一部分中，我们展示了我们的安全审计协议可以防止来自存储在区块链上的审计证明的数据泄漏。我们将认证器σ视为私有输入，防止其受到链外对手的野蛮攻击。然而，在实践中不必隐藏σ。我们强调以下定理是可以证明的：

定理2。对于任意概率多项式时间的敌方AP-P T，在看到所有公共输入后，AP-pt能够区分证人（w1，w2）的概率可以忽略不计。此外，在标准离散对数假设下，当所有公共输入都是可忽略的时，概率AP-P T可以将F与随机数据区分开来。

简言之，对于分布式存档存储，证人不可分辨的特性足以在区块链上实现完美的数据隐私。由于篇幅有限，我们不作正式分析。然而，潜在的原因是，加密的数据域及其生成的身份验证程序提供了大量的熵来防止野蛮的武力攻击，即使对手可以访问存储在区块链上的身份验证程序。

七、评价

我们现在通过回答以下问题来评估我们的审计协议。首先也是最重要的是，引入的操作的链上开销是多少？强制审计的总体成本是多少？第二，我们的DSN审计系统的链外开销是多少？在实际使用中是否会给数据所有者和存储提供商带来沉重的使用成本？此外，系统能支持的用户基础规模有多大？

A、实现和实验设置

我们的实现遵循兼容性的设计原则，可以部署为一个插件，适用于大多数底层P2P类存储系统和构建在区块链上的激励系统。特别是，我们选择Tahoe LAFS[46]和以太坊作为我们的测试平台。我们在以太坊平台上遇到的主要挑战是，由于链上编程语言的可靠性限制，无法有效地在本机上实现大多数复杂的密码原语。这个障碍阻碍了以太坊测试网的传统测试方法。尽管以太坊社区已经提出了像WebAssembly[47]这样的更多本地语言的坚实进展，但我们发现在可预见的未来，它仍然需要大量的开发工作。

有鉴于此，我们开发了带有操作码优化的预编译智能合约。我们的合约，连同离线实现，由1000多行代码组成，主要是在Golang。基于我们对操作码的定制，我们部署了自己的私有testnet，并初步验证了概念实现。我们强调我们的测试方法与以太坊社区提出的WebAssembly框架的当前开发计划是兼容的。为了模拟去中心化分布式档案存储网络中的基本存储服务，建立了由三个节点组成的专用网络，即一个节点代表矿工，一个节点代表存储提供者，另一个节点代表数据所有者。miner和存储提供商在Linux（Ubuntu服务器18.04 LTS）中使用Dell Poweredge T140服务器（Intel Xeon E-2174G CPU x4@3.80 GHz）。数据所有者使用台式PC（Intel Core i7 8700k CPU x6@3.70 GHz）。

为了有效地实现基于配对的加密，我们利用BN256曲线（| p |=| G1 |=256位，| G2 |=512位，| GT |=1536位），该曲线是在Golang库[48]中用优化的汇编语言实现的，用于椭圆曲线相关操作。除了椭圆曲线运算外，另一个主要的计算开销是由Zp上的有限域运算造成的。由于Golang的native math/big library[49]的限制，我们努力在Zp上优化有限域操作。最后，请注意，所有评价结果代表100个试验的平均结果。

B、论连锁效率与审计成本

大多数Dapp最关心的是链上成本。在我们的场景中，链上成本也占了我们支持的去中心化分布式存储系统中存储费用的大部分。在整个审计过程中，数据所有者需要为以下项目支付链上成本。

一次性存储成本。在预处理阶段，我们的审计协议依赖于存储在区块链上的公钥。图4显示了一次性成本的波动范围。不过，我们强调，这笔费用不超过1美元，与储存合同期限无关。

每次审计成本。由于ZK-SNARK框架是我们的strawman/斯特劳曼解决方案，因此我们在表二的128位安全级别上比较了我们的主要解决方案和非常精简的基于SNARK的解决方案。为了实现相对公平的比较，我们假设计算开销所产生的燃气GAS成本与计算时间成正比。然后，我们采用Ropsten Testnet[51]上的ZK-SNARK验证事务（带有预编译的Golang操作码）作为基线基准，这是在主网络上部署的ZK-SNARK契约。我们外推的详细方法如图5所示。

请注意，与基准实现相比，我们的链上计算性能得到了积极优化[52]，[53]。使用我们实验设置中的安全参数，每次审核只需要大约589000个gas（7.2ms用于验证，验证大小288字节，包含3g1和1gt）。与标准的基于SNARK的通用解决方案相比，我们的安全审计协议的链上成本要便宜50%。综上所述，我们的主要解决方案在计算时间较短的情况下产生了更简洁的链上证明。

随机生成的成本效益。对于每一个具有挑战性的时间窗口，智能合约必须获取足够的随机性，以生成唯一的C1、C2、r（48字节）。根据我们的估计，这些服务的费用从0.01美元[34]到0.05美元[35]不等，占总费用的比例很小。

估计年费。与云存储方案相比，我们分散的归档存储的最大额外成本属于链上总成本，这与可调审计频率成正比。值得注意的是，在实践中，考虑到区块链延迟问题和存储保证的实际需要，审计频率应该根据一天（或更高）的顺序进行调整。

在图6中，我们展示了在合同期限固定的情况下，审计频率与总成本之间的关系。通过保持每日审计合同，甚至考虑第三节a中所述的数据冗余因素（例如，10个擦除编码中的3个），链成本的年度审计与大多数云存储提供商的年度存储费用2接近.

C、链外成本

如表二所示，基于SNARK的解决方案在可信设置阶段会给数据所有者带来巨大的开销，在验证生成阶段会给存储提供程序带来巨大的开销。而我们的审计协议将在很大程度上减轻数据所有者和存储提供者的开销。

为数据所有者最小化工作。与重量级的基于SNARK的解决方案相比，我们的审计协议只要求数据所有者为预处理投入一次性的、相当微不足道的时间。相比之下，基于SNARK的解决方案产生的公共参数的大小高达数百兆字节，即使是一小部分数据也需要大量的时间（见表二中我们的strawman预处理解决方案评估）。与现有技术[24]、[25]相比，我们的解决方案大大减少了所需的时间，如图7所示。事实上，要外包一个1GB大小的文件，数据所有者只需花2分钟时间在四核笔记本电脑上将存储/计算参数s设置为50。注意，除了用户预处理期间的签名生成时间外，我们还将其他因素（如密钥生成和数据块的多项式系数转换）计算为广义的预处理时间。为了全面考虑预处理阶段和验证生成阶段，我们建议将可调参数设置为50左右。

高效的存储提供商。存储提供商还可以从我们的审核解决方案中获益。通过引入参数s，从存储提供程序获得的额外存储的大小仅为原始数据大小的1/s。虽然通过增加参数s，生成证明的时间也增加了，但考虑到Zp和椭圆曲线上的所有密码操作，实际结果是相当令人满意的。图8显示了当被质询块的数量设置为300时，详细操作的处理时间。我们强调，在存储提供程序方面限制计算开销是很重要的。我们还提供了一个更彻底的比较，当挑战块的数量变化时，适合不同的存储保证级别。在图9中，我们发现，当给定1%的数据篡改时，随着存储保证的置信水平从91%（挑战块的数量等于240）上升到99%（挑战块的数量等于460），生成证明的时间显著增加。

D、全系统因素

区块链吞吐量。对于单个数据所有者来说，审计成本主要受审计频率的影响。然而，随着用户群规模的扩大，整个分散存储系统的可扩展性受到区块链吞吐量的限制。在现实世界的部署中，我们可以使用一个专用的以太坊fork来进行审计。我们进一步假设平均块大小约为18kb，这与过去6个月以太坊[55]上的平均块大小非常接近。在这种假设下，平均吞吐量为每秒2个事务。即使考虑到数据备份的数据冗余因素，我们的系统也可以轻松地同时支持5000个活动用户。相比之下，Storj[7]和Siacoin目前都只支持1000个用户的存储系统。可扩展性。如图10的左图所示，与目前以太坊平台的每日增长约128mb[56]相比，区块链规模的估计年度增长将处于较慢的位置。从我们在Siacoin和Storj网络上收集的数据中，我们发现在一个有1000个用户的系统中，平均一个存储提供商可能需要存储大约30个用户的数据。尽管我们的审计协议本机支持批处理审计[24]，证明生成时间仍随公钥数量成比例增长。图10右侧的子图显示了在假设线性回归模型的情况下，当存储数据的用户数量逐渐增加时，每个存储提供程序所需的总体验证时间。特别是，当用户数为5000时，存储提供程序完成所有证明生成过程可能需要大约20秒的时间。然而，我们认为这一时间量是可以容忍的，因为异步区块链上的延迟（平均确认时间）花费了相似的时间量。

八、相关工作

在过去的十年里，人们对储存的证据进行了大量的研究。最直接的审计方案是应用标准哈希函数或消息验证码（MAC）来检查不受信任位置的数据完整性。尽管该方案具有计算效率高的特点，但由于验证者在输入相同数据的情况下需要重新计算结果的不便，该方案不具有可扩展性。而且，我也不能支持无限次的挑战。因此，大多数部署的解决方案都在数据上构造一个Merkle树，以减少通信和验证开销。

在云存储审计的设置中，大多数设计都利用公钥密码[25]、[40]，它聚合块的身份验证器，从而生成简短的证明。后来，在公共验证领域的发展[25]、[57]、[26]、[27]和动态性领域的发展[57]、[59]使人们重新对存储审计及其在云存储设置中的进一步应用的文献产生了兴趣。然而，这些先前的审计设计无法令人满意地解决分散式归档存储模式中的独特挑战。