如何使用 getEpochSchedule

​

常见用例

• 预测 Epoch 边界： 确定 epoch 中的插槽数量，以估计当前 epoch 何时结束以及下一个 epoch 何时开始。
• 领导者计划计算： 理解 leaderScheduleSlotOffset 以了解为即将到来的 epoch 生成领导者计划的提前时间。
• 分析网络初始化： 观察 warmup、firstNormalEpoch 和 firstNormalSlot 以了解集群 epoch 长度的初始启动阶段（如果适用）。
• 构建网络监控工具： 使用此信息准确显示 epoch 的时间和进度。

​

请求参数

​

响应结构

• slotsPerEpoch (u64)：每个 epoch 的最大插槽数（如果有预热期，则在预热期之后）。
• leaderScheduleSlotOffset (u64)：在 epoch 开始之前生成该 epoch 的领导者计划的插槽数。
• warmup (boolean)：一个布尔值，指示集群是否有一个预热期，在此期间 epoch 开始较短并逐渐增加长度。
• firstNormalEpoch (u64)：具有完整 slotsPerEpoch 长度的第一个 epoch 编号。如果 warmup 为 true，则此字段相关。
• firstNormalSlot (u64)：firstNormalEpoch 中第一个插槽的插槽索引。如果 warmup 为 true，则此字段相关。

​

示例

​

1. 获取集群的 Epoch 计划

curl https://mainnet.helius-rpc.com/?api-key=<api-key> -X POST -H "Content-Type: application/json" -d \
  '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getEpochSchedule"
  }'

​

开发者提示

• 静态信息： Epoch 计划由集群的创世配置决定，通常不会改变，除非有重大网络升级或使用不同参数的新集群启动。
• 主网与测试网/开发网： Epoch 计划，特别是 slotsPerEpoch 和 warmup 参数，在主网 Beta、测试网和开发网之间可能有显著差异。始终查询您感兴趣的特定集群。
• 预热期： 如果 warmup 是 true，那么在 firstNormalEpoch 之前的 epochs 将比 slotsPerEpoch 拥有更少的 slots。预热 epoch 长度的精确计算是 2^N * MINIMUM_SLOTS_PER_EPOCH，其中 N 是 epoch 编号（从 0 开始）直到达到 firstNormalEpoch。通常 MINIMUM_SLOTS_PER_EPOCH 是 32。