Solana 将时隙时间缩短至 250 毫秒：周五之前检查的内容

2026 年 9 月 18 日星期五，世界标准时间 05:01 左右，Solana 网络收紧了自己的节拍：一个时隙将持续 250 毫秒，而不是 300 毫秒。它的切换已经设置好，并在 1037 纪元的边界自动生效。对于作为 Solana 持有者的您来说，这主要意味着三件事：委托和取消质押生效更快，质押奖励更频繁且更小部分地到达，以及签名交易保持有效的时间窗口缩短至大约 38 秒。如果您的 SOL 只是位于交易所，则您无需执行任何操作。如果您自己离线签名、委托或运行验证器，请阅读本文末尾。这一变化并不令人意外，而是八月份开始的路线图的第三步。唯一的新鲜事是 250 毫秒的步骤现在有了具体的日期。当我们在 9 月 17 日检查时，Solana 的官方概述页面仍然列出了这一步骤，但没有主网日期，而开发团队 Anza 已经将激活标记为即将在 9 月 16 日进行。公告和文档之间的差距就是为什么到目前为止该数字几乎没有浮出水面的原因。 9 月 18 日，Solana 实际发生了什么变化 协议中的一个数字正在发生变化：时段的目标时间。该值从 300 毫秒降至 250 毫秒。这个数字看起来很小，但网络中几乎所有看起来像时间的东西都挂在它身上。纪元长度跟随它，块哈希的有效期跟随它，每个块的计算上限也跟随它。负责的改进提案是SIMD-0525。它描述了从 400 到 350、300 和 250 毫秒到 200 毫秒目标的阶梯。主网上已经采取了两个步骤：2026 年 8 月 19 日，第 1019 纪元开始时，从 400 毫秒变为 350 毫秒；2026 年 8 月 25 日，第 1023 纪元开始，从 350 毫秒变为 300 毫秒。第三步是这里讨论的步骤。其后还有第四个。明确不会发生的事情：没有代币交换，没有迁移，没有从合约中提取某些东西的最后期限，也不需要在钱包中进行确认。任何要求您批准 Solana 升级的人都希望从您那里得到一些东西，而不是您对协议参数的同意。时隙是一个区块的时间窗口 时隙是恰好有一个验证者可以生成一个区块的时间窗口。一旦过期，无论上一份是否已交付，下一份都会上线。因此，时隙并不是交易的速度限制，而是网络发出区块的时钟速率。 epoch 是记账周期 epoch 是 Solana 的记账周期，覆盖固定的 432,000 个时隙。网络在其边界进行记账：委托生效，奖励结算，准备好的协议交换机准备就绪。由于时隙的数量是固定的，而时隙的持续时间会减少，因此纪元会变短。 400 毫秒计算出 48 小时，300 毫秒计算出 36 小时，250 毫秒计算出 30 小时。最终目标是 200 毫秒，最终目标是 24 小时。此时此刻，流通中的数据值得关注：一些报告给出了周五变化的纪元长度为 24 小时。这是 200 毫秒的值，表示此步骤之后的步骤。对于 250 毫秒，同样的计算得出 30 小时，基于 432,000 个时隙的官方公式也得出该值。功能门是带有延迟的开关功能门是验证器代码中的一个开关，它使已发布的功能保持休眠状态，直到有足够的权益重量支持。当它翻转时，它不会在纪元中期发生，而是在纪元边界发生。对于此更改，该链跨越了三个纪元：在纪元 1035 中，切换处于待处理状态，在纪元 1036 中，它在协议级别变得活跃，并且随着纪元 1037 开始，应用新的计时规则。自八月中旬以来，该网络的节奏第三次收紧。为什么开关在纪元边界 1037 而非午夜翻转 Solana 没有时钟。网络对时隙进行计数，并且只能根据时隙来估计一天中的某个时间。这正是为什么每个严肃的公告都会在时间前面加上一个“周围”：纪元 1037 的边界落在特定的时隙上，而何时到达该时隙取决于网络在前几个小时内实际运行的速度。这种不精确性就是为什么两个来源可以说 05:01 UTC 和第三个说 05:06 UTC 而没有任何一个错误。如果你想在确切的时刻完成某件事，请计划一个小时的缓冲时间。如果您只想知道自己是否受到影响，日历日就可以了：欧洲时间周五凌晨。

我们自己的测量结果：更改前一天每个时段 317 毫秒 cryptoticker.io 于 2026 年 9 月 17 日自行收集了此分析。方法：通过 Solana 的公共主网节点进行 10 个连续性能样本，每个样本 60 秒，在 UTC 00:50 后不久检索，加上对当前纪元状态的查询。这涵盖了 1,893 个时隙，覆盖了 10 分钟的网络运行时间。结果：每个时隙平均花费 317.0 毫秒，单个样本在 312.5 到 326.1 毫秒之间。因此，该值高于 300 毫秒的当前目标。这是正常现象，没有任何问题的迹象。测量的是经过的时钟时间除以实际填充的槽数，并且验证器不服务的每个槽都会延伸该平均值。可以根据同一查询重新计算日期。该网络位于 1036 纪元，位于 432,000 个时隙中的第 111,540 个时隙，还剩下 320,460 个时隙。测得的时间为 317 毫秒，剩余运行时间为 28.2 小时，因此是 9 月 18 日 05:06 UTC 左右。我们自己的计算证实所宣布的时间为 05:01 UTC，误差在几分钟之内。该节点查询报告的客户端版本4.3.0-rc.0。我们无法检查的是：已经运行推荐版本的验证器的比例有多大，以及切换是否在周五真正生效。两者都只在事后出现。下面提到的计算上限也取决于专家报告，而不是官方概述页面。 Solana 质押：较短的 epoch 对委托、取消质押和奖励意味着什么对于任何委托 SOL 的人来说，epoch 长度实际上是整个变化中最重要的数量。代表团及其撤回在纪元边界生效，而不是立即生效。如果 epoch 从 36 小时缩短到 30 小时，那么直到新委托获得奖励或直到停用的 SOL 再次免费可用的典型等待时间也会随之缩短。我们在有关锁定期和解除质押期限的文章中详细阐述了该过程如何运作，以及为什么等待期不是惩罚。有了奖励，改变的是节奏，而不是数量。每个时期都会进行支付。因此，一年中更多的纪元意味着更多的学分，但也意味着更少的学分。您的代表团的年收益并没有因此而增加。从周五开始，任何按纪元记录收入的人都会在同一电子表格中获得更多行，任何按支付频率比较提供商的人都会在我们的质押提供商概述中发现平台之间的差异。这里应该澄清一个常见的误解：周五的日期与朝霞无关。这是对共识机制的一次不同的、规模更大的改革，有自己的路线图，我们在 9 月底关于 Alpenglow 激活的文章中对此进行了描述。两次转换，两次日期，两组不同的后果。离线签名的交易在更改后、区块哈希过期之前的秒数会减少。 Blockhash 在 250 毫秒到期：为什么签名时必须更快 blockhash 是 Solana 事务的时间戳：对最近生成的块的引用，可防止稍后再次提交相同的指令。该邮票的生命周期不是以秒为单位，而是以块为单位。根据 Solana 的文档，151 个区块哈希是有效的。该文档仍然使用 400 毫秒的旧目标时间进行转换，因此得出大约 60 到 90 秒。这个跨度随着节拍而下降。今天测量的 317 毫秒，大约还剩下 48 秒；为 250 毫秒，大约为 38。关于即将发生的变化的专家报告将窗口设置为 37.5 秒，这与使用 150 个区块而不是 151 个区块的计算结果相同。无论哪种方式，数量级都是相同的：足足半分钟。无论是人还是设备在创建和发送交易之间，这一点都很重要。使用硬件钱包签名会消耗解锁、翻阅显示屏和确认的时间。准备交易，然后闲暇时再次检查地址，然后才发送也是如此。结果不是付款丢失，而是付款被拒绝：网络丢弃区块哈希过期的交易，并且钱包报告错误。我们的 Solana 交易失败指南中介绍了如何判断此类尝试是否真的失败或最终完成。实际上，这意味着：在发送之前解锁设备，事先检查地址而不是在运行窗口内检查地址，并且不要将确认对话框视为阅读时间。我们的硬件钱包比较中显示了哪些设备具有较短的确认路径以及哪些设备会让您通过多个菜单。