Validators 信息 API 文档

什么是 Validators 信息(getValidatorsInformation)API?

getValidatorsInformation 是一个扩展 Solana RPC 方法,用于返回当前 epoch 中至少领导一个 slot 的 validator,并把 stake weight、网络端点元数据、估算的 leader 位置与参考延迟测量合并为每个 validator 一条记录。它不会返回网络上所有节点的列表,也不会返回 RPC 节点。持有 ERPC 使用额度(API token)的用户,可以用与标准 Solana RPC 相同的格式调用。
此 API 提供:
  • 当前 epoch 中领导 slot 的每个 validator 一条记录,slotCount 表示它领导的 slot 数量——与每个 slot 一条记录的 getLeaderSlots 不同
  • 每个 leader validator 的 stakeWeight
  • 估算的 leader region、city、country、坐标、ASN organization 与 timezone
  • ERPC 观测 region 到 leader 的参考 ping 测量(pingToLeaders

端点和请求体示例

text
https://edge.erpc.global?api-key=<YOUR_API_KEY>
所有参数均为可选;省略 params 或传入 params: [],将返回当前 epoch 中领导 slot 的全部 validator。
json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getValidatorsInformation",
  "params": []
}
要缩小结果范围,可传入包含 limitcountryregion 的对象。下面的示例请求德国境内最多 5 个 validator,其消耗也低于上面未筛选的请求。
json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getValidatorsInformation",
  "params": [{ "limit": 5, "country": "DE" }]
}
这三个参数均为可选。country 使用 ISO 3166-1 alpha-2 代码与 leaderCountry 匹配,不区分大小写。regionleaderRegion 做区分大小写的完全匹配——可先发送未筛选的请求,从响应中读取 leaderRegion,以了解目标 validator 的有效取值。limit 接受 1 到 2000,并会收敛为该 epoch 中 validator 的实际数量,因此超过实际数量的 limit 不会报错。

示例(HTTP)

bash
curl 'https://edge.erpc.global?api-key=<YOUR_API_KEY>' \
  --header 'Content-Type: application/json' \
  --data '{
    "jsonrpc":"2.0",
    "id":1,
    "method":"getValidatorsInformation",
    "params":[]
  }'

响应示例(JSON)

result.total 表示本次请求返回的 validator 数量。下面的 data[] 数组从本 epoch 的 670 条记录中摘录了三条,并且为便于阅读,每条记录的 pingToLeaders 只保留了一个观测 region。
json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "success": true,
    "message": "Validator information retrieved successfully",
    "epoch": 1010,
    "total": 670,
    "totalValidators": 670,
    "data": [
      {
        "identity": "JupmVLmA8RoyTUbTMMuTtoPWHEiNQobxgTeGTrPNkzT",
        "gossipNodeId": 2233,
        "slotCount": 13232,
        "stakeWeight": 12254651.761860535,
        "ipAddress": "64.130.41.46",
        "gossipPort": 8000,
        "tpuPort": 9001,
        "tpuQuicPort": 9007,
        "rpcAddress": null,
        "version": "3.1.13",
        "featureSet": "534737035",
        "leaderRegion": "frankfurt",
        "leaderCity": "Frankfurt am Main",
        "leaderCountry": "DE",
        "leaderLat": 50.1924,
        "leaderLon": 8.6753,
        "leaderOrg": "AS20326 TeraSwitch Networks Inc.",
        "leaderTimezone": "Europe/Berlin",
        "pingToLeaders": [
          {
            "city": "Frankfurt am Main",
            "region": "frankfurt",
            "ms": 0.974,
            "icmpReplied": true,
            "fromIp": "185.191.118.11",
            "country": "DE",
            "lat": 50.139,
            "lon": 8.6725,
            "org": "AS213896 UAB Cherry Servers",
            "postal": "60320",
            "timezone": "Europe/Berlin",
            "measuredAt": "2026-08-01T06:02:18.000Z"
          }
        ]
      },
      {
        "identity": "BSVckjdW2f8kcXPGcrPPtV9kUDBZ8w8PjrrGVnxgEdwq",
        "gossipNodeId": 1487,
        "slotCount": 2704,
        "stakeWeight": 2502391.138720913,
        "ipAddress": "5.199.172.175",
        "gossipPort": 12000,
        "tpuPort": 12003,
        "tpuQuicPort": 12009,
        "rpcAddress": null,
        "version": "3.1.13",
        "featureSet": "534737035",
        "leaderRegion": "stockholm",
        "leaderCity": "Šiauliai",
        "leaderCountry": "LT",
        "leaderLat": 55.93333,
        "leaderLon": 23.31667,
        "leaderOrg": "AS16125 UAB Cherry Servers",
        "leaderTimezone": "Europe/Vilnius",
        "pingToLeaders": [
          {
            "city": "Frankfurt am Main",
            "region": "frankfurt",
            "ms": 27.742,
            "icmpReplied": true,
            "fromIp": "185.191.118.11",
            "country": "DE",
            "lat": 50.139,
            "lon": 8.6725,
            "org": "AS213896 UAB Cherry Servers",
            "postal": "60320",
            "timezone": "Europe/Berlin",
            "measuredAt": "2026-08-01T06:02:53.000Z"
          }
        ]
      },
      {
        "identity": "2oHUYyW2PU9VJh4XBs5TbGgzdernunvGqyKth3kxW4ns",
        "gossipNodeId": 902,
        "slotCount": 304,
        "stakeWeight": 280745.689124988,
        "ipAddress": "64.130.43.229",
        "gossipPort": 8001,
        "tpuPort": 5004,
        "tpuQuicPort": 5010,
        "rpcAddress": null,
        "version": "3.1.13",
        "featureSet": "534737035",
        "leaderRegion": "amsterdam",
        "leaderCity": "Amsterdam",
        "leaderCountry": "NL",
        "leaderLat": 52.37403,
        "leaderLon": 4.88969,
        "leaderOrg": "AS20326 TeraSwitch Networks Inc.",
        "leaderTimezone": "Europe/Amsterdam",
        "pingToLeaders": [
          {
            "city": "Frankfurt am Main",
            "region": "frankfurt",
            "ms": 16.835,
            "icmpReplied": true,
            "fromIp": "185.191.118.11",
            "country": "DE",
            "lat": 50.139,
            "lon": 8.6725,
            "org": "AS213896 UAB Cherry Servers",
            "postal": "60320",
            "timezone": "Europe/Berlin",
            "measuredAt": "2026-08-01T06:03:07.000Z"
          }
        ]
      }
    ]
  }
}

响应字段

字段含义
result.success请求是否成功。
result.message可读的状态消息。
result.epoch所返回 leader 集合所属的 epoch。这是 leader schedule 中最新的 epoch。
result.totaldata 中的 validator 数量。计费依据的就是这个数量。
result.totalValidators应用 countryregionlimit 之前,该 epoch 中的 leader validator 数量。与 result.total 对比即可看出筛选缩小了多少范围。
result.data[]每个 validator 一条记录,按 slotCount 降序排列,其次按 identity 排序,因此设置 limit 时返回的是领导 slot 最多的 validator。
identityValidator identity 公钥。
gossipNodeId与该 validator 关联的 gossip 节点记录的标识符。未关联 gossip 节点时为 null,此时位置、端口与 ping 字段同样为空。没有关联 gossip 节点的 validator 会出现在未筛选的请求中,但无法满足 countryregion 筛选。
slotCount该 validator 在所报告 epoch 中领导的 slot 数量。每条记录对应一个 validator,而不是一个 slot。
stakeWeight该 validator identity 的激活质押量,单位为 SOL。没有关联 gossip 节点的 validator 返回 0
ipAddress, gossipPort, tpuPort, tpuQuicPort, rpcAddress该 validator 的 gossip 网络端点元数据。
version, featureSet该 validator 报告的 Solana 客户端版本与 feature set。
leaderRegion用于路由与分析的规范化运营 region 标签。它可能会把邻近的城市或服务商位置归为一组,也是 region 请求参数所匹配的值。
leaderCity, leaderCountry, leaderLat, leaderLon, leaderOrg, leaderTimezone该 validator 的估算地理位置与网络组织。
pingToLeaders[]从各个 ERPC 观测 region 到该 validator 的参考延迟,包含 region、city、ms、icmpReplied、fromIp、country、坐标、ASN organization、邮政编码、timezone 与 measuredAt。
pingToLeaders[].icmpReplied该 validator 是否回应了本次测量。为 false 时,ms 中是预置的哨兵值而不是延迟实测值,不应按延迟解读。
pingToLeaders[].measuredAt最近一次测量该延迟的时间,采用 ISO-8601 UTC 格式。可用它判断读数的新鲜程度。

可视化 Validator 覆盖

同一响应可以按 epoch 级别的覆盖分布来阅读,而不是按 slot 逐条查询。下面示例以 Frankfurt 作为观测点。
Validator region位置epoch 内 slot 数Stake weight来自 Frankfurt 的 ping运营含义
frankfurtFrankfurt am Main, DE13,23212,254,651.760.974 ms本 epoch 约 432,000 个 slot 中的 13,232 个,且位于同一 metro。Frankfurt 的资源在整个 epoch 都在服务该 validator,而不只是在某一个 slot 窗口内。
stockholmŠiauliai, LT2,7042,502,391.1427.742 ms在 epoch 中反复占有一定比例,但这个延迟由另一个欧洲位置来服务会更好。
amsterdamAmsterdam, NL304280,745.6916.835 ms每个 epoch 的 slot 很少。路径虽然短,但仅凭这一点还不足以成为部署资源的理由。
getLeaderSlots 回答的是接下来的 slot 由哪些 validator 领导,因此适合当下的交易路由;本方法回答的是整个 epoch 中究竟有哪些 validator 领导、各自领导多少次,因此适合决定该 epoch 的资源应当部署在何处。

Solana 网络数据网站

Validators Solutions - Solana network data
网络分布的公开视图可以通过 Validators Solutions 查看,随后使用 getValidatorsInformation 获取每个 validator 的 slot 数量、stake、位置与实测延迟。

Token 使用量

该方法按实际返回的 validator 数量计费,以 10 个为一个计费单位:每 10 个 validator 收取 100 tokens,不足一个单位也按一个完整单位计算。因此返回 95 个 validator 时按 10 个单位计费,即 1,000 tokens。
由于计费依据的是实际返回的数量而不是请求的数量,用 countryregion 缩小范围会按比例减少消耗,没有匹配到任何 validator 的请求则不计费。超过该 epoch 中 validator 数量的 limit 会被收敛为实际数量,因此请求不会为不存在的 validator 付费。
leader 集合的规模会随 epoch 变化。在上面示例的 epoch 中为 670 个 validator,因此完整读取大约需要 6,700 tokens。

为什么 Validator 信息重要

  • 每个 validator 一条记录,可直接回答本 epoch 由谁领导、领导多少,无需在客户端聚合数十万条 slot 记录。
  • slotCount 表明某个 validator 在本 epoch 中出任 leader 的频率,因此通往高 slotCount validator 的短路径会反复带来收益。
  • countryregion 表明该 epoch 的 leader 资源实际位于何处。
  • Ping 结合 measuredAt 可以区分「路径慢」与「读数过时」。

背景

一个 Solana epoch 大约包含 432,000 个 slot。将这些 slot 的 leader 分配按 validator identity 归组之后,会收敛为大约 670 条 validator 记录。ERPC 维护 leader schedule、validator metadata、geolocation 与 latency 采集,并通过 RPC 接口提供结果。

战略使用场景

  • epoch 级容量规划:按当前 epoch 全部 leader validator 的集合来规划基础设施规模,而不是按滚动的 slot 窗口。
  • 区域候选名单:使用 countryregion 提取在目标位置领导 slot 的 validator。
  • 结合 slot 数与 stake 的优先级排序:组合 slotCountstakeWeight,在候选名单内对 validator 排序。
  • 跨 epoch 监控:比较不同 epoch 之间的 leaderRegion 分布,观察 leader 地理分布如何变化。

可用性

getValidatorsInformation 对所有 ERPC 用户可用。API token 与使用额度可在 ERPC Web 仪表盘发行或确认。

交易成功率与 SWQoS Endpoint

若要进一步提高交易成功率和执行速度,建议使用 SWQoS Endpoint。SWQoS(Stake-weighted Quality of Service)会优先处理拥有 stake connection 的 validator。Leader 大约将 80% 带宽分配给 priority traffic,20% 分配给 non-priority traffic,priority lane 约有 5 倍 throughput。该调度发生在 Priority fee 评估之前,因此进入 SWQoS priority lane 是实现真正低延迟性能的前提。