Solana出块加快17%，处理量不变是设计使然，上限按比例调降
2026-09-18分类：Solana（SOL） 阅读（）
Solana 的目标出块间隔近日缩短到250 毫秒，比先前的300 毫秒快了约17%。不过网络整体的交易处理量没有跟着增加，而且这是设计上刻意的安排—每一格能塞的运算量与资料量，按同样比例调降了。
提案把400 毫秒分四阶段砍到200 毫秒
依Anza 的Brennan Watt 提出的SIMD-0525 提案，Solana 要把目标出块间隔从400 毫秒降到200 毫秒，途中分成四道功能开关依序启用：350、300、250，最后才是200 毫秒。目前走到第三阶段。
每一阶段启用时都带一个epoch 的延迟。提案写明，若某道开关在第E 个epoch 首次启用，该epoch 内的所有slot 仍必须沿用前一组出块时间参数，用意是让Turbine 等网络基础设施先做好准备。
每一格的运算上限按比例往下调
关键在容量怎么算。提案给的换算方式是「整数值以trunc（400 毫秒时的数值× 目标出块毫秒数÷ 400）缩放」。
以提案列出的两端为例：在400 毫秒时，单一区块的运算单元上限是6,000 万、可写入帐户的上限2,400 万、投票上限3,600 万，资料变动上限则是1 亿。降到200 毫秒后，这四个数字各自减半，成为3,000 万、1,200 万、1,800 万与5,000 万。
也就是说，每秒产生的区块变多了，但每个区块能承载的工作变少，两者相抵。使用者拿到的是更快的确认，不是更大的吞吐量。
换来的是延迟，不是容量
提案自己说明的动机正是延迟。文件写道，较短的slot「降低使用者的确认与最终性延迟」，并让应用程式（提案举的例子是预言机的使用者）对链上时间有「更细致的理解」。
提案同时列出风险。文件指出，较短的slot「减少了leader 交接、区块传播、重播与投票落地可用的时间」。另有两项安全考量：验证者必须正确实作那个一epoch 的延迟，以及通膨相关程式码必须采用等同于实际时间的slot 计算方式。
SIMD-0525 目前在提案库中的状态仍标示为草案。
Tags：
