加载中…
个人资料
币码翁院长凌发明
币码翁院长凌发明
  • 博客等级:
  • 博客积分:0
  • 博客访问:1,356
  • 关注人气:1
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
谁看过这篇博文
加载中…
正文 字体大小:

币码翁区块链研究院翻译IPFS白皮书(中文版)02

(2019-11-01 17:33:38)
标签:

ipfs星际特工

币码翁

凌发明

ipfs

ipfs星际文件

币码翁区块链研究院翻译IPFS白皮书(中文版)01
前面一遍,由币码翁区块链研究院翻译的IPFS白皮书,让我们认知到IPFS星际文件,去中心化分布式存储的价值,下面跟着币码翁翻译继续看下文。

3.5 Merkle DAG对象

DHT和BitSwap允许IPFS构造一个庞大的点对点系统用来快速稳定的分发和存储。最主要的是,IPFS建造了一个Merkle DAG,一个无回路有向图,对象之间的links都是hash加密嵌入在源目标中。这是Git数据结构的一种推广。Merkle DAGS给IPFS提供了很多有用的属性,包括:


  1. 内容可寻址:所有内容都是被多重hash校验和来唯一识别的,包括links。

  2. 防止篡改:所有的内容都用它的校验和来验证。如果数据被篡改或损坏,IPFS会检测到。

  3. 重复数据删除:所有的对象都拥有相同的内容并只存储一次。这对于索引对象非常有用,比如git的tree和commits,或者数据的公共部分。

IPFS对象的格式是:

type IPFSLink struct {
        Name string      // 此link的别名
        Hash Multihash // 目标的加密hash
        Size int             // 目标总大小
  }
type IPFSObject struct {
      links []IPFSLink   //links数组
      data []byte         //不透明内容数据
}

IPFS Merkle DAG是存储数据非常灵活的一种方式。只要求对象引用是(a)内容可寻址的,(b)用上面的格式编码。IPFS允许应用完全的掌控数据域;应用可以使用任何自定义格式的数据,即使数据IPFS都无法理解。单独的内部对象link表允许IPFS做:


  • 用对象的形式列出所有对象引用,例如:


> ipfs ls /XLZ1625Jjn7SubMDgEyeaynFuR84ginqvzb
XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x 189458 less
XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5 19441 script
XLF4hwVHsVuZ78FZK6fozf8Jj9WEURMbCX4 5286 template

  • 解决字符串路经查找,例如foo/bar/baz。给出一个对象,IPFS会解析第一个路经成分进行hash放入到对象的link表中,再获取路径的第二个组成部分,一直如此重复下去。因此,任何数据格式的字符串路经都可以在Merkle DAG中使用。


  • 递归性的解决所有对象引用:

> ipfs refs --recursive 
/XLZ1625Jjn7SubMDgEyeaynFuR84ginqvzb
XLLxhdgJcXzLbtsLRL1twCHA2NrURp4H38s
XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x
XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5
XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z

原始数据结构公共link结构是IPFS构建任意数据结构的必要组成部分。可以很容易看出Git的对象模型是如何套用DAG的。一些其他潜在的数据结构:


  1. 键值存储

  2. 传统关系型数据

  3. 数据三倍存储

  4. 文档发布系统

  5. 通信平台

  6. 加密货币区块


这些系统都可以套用IPFS Merkle DAG,这使这些系统更复杂的应用可以使用IPFS作为传输协议。


3.5.1 路经

IPFS对象可以遍历一个字符串路经。路经格式与传统UNIX文件系统以及Web一致。Merkle DAG的links使遍历变得很容易。全称路经在IPFS中的格式是:


# 格式
/ipfs//


# 例子

/ipfs/XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x/foo.txt


/ipfs前缀允许只要在挂载点不冲突(挂载点名称当然是可配置的)的情况下挂载到一个已存在的系统上。第二个路经组成部分(第一个是IPFS)是一个对象的hash。通常都是这种情况,因为没有全局的根。一个根对象可能会有一个不可能完成的任务,就是在分布式环境(可能还断开链接)中处理百万对象的一致性。因此,我们用地址可寻址来模拟根。通过的hash所有的对象都是可访问的。这意思是说,给一个路经对象/bar/baz,最后一个对象可以可以被所有的访问的:

/ipfs//bar/baz
/ipfs//baz

/ipfs/


3.5.2 本地对象

IPFS客户端需要一个本地存储器,一个外部系统可以为IPFS管理的对象存储以及检索本地原始数据。存储器的类型根据节点使用案例不同而不同。在大多数情况下,这个存储器只是硬盘空间的一部分(不是被本地的文件系统使用键值存储如leveldb来管理,就是直接被IPFS客户端管理),在其他的情况下,例如非持久性缓存,存储器就是RAM的一部分。


最终,所有的块在IPFS中都是能够获取的到的,块都存储在了一些节点的本地存储器中。当用户请求一个对象时,这个对象会被查找到并下载下来存储到本地,至少也是暂时的存储在本地。这为一些可配置时间量提供了快速的查找。


3.5.3 对象锁定

希望确保特定对象生存的节点可以锁定此对象。这保证此特定对象被保存在了节点的本地存储器上。也可以递归的进行锁定所有相关的派生对象。这使所有被指定的对象都保存在本地存储器上。这对长久保存文件特别有用,包括引用。这也同样让IPFS成为一个links是永久的Web,且对象可以确保其他被指定对象的生存。


3.5.4 发布对象

IPFS是全球分布的。它设计为允许成千上万的用户文件可以共同的存在的。DHT使用内容哈希寻址技术,使发布对象是公平的,安全的,完全分布式的。任何人都可以发布对象,只需要将对象的key加入到DHT中,并且以对象是对等节点的方式加入进去,然后把路径给其他的用户。要注意的是,对象本质上是不可改变的,就像在Git中一样。新版本的哈希值不同,因此是新对象。跟踪版本则是额外版本对象的工作。


3.5.5 对象级别的加密

IPFS是具备可以处理对象级别加密操作的。一个已加密的或者已签名的对象包装在一个特殊的框架里,此框架允许加密和验证原始字节。

type EncryptedObject struct {
Object []bytes // 已加密的原始对象数据
Tag []bytes    // 可选择的加密标识
type SignedObject struct {
Object []bytes  // 已签名的原始对象数据
Signature []bytes // HMAC签名
PublicKey []multihash // 多重哈希身份键值
}


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


3.6 文件

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


  1. Block:一个可变大小的数据块

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

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

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


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

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

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

  3. commits嵌入到trees中。


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


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


3.6.1 文件对象:BLOB

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


{
'data': 'some data here',  // blobs无links
}


3.6.2 文件对象: LIST

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


{
'data': ['blob', 'list', 'blob'], //lists有一个对象类型的数组作为数据
'links': [
{ 'hash': 'XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x',
'size': 189458 },
{ 'hash': 'XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5',
'size': 19441 },
{ 'hash': 'XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z',
'size': 5286 } //在links中lists是没有名字的
]

}


3.6.3 文件对象:tree

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


{
'data': ['blob', 'list', 'blob'],//trees有一个对象类型的数组作为数据
'links': [
{ 'hash': 'XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x',
'name': 'less', 'size': 189458 },
{ 'hash': 'XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5',
'name': 'script', 'size': 19441 },
{ 'hash': 'XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z',
'name': 'template', 'size': 5286 }//trees是有名字的
]
}


3.6.4 文件对象:commit

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

币码翁区块链研究院翻译IPFS白皮书(中文版)02

币码翁区块链研究院翻译IPFS白皮书(中文版)02

3.6.5 版本控制

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


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

  1. 构建一个Git工具版本改造成使用IPFS对象图,

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


3.6.6 文件系统路径

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


3.6.7 将文件分隔成Lists和Blob

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

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

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

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


3.6.8路径查找性能

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

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

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


例如,对于上面的ttt111的flattened tree如下:
{
'data':
['tree', 'blob', 'tree', 'list', 'blob' 'blob'],
'links': [
{ 'hash': '', 'size': 1234
'name': 'ttt222-name' },
{ 'hash': '', 'size': 123,
'name': 'ttt222-name/bbb111-name' },
{ 'hash': '', 'size': 3456,
'name': 'ttt333-name' },
{ 'hash': '', 'size': 587,
'name': 'ttt333-name/lll111-name'},
{ 'hash': '', 'size': 22,
'name': 'ttt333-name/lll111-name/bbb222-name' },
{ 'hash': '', 'size': 22
'name': 'bbb222-name' }
] }


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(Inter Planetary的命名空间)分开前缀是在可变和不可变的路径之间建立一个很容易辨认的区别,为了程序也为了人类阅读的便利。

  • 因为这不是一个内容可寻址的对象,所以发布它就要依靠IPFS中的唯一的可变状态分配制度,路由系统。过程是(1)首先把此对象做一个常规的不可变IPFS的对象来发布,(2)将此对象的哈希值作为元数据的值发布到路由系统上:
    routing.setValue(NodeId, )

  • 发布的对象中任何links在命令空间中充当子名称:
    /ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/
    /ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/docs
    /ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/docs/ipfs

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


注意当用户发布一个对象的时候,他不能使用相同的方式来发布对象。


3.7.2 人类友好名称

IPNS的确是一个分配和在分配名称的好方法,但是对用户却不是十分友好的,因为它使用很长的哈希值作为名称,众所周知这样的名称很难被记住。IPNS足够应付URLs,但对于很多线下的传输工作就没有这么好用了。因此,IPFS使用下面的技术来增加IPNS的用户友好度。


对等节点Links

被SFS所鼓舞,用户可以直接将其他用户的对象link到自己的对象上(命令空间,家目录等等)。这有一个好处就是创建了一个可信任的Web(也支持老的真实性认证模型):

# Alice links 到Bob上
ipfs link //friends/bob /
# Eve links 到Alice上
ipfs link /
# Eve 也可以访问Bob
/
# 访问Verisign 认证域
//foo.com

DNS TXT IPNS 记录

如果/ipns/是一个有效的域名称,IPFS会在DNS TXT记录中查找关键的ipns。IPFS会将查找到的值翻译为一个对象的哈希值或者另一个ipns的路径:
# DNS TXT 记录
ipfs.benet.ai. TXT 'ipfs=XLF2ipQ4jD3U ...'
# 表现为符号链接
ln -s /ipns/XLF2ipQ4jD3U /ipns/fs.benet.ai

Proquint 可读的标识符

总是会有将二进制编码翻译成可读文件的方法。IPNS则支持Proquint[?].。如下:
# proquint语句
/ipns/dahih-dolij-sozuk-vosah-luvar-fuluh
# 分解为相应的下面形式
/ipns/KhAwNprxYVxKqpDZ

缩短名称服务

会涌现出很多服务器提供缩短名称的服务,向用户提供他们的命名空间。就像我们现在看到的DNS和Web的URLs:
# 用户可以从下面获取一个link
/ipns/shorten.er/foobar
# 然后放到自己的命名空间

/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm


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实现的目标:

  1. 一个IPFS库可以导出到你自己应用中使用

  2. 命令行工具可以直接操作对象

  3. 使用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,为他之前非常聪明的主意。


原版白皮书链接(需外网):

 

https://ipfs.io/ipfs/QmR7GSQM93Cx5eAg6a6yRzNde1FQv7uL6X1o4k7zrJa3LX/ipfs.draft3.pdf

技术革命,必将是重新分配财富的机遇,IPFS颠覆传统互联网去中心化分布式存储,搭建网络基础建设,必将带来全新的网络架构,更是财富盛宴的商机。币码翁区块链研究院,自主研发,生产,销售,托管为一体的高科技企业,董事长凌发明先生,更是行业知名大咖,专注IPFS布道者,共建IPFS分布式存储。
币码翁区块链研究院翻译IPFS白皮书(中文版)01

0

阅读 评论 收藏 转载 喜欢 打印举报/Report
  • 评论加载中,请稍候...
发评论

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有