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의 리더 정보, 추정 위치, 레이턴시를 파악하기 위한 API를 강화하여 Leader Slot API가 전 세계 7개 리전의 참조 RTT(ping 측정)에 대응하도록 확장하고, 새로운 Validators Information API 제공을 시작했습니다.
먼저 Leader Slot API(
getLeaderSlots)를 확장하여 전 세계 7개 ERPC 관측 리전(프랑크푸르트, 암스테르담, 뉴욕, 런던, 도쿄, 싱가포르, 시드니)에서 참조 RTT를 얻을 수 있게 했습니다. 이전에는 프랑크푸르트에서만 측정했습니다.아울러 새로운 Validators Information API(
getValidatorsInformation)를 공개했습니다. 이 API는 현재 epoch에서 최소 1개의 리더 slot을 보유한 모든 검증자를 한 번의 호출로 목록화합니다. 담당 slot 수와 액티브 스테이크 수량에 더해, 이용 가능한 경우 추정 위치, 네트워크 엔드포인트, 클라이언트 버전, 7개 리전의 참조 RTT도 반환합니다.두 API 모두 표준 JSON-RPC 인터페이스를 통해 모든 ERPC 사용자가 이용할 수 있습니다.
- Leader Slot API 문서: https://erpc.global/en/doc/rpc/leader-slot-api/
- Validators Information API 문서: https://erpc.global/en/doc/rpc/validators-information-api/
기존 트레이딩 인프라와의 차이: Solana에서는 통신 대상이 동적으로 변합니다
기존 거래소나 금융 시스템에서는 주문을 볼내는 대상인 거래소, 게이트웨이, 매칭 엔진 등이 일반적으로 특정 데이터 센터나 네트워크에 고정되어 있습니다.
따라서 사용자는 한 번 접속 대상을 파악하면 그 대상까지의 네트워크 경로를 지속적으로 최적화할 수 있습니다. 대상 서버의 위치가 자주 바뀌지 않기 때문에 인프라 배치와 통신 경로도 비교적 정적으로 설계할 수 있습니다.
반면 Solana에서는 블록 생성을 담당하는 리더가 리더 스케줄에 따라 몇 slot마다 교첳됩니다. 리더를 담당하는 검증자는 전 세계에 분산되어 있으므로, 트랜잭션이 도달해야 할 상대와 그 상대에 가까운 네트워크 경로는 계속해서 변화합니다.
즉 Solana에서는 최적화해야 할 통신 대상을 고정된 단일 접속 지점으로 다룰 수 없습니다.
현재와 미래의 리더가 누구인지를 먼저 리더 스케줄에서 파악해야 합니다. 그 위에서 각 검증자가 어느 지역이나 네트워크에 있을 가능성이 높은지, 또 각 송신 위치에서 어느 정도의 레이턴시가 있는지를 확인하고 송신 경로를 결정합니다.
이 구조를 올바르게 이해하는 것이 Solana에서 저지연 트랜잭션 전송과 글로벌 인프라 설계의 출발점이 됩니다.
리더 스케줄과 네트워크 위치를 데이터로 다루기
통신 대상이 동적으로 변하는 환경에서는 사람이 그때마다 리더와 송신 위치를 확인하고 수동으로 경로를 전환하는 것이 현실적이지 않습니다.
필요한 것은 다음 정보를 지속적으로 수집하여 애플리케이션과 인프라의 판단 로직에 내장하는 것입니다.
- 현재 및 향후 slot을 담당하는 리더
- 각 검증자가 담당하는 slot 수
- 각 검증자의 추정 국가, 도시, 리전
- TPU와 QUIC 같은 네트워크 엔드포인트
- 각 관측 리전에서 수집한 참조 RTT
- 측정값의 획득 시각과 응답 상태
추정 위치와 실측 레이턴시는 각각 다른 역할을 합니다.
위치 정보는 인프라와 용량을 어디에 배치해야 하는지에 대한 중장기적 판단에 활용할 수 있습니다. 반면 각 리전의 참조 RTT는 현재 어느 위치에서 짧은 경로로 도달할 가능성이 가장 높은지를 판단하는 재료가 됩니다.
물리적 또는 지리적으로 가까운 장소가 항상 네트워크상에서도 최단이 되는 것은 아닙니다. 그렇기 때문에 추정 위치와 실제 관측값을 조합하여 판단하는 것이 중요합니다.
ERPC의 Leader Slot API와 Validators Information API는 이러한 판단을 데이터에 기반해 프로그래밍할 수 있도록 하기 위한 API입니다.
Leader Slot API: 전 세계 7개 리전에서 참조 RTT 측정
Leader Slot API는 향후 리더 slot을 검증자 신원 정보, 액티브 스테이크 수량, 네트워크 엔드포인트, 추정 위치, 참조 RTT 등과 함께 반환합니다.
지금까지
pingToLeaders 측정은 프랑크푸르트 오리진에서만 수집되었습니다. 이는 글로벌하게 분산된 Solana 네트워크에 대한 단일 관측 지점이었습니다.이번 업데이트로 다음 7개 리전에서 측정한 참조 RTT를 얻을 수 있게 되었습니다.
frankfurtamsterdamnylondontokyosingaporesydney
각 리더에 대해 7개 관측 리전의 참조 RTT를 비교함으로써, 어느 송신 위치에서 짧은 네트워크 경로로 도달할 가능성이 높은지를 판단할 수 있습니다.
이는 트랜잭션 라우팅뿐 아니라 RPC, gRPC, Direct Shreds, 트랜잭션 전송 서버 등의 용량을 어느 지역에 배치할지 결정할 때의 판단 재료가 되기도 합니다.
측정 결과에는 ICMP 응답 유무를 나타내는
icmpReplied와 마지막으로 정상적인 측정값을 얻은 시각을 나타내는 measuredAt이 포함됩니다.ICMP에 응답하지 않는 검증자라도 TPU나 QUIC 같은 서비스가 정상적으로 가동되고 있는 경우가 있습니다. 그렇기 때문에
icmpReplied가 false인 경우에는 '멀다'가 아니라 'ICMP로는 측정할 수 없다'로 다루어야 합니다.또한 갱신 시 정상적인 측정값을 얻지 못한 경우에는 미측정 값으로 덮어쓰지 않고, 마지막으로 정상적으로 획득한 실측값과 그 측정 시각을 유지합니다.
Validators Information API: epoch 전체의 리더 정보 한눈에 조회
Leader Slot API는 '다음 slot을 담당하는 리더는 누구인가'라는 slot 단위 판단에 적합합니다.
반면 인프라 배치와 용량 계획에는 더 넓은 관점이 필요합니다.
- 현재 epoch에서 리더를 담당하는 검증자는 누구인가
- 각각 몇 개의 slot을 담당하는가
- 어느 국가와 리전에 분산되어 있는가
- 어느 지역에 인프라를 배치하면 더 많은 리더에 가까워질 수 있는가
새로운 Validators Information API(
getValidatorsInformation)는 이러한 질문에 답하기 위한 API입니다.파라미터 없이 호출하면 현재 epoch에서 최소 1개 slot의 리더를 맡은 모든 검증자를 검증자당 한 행으로 반환합니다. 기본적으로 담당하는 리더 slot 수가 많은 순으로 가져올 수 있습니다.
각 행에는 다음 정보가 포함됩니다.
slotCountstakeWeight(SOL 단위의 액티브 스테이크 수량)- 검증자 신원 정보
이용 가능한 경우에는 다음 정볼도 반환됩니다.
- 추정 리전, 도시, 국가
- 네트워크 엔드포인트
- 클라이언트 버전
- 7개 리전의 참조 RTT
데이터는 정기적으로 갱신되므로 API를 정기적으로 호출함으로써 계획용 데이터셋을 최신 상태로 유지할 수 있습니다.
또한 선택 파라미터인
limit(1–2000), country, region을 이용해 결과를 좁힐 수도 있습니다.과금은 반환된 검증자 수에 따라 이루어집니다. 리더 검증자 수는 epoch마다 변동하지만, 작성 시점의 예시에서는 전체 673명 조회에 6,800 API tokens(ERPC의 API 사용 크레딧), 최대 10명 조회에 100 API tokens이 사용됩니다.
데이터 기반 프로그래머블 라우팅을 향해
이러한 API는 단순히 검증자 목록이나 참조 RTT를 표시하기 위한 것이 아닙니다.
최종적인 목적은 리더 스케줄, 검증자의 추정 위치, 각 관측 리전의 참조 RTT를 애플리케이션의 판단 로직에 내장할 수 있게 하는 것입니다.
예를 들어 애플리케이션은 향후 리더 스케줄을 가져와 리더마다 7개 관측 리전의 참조 RTT를 비교한 뒤, 이용할 RPC나 트랜잭션 송신 경로를 선택할 수 있습니다.
또한 epoch 전체의 리더 분포를 분석하여 담당 slot 수가 많은 검증자에 가까운 지역에 미리 인프라를 배치할 수도 있습니다.
주요 용도는 다음과 같습니다.
- slot 단위의 송신 경로 선택
- epoch 단위의 용량 계획
- 리전별 리더 검증자 분석
- 액티브 스테이크 수량과 담당 slot 수를 고려한 우선순위화
- epoch별 지리적·네트워크적 분포 변화 모니터링
- 여러 리전에 배치한 RPC와 송신 서버의 자동 선택
통신 대상이 동적으로 변하는 Solana에서는 정적인 네트워크 최적화만으로는 충분하지 않습니다.
변화하는 리더를 지속적으로 파악하고 그 위치와 네트워크 상태에 따라 송신 경로와 인프라를 동적으로 선택하는 것이 중요해집니다.
글로벌 운영을 전제로 설계된 Solana 인프라를 향해
ERPC는 Solana를 위한 고성능 인프라로, 첫날부터 글로벌 운영을 전제로 설계되었습니다.
엣지 네트워크, 베어 메탈과 VPS, Direct Shreds, Geyser gRPC, SWQoS 엔드포인트, 그리고 이번 운영 인텔리전스 API는 모두 공통의 목적에 기반해 제공되고 있습니다.
그것은 사용자와 리더가 전 세계에 분산된 환경에서 저지연이면서 효율적인 실행을 요구하는 빌더에게 데이터와 인프라 양쪽을 제공하는 것입니다.
전 세계 7개 리전의 참조 RTT와 epoch 전체의 검증자 정보를 간단한 RPC 호출로 얻을 수 있게 되었습니다. Solana 애플리케이션은 계속 변화하는 리더에 맞춘 송신 위치와 네트워크 경로를 데이터에 기반해 선택할 수 있게 됩니다.
이는 Solana에서 저지연 전송, 글로벌 인프라 배치, 동적 라우팅 최적화를 추구하는 빌더에게 실제 운영에 직결되는 판단 재료가 됩니다.
저지연 송신 경로 선택, 불필요한 장거리 전송을 줄이는 인프라 설계, 글로벌 용량 배치에 활용해 주세요.
자세한 내용은 문서를 참조하세요.
- Leader Slot API: https://erpc.global/en/doc/rpc/leader-slot-api/
- Validators Information API: https://erpc.global/en/doc/rpc/validators-information-api/
- ERPC Web Dashboard: https://dashboard.erpc.global/en









