Solana 出块更快、单块更小 —— 为什么快不等于容量大

Solana 主网计划在第1020个 epoch 把目标出块间隔从400毫秒缩短到350毫秒,同时按大致相同的比例下调单个区块允许包含的最大计算量。区块来得更频繁,每秒允许的工作量却基本不变。这就是这次改动的全部要点,也顺带纠正了新手常见的一个假设:出块更快并不自动等于容量更大。

这些数字来自仍处于草案阶段的 SIMD-0525。主网此前已在400毫秒的目标下启用了每块1亿计算单元(CU)的上限。提案把该上限与各档出块间隔组合起来:350毫秒对应8750万 CU,300毫秒对应7500万,250毫秒对应6250万,200毫秒对应5000万。每一档折算下来,理论上限都约为每秒2.5亿 CU。提案同时下调了每个 slot 的账户写入、投票、数据分配、数据分片与编码分片,以及分区奖励等预算。

推进是分阶段的,不是一步到位。350毫秒的功能账户已在第1019个 epoch 的首个 slot(440,208,000)激活,但按延后一个 epoch 的规则,主网在该 epoch 内仍按400毫秒运行。测试集群走得更前:testnet 已处于200毫秒的生效目标,devnet 为300毫秒,其250毫秒的开关已激活但尚未生效。功能被激活,只说明某项具体改动正在网络中推进,并不代表完整的200毫秒设计已成定论。

代价是协调时间。Solana 会把连续四个 slot 分配给同一个出块者,因此400毫秒对应约1.6秒的出块窗口,到200毫秒就只剩0.8秒。验证者接收上一个区块、重放、在其上构建并完成投票的时间都被压缩。epoch 也随之变化:每个 epoch 固定为432,000个 slot,名义时长会从400毫秒下的约48小时,向200毫秒下的约24小时靠拢。

对在 Solana 上开发或读取链上数据的人来说,还有一个不显眼的兼容性问题。部分 SDK 常量与链下假设仍绑定在400毫秒上,因此用 slot 数乘以400毫秒来估算经过时间的软件,在更快的阶段生效后就会与集群对不上 —— 用 slot 间距判断数据新鲜度的浏览器、RPC 客户端与看板同样如此。提案给出的方向是:软件应向集群获取当前生效的时间参数,而不是把编译期常量当作永久事实。

细节之外有三点值得记住。区块上限描述的是一个区块最多能装多少工作,而不是每个区块实际会装多少。目标出块间隔也不等于你实际体验到的确认速度,后者还取决于传播与最终性。以及,一条网络完全可能在纸面上变快,而每秒容量还停在原地。本文是信息,不是投资建议。