1. 首页
  2. 行业资讯

先睹为快!STORJ V3 白皮书发布(二)

STORJ V3

先睹为快!STORJ V3 白皮书发布(二)

在无数次博客更新V3进度之后,终于在30号,STORJ官方发布了STORJ 3.0的白皮书。

作为分布式云存储的元老级项目,STORJ是最早将分布式存储与区块链结合在一起的项目。经过时间的洗礼,官方团队在技术研发上的进展,加之Filecoin的上线临近,让本次STORJ的V3都非常令人期待。

事实上,官方也不负众望,在新版本的白皮书中,我们看到了STORJ有非常大的改变,在之前的文章中,我们也翻译了STORJ官方发布的V3 Demo:(点击可查看)。

下面,让我们来揭开STORJ V3 的神秘面纱!

昨天翻译到了第三章第五节,今天继续来看:

3.6

加密

无论存储系统如何,我们的设计约束都需要完全的安全性和隐私性。所有数据或元数据都将被加密。数据必须尽早在数据存储过程中中加密,理想情况是在数据离开源计算机之前。这意味着与Amazon S3兼容的界面或适当的,类似的客户端应该与用户的应用程序在同一台计算机上共存。

加密应使用弹性机制,允许用户选择所需的加密方案。它还应存储有关该加密方案的元数据,以允许用户在更改或升级其加密选项时使用适当的解密机制恢复其数据。

为了支持丰富的访问管理功能,不应对每个文件使用相同的加密密钥,因为访问一个文件将导致访问所有文件的解密密钥。相反,每个文件都应使用唯一密钥加密。这应该允许用户共享对某些选定文件的访问权限,而不会泄露其他人加密的详细信息。

因为每个文件应该使用不同的密钥,也可能是不同的算法进行加密,所以有关该加密的元数据必须以安全可靠的方式存储在某处。此元数据以及有关的其他元数据文件,包括其路径,将存储在先前讨论的元数据存储系统中,由确定性的分层加密方案加密。基于BIP32 [46]的分层加密方案将允许共享子树而不共享其上一级,并允许共享一些文件而不共享其他文件。有关基于路径的分层确定性加密方案的讨论,请参见第4.11节。

3.7

审计和声誉

激励存储节点准确存储数据对于整个系统的可行性至关重要。必须能够验证和验证存储节点是否准确存储了他们应该存储的内容。

许多存储系统使用全文件概率性的审计(称为检索证明)作为确定何时何处修复文件方法[47,48]。我们正在扩展可恢复性的,常见的全文件证明的概率性质,以涵盖特定节点存储的所有可能文件。在这种情况下,审计是概率上的挑战,它们以高度的确定性和低开销量确认存储节点是否良好,是否存有其声称存储的数据,并且不易受硬件故障或恶意攻击的影响。审计功能作为“抽查”[49],以帮助计算给定存储节点的未来实用性。

在我们的存储系统中,审计只是用于确定节点稳定程度的机制。审核失败将导致存储节点被标记为“出错的节点”,这将导致将数据重新分发到新节点并在将来的存储中完全避开该节点。存储节点正常运行时间和总体运行状况是用于确定哪些文件需要修复的主要指标。

与检索证明的情况一样[47,48],这种审计机制不会审计所有文件中的所有字节。这可能为误报留出空间:验证者认为存储节点保留了完整的数据而节点实际上修改或部分删除了文件。幸运的是,单个部分审计的误报概率很容易计算(见7.2节)。当作为整体迭代地应用于存储节点时,对已丢失或改变的数据的检测可以确定在已知且可修改的错误阈值内。

需要一个声誉系统来保持给定节点身份的审计结果的历史。我们的整体框架对这种系统的使用有灵活的要求,有关我们最初方法的讨论,请参见第4.15节。

3.8

数据修复

数据丢失是任何分布式存储系统中始终存在的风险。虽然存在许多导致文件丢失的潜在原因,但与其他原因相比,存储节点流失(存储节点加入和离开网络)是最大的主要风险。如2.5节所述,许多现实世界系统中的网络会话时间从几小时到几分钟不等[7]。虽然还有许多其他方式可能会丢失数据,例如损坏,恶意行为,硬件错误,软件错误或用户启动的空间回收,但这些问题都没有。我们预计节点流失是我们网络中数据丢失的主要原因。

由于审计已经验证了符合要求的节点是否正确存储数据,因此剩下的任务就是检测存储节点何时不再以正确的方式存储数据或脱机然后修复新节点所需的数据。为了修复数据,我们将通过从剩余部分重建的纠删码来恢复原始数据,然后重新生成丢失的部分并将它们存储在网络上的新存储节点上。

在我们的系统中,最重要的是激励存储节点参与者保持在线的时间不只是几个小时而已。为了鼓励这种行为,我们的支付策略将涉及奖励存储节点运营商,使其节点一次数月和数年保持参与。

3.9

支付

去中心化网络中的支付,价值归属和计费是维持健康的供需生态系统的关键部分。当然,去中心化的支付系统在很多方面仍处于起步阶段。

对于我们的框架来实现低延迟和高吞吐量,我们不能对区块链具有事务依赖性(参见第2.10节)。这意味着具有足够性能的存储系统无法等待区块链操作。当操作应以毫秒为单位进行测量时,等待一组节点在概率上就全网账本达成一致是不可能的。

相对的,我们的框架强调游戏理论模型,以确保网络中的参与者得到适当的激励,通过持续在线并且以理性的行动以获得报酬。我们的许多决策都是以现实世界的财务关系为蓝本的。付款将在后台结算过程中在网络中表现良好的节点中转移。我们框架中的存储节点应该限制他们与不受信任的付款人的接触,直到获得这些付款人可能为所提供的服务支付报酬的信任。

此外,该框架还跟踪和汇总拥有网络上存储的数据的人员对这些服务的消费价值。通过收取使用费,该框架能够支持存储市场的端到端经济生态系统。

虽然Storj网络与支付无关,并且协议不需要特定的支付类型,但网络假定基于以太坊的STORJ令牌作为支付的默认机制。虽然我们打算将STORJ令牌作为主要支付形式,但未来可以实施其他用于替代支付类型,包括比特币,以太坊,信用卡或借记卡,ACH(自动清算中心),甚至可以用活山羊。

4

具体实现

考虑到我们的设计约束,我们认为我们所描述的框架是相对基础的。但是,在框架内,仍然可以自由选择如何实现每个组件。

在这一节中,我们制定了最初的实施策略。我们希望本节中包含的详细信息会随着时间的推移逐渐变化。然而,我们相信这里给出的细节是可行的,并且支持我们框架的有效实现,即提供高安全性、高性能和耐用的生产级存储。

和我们的前期版本一样[37],我们将通过我们的Storj改进提案流程[50]发布对这个具体结构的更改。

4.1

定义

下面的术语在整个具体实现的描述中使用如下:

4.1.1 角色

客户 从网络上传或下载数据的用户或应用程序。

对等节点类 一个有凝聚力的网络服务和责任集合。有三种不同的对等节点代表我们网络中的服务:存储节点,卫星和上行链路。

存储节点 此类对等节点参与节点发现系统,为其他人存储数据,并获得存储和带宽的报酬。

上行链路 此类对等节点表示实现libuplink并希望存储和/或检索数据的任何应用程序或服务。 预计此类对等节点不会像其他两个类一样保持在线状态,并且相对较轻。 此对等类代表客户/客户端执行加密,擦除编码以及与其他类对等节点的协调。

Libuplink 一个库,提供与存储节点和卫星直接交互所需的所有功能。 该库将以多种不同的编程语言提供。

Gateway 一种服务,它在其他对象存储服务(如Amazon S3)和libuplink之间提供兼容层,从而公开与Amazon S3兼容的API。

Uplink CLI 命令行接口,用于从网络上载和下载文件、管理权限和共享以及管理帐户。

Satellite 此类对等节点参与节点发现系统,缓存节点地址信息,存储每个对象元数据,维护存储节点信誉,聚合计费数据,支付存储节点,执行审计和修复,以及管理授权和用户帐户。用户拥有帐户并信任特定的卫星。 任何用户都可以运行他们自己的卫星,但我们希望许多用户选择避免操作复杂性,并在由受信任的第三方(如Storj Labs,朋友,小组或工作场所)托管的另一个卫星创建帐户。

先睹为快!STORJ V3 白皮书发布(二)

4.1.2 数据

 存储桶是一个无限但命名的文件集合,由路径标识。 每个文件在桶中都有一条独有的路径。

路径 路径是存储桶中文件的唯一标识符。 路径是任意字符串。 路径在访问控制边界包含正斜杠。 正斜杠(称为路径分隔符)分隔路径组件。 示例路径可能是videos / carlsagan / gloriousdawn.mp4,其中路径组件是视频,carlsagan和gloriousdawn.mp4。 除非另有要求,否则我们会在路径离开客户应用程序的计算机之前对其进行加密。

文件或对象 文件(或对象)是我们系统中的主要数据类型。文件由路径引用,包含任意数量的字节,并且没有最小或最大限制。文件由一个或多个有序集合表示。 分段具有固定的最大值。文件还支持有限数量的用户定义键/值字段,称为扩展属性。与路径一样,文件中包含的数据在离开客户端计算机之前会被加密。

扩展属性 扩展属性是与文件关联的用户定义键/值字段。 与其他文件元数据一样,扩展属性以加密方式存储。、

 段表示单个字节数组,介于0和用户可配置的最大段之间。 有关详细信息,请参见第4.8.2节。

远程段 远程段是将在网络上进行纠删码和分发的段。 远程段大于跟踪其簿记所需的元数据,其中包括诸如存储数据的节点的ID之类的信息。

先睹为快!STORJ V3 白皮书发布(二)

内联段 内联段是一个足够小的段,其中所表示的数据占用的空间少于远程段需要跟踪哪些节点具有数据的相应数据。 在这些情况下,数据存储为“内联”而不是存储在节点上。

 带是段的进一步细分。 带是固定数量的字节,用作加密和纠删码边界大小。 纠删码单独发生在带上,其中加密可能一次发生在一小部分条带上。 所有段都是加密的,但只有远程段纠删码带。 带是执行审核的单位。 有关详细信息,请参见第4.8.3节。

纠删码块 当带被纠删码编码时,它会生成多个称为纠删码块的片段。 只需要一部分纠删码块来恢复原始条带。 每个纠删码块具有标识哪个纠删码块它的索引(例如,第一,第二等)。

 当远程段的带被纠删码编码为纠删码块时,具有相同索引的该远程段的纠删码块被连接在一起,并且该连接的纠删码块组被称为一块。 如果在纠删码编码带后存在n个纠删码块,则在处理远程段之后有n个块。 第i个部分是来自该部分条纹的所有第i个纠删码块的串联。 有关详细信息,请参见第4.8.5节。

指针 指针是一种数据结构,它包含内联段数据,或跟踪存储远程段的各个存储节点以及其他每个文件的元数据。

4.2

对等节点类

我们的整体战略从我们以前的版本[37]延伸出来,并且还反映了分布式存储系统,例如Google文件系统[26](以及其他类似GFS的系统[27,51,52])和Lustre分布式文件系统[28]。在任何一种情况下,网络中都有三个主要角色:元数据服务器,对象存储服务器和客户端。对象存储服务器保存系统中存储的大量数据。元数据服务器跟踪每个对象的元数据以及对象在对象存储服务器上的位置。客户端通过与元数据和对象存储服务器通信,提供连贯的视图和轻松访问文件的途径。

Lustre的架构经证明具有高性能。大多数前100名最快的超级计算机都使用Lustre来实现其高性能,可扩展的存储[28]。虽然我们不期望在广域网上实现相同的性能,但我们期望比其他架构具有更好的性能。我们在性能方面遇到的任何限制(如果有的话)都将归因于我们整体架构之外的因素。

我们以前的版本为每个组件使用了不同的名称。我们之前称之为Storj Share,我们现在称之为简单的存储节点。我们以前集中的单桥实例现在可以由任何人运行,并称为卫星。我们的libstorj库将尽可能向后兼容,但我们现在将客户端软件称为Uplinks。

4.3

存储节点

存储节点的主要职责是可靠地存储和返回数据。节点运营者是拥有超额硬盘空间并希望通过将空间租给他人来赚取收入的个人或实体。这些运营者将在本地下载,安装和配置Storj软件,无需任何账户1。然后,他们将配置磁盘空间和每个卫星的带宽限额。在节点发现期间,存储节点将通告可用的带宽和硬盘空间量,以及它们指定的STORJ令牌钱包地址。

为了简化临时文件的生命周期管理,存储节点还跟踪可选的每件“生存时间”或TTL、名称。片段与特定的TTL到期值,在到期日期之后,数据将被删除。如果未提供TTL,则预计数据将无限期存储。 这意味着存储节点具有到期时间的数据库,并且必须偶尔清除旧数据。

存储节点还必须跟踪已签名的带宽分配(参见第4.17节),以便发送给卫星方便以后进行结算和支付。这还需要一个小型数据库。TTL和带宽分配都存储在SQLite [53]数据库中。存储节点可以选择哪些卫星工作。如果他们使用多个卫星(默认行为),那么支付可能来自不同支付时间表的多个来源。存储节点由特定的卫星支付,用于:

(1)在请求时以出口带宽支付的形式返回数据;

(2)在静止时存储数据。

期望存储节点可靠地存储发送给它们的所有数据,并且以假定它们忠实地存储所有数据来支付。未通过随机审核的存储节点将从池中删除,可能会损失托管中的资金以支付额外费用,并且将来只会收到有限的付款。存储节点不支付数据的初始传输以存储(入口带宽)。这是为了阻止存储节点删除数据,而只是为了存储更多的数据而支付,这成为我们之前版本的一个问题[37]。虽然支付存储节点用于修复出口带宽使用,但一些卫星可以选择支付低于正常检索出口带宽使用的费用。存储节点不为节

点发现或任何其他维护业务付费。

存储节点将支持三种方法:get,put和delete。 每种方法都将采用片段ID,卫星ID,自相关实例的签名和带宽分配(参见4.17节)。 卫星ID形成明媚空间。 具有不同卫星ID的片段ID指的是不同片段。

Put操作将获取一个字节流和一个可选的TTL,并存储这些字节,以便可以通过get操作再次检索字节的任何子范围。Get操作预计会一直工作到TTL到期(如果提供了TTL)或者直到接收到删除操作,以先到者为准。

存储节点将允许管理员在过去30天内配置允许的最大磁盘空间和每个卫星的带宽使用量。他们将跟踪两者的剩余量,并拒绝没有来自相应卫星有效签名的操作。

存储节点正在开发中,将作为开源软件发布。


1可能需要使用US-1099税务表格进行注册,见4.21节

4.4

节点标识

在安装期间,存储节点、卫星和上行链路都生成它们自己的标识和证书,以便在网络中用。此节点ID用于节点发现和路由。

每个节点都将运行自己的证书颁发机构,该机构需要公钥/私钥对和自签名证书。理想情况下,证书颁发机构的私钥将保存在冷存储中以防止密钥泄露。由于证书颁发机构的密钥轮换需要全新的节点ID,因此以良好的操作安全性管理证书颁发机构私钥非常重要。

先睹为快!STORJ V3 白皮书发布(二)

节点的证书颁发机构的公钥确定其节点ID。与S / Kadem-lia [32]一样,节点ID将是公钥的哈希值,并将作为加入网络的工作证明。与比特币的工作证明[23]不同,工作证明将取决于在散列输出中可以找到多少尾随零位。这意味着节点ID(可以以多个尾随零位结束)仍然可以在平衡的Kademlia [8]树中使用。这笔费用是为了让Sybil的攻击成本过高,又费时。

每个节点都有一个可撤销的叶证书和由该节点的证书颁发机构签名的密钥对。节点使用叶密钥对进行通信。每个叶子都有一个签名时间戳,卫星跟踪每个节点。如果叶子被破坏,节点可以发布具有更晚时间戳的新叶子。感兴趣的对等节点将记录新看到的叶时间戳并拒绝具有较旧叶证书的节点的连接。作为优化的特殊情况,当叶证书和证书颁发机构共享相同的时间戳时,对等节点不需要记录。

4.5

点对点通信

最初,我们在传输层安全协议(TLS)[55]之上使用gRPC[54]协议,在μTP[56]传输协议之上添加了用于NAT(STUN)的会话遍历实用程序[29]。STUN提供NAT遍历;μTP提供可靠的、或按序的交付(如TCP)的LEDBAT[57]功能;TLS提供隐私和身份验证;gRPC提供多路复用和方便的程序员接口。LEDBAT允许竞争的互联网传输优先,为家庭运营商提供更优雅的用户体验,减少网络使用干扰。随着时间的推移,我们将用一个更灵活的安全传输框架(比如噪声协议框架[58])来代替TLS,以便在数据已经加密并且不需要转发保密的情况下减少由于连接握手导致的往返。

当使用诸如TLS或Noise之类的经过身份验证的通信时,每个对等节点都可以通过验证证书链并散列其对等节点的证书颁发机构的公钥来提升它与之通信的节点的ID。然后,通过考虑ID末尾的尾随零位数,可以估计构建节点ID需要多少工作。由于用户的自然干预而工作。

对于节点不能通过NAT或防火墙(通过STUN[29]、uPnP[30]、NATPmP[31]或类似技术)实现成功连接的少数情况,将需要人工干预和端口转发。将来,无法通过防火墙创建连接的节点可能需要支付费用来依赖来自其他更可用节点的流量代理。节点还可以为其他节点提供帮助,用于初始STUN设置、公共地址验证等。

4.6

节点发现

此时,我们有存储节点,如果我们知道它们的地址,我们就有了识别和与之通信的方法。 我们必须考虑到存储节点通常位于消费者互联网连接上以及具有不断变化的IP地址的路由器后面的事实。 因此,节点发现系统的目标是提供一种按节点ID查找节点最新地址的方法,有点类似于DNS为公共互联网提供的角色。

Kademlia分布式哈希表(DHT)是具有内置节点查找协议的键/值存储。 我们利用Kademlia作为节点查找的类似DNS的功能的主要来源,同时忽略了Kademlia的键/值存储方面。 仅使用Kademlia进行节点查找,就不需要Kademlia需要的其他功能,例如基于所有者的密钥重新发布,基于邻居的密钥重新发布,存储和检索值等等。 此外,我们通过在适当的地方使用S / Kademlia [32]扩展来避免许多其他已知的攻击。

不幸的是,诸如Kademlia之类的DHT需要多次网络往返进行许多操作,这使得难以实现毫秒级的响应时间。为了解决这个问题,我们在Kademlia之上添加了一个基本的分散式缓存服务。

缓存服务将在每个Satellite中独立存在,并尝试与网络中的每个存储节点进行持续通信,可能每小时一次。然后,缓存服务将缓存每个节点的最后已知良好地址,并逐出在一段时间后未与之交谈的节点。无需扩展存储节点即可了解这些缓存服务。我们预计这将在合理的未来扩展,因为ping操作很便宜,但承认最终可能需要一个新的解决方案。幸运的是,空间要求可以忽略不计。例如,只需5MB内存即可完成80k节点网络的缓存地址2。

基于这种设计,每个Satellite的缓存都不会成为事实的主要来源,并且缓存中的结果可能是陈旧的。但是,由于我们的冗余存储策略,存储网络将具有抵御预期的节点流失和陈旧程度的弹性。因此,即使缓存中的某些查找失败或返回错误的地址,系统也会很健康。此外,由于我们的点对点通信系统已经提供了对等节点身份验证,因此有时会导致错误或故意误导地址查找响应的节点发现缓存只会导致性能损失,但不会导致正确性缺失。

修复(第4.14节)要求快速确定节点是在线还是离线,因此虽然Satellite缓存不是真正的主要来源,我们系统中的查找将停止缓存查找,并且不会尝试使用Kademlia进行另一次查找。 只有在审计请求失败的情况下才会出现回退,才会执行Kademlia中的非并发查找以纠正可能过时的缓存信息。

除了包含在每个Satellite中之外,我们还计划托管并帮助建立一些著名的社区运行节点发现缓存。如果节点最近在线,这些高速缓存将执行快速返回给定节点ID的地址信息的任务。

Kademlia消息将使用我们的点对点通信协议(第4.5节),其中包括机密性和对等节点识别。 因为这需要加密设置,所以在可能的情况下将缓存与Kademlia相邻和频繁联系的连接。

通过在网络上共享每个Kademlia消息,节点将包括其可用磁盘空间,每个Satellite的带宽可用性,STORJ钱包地址以及网络所需的任何其他元数据。节点发现缓存将收集节点提供的此信息,从而允许更快地查找它。


2假设一个有序的内存列表,包含4元组的节点ID(32字节),IP地址(IPv6为16字节),端口(2个字节)和时间戳(4个字节)。80000·(32B+16B+2B+4B)≈4.12MB

4.6.1 防止女巫攻击

虽然我们采用了工作证明方案S / Kademlia建议部分解决女巫攻击,但我们通过特定于应用程序的集成扩展了Kademlia以进一步保护我们的网络。

给定两个存储节点A和B,存储节点B不允许进入存储节点A的路由表,直到存储节点B能够呈现来自卫星C的签名消息,存储节点A信任该签名消息,该签名消息声称B已经通过了足够的审计,C信任它(第4.13和4.15节)。这确保只有具有经过验证磁盘空间的节点才有机会参与路由层。

允许进入路由表的节点被认为是经过审查的,并且仅通过经过审查的节点进行查找。为了确保仍然可以找到未被发现的节点,经审查的节点保留其未被发现的邻居的无限列表,前提是所有未被发现的邻居的XOR距离不比最近的k个被审查的邻居的距离更远。Unvetted节点使他们的k最近的审查节点保持最新。

4.7

冗余

我们使用Reed-Solomon纠删码[59]。为了实现减少长尾效应的解决方案(参见第3.4.2节),我们为每个存储的对象选择4个数,k,m,o和n,这样k≤m≤o≤n 。标准Reed-Solomon是k和n,其中k是重建所需的最小数量,n是创建过程中产生的总数。

最小安全值和最佳值分别是m和o。m值是cho-sen,这样如果卫星注意到可用碎片的数量已经降到m以下,它立即触发修复,以确保我们总是保持k个或更多碎片(在Giroire等人中,m称为r0)。L.〔36〕为了实现我们的长尾性能改进[39,40,43,44],选择值o,以便在上传和修复期间,一旦o个片段完成上传,剩余的n个片段将被取消。此外,选择o以使得存储o个碎片是实现期望的耐久性目标所需的全部;因此选择n个碎片以使得存储n个碎片将具有超额耐久性。

先睹为快!STORJ V3 白皮书发布(二)

我们可以容忍的长尾上传量是n – o,因此是我们免疫的慢节点数量。可以在不触发修复的情况下暂时同时进行的节点数量为o – m。在我们识别数据需要修复和执行实际修复之间避免丢失数据的安全措施是m–k。

请参阅第7.3节,我们如何选择我们的Reed Solomon数。也请参阅第4.14节讨论如何修复数据,因为它的耐久性随着时间的推移而下降。

4.8

结构化文件存储

4.8.1 具有扩展属性的文件

许多应用程序都可以将元数据与文件一起保存。 Amazon S3支持“对象元数据”[60]来满足这种需求。 此功能在许多POSIX兼容系统中称为“扩展属性”,我们在系统中继续使用该名称。 每个文件都将包含一组有限的用户指定键值对(扩展属性),这些键值对将与文件的其他元数据一起存储。

4.8.2 文件分段

先睹为快!STORJ V3 白皮书发布(二)

在我们之前的版本[37]中,术语“碎片”是指存储节点上的碎片,而碎片是指将文件分割成较小的块以便于处理。在我们之前的版本中添加了纠删码之后,这些术语变得有些混乱,因此我们决定用新词区分每个含义。

分片过程现在称为分段,文件数据流的最高级别细分称为段。不巧的是,在文献中使用这些术语存在一般不一致。 GFS将段称为块[26]。 Lustre将段称为条带[28],但我们使用术语Stripe进行进一步的子划分。

文件可能足够小,只包含一个段。如果该段小于将其存储在网络上所需的元数据,则数据将与元数据内联存储3。我们将其称为内联段。

对于较大的文件,数据将分成一个或多个不同的段。以这种方式进行分段在安全性,隐私性,性能和可用性方面提供了许多优点。与其他分布式存储系统[26-28,51,52]一样,对大型文件(例如视频)进行分段并在网络中分发段可以减少内容交付对任何给定节点的影响,因为带宽需求在整个网络中分布更均匀。与我们以前的版本[37]一样,标准化的大小有助于防止某些段内容的丢失,并且可以帮助模糊通过网络的数据流。此外,最终用户可以利用并行传输,类似于BitTorrent [62]或其他对等网络。最后,限制段的大小允许更均匀的存储节点填充。因此,节点只需要足够的空间来存储段以参与网络,并且客户端不需要找到具有足够空间用于大文件的节点。


3Linux文件系统Ext4使用内联inode执行相同的优化[61]

4.8.3 段分带

先睹为快!STORJ V3 白皮书发布(二)

在许多情况下,访问更大数据的子部分非常重要。 某些文件格式(如视频文件或磁盘映像)支持搜索,其中只有一部分数据需要进行读取操作。音频CD的发明者发现,能够解码片段的小部分以支持这些操作是有用的[38]。

为此,带定义了段的子集,并且大小不应超过几千字节。 加密发生在一小部分带上,而纠删码一次发生在一个带上。 由于我们使用经过身份验证的加密,因此每个加密批处理都有轻微的开销,因此首选稍大的加密大小。 但是,当对带进行审计时,我们希望审计使用带宽的量很小。

对于熟悉zfec库的读者,在filefec模式下,zfec将带称为块[42]。

4.8.4 带分为纠删码块

先睹为快!STORJ V3 白皮书发布(二)

如3.4和4.7节所述,纠删码使我们有机会在不可靠的存储节点面前控制网络内数据存储的持久性。

带是我们执行纠删码的大小边界。 在(k,n)纠删码方案中,为每个带生成纠删码块[59]。 例如,可能将带分成40个纠删码块(n = 40),其中需要任何20(k = 20)来重建带。 40个纠删码块中的每一个将是原始带大小的1/20。

一次编码单个带的纠删码允许我们读取大段的一小部分而不首先检索整个段[38]。 它还允许我们将数据流式传输到网络中,而无需事先对其进行分级,并且它还支持许多其他有用的功能。

有关纠删码参数变化如何影响可用性和冗余的细节,请参见第7.3.3节。

4.8.5 纠删码块组成片段

先睹为快!STORJ V3 白皮书发布(二)

因为带已经很小,所以纠删码块通常要小得多,并且分别跟踪所有带的元数据的代价相对于它们的大小而言是巨大的。所有n纠删码块都有一个定义明确的索引。更具体地说,对于固定带和任何给定的n,纠删码的第i个份额将始终相同。与zfec库的filefec模式[42]一样,我们不是单独跟踪所有纠删码块,而是将具有相同索引的所有纠删码块打包成一块。在(k,n)方案中,存在n个片段,其中每个片段i是具有索引i的所有纠删码块的有序串联。结果,在每个纠删码块是条带的1 / k的情况下,每个片段是段的1 / k,并且仅需要k个片段来恢复整个段。片段是我们存储在存储节点上的东西。

每次新的上传开始时,卫星都会生成一个全新的,随机选择的根片段ID。上行链路将保持根片段ID秘密,并将节点特定的片段ID发送到每个存储节点,通过获取根片段ID的基于哈希的消息认证码(HMAC)和节点的ID形成。这用于模糊存储节点中的各个部分。根片ID存储在指针中。

存储节点的命名空间被卫星ID分片。如果一个卫星使用的片段ID被另一个卫星重复使用,则每个卫星可以清楚地知道共享的片段ID指的是与另一个卫星不同的片段,具有不同的内容和生命周期。

4.8.6 指针

数据所有者将需要了解远程段如何被分解以及这些块位于网络中的位置以恢复它。 这包含在指针数据结构中。

指针包括:哪些节点存储片段,加密信息,纠删码细节,确定片段在触发修复之前必须丢失多少冗余的修复阈值,为保证修复成功必须存储的片段数量,以及其他细节。 如果段是内联段,则指针包含整个段的二进制数据,而不是存储块的节点。

在我们之前的版本[37]中,我们使用两种数据结构来跟踪上述类型的信息:帧和指针。 在这个版本中,我们将这些数据结构组合成一个数据结构,并选择将新的组合数据结构称为指针。

未完待续

今天距离深圳线下分享会举行还有3天,详情请见: 深圳线下分享会活动预告

报名链接:

http://www.huodongxing.com/event/1464336840511

先睹为快!STORJ V3 白皮书发布(二)

先睹为快!STORJ V3 白皮书发布(二)

原创文章,作者:点对点资讯,如若转载,请注明出处:https://ipfsdrop.com/news/xianduweikuaistorj-v3-baipishufabuer/

发表评论

电子邮件地址不会被公开。 必填项已用*标注

联系我们

(+86)18301922335

在线咨询:点击这里给我发消息

邮件:haskell@freechains.cn

工作时间:7×24小时

QR code