ERPC Memperluas Solana Leader Slot API dengan Pengukuran Ping dari 7 Region Global — Validators Information API Juga Diluncurkan

ERPC Memperluas Solana Leader Slot API dengan Pengukuran Ping dari 7 Region Global — Validators Information API Juga Diluncurkan

ERPC Memperluas Solana Leader Slot API dengan Pengukuran Ping dari 7 Region Global — Validators Information API Juga Diluncurkan
ELSOUL LABO B.V. (Kantor pusat: Amsterdam, Belanda; CEO: Fumitake Kawasaki) dan Validators DAO, operator ERPC, telah meningkatkan API untuk memahami informasi leader, perkiraan lokasi, dan latency Solana — menambahkan dukungan RTT referensi (pengukuran ping) dari 7 region global ke Leader Slot API serta meluncurkan Validators Information API baru.
Pertama, Leader Slot API (getLeaderSlots) telah diperluas sehingga RTT referensi dapat diperoleh dari 7 region observasi ERPC di seluruh dunia (Frankfurt, Amsterdam, New York, London, Tokyo, Singapura, dan Sydney). Sebelumnya, pengukuran hanya dilakukan dari Frankfurt.
Bersamaan dengan itu, kami meluncurkan Validators Information API (getValidatorsInformation) yang baru. API ini mencantumkan, dalam satu panggilan, setiap validator yang memegang setidaknya satu leader slot di epoch saat ini. Selain jumlah slot dan stake aktif, API ini juga mengembalikan — jika tersedia — perkiraan lokasi, network endpoint, versi client, dan RTT referensi dari 7 region.
Kedua API tersedia untuk semua pengguna ERPC melalui interface JSON-RPC standar.

Perbedaan dengan Infrastruktur Trading Tradisional: Tujuan Komunikasi Berubah Secara Dinamis di Solana

Dalam bursa dan sistem keuangan tradisional, tujuan pengiriman order — bursa, gateway, matching engine — biasanya terikat pada data center atau jaringan tertentu.
Karena itu, setelah mengetahui tujuan koneksi, pengguna dapat terus mengoptimalkan network path menuju tujuan tersebut. Karena lokasi server target tidak sering berubah, penempatan infrastruktur dan rute komunikasi dapat dirancang secara relatif statis.
Sebaliknya, di Solana, leader — validator yang bertanggung jawab memproduksi blok — berganti setiap beberapa slot mengikuti leader schedule. Karena validator yang bertugas sebagai leader tersebar di seluruh dunia, baik tujuan yang harus dicapai transaksi Anda maupun network path yang paling dekat dengan tujuan itu berubah secara berkelanjutan.
Dengan kata lain, di Solana, tujuan komunikasi yang harus dioptimalkan tidak dapat diperlakukan sebagai satu titik koneksi yang tetap.
Anda perlu terlebih dahulu mengidentifikasi leader saat ini dan mendatang dari leader schedule. Di atas itu, Anda memeriksa di region atau jaringan mana setiap validator kemungkinan besar berada, serta berapa besar latency dari setiap lokasi pengiriman, sebelum memutuskan rute pengiriman.
Memahami struktur ini dengan benar adalah titik awal untuk pengiriman transaksi ber-latency rendah dan perancangan infrastruktur global di Solana.

Memperlakukan Leader Schedule dan Lokasi Jaringan sebagai Data

Dalam lingkungan di mana tujuan berubah secara dinamis, tidaklah praktis jika seseorang harus memeriksa leader dan lokasi pengiriman setiap saat lalu mengganti rute secara manual.
Yang dibutuhkan adalah memperoleh informasi berikut secara berkelanjutan dan membangunnya ke dalam logika keputusan aplikasi dan infrastruktur Anda.
  • Leader yang bertanggung jawab atas slot saat ini dan mendatang
  • Jumlah slot yang ditangani setiap validator
  • Perkiraan negara, kota, dan region setiap validator
  • Network endpoint seperti TPU dan QUIC
  • RTT referensi yang dikumpulkan dari setiap region observasi
  • Waktu setiap pengukuran dilakukan dan status responsnya
Perkiraan lokasi dan latency terukur masing-masing memainkan peran yang berbeda.
Informasi lokasi dapat digunakan untuk keputusan jangka menengah hingga panjang tentang di mana menempatkan infrastruktur dan kapasitas. Sebaliknya, RTT referensi dari setiap region menjadi bahan untuk menilai lokasi mana yang saat ini paling mungkin menawarkan jalur yang pendek.
Lokasi yang dekat secara fisik atau geografis tidak selalu menjadi yang terpendek di jaringan. Karena itu, penting untuk mengambil keputusan dengan menggabungkan perkiraan lokasi dan nilai observasi aktual.
Leader Slot API dan Validators Information API dari ERPC adalah API yang dirancang agar Anda dapat memprogram keputusan-keputusan ini berdasarkan data.

Leader Slot API: Mengukur RTT Referensi dari 7 Region Global

Leader Slot API mengembalikan leader slot mendatang bersama identitas validator, stake aktif, network endpoint, perkiraan lokasi, RTT referensi, dan lainnya.
Hingga kini, pengukuran pingToLeaders hanya dikumpulkan dari origin Frankfurt — satu titik observasi tunggal pada jaringan Solana yang terdistribusi secara global.
Dengan update ini, Anda kini dapat memperoleh RTT referensi yang diukur dari 7 region berikut.
  • frankfurt
  • amsterdam
  • ny
  • london
  • tokyo
  • singapore
  • sydney
Dengan membandingkan RTT referensi dari 7 region observasi untuk setiap leader, Anda dapat menilai lokasi pengiriman mana yang paling mungkin menawarkan network path yang pendek.
Ini menjadi bahan pengambilan keputusan tidak hanya untuk routing transaksi, tetapi juga untuk menentukan di region mana menempatkan kapasitas untuk RPC, gRPC, Direct Shreds, server pengiriman transaksi, dan lainnya.
Hasil pengukuran mencakup icmpReplied, yang menunjukkan apakah validator merespons ICMP, dan measuredAt, yang menunjukkan waktu ketika pengukuran sukses terakhir diperoleh.
Validator yang tidak merespons ICMP mungkin tetap menjalankan layanan seperti TPU dan QUIC secara normal. Karena itu, ketika icmpReplied bernilai false, kondisi ini harus diperlakukan bukan sebagai "jauh", melainkan sebagai "tidak dapat diukur melalui ICMP".
Selain itu, ketika pengukuran sukses tidak dapat diperoleh pada saat refresh, entri tidak ditimpa dengan nilai yang tidak terukur — nilai terakhir yang berhasil diukur beserta waktu pengukurannya tetap dipertahankan.

Validators Information API: Mencantumkan Informasi Leader di Seluruh Epoch

Leader Slot API cocok untuk keputusan level slot — "siapa leader yang bertanggung jawab atas slot berikutnya?"
Sebaliknya, penempatan infrastruktur dan perencanaan kapasitas membutuhkan sudut pandang yang lebih luas.
  • Validator mana yang bertugas sebagai leader di epoch saat ini
  • Berapa banyak slot yang ditangani masing-masing
  • Tersebar di negara dan region mana saja
  • Di mana menempatkan infrastruktur agar lebih dekat ke lebih banyak leader
Validators Information API baru (getValidatorsInformation) adalah API yang dibangun untuk menjawab pertanyaan-pertanyaan ini.
Dipanggil tanpa parameter, API ini mengembalikan setiap validator yang bertugas sebagai leader untuk setidaknya satu slot di epoch saat ini, satu baris per validator. Secara default, hasil dikembalikan dalam urutan menurun berdasarkan jumlah leader slot yang dipegang.
Setiap baris mencakup informasi berikut.
  • slotCount
  • stakeWeight (stake aktif dalam SOL)
  • Identitas validator
Jika tersedia, informasi berikut juga dikembalikan.
  • Perkiraan region, kota, dan negara
  • Network endpoint
  • Versi client
  • RTT referensi dari 7 region
Karena data diperbarui secara berkala, memanggil API secara rutin akan menjaga dataset perencanaan Anda tetap up to date.
Anda juga dapat mempersempit hasil menggunakan parameter opsional limit (1–2000), country, dan region.
Billing didasarkan pada jumlah validator yang dikembalikan. Jumlah leader validator bervariasi dari epoch ke epoch; pada contoh saat penulisan, mengambil seluruh 673 validator menggunakan 6,800 API tokens (kredit penggunaan API ERPC), dan mengambil hingga 10 validator menggunakan 100 API tokens.
API ini tidak dimaksudkan sekadar untuk menampilkan daftar validator atau RTT referensi.
Tujuan akhirnya adalah memungkinkan Anda membangun leader schedule, perkiraan lokasi validator, dan RTT referensi dari setiap region observasi ke dalam logika keputusan aplikasi Anda.
Misalnya, sebuah aplikasi dapat mengambil leader schedule mendatang, membandingkan RTT referensi dari 7 region observasi untuk setiap leader, lalu memilih RPC atau rute pengiriman transaksi yang akan digunakan.
Anda juga dapat menganalisis distribusi leader di seluruh epoch dan menempatkan infrastruktur terlebih dahulu di region yang dekat dengan validator ber-slot count tinggi.
Penggunaan umum meliputi hal berikut.
  • Pemilihan rute pengiriman pada level slot
  • Perencanaan kapasitas pada level epoch
  • Analisis leader validator per region
  • Prioritisasi yang memperhitungkan stake aktif dan jumlah slot
  • Pemantauan perubahan distribusi geografis dan jaringan antar-epoch
  • Pemilihan otomatis di antara RPC dan server pengiriman yang di-deploy di beberapa region
Di Solana, di mana tujuan berubah secara dinamis, optimasi jaringan statis saja tidak cukup.
Menjadi penting untuk terus melacak leader yang berubah dan secara dinamis memilih rute pengiriman serta infrastruktur sesuai lokasi dan kondisi jaringannya.
ERPC adalah infrastruktur berperforma tinggi untuk Solana, dirancang sejak hari pertama dengan mempertimbangkan operasi global.
Edge network, bare metal dan VPS, Direct Shreds, Geyser gRPC, SWQoS endpoint, serta operational intelligence API ini semuanya disediakan untuk melayani satu tujuan bersama.
Tujuan itu adalah menyediakan data dan infrastruktur sekaligus bagi para builder yang menuntut eksekusi efisien ber-latency rendah dalam lingkungan di mana pengguna dan leader tersebar di seluruh dunia.
RTT referensi dari 7 region global dan informasi validator seluruh epoch kini dapat diperoleh melalui RPC call sederhana. Aplikasi Solana kini dapat memilih lokasi pengiriman dan rute jaringan berdasarkan data, mengikuti leader yang terus berubah.
Bagi builder yang menginginkan pengiriman ber-latency rendah, penempatan infrastruktur global, dan optimasi routing dinamis di Solana, ini adalah bahan pengambilan keputusan yang terhubung langsung dengan operasi nyata.
Semoga ini bermanfaat untuk memilih rute pengiriman ber-latency rendah, merancang infrastruktur yang mengurangi transfer jarak jauh yang tidak perlu, dan merencanakan penempatan kapasitas global.
Untuk detail, lihat dokumentasi.