IPFS与数据结构
[TOC]
在开始编码前，我们花几分钟看看在Web去中心化下几个重要概念。
与其他教程不同，本教程不涉及代码、只是介绍几个相关的重要概念。
Let's get started!
什么是数据结构?
无论你是否是一个程序员，任何时候都是被数据结构所围绕。
如列表、字典、目录这些都帮助我们组织信息、体现不同数据碎片之间的关联关系。
From Wikipedia:
在计算机领域，数据结构是数据的组织、管理、存储格式。
目的是为了便于有效访问和修改数据。
更准确说，一个数据结构是一组数据值集合。
同时数据结构还体现了这组数据值之间的关系以及使用这组数据值的相关函数或操作方法。
In computer science, a data structure is a data organization, management and storage format that enables efficient access and modification. More precisely, a data structure is a collection of data values, the relationships among them, and the functions or operations that can be applied to the data.
软件开发中，数据结构无所不在，每当把数据绑定给变量、在程序中使用这些变量就意味着你其实是在使用各式各样的数据结构。
如果你是一个开发人员，那么你对通用数据结构如数组、对象、图形等应该非常熟悉。
去中心化数据结构
在去中心化web世界中，我们访问的数据来自与我们同等的个体、并非来自某个权威数据中心，这时候我们需要一种特殊数据结构：
- 能够支持我们对数据执行验证；
- 同时支持我们可以链接不同内容碎片；
去中心化web世界中的数据结构需要在被分享的同时可以被验证。
比如对于自己的笔记本系统，我们能够对笔记本内存或磁盘上的这种数据结构具有更高级别的信任！
然而，在去中心化的web世界中，对于来自与我们同等的个体(网络中的其他计算机)的数据结构，我们仅有有限信任甚至根本就是零信任。所以去中心化web世界的数据结构需要可以被验证。
去中心化web世界中的大型数据结构需要在网络世界中被分享的同时需要具有数据链接能力，如同Web链接可以把不同网页链接在一起，去中心化的web数据结构同样需要支持类似Web方式的数据链接。
中心化web : 基于位置定位数据
在我们讲解web去中心化之前，让我们花点时间了解一下web中心化的世界中数据访问惯例。
通过URLs定位内容
- 中心化web世界中，通过
URLs(Uniform Resource Locators) 定位数据。 - 数据通过创建链接的方式在web中连通。
- 如果没有链接，web世界简直是无法想象。
中心化web世界中，URLs用于定位数据所在的位置、而非是通过数据内容本身来定位数据。
所以我们称之为：基于位置寻址(location addressing)。
这种位置定位数据的方式实际上存在一定问题。
我们大家对URLs比较熟悉，我们总是按照自己的经验来假定URLs。https://www.puppies.com/beagle.jpg对于我们而言，我们通常按照这个URLs的语义去猜测它代表着一个JPEG格式的比格犬图片。
然而我们无法通过对这个URLs执行验证：数据是否真如我们猜想的那么。
实际结果完全可能是一个吉娃娃甚至可能是一只猫。
尽管URLs中包含的域名表示一个URL是一个权威性中心、我们可以从中访问并获取数据，然而这个链接所引用的数据是通过位置寻址(location addressing)的。即使现在的web世界已经有了去中心化Web的一些特点，但这种URL链接依然是位置寻址。
通过位置寻址的数据必然需要依赖某个数据中心，所以我们可能会认为在puppies.com上托管的文件比在evilhacker.com上托管的文件更安全，但事实上并非如此。
:loudspeaker: 位置寻址最终导致：某个中心所托管的一个文件内容与这个文件的URLs 没有任何直接关联。
中心化web的可信性和效率问题
在web中心化世界中，由于我们无法验证一个URLs 实际对应的内容(数据)，我们非常容易被用心不良者所捉弄。
而且，同一个比格犬图片完全可能以不同文件名称存储在不同域名上。当我们下载明明是同一个文件时会得到类似download.pdf 和 download(01).pdf的不同文件、而事实上就是同一个文件，但我们却无法下载时分辨。
Web世界中充斥着大量被重复托管的数据、因为只要使用不同的URLs就可以重复托管。
而且没有一种简洁方法可以识别这些重复托管数据，这无疑降低了数据的使用效率。
必须有更好的方式解决数据可信性和数据唯一性问题。
去中心化 web: 基于数据内容定位
正如我们已经看到的：
- 中心化的web世界中，我们依靠"值得信任"的中心来存储数据、依靠
URL定位数据。 - 这种方式下，数据的可信度和重复数据的导致的低效一直是存在的问题。
而在去中心化的web世界中，将解决上述问题：
所有的数据是由我们个体之间彼此存储、同时通过另一种方式的链接可以确保数据安全、使得我们对数据的信任度达到我们生活中对自己邻居的可信度。
哈希加密
哈希加密(Cryptographic hashing) 是去中心化数据结构工具箱中的最重要工具。
它使得我们可以通过一种崭新链接方式定位数据。
称之为基于内容寻址的链接。使得我们彻底从中心化数据储存中解放了出来。
任意类型、任意大小的数据都可以通过哈希算法得到一个唯一的固定大小的哈希值。
一个哈希值是一个看似是胡言乱语的字符串，但是却可以作为某个数据的唯一标记。
一个哈希值类似如下：
zdpuAsHkamdCQgrDrNSwJVgjMkQWoLxdrccxV6qe9htipNein
复制代码实话说，这样的哈希值对于我们而言不再具有描述性、然而却是更安全的。
为什么这样说？
- 哈希值源自于数据本身。这意味着同一个数据如果使用同样的哈希算法，那么哈希值是一致的。这确保了数据的唯一性，可以避免了数据的重复。
- 哈希值具有唯一性。任何被修改过的数据所对应的哈希值是一个新的唯一哈希值。通过哈希值就可以直接判断两个数据是否一致。
去中心化数据结构是可信的
在中心化的web世界中：
- 我们必须信任数据中心(网站或托管中心)别无选择！
- 对于某个web数据，我们唯一的线索就是数据的
URL，通过这个URL访问对应的数据。 - 而这种访问数据的方式使得我们经常很容易被中心化的web世界中某些人欺骗、玩弄。
而在去中心化的web世界中：
- 我们从之前的
CS方式变成了P2P方式：不再有数据中心、所有的网络用户彼此存储数据。 - 访问数据的方式变成了基于数据内容所产生的哈希值。通过哈希值即可以定位数据。
- 哈希值使得我们不再被某些用意不良的人捉弄。
这就是在去中心化的web世界中，加密哈希如此重要的原因！
P2P方式获取数据
传统的基于位置定位数据的方式，一旦数据中心出现坍塌，那么托管的数据即丢失。
但是在去中心化的web世界中不存在数据丢失现象。
因为数据定位是按照数据内容所生成的哈希值定位的，只要存储数据的peer在线，就可以定位到数据。即使是当前peer离线，我们依然可以通过其他peer定位到需要访问的数据。
:bell:此时的哈希值如同传统意义的链接，并非仅仅代表数据的名称。
加密哈希和内容ID(CIDs)
目前我们专门讨论了关于猫狗的图像数据，实际上可以是任何类型的数据、都可以通过内容寻址的方式访问。
不同数据对应的唯一哈希值真正发挥作用，需要在哈希值中需要包含数据相应的格式信息，不同格式意味着我们需要相应的工具来处理不同类型的数据（执行编辑、查看操作）。
数据结构解码(Decoding)
-
CID (内容标识符)是去中心化web世界中实现内容寻址的专用格式。 -
CID (内容标识符)是IPFS(去中心化web协议)所约定的。 -
CID (内容标识符)有着丰富的寓意。
CID是英文 Content Identify 的缩写
一个 CID (内容标识符) 包含两部分信息：
- 一个**
codec**：encode and decode data in certain formats；- 一个哈希值(
Multihash)；
+-------+------------------------------+
| Codec | Multihash |
+-------+------------------------------+
复制代码很多数据格式和协议已经在使用内容寻址，例如 Git 工具、 Ethereum 、Bitcoin 协议都在使用内容寻址，但是它们解析数据的方式、所使用的哈希算法函数各不相同。
Git 工具、 Ethereum 、Bitcoin 协议都可以针对不同数据创建不同且唯一的一个 CID。
下面我们更详细讲解 CID (内容标识符)
+------------------------------+
| Codec |
+------------------------------+
| |
| Multihash |
| +----------+---------------+ |
| |Hash Type | Hash Value | |
| +----------+---------------+ |
| |
+------------------------------+
复制代码关于 CID (内容标识符)如何构建 IPFS，请参考 剖析CID 教程。
链接不同数据结构
CID (内容标识符)使得我们可以创建支持内链接的数据结构，就是说一个由 CID (内容标识符)标识的数据结构可以由不同类型的数据结构组成。
比如一个由 CID (内容标识符)标识的JSON对象，其内部链接着BSON对象：git中常见的数据结构。
同样我们也可以使用一个由 CID (内容标识符)标识一个目录型数据结构，其中包含任意不同类型数据。
由此延伸，那么使用 CID (内容标识符)使得我们可以创建分布式链接数据。
那么为什么在不同类型数据间的链接非常重要？
-
在中心化web世界中，本身就存在不同类型数据的链接，例如文本数据中链接着图片数据、主页上链接着
logo、PDF文件中链接着邮件地址。 -
在去中心化web世界中，基于内容寻址的数据同样需要链接使得所有资源可以连通在一起！
默克尔树与定向无环图(DAG)
去中心化web世界需要可链接的数据结构。
那么可链接的数据结构到底是什么？
默克尔树
Merkle tree (或简称哈希树) 是一种数据结构，其中每个节点都是哈希值。
+--------+
| |
+---------+ root +---------+
| | | |
| +----+---+ |
| | |
+----v-----+ +-----v----+ +-----v----+
| | | | | |
| node A | | node B | | node C |
| | | | | |
+----------+ +-----+----+ +-----+----+
| |
+-----v----+ +-----v----+
| | | |
| node D | | node E +-------+
| | | | |
+----------+ +-----+----+ |
| |
+-----v----+ +----v-----+
| | | |
| node F | | node G |
| | | |
+----------+ +----------+
复制代码默克尔树中，每个节点所指向的节点都是基于内容生成的哈希值(数据代表)。
:bellhop_bell:
- 每当通过其中一个节点(
CID)操作数据时，我们就可以回溯寻址内容(即数据)。 - 一个默克尔树就是一个带链接的节点集合。
- 每个节点(
CID)是一个数据的唯一标识符。
在上图中，node E 中包含了对node F和 node G的引用(链接)。
这意味着 node E 是引用其他节点的唯一节点。
这样会迷路吗？
我们可以想象 node E 是一个文件目录：
- 如果我们通过哈希算法操作
node E，会发现node E引用了目录F 和 G； - 因为在执行哈希算法得到的源于内容的哈希值将会包含对这两个目录(F 和 G)的引用信息。
- 如果目录G被删除，就意味着目录E被修改，那么
node E所对应的哈希值将是一个新的哈希值！
一旦上述的默克尔数被创建，就表示一个数据被创建，那么根节点的哈希值就是这个数据对象的唯一标识符。
:bell:如果默克尔树中的任何一个节点的数据被修改，那么被修改的节点CID（哈希值）将会变化，同时将导致该节点所关联的上级节点的CID（哈希值）被修改！
:loudspeaker:
这意味着对于一个程序员，总是需要向后创建数据：从叶节点回溯直至根节点。
定向无环图 (DAG)
- 定向无环图(DAG) 是英文
Directed Acyclic Graph的缩写。 - 定向无环图(DAG) 是对默克尔树的一种有趣描述（箭头向下直至叶节点）。
- 默克尔树中的不同分支可以单向指向其他分支。
原文地址及参考资源
原文
参考资源
Ready to learn more? There are plenty of additional resources to explore, both in ProtoSchool and beyond. Here are some of our favorites:
Understanding How IPFS Deals with Filesvideo
This course from IPFS Camp 2019 offers a deep exploration of how IPFS deals with files, including key concepts like immutability, content addressing, hashing, the anatomy of CIDs, what the heck a Merkle DAG is, and how chunk size affects file imports.
The Lifecycle of Data in the DWebvideo
This course from IPFS Camp 2019 explores how users share files on IPFS, from providing to getting to pinning to deleting.
Decentralized Web Primer: The Power of Content-Addressingarticle
A beginner-friendly primer on content addressing from Matt Zumwalt.
The Next Internet Revolutionvideo
In this excerpt from his TedX Talk, Juan Benet explains how the InterPlanetary File System (IPFS) uses content addressing to reframe our model for sharing knowledge.
Why is Decentralized and Distributed File Storage Critical for a Better Web?article
Juan Benet, Jesse Clayburgh, and Matt Zumwalt of Protocol Labs explain how advances in distributed data storage and strong alignment of market incentives are combining to create a more secure and efficient web.
Instructions for Saving Endangered Dataarticle
Matt Zumwalt of IPFS explains why data isn't safe on the centralized web and how IPFS can be used to protect it.
HTTP is Obsolete. It's Time for the Distributed, Permanent Web.article
Kyle Drake of Neocities explores the downsides of the Hypertext Transfer Protocol (HTTP).
Anatomy of a CIDtutorialProtoSchool
Dive deeper into how CIDs are constructed in IPFS, from multihash and multicodec prefixes to CID versions. (No coding required.)
IPFS: Mutable File System (MFS)tutorialProtoSchool
Explore the Mutable File System (MFS), which lets you work with files and directories in IPFS as if you were using a traditional name-based file system. (This tutorial includes JavaScript code challenges.)
P2P Data Links with Content AddressingtutorialProtoSchool
Use the IPFS DAG API to create create verifiable links between dataset with Content Identifiers (CIDs). (This tutorial includes JavaScript code challenges.)