ERPC 擴展 Solana Leader Slot API:新增全球 7 個區域的 Ping 測量 — Validators Information API 同步上線

ERPC 擴展 Solana Leader Slot API:新增全球 7 個區域的 Ping 測量 — Validators Information API 同步上線

ERPC 擴展 Solana Leader Slot API:新增全球 7 個區域的 Ping 測量 — Validators Information API 同步上線
由 ELSOUL LABO B.V.(總部:荷蘭阿姆斯特丹,代表董事暨 CEO:Fumitake Kawasaki)和 Validators DAO 運營的 ERPC,已強化用於掌握 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 的所有 validator。除了擔當 slot 數與有效 stake 數量之外,在可取得的情況下,還會返回估計位置、網路端點、客戶端版本,以及來自 7 個區域的參考 RTT。
兩個 API 均可透過標準 JSON-RPC 介面提供給所有 ERPC 用戶。

與傳統交易基礎設施的差異:Solana 的通訊對象會動態變化

在傳統的交易所與金融系統中,送出訂單的目的地 — 交易所、閘道、撮合引擎等 — 通常固定於特定的資料中心或網路。
因此,用戶一旦掌握連接對象,便能持續優化通往該對象的網路路徑。由於目標伺服器的位置不會頻繁變動,基礎設施的部署與通訊路徑也能相對固定地設計。
另一方面,在 Solana 上,負責產生區塊的 Leader 會依照 Leader 排程每隔幾個 slot 輪換一次。由於擔任 Leader 的 validator 分佈於世界各地,交易需要送達的對象以及最接近該對象的網路路徑都會持續變化。
換句話說,在 Solana 上,需要優化的通訊對象無法被視為固定、單一的連接點。
首先必須從 Leader 排程掌握現在與未來的 Leader 是誰。在此基礎上,確認每個 validator 最可能位於哪個地區或網路,以及從各發送位置的延遲程度,再決定發送路徑。
正確理解這個結構,是 Solana 上低延遲交易發送與全球基礎設施設計的起點。

將 Leader 排程與網路位置視為資料

在通訊對象動態變化的環境中,由人員每次確認 Leader 與發送位置、再手動切換路徑,並不實際。
需要的是持續取得以下資訊,並將其納入應用程式與基礎設施的判斷邏輯。
  • 負責現在與即將到來的 slot 的 Leader
  • 每個 validator 擔當的 slot 數
  • 每個 validator 估計的國家、城市與區域
  • TPU、QUIC 等網路端點
  • 從各觀測區域取得的參考 RTT
  • 測量值的取得時間與回應狀態
估計位置與實測延遲各自扮演不同的角色。
位置資訊可用於基礎設施與容量應配置於何處的中長期判斷。另一方面,來自各區域的參考 RTT,則是判斷目前從哪個位置最有可能以較短路徑抵達的依據。
物理上或地理上接近的位置,在網路上不一定總是最短。因此,結合估計位置與實際觀測值來判斷非常重要。
ERPC 的 Leader Slot API 與 Validators Information API,正是為了讓這些判斷能夠基於資料進行程式化而設計的 API。

Leader Slot API:從全球 7 個區域測量參考 RTT

Leader Slot API 返回即將到來的 leader slot,同時附帶 validator 身分、有效 stake 數量、網路端點、估計位置、參考 RTT 等資訊。
此前,pingToLeaders 的測量僅從法蘭克福節點收集 — 這是對全球分散的 Solana 網路的單一觀測點。
透過本次更新,現在可以取得從以下 7 個區域測量的參考 RTT。
  • frankfurt
  • amsterdam
  • ny
  • london
  • tokyo
  • singapore
  • sydney
針對每個 Leader,比較來自 7 個觀測區域的參考 RTT,即可判斷從哪個發送位置最有可能以較短的網路路徑抵達。
這不僅是交易路由的依據,也是決定 RPC、gRPC、Direct Shreds、交易發送伺服器等容量應部署於哪些地區時的判斷材料。
測量結果包含表示是否回應 ICMP 的 icmpReplied,以及表示最後一次成功取得測量值之時間的 measuredAt
即使是不回應 ICMP 的 validator,TPU、QUIC 等服務也可能正常運作。因此,當 icmpRepliedfalse 時,應視為「無法以 ICMP 測量」,而非「遙遠」。
此外,當更新時無法取得成功的測量值時,不會以未測量的數值覆寫,而是保留最後一次成功取得的實測值及其測量時間。

Validators Information API:一覽取得整個 Epoch 的 Leader 資訊

Leader Slot API 適合「接下來的 slot 由誰領導」這種以 slot 為單位的判斷。
另一方面,基礎設施部署與容量規劃需要更宏觀的視角。
  • 當前 epoch 中擔任 Leader 的 validator 是誰
  • 各自擔當多少 slot
  • 分佈在哪些國家與區域
  • 將基礎設施部署在哪個地區,才能更接近更多 Leader
全新的 Validators Information API(getValidatorsInformation)正是為了回答這些問題而生的 API。
不帶參數呼叫時,它會返回當前 epoch 中至少擔任一個 slot 之 Leader 的所有 validator,每個 validator 一列。預設情況下,可依擔當的 leader slot 數由多到少取得。
每列包含以下資訊。
  • slotCount
  • stakeWeight(以 SOL 計的有效 stake 數量)
  • validator 的身分資訊
在可取得的情況下,還會返回以下資訊。
  • 估計的區域、城市與國家
  • 網路端點
  • 客戶端版本
  • 來自 7 個區域的參考 RTT
由於資料會定期更新,定期呼叫 API 即可讓規劃用資料集保持最新。
你也可以使用可選的 limit(1–2000)、countryregion 參數來篩選結果。
計費依返回的 validator 數量計算。Leader validator 數量會隨 epoch 變動;以撰寫本文時的情況為例,取得全部 673 個 validator 需使用 6,800 API tokens(ERPC 的 API 使用額度),取得最多 10 個 validator 需使用 100 API tokens。

邁向以資料為基礎的可編程路由

這些 API 並非僅用於顯示 validator 清單或參考 RTT。
最終目的,是讓你能將 Leader 排程、validator 的估計位置、來自各觀測區域的參考 RTT,納入應用程式的判斷邏輯。
例如,應用程式可以取得即將到來的 Leader 排程,針對每個 Leader 比較來自 7 個觀測區域的參考 RTT,然後選擇要使用的 RPC 或交易發送路徑。
你也可以分析整個 epoch 的 Leader 分佈,預先將基礎設施部署到接近擔當 slot 數較多之 validator 的地區。
主要用途如下。
  • 以 slot 為單位選擇發送路徑
  • 以 epoch 為單位進行容量規劃
  • 按區域分析 leader validator
  • 考量有效 stake 數量與擔當 slot 數的優先排序
  • 監控每個 epoch 的地理與網路分佈變化
  • 在部署於多個區域的 RPC 與發送伺服器之間自動選擇
在通訊對象動態變化的 Solana 上,僅靠靜態網路優化並不足夠。
持續掌握不斷變化的 Leader,並依其位置與網路狀態動態選擇發送路徑與基礎設施,變得至關重要。

邁向以全球營運為前提的 Solana 基礎設施

ERPC 是面向 Solana 的高效能基礎設施,從第一天起就以全球營運為前提設計。
我們的邊緣網路、bare metal 與 VPS、Direct Shreds、Geyser gRPC、SWQoS 端點,以及本次的營運情報 API,全都基於同一個目的而提供。
這個目的是:在用戶與 Leader 分佈於世界各地的環境中,為追求低延遲且高效執行的開發者,同時提供資料與基礎設施。
來自全球 7 個區域的參考 RTT 與覆蓋整個 epoch 的 validator 資訊,現在透過簡單的 RPC 呼叫即可取得。Solana 應用程式可以因應不斷變化的 Leader,基於資料選擇發送位置與網路路徑。
對於在 Solana 上追求低延遲發送、全球基礎設施部署與動態路由優化的開發者而言,這是與實際營運直接相關的判斷依據。
歡迎用於選擇低延遲的發送路徑、設計可抑制不必要長距離傳輸的基礎設施,以及全球容量配置。
詳情請參閱文件: