ERPC 扩展 Solana Leader Slot API：新增全球 7 个区域的 Ping 测量，Validators Information API 同步上线
ERPC 运营方 ELSOUL LABO B.V.（总部位于荷兰阿姆斯特丹；代表董事兼 CEO：Fumitake Kawasaki）与 Validators DAO 增强了用于了解 Solana leader 信息、估算位置和延迟的 API：Leader Slot API 现已支持来自全球 7 个区域的参考 RTT（ping 测量），并推出全新的 Validators Information API。
首先，我们扩展了 Leader Slot API（
getLeaderSlots），现在可获取来自全球 7 个 ERPC 观测区域（法兰克福、阿姆斯特丹、纽约、伦敦、东京、新加坡和悉尼）的参考 RTT。此前仅从法兰克福进行测量。同时，我们推出了全新的 Validators Information API（
getValidatorsInformation）。该 API 一次调用即可列出当前 epoch 中所有至少拥有一个 leader slot 的验证节点。除 slot 数和活跃质押量外，在有可用数据时还会返回估算位置、网络端点、客户端版本及来自 7 个区域的参考 RTT。所有 ERPC 用户均可通过标准 JSON-RPC 接口使用这两项 API。
- Leader Slot API 文档：https://erpc.global/zh/doc/rpc/leader-slot-api/
- Validators Information API 文档：https://erpc.global/zh/doc/rpc/validators-information-api/
Solana 与传统交易基础设施的不同：通信目标动态变化
在传统交易所和金融系统中，订单发送目标——交易所、网关、撮合引擎——通常固定在特定数据中心或网络。
因此，用户一旦知道连接目标，就可以持续优化通往该目标的网络路径。由于目标服务器的位置不会频繁变化，基础设施部署和通信路由可以采用相对静态的设计。
相比之下，在 Solana 上，负责生成区块的 leader 会按照 leader 时间表每隔几个 slot 轮换。由于担任 leader 的验证节点分布在全球各地，交易必须到达的目标，以及最接近该目标的网络路径都在持续变化。
换句话说，在 Solana 上，需要优化的通信目标无法被视为固定、单一的连接点。
首先需要根据 leader 时间表确定当前和未来的 leader。在此基础上，再确认各验证节点最可能位于哪个区域或网络，以及从不同发送位置到达它的延迟，最后决定发送路由。
正确理解这一结构，是 Solana 上低延迟交易发送与全球基础设施设计的起点。
将 leader 时间表与网络位置作为数据使用
在通信目标动态变化的环境中，每次都由人工查看 leader 和发送位置再手动切换路由，并不现实。
需要的是持续获取以下信息，并将其纳入应用与基础设施的判断逻辑。
- 负责当前及即将到来的 slot 的 leader
- 每个验证节点负责的 slot 数量
- 每个验证节点的估算国家、城市和区域
- TPU、QUIC 等网络端点
- 从各观测区域获取的参考 RTT
- 每次测量的时间和响应状态
估算位置和实测延迟分别发挥不同作用。
位置信息可用于决定中长期应在何处部署基础设施和容量；来自各区域的参考 RTT，则可用于判断当前从哪个位置最有可能获得较短的网络路径。
物理或地理位置较近，并不一定意味着网络路径最短。因此，将估算位置与实际观测值结合起来作出判断十分重要。
ERPC 的 Leader Slot API 与 Validators Information API 正是为将这些数据驱动的判断编入程序而设计。
Leader Slot API：测量来自全球 7 个区域的参考 RTT
Leader Slot API 会返回即将到来的 leader slot，并附带验证节点身份、活跃质押量、网络端点、估算位置、参考 RTT 等信息。
此前，
pingToLeaders 仅从法兰克福源点采集测量数据——面对全球分布的 Solana 网络，只有这一个观测点。本次更新后，可获取从以下 7 个区域测得的参考 RTT。
frankfurtamsterdamnylondontokyosingaporesydney
通过比较各 leader 在 7 个观测区域的参考 RTT，可以判断哪个发送位置最可能提供较短的网络路径。
这不仅可用于决定交易路由，也可为确定应在哪些区域部署 RPC、gRPC、Direct Shreds 和交易发送服务器等服务的容量提供依据。
测量结果包含
icmpReplied（表示验证节点是否响应 ICMP）和 measuredAt（表示最后一次成功取得测量值的时间）。不响应 ICMP 的验证节点仍可能正常运行 TPU、QUIC 等服务。因此，当
icmpReplied 为 false 时，应理解为“无法通过 ICMP 测量”，而不是“距离较远”。此外，如果刷新时未能成功测量，系统不会用未测量值覆盖现有条目，而会保留最后一次成功测得的数值及其测量时间。
Validators Information API：列出整个 epoch 的 leader 信息
Leader Slot API 适合回答“接下来几个 slot 的 leader 是谁”这类 slot 级决策问题。
另一方面，基础设施部署与容量规划需要更宏观的视角。
- 当前 epoch 中哪些验证节点担任 leader
- 每个验证节点负责多少个 slot
- 分布在哪些国家与区域
- 基础设施部署在哪些区域才能接近更多 leader
全新的 Validators Information API（
getValidatorsInformation）正是为回答这些问题而设计。不带参数调用时，它会为当前 epoch 中至少负责一个 leader slot 的每个验证节点返回一行数据。默认按所拥有的 leader slot 数量从多到少排序。
每行包含以下信息。
slotCountstakeWeight（以 SOL 计的活跃质押量）- 验证节点身份
在可获取的情况下，还会返回以下信息。
- 估算区域、城市和国家
- 网络端点
- 客户端版本
- 来自 7 个区域的参考 RTT
数据会定期刷新，因此定期调用该 API 即可让规划数据集保持最新。
还可使用可选参数
limit（1–2000）、country 和 region 筛选结果。费用按返回的验证节点数量计算。担任 leader 的验证节点数量会随 epoch 变化；以撰写本文时的示例为准，获取全部 673 个验证节点会使用 6,800 API tokens（ERPC API 使用额度），获取最多 10 个验证节点会使用 100 API tokens。
迈向数据驱动的可编程路由
这些 API 并非只用于显示验证节点列表或参考 RTT。
最终目标是让用户将 leader 时间表、验证节点的估算位置及各观测区域的参考 RTT 纳入应用决策逻辑。
例如，应用可以获取即将到来的 leader 时间表，比较每个 leader 在 7 个观测区域的参考 RTT，再选择要使用的 RPC 或交易发送路由。
用户也可以分析整个 epoch 的 leader 分布，预先把基础设施部署在靠近负责较多 slot 的验证节点的区域。
主要用途如下。
- 以 slot 为单位选择发送路径
- 以 epoch 为单位进行容量规划
- 按区域分析 leader 验证节点
- 根据活跃质押量和 slot 数量确定优先级
- 监控每个 epoch 的地理与网络分布变化
- 在部署于多个区域的 RPC 与发送服务器之间自动选择
在通信目标动态变化的 Solana 上，仅靠静态网络优化并不足够。
持续跟踪不断变化的 leader，并根据其位置和网络状况动态选择发送路由及基础设施，会变得越来越重要。
面向全球运营设计的 Solana 基础设施
ERPC 是专为 Solana 打造的高性能基础设施，从设计之初就以全球运营为前提。
我们的边缘网络、裸金属服务器与 VPS、Direct Shreds、Geyser gRPC、SWQoS 端点，以及这些运维信息 API，都服务于同一个目标。
这个目标是：在用户和 leader 分布于全球各地的环境中，为追求低延迟和高效执行的开发者同时提供数据与基础设施。
如今，只需简单的 RPC 调用，即可获取来自全球 7 个区域的参考 RTT 和覆盖整个 epoch 的验证节点信息。Solana 应用可以针对不断变化的 leader，基于数据选择发送位置和网络路由。
对于希望在 Solana 上实现低延迟交付、全球基础设施部署和动态路由优化的开发者，这些数据可直接为实际运营决策提供依据。
我们希望这些功能能帮助用户选择低延迟发送路由、设计可减少不必要长距离传输的基础设施，并规划全球容量部署。
详情请参阅文档：
- Leader Slot API：https://erpc.global/zh/doc/rpc/leader-slot-api/
- Validators Information API：https://erpc.global/zh/doc/rpc/validators-information-api/
- ERPC Web Dashboard：https://dashboard.erpc.global/zh
