IPFS - 星际文件可快速索引的版本化的点对点文件系统

2021-09-17 21:11:47 FIL16888 1302

星际文件系统是一种点对点的分布式文件系统, 旨在连接所有有相同的文件系统的计算机设备。在某些方面, IPFS类似于web, 但web 是中心化的,而IPFS是一个单一的Bittorrent 群集, 用git 仓库分布式存储。换句话说, IPFS 提供了高吞吐量的内容寻址块存储模型, 具有内容寻址的超链接。这形成了一个广义的Merkle DAG 数据结构,可以用这个数据结构构建版本文件系统,区块链,甚至是永久性网站。。IPFS 结合了分布式哈希表, 带有激励机制的块交换和自我认证命名空间。IPFS 没有单故障点, 节点不需要相互信任。

ipfs挖矿-ipfs云算力挖矿-ipfs挖矿云算力-ipfs算力挖矿人人ipfs云算力,swarm,bzz节点挖矿,bzz挖矿,bzz矿机,FIL云算力,filecoin,FIL云矿机,IPFS云算力挖矿

1. 介绍

在全球分布式文件系统这领域, 已经有许多人的尝试。一些系统已经取得了重大的成功, 而很多却完全失败了。在学术尝试中, AFS【6】就是成功的例子,如今已经得到广泛的应用, 然而,其他的【7, ?】却没有得到相同的结果。在学术界之外,应用最广泛的是面向音视频媒体的点对点文件共享系统。 最值得注意的是, Napster, KaZaA 和BitTorrent[2]部署的文件分发系统支持1亿用户的同时在线。即使在今天, BitTorrent 也维持着每天千万节点的活跃数。 基于这些学术文件系统理论而实现的应用程序有很多的用户量, 然而,这些系统理论是在应用层,而没有放在基础层。以致没有出现通用的文件系统基础框架, 给全球提供低延迟的分发。

也许是因为HTTP这样“足够好“的系统已经存在。到目前为止,HTTP已经作为“分布式文件系统“的协议,并且已经大量部署,再与浏览器相结合,具有巨大的技术和社会影响力。在现在, 它已经成为互联网传输文件的事实标准。然而,他没有采用最近15年的发明的数十种先进的文件分发技术。 从一方面讲, 由于向后兼容的限制 和 当前新模式的投入, 不断发展http web 的基础设施几乎是不可能的。但从一个角度看, 从http 出现以来, 已经有许多新协议出现并被广泛使用。升级http协议虽然能引入新功能和加强当前http协议,但会降低用户的体验。

有些行业已经摆脱使用HTTP 这么久, 因为移动小文件相对便宜,即使对拥有大流量的小组织也是如此。但是,随着新的挑战,我们正在进入数据分发的新纪元。


(a)托管和分发PB级数据集,

(b)跨组织的大数据计算,

(c)大批量的高清晰度按需或实时媒体流,

(d)大规模数据集的版本化和链接,

(e)防止意外丢失重要文件等。其中许多可以归结为“大量数据,无处不在”。由于关键功能和带宽问题,我们已经为不同的数据放弃了HTTP 分销协议。下一步是使它们成为web自己的一部分。

正交于有效的数据分发,版本控制系统,已经设法开发重要的数据协作工作流程。Git是分布式源代码版本控制系统,开发了许多有用的方法来建模和实现分布式数据操作。Git工具链提供了灵活的版本控制功能,这正是大量的文件分发系统所严重缺乏的。由Git启发的新解决方案正在出现,如Camlistore [?],个人文件存储系统,Dat [?]数据协作工具链和数据集包管理器。Git已经影响了分布式文件系统设计[9],因为其内容涉及到Merkle DAG数据模型,能够实现强大的文件分发策略。还有待探讨的是,这种数据结构如何影响面向高吞吐量的文件系统的设计,以及如何升级Web本身。

本文介绍了IPFS,一种新颖的对等版本控制的文件系统,旨在调和这些问题。 IPFS综合了许多以前成功的系统的优点。 IPFS产生了突出的效果, 甚至比参考的这些系统的总和还要好。IPFS的核心原则是将所有数据建模为同一Merkle DAG的一部分。

2. 背景

本节回顾了IPFS所采用成功的点对点系统技术的重要属性。

2.1 分布式哈希表(DHT)

分布式散列表(DHT)被广泛用于协调和维护关于对等系统的元数据。比如,MainlineDHT 是一个去中心化哈希表,他可追踪查找所有的对等节点。

2.1.1 KADEMLIA DHT


Kademlia[10] 是受欢迎的DHT, 它提供:

1.通过大量网络进行高效查询:查询平均联系人O(log2N)节点。 (例如,20跳10万个节点的网络)

2.低协调开销:优化数量的控制消息发送到其他节点。

3.抵抗各种攻击,喜欢长寿节点。

4.在对等应用中广泛使用,包括Gnutella和BitTorrent,形成了超过2000万个节点的网络[16]。

2.1.2 CORAL DSHT


虽然一些对等文件系统直接在DHT中存储数据块,这种“数据存储在不需要的节点会乱费存储和带宽”[5]。Coral DSHT扩展了Kademlia三个特别重要的方式:


1.Kademlia在ids为“最近”(使用XOR-distance)的关键节点中存储值。这不考 虑应用程序数据的局部性,忽略“远”可能已经拥有数据的节点,并强制“最近”节点存储它,无论它们是否需要。这浪费了大量的存储和带宽。相反,Coral 存储了地址, 该地址的对等节点可以提供相应的数据块。

2.Coral将DHT API从get_value(key)换成了get_any_values(key)(DSHT中的“sloppy”)中。这仍然是因为Coral用户只需要一个(工作)的对等体,而不是完整的列表。作为回报,Coral可以仅将子集分配到“最近”的节点,避免热点(当密钥变得流行时,重载所有最近的节点)。

3.另外,Coral根据区域和大小组织了一个称为群集的独立DSHT层次结构。这使得节点首先查询其区域中的对等体,“查找附近的数据而不查询远程节点”[5]并大大减少查找的延迟。

2.1.3 S/KADEMLIA DHT


S/Kademlia[1] 扩展了Kademlia, 用于防止恶意的攻击。有如下两方面的方法:

1.S/Kad 提供了方案来保证NodeId的生成已经防止Sybill攻击。它需要节点产生PKI公私钥对。从中导出他们的身份,并彼此间签名。一个方案使用POW工作量证明,使得生成Sybills成本高昂。

2.S/Kad 节点在不相交的路径上查找直, 即使网络中存在大量的不诚实节点,也能确保诚实节点可以互相链接。即使网络中存在一半的不诚实节点,S/Kad 也能达到85%的成功率。

2.2 块交换 - BitTorrent

BitTorrent[3] 是一个广泛成功应用的点对点共享文件系统,它可以在存在不信任的对等节点(群集)的协作网络中分发各自的文件数据片。从BitTorrent和它的生态系统的关键特征, IPFS得到启示如下:

1.BitTorrent的数据交换协议使用了一种bit-for-tat的激励策略, 可以奖励对其他方面做贡献的节点,惩罚只榨取对方资源的节点。

2.BitTorrent对等体跟踪文件的可用性,优先发送稀有片段。这减轻了seeds节点的负担, 让non-seeds节点有能力互相交易。

3.对于一些剥削带宽共享策略, BitTorrent的标准tit-for-tat策略是非常脆弱的。 然而,PropShare[8]是一种不同的对等带宽分配策略, 可以更好的抵制剥削战略, 提高群集的表现。

2.3. 版本控制系统- Git

版本控制系统提供了对随时间变化的文件进行建模的设施,并有效地分发不同的版本。流行版本控制系统Git提供了强大的Merkle DAG对象模型,以分布式友好的方式捕获对文件系统树的更改。

1.不可更改的对象表示文件(blob),目录(树)和更改(提交)。

2.通过加密hash对象的内容,让对象可寻址。

3.链接到其他对象是嵌入的,形成一个Merkle DAG。这提供了很多有用的完整和work-flow属性。

4.很多版本元数据(分支,标示等等)都只是指针引用,因此创建和更新的代价都小。

5.版本改变只是更新引用或者添加对象。

6.分布式版本改变对其他用户而言只是转移对象和更新远程引用。



3. IPFS设计

IPFS是一个分布式文件系统,它综合了以前的对等系统的成功想法,包括DHT,BitTorrent,Git和SFS。 IPFS的贡献是简化,发展和将成熟的技术连接成一个单一的内聚系统,大于其部分的总和。 IPFS提供了编写和部署应用程序的新平台,以及一个新的分发系统版本化大数据IPFS甚至可以演进网络本身。

IPFS是点对点的;没有节点是特权的。 IPFS节点将IPFS对象存储在本地存储中。节点彼此连接并传输对象。这些对象表示文件和其他数据结构。 IPFS协议分为一组负责不同功能的子协议:

1. 身份 - 管理节点身份生成和验证。描述在3.1节。

2.网络 - 管理与其他对等体的连接,使用各种底层网络协议。可配置的。详见3.2节。

3.路由 - 维护信息以定位特定的对等体和对象。响应本地和远程查询。默认为DHT,但可更换。在3.3节描述。

4.交换 - 一种支持有效块分配的新型块交换协议(BitSwap)。模拟市场,弱化数据复制。贸易策略可替换。描述在3.4节。

5.对象 - 具有链接的内容寻址不可更改对象的Merkle DAG。用于表示任意数据结构,例如文件层次和通信系统。详见第3.5节。

6.文件 - 由Git启发的版本化文件系统层次结构。详见3.6节。

7.命名 - 自我认证的可变名称系统。详见3.7节。

这些子系统不是独立的;它们是集成在一起,互相利用各自的属性。但是,分开描述它们是有用的,从下到上构建协议栈。符号:Go语言中指定了以下数据结构和功能


3.1 身份

节点由NodeId标识,这是使用S / Kademlia的静态加密难题[1]创建的公钥的密码散列。节点存储其公私钥(用密码加密)。用户可以在每次启动时自由地设置一个“新”节点身份,尽管这会损失积累的网络利益。激励节点保持不变。


 


首次连接时,对等体交换公钥,并检查:hash(other.PublicKey)等于other.NodeId。如果没有,则连接被终止

关于加密函数的注意事项:

IPFS不是将系统锁定到一组特定的功能选择,而是支持自我描述的值。哈希摘要值以多重哈希格式存储,其包括指定使用的哈希函数的头和以字节为单位的摘要长度。例如:


这允许系统


(a)选择最佳功能用例(例如,更强的安全性与更快的性能),

(b)随着功能选择的变化而演变。自描述值允许兼容使用不同的参数选择。

3.2 网络

IPFS节点与数百个其他节点进行定期通信网络中的节点,可能跨越广域网络。IPFS网络堆栈功能:

传输层: IPFS可以使用任何传输协议,并且最适合WebRTC DataChannels [?](用于浏览器连接)或uTP(LEDBAT [14])。

可靠性: 如果底层网络不提供可靠性,IPFS可使用uTP(LEDBAT [14])或SCTP [15]来提供可靠性。

可连接性:IPFS还可以使用ICE NAT穿墙打洞技术[13]。

完整性:可以使用哈希校验和来检查邮件的完整性。

可验证性:可以使用发送者的公钥使用HMAC来检查消息的真实性。

3.2.1对等节点寻址注意事项:


IPFS可以使用任何网络; 但它不承担对IP的获取以及不直接依赖于ip层。这允许在覆盖网络中使用IPFS

IPFS将地址存储为多层地址,这个多层地址是由字节字符串组成的, 以便于给底层网络使用。多层地址提供了一种方式来表示地址及其协议,可以封装成好解析的格式。例如:


3.3 路由

IPFS节点需要一个路由系统, 这个路由系统可用于查找:


(a)其他同伴的网络地址,

(b)专门用于服务特定对象的对等节点。

IPFS使用基于S / Kademlia和Coral的DSHT,在2.1节中具体介绍过。在对象大小和使用模式方面, IPFS 类似于Coral[5] 和Mainline[16], 因此,IPFS DHT根据其大小对存储的值进行区分。小的值(等于或小于1KB)直接存储在DHT上。对于更大的值,DHT只存储值索引,这个索引就是一个对等节点的NodeId, 该对等节点可以提供對该类型的值的具体服务。

DSHT的接口如下:


3.4块交换 - BitSwap协议

IPFS 中的BitSwap协议受到BitTorrent 的启发,通过对等节点间交换数据块来分发数据的。像BT一样, 每个对等节点在下载的同时不断向其他对等节点上传已下载的数据。和BT协议不同的是, BitSwap 不局限于一个torrent文件中的数据块。BitSwap 协议中存在一个永久的市场。 这个市场包括各个节点想要获取的所有块数据。而不管这些块是哪些如.torrent文件中的一部分。这些快数据可能来自文件系统中完全不相关的文件。 这个市场是由所有的节点组成的。

虽然易货系统的概念意味着可以创建虚拟货币,但这将需要一个全局分类账本来跟踪货币的所有权和转移。这可以实施为BitSwap策略,并将在未来的论文中探讨。

在基本情况下,BitSwap节点必须以块的形式彼此提供直接的值。只有当跨节点的块的分布是互补的时候,各取所需的时候,这才会工作的很好。 通常情况并非如此,在某些情况下,节点必须为自己的块而工作。 在节点没有其对等节点所需的(或根本没有的)情况下,它会更低的优先级去寻找对等节点想要的块。这会激励节点去缓存和传播稀有片段, 即使节点对这些片段不感兴趣。


3.4.1 - BITSWAP 信用


这个协议必须带有激励机制, 去激励节点去seed 其他节点所需要的块,而它们本身是不需要这些块的。 因此, BitSwap的节点很积极去给对端节点发送块,期待获得报酬。但必须防止水蛭攻击(空负载节点从不共享块),一个简单的类似信用的系统解决了这些问题:


1, 对等节点间会追踪他们的平衡(通过字节认证的方式)。

2, 随着债务增加而概率降低,对等者概率的向债务人发送块。

注意的是,如果节点决定不发送到对等体,节点随后忽略对等体的ignore_cooldown超时。 这样可以防止发送者尝试多次发送(洪水攻击) (BitSwap默认是10秒)。

3.4.2 BITSWAP的策略


BitSwap 对等节点采用很多不同的策略,这些策略对整个数据块的交换执行力产生了不同的巨大影响。在BT 中, 标准策略是明确规定的(tit-for-tat),其他不同的策略也已经被实施,从BitTyrant [8](尽可能分享)到BitThief [8](利用一个漏洞,从不共享),到PropShare [8](按比例分享)。BitSwap 对等体可以类似地实现一系列的策略(良好和恶意)。对于功能的选择,应该瞄准:

1.为整个交易和节点最大化交易能力。

2.为了防止空负载节点利用和损害交易。

3.高效抵制未知策略。

4.对可信任的对等节点更宽容。

探索这些策略的空白是未来的事情。在实践中使用的一个选择性功能是sigmoid,根据负债比例进行缩放:

让负债比例在一个节点和它对等节点之间:

BitSwap节点保存了一个记录与所有其他节点之间交易的账本。这个可以让节点追踪历史记录以及避免被篡改。当激活了一个链接,BitSwap节点就会互换它们账本信息。如果这些账本信息并不完全相同,分类账本将会重新初始化, 那些应计信贷和债务会丢失。 恶意节点会有意去失去“这些“账本, 从而期望清除自己的债务。节点是不太可能在失去了应计信托的情况下还能累积足够的债务去授权认证。伙伴节点可以自由的将其视为不当行为, 拒绝交易。

加密操作改变了对象的哈希值,定义一个不同的新的对象。IPFS自动的验证签名以及使用用户指定的钥匙链解密数据。加密数据的links也同样的被保护着,没有解密秘钥就无法遍历对象。也存在着一种现象,可能父对象使用了一个秘钥进行了加密,而子对象使用了另一个秘钥进行加密或者根本没有加密。这可以保证links共享对象安全。


3.6 文件

IPFS在Merkle DAG上还为模型化版本文件系统定义了一组对象。这个对象模型与Git比较相似:

Block:一个可变大小的数据

List:块或者其他链表的集合

Tree:块,链表,或者其他树的集合

Commit:树在版本历史记录中的一个快照

我原本希望使用与Git对象格式一致的模型,但那就必须要分开来引进在分布式文件系统中有用的某些特征,如


(a)快速大小查找(总字节大小已经加入到对象中)

(b)大文件的重复删除(添加到list对象)

(c)commits嵌入到trees中。不过,IPFS文件对象与Git还是非常相近的,两者之间进行交流都是有可能的。而且,Git的一个系列的对象可以被引进过来转换都不会丢失任何的信息。(UNIX文件权限等等)。

标记:下面的文件对象格式使用JSON。注意,虽然IPFS包含了JSON的互相转换,但是文件对象的结构体还是使用protobufs的二进制编码。

3.6.1 文件对象:BLOB

3.6.4 文件对象:COMMIT


IPFS中的commit对象代表任何对象在版本历史记录中的一个快照。与Git中类似,但是它能够表示任何类型的对象。它同样link着发起对象。


3.6.5 版本控制


Commit对象代表着一个对象在历史版本中的一个特定快照。在两个不同的commit中比较对象(和子对象)可以揭露出两个不同版本文件系统的区别。只要commit和它所有子对象的引用是能够被访问的,所有前版本是可获取的,所有文件系统改变的全部历史是可访问的,这就与Merkle DAG对象模型脱离开来了。


