IPLD是什么
IPLD是内容可寻址web的数据模型。它允许我们将所有散列连接的数据结构视为统一信息空间的子集，将所有将数据与散列连接的数据模型统一为IPLD实例。
IPLD数据模型定义了一种简单的，适用于所有merkle-dags，基于JSON的结构。同时也定义了一系列编码的格式结构。
目前系统的问题
在分布式系统中，通过使用加密哈希来定位内容已经成为了广泛使用的方法。 从区块链到加密数字货币到网页，这中间的数据是庞大的。然而，尽管所有这些工具都依赖于一些常见的原语，但是它们的特定底层数据结构是不可互操作的。
IPLD是所有受哈希启发的协议的一个名称空间。通过IPLD，可以跨协议遍历链接，允许您探索数据，而不管底层协议是什么。
IPLD如何解决了这些问题
IPLD定义了一系列规范来让基于内容寻址，加密hash的分布式系统中的数据变的具有互操作行。
它具有如下特点
- 规范化数据模型
一个自包含的描述性模型，惟一地标识任何基于哈希的数据结构，并确保相同的逻辑对象总是映射到相同的位序列。
- 协议独立
IPLD将独立的系统组合在一起，使与现有协议的集成变得简单。
- 可升级
有了多格式（multiformat）支持，IPLD很容易升级，并将随着您喜欢的协议而增长。
- 跨格式的互操作
以各种可序列化的格式表示IPLD对象，如JSON、CBOR、YAML、XML等，使IPLD在任何框架中都易于使用。
- 向后兼容的
非侵入性解析器使IPLD易于集成到现有工作中。
- 所有协议的名称空间
IPLD允许您通过一个公共名称空间，通过协议无缝地跨协议探索数据，结合基于哈希的数据结构。
IPLD结构和组成
一些核心术语和组成
merkle-links: merkle-graph的核心单位
merkle-dag： 默克尔DAG: 任何边为merkle-links的有向无环图
merkle-paths: unix风格的路径便于遍历 merkle-dag
IPLD Data Model:一种灵活的、基于JSON的数据模型，用于表示merkle-dags.
IPLD Serialized Formats：序列化模型，一系列IPLD对象可以使用的格式, 例如 JSON, CBOR, CSON, YAML, Protobuf, XML, RDF, etc.
可见，IPLD 是多个由默克尔链接组成的dag图的一种数据模型。
IPLD协议的其他关联部分协议
[图片上传失败...(image-659b3f-1533192576398)]
可以看出，有一些协议还在修订中
一些关键概念
什么是默克尔链接（merkle-link）
一个merkle-link是链接两个对象的方式。目标对象和源对象都使用加密Hash的内容寻址。同时，目标对象的hash也会嵌入到源对象中。包含merkle-links的内容寻址可以做到：
加密完整性检查：解析链接的值可以通过Hash来测试。 这样一来可以实现广泛的，安全的，不受信任的数据交换（例如git或bittorrent），因为其他人不能给你任何不通过Hash链接到的数据。
不可变数据结构：带有merkle链接的数据结构不能改变，这对于分布式系统来说是一个重要的属性。 这对于版本控制，表示分布式可变状态（例如CRDT）和长期归档很有用。
一个merkle-link通过如下的IPLD对象模型表示：一个包含 / 映射到一个 “映射值”（“link value”），例如： 一个链接，在json中可以表示为一个“链接对象”（“link object”）。
{
"/" : "/ipfs/QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k"
}
// "/" 是一个链接key
// "/ipfs/QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k" 是一个链接值
一个在foo/baz有链接的对象：
{
"foo": {
"bar": "/ipfs/QmUmg7BZC1YP1ca66rRtWKxp77WgVHrnv263JtDuvs2k", // 不是一个链接
"baz":
{"/": "/ipfs/QmUmg7BZC11ca66rRtWKxpXp77WgVHrnv263JtDuvs2k"}
// 是一个链接
}
}
一下结构中又一个 有一个伪”链接对象” 在 files/cat.jpg ，而实际的链接在 files/cat.jpg/link
{
"files": {
"cat.jpg": { // 链接的属性包含在其他对象中
"link": {
"/": "/ipfs/QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k"},
"mode": 0755,
"owner": "jbenet"
}
}
}
当链接被修改时，映射本身将被其指向的对象替换，除非链接路径无效。
这个链接可以是multihash, 也就是说它假设这个链接是在 /ipfs 层级下的，或者是对象的绝对路径。但目前只有 /ipfs 层级路径可以使用。 如果应用需要使用 /表示其他内容，那么应用自身需要保证解析的时候不冲突。
merkle-graph和merkle-dag
具有merkle-link的对象形成一个有方向的图叫Merkle-graph
merkle-path是什么
一个merkle-path是一个unix风格的路径(e.g. /a/b/c/d)，它可以实现通过merkle-link遍历，并且获得所有的对象。 通用的文件系统可以被设计成在IPFS之上的对象模型，设计特定的算法来实现数据对象的操作和查询。
工作原理
一个merkle-path是一种unix风格的路径，它依据路径遍历，同时也逐步解析循内容。解析内容意味着获得merkle-link的内容，再进一步解析。例如，假设我们有如下merkle-path:
/ipfs/QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k/a/b/c/d
其中:
ipfs 是协议的命名空间。
QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k 是一个加密哈希值
a/b/c/d 是一个可遍历的unix路径 由 /表示的可遍历的路径 ，可以表示两种链接： 在同一对象内部遍历数据 依据merkle-link实现对象间的信息遍历
例如
> ipfs object cat --fmt=yaml QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k
---
a:
b:
link:
/: QmV76pUdAAukxEHt9Wp2xwyTpiCmzJCvjnMxyQBreaUeKT
c: "d"
foo:
/: QmQmkZPNPoRkPd7wj2xUJe5v5DsY6MX33MFaGhZKB2pRSE
> ipfs object cat --fmt=yaml QmV76pUdAAukxEHt9Wp2xwyTpiCmzJCvjnMxyQBreaUeKT
---
c: "e"
d:
e: "f"
foo:
name: "second foo"
> ipfs object cat --fmt=yaml QmQmkZPNPoRkPd7wj2xUJe5v5DsY6MX33MFaGhZKB2pRSE
---
name: "third foo"
假设有如下paths:
/ipfs/QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k/a/b/c 只会遍历第一个对象，得到字符串 d. /ipfs/QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k/a/b/link/c 会遍历两个对象，得到字符串 e /ipfs/QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k/a/b/link/d/e 会遍历两个对象，得到字符串 f /ipfs/QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k/a/b/link/foo/name 会遍历第一个，第二个对象，得到字符串 second foo /ipfs/QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k/a/b/foo/name 会遍历第一个，第二个对象，得到字符串 third foo
IPLD限制和愿景
有如下限制：
1. IPLD 路径必须是明确无误的，任意给定的路径遍历的方式必须是恒定的（e.g.避免链接命名冲突）
2.IPLD 路径必须是全局的，同时也要支持其他语言(e.g. 使用 UTF-8,而不是ASCII).
3. IPLD 路径必须是在UNIX和Web之上的层级 (使用 /, 在ASCII 系统内转变必须是确定的 ). 鉴于JSON的成功, 很多系统都支持JSON 接口.
4.IPLD 必须具有支持JSON格式的导入导出能力 JSON数据模型也是简单而且易于使用的。5.IPLD 也必须要易于使用。 可以让定义数据的操作变得很简单。在IPLD之上定义新的数据结构不需要具有很多背景知识 由于IPLD 是基于JSON数据模型的， 它应该通过JSON-LD与RDF及 Linked Data standards 兼容 IPLD序列化格式(在磁盘上，传输中)都需要快速和空间有效 (不能用JSON格式存储, 而是应该用CBOR或其他格式) IPLD 加密哈希散列必须可升级 (使用multihash)
如下特性是加分项:
1. IPLD不应该包含错误的数据，e.g. 存储不完整的JSON.
2..IPLD 应该可升级, e.g. 如果一种更好的在磁盘上存储的格式出现了，系统应该可以只要花费很小的代价就升级 IPLD 对象应该可以可以解析属性，而不仅仅是 merkle links.
3. IPLD 事先定义的格式应该容易实现和转化 IPLD 事先定义的格式应该在不获得整个对象的情况下也可以搜索(CBOR 和 Protobuf 已经可以做到).
参考链接
https://ipld.io/
https://github.com/ipld/specs/blob/master/IPLD.md
联系微信：bitwiki