区块链
挖矿,比特币,EOS,以太坊

IPFS开发教程 – 可快速索引的版本化的点对点文件系统(3)

221

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
blob对象代表一个文件且包含一个可寻址的数据单元,IPFS的blobs就像Git的blobs或者文件系统数据块。它们存储用户的数据。需要留意的是IPFS文件可以使用lists或者blobs来表示。Blobs没有links。

3.6.2 文件对象: LIST

List对象代表着由几个IPFS的blobs连接成的大文件或者重复数据删除文件。Lists包含着有序的blob序列或list对象。从某种程度上而言,IPFS的list函数就像一个间接块的文件系统。
由于lists可以包含其他的lists,那么包含linked的链表和平衡树的拓扑结构是有可能的。有向图中相同的节点出现在多个不同地方允许在文件中重复数据删除。当然,循环是不可以能的,因为是被哈希寻址强制实行的。

3.6.3 文件对象:TREE
IPFS中的tree对象与Git中相似,它代表着一个目录,一个名字到哈希值的映射。哈希值则表示着blobs,lists,其他的trees,或者commits。注意,传统路径的命名早已经被Merkle DAG实现了。

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.7 IPNS:命名以及易变状态
目前为止,IPFS桟形成了一个对等块交换组成一个内容可寻址的DAG对象。这提供了发布和获取不可改变的对象。这甚至可以跟踪这些对象的版本历史记录。但是,这里有一个关键成分遗漏了:易变的命名。没有这个,发送IPFS的links,所有新内容的通信肯定都会有所偏差。现在所需就是能有某些方法可以获取相同路径的的易变状态。
这值得详述原因—如果最终易变数据是必须的—我们费了很大的力气构建了一个不可改变的Merkle DAG。就当做IPFS脱离了Merkle DAG的特征:
对象可以(a)通过哈希值可以获取(b)完整性的检查(c)link其他的对象(d)无限缓存。从某种意义上说:
对象就是永恒的

这些就是一个高性能分布式系统的关键特征,在此系统上跨网络links之间移动文件是非常昂贵的。对象内容可寻址构建了一个具有以下特点的Web,(a)优秀的宽带优化(b)不受信任的内容服务(c)永恒的links(d)能够永久备任何对象以及它的引用。
不可变的内容可寻址对象和命名的Merkle DAG, 可变指针指向Merkle DAG,实例化了一个出现在很多成功分布式系统中的二分法。这些系统包括Git的版本控制系统,使用不可变的对象和可变的引用;还有UNIX分布式的继承者Plan9[?]文件系统,使用可变的Fossil和不可变的Venti[?]。LBFS[?]同样使用可变的索引以及不可变的块。

3.7.1 自我认证名称
使用SFS[12,11]中的命名方案,给我们提供了一个种可以构建自我认证名称的方法,
在一个加密指定的全局命名空间中,这是可变的。IPFS的方案如下:1.回想一下在IPFS中:NodeId = hash(node.PubKey)2.我们给每个用户分配一个可变的命名空间,在此路径下:/ipns/
3.一个用户可以在此路径下发布一个用自己私钥签名的对象,比如说:/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/4.当其他用户获取对象时,他们可以检测签名是否与公钥和NodeId匹配。这个验证了用户发布对象的真实性,达到了可变状态的获取。
注意下面的细节:IPNS(InterPlanetary的命名空间)分开前缀是在可变和不可变的路径之间建立一个很容易辨认的区别,为了程序也为了人类阅读的便利。
因为这不是一个内容可寻址的对象,所以发布它就要依靠IPFS中的唯一的可变状态分配制度,路由系统。过程是(a)首先把此对象做一个常规的不可变IPFS的对象来发布(b)将此对象的哈希值作为元数据的值发布到路由系统上:

发布的对象中任何links在命令空间中充当子名称:

一般建议发布一个commit对象或者其他对象的时候,要使用历史版本记录,因为这样就用户就可以找到之前使用过的名字。不过由于这并不总是需要的,所以留个用户自己选择。
注意当用户发布一个对象的时候,他不能使用相同的方式来发布对象。

3.7.2人类友好名称
IPNS的确是一个分配和在分配名称的好方法,但是对用户却不是十分友好的,因为它使用很长的哈希值作为名称,众所周知这样的名称很难被记住。IPNS足够应付URLs,但对于很多线下的传输工作就没有这么好用了。因此,IPFS使用下面的技术来增加IPNS的用户友好度。
对等节点Links
被SFS所鼓舞,用户可以直接将其他用户的对象link到自己的对象上(命令空间,家目录等等)。这有一个好处就是创建了一个可信任的Web(也支持老的真实性认证模型):


DNS TXT IPNS 记录
如果/ipns/是一个有效的域名称,IPFS会在DNS TXT记录中查找关键的ipns。IPFS会将查找到的值翻译为一个对象的哈希值或者另一个ipns的路径:


Proquint 可读的标识符
总是会有将二进制编码翻译成可读文件的方法。IPNS则支持Proquint[?].。如下:


缩短名称服务
会涌现出很多服务器提供缩短名称的服务,向用户提供他们的命名空间。就像我们现在看到的DNS和Web的URLs:

3.8使用IPFS
IPFS设计为可以使用多种不同的方法来使用的,下面就是一些我将会继续追求的使用方式:
1.作为一个挂载的全局文件系统,挂载在/ipfs和/ipns下2.作为一个挂载的个人同步文件夹,自动的进行版本管理,发布,以及备份任何的写入3.作为一个加密的文件或者数据共享系统4.作为所有软件的版本包管理者5.作为虚拟机器的根文件系统6.作为VM的启动文件系统 (在管理程序下)7.作为一个数据库:应用可以直接将数据写入Merkle DAG数据模型中,获取所有的版本,缓冲,以及IPFS提供的分配8.作为一个linked(和加密的)通信平台9.作为一个为大文件的完整性检查CDN(不使用SSL的情况下)10.作为一个加密的CDN11.在网页上,作为一个web CDN12.作为一个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,为他之前非常聪明的主意。

6.引用备忘录

7.引用
[1].I. Baumgart and S. Mies. S/kademlia:一个安全的基于秘钥路由的可行方法。2007年国际会议,第2卷,1-8页,在《并发和分布式系统》中。IEEE,2007年。
[2].I. BitTorrent.Bittorrent和Attorrent软件超过1亿5000万用户里程碑,Jan。2012
[3].B. Cohen.激励机制在bittorrent中建立了健壮性。在《对等系统经济研讨会》中,第6卷,68-72页,2003年。
[4].J. Dean and S. Ghemawat. Leveldb – 一个快速和轻量级键值存储数据库,谷歌提供,2011年。
[5].M. J. Freedman, E. Freudenthal, and D. Mazieres. Coral民主内容发布。在NSDI中,第4卷,18-18页,2004年。
[6].J. H. Howard, M. L. Kazar, S. G. Menees, D. A,Nichols, M. Satyanarayanan, R. N. Sidebotham, 以及M. J. West.分布式文件系统的规模和性能。“ACM 电脑系统上的交易 (TOCS)” 6(1):51-81, 1988年

赞(0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址