为什么IOTA选择了鲁棒性而Sui选择了更低的延迟

• 广告 -

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

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

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

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

然而，同样的设计也留下了技术上的隐患。没有显式认证，区块可用性不再“免费”。验证器可能需要从对等节点获取缺失的数据，这在重负载下可能会给网络带来压力。研究人员还提出了对活性的担忧，尤其是当验证器在轮次间移动而不生成自己的区块时。这些差距造成了如今 Sui 和 IOTA 之间的分歧。

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

如果你想更深入地了解我们的协议，特别是 Starfish 的技术细节——@kowei1995 在这篇精彩的文章中为你提供了详尽内容。请阅读！https://t.co/wdTklasvvt

— 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 部署，以支持非洲大陆自由贸易区下的数字贸易。该项目针对非洲 1000 亿美元的贸易融资缺口，通过连接数字身份、支付和跨境数据交换来实现。