ERPC, Solana Leader Slot API'yi 7 küresel bölgeden ping ölçümüyle genişletti — Validators Information API de yayında

ERPC, Solana Leader Slot API'yi 7 küresel bölgeden ping ölçümüyle genişletti — Validators Information API de yayında

ERPC, Solana Leader Slot API'yi 7 küresel bölgeden ping ölçümüyle genişletti — Validators Information API de yayında
ELSOUL LABO B.V. (Merkez: Amsterdam, Hollanda; Temsilci Direktör ve CEO: Fumitake Kawasaki) ve ERPC'nin operatörleri olan Validators DAO, Solana'nın leader bilgilerini, tahmini konumlarını ve latency'sini anlamaya yönelik API'leri güçlendirdi; Leader Slot API'ye dünya genelindeki 7 bölgeden referans RTT (ping ölçümü) desteği ekledi ve yeni Validators Information API'yi kullanıma sundu.
İlk olarak, Leader Slot API'yi (getLeaderSlots) genişleterek dünya genelindeki 7 ERPC gözlem bölgesinden (Frankfurt, Amsterdam, New York, Londra, Tokyo, Singapur ve Sidney) referans RTT alınabilir hale getirdik. Daha önce ölçümler yalnızca Frankfurt'tan yapılıyordu.
Ayrıca yeni Validators Information API'yi (getValidatorsInformation) yayına aldık. Bu API, mevcut epoch'ta en az bir leader slot tutan tüm validator'ları tek bir çağrıda listeler. Slot sayısı ve aktif stake miktarına ek olarak, mevcut olduğu durumlarda tahmini konum, ağ endpoint'leri, client version ve 7 bölgeden referans RTT de döndürür.
Her iki API de standart JSON-RPC arayüzü üzerinden tüm ERPC kullanıcılarına açıktır.

Geleneksel işlem altyapısından farkı: Solana'da iletişim hedefi dinamik olarak değişir

Geleneksel borsalarda ve finans sistemlerinde, emirlerin gönderildiği hedefler — borsalar, gateway'ler, matching engine'ler — genellikle belirli veri merkezlerine veya ağlara sabitlenmiştir.
Bu nedenle kullanıcı, bağlantı hedefini bir kez öğrendikten sonra o hedefe giden ağ yolunu sürekli olarak optimize edebilir. Hedef sunucuların konumu sık değişmediği için altyapı yerleşimi ve iletişim rotaları görece sabit tasarlanabilir.
Solana'da ise blok üretmekten sorumlu leader, leader schedule uyarınca birkaç slot'ta bir değişir. Leader olarak görev yapan validator'lar dünya geneline dağıldığı için, transaction'ların ulaşması gereken taraf ve o tarafa en yakın ağ yolu sürekli değişir.
Başka bir deyişle Solana'da optimize edilecek iletişim hedefi, sabit ve tek bir bağlantı noktası olarak ele alınamaz.
Önce mevcut ve gelecek leader'ların kim olduğunu leader schedule'dan belirlemek gerekir. Ardından her validator'ın büyük olasılıkla hangi bölgede veya ağda bulunduğu ve her gönderim konumundan ne kadar latency olduğu kontrol edilerek gönderim rotasına karar verilir.
Bu yapıyı doğru anlamak, Solana'da düşük latency'li transaction gönderimi ve küresel altyapı tasarımının başlangıç noktasıdır.

Leader schedule'ı ve ağ konumlarını veri olarak ele almak

Hedefin dinamik olarak değiştiği bir ortamda, bir kişinin her seferinde leader'ı ve gönderim konumunu kontrol edip rotayı manuel olarak değiştirmesi gerçekçi değildir.
Gerekli olan, aşağıdaki bilgileri sürekli olarak alıp uygulamaların ve altyapının karar mantığına yerleştirmektir.
  • Mevcut ve yaklaşan slot'lardan sorumlu leader'lar
  • Her validator'ın sorumlu olduğu slot sayısı
  • Her validator'ın tahmini ülkesi, şehri ve bölgesi
  • TPU ve QUIC gibi ağ endpoint'leri
  • Her gözlem bölgesinden alınan referans RTT
  • Her ölçümün alındığı zaman ve yanıt durumu
Tahmini konum ile ölçülen latency farklı roller oynar.
Konum bilgisi, altyapı ve kapasitenin nereye yerleştirileceğine dair orta ve uzun vadeli kararlarda kullanılabilir. Buna karşılık her bölgeden referans RTT, o anda hangi konumdan kısa bir yol ile ulaşma olasılığının daha yüksek olduğunu değerlendirmek için bir girdi sağlar.
Fiziksel veya coğrafi olarak yakın bir konum, ağ üzerinde her zaman en kısa yol olmayabilir. Bu nedenle tahmini konum ile gerçek gözlem değerlerini birlikte değerlendirerek karar vermek önemlidir.
ERPC'nin Leader Slot API'si ve Validators Information API'si, bu kararları veriye dayalı olarak programlanabilir kılmak için tasarlanmış API'lerdir.

Leader Slot API: 7 küresel bölgeden referans RTT ölçümü

Leader Slot API; yaklaşan leader slot'larını validator kimliği, aktif stake miktarı, ağ endpoint'leri, tahmini konum ve referans RTT gibi bilgilerle birlikte döndürür.
Şimdiye kadar pingToLeaders ölçümleri yalnızca Frankfurt origin'inden toplanıyordu — küresel olarak dağılmış Solana ağı üzerinde tek bir gözlem noktasıydı.
Bu güncellemeyle birlikte aşağıdaki 7 bölgeden ölçülen referans RTT alınabilir hale geldi.
  • frankfurt
  • amsterdam
  • ny
  • london
  • tokyo
  • singapore
  • sydney
Her leader için 7 gözlem bölgesinden gelen referans RTT'yi karşılaştırarak, hangi gönderim konumunun kısa bir ağ yolu sunma olasılığının daha yüksek olduğuna karar verebilirsiniz.
Bu, yalnızca transaction routing için değil; RPC, gRPC, Direct Shreds ve transaction gönderim sunucuları gibi kapasitelerin hangi bölgelere yerleştirileceğine karar verirken de bir girdi sağlar.
Ölçüm sonuçları, ICMP'ye yanıt verilip verilmediğini gösteren icmpReplied ile son başarılı ölçümün alındığı zamanı gösteren measuredAt alanlarını içerir.
ICMP'ye yanıt vermeyen bir validator, TPU ve QUIC gibi servisleri normal şekilde çalıştırıyor olabilir. Bu nedenle icmpReplied false olduğunda bu durum "uzak" olarak değil, "ICMP ile ölçülemez" olarak ele alınmalıdır.
Ayrıca yenileme sırasında başarılı bir ölçüm alınamadığında, kaydın üzerine ölçülmemiş bir değer yazılmaz; son başarılı ölçümün değeri ve ölçüm zamanı korunur.

Validators Information API: Epoch genelindeki leader bilgilerini listeleme

Leader Slot API, "sonraki slot'lardan sorumlu leader kim?" sorusuna yönelik slot düzeyinde kararlar için uygundur.
Altyapı yerleşimi ve kapasite planlaması ise daha geniş bir bakış açısı gerektirir.
  • Mevcut epoch'ta leader olarak görev yapan validator'lar kimler
  • Her biri kaç slot'tan sorumlu
  • Hangi ülke ve bölgelere dağılmış durumdalar
  • Daha fazla leader'a yaklaşmak için altyapı nereye yerleştirilmeli
Yeni Validators Information API (getValidatorsInformation), bu soruları yanıtlamak için geliştirilen API'dir.
Parametresiz çağrıldığında, mevcut epoch'ta en az bir slot'a leader'lık eden tüm validator'ları validator başına bir satır olacak şekilde döndürür. Varsayılan olarak sonuçlar, tutulan leader slot sayısına göre azalan sırada alınır.
Her satır şu bilgileri içerir.
  • slotCount
  • stakeWeight (SOL cinsinden aktif stake miktarı)
  • Validator kimliği
Mevcut olduğu durumlarda ayrıca şu bilgiler de döndürülür.
  • Tahmini bölge, şehir ve ülke
  • Ağ endpoint'leri
  • Client version
  • 7 bölgeden referans RTT
Veriler düzenli olarak yenilendiği için API'yi düzenli aralıklarla çağırarak planlama veri setinizi güncel tutabilirsiniz.
Ayrıca opsiyonel limit (1–2000), country ve region parametreleriyle sonuçları daraltabilirsiniz.
Faturalama, döndürülen validator sayısına göre yapılır. Leader validator sayısı epoch'tan epoch'a değişir; yazının hazırlandığı andaki örnekte, 673 validator'ın tamamını almak 6,800 API token (ERPC API kullanım kredisi), en fazla 10 validator almak ise 100 API token kullanır.

Veriye dayalı, programlanabilir routing'e doğru

Bu API'ler yalnızca validator listesi veya referans RTT göstermek için değildir.
Nihai amaç; leader schedule'ı, validator'ların tahmini konumlarını ve her gözlem bölgesinden referans RTT'yi uygulamalarınızın karar mantığına yerleştirebilmenizi sağlamaktır.
Örneğin bir uygulama, yaklaşan leader schedule'ı alıp her leader için 7 gözlem bölgesinden gelen referans RTT'yi karşılaştırarak kullanacağı RPC'yi veya transaction gönderim rotasını seçebilir.
Ayrıca epoch genelindeki leader dağılımını analiz edip slot sayısı yüksek validator'lara yakın bölgelere önceden altyapı yerleştirebilirsiniz.
Tipik kullanımlar şunlardır.
  • Slot düzeyinde gönderim rotası seçimi
  • Epoch düzeyinde kapasite planlaması
  • Bölgeye göre leader validator analizi
  • Aktif stake miktarını ve slot sayısını dikkate alan önceliklendirme
  • Epoch'lar arası coğrafi ve ağ dağılımı değişikliklerinin izlenmesi
  • Birden fazla bölgeye yerleştirilmiş RPC ve gönderim sunucuları arasında otomatik seçim
Hedefin dinamik olarak değiştiği Solana'da, yalnızca statik ağ optimizasyonu yeterli değildir.
Değişen leader'ı sürekli izlemek ve konumu ile ağ durumuna göre gönderim rotalarını ve altyapıyı dinamik olarak seçmek önem kazanır.

Küresel operasyon öngörüsüyle tasarlanmış Solana altyapısına doğru

ERPC, Solana için ilk günden itibaren küresel operasyon gözetilerek tasarlanmış yüksek performanslı bir altyapıdır.
Edge ağımız, bare metal ve VPS'ler, Direct Shreds, Geyser gRPC, SWQoS endpoint'leri ve bu operasyonel istihbarat API'lerinin tümü ortak bir amaca hizmet eder.
Bu amaç; kullanıcıların ve leader'ların dünya geneline dağıldığı bir ortamda düşük latency'li ve verimli execution talep eden builder'lara hem veriyi hem de altyapıyı sunmaktır.
7 küresel bölgeden referans RTT ve epoch genelinde validator bilgileri artık basit RPC çağrılarıyla alınabiliyor. Solana uygulamaları, sürekli değişen leader'a göre gönderim konumlarını ve ağ rotalarını veriye dayalı olarak seçebilir.
Solana üzerinde düşük latency'li gönderim, küresel altyapı yerleşimi ve dinamik routing optimizasyonu arayan builder'lar için bu, gerçek operasyonlarla doğrudan bağlantılı bir karar girdisidir.
Düşük latency'li gönderim rotaları seçmek, gereksiz uzun mesafeli transferleri azaltan altyapı tasarımı ve küresel kapasite yerleşimi için bu API'lerden yararlanabilirsiniz.
Ayrıntılar için dokümantasyona bakın: