为何IOTA选择稳健性而Sui选择更低延迟

• 广告 -

• Starfish 添加了纠删码和基于 DAG 的数据可用性证书，以提升 IOTA 在更高验证器负载下的数据可用性。

• Sui 的 Mysticeti V2 通过将交易验证移入共识流程，而非重新设计核心架构，从而降低了产品延迟。

IOTA 转向 Starfish 显示了区块链网络在共识设计上的明显分歧。IOTA 选择了另一条道路，专注于更强的活跃性、更好的数据可用性以及在网络压力下更稳定的性能。与此同时，Sui 通过 Mysticeti V2 持续降低延迟。

Mysticeti 移除了共识过程中的显式认证，允许 DAG 结构本身充当虚拟证书。这一设计有助于减少延迟，并降低由重复签名和认证轮次带来的开销。

然而，同样的设计也留下了技术隐患。没有显式认证，区块的可用性不再“免费”。验证器可能需要从对等节点获取缺失数据，这在负载较高时会给网络带来压力。研究人员还提出了对活跃性的担忧，特别是当验证器在轮次间移动却未生成自己的区块时。这些缺陷导致了 Sui 与 IOTA 之间目前的分歧。

Sui 的 Mysticeti V2 将核心共识引擎视为已接近最优。Sui 没有重建基础层，而是针对共识周围的额外交易验证流程进行优化。网络将更多验证工作移入共识流程，并使用交易驱动（Transaction Driver）来减少旧版 Quorum Driver 模型带来的延迟。

如果你想深入了解我们协议的技术细节，特别是 Starfish——@kowei1995 的这篇精彩文章为你提供了全面解析。快去阅读吧！

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

这种方法符合 Sui 专注于消费者应用、DeFi 和高吞吐量活动的战略。更低的交易延迟对于期待快速兑换、游戏、支付和链上交互的用户至关重要。因此，Mysticeti V2 通过削减外围摩擦而非改变核心传播模型，来保持速度竞赛的势头。

IOTA 选择稳定性，Sui 选择更低延迟

IOTA 的 Starfish 将数据传播和活跃性视为系统的薄弱环节，而非外围的交易层。Starfish 并未仅仅追求更快的最终确认，而是重新设计了数据在验证器间的移动方式，以及网络在条件恶化时如何保持进展。

Starfish 将区块元数据与交易负载分离。头部携带共识所需的快速信息，而更重的负载数据则以更可控的方式移动。

Starfish 还使用 Reed-Solomon 纠删码将交易数据分割成可恢复的片段。每个负载被拆分为碎片，验证器可以从足够多的有效碎片中重构完整数据。这一设计减少了全量数据的重复，同时保证了可用性。随后，Starfish 使用数据可用性证书，这些证书在 DAG 内部自然增长，而非为每个区块添加单独的认证轮次。

推进节奏器也起到了核心作用。验证器必须在前进之前生成自己的区块，从而减少 DAG 中的空洞。该规则针对的是无证书 DAG 设计中的活跃性问题——缺失过多区块可能阻止网络形成所需的见证和确认模式。

Starfish 确实付出了延迟成本。在更清晰的对比下，实际环境中 Mysticeti 的延迟约为四条消息，而 Starfish 接近五条。在更严苛的调度条件下，两者都可能进一步延长。即便如此，IOTA 接受这一增加的延迟，以换取更强的可用性保证、更稳定的尾部行为以及更正式的活跃性路径。

与此同时，本月 IOTA 在肯尼亚、摩洛哥和尼日利亚启动了首个 ADAPT 部署，以支持非洲大陆自由贸易区（AfCFTA）下的数字贸易。该项目旨在通过连接数字身份、支付和跨境数据交换，解决非洲 1000 亿美元贸易融资缺口。