IPFS 技术原理详解

本站已在 IPFS 上同步部署

• 您可运行节点使用本地网关访问：
  • IPNS KEY: k51qzi5uqu5dmfcprlafbp7idt7jujlsgp48hx8ful5k7iqm0el582yva4fgq3

• 或通过公共网关访问：

  • dweb.link/ipns/portkey.fanwb.xyz

  • dweb.link/ipns/k51qzi5uqu5dmfcprlafbp7idt7jujlsgp48hx8ful5k7iqm0el582yva4fgq3

  • flk-ipfs.xyz/ipns/portkey.fanwb.xyz

  • flk-ipfs.xyz/ipns/k51qzi5uqu5dmfcprlafbp7idt7jujlsgp48hx8ful5k7iqm0el582yva4fgq3

规模经济和云计算正导致网络系统日益中心化。域名解析、内容托管、路由、协议开发和证书颁发等服务的提供和运营都在向中心化的方向发展，一些领域的特定服务商甚至已接近垄断地位。我们的网络系统不可避免地面临着中心化系统所固有的单点故障风险，极端情况下的服务宕机可能会导致严重的后果和巨大的经济损失。据报道称，亚马逊的电商平台在 2013 年的宕机期间每分钟的损失超过 66000 美元。

为应对这一问题，近年来兴起了一场“网络去中心化”技术运动。其中包括一系列旨在赋予用户更多控制权的技术。这些技术通常依赖开源、社区驱动的软件实现，将传统网络功能(如域名查找、托管、认证)去中心化，以避免单一实体阻碍整体运营或设计决策。目前，已经有许多项目在通过去中心化的系统提供常见的应用服务，例如用于视频共享的 PeerTube 和用于博客的 Mastodon 等。这些项目为网络去中心化做出的努力值得肯定，但在实际层面其影响力仍然较小，且局限于特定应用场景。其实归根到底，所有网络平台的核心都是大规模地存储和分发媒体对象，如果能将这些核心功能本身去中心化，那么基于此构建出的应用就无需再处理去中心化的复杂性。星际文件系统 (IPFS) 正是基于这一理念诞生的。

用一句话定义 IPFS：一个完全去中心化的、内容寻址的媒体对象存储和检索平台。

当前，IPFS 已经得到了广泛应用，每周有超 300 万次 Web 客户端访问，对等网络中有超过 30 万个节点提供内容。IPFS 支持了各类去中心化网络应用，包括社交网络和论坛 (Discussify，Matters News) 、数据存储解决方案 (Space，Peergos，Temporal) 、内容搜索 (Almonit，Deece) 、消息传递 (Berty) 、内容流媒体 (Audius，Watchit) 以及电商 (Ethlance，dClimate) 等。Opera 和 Firefox 等主流浏览器也已提供访问 IPFS 的功能，使用更加便捷。

本文将详细介绍 IPFS 的设计和原理，其核心依赖四个主要概念：

• 内容寻址：IPFS 将对象名称与主机位置分离，使对象可以由任何对等点提供；
• 去中心化对象索引：IPFS 依赖去中心化的 P2P 覆盖来索引对象的可用位置，减少技术或组织失效的影响；
• 不可变性及自认证：IPFS依赖加密哈希来自认证对象，消除基于证书的身份验证需求，提供可验证性；
• 开放参与：任何人都可以部署 IPFS 节点并参与网络，无需特殊权限。

1 IPFS 基础

首先概述 IPFS 的核心模块，即 IPFS如何寻址内容、如何寻址对等点、如何构建分布式索引来将内容标识符映射到存储该内容的对等点。

1.1 内容寻址

IPFS 的核心是基于内容的寻址方案，其中使用了基于哈希的内容标识符 (CID) 。HTTP 等基于位置的系统，将内容地址 (URL) 与提供内容的主机绑定。而 IPFS 的内容寻址方案则将 CID 作为基本原语将内容的名称与其存储位置解耦。正是这一设计使得内容存储、内容传递和地址管理的去中心化成为可能，同时还能够防止供应商锁定，并消除了由中心化实体处理地址分配的需求。

图1 CID V1 结构说明

图1 展示了 CID 及其结构的示例。CID 依赖于一组自描述的数据表示协议，由以下四个字段组成：

• Multibase 前缀：二进制 CID 被编码的方式（“b”代表 base32）；
• CID 版本标识符：表示CID版本（v1）；
• Multicodec 标识符：表示数据的序列化方式（protobuf、json、cbor等）；
• Multihash：寻址数据的自描述哈希摘要。Multihash 包括表示所使用的哈希函数（默认为 sha2-256）和实际哈希长度（默认为 32 字节）的元数据。

当内容添加到 IPFS 时，会被分割成块（默认为 256 kB），每个块都会被分配一个 CID。块的 CID 是通过对其内容进行哈希并添加上述元数据产生的。随后 IPFS 构建文件的默克尔有向无环图 (Merkle DAG) ，原始内容发布者以该形式提供文件。Merkle DAG 是类似于 Merkle 树的数据结构，但没有平衡要求。根节点合并其后代节点的所有 CID，并形成最终的内容 CID（通常称为根 CID）。在 Merkle DAG 中，允许节点有多个父节点，这一特性使块去重成为可能。反过来，内容去重意味着相同的内容不需要重复存储或传输，从而节省存储和带宽资源。此外，Merkle DAG 对内容存储的位置是不可知的。因此，在网络中的节点上复制或删除文件时不需要进行更新。

CID 基于哈希的结构决定了其具有不可变和自认证的特性，也就是说无法只修改内容而不变更其 CID。利用这一特性，可以通过比较 CID 与内容本身的哈希进行来进行自验证。但另一方面，对于动态变化的数字对象，这一特性会带来挑战，后文将详细讨论。

1.2 对等点寻址

加入 IPFS 网络并连接到一组引导对等点后，节点会生成一个公私钥对。IPFS 网络中的每个对等点都由其唯一的 PeerID 标识，该标识是其公钥的哈希值（表示为 Multihash）。除非手动更改，否则PeerID保持不变。在建立安全通信通道时，PeerID 用于验证保护通道的公钥与识别对等点的公钥是否相同。

IPFS 使用 Multiaddresses 表示远程对等点的位置。Multiaddress 是一种自描述的、人类可读的、按层次分隔的协议选择序列。Multiaddress 这个术语源于其格式允许包含多个协议和地址类型。Multiaddress 代表对等点的一个可交互端点。IPFS 涵盖了从网络层到应用层的多种协议。

图2 Multiaddress 结构说明

图2 展示了 Multiaddress 的结构，其中包含了用于通信的网络和传输协议（IPv4 和 TCP）及其对应的基于位置的地址信息（IP 地址 1.2.3.4 和 TCP 端口号 3333），以及用于寻址特定对等点的协议 (p2p) 和其 PeerID (QmZyWQ14…) 。由此，Multiaddress 通过将多个层次的地址信息编码为路径表示来指向远程进程。

Multiaddress 使用此结构有两个原因：

• 并非所有 IPFS 节点都共享相同的协议子集。Multiaddress 使节点能在尝试连接之前知道是否能够连接到远程对等点。
• Multiaddress 的可扩展语法允许通过前缀化对等点地址进行中间中继通信。这一特点用于将消息代理到无法直接联系的浏览器节点。

1.3 内容索引

要发布或检索对象，就需要在 CID 和能够提供对象的 PeerID 之间创建映射（包括其Multiaddress）。为了以分布式的方式支持内容和对等点的发现，映射被索引到一个分布式哈希表 (DHT) 上，该表提供了简单的 PUT 和 GET 基元。IPFS 的 DHT 基于Kademlia，CID 和 PeerID 存在于一个共同的 256 位密钥空间中，使用其二进制表示的 SHA256 哈希作为索引键（见图1）。

与原始的 Kademlia 规范相比，IPFS 进行了一些调整：

• DHT 中的节点使用 256 位 SHA256 密钥而非 160 位 SHA1 密钥，以防止哈希碰撞。
• 维护 i = 256 个 k-节点的桶（其中 k = 20）来划分哈希空间。
• 采用可靠的传输协议如 TCP 和 QUIC，使连接管理更加简单直接。

新节点以 DHT 服务器或 DHT 客户端的形式加入 DHT，其中 DHT 服务器具有公共IP连接性，而 DHT 客户端不可公开访问（如处于NAT后）。IPFS 通过一种称为 Autonat 的简单技术来区分 DHT 客户端和服务器，其工作原理如下：新节点默认作为客户端加入，并立即要求网络中的其他节点主动与其建立连接。如果超过 3 个节点能够连接新加入的节点，则该节点将升级为服务器节点，否则节点保持为客户端。DHT 服务器执行所有网络操作，即存储内容、存储映射记录并向请求的节点提供这些记录。而 DHT 客户端只从网络请求记录或内容，但不存储或提供任何内容。DHT 客户端/服务器的区分可以避免不可访问的对等点进入其他对等点的路由表，从而加快对象的发布和检索过程。

2 IPFS 流程

这一部分主要介绍 IPFS 如何发布内容，对等点如何查找并检索内容以及 IPFS 如何处理可变内容。

图3 IPFS中的内容发布与检索

2.1 内容发布

为了在IPFS网络中提供内容，内容首先导入IPFS并分配一个 CID ① (见内容寻址部分)。

内容导入本地 IPFS 实例后，不会复制或上传到任何外部服务器。要发布内容，主机需要生成一个提供者记录 (provider record) ，并将其推送到 DHT。该记录会将 CID 映射到主机的 PeerID。随后，通过计算 CID 的 SHA256 哈希与 PeerID 间的异或距离，找到最近的 k = 20 个对等点存储提供者记录。记录复制到 k 个对等点上可以确保即使某些对等点离线，记录仍然可用。记录副本数选择 20 是 IPFS 根据实际的网络情况，在复制开销和记录删除风险之间的一个折衷。

一旦 IPFS 找到最接近的对等点 ②，会尝试在这些节点上存储提供者记录。此操作是通过建立连接并发起 RPC 来完成的 ③。该过程不会等待对等点的响应，而是以“即发即忘”的方式执行 RPC。值得注意的是，后续检索数据的所有对等点都会向 DHT 发布指向其自己节点的提供者记录，从而成为临时内容提供者。检索内容的对等点无需信任新的提供者，只需要验证收到的数据与请求的 CID 匹配即可。

对等点还需要发布其对等点记录 (peer record) ，将其自己的 PeerID 映射到与之关联的 Multiaddress。由此可以通过请求对等点来获取其底层网络地址。对等点记录的发布与上述过程相同，但与内容发布无关，独立进行。

除了复制因子 (k = 20) 之外，提供者记录还与另外两个参数相关：

• 重新发布间隔，默认设置为12小时，以确保即使最初负责保留提供者记录的 20 个对等点离线，提供者也会在 12 小时内分配新对等点；

• 过期间隔，默认设置为24小时，以确保发布者未离线且仍愿意提供内容。

这些参数设置是为了防止系统存储和提供过时的记录。

2.2 内容检索

一旦提供者和对等点记录被发布，用户就可以检索内容了。内容检索需要请求方执行以下四个步骤：

• 内容发现：识别托管内容 / CID 的 PeerID；
• 对等点发现：将 PeerID 映射到一个 Multiaddress（如一个IP地址）；
• 对等点路由：连接到对等点；
• 内容交换：获取内容。

内容发现： IPFS 中的内容发现主要使用 DHT 完成。然而，在进入 DHT 查找前，请求节点会要求其已连接到的所有对等点提供所需的 CID ④。这一步是以机会性的方式进行的（使用后文提到的Bitswap协议）。如果对等点的直接邻居存储了所需的内容，这一机制能更快地解析内容。如果尝试不成功，内容发现会在1秒的超时后回退到 DHT。

DHT实现多轮迭代查找，以将 CID 解析为对等点的 Multiaddress，此过程称为 DHT 遍历 (DHT walk) ⑤。当对等点 A 发出对 CID $x$ 的请求时，该请求被转发到其路由表中与 $x$ 最接近的 $\alpha$ = 3 个对等点（按照原始的 Kademlia 规范）。接收到请求的对等点如果有请求的内容则回复该内容。如果没有所请求的内容，则回复以下之一：

• 指向拥有所请求项的 PeerID 的提供者记录，以及该对等点的 Multiaddress（若有）

• PeerID 更接近于 $x$ 的对等点

该过程将持续进行，直到提供者记录中与被请求 CID 副本相关联的节点被返回为止。

对等点发现： 在内容发现阶段之后，客户端知道了托管目标内容的 PeerID。随后，需要通过查找对等点记录将 PeerID 映射到物理网络地址。此过程称为对等点发现 (peer discovery) ，通过再次查询 DHT 来完成。

为了进一步简化该过程，每个 IPFS 节点维护一个最多包含 900 个对等点的地址簿。在执行进一步的查找前，节点会检查是否已经拥有该 PeerID 的地址。

对等点路由： PeerID 解析为对等点记录后，请求节点会获取到提供目标内容的对等点的 Multiaddress，随后使用该地址尝试连接到对等点。

内容交换： 确定了提供内容的对等点后，使用块交换协议 Bitswap 来从对等点获取内容 ⑥。Bitswap 使用 wantlists 发出对内容块的请求。请求使用 IWANT-HAVE 消息发送。拥有被请求内容块的对等点用 IHAVE 消息回复。请求节点最后回复 IWANT-BLOCK 消息。接收到请求的内容块终止此交换过程。如前所述，Bitswap 协议也用于节点与其邻近节点之间机会性地发现可用内容。

2.3 可变内容

基于哈希的结构决定了 CID 是不可变和自认证的。利用这一特性可以消除对中心化协调者的需求，使其十分适合去中心化的命名空间管理，同时还令通用缓存（即从任何对等点缓存）成为可能。然而，这一特点在处理动态内容（如频繁变更的文档）时会成为问题。

为了处理可变内容，在文件修改时保持内容名称一致，IPFS提供了一种名为星际命名系统 (IPNS) 的命名系统，支持基于发布者的公钥哈希 (PeerID) 而不是内容的哈希 (CID) 来发布内容。IPNS 的标识符是从节点的公钥派生的，因此每个节点只能创建一个 IPNS 标识符。IPNS 记录会将发布者公钥的 CID 映射到由相应私钥签名的另一个 CID，虽然标识符本身是静态的，但其所指的 CID 可以由发布节点任意修改，这使得 IPNS 标识符背后的 IPFS 对象具有了可变性。IPNS 标识符可以表示其他任意的 CID，例如块、文件或数据结构。IPNS 标识符在其路径名中使用 /ipns/ 前缀而非 /ipfs/ 前缀以作区分。

2.4 IPFS 网关

为了方便还没有安装 IPFS 客户端的用户访问 IPFS 托管的内容，IPFS 系统通过网关进行补充，提供了 (HTTP) 进入 IPFS 的入口。网关相当于一个桥梁：一侧是DHT服务器节点，另一侧是一个 nginx HTTP web 服务器，可以接收包含 CID 作为 URL 路径的 GET 请求，即 https://ipfs-gateway.io/ipfs/{CID}。

运营网关不需要任何实体的授权或许可，只需要使用公网 IP 地址设置。需要注意的是，网关本质上对于整个存储和检索网络并非不可或缺，IPFS 网关是通过提供另一种从 IPFS 中检索文件的方法来支持整个网络。

3 IPFS 的主要特性

在应用程序中使用 IPFS 作为文件存储有诸多好处，例如内置的文件完整性检查、固有的内容去重，以及将文件检索与特定位置解耦的内容寻址。与此同时，由于其去中心化和无许可的性质，IPFS 也有一些特殊特性（如默认不提供授权/访问控制），在将 IPFS 集成到项目或应用程序中作为分布式存储时需要考虑这些特性。以下是关于 IPFS 的一些关键属性及其影响的讨论。

3.1 名称持久性及文件完整性

使用 Multihash 而非位置地址来标识内容，可以为网络提供更大的灵活性：

• 首先，资源可以更有效地利用，因为重复的文件甚至文件块都会被分配相同的标识符，因此可以进行链接和重用，以避免额外的资源浪费。而在传统的基于主机的寻址方案中，重复的文件可能以不同的文件名和不同的位置标识符被冗余存储。需要注意的是，虽然集中式云提供商也会应用数据去重方案，但这些方案一般不会应用在块级别，且不同方案使用的数据模型各不相同。

• 显式的内容寻址还简化了路径上和网络内缓存。因为可以使用 Multihash 验证文件块的完整性，因而无需信任第三方指向或提供正确的文件片段，由此可以消除对单个网络或内容提供商的依赖，避免了潜在的集中化。

IPFS 中名称持久性的特点之一是当内容本身更新时，内容标识符会发生变化。这与当前基于 HTTP 的模型不同，在 HTTP 模型中，URL 在其代表的内容发生变化时仍保持不变。因此，需要有额外的机制来处理动态内容，如使用星际命名系统 IPNS 或 libp2p 的 pubsub 协议（允许对等点彼此创建 pubsub 通道以动态广播和监听事件）来更新发布在 IPFS 上的内容。

3.2 数据可审计性、抗审查性及隐私保护

与 HTTP 相比，IPFS 在“隐私设计”原则方面做得更出色，因为它允许对存储数据进行更精确和全面的审计。例如，在用户撤销授权、需要删除个人数据的情况下，使用 HTTP 面临的问题是无法确定给定数据的所有副本是否已经从实体的服务器上删除（可能以不同的名称存储）。而在 IPFS 下，内容标识符的持久性使用户能更准确和彻底地了解包含个人数据的文件存储在何处。得益于默克尔链接，可以通过扫描CID 来验证数据是否存储在某个位置。但要注意的是，修改数据会产生不同的 CID，因此很难检测到修改后的数据版本（如添加了 padding 的数据）。尽管内容标识本身是不可变的，但实际数据可以在需要时被删除，这种数据可变性与特定元数据不可变性的结合，能更好地为基于 IPFS 构建的应用程序提供隐私保护的基础。

同时，由于 IPFS 是一个没有中央索引实体的分布式 P2P 文件系统，因此无法在其中明确地审查内容。由于对等点没有组织成层次结构，网络中不存在可以禁止存储和传播文件或从其他对等点的存储中删除文件的权威节点。因此，从技术上无法强制审查特定内容。IPFS 提供的抗审查性是通过在请求过的不同对等点之间复制内容来实现的，这使得完全审查提供者节点的难度极大。此外，任何公共 IPFS 网关也可以检索并向用户提供特定内容，这进一步增强了抗审查性。

另一方面，通过指纹查找存储相关文件的对等点会泄露其 IP 地址，这意味着这些对等点仍然可以被识别。关于隐私，这里有两个要点需要强调：

1. 与任何无许可、公开的 P2P 网络一样，IPFS 是一个全球分布、公开的服务器，用于存储网络中发布的数据。也就是说，IPFS 目前主要的用例是提供公共数据（例如数据集或网站）的存储和访问。考虑到 IPFS 预计能够支持的模块化和广泛应用，IPFS 目前并不在协议层支持隐私，这样的隐私设计目前必须在应用层实现。在撰写本文时，增强隐私同时支持广泛应用的模块化方法仍有待研究。
2. IPFS 对等点可以控制其在网络中与他人共享的内容。默认情况下，对等点会向网络发布其缓存中的每个 CID，即已发布或先前请求并获取的内容。如果对等点希望请求历史保密，可以进行本地节点配置，停止提供请求过的内容。该对等点仍然能获取和使用内容，并将其保存在本地缓存中，但不会在被请求时提供内容（如通过Bitswap），也不会让网络知道本地拥有特定内容。

3.3 网络分区容错性

由于 IPFS 是一个去中心化的 P2P 网络，没有核心中央组件，因此可以在网络分区或离线情况下运行。虽然一些组件可能无法检索或更新，但分区不会完全影响内容发布和检索过程。因此，只要所需对象和提供者记录在同一个子图中已知且可用，IPFS 就能够容忍分区，并且如果提供者节点可访问，则不需要完整的互联网连接。此外，可以使用 IPFS 集群构建一组机器之间的私有 IPFS 网络，从而允许在本地网络中部署 IPFS。

3.4 参与激励

IPFS 的设计初衷是一个无许可、尽力而为的去中心化 P2P 网络，因此不包含任何激励机制。运行一个 IPFS 节点会产生带宽、存储和电力方面的基础设施维护成本，在检索到所需对象后，普通用户没有动力继续运行节点，这也导致了 IPFS 中的网络会话时间短，波动性高。用户甚至可以只依靠 IPFS 网关通过 HTTP 检索所需对象，完全不参与网络。第三方固定服务可以一定程度缓解缺乏激励的问题，这类服务通过固定文件的来保障其可用性并向用户收取费用。另一种解决该问题的方法是提供独占性，即提供其他地方无法获得的内容或功能，但这点较难实现，因为与集中化的基础设施相比，IPFS 尽力而为的存储方式在便捷性和用户体验方面更不稳定，这可能导致应用难以获得关键用户数量。

Filecoin 是一个激励式的 P2P 网络，用于存储和检索基于 IPFS 的对象。其目标是提供比集中式云存储解决方案更便宜的分布式存储。Filecoin 使用与 IPFS 相同的构建模块，核心是通过 CID 进行内容寻址。与 IPFS 不同的是，IPFS 在其他对等点明确请求内容之前不会复制内容，而 Filecoin 对其参与者进行加密经济激励：在网络中存储和复制内容会获得加密货币奖励。由此 Filecoin 获得了更高的可用性、更快的检索速度并抵消了节点变动。通过支付费用，对等点可以相互之间签订存储交易来进行持久存储，并通过复制证明和时空证明进行证明。Filecoin 通过提供激励机制改进了 IPFS 尽力而为的存储和交付服务，且由于 Filecoin 是去中心化、基于区块链的，合约双方无需相互信任。

4 IPFS 相关数据

4.1 地理分布

根据 Protocol Labs 的研究，截止 2021 年 9 月，IPFS 中共有 198,964 个对等点，在 DHT 中有 1,998,825 个 Multiaddress，覆盖了来自 152 个国家的 464,303 个唯一 IP 地址。图 4 显示了 PeerID 的地理分布。

图4 IPFS 对等点地理分布

可以发现，尽管 IPFS 覆盖范围很广，但仍存在某些地区的集中分布，美国 (28.5%) 和中国 (24.2%) 在对等点数量上占据了主导地位，其次是法国 (8.3%) 和韩国 (6.7%)。

图5 每个 IP 地址上对等点数量的累积分布函数

需要注意的是，单个 IP 地址可以托管多个 PeerID。图 5 绘制了每个主机上对等点数量的累积分布函数 (CDF)。虽然大多数 (92.3%) IP 地址只托管一个 PeerID，但排名前 10 的 IP 地址托管了近 6.6 万个不同的 PeerID，如果恶意对等点轮换 PeerID，会影响网络整体路由性能，存在拒绝服务攻击的风险。

4.2 自治系统分布

IPFS 对等点分布于 2715 个自治系统 (AS) 中。图 6 展示了每个 AS 中的 IP 地址数量，其中，排名靠前的少数 AS 容纳了大量 IPFS 主机。排名前 10 的 AS 涵盖了 64.9% 的 IP 地址，排名前 100 的 AS 涵盖了 90.6%，超过 50% 的 IP 地址仅分布于 5 个 AS中。这与 IPFS 对等点的地理分布存在显著差异，每个地区都主要由少数 AS 主导。

图6 IP 地址在不同规模自治系统中的分布情况

这一趋势的一个可能原因是 IPFS 节点广泛使用云基础设施。下表列出了每个云提供商中部署的节点数量。与预期相反，统计发现只有少数 (<2.3%) 的 IPFS 节点托管在云上。这对去中心化存储和交付网络来说是一个重要发现，表明大多数用户托管了自己的部署。

排名	提供商	IP 地址	占比
1	Contabo GmbH	2038	0.44 %
2	Amazon AWS	1792	0.39 %
3	Microsoft Azure/Coporation	1536	0.33 %
4	Digital Ocean	836	0.18 %
5	Hetzner Online	592	0.13 %
6	GZ Systems	346	<0.10 %
7	OVH	341	<0.10 %
8	Google Cloud	286	<0.10 %
9	Tencent Cloud	258	<0.10 %
10	Choopa, LLC. Cloud	244	<0.10 %
12	Alibaba Cloud	180	<0.10 %
13	CloudFlare Inc	140	<0.10 %
27	Oracle Cloud	27	<0.10 %
54	IBM Cloud	9	<0.10 %
	Non-Cloud	453661	97.71 %

4.3 节点波动

节点波动是指节点进出网络的行为。图 7 绘制了主要国家和地区的 DHT 节点在线时长的累计分布函数。

图7 主要地区 DHT 节点在线时长的累计分布函数

可以看到，节点在线时长通常较短，87.6% 的会话少于 8 小时，只有 2.5% 的会话超过 24 小时。这也解释了 IPFS 选择在相对较多节点（复制因子 k = 20）上复制记录的设计决策。另外，节点的稳定性会因地区而异，香港的中位在线时长仅为 24.2 分钟，而德国的数据是其两倍以上。

---

IPFS 在设计上是高度去中心化的。尽管在某些地区存在地理聚集，但总体而言 IPFS 节点仍在全球范围内广泛分布。仅有不到 2.3% 的 IPFS 节点运行在云平台上，这一方面有益于网络的健壮性和去中心化，但同时也导致了网络节点的高波动率（只有 2.5% 的对等点在线超过 24 小时）。此外，虽然在 2715 个自治系统中存在 IPFS 节点，但排名前 10 的自治系统就占了 64.9%，未来 IPFS 网络仍需扩大部署，以避免自治系统中的中心化。

5 总结

本文概述了 IPFS 核心原理及其功能，介绍了 IPFS 如何结合多种网络协议和 P2P 理念构建去中心化云存储基础设施。其基础模块通过内容标识符 CID 实现了名称持久性、文件去重和完整性检查等功能，支持对等的文件分发和交付，同时提供抗审查、网络分区容错和去中心化等特性。总体而言，IPFS 节点目前已广泛分布在全球各地和多个自治系统中，具有较强的网络健壮性和去中心化程度，但同时，在访问控制、参与激励、内容可用性等方面 IPFS 仍面临着挑战。