ERPC merilis Solana Stream SDK v4.0.0 dengan pemrosesan UDP Shreds dan pemulihan gRPC yang lebih cepat

ERPC merilis Solana Stream SDK v4.0.0 dengan pemrosesan UDP Shreds dan pemulihan gRPC yang lebih cepat

ERPC merilis Solana Stream SDK v4.0.0 dengan pemrosesan UDP Shreds dan pemulihan gRPC yang lebih cepat
ELSOUL LABO B.V. dan Validators DAO resmi merilis Solana Stream SDK v4.0.0, SDK sumber terbuka untuk menangani data streaming Solana, pada 6 November 2026. Benchmark lokal mengukur peningkatan kecepatan pemrosesan internal UDP Shreds di Rust sekitar 108 kali lipat dan throughput antrean event TypeScript sekitar 4 kali lipat. Geyser gRPC juga dapat kembali menerima pembaruan lebih cepat setelah koneksi terputus. SDK ini dapat digunakan secara gratis, dengan contoh Rust dan TypeScript untuk membantu pengembang memulai.
Pemanfaatan pengiriman data berlatensi rendah di dalam aplikasi juga bergantung pada seberapa cepat data yang masuk diproses. Versi 4.0.0 membuat pemrosesan internal setelah data tiba menjadi lebih efisien dan meningkatkan pemulihan koneksi setelah terputus. Penggunaannya bersama ERPC Shreds UDP Forwarding Premium memungkinkan pengembang meningkatkan jalur pengiriman sekaligus implementasi penerimaan data pada aplikasi Solana mereka.

Peningkatan pemrosesan dan pemulihan diukur melalui tiga pengujian

Perbandingan pemrosesan internal Rust UDP, antrean event TypeScript, dan pemulihan gRPC pada Solana Stream SDK v4.0.0
Pada jalur penerimaan Rust UDP, v4 mempercepat dekode datagram, penyisipan ke dalam buffer internal, dan proses deshred yang merekonstruksi data dari Shreds. Beban tambahan pemrosesan dikurangi dengan menata ulang pembersihan status internal dan pembacaan waktu yang sebelumnya diulang untuk setiap paket, sambil tetap mempertahankan periode penyimpanan data. Dalam perbandingan tersebut, waktu pemrosesan internal per datagram turun dari 94.236 ns menjadi 855–881 ns, atau sekitar 108 kali lebih cepat.
Benchmark dijalankan pada Mac dengan chip Apple seri M, dengan memproses 403.200 datagram dari 300 slot dalam setiap putaran. Hasilnya membandingkan median dari lima putaran. Pengukuran mencakup jalur internal decode→insert→deshred. Waktu pengiriman melalui jaringan dan pemrosesan lanjutan di aplikasi pengguna tidak termasuk dalam pengukuran ini. Pengurangan pekerjaan yang diperlukan untuk merekonstruksi Shreds yang masuk membantu pengembang mengalokasikan lebih banyak sumber daya komputasi untuk logika aplikasi.
Contoh dan proyek awal Geyser gRPC untuk TypeScript mengurangi waktu tunggu selama masih ada event dalam antrean, sehingga data yang diterima dapat diambil dengan lebih efisien. Dalam pengujian khusus antrean yang memproses dua juta event pada Node.js 24, throughput meningkat dari 5,7–7,4 juta event per detik menjadi 24,8–29,4 juta event per detik, atau sekitar 4 kali lipat.
Untuk Geyser gRPC, klien yang menangani penyambungan kembali dan interval percobaan ulang pertama telah diperbarui. Dalam pengujian yang memicu 20 kali pemutusan koneksi pada server tonic lokal, median jeda antara pembaruan yang diterima sebelum dan sesudah setiap pemutusan turun dari 552 ms dengan 3.0 runner menjadi 103 ms dengan 4.0 runner. Nilai ini mengukur jeda hingga pembaruan kembali diterima dalam lingkungan pengujian lokal.
Ketiga hasil ini berasal dari pengujian yang berbeda dengan cakupan dan kondisi yang berbeda. Masing-masing menunjukkan peningkatan pada pemrosesan internal Rust, antrean event TypeScript, dan penyambungan kembali gRPC. Rincian implementasi serta kondisi pengujian tersedia di PR #129 yang tercantum pada bagian Tautan terkait.

Mempertahankan dukungan Alpenglow dan memperbarui klien

Dukungan Alpenglow diperkenalkan pada v3.0.0. Versi 4.0.0 mempertahankan pemisahan antara penanda blok yang merepresentasikan header, footer, dan pembaruan blok induk, serta entries yang memuat transaksi. Aplikasi dapat menangani informasi tentang struktur blok secara terpisah dari entries yang perlu diproses.
Versi 4.0.0 memperbarui klien ke Agave 4.4.1 dan Yellowstone gRPC 17.x. Saat penyambungan kembali, event Disconnected dapat melaporkan informasi yang mengidentifikasi data yang baru diterima sebagian, beserta posisi untuk melanjutkan penerimaan. Informasi ini memungkinkan aplikasi menerapkan penanganannya sendiri atas duplikat data yang dikirim ulang dan data yang belum diterima secara utuh.
Migrasi dari v3 ke v4 mempertahankan definisi Geyser protobuf sambil memperbarui event penyambungan kembali serta tipe Solana message dan transaction yang digunakan di Rust. Panduan migrasi yang telah diterbitkan menjelaskan perubahan pada penangan event dan versi dependensi.

Gunakan Rust untuk UDP, atau Rust dan TypeScript untuk gRPC

Paket Rust solana-stream-sdk dan paket TypeScript @validators-dao/solana-stream-sdk yang telah diterbitkan sama-sama tersedia dalam versi v4.0.0. Bahasa yang didukung untuk setiap jenis koneksi tercantum di bawah ini.
Jenis koneksiBahasa yang didukung
Shreds UDPRust
Geyser gRPCRust dan TypeScript
Shreds gRPCRust dan TypeScript
Gunakan klien Rust untuk menerima Shreds melalui UDP. Contoh dan proyek awal Rust UDP menggunakan SDK v4.0.0 yang telah diterbitkan dan memungkinkan Anda mencoba penerimaan data, rekonstruksi data dari Shreds, serta deteksi instruksi untuk program yang ingin dipantau. Ubah program yang dipantau dan pemrosesan setelah deteksi untuk menjadikannya titik awal bagi aplikasi Anda sendiri.
Untuk pengembangan dengan TypeScript, Anda dapat menggunakan Geyser gRPC atau Shreds gRPC. Peningkatan antrean event dalam rilis ini disertakan dalam contoh dan proyek awal Geyser gRPC. Pilih implementasi yang telah diterbitkan sesuai dengan bahasa dan metode pengiriman data yang Anda gunakan.

Memanfaatkan Shreds UDP Forwarding Premium

ERPC Shreds UDP Forwarding Premium menghubungkan beberapa node dalam setiap region melalui jaringan mesh dan meneruskan salinan pertama dari setiap Shred yang diterima oleh jaringan tersebut. Waktu kedatangan melalui jalur pengiriman dan waktu rekonstruksi di dalam SDK setelah data tiba sama-sama memengaruhi seberapa cepat data yang diterima dapat digunakan. Peningkatan penerimaan Rust UDP dapat diterapkan di sisi penerima untuk data yang dikirimkan oleh Premium.
Dalam perbandingan di Frankfurt pada 30 Oktober 2026, Standard dan Premium direkam secara bersamaan selama 120 detik pada satu mesin menggunakan jam yang sama. Payload UDP dengan isi yang identik dicocokkan dari pcap. Premium tiba lebih dahulu pada 98% kumpulan data yang cocok tersebut, dengan median selisih waktu kedatangan sebesar 1,78 ms. Dari payload yang teramati pada Standard, 93,9% juga teramati pada Premium.
Perbandingan kedatangan pertama Shreds UDP Forwarding Premium dan Standard dalam kondisi yang sama di Frankfurt
Gambar Premium menunjukkan perbedaan waktu kedatangan antarjalur pengiriman, sedangkan gambar SDK menunjukkan pemrosesan internal di sisi penerima dan pemulihan koneksi. Dalam aplikasi nyata, pencatatan waktu kedatangan paket sekaligus waktu terdeteksinya instruksi yang relevan memungkinkan Anda memeriksa sejauh mana keunggulan pengiriman tetap tercermin pada hasil pemrosesan.

Bandingkan di lingkungan Anda dengan akses per jam dan contoh

Shreds UDP Forwarding Premium tersedia dengan penagihan per jam seharga €1,39 per jam. Mulai gunakan layanan dari dasbor dan verifikasi penerimaan dengan proyek awal Rust UDP. Penggunaan region, server penerima, dan beban kerja aplikasi yang sama memungkinkan Anda menilai perbedaan waktu kedatangan secara terpisah dari waktu pemrosesan setelah penerimaan.
Pertama, daftarkan alamat IPv4 publik dan port UDP Anda di dasbor, lalu izinkan lalu lintas masuk dari sumber yang tercantum. Setelah memeriksa penerimaan paket dan rekonstruksi data dengan proyek awal Rust UDP, sertakan program yang ingin dipantau dan pemrosesan aplikasi Anda yang sebenarnya dalam evaluasi. Gunakan contoh bersama layanan pengiriman untuk mengukur waktu dari penerimaan hingga deteksi di lingkungan Anda sendiri.

Tautan terkait