Git版本控制工具的所有功能对于IPFS的用户是可用的。对象模型不完全一致,但也是可兼容的。这可能


(a)构建一个Git工具版本改造成使用IPFS对象图,

(b)构建一个挂载FUSE文件系统,挂载一个IPFS的tree作为Git的仓库,把Git文件系统的读/写转换为IPFS的格式。

3.6.6 文件系统路径


如我们在Merkle DAG中看到的一样,IPFS对象可以使用字符串路径API来遍历。IPFS文件对象是特意设计的,为了让挂载IPFS到UNIX文件系统更加简单。文件对象限制trees没有数据,为了使它们可以表示目录。Commits可以以代表目录的形式出现,也可以完全的隐藏在文件系统中。

3.6.7 将文件分隔成LISTS和BLOBS


版本控制和分发大文件其中一个最主要的挑战是:找到一个正确的方法来将它们分隔成独立的块。与其认为IPFS可以为每个不同类型的文件提供正确的分隔方法,不如说IPFS提供了以下的几个可选选择:

就像在LIBFS[?]中一样使用Rabin Fingerprints [?]来选择一个比较合适的块边界。

使用rsync[?] rolling-checksum算法,来检测块在版本之间的改变。

允许用户指定专为特定文件而调整的’快分隔’函数。


3.6.8路径查找性能


基于路径的访问需要遍历对象图。获取每个对象要求在DHT中查找它们的key,连接到对等节点,然后获取它的块。这造成相当大的开销,特别是查找的路径由很多子路径组成时。下面的方法可以减缓开销:


tree缓存:由于所有的对象都是哈希寻址的,它们可以被无限的缓存。另外,trees一般比较小,所以比起blobs,IPFS会优先缓存trees。

flattened trees:对于任何tree,一个特殊的 flattened tree可以构建一个链表,所有对象都可以从这个tree中访问得到。在flattened tree中名字就是一个从原始tree分离的路径,用斜线分隔。

例如,对于上面的ttt111的flattened tree如下:


3.8使用IPFS

IPFS设计为可以使用多种不同的方法来使用的,下面就是一些我将会继续追求的使用方式:


1.作为一个挂载的全局文件系统,挂载在/ipfs和/ipns下

2.作为一个挂载的个人同步文件夹,自动的进行版本管理,发布,以及备份任何的写入

3.作为一个加密的文件或者数据共享系统

4.作为所有软件的版本包管理者

5.作为虚拟机器的根文件系统

6.作为VM的启动文件系统 (在管理程序下)

7.作为一个数据库:应用可以直接将数据写入Merkle DAG数据模型中,获取所有的版本,缓冲,以及IPFS提供的分配

8.作为一个linked(和加密的)通信平台

9.作为一个为大文件的完整性检查CDN(不使用SSL的情况下)

10.作为一个加密的CDN

11.在网页上,作为一个web CDN

12.作为一个links永远存在新的永恒的Web

IPFS实现的目标:

(a)一个IPFS库可以导出到你自己应用中使用

(b)命令行工具可以直接操作对象

(c)使用FUSE[?]或者内核的模型挂载文件系统

4. 未来

IPFS的思想是几十年成功的分布式系统的探索和开源的产物。IPFS综合了很多迄今为止很成功的系统中优秀的思想。除了BitSwap新协议之外,IPFS最大的特色就是系统的耦合以及设计的综合性。

IPFS是去中心化网络基础设施的一个野心设想,很多不同类型的应用都可以建立在IPFS上。最低限度,它可以用来作为一个全局的,挂载性,版本控制文件系统和命名空间,或者作为下一代的文件共享系统。而最好的情况是,IPFS可以让Web升级一个层次,当发布一个有价值的信息时,任何感兴趣的人都可以进行发布而不会强迫性的必须只允许发布机构进行发布,用户可以信任信息的内容,信不信任信息的发送者都是无关紧要的,还有一个特点就是,一些重要但很老的文件也不会丢失。IPFS期待着带我们进入到一个永恒Wdb的世界。

5. 感谢

IPFS是一个很多很棒的主意以及系统的综合体。没有站在巨人的肩膀上,IPFS也不可能敢于有一个这么有野心的目标。个人感谢参与这些主意长期讨论的人:David Dalrymple, Joe Zimmerman, and Ali Yahya,特别是:揭开Merkle DAG的总体架构(David, Joe),滚动哈希阻塞(David), s/kademlia sybill 保护(David, Ali),特别感谢David Mazieres,为他之前非常聪明的主意。




首页
产品
新闻
联系