6月22日，Filecoin官方博客发布“Lotus 节点的演变”的内容：

Lotus & Retrieval Markets 建设者峰会

Retrieval Market 小型峰会的目的是聚集多个 Retrieval Market 解决方案的所有构建者，突出迄今为止取得的进展，并确定多个系统如何结合在一起以提高检索交易的效率、网络效率和可靠性对于网络用户。

峰会的所有谈话都在 Filecoin 频道上提供。

在4 月的Retrieval Market 建设者小型峰会上，Raul Kripalani（libp2p 和 Filecoin 核心开发者）组织深入探讨了 Lotus 节点的架构和计划的更改，特别是对 Lotus矿工节点的更改，以便更好地满足矿工的需求和网络参与者。该演讲旨在强调确保 Lotus 矿工的检索交易高度可靠和可扩展所需的工作，帮助确保 Filecoin 检索市场建立在稳健的基础上。

Lotus是 Filecoin 网络的一个系统实现，用 Go 编写。作为 Filecoin 的第一个系统实现，Lotus 旨在为整个网络奠定坚实而有弹性的基础。任何 Filecoin 节点的核心功能之一是实现有用数据的存储和检索，从而为 Filecoin 网络上强大的检索市场奠定基础。

Lotus 节点的演变

Filecoin 生态系统正在快速发展，Lotus 等生态系统工具也在不断发展以满足网络的需求并寻求未来发展的机会。特别是检索市场将为 Filecoin 网络引入新功能，包括索引、CDN、公共检索等。

我们发现这些新的检索市场功能将依赖于强大的矿工基础。如今，Lotus 矿工倾向于解决他们认为不稳定或无利可图的某些功能。归根结底，这是来自矿工的良好行为，它帮助 Lotus 实现演进以满足他们的需求。当网络参与者开始屏蔽某些功能时，表明软件本身应该为其用户提供更多的灵活性和模块化。

通过这一观察，我们意识到 Lotus 的单体二进制文件阻碍了 Lotus 矿工的灵活和稳健的操作，并试图从中找出解决问题的机会。

单体二进制

到目前为止，Lotus 节点的架构在很大程度上是单体的。Lotus 有两个不同的入口点：1) 一个完整节点，2) 一个矿工。

然而，除此之外，网络参与者在存储生命周期中承担的责任几乎没有选择余地。例如，矿工的任务就是挖矿、证明存储、交易等。这些是根本不同的职责，但它们通过当前的 Lotus-miner 架构耦合在一起。

单体架构的问题

从广义上讲，这种整体架构阻止了矿工在不同的职责之间有效地分配他们的资源。强制合并责任与矿工的核心动机（即在最小化运营风险的同时实现利润最大化）相矛盾。具体来说，单体二进制存在许多问题。

脆弱性：当架构内没有隔离时，一个区域的错误可能会泄漏并影响其他关键流程。这使得很难在关键进程和非关键进程之间进行分段，从而使整个实例可能崩溃。

增加攻击面： Lotus 矿工的某些进程需要公开公共端点，这使系统的该部分容易受到攻击。如果架构是单一的，则单个公共端点可能会危及整个系统。

功能膨胀：在 Filecoin 的使命中，矿工不仅存储和提供原始数据，而且还提供有用的服务，例如索引、发现等。使用新的矿工侧功能重载单个进程会导致进一步的忧患和操作风险。

无法扩展：不同的能力需要不同的特性和不同的升级过程。尝试在单一系统中管理这些不同的功能很困难，并且会导致迭代和增长缓慢。

缺乏细粒度控制：由于矿工无法主动选择加入或退出功能，他们必须通过拒绝交易、设置高价以劝阻交易甚至分叉代码库等机制来解决这些问题。

迭代更慢：单体架构意味着更难测试和创新，因为没有简单的方法来隔离新组件并选择加入实验功能而不将其引入整个系统。

Lotus 矿工的更多责任

使用这种初始分类，是迈向模块化矿工架构的第一步，解决了单一架构的缺点:将 Lotus 矿工流程分为 1) Lotus 市场流程 2) 其他 Lotus 矿工流程。

通过分离市场和挖矿，Lotus 节点的架构对于矿工来说变得更加聚焦于功能，使他们能够将自己的职责与最适合他们的能力以及他们对网络的经济偏好的责任保持一致。

设计原则

在沿着这条通往更加模块化的矿工架构的新道路前进的同时，Lotus 将继续坚持一些设计原则：

避免类似微服务架构的复杂性：明确避免复杂的相互依赖网络，这些网络会迅速转化为意大利面条式架构，并需要专门的工具（如服务网格）来管理和调试。这是引入 Lotus 错误的复杂性级别。秩序和等级仍然存在，因为这些过程仍然是一个单一的有凝聚力的单元的一部分。

简单的中心/辐条架构： Lotus 正在向中心辐射架构发展，该架构由主管实例管理。这些主管知道部署中提供了哪些功能以及哪些节点提供了这些功能。它们还充当聚合的外部 API 入口点。

值得投资：新的 Lotus 架构一定值得投资。除了盈利能力外，其他一些 ROI 因素包括可靠性、安全性、开发人员敏捷性和稳健性。

强大的分布式流程生命周期监督：模块化架构并不意味着完全孤立的架构。如果出现故障并且意味着其他下游服务将出现故障，那么整个系统必定能够注意到并做出反应。

为了设计这个新的运行时间，我们通过 Erlang/OTP 和面向角色的编程（例如 JVM 世界中的 Akka）等模型来激励自己，而无需完全依赖这些框架，并从服务网格和编排器中借用精选概念和抽象概念。