Solana 刚刚将验证者生成区块所需的时间缩短了 50 毫秒，而且这是该网络有史以来第一次这样做。Solana 插槽时间升级已于周五在主网正式上线，将目标插槽时间从 400 毫秒缩短到 350 毫秒，并开启了开发者所描述的、按 epoch 分阶段推进、最终迈向 200 毫秒这一更快目标的进程。
Summary
要点速览
- Solana 主网的插槽时间从400 毫秒降至 350 毫秒，这是自网络上线以来首次下调。
- 该变更作为功能 SIMD-0525 在第 1019 个 epoch 的插槽 440,208,000 激活，此前已于 5 月 14 日合并进代码库。
- 还计划通过单独的功能开关再进行三次 50 毫秒的削减，依次降至 300、250，最终到 200 毫秒，每一步都取决于区块跳过率是否保持健康。
- 此次升级被标记为破坏性变更，Solana 表示第三方工具的索引调整仍在推进中。
- Solana 基金会技术副总裁 Jacob Creech 确认，300 毫秒是路线图上的下一个目标。
Solana 首次缩短主网插槽时间
核心答案很简单：Solana 在不改变网络底层结构的前提下，让区块到达得更快了。这是自 Solana 诞生以来首次缩短插槽时间，直接压缩了每个验证者用来组装并广播一批交易区块的时间窗口。
激活细节与即时效果
根据 Solana 自身的区块浏览器显示，该功能以 SIMD-0525 的编号在第 1019 个 epoch 的插槽 440,208,000 上于主网 Beta 激活。该提案本身早在 5 月 14 日就已合并进网络改进文档，为开发者在正式切换前预留了数月时间来准备验证者软件。
在确认速度上，实际效果几乎立刻显现。《The Block》报道的一次时点检查显示，升级前不久的一段 1,000 个插槽区间耗时 415 秒完成，而升级在第 1020 个 epoch 激活后，类似区间仅耗时 368 秒——这一现实世界中的下降与新的 350 毫秒目标高度吻合。
由于 Solana 上每个 epoch 仍然包含 432,000 个插槽，更快的插槽会直接转化为更快的 epoch。过去大约需要 48 小时完成的一个 epoch，现在大约 42 小时就能结束，即便 epoch 内部的计数方式完全没有改变。
支撑此次升级的技术基础
如果没有在验证者客户端侧的工作，这一切都不可能实现。Solana 将此归功于对 Turbine（网络的区块传播层）以及 Replay（验证者用来验证并对传入区块进行投票的流程）的改进，这些技术进步让更短的插槽时间在大规模环境下仍然可承受。
在网络能够安全压缩领导者完成区块、通过 Gulf Stream 将其交给下一位领导者，并让其余验证者重放并对其投票的时间之前，这两个系统必须先变得更快。如果没有这些升级就缩短时间窗口，很可能会推高跳块率并破坏区块生产的稳定性。
分阶段推进的进一步插槽时间缩短
Solana 并未直接跳到最终目标。相反，网络将分四个独立阶段，从 400 毫秒逐步降到 200 毫秒，每一步都需要单独激活，并在通过健康检查后才允许进入下一步。
未来升级的功能开关机制
每一次额外的 50 毫秒削减——无论是到 300、250 还是 200 毫秒——都将通过在后续 epoch 中激活的独立功能开关触发，而不是一次性总开关。这种结构为 Solana 基金会和验证者运营方留出了观察空间，可以在每一个新速度下先观察网络表现，再决定是否推进下一次削减。
从原 Solana Labs 分拆出来的验证者客户端开发团队 Anza，已经给出了一个初步的 Agave v4.2 时间表，目标是在主网上最终完成全部四个阶段的削减。对于下一步的 300 毫秒阶段，目前尚未设定具体的日历日期或特定 epoch。
基于区块跳过率的风险控制
谨慎态度在这里体现得尤为明显。Solana 基金会已经明确表示，如果区块跳过率升得过高——也就是有太多验证者未能及时产出其被分配的区块——网络就不会推进到下一次插槽时间削减。这一内置“刹车”非常关键，因为更短的插槽会压缩所有下游流程：区块完成、交易传播以及验证者投票都拥有更少的物理时间来正确完成。
这之所以重要，是因为带有跳块率触发条件的分阶段上线，实际上把“速度”变成了一个可监控变量，而不是一项固定承诺。如果验证者的硬件或软件无法在 300 毫秒下保持同步，网络就可以选择停留在该阶段，而不是继续推进并冒着不稳定的风险。
更广泛的影响与网络层面的意义
更快的插槽并不自动意味着在所有意义上都拥有更快的网络，这一点对关注 Solana 吞吐量指标的人来说尤为重要。验证者更频繁地处理插槽，但每个插槽承载的工作量更少，因此此次变更主要提升的是延迟和确认速度，而非原始交易容量。Solana 还在 2025 年 7 月单独将其计算单元上限提高到 1 亿，这是另一项旨在扩展每个区块可容纳工作量的升级。
破坏性变更状态与对索引的影响
Solana 自身将整体的Solana 插槽时间升级标记为破坏性变更，而第三方工具和服务所需的索引调整仍有待确定。这是一个值得注意的空白：Solana 自己的文档仍然将默认插槽时长描述为 400 毫秒，尽管网络浏览器已经确认首个 350 毫秒功能开关处于激活状态。基于索引器、分析面板或区块浏览器进行开发的开发者，应预期在工具追赶网络新节奏的过程中会遇到一些短期摩擦。
官方表态与升级路径洞察
Solana 基金会技术副总裁 Jacob Creech 将此次举措描述为网络的首次插槽时间削减，并确认 300 毫秒是路线图上的下一个目标。无论是 Creech 还是基金会的公开升级页面，目前都尚未为下一步设定明确日期，而且该计划明确取决于网络在 350 毫秒下的表现。
这里还有更长远的视角。插槽时间与完全终局性并不相同——即便在新的 350 毫秒插槽节奏下，Solana 区块今天仍大约需要 12.8 秒才能变得完全不可逆。一个名为 Alpenglow 的、仍在开发中的独立重构，目标是最终将这一终局性窗口缩短到约 150 毫秒，这将比当前分阶段的插槽时间削减带来更大的结构性变化。网络最近还引入了由 Jump Crypto 构建的 Firedancer 客户端，其使用的编程语言不同于主流的 Agave 技术栈，在整体提速的同时也提升了验证者客户端的多样性。
常见问题
Solana 最近对插槽时间做了什么改动？
Solana 将其主网插槽时间从 400 毫秒缩短到 350 毫秒，这是自网络诞生以来的首次削减。
未来的插槽时间削减将如何管理？
未来将分别通过功能开关激活 300、250 和 200 毫秒的削减，并取决于区块跳过率不会过高。
插槽时间削减会影响 Solana 的 epoch 结构或每个插槽的 tick 数吗？
不会，此次升级不会改变每个插槽的 tick 数、领导者跨度或每个 epoch 中的插槽数量。
为什么此次升级被视为破坏性变更？
此次升级被视为破坏性变更，是因为它要求第三方工具和基础设施进行索引方面的调整，尽管这些调整尚未最终确定。
{“@context”:”https://schema.org”,”@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”Solana 最近对插槽时间做了什么改动？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Solana 将其主网插槽时间从 400 毫秒缩短到 350 毫秒，这是自网络诞生以来的首次削减。”}},{“@type”:”Question”,”name”:”未来的插槽时间削减将如何管理？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”未来将分别通过功能开关激活 300、250 和 200 毫秒的削减，并取决于区块跳过率不会过高。”}},{“@type”:”Question”,”name”:”插槽时间削减会影响 Solana 的 epoch 结构或每个插槽的 tick 数吗？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”不会，此次升级不会改变每个插槽的 tick 数、领导者跨度或每个 epoch 中的插槽数量。”}},{“@type”:”Question”,”name”:”为什么此次升级被视为破坏性变更？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”此次升级被视为破坏性变更，是因为它要求第三方工具和基础设施进行索引方面的调整，尽管这些调整尚未最终确定。”}}]}
本文由人工智能协助生成，并由编辑团队审核。
