在海星内部：IOTA的基于推送的共识机制解析

• 广告 -

• IOTA的Starfish提前发送关键信息，帮助验证者在网络压力下避免长时间等待缺失的区块。

• IOTA采用Reed-Solomon编码和DAG校验，无需将完整交易数据推送给每个验证者即可恢复有效载荷。

IOTA已通过v1.21.1版本和协议版本24将Starfish共识机制迁移到主网。此次升级为网络带来了基于实际应用条件的新型共识设计，验证者即使在节点变慢、消息延迟或部分参与者行为异常时，也能保持数据流动。

共识通常围绕达成一致展开。验证者必须在压力下就相同的历史达成一致。然而，Starfish将同步视为同一问题的一部分。验证者不能对未见过的区块投票，也不能认证无法重建的交易数据。因此，Starfish将数据传输放在协议内部，而非作为单独的网络任务。

“诚实的做法是帮助网络前进。”

Starfish已在IOTA主网上上线——我们的研究团队@NaitsabesMue详细解析了技术设计决策、权衡取舍，以及IOTA博客上的数据分析。pic.twitter.com/78f0x5f8wz

— IOTA (@iota) 2026年5月7日

IOTA的有向无环图（DAG）记录了区块之间的引用关系。这些链接显示验证者已见到的内容以及网络中仍存在的空白。当多个验证者之间出现引用时，网络显示出共享的知识；当引用缺失时，结构揭示了同步失败的具体位置。

IOTA早期的Mysticeti共识模型更依赖拉取行为。在该模型中，验证者在检测到差距后向同行请求缺失的区块。拉取在平静条件下节省带宽，但在网络压力下会增加延迟。每个缺失项都会引发新的请求、等待和恢复步骤。

IOTA在主网激活Starfish共识升级，作为支持与全球80亿亿美元市场相关的实际贸易基础设施的一部分。此次升级帮助网络在部分节点滞后或断开时保持韧性。

IOTA的Starfish采用推送以减少恢复延迟

Starfish用一种基于推送的方法改变了这一模式。验证者在其他节点请求之前，主动将有用信息向前传递。这使得滞后节点在关键路径到来之前，已获得可能需要的数据。IOTA的出站请求图清楚显示了这一变化，Starfish比Mysticeti将拉取请求减少了大约一个数量级。

出站请求速率 | Mysticeti与Starfish | 来源：IOTA博客

该设计并未全部推送。Starfish将元数据与交易有效载荷分离。头部携带引用、投票、确认、时间细节和有效载荷承诺。交易数据则单独传输。这保持了共识路径的轻量化，同时为验证者提供足够信息以维护DAG的健康。

Reed-Solomon编码支持这种结构。Starfish将区块的交易有效载荷分割成多个碎片，每个验证者分配一个碎片。原始有效载荷可以由任何足够数量的有效碎片重建。在Starfish中，任何f+1个有效碎片都能重建有效载荷，而2f+1个确认则构成在拜占庭假设下确保安全的可用性条件。

因此，Starfish不要求每个验证者同时持有完整的有效载荷。相反，它证明在诚实验证者中存在足够的已验证碎片以重建数据。随着DAG的增长，后续区块携带早期有效载荷仍可恢复的证据。

性能数据解释了为何IOTA接受了这一权衡。Starfish在测试期间比Mysticeti使用了更多带宽，但额外的通信发生得更早，并遵循结构化路径。协议提前发送有用信息，而非等待验证者请求缺失数据，从而降低了后续的恢复成本，并帮助网络在压力下保持一致。

带宽：Mysticeti与Starfish | 来源：IOTA博客

性能表现还涉及方差。Starfish在排序前增加了可用性步骤，可能略微提高普通交易的延迟。然而，较慢的情况得到了改善，网络在恢复缺失信息方面的时间也减少了。