Solana 近期将目标出块间隔缩短至 250 毫秒，较此前的 300 毫秒快约 17%。不过，网络整体交易处理量并没有跟着上升。这并非异常，而是协议设计中的安排：每个区块可容纳的运算量与数据量，也会按同样比例下调。
SIMD-0525 计划分四阶段把目标出块时间从 400 毫秒降到 200 毫秒
根据 Anza 的 Brennan Watt 提出的 SIMD-0525 提案，Solana 计划把目标出块间隔从 400 毫秒逐步降到 200 毫秒。整个过程分为四道功能开关，依序对应 350 毫秒、300 毫秒、250 毫秒和 200 毫秒。目前已经走到第三阶段，也就是 250 毫秒。
提案还写明，每一阶段启用时都会带有一个 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 也带来实施与安全考量
提案同时列出了风险。文件指出，较短的 slot「减少了 leader 交接、区块传播、重播与投票落地可用的时间」。
文件还提到两项安全相关考量：其一，验证者必须正确实现那个一个 epoch 的延迟；其二，通胀相关代码必须采用与实际时间等价的 slot 计算方式。
目前，SIMD-0525 在提案库中的状态仍标示为草案。