Storj:A Peer-to-Peer Cloud Storage Network(点对点云存储网络)

最近在研究关于区块链存储相关的问题,于是在网上搜罗了一下相关的文章,本文是在14年出现的,在网上没有看见相应的中文文档,于是自己试着翻译了一下,不当之处,欢迎指正。

摘要

一种点对点的云存储网络,利用端到端加密技术允许用户能够不依赖第三方数据供应商实现数据的传送和共享。没有中间控制机构,能够消除大多数传统的数据故障和中断,并且显著性地提高了安全性、隐私性和数据控制。点对点网络和基础加密能够对大多数问题提供解决办法,但我们必须提供用户合理地参与这个系统的合适的激励。我们提出了一个解决这些额外问题的方法,通过使用质询算法。用这种方法,我们定期地加密检查文件的完整性和有效性,并且给维护文件的那些“农户”提供了一种直接的奖励。在不存在对等网络的情况下,所描述的方法可以用于允许用户在第三方数据提供者上控制,迁移,验证他们的数据,而提供者没有对数据的直接访问。

1 简介

互联网上的云存储传输和存储数据几乎唯一依赖于作为第三方信任机构的数据供应商。尽管这种系统在大多数情况下都能正常工作,但是它仍然患有这种基于信任模式的固有弱点。因为端到端加密是不标准的,传统云面临各种安全威胁,包括中间人攻击、恶意软件和揭露客户和企业敏感和隐私数据的黑客程序。此外,目前云存储应用程序能够在数据存储上收取很大的超过核心花费的附加费,因为用户在有互操作性,并且强大的供应商上有很少选择。此外,这些第三方供应商可能有技术故障导致数据泄露和不可用,这会使得依赖于他们的用户和应用遭到巨大危难。这些缺点在我们之前的Metadisk白皮书上已经深度讨论过。
所需要的是一个去中心化的云存储平台,在去中心化和开放网络上实现端到端加密。这种平台必须能够抵制试图进行女巫攻击或者其他形式进行欺诈的攻击者。另外,这种网络必须对时延、性能和用户计算机和“农户”硬盘的平均停机时间负责。在我们提出的网络中,加密算法能够保护转移和设备中的数据不被用户控制。开放市场将通过允许所有数据在网络中平等交易和移动来消除大量的费用。因为大多数连接在英特网上的计算机都有没有使用的硬盘空间,用户可以把这些资源卖给网络。这个网络上的文件通过它们的内容进行处理,通过哈希。网络上的数据将完全地抵抗审查、篡改、和/或数据故障。只要文件的一个副本存在它就能被访问,不用管原始的提供者是否在线。

2 文件加密碎片

我们确定一个碎片作为我们想存储在网络上的文件的加密的一部分。把文件分裂成碎片能更好的保证数据的安全性,以致于只要存储的文件是标准碎片大小,就没有农户拥有一个完整的副本。我们把出租他或者她的硬盘空间给网络的用户定义为农户。定义标准碎片大小为字节的倍数如8MB或者32MB。这些都是保持在预先设定的大小,以阻止试图存储任何东西(可能意思是碎片大小是预设的,不能存储想存储的任何东西,大小得符合)。分片也能更好的管理大文件,因为它们被分散到网络中。
这里写图片描述
1. 文件被分割成一些标准多倍字节例如32MB的碎片,或者多个小文件链接在一起形成一个碎片。任何额外的空间都用0填充。
2. 每一个碎片都用同样的方法加密,或者用户定义的方法,如外部加密密钥。
3. 碎片可以直接发送到网络。碎片可能会进一步修改,这取决于文件审核机制。
如果有必要,多个碎片可以结合在一起。这在两种情形下有用:第一,如果客户正在存储特别敏感或者重要的数据,把他们的碎片和其他客户的数据或者垃圾数据结合在一起就很有用,能够掩饰他们自己的数据。第二,在文件上,我们采用验证和审计的方法,但这在验证小文件的时候产生了不必要的费用,因此,把小文件结合在一起很有价值,它们都能够立即得到进行验证。

3 存储证明

另一个问题是存储在网络上的碎片的完整性和有效性。农户必须能够加密地证明他拥有这个碎片,并且没有以任何形式修改过。我们通过以下讨论的方法完成这个问题。

3.1 Proof-of-Storage via Merkle Audits

为了实现一个去信任的数据存储网络,我们必须给客户提供一个审计方法,证明他或她存储在网络上的数据可用并且没有被修改。我们通过使用Merkle树[2]和Merkle证明来做到这一点。 我们采集数据的集合并生成Merkle树,如图2所示:
这里写图片描述
树的叶子应该是256字节碎片或更小。理想情况下,树应该比数据大,因此树应该在生成而不是存储。 对远程位置上的数据的审计仅由特定索引和由位于该索引处的子分片加上Merkle树SPV证明的响应组成。该算法已被进一步描述在秘密共享和擦除编码[ 3 ]。

3.2 Proof-of-Storage via Pre-generated Audits

我们提出了一个替代的审计方法,这需要更多的开销,但可能比之前的方法有一定的优势。我们通过哈希挑战(质询算法)来做到这一点,在客户端产生一系列种子(由根种子确定),可以添加到文件并且进行哈希,产生唯一的哈希值。我们把这个过程称为心跳。客户端产生这些哈希挑战(质询算法),建立一颗merkle树[2]并且把merkle根加入到中本聪类型的区块链中。然后把除去叶子节点的merkle树发送给农户。客户端可以定期的发送种子给它托管数据的农户,检查农户的返回结果是否能和它产生的哈希值匹配,通过验证农户返回的值与merkle树中的值。(客户端自己有完整的merkle树,所有节点都在,农户只存储了某一个碎片,给它发送种子,它会返回一个哈希值,我检查这个哈希值是否在我的merkle树中就可以了)
这里写图片描述
农户不能修改或者删除文件,因为他或她进行哈希挑战(质询算法)时会失败,这会在第8节深一步描述。通过加密和哈希的前提,这些心跳不能蛮力强迫。客户端不能欺骗农户,因为哈希返回值能够通过merkle根验证,它是加入到区块链中的。这样,我们用区块链给存在证明背书,以使各个部分都是诚实的。
我们采用3种不同的机制产生挑战:
这里写图片描述

3.3 Full Heartbeat

我们可以用种子和整个碎片产生哈希返回值。这验证了整个碎片的完整性,但是I/O效率特别差,并且导致查询时间长。

3.4 Cycle Heartbeat

一个小小的改进就是碎片被分成N个离散的条,我们按照顺序验证每个小条直到完成周期。这种方法在Filecoin中首次提到。这种方法效率好,并且允许我们验证整个碎片的完整性,完成了N次心跳。不幸的是,它给系统留下了潜在的攻击可能,攻击者只需要有完整数据的1/n就能完成心跳。

3.5 Deterministic Heartbeat

在这种方法中,我们使用客户端传过来的根种子读取碎片时确定地产生心跳(由客户端传过来的根的种子确定碎片产生的心跳)。使用Feistel序列,我们最多进行n+2√n次挑战就能验证数据。我们把纠删码技术加到心跳方案中,以致于碎片任何微小的变化都能通过心跳检测到,或者通过碎片检索进行恢复。这是最有效的方法,并且通过调整参数,我们能平衡I/O效率和验证文件完整性。

3.6 Mixed Methodology

每种方法都有自己的优点和缺点。我们建议使用这些方法的组合。建议当文件第一次上传到网络时,使用一个完整的心跳。周期性心跳应当在定义的时间表上定期使用。确定性心跳应当在其他的挑战中使用。这样,我们能得到每个算法提供的所有的有点。

4 冗余证明

传统云存储公司拥有或者租借服务器存储他们客户的文件。他们使用RAID方案或者多个数据中心的方法从物理或者网络故障中保护文件。Storj没有中心服务器。文件存在于一个分布式的、虚拟的、去中心化的网络中。我们不像传统云存储公司那样依赖于一个农户雇佣相同的安全措施防止数据丢失。鉴于此,我们通过在多个农户上使用K-M纠删码技术存储碎片保证冗余。更具体地说,我们考虑到在网络层上的冗余,而不是物理层。我们还必须解决农户干脆关掉电脑的可能,从而从网络中删除一个碎片的可用性。
这里写图片描述

4.1 Simple Fault Tolerance

如果一个节点审计失败或者不可到达,我们就发起一个网络复制过程,通过把网络上一个现有的副本转移到一个新的节点上。因此,网络就能在每次审计之后恢复正常。

4.2 Sybil Redundancy Attacks

每个碎片都是唯一加密的。这意味着,当恶意农户只有一个文件副本时,不能假装拥有多个冗余副本。我们可以通过在集中加密碎片时,加入确定性的混淆值来完成。即使解密密钥是一个已知的特定文件,恶意农户也不能完成他们没有被分配到的碎片的审核。这样,我们可以证明一个特定的碎片的冗余,因为每一个冗余副本是独一无二的。

4.3 K-of-M Erasure Encoding

我们使用K-M纠删码技术确保文件碎片是有效的。客户端可以选择K和M达到文件鲁棒性和花费代价的平衡。在计算章节更是统计性地描述了文件的鲁棒性。纠删码技术也对攻击章节提到的hostage字节和修改字节提供了一种保护。

4.4 Redundancy Scaling

最终,用户和应用都被K-M纠删码技术的参数和分布式的冗余控制。对于简单的数据存储,用户可能选择推荐的设置,把他们的数据平均分配在3到4个农户上。这对简单容错已经足够。如果数据特别重要,用户可能把数据分散到500个农户中,这能保护数据免受世界末日和上帝的破坏。K-M纠删码技术也能影响数据的鲁棒性。

5 区块链

为了网络能够在文件位置和完整性上达到共识,我们使用中本聪类型的区块链。由于区块链是一个公共的账本,这是一个获得准确信息的非常有用的工具,并且能作为解决争端和阻止攻击的最终机制。打个比方,在一个隐蔽的地区,从一个饼干罐里偷一块饼干是很容易的,但是当罐子在公共广场中间时这很难做到,它被成千上万的人看着。通过使用区块链作为分布式数据存储,我们可以建立了一个既定的和经过时间考验的分布式一致性机制。我们不在区块链上存储任何文件,只存储文件元数据。本质上,我们存储文件哈希、碎片副本的网络位置和merkle根。这个方法的细节和可扩展性在Metadisk论文中已经描述了[1]。
数据通过一个带有额外元数据的标准交易插入到区块链。由于这种方法在比特币区块链上十分昂贵,并且在交易中进行严格限制元数据从技术上不可行,因此,我们不用它存储这类元数据。如Metadisk论文中描述的一样,我们用Florincoin作为最初的机制。最终,我们将过度到一个系统,它可以更加直接的使用比特币区块链,并且以一种可扩展的方式,通过存在性证明。由于区块链技术的提高,我们能使用类似于Factom的系统来提供更快的吞吐量,和利用以太坊对数据存储创建可执行的合约。
这里写图片描述

6 速度

增加冗余允许Storj网络有一些独特的特征。因为Storj是一个去中心化、分布式的网络,一旦一个额外的新的农户托管一个碎片,我们将还增加一个能够连接上的对等体,并且可以从这个对等体碎片。如果我们设置冗余为20x,那么将会有20个节点同时下载该碎片。这个正好和客户-服务器模式相反,它取决于最快连接到最近的数据中心。
和一个对等网络的标准功能一样,我们可以连接在地理位置上近的节点实现高的转移速度。我们可以用加密货币给维护节点到网络的连通性的节点提供一种激励,这解决了一种典型的问题,在对等网络中经常出现的为了更快的转移而节点不足的问题。虽然在这篇论文中没有讨论,但是却说明了在Storj中进行内容和数据的分散有很大的可能。

7 奖励

网络要正确工作,我们必须奖励正确和一致的行为。我们用加密货币Storjcoin X,即SJCX,作为Storj网络中的基准代币。客户和农户可以交易SJCX,用以使用网络上带宽和存储空间。
这里写图片描述
我们可以利用微支付/微交易促进节点间用以支付带宽和存储空间的加密货币的瞬间转移。客户端在心跳完成后就给农户付款。如果两方都是诚实的,并且达成了一致,就不需要更多的步骤了。此外,交易将会结束,并且最后商定的金额被认为是最终的。我们可以使用去信任的和自动确认机制来解决节点间的争端。只要双方都以经济上的合理的方式行事,这些方法可能没有必要,因为潜在的损失只相当于一分钱的微小部分。在有针对性的攻击的情况下,攻击者只关心的是能够得到巨大财富的网络攻击,这种就需要进一步的保护机制来保护网络中的新节点。

7.1 Market Basis

不同于传统的云服务,实现固定的定价,Storj网络上的定价取决于市场。数据资源的有效配置是由自由市场激活和激励的。农户设置要求,客户出价。价格可以基于带宽、位置和速度变化。例如,用SSD的更快的服务器可能比标准的笔记本电脑收费多。这样,我们可以实现我们的数据源的有效使用。Bob可能想在网络上存储一个能随时访问的视频文件。这种情况下,Bob可能想用更快的SSD服务。Alice仅仅想使用Storj网络进行备份。这时,电脑就是一个更便宜,并且更有效的选择了。

7.2 Peer Discovery

我们可以从任何源中得到质量可靠的数据和农户服务类型,它是一个可追踪服务或者直接来源于网络。这些在节点发现中都很容易做到。在这种方式中,我们使用一个伪信誉系统。如果Bob和Alice说Eve是有信誉的那Eve可能是有信誉的。Eve可能在在线时间或者速度上撒谎,但是我们的审核系统将会检测到这种情况,并且会把Eve这个节点删除。这种方式,我们不依赖于Bob和Alice的推荐,但是他们确实能帮助我们找到好的节点。

7.3 Market Scale

市场也会帮助平衡网络中的存储空间的供求关系。如果网络上存储空间需求量增加,然后SJCX代币的价值将会增大,刺激农户增加更多的存储空间到网络以满足需求。同样,需求减少,存储价格会降低,减缓增加到网络中的存储空间量。因此,网络依赖于市场能力以确保足够的网络资源。

7.4 Peer Rewarding

传统对等网络中存在的一个问题是节点不足。节点仅仅是自愿帮助加快传输流行文件的志愿者。同理,缺乏节点共享的不热门的文件的传输速度就会特别慢,或者几乎不存在可用性。我们内置的基于SJCX的奖励机制,通过支付托管碎片的节点解决了这一问题。用微支付/微交易,我们也可以直接支付节点,它们给需要碎片的节点发送碎片。这样,节点或许会更加自愿的托管流行碎片,能赚取更多的SJCX。简言之,这个系统能够在没有宽带证明算法这一专门开销下,能够至今去信任化的激励着传输。然而,最近的一篇论文TorPath已经揭露了那样是怎样成为可能的。

7.5 Uptime

农户被鼓励长期在线。这对于专用的农户硬件十分容易,难的是一般农户。由于这种不断变化的情形,我们在客户和农户之间设置数据合约进行替代。因此,我们可以设置在线时间的期望。Bob在他的笔记本上运行农户软件,因此,他可以接受一个允许定期关机的合约。但是,Bob会收到比Alice低很多的报酬,她有专用的硬件并且常年在线。一个简单的在线监视服务就能帮助客户端发现农户的在线时间。我们并不依赖于这些在线服务。它们只是用来帮助发现信誉节点,而我们的心跳算法能更直接的确保碎片的有效性。

8 Sybil and Bad Actor Attacks

有许多类型的传统的攻击,我们必须在我们的网络中加以解决。我们列出了许多攻击类型和他们的解决方案。

8.1 “Google Attack”

谷歌攻击是一个由比特币核心开发者Peter Todd所称的术语,用来描述由控制大量计算能力/存储空间的大公司或实体对网络的协同攻击。研究显示,Google目前存储了大约8000PB的有用数据。我们介绍用户空间的概念,或者在普通消费者(average consumers)的计算机上的集体未使用的可用空间。如果用户把Storj作为主要的云存储平台,用户空间可以扩展。我们的研究显示这一数字将达到250000PB。因此,即使Google停止了其所有服务来攻击网络,也不可能超过用户空间提供的资源。 我们认为集体用户空间更大,并且将总是大于集中式云计算行业的整体。
这里写图片描述

8.2 Sybil Redundancy Attacks

攻击者,当只有一个副本时,想通过假装他/她有多个副本冗余来控制网络,他/她做不到。这是因为每个碎片都是唯一加密的。因此,攻击者不能通过审核,除非他们有每个唯一冗余副本。客户端节点应按照步骤将其冗余副本分发给地理上分布且独立的节点。如果随机分散,相同的冗余片被托管在同一个控制节点的概率在统计学上概率相当小。采用随机分布和我们独特加密冗余副本的标准方法,攻击者是不能进行Sybil冗余攻击的。

8.3 Improper Distribution

这种情形,我们要检测想攻击网络的恶意农户。这种攻击者不关心经济效益,他希望的是能通过删除网络中的数据或者自己的冗余副本而导致网络不能信任,同时,致使文件不能恢复。通过与一个或多个恶意农户串通,它的目的是获得多个冗余副本的碎片。我们的第一道防线是上传敏感文件到网络时不能只用一个节点,而是使用多个节点进行转播碎片。这样,即使有一个节点是恶意节点,它也不能实施这种攻击。节点或许会串通好,但是客户随机选择节点的话,选到串通好的这些节点的概率特别的小。在最坏的情况下,农户串通好的很多转播节点,现在就有第二道防线,它由两个额外的机制组成:第一,使用具有不同参数的纠删码技术和冗余方案,确保农户不知道自己需要破坏多少副本碎片。此外,我们可以设计一个方法,所有的验证都是在GVN上进行的,详细在第10节介绍。这样,如果它有多个冗副本,它无法确定那些相关的碎片。

8.4 Cheating Client Node

让我们想象这样一种情形,一个恶意参与者想托管一个文件,但是它不想为这个文件进行支付,或者故意拒绝正确的审核来避免支付。这种情形,两个节点就会有不一致,交易就会终止。如前面描述的,merkle根被写入区块链,作为客户进行验证挑战的充足的和无可辩驳的证据。

8.5 Hostage Byte

人质字节攻击首先是由Vitalik Buterin阐述的,农户向客户传输数据,但是把最后一片数据留着作为人质字节,以索取更高的费用。我们用纠删码技术解决这个问题,这样,恢复文件所用的碎片就不必要非得用那个被挟持碎片。只要客户端把纠删码收藏好,恶意农户就不会知道最后一个字节是什么。

8.6 Honest Geppetto Attack

在这种攻击向量中,农户在较长的时间诚实地提供了大量的存储空间。在某些时候,他们拉动字符串,试图占用大部分网络。我们可以通过两种方式使这个代价昂贵:第一,通过使用在Outsourceable Audits章节中详细描述的GVNs方法,我们可以延迟给农户支付。农户接受支付之前在一定程度上证明了可靠性,并且如果他们突然变成恶意节点或者不能提供适当的服务,未付资金将会被没收。第二,客户和农户之间可以创建一个担保合约。他们都同意服务等级协议,如果农户背离协议,客户端应当被支付,或者资金可能会被销毁。

9 网络

上传到文件到网络和从网络恢复文件的步骤:
1. 文件被切成小片,增加纠删码技术和加密技术生成碎片。
2. 传输碎片到网络中的不同农户节点,基于分布式和纠删码技术。
3. 一旦核实完成,支付农户。
4. 客户端或许会联系任何农户用以恢复数据,此时,农户支付传输数据的费用。

10 Outsourceable Heartbeats

传统去中心化网络,例如比特币,为了能够正常运行,依赖于一致性算法。它们直接使用类似于工作量证明这样的算法,计算能力决定了网络一致性。不幸地是,这类机制要求网络中的大多数节点都是诚实可信的。这就摧毁了很多类似于Terracoin这样的小型的加密货币,它们中的大多数节点都表现的不诚实,所熟知的51%攻击。比特币本身也有潜在的51%攻击的问题。此外,这些算法为了保证安全,浪费了大量的算力,尽管在类似于Peercoin这样的加密货币中取得了一定的进展。
在一个标准的加密货币网络如比特币中,51%攻击对网络中的大多数没有多大影响。只有在进行交易时进行攻击才能成功,而不是网络中的其他时候。这与基于数据的网络不同,作为一个攻击者,它能改变网络中碎片的状态,并导致数据丢失。依赖于数据,这可能会对网络产生灾难性的影响,并可能导致其完全失败。这样,我们不能仅仅依靠共识来决定存储在网络上的碎片的状态。
相反,我们把客户指定为网络中的最终决策者。毕竟,是客户为网络中的存储空间支付。使用区块链作为无可争议的根据,即使客户是最终决策者,他也不能欺骗农户。感谢审核算法,我们不用担心网络中有多少不诚实或者串通好的节点。恶意节点不能通过审核,并且唯一、加密的冗余副本确保了节点串通或者女巫攻击不可能发生。
剩下的问题就是当客户离线时怎么进行审核。我们不期待传统客户一直在线,因此,我们必须设计一种去信任的方法,来验证心跳和给农户支付。我们提出了几种方法,验证和支付都能单独或者集中进行。

10.1 Client Controlled

最早的方法仅仅简单涉及给客户控制和访问自己在线硬件的权限。例如,他们或许购买了一个一个月仅几美元的基础VPS服务。为了降低开支,他们或许跟其他用户或者了解的朋友共享这以服务。操作非常简单,服务器只需定期地向农户传递一个审计,把它和一个预先确定的响应进行验证。同时,也可以向农户支付各种款项。

10.2 Group of Verification Nodes

另外一种方法依赖于管理心跳和支付的组节点验证(GVNs)。用户传递审计和款项到GVNs。在M-of-N多方签名方案中,我们使用N-of-N,N是GVN中的节点数。这样,单个非串通和诚实的节点能够反驳并阻止任何串通节点的支付。由客户端决定,我们可能采用M ¡ N方案。Sia[18]描述了一些方法,可以用来驱逐那些串通节点。为了确保客户仍然是最终决策者,我们还需要制作一种返回资金到客户的交易。这种交易将不会被传播,所以客户端任何时候都能检索任何未被花费的资金。我们更能增加存在性证明方法,导致这些组节点采取的所有行动都是通过区块链公共认证的。

10.3 Buried Keys

审计反应本身可能是私有的或者访问资金的钥匙。响应返回后,农户可以得到从网络或者GVN中直接支付的密钥。另外,由智能合约管理的去中心化支付服务它本身就是一个解决方法,或者和GVN一致。

10.4 Dust and Anonymizing

GVNs允许我们核查给农户的成千上万的验证和奇怪的支付。理想情况,GVN和农户之间应当建立一个微支付通道,农户应当通过GVN的即时验证得到支付。这将允许我们避免产生成千上万的尘埃般的交易。此外,GVN能够为用户提供匿名,如把资金混淆在里面一样。因此,用户资金和用户文件之间没有直接或者非直接的联系。

10.5 Extending GVNs

为我们的Stroj奠定了思想,这里还有一些其他的开发出来的方法,能够处理审核和去信任支付。包括Factom,oracles,smart contract,Turing-complete blockchains,p2p networks,quorums,and scratch-off puzzles。这些里面的每一个方法都是能够处理心跳和支付的有用且去信任化的方法。尽管Metadisk将作为GVN中一个节点的第一种实现,但是其他的方法也能够在GVN中作为这样一个节点进行服务。我们的核心目标是让客户作为最终决策者。客户能够处理这些任务,也能有足够的能力实现它以最舒适的方法保护其数据。
这里写图片描述

11 Calculations

假定每个碎片在线的概率为p,k-of-n纠删码技术失败的概率计算方法如下:
这里写图片描述
这里写图片描述
这里写图片描述

因此,纠删码有足够的参数时,除了上面描述的恢复方法外,碎片或者文件丢失的概率特别小。

12 结论

我们概述了一种实现点对点加密技术的对等云存储网络,它允许用户能够不依赖第三方数据供应商而传输和共享数据。我们已经解决了一些问题,如女巫攻击和节点连接失败,通过使用独特地加密冗余副本,和定期检查文件可用性和完整性的审核算法。通过使用加密货币,我们提供适当的激励促使网络壮大,并且能够在客户和农户之间进行数据交易。我们给予客户足够的权力,超过了处理文件验证和支付的算法。使用这些方法,我们把云上数据的控制权交还给用户。
我们还假设,当缺乏对等网络中描述的这些方法时,允许用户在第三方数据提供商上控制、转移和验证他们的数据。本质上,在信任的数据提供商上运行去信任化和容错系统,能增强安全性和隐私性。

猜你喜欢

转载自blog.csdn.net/yooliee/article/details/56837397