Kubo vs Helia vs Elastic-IPFS：主流 IPFS 实现方案对比（完整翻译）

一、易用性（Ease Of Working With）

Kubo

Kubo 需要一定的命令行经验才能运行，其复杂程度在一定程度上取决于你所使用的操作系统（MacOS 最为简单），但一旦 Kubo 安装完成，运行和与你自己的本地 IPFS 节点进行交互就很容易了。

Kubo 充当一个一体化的 IPFS "守护进程"（daemon），一旦运行起来，用户就可以通过 RPC 接口或 Kubo 实现内置的易用 CLI（命令行界面）来与之交互。

随着你学到更多知识，对于那些希望进行自定义的人来说，Kubo 还有一个广泛的配置文件，让用户可以根据自己的特定用例微调 Kubo 实例。

Kubo 的另一个巨大优势是其周围成熟的文档。由于 Kubo 是最古老的 IPFS 实现，其文档非常广泛，几乎涵盖了你在使用时可能遇到的任何问题。

总的来说，如果你希望尽快开始使用 IPFS，Kubo 是一个极佳的实现方案。

Helia

与可以作为独立进程 / IPFS 进程运行的 Kubo 不同，Helia 旨在成为一个轻量级、模块化的组件，被构建到 NodeJS 或浏览器应用程序容器中。

这个"容器"的范围可以从运行 Helia 实例的单个 NodeJS 文件，到以复杂方式使用 Helia 的更大应用程序。

对于那些在 JS 生态系统中构建的人来说，这是一种强大的范式。能够在与主应用程序相同的进程中配置和运行 IPFS 实例，可以降低复杂性并加快开发周期。

截至本指南撰写之时（此处插入日期），Helia 仍然是 IPFS 的一个较新的实现，其文档不如 Kubo 等实现那样广泛。对于那些刚开始的人来说，这可能不会构成太大问题，但对于那些构建更复杂 IPFS 应用程序的人来说，你可能需要深入 Helia 源代码来寻找答案。

Elastic-IPFS

Elastic IPFS 的云原生设置意味着希望使用它进行构建的团队需要全面了解自动化代码部署工具、网络和云计算服务。具体来说，你需要了解以下 AWS 服务：

• DynamoDB
• S3
• Lambda
• Route53
• EKS
• ELB
• VPC
• SQS

在文档方面，Elastic-IPFS 确实包含一些有用的图表 / ReadMe 文件，解释关键概念和配置设置等内容，但那些计划使用 Elastic-IPFS 的人应该做好阅读源代码来回答许多问题的准备。

简而言之，Elastic-IPFS 的入门门槛相对较高。

二、功能集（Feature Sets）

Kubo

Kubo 将自己描述为一个具有广泛 API 的"通用型"实现，其功能集反映了这一点。虽然这些功能中的许多都可以在其他实现之上构建，但 Kubo 的亮点在于它"开箱即用"地支持这些功能，作为一个独立进程，无需额外的编码或应用程序。

显著功能包括：

• 通过 Kubo 配置提供的广泛配置选项，支持以下功能：
  • API 限制和访问控制
  • 资源限制/调优
• 内置 HTTP RPC API，用于与 Kubo 和 IPFS 网络的其余部分交互
• 内置 CLI 访问 Kubo API
• 内置 IPFS 网关
• 能够自动将固定（pins）复制到外部固定服务

有关完整功能列表，请查看官方 Kubo 仓库！

Helia

Helia 最强大的功能是能够被配置和运行为原生 JS 应用程序的一部分。这使它能够轻松地在浏览器中运行，这是其他 IPFS 实现目前无法做到的，除非进行非常有创意的工程工作。

我们之前提到 Helia 旨在轻量级和模块化。这意味着 Helia 对于自身包含的内容非常谨慎。从功能集的角度来看，这意味着 Helia 本身由核心包组成，外部库可以与之交互以添加功能。

如果开发者需要额外的功能，他们可以选择引入接口库来满足他们的需求。Helia 团队还维护着一组提供 Kubo 等实现中常见的"标准"IPFS 功能的库。

这种方法使 Helia 团队能够升级 Helia 的核心组件，而无需担心破坏外部库，只要这些库继续遵守 Helia 实现规范。

Elastic-IPFS

Elastic-IPFS 在功能丰富性方面可能有所欠缺。它做两件事，但它做得非常好：

• 存储 IPFS 内容
• 提供 IPFS 内容

使用 Elastic-IPFS 的运维人员可能希望将某些组件替换为修改版本，或向代码库添加额外的功能，但核心 Elastic-IPFS 实现可能永远不会支持广泛的功能集，因为它的目标与 Helia 类似，是轻量级和模块化。

这一点，加上 Elastic-IPFS 的云原生设置，意味着运维人员可以在无停机的情况下更新和修改其 IPFS 设置的某些部分，因为 Elastic-IPFS 只是一起工作的无服务器组件的组合，充当一个巨大的 IPFS 提供者。这相对于 Kubo 等实现来说是一个优势，因为 Kubo 需要重启/停机才能接收更新。

使用 Elastic-IPFS 等云原生 IPFS 实现的其他好处是，运维人员可以利用额外的云工具来实现以下功能：

• 增强的日志记录/可观察性
• 网络保护
• 数据备份/删除保护

三、可扩展性（Scalability）

Kubo

单个 Kubo 节点的可扩展性取决于三个主要因素：

• Kubo 运行的物理硬件（内存 GB 数/CPU 核心数）
• 运行 Kubo 的机器的网络连接
• 正在处理的内容量

