➡ 繁

IPFS(星际文件系统)中文白皮书

IPFS - 可快速索引的版本化的点对点文件系统(草案3)

作者: Juan Benet ([email protected])
译者: 郭光华([email protected])

摘要

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

1. 介绍

在全球分布式文件系统这领域, 已经有许多人的尝试。一些系统已经取得了重大的成功, 而很多却完全失败了。在学术尝试中, AFS【6】就是成功的例子,如今已经得到广泛的应用, 然而,其他的【7, ?】却没有得到相同的结果。在学术界之外,应用最广泛的是面向音视频媒体的点对点文件共享系统。 最值得注意的是, Napster, KaZaA 和BitTorrent[2]部署的文件分发系统支持1亿用户的同时在线。即使在今天, BitTorrent 也维持着每天千万节点的活跃数。 基于这些学术文件系统理论而实现的应用程序有很多的用户量, 然而,这些系统理论是在应用层,而没有放在基础层。以致没有出现通用的文件系统基础框架, 给全球提供低延迟的分发。
也许是因为HTTP这样“足够好“的系统已经存在。到目前为止,HTTP已经作为“分布式文件系统“的协议,并且已经大量部署,再与浏览器相结合,具有巨大的技术和社会影响力。在现在, 它已经成为互联网传输文件的事实标准。然而,他没有采用最近15年的发明的数十种先进的文件分发技术。 从一方面讲, 由于向后兼容的限制 和 当前新模式的投入, 不断发展http web 的基础设施几乎是不可能的。但从一个角度看, 从http 出现以来, 已经有许多新协议出现并被广泛使用。升级http协议虽然能引入新功能和加强当前http协议,但会降低用户的体验。
有些行业已经摆脱使用HTTP 这么久, 因为移动小文件相对便宜,即使对拥有大流量的小组织也是如此。但是,随着新的挑战,我们正在进入数据分发的新纪元。

2. 背景

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

### [](#2-1-分布式哈希表-DHT "2.1 分布式哈希表(DHT)")2.1 分布式哈希表(DHT)

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

#### [](#2-1-1-Kademlia-DHT "2.1.1 Kademlia DHT")2.1.1 Kademlia DHT

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

2.1.2 Coral DSHT

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

2.1.3 S/Kademlia DHT

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

2.2 块交换 - BitTorrent

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

2.3 版本控制系统- Git

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

2.4 自我认证认文件系统-SFS

SFS [ 12,11 ]提出了两个引人注目的实现(a)分布式信任链,和(b)平等共享的全局命名空间。SFS引入了一种自我建构技术—注册文件:寻址远程文件系统使用以下格式:

    /sfs/
:

    
    Location:代表的是服务网络地方
    
    HostID = hash(public_key || Location)

因此SFS文件系统的名字认证了它的服务,用户可以通过服务提供的公钥来验证,协商一个共享的私钥,保证所有的通信。所有的SFS实例都共享了一个全局的命名空间,这个命名空间的名称分配是加密的,不被任何中心化的body控制。

3. IPFS设计

IPFS是一个分布式文件系统,它综合了以前的对等系统的成功想法,包括DHT,BitTorrent,Git和SFS。 IPFS的贡献是简化,发展和将成熟的技术连接成一个单一的内聚系统,大于其部分的总和。 IPFS提供了编写和部署应用程序的新平台,以及一个新的分发系统版本化大数据。 IPFS甚至可以演进网络本身。
IPFS是点对点的;没有节点是特权的。 IPFS节点将IPFS对象存储在本地存储中。节点彼此连接并传输对象。这些对象表示文件和其他数据结构。 IPFS协议分为一组负责不同功能的子协议:
1. 身份 - 管理节点身份生成和验证。描述在3.1节。
2.网络 - 管理与其他对等体的连接,使用各种底层网络协议。可配置的。详见3.2节。
3.路由 - 维护信息以定位特定的对等体和对象。响应本地和远程查询。默认为DH​​T,但可更换。在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]创建的公钥的密码散列。节点存储其公私钥(用密码加密)。用户可以在每次启动时自由地设置一个“新”节点身份,尽管这会损失积累的网络利益。激励节点保持不变。

 type NodeId Multihash
 type Multihash \[\]byte  // 自描述加密哈希摘要
 type PublicKey \[\]byte
 type PrivateKey \[\]byte // 自描述的私钥
 type Node struct {
     NodeId NodeID
     PubKey PublicKey
     PriKey PrivateKey
 }

基于S / Kademlia的IPFS身份生成:

difficulty = 

n = Node{}
do {
    n.PubKey, n.PrivKey = PKI.genKeyPair()
    n.NodeId = hash(n.PubKey)
    p = count\_preceding\_zero_bits(hash(n.NodeId))
} while (p < difficulty)

首次连接时,对等体交换公钥,并检查:hash(other.PublicKey)等于other.NodeId。如果没有,则连接被终止
关于加密函数的注意事项:
IPFS不是将系统锁定到一组特定的功能选择,而是支持自我描述的值。哈希摘要值以多重哈希格式存储,其包括指定使用的哈希函数的头和以字节为单位的摘要长度。例如:





这允许系统

3.2 网络

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

    \# an SCTP/IPv4 connection
    
    /ip4/10.20.30.40/sctp/1234/
    
    \# an SCTP/IPv4 connection proxied over TCP/IPv4
    
    /ip4/5.6.7.8/tcp/5678/ip4/1.2.3.4/sctp/1234/

3.3 路由

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

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

DSHT的接口如下:

type IPFSRouting interface {
	FindPeer(node NodeId) // 获取特定NodeId的网络地址。
	SetValue(key \[\]bytes, value \[\]bytes) // 往DHT存储一个小的元数据。
	GetValue(key \[\]bytes) // 从DHT获取元数据。
	ProvideValue(key Multihash) // 声明这个节点可一个提供一个大的数据。
	FindValuePeers(key Multihash, min int) // 获取服务于该大数据的节点。
}

注意:不同的用例将要求基本不同的路由系统(例如广域网中使用DHT,局域网中使用静态HT)。因此,IPFS路由系统可以根据用户的需求替换的。只要使用上面的接口就可以了,系统都能继续正常运行。

3.4 块交换 - BitSwap协议

IPFS 中的BitSwap协议受到BitTorrent 的启发,通过对等节点间交换数据块来分发数据的。像BT一样, 每个对等节点在下载的同时不断向其他对等节点上传已下载的数据。和BT协议不同的是, BitSwap 不局限于一个torrent文件中的数据块。BitSwap 协议中存在一个永久的市场。 这个市场包括各个节点想要获取的所有块数据。而不管这些块是哪些如.torrent文件中的一部分。这些快数据可能来自文件系统中完全不相关的文件。 这个市场是由所有的节点组成的。
虽然易货系统的概念意味着可以创建虚拟货币,但这将需要一个全局分类账本来跟踪货币的所有权和转移。这可以实施为BitSwap策略,并将在未来的论文中探讨。
在基本情况下,BitSwap节点必须以块的形式彼此提供直接的值。只有当跨节点的块的分布是互补的时候,各取所需的时候,这才会工作的很好。 通常情况并非如此,在某些情况下,节点必须为自己的块而工作。 在节点没有其对等节点所需的(或根本没有的)情况下,它会更低的优先级去寻找对等节点想要的块。这会激励节点去缓存和传播稀有片段, 即使节点对这些片段不感兴趣。

3.4.1 BitSwap 信用

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

3.4.2 BitSwap的策略

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

根据r,发送到负债节点的概率为:

P(send | r ) = 1 − ( 1/  ( 1 + exp(6 − 3r) ) )

正如你看到的图片1,当节点负债比例超过节点已建立信贷的两倍,发送到负债节点的概率就会急速下降。

当r增加时发送的概率

图1 当r增加时发送的概率

负债比是信任的衡量标准:对于之前成功的互换过很多数据的节点会宽容债务,而对不信任不了解的节点会严格很多。这个(a)给与那些创造很多节点的攻击者(sybill 攻击)一个障碍。(b)保护了之前成功交易节点之间的关系,即使这个节点暂时无法提供数据。(c)最终阻塞那些关系已经恶化的节点之间的通信,直到他们被再次证明。

3.4.3 BitSwap 账本

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

type Ledger struct {

    owner NodeId

    partner NodeId

    bytes_sent int

    bytes_recv int

    timestamp Timestamp

}

节点可以自由的保留分布式账本历史,这不需要正确的操作,因为只有当前的分类账本条目是有用的。节点也可以根据需要自由收集分布式帐本,从不太有用的分布式帐开始:老(其他对等节点可能不存在)和小。

3.4.4 BitSwap 详解

BitSwap 节点有以下简单的协议。

// Additional state kept
type BitSwap struct {
	ledgers map\[NodeId\]Ledger // Ledgers known to this node, inc inactive
	active map\[NodeId\]Peer // currently open connections to other nodes
	need_list \[\]Multihash // checksums of blocks this node needs
	have_list \[\]Multihash // checksums of blocks this node has
}

type Peer struct {
	nodeid NodeId
	ledger Ledger // Ledger between the node and this peer
	last_seen Timestamp // timestamp of last received message
	want_list \[\]Multihash // checksums of all blocks wanted by peer 
	// includes blocks wanted by peer's peers
}

// Protocol interface:
interface Peer {
	open (nodeid : NodeId, ledger : Ledger);
	send\_want\_list (want_list : WantList);
	send_block(block: Block) -> (complete:Bool);
	close(final: Bool);
}

对等连接的生命周期草图:

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
    

 
 

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

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

这些系统都可以套用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比较相似:
Block:一个可变大小的数据块
List:块或者其他链表的集合
Tree:块,链表,或者其他树的集合
Commit:树在版本历史记录中的一个快照
我原本希望使用与Git对象格式一致的模型,但那就必须要分开来引进在分布式文件系统中有用的某些特征,如

标记:下面的文件对象格式使用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着发起对象。

3.6.5 版本控制

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

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,连接到对等节点,然后获取它的块。这造成相当大的开销,特别是查找的路径由很多子路径组成时。下面的方法可以减缓开销:

{
	"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的特征:对象可以

不可变的内容可寻址对象和命名的Merkle DAG, 可变指针指向Merkle DAG,实例化了一个出现在很多成功分布式系统中的二分法。这些系统包括Git的版本控制系统,使用不可变的对象和可变的引用;还有UNIX分布式的继承者Plan9[?]文件系统,使用可变的Fossil和不可变的Venti[?]。LBFS[?]同样使用可变的索引以及不可变的块。

3.7.1 自我认证名称

使用SFS[12,11]中的命名方案,给我们提供了一个种可以构建自我认证名称的方法,在一个加密指定的全局命名空间中,这是可变的。

IPFS的方案如下:

注意下面的细节:

routing.setValue(NodeId, 
)
/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/
/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/docs
/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/docs/ipfs

3.7.2人类友好名称

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

# Alice links 到Bob上
ipfs link /
/friends/bob /

# Eve links 到Alice上
ipfs link /