本文由 AI 生成,请独立核实重要信息。

Solana 纪元时间:时长、奖励与机制

Crypto Wiki|Oct 8, 2026|★★★★★★4.5 (500 人评分)
AI 摘要

Learn how Solana epochs work: 432,000 slots every 2-3 days. Understand staking rewards distribution, validator schedules, and epoch boundaries.

Solana 纪元时间描述了网络完成固定槽位(slots)计划所需的时间,之后验证者日程、质押奖励和质押状态更改将被处理。

本文内容: 什么是 Solana 纪元? | Solana 纪元有多长? | 验证者日程和机制 | 质押奖励 | 质押激活和冷却期 | Solana 与以太坊纪元 | 纪元边界清单 | 通胀与代币经济学 | 如何查看当前纪元 | 面向开发者 | 常见问题解答 | 质押决策


引言:为什么 Solana 纪元对每个 SOL 持有者都很重要

如果您通过 Phantom 或 Solflare 质押了 SOL,并注意到您的质押仪表板上出现了“纪元”一词,那么您并不孤单,也很想知道它的含义。该数字直接影响您关心的两件事:您新委托的 SOL 何时开始赚取质押奖励,以及这些奖励何时进入您的账户。

Solana (SOL) 是一个高性能的区块链(一个由节点网络保护的分布式数字账本),每秒可处理数千笔交易。在数百个验证者之间协调这些活动需要一个结构化的时间框架。这个框架就是纪元。在中心化交易所(如 Coinbase 或 Binance)持有的 SOL 无法进行本地质押,也不参与纪元奖励周期。持有者必须将他们的 SOL 托管在自行管理的钱包中才能进行直接质押。

关键统计数据: 每个 Solana 纪元包含正好 432,000 个槽位,这相当于大约 2 到 3 天的实际时间。

本文涵盖了您需要了解的关于该术语的所有内容:定义、时长及其变化原因、质押奖励的计时方式、每个纪元边界会发生什么、如何查看当前纪元,以及开发者如何以编程方式访问纪元数据。


什么是 Solana 纪元时间?

Solana 纪元是一个固定时期,包含正好 432,000 个连续的槽位,它构建了网络如何分配验证者职责、分发质押奖励和应用通胀调整的框架。在实际条件下,一个纪元大约持续 2 到 3 天。

“纪元”一词在通用计算中有不同的含义。在 Unix 系统中,纪元是固定的时间戳参考点(1970 年 1 月 1 日)。在 Solana 的协议语境中,纪元是一个由槽位数量定义的、重复出现的、离散的时间段,而不是由日历时间定义的。这两个概念共用一个名称,除此之外别无他物。

槽位和区块如何构成纪元

槽位是 Solana 架构中时间的原子单位。在每个槽位期间,会有一位指定的验证者有机会生成区块。每个槽位的目标持续时间约为 400 毫秒,但这并非绝对。如果指定验证者离线或网络拥堵,该槽位就会在没有生成区块的情况下过去。这些被称为跳过的槽位。

区块是在槽位内生成的数据。槽位是时间窗口;区块是填充它的一切。有些槽位会生成区块;跳过的槽位则什么也不生成。

层级结构是:一个槽位(目标约为 400 毫秒)可以生成一个区块,而 432,000 个连续的槽位则构成一个完整的纪元。

槽位 1 到槽位 2 到...到槽位 432,000 = 一个纪元完成。

**历史证明(Proof of History, PoH)**是使这种槽位排序成为可能且可验证的加密机制。PoH 是一个计时机制,而不是一个共识机制。它不应与工作量证明(Proof of Work)或质押证明(Proof of Stake)混淆。PoH 创建了一个可验证的历史记录,证明事件是以特定顺序和特定时间发生的,而无需所有验证者实时就时间达成一致。每个槽位都经过 PoH 序列的加密锚定,这就是为什么 Solana 可以在大约 400 毫秒的间隔内处理槽位,而无需等待全网达成时间一致。

Solana 的架构,包括用于区块传播的 Turbine、用于无内存池交易转发的 Gulf Stream,以及用于并行智能合约执行的 Sealevel,使得其高吞吐量成为可能,从而支持其纪元结构。根据 Solana 官方纪元术语文档,),每个纪元 432,000 个槽位是一个协议常量。


Solana 纪元有多长?

Solana 纪元包含正好 432,000 个槽位。以每个槽位目标持续时间约 400 毫秒计算,理论最短持续时间约为 2.0 天(172,800 秒)。实际纪元通常在 2 到 3 天之间。

算术计算:432,000 槽位乘以 0.400 秒/槽位等于 172,800 秒,除以 86,400 秒/天,等于理论下限的 2.0 天。

实际时钟持续时间如何随实际槽位速度缩放:

  • 平均每槽位 400 毫秒:172,800 秒,约 48 小时
  • 平均每槽位 450 毫秒:194,400 秒,约 54 小时
  • 平均每槽位 500 毫秒:216,000 秒,约 60 小时

注意: 每个纪元 432,000 个槽位的数量由协议固定,不会改变。实际时钟持续时间根据网络状况在约 2 到 3 天之间变化。

导致实际纪元持续时间与理论最小值不同的三个因素:

跳过的槽位: 当验证者错过其分配的领导者槽位时,该槽位将被跳过,网络继续前进。PoH 序列继续,但该槽位不生成区块。跳过的槽位会延长完成 432,000 个槽位所需的时间。

网络拥堵: 高交易量时期会减慢槽位处理速度,在许多槽位上增加额外时间。

网络中断: Solana 主网历史上曾发生过中断。在中断期间,槽位处理会暂停,从而延长了跨越该时期的任何纪元的实际时钟持续时间。

实际建议:将纪元持续时间视为大约 2 到 3 天,而不是固定的时间间隔。有关当前的平均纪元持续时间,请参阅 Solana Beach 或 Solana 基金会的文档。Solana 协议参数可能会发生变化。


Solana 纪元如何运作:验证者日程和网络机制

每个纪元开始时,Solana 网络会计算一个完整的领导者日程,该日程预先为即将到来的纪元的所有槽位分配一个特定的验证者。分配取决于纪元边界快照中每个验证者的质押权重。

验证者是 Solana 网络上的节点,负责处理交易、生成区块和对账本状态进行投票。委托者是 SOL 持有者,他们将代币质押给验证者,而不是自己运行节点。这些角色是不同的:验证者运行基础设施;委托者贡献经济权重。

质押证明 (PoS) 是与 PoH 一起工作的共识层。Solana 通过 Tower BFT(拜占庭容错)实现 PoS,Tower BFT 使用 PoH 作为其时钟。在一个时期内累积的质押权重决定了每个验证者在下一时期领导者计划中被分配时段的概率。PoS 使时期在纯粹的时间记录之外具有经济意义。请勿将 Solana 的 Tower BFT 实现与以太坊的 PoS 相混淆,后者是一个结构上不同的系统。

Solana 的质押模型类似于委托质押(有时称为委托权益证明,或 DPoS)。在此模型中,代币持有者将他们的质押分配给验证者,而不是自行运行基础设施。SOL 持有者可以委托给任何验证者;委托在预热期后的下一个时期边界生效。委托人分享验证者的质押奖励,减去验证者的佣金费率。对委托的任何更改,无论是新的分配、切换还是提款,都将在时期边界生效,而不是立即生效。这是导致质押更改需要预热期或冷却期的协议级原因。Solana 的机制在技术上结合了 PoH 和 Tower BFT,而不是纯粹的 DPoS;请使用“委托质押”作为主要描述符。

每个时期边界如何计算领导者计划

领导者计划是验证者在特定时段内的确定性、预先计算的分配。 “确定性”意味着网络上的任何节点都可以从相同的输入独立计算完整的计划,而无需与其他节点通信。此设计使计划可验证且高效。

计算使用时期边界快照中每个验证者的质押权重。持有 1% 总质押 SOL 的验证者在大约 432,000 个时段的领导者计划中获得约 1% 的份额。该计划使用更新的质押权重在每个时期边界从头开始重新计算。时期内的质押委托不会影响当前时期的领导者计划;它仅影响下一时期的计划。

完整的领导者计划机制记录在 Solana 的领导者轮换文档.) 中

许多基于 Solana 构建的 DeFi 协议都具有时期意识,围绕时期边界安排流动性事件、治理投票或奖励分配。

提示: 验证者在时期边界的质押权重决定了他们在下一时期被分配的时段数量。时期内的质押委托不会影响当前时期的计划。

一个时期内投票积分如何累积

每个验证者维护一个投票账户:这是一个特殊的链上账户,用于记录验证者在一个时段内对账本状态的投票。投票账户不是治理系统。在 Solana 中,“投票”是指验证者对区块的有效性进行加密证明,这是一项共识机制操作。

每次成功投票都会为验证者赢得一个投票积分。在时期边界,协议会统计在一个已完成时期内累积的所有投票积分。验证者在时期质押奖励中的份额与其投票积分分数相对于该时期的最大可能积分成正比。

错过投票的验证者获得的奖励比例较低,因此他们的委托人获得的奖励也较少。在 Phantom 和 Solflare 等钱包 UI 中,此指标显示为“正常运行时间”或“投票成功率”。投票积分分数较高的验证者为委托人带来的质押奖励在每个时期都更多。


Solana 时期和质押奖励:何时何地获得支付

Solana 质押奖励会在每个时期结束时自动分发,大约每 2 到 3 天一次,直接记入您的质押账户,无需您采取任何操作。

质押账户在链上持有委托的 SOL,并且独立于常规的 Solana 钱包账户。它们会经历四个状态:非活动、激活中、活动、然后是非活动中。状态转换发生在时期边界。大多数钱包界面(Phantom、Solflare)会从用户那里抽象出质押账户,但底层机制解释了您在仪表板中看到的时序行为。有关完整的质押账户规范,请参阅 Solana 的质押文档.

重要提示: 质押奖励会在时期边界自动分发,大约每 2 到 3 天一次。无需手动操作。奖励直接添加到您的质押账户本金中,并自动为下一时期重新质押。

您的奖励份额如何计算

您在给定时期内的质押奖励遵循以下关系:

  1. 协议计算您质押占总网络质押的比例份额(您的质押除以所有已质押的 SOL)。
  2. 该份额乘以该时期的总发行量(根据当前发行计划,在时期边界新铸造的 SOL)。
  3. 在将剩余部分分配给委托人之前,验证者的佣金费率将从验证者的总奖励分配中扣除。

仅供说明:如果网络在一个时期内通过发行奖励铸造 100 SOL,而您的质押占总质押 SOL 的 0.01%,那么您的税前份额是 0.01 SOL。然后,在扣除验证者的佣金费率后,您的净金额才会被记入。

对于质押 年化收益:该关系近似等于(年发行量除以总质押 SOL)乘以(1 减去佣金费率)。由于发行率和总质押 SOL 都会随时间变化,因此硬编码的 年化收益 数字在一个时期后就不再准确。有关当前估算,请使用您的钱包的质押界面或 Solana 质押计算器。

Solana 的发行模型工作原理如下:协议有一个程序化发行计划,该计划在主网启动时高于每年 8%,并每年下降 15%,目标是长期达到 1.5%。在每个时期边界,会根据当前发行率铸造新的 SOL,并根据质押权重成比例地分发为质押奖励。此发行是指协议级别的代币发行,而不是宏观经济的消费者价格指数。有关当前费率,请参阅 Solana 基金会的发行文档.

佣金费率是验证者在将剩余部分分配给委托人之前保留的质押奖励的百分比。它不是由委托人支付的交易费。佣金费率的变化仅在时期边界生效。如果您的验证者在时期中宣布提高费率,该变化不会影响您的奖励,直到下一个时期边界,给您时间自行选择重新委托。

验证者每个时期可赚取两类奖励。主要类别是来自协议铸币计划的发行奖励。次要类别是在其分配的时段内收集的交易费的 50%;剩余的 50% 交易费将被销毁,减少 SOL 的总供应量。委托人获得的大部分质押奖励来自发行部分;费用奖励是较小的贡献。

您的时期奖励可能存在差异的原因

您的质押奖励在一个时期到下一个时期之间可能存在差异,原因有四:

  1. 您的验证者的投票积分分数发生变化(错过投票会减少验证者的奖励份额,委托人获得的比例也相应减少)。
  2. 您的验证者的佣金费率在时期边界发生变化。
  3. 网络总质押量发生变化(更大的总质押池会减少您在相同发行量中的比例份额)。
  4. 发行率在年度计划里程碑处下降。

奖励会添加到您的质押账户本金中,并在下一个时期自动重新质押,实现复利,无需任何操作。

如果您的质押是新委托的,尚未显示奖励,则质押预热期可以解释原因。这将在下一节中介绍。


质押 激活与冷却期:周期如何决定您的 质押 决策

如果您的 质押 在钱包中显示为“激活中”但尚未赚取奖励,这是预期行为。新的委托不会在周期中期激活。它们会进入预热状态,并在下一个周期的开始时激活。这是设计使然,并非错误。

质押 账户状态序列:

非激活(未委托 质押)导致 激活中(当前周期内委托,尚无奖励)导致 激活(从下一个周期开始,赚取奖励)导致 取消激活(提交 赎回 请求后,无新奖励)重新回到 非激活(在冷却周期结束后可提取)。

重要提示: 质押 和 赎回 都受周期限制。在安排 质押 变动时,请为每个方向预留最多一个完整的周期(2至3天)。请参阅 Solana 的 质押 账户文档) 以获取完整协议规范。

在周期的什么时间委托很重要吗?

预热规则如下:

  1. 您在当前周期的任何时间委托 SOL。
  2. 您的 质押 账户在当前周期的剩余时间内进入“激活中”状态。
  3. 在下一个周期开始时,您的 质押 将转为“激活”状态并开始赚取奖励。
  4. 您的第一笔奖励将在该第一个激活周期结束时到账。

无论您在周期的何时委托,您的 质押 都将在下一个周期开始时激活。在周期开始时委托意味着在激活前几乎等待了整个周期。在周期结束时委托意味着只等待剩余的区块时间,可能只有几个小时。等待时间总是“直到下一个周期开始”,而不是固定的日历时长。

在周期内等待特定时间点委托,没有实质性好处。

取消 质押 需要多长时间?

取消 质押 遵循类似的流程:

  1. 您在当前周期的任何时间提交取消 质押(停用)请求。
  2. 您的 质押 账户进入“取消激活”状态。
  3. 在下一个周期开始时,将处理取消激活。
  4. 您的 SOL 在该周期结束后将变得可提取。

请预留一个完整的周期(2至3天),以便在发起取消 质押 后使您的 SOL 变得可用。

流动性 质押 协议(例如 mSOL 或 jitoSOL)处理预热和冷却的方式不同,会立即提供流动性代币。本文仅涵盖原生 质押。

验证者切换: 如果您切换验证者,旧的 质押 必须完成一个周期的冷却期,新的 质押 必须完成一个周期的预热期。此过渡可能导致错过一个完整的奖励周期。佣金率变更在周期开始时生效,因此如果您的当前验证者提高了佣金率,您将在下一个周期开始前有时间重新委托,以免新费率影响您的奖励。

三个 质押 决策,总结如下:

  1. 委托时间: 随时委托。直到下一个周期开始的等待时间,与您当前所处周期内的位置无关。
  2. 验证者切换: 考虑过渡期间可能出现的一个奖励周期空档。切换前请检查新验证者的投票信用分数。
  3. 取消委托: 计划一个完整的周期,然后您的 SOL 才会变得可用。请勿委托您可能在2至3天内需要使用的 SOL。

Solana 周期 vs. Ethereum 周期:主要区别

尽管名称相同,Solana 和 Ethereum 的周期服务于不同的目的,并且在完全不同的时间尺度上运行。此比较引用的是 Ethereum 合并后(2022 年 9 月)的权益证明架构。合并前的 Ethereum 具有不同的周期机制,此处不包含在内。

特征SolanaEthereum(合并后)
每个周期的区块数432,00032
区块时长~400 毫秒~12 秒
周期时长(实际)2 至 3 天~6.4 分钟
共识机制历史证明 + Tower BFT(PoS 变体)权益证明(Gasper/Casper FFG)
奖励分配时间每个周期开始时(~2 至 3 天)每日(独立于周期节奏)
区块生产者分配每个周期的确定性领导者计划每个区块的委员会式验证者选择

Ethereum 的周期(约 6.4 分钟)主要服务于通过 Casper FFG 进行最终性检查点和验证者委员会轮换。Ethereum 每日分配 质押 奖励,其节奏独立于其周期结构。

Solana 的周期(约 2 至 3 天)服务于领导者计划分配、 质押 奖励分配、通货膨胀代币铸造、 质押 账户状态转换和佣金率更新。所有这些功能都受周期限制。

Solana 更短的区块时长(约 400 毫秒,而 Ethereum 的约 12 秒)允许 432,000 个区块适应多天的周期窗口。Ethereum 在大约 6.4 分钟内完成 32 个区块。这两种架构反映了吞吐量和最终性节奏的不同设计优先事项。有关 Ethereum 的周期规范,请参阅 Ethereum 的合并后共识文档.


周期开始时发生什么:完整清单

在每个周期开始时,Solana 协议会自动执行一系列固定的状态转换和经济事件。

  1. 下一个周期的领导者计划是根据当前的验证者 质押 重量计算的。
  2. “激活中”状态的 质押 账户将转为完全激活并开始赚取奖励。
  3. “取消激活”状态的 质押 账户将变得完全可用且可提取。
  4. 将计算所有活跃 质押 的 质押 奖励,并分配给 质押 账户。
  5. 根据当前的通货膨胀计划铸造新的 SOL,并作为奖励进行分配。
  6. 验证者先前排队的佣金率变更将在新周期生效。
  7. 在已完成周期中累积的投票积分将被统计并为下一个周期重置。

注意: 事件 2 至 5 和事件 7 是自动发生的。验证者和委托者无需采取任何操作。事件 6 是唯一需要验证者提前输入(设置新的佣金率)的事件。

事件 2 和 3 对委托者最为重要:这是新委托的 质押 变为激活状态以及取消 质押 的 SOL 变得可提取的时刻。

事件 1 对验证者运营商最为重要:下一个周期的区块分配在此刻锁定,基于周期开始时的快照 质押 重量。

事件 4 和 5 协同工作:通货膨胀计划铸造新的 SOL,然后根据 质押 重量和投票积分分数,将新铸造的 SOL 按比例分配为 质押 奖励。

事件 6 记录了一项大多数面向 质押 者的内容都忽略的规则。验证者不能在周期中间更改其佣金率。在周期内宣布的任何变更将在周期开始时生效,这给了委托者前一个周期时间来观察变更,并在需要时重新委托。


Solana 的通货膨胀模型和基于周期的代币经济学

Solana 的 质押 奖励不来自固定池。它们是通过协议内置的程序化通货膨胀计划在每个周期生成的。

这里的“通货膨胀”特指协议层面的新 SOL 代币发行,而非宏观经济的消费者价格通胀。这两个概念是不同的,不应混淆。

通货膨胀计划:Solana 最初的年通货膨胀率为 8% 以上。该比率在通货紧缩模型下每年下降 15%,朝着长期目标 1.5% 迈进。在每个周期开始时,将根据当前的通货膨胀率铸造新的 SOL,并按 质押 重量比例分配给验证者及其委托者。这就是 质押 奖励的来源:每位委托者都会获得该周期内新 SOL 发行的份额。

验证者赚取两类 epoch 奖励。主要类别是来自铸币计划的通货膨胀奖励。第二类是其分配的 slot 中收集的交易费用的 50%;剩余的 50% 被销毁,减少了总 SOL 供应量。通货膨胀部分是委托人质押奖励的主要驱动因素。

通货膨胀率每年都在下降。有关当前费率,请参阅 Solana 基金会的通货膨胀文档.)。文章中引用的任何特定费率都会随着计划的推进而过时。


如何查看当前的 Solana Epoch

三个区块浏览器提供实时的 Solana epoch 数据,每个都会随着 slot 的处理而自动更新。

注意: Epoch 号大约每 2 到 3 天更改一次。文章中引用的任何特定 epoch 号都会在您阅读时过时。使用下面的工具获取当前数据。

步骤 1: 访问 Solana Beach。主页上的 epoch 小部件显示当前的 epoch 号、当前 epoch 中已过去的 slots、剩余的 slots 以及到下一个 epoch 边界的预计时间。

步骤 2: 访问 Solscan (solscan.io)。网络统计面板中的“Epoch”标签显示当前的 epoch 数字,以及按 epoch 细分的验证者性能数据。

步骤 3: 访问 Solana Explorer (explorer.solana.com)。集群统计面板显示 epoch 信息、slot 高度和交易计数。

开发者还可以从命令行查询 epoch 数据:

solana epoch-info

此命令返回当前的 epoch 数字、epoch 内的 slot 索引以及剩余的 slots。

要以编程方式访问 epoch 数据,包括在链上程序或通过 JSON-RPC 读取 epoch 配置,请参阅下面的开发者部分。EpochSchedule sysvar 是 epoch 配置数据的链上来源。


开发者指南:通过 EpochSchedule Sysvar 和 RPC 访问 Epoch 数据

本节介绍为开发者构建基于 epoch 的 Solana 应用程序的程序化访问 epoch 数据的方法。非技术读者可以跳至 FAQ 部分。

需要基于 epoch 的逻辑来处理实施 epoch 限制的代币归属、治理投票期、周期性协议再平衡以及验证者性能跟踪的应用程序。

EpochSchedule Sysvar

一个 sysvar 是一个特殊的只读 Solana 系统账户,它将网络配置数据暴露给链上程序。EpochSchedule Sysvar 暴露了 epoch 计划配置,其中包括:

  • slots_per_epoch: 432,000(主网的协议常量)
  • leader_schedule_slot_offset: 432,000(计算 leader 计划时使用的偏移量)
  • warmup: bool(初始 epoch 预热期是否激活)
  • first_normal_epoch: 具有完整 slot 数量的第一个 epoch
  • first_normal_slot: 第一个正常 epoch 的第一个 slot

EpochSchedule 是 Solana 的多个 sysvars 之一;其他(Clock、Rent、StakeHistory、SlotHashes)在此不作介绍。完整的字段定义可在 EpochSchedule sysvar 文档.) 中找到

slots_per_epoch 值(432,000)是所有 epoch 持续时间计算的基础固定协议常量。PoH slot 定时是 EpochSchedule 计算的基础:sysvar 暴露了计划结构,而实际的实际时间取决于真实的 slot 处理速度。

通过 getEpochInfo RPC 方法读取 epoch 数据

getEpochInfo JSON-RPC 方法返回当前的 epoch 状态。使用空的 params 数组调用它:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getEpochInfo",
  "params": []
}

响应:

{
  "jsonrpc": "2.0",
  "result": {
    "absoluteSlot": 166598,
    "blockHeight": 166500,
    "epoch": 27,
    "slotIndex": 2790,
    "slotsInEpoch": 432000,
    "transactionCount": 22661093
  },
  "id": 1
}

字段说明:

  • absoluteSlot: 整个链历史中的当前 slot 号
  • blockHeight: 当前的 block 高度
  • epoch: 当前 epoch 号
  • slotIndex: 当前 epoch 内的 slot 索引(范围从 0 到 431,999)
  • slotsInEpoch: 在主网上始终为 432,000(协议常量)
  • transactionCount: 截至目前处理的总交易数