虽然 Kubo 确实提供了广泛的设置列表，可以帮助运维人员根据他们的需求调整 Kubo，但归根结底，单个 Kubo 守护进程在遇到问题之前只能扩展到一定程度。

因此，Kubo 非常适合许多桌面应用程序（如 IPFS-Desktop），或服务于较小数据集的项目，但在遇到大规模情况时可能难以作为独立选项，特别是当处理可能需要定期删除数据的较大数据集时。

对于需要更多扩展性的运维，Kubo 通常通过在基于 Kubernetes 等技术构建的编排设置中并行运行多个 Kubo 节点来扩展。对于那些寻找预构建选项的人来说，IPFS-Cluster 是一个专为与 Kubo 节点配合设计的固定集（pinset）编排系统。

Helia

Helia 目前优于其他 IPFS 实现的一个显著领域是其引用计数（Reference Counting）文件系统的实现，这在向 IPFS 添加和删除内容时提供了相对于 Kubo 的显著性能优势。这使 Helia 在处理大量数据时具有优势。

然而，Helia 与 Kubo 类似，Helia 的可扩展性也依赖于：

• Helia 运行的物理硬件（内存 GB 数/CPU 核心数）
• 运行 Helia 的机器的网络连接

因此，Helia 的许多示例...

三、可扩展性（Scalability）- 续

Helia（续）

Helia 目前优于其他 IPFS 实现的一个显著领域是其引用计数（Reference Counting）文件系统的实现，这在向 IPFS 添加和删除内容时提供了相对于 Kubo 的显著性能优势。这使 Helia 在处理大量数据时具有优势。

然而，Helia 与 Kubo 类似，Helia 的可扩展性也依赖于：

• Helia 运行的物理硬件（内存 GB 数/CPU 核心数）
• 运行 Helia 的机器的网络连接

因此，Helia 的许多示例都集中在其在中小型规模应用程序中的使用，例如桌面或基于浏览器的 IPFS 应用程序。有一些 Helia 在服务器类型环境中运行的示例，但与用户的机器类似，这些服务器环境也依赖于上述可扩展性限制。

与 Kubo 类似，Helia 可以通过 Kubernetes 等编排技术并行运行多个实例来扩展。不幸的是，在撰写本文时，IPFS-Cluster 尚未与 Helia 兼容，因此任何并行 Helia 编排都必须自定义构建。

Elastic-IPFS

Elastic-IPFS 是专门为数据中心规模而构建的。

其他 IPFS 实现可能会遇到硬件限制等瓶颈，而 Elastic-IPFS 采用完全不同的方法，将硬件限制完全排除在外。它使用模块化的云原生设计，将 IPFS 实现的核心部分分解为无服务器子系统，每个子系统都彼此独立扩展。

换句话说，Elastic-IPFS 利用经过实战检验的基于云的构建块来提供一个快速、稳定且"自动扩展"的 IPFS 节点，其扩展能力几乎是无限的。

Elastic-IPFS 需要大量的工程投资来正确运行和维护，但对于需要大规模的项目来说，你肯定会通过 Elastic 获得这种能力。

总结

原文链接: https://pinata.cloud/blog/kubo-vs-helia-vs-elastic-ipfs-comparing-the-major-ipfs-implementations-ease-of-working-with/

翻译完成 ✅

用费曼风格聊聊 IPFS 实现方案：为什么“点餐”和“买菜做饭”不一样？

读完这篇详实的 IPFS 实现对比，我们该怎么理解 Kubo、Helia 和 Elastic-IPFS 之间的差异呢？

我们可以把 IPFS（星际文件系统） 比作一个 “全球共享大厨房”，每个人的文件都贴着独特的“菜名标签（CID）”。而这三种不同的实现方案，其实是三种完全不同的“进厨房”方式：

1. Kubo：大而全的“标准商用厨具套装” Kubo（以前的 go-ipfs）就像是那种功能齐全、工业级的商用炉灶。

   • 它的特点： 什么都有，极其耐造，能处理海量食材（大数据量）。如果你要在餐厅里大干一场（做服务器后端、长时间挂机），它就是不二之选。
   • 缺点： 块头大，你得专门给它在后厨留个大空位（占用内存和 CPU 高）。

2. Helia：轻巧的“迷你便携卡式炉” Helia（js-ipfs 的继任者）就像是你带去野餐的那个便携炉子，甚至可以直接在你的餐桌上（浏览器里）点火。

   • 它的特点： 极轻，不需要复杂的安装，直接写在网页代码里就能跑。它是为了让普通的“食客（网页访问者）”也能顺手在这个大厨房里找点零食吃。
   • 缺点： 火力有限。你让它煮一锅 100 人的大米饭，它可能半路就熄火了。

3. Elastic-IPFS：这种是“云端中央厨房” 当你发现自己要开 1000 家连锁店时，无论是 Kubo 还是 Helia 都满足不了你了。

   • 它的特点： 它不是一个单一的炉灶，而是一套分布在云端的、可自动扩展的厨房系统。它专门为那些需要极高可靠性、海量存储（像 Pinata 这种公司）的人设计。
   • 一句话总结： 它把 IPFS 变成了“弹性的云服务”。

总结建议：

• 如果你是在服务器上干脏活累活，选 Kubo；
• 如果你是在写网页，想让用户在浏览器里直接下图片，选 Helia；
• 如果你是在搞大厂规模的数据托管，或者想要极致的扩展性，研究一下 Elastic-IPFS。

#IPFS #分布式存储 #Web3架构 #费曼学习法 #技术对比分析