Solana 可能获得涡轮增压，因为 Firedancer 针对区块限制

Solana的性能提升本周获得新动力，由Jump领导的高性能验证器客户端Firedancer背后的工程师们提交了一份新的Solana改进文档(SIMD-0370)，旨在移除网络的区块级计算单元(CU)限制——他们认为这一变更在Alpenglow之后已经变得多余，并且在需求激增时能立即转化为更高的吞吐量和更低的延迟。

Solana的下一次涡轮增压

"Firedancer团队"撰写并于2025年9月24日提交的拉取请求，明确定位为"Alpenglow后"提案。在Alpenglow中，如果投票节点无法在分配的时间内执行提议的区块，就会广播SkipVote。由于慢速区块会被自动跳过，作者认为每个区块单独的协议强制CU上限已经不再必要。

"在Alpenglow中，如果投票节点无法及时执行区块，就会广播SkipVote...因此，本SIMD移除了区块计算单元限制的强制执行，"文档指出，描述在升级后的调度规则下，这一限制已经多余。

除了技术上的简洁性，作者还提出了更明确的经济对齐。他们认为，当前的区块级CU上限通过协议而非硬件和软件改进来限制容量，破坏了激励机制。移除它将允许生产者填充区块至其机器能安全处理和传播的程度，将客户端和硬件竞争推向前沿。

"网络的容量不是由硬件能力决定的，而是由任意的区块计算单元限制决定的，"他们写道，随后概述了为什么取消这一限制将重新调整验证器客户端和程序开发者的激励机制。

来自核心贡献者和客户端团队的早期代码审查评论强调了这一变更对近期用户的影响和边界。一位审查者总结了实际好处："今天移除限制对生态系统和终端用户有切实的好处...无需等待网络未来架构的完善。"另一位强调某些区块约束将保留，引用"最大碎片限制"，而其他人则建议网络应该暂时保留每笔交易的CU限制，并将其任何变更视为一个单独的、更深远的讨论。

安全性和活跃度考虑成为重点。审查者要求提案明确说明为什么即使区块太重而无法及时传播，安全性仍能得到保障；Alpenglow的答案是这类区块根本不会被投票通过，即它们会被跳过——在不惩罚网络的情况下维持前进。Firedancer作者同意，决定性的护栏是时钟和传播预算，而非静态CU上限。

该提案还解决了吞吐量辩论中的一个常见问题：协调。如果一个区块生产者积极升级硬件而其他人落后，网络是否会因跳过的区块而面临波动？一位审查者指出，过于雄心勃勃的生产者已经在自我校准，因为错过区块意味着错过奖励，自然将区块大小限制在同行能及时接受的范围内。文档进一步论证，随着CU限制的取消，市场力量将主导容量：优化执行、网络和调度的生产者和客户端团队将赢得更多区块和费用，随着需求的增长推动边界扩展。

至关重要的是，SIMD-0370具有未来兼容性。Solana长期路线图中的多并发提议者设计有时假设存在区块限制，有时则不假设。审查者强调，移除当前限制不会排除日后的并发提议者架构；它只是解锁了"今天就能实现"的改进。

虽然GitHub讨论提供了技术细节，但Solana客户端团队Anza（Agave背后的团队）也在社交渠道上放大了这一提案，表明客户端团队广泛关注这一变更及其面向用户的影响。

如果SIMD-0370部署，用户和开发者会有什么变化？在高峰期——空投、铸造、市场波动——只要区块能在时隙时间内执行和传播，就能承载更多计算，潜在提高持续吞吐量并平滑费用峰值。

对Solana开发者而言，更高的余量和更强的客户端/硬件优化激励可能减少高需求工作负载的尾部延迟，尽管仍需继续优化程序的并行性和局部性。对验证者而言，竞争优势将更倾向于执行效率、网络性能和智能区块构建策略，平衡费用收入与生产过重区块被跳过的风险。

与所有SIMD一样，这一变更需经过社区审查、实施和跨验证器客户端的部署协调。但方向已经明确。在Alpenglow之后，Solana的设计者认为时隙时间预算才是真正的限制因素。

截至发稿时，Solana交易价格为$205.38。