slotIndex 值告诉您当前 epoch 的进度。将 slotIndex 从 slotsInEpoch (432,000) 中减去,即可计算出当前 epoch 剩余的 slots。

关键区别:EpochSchedule 暴露了固定的计划配置数据;getEpochInfo 返回动态的当前状态。使用 EpochSchedule 读取计划参数;使用 getEpochInfo 或 Clock sysvar 在运行时读取当前的 epoch 号。

在链上程序中访问当前的 epoch 号

要在链上程序中读取当前的 epoch 号,请访问 Clock sysvar。epoch 字段将当前的 epoch 号作为 u64 返回。

use solana_program::sysvar::clock::Clock;
use solana_program::sysvar::Sysvar;


// 在您的指令处理程序内:
let clock = Clock::get()?;
let current_epoch: u64 = clock.epoch;
// current_epoch 现在持有当前的 Solana epoch 号

此模式适用于任何需要按 epoch 限制逻辑的链上程序:在特定 epoch 号释放归属代币、将治理投票限制在定义的 epoch 窗口内,或按 epoch 跟踪验证者性能。


关于 Solana Epoch 时间的常见问题解答

以下问题解答了关于所有五个“其他人也问”集群中 Solana epochs 的最常见搜索。

Solana epoch 是一个固定周期,精确持续 432,000 个连续 slot,在实际条件下大约持续 2 到 3 天。每个 epoch 结构化了 Solana 网络如何将区块生产责任分配给验证者、累积投票积分、分发质押奖励、通过通货膨胀铸造新的 SOL,以及处理质押账户状态变更。所有这些事件都在 epoch 边界自动发生。

一个 Solana epoch 有几天?

一个 Solana epoch 包含正好 432,000 个 slot。按照协议目标 slot 持续时间 ~400 毫秒/slot,理论最小值约为 2.0 天(48 小时)。实际上,跳过的 slots 和网络条件会将实际 epoch 持续时间推高到 2 到 3 天之间。每个 epoch 的 slot 数量是固定的协议常量;实际持续时间是可变的。

Solana 质押奖励在每个 epoch 结束时自动分发,大约每 2 到 3 天一次。无需手动操作。在 epoch 边界,协议根据委托人的质押占总质押 SOL 的比例份额、其验证者在该 epoch 的投票积分分数以及当前的通货膨胀率来计算每个委托人的奖励。奖励直接存入委托人的质押账户并自动再质押。

当您委托 SOL 时,您的质押将进入“激活中”状态,直到下一个 epoch 边界才能获得奖励。此预热期可能需要几小时(如果您在 epoch 结束前委托)到近 2 到 3 天(如果您在 epoch 开始时委托)。激活时间由下一个 epoch 边界决定,而不是自您委托以来经过的时间。

在每个 Epoch 边界,Solana 协议都会自动执行七项事件:(1) 根据当前的质押权重计算下一个 Epoch 的领导者计划 (Leader Schedule);(2) 激活中的质押账户变为完全激活状态;(3) 停用中的质押账户变为可提现状态;(4) 计算并分发质押奖励;(5) 根据通胀时间表铸造新的 SOL;(6) 排队中的验证者佣金率更改正式生效;(7) 统计并重置投票积分 (Vote Credits)。

Solana 领导者计划是如何运作的?

领导者计划是将验证者分配到 Epoch 内特定 Slot(插槽)的确定性、预先计算的安排。在每个 Epoch 边界,网络会根据当时每个验证者的质押权重,计算出在整个即将到来的 Epoch 中,哪个验证者被分配到哪些 Slot。任何节点都可以通过相同的输入独立计算出相同的计划。质押权重较大的验证者会被分配成比例更多的 Slot。

Solana 的 Epoch 与以太坊的相比如何?

Solana 的 Epoch 由 432,000 个 Slot 组成,持续时间约 2 到 3 天。以太坊的 Epoch(合并后)由 32 个 Slot 组成,持续时间约 6.4 分钟。两者的用途不同:Solana 的 Epoch 决定了领导者计划分配、奖励分发和通胀铸币;以太坊的 Epoch 则通过 Casper FFG 处理最终性检查点和验证者委员会轮换。以太坊每天分发质押奖励,其节奏与其 Epoch 结构是分开的。

如何查看当前的 Solana Epoch?

有三个工具提供实时 Epoch 数据:Solana Beach 在其首页显示当前 Epoch 编号、已用 Slot 和剩余时间。Solscan (solscan.io) 在其网络统计面板中提供 Epoch 数据。Solana Explorer (explorer.solana.com) 在集群统计面板中显示 Epoch 信息。开发者还可以通过 Solana CLI 运行 solana epoch-info。Epoch 编号大约每 2 到 3 天更改一次。

在错误的时间进行委托会损失奖励周期吗?

在任何特定时间进行委托都不会永久损失奖励周期。无论您在 Epoch 的哪个时间点进行委托,您的质押都会在下一个 Epoch 边界开始时激活,并从那时起赚取奖励。如果您在 Epoch 快结束时委托,您的“热身”等待时间较短;如果您在开始时委托,则需要等待将近一个完整的 Epoch。您并不会错失奖励,只是推迟了第一个收益 Epoch 的开始时间。

每年会发生多少个 Solana Epoch?

按每个 Epoch 2.0 天的理论最小值计算,每年大约有 182 个 Epoch(365 天除以每 Epoch 2.0 天)。按更典型的现实时长每 Epoch 2.5 天计算,每年大约有 146 个 Epoch。确切的计数取决于全年的网络表现。

Solana 的 Epoch 年化收益是多少?

Solana 的质押年化收益并不是固定的,不能用单一数字表示。其关系大致为:(年通胀发行量除以总质押 SOL)乘以(1 减去您的验证者佣金率)。由于通胀率和总质押 SOL 都会随时间变化,年化收益在每个 Epoch 也会发生变化。如需当前估算值,请使用您的钱包质押界面、Solana 质押计算器,或参考 Solana 基金会的通胀文档。


利用 Epoch 知识做出更好的质押决策

Solana Epoch 是网络的基本协调周期:432,000 个 Slot,约 2 到 3 天,所有经济事件都在每个 Epoch 边界自动触发。

阅读本文后,您现在可以满怀信心地完成以下四件事:

  1. 定义什么是 Solana Epoch:一个由正好 432,000 个连续 Slot 组成的固定周期,用于构建验证者计划、奖励分发和通胀。
  2. 明确其持续时间:在现实条件下约 2 到 3 天,根据 Slot 处理速度而变化。
  3. 解释持续时间为何会变化:跳过的 Slot、网络拥堵以及历史性的停机都可能使实际时间超过理论上的 2.0 天最小值。
  4. 了解奖励何时到达以及质押何时激活:两者都自动发生在 Epoch 边界,无需任何操作。

关于您在 Solana (SOL) 进行质押活动的三个实用建议:

  1. 质押奖励大约每 2 到 3 天发放一次,自动存入您的质押账户。
  2. 为新委托的 SOL 预留 2 到 3 天的激活时间,之后才能期待第一笔奖励。
  3. 如果更换验证者,请考虑到在过渡期间可能会有一个 Epoch 的奖励缺口,并核实新验证者的投票积分得分。

将 Solana Beach 或 Solscan 存为书签,以便在奖励周期之间追踪当前 Epoch 和您验证者的投票积分得分。


本文仅供信息和教育目的,不构成财务或投资建议。质押加密货币涉及风险,包括损失风险。在做出质押或投资决定之前,请务必自行研究。Solana 协议参数和网络统计数据(包括通胀率和平均 Epoch 持续时间)可能会发生变化。有关当前数据,请参考 Solana 基金会的官方文档或 Solana 区块浏览器。

相关 Solana 技术指南

研究质押相关产品的读者可以分别查看 Bybit 赚币) 和 SOL 价格页面)。产品可用性、条款和风险因地区而异,并随时间变化。