ERPC Meningkatkan Infrastruktur Jaringan Solana secara Signifikan; Platform Proxy Rust Berperforma Tinggi Ditingkatkan Menyeluruh dan Diterapkan di Seluruh Region untuk Endpoint Bersama RPC, gRPC, serta Shredstream; Update Tanpa Downtime Berhasil Dicapai
ERPC, yang dioperasikan oleh ELSOUL LABO B.V. (Kantor pusat: Amsterdam, Belanda; CEO: Fumitake Kawasaki) bersama Validators DAO, telah menyelesaikan peningkatan besar pada infrastruktur jaringan Solana.
Peningkatan ini telah diterapkan pada seluruh region dan semua endpoint bersama yang disediakan ERPC (Solana RPC, Geyser gRPC, dan Shredstream). Kami memperbarui perilaku infrastruktur yang cenderung memengaruhi hasil nyata secara langsung sebagai satu sistem terpadu, termasuk inisiasi koneksi, pemrosesan TLS, kontrol cache, transport HTTP/1.1 dan HTTP/2, perilaku koneksi berumur panjang, serta metrik untuk observability dan troubleshooting.
Sembari mempertahankan responsivitas sehari-hari sebagai baseline, kami juga menata ulang perilaku jaringan mendasar agar tidak mudah mengalami bias atau ketidakstabilan dalam skenario yang cenderung menurunkan hasil—seperti volatilitas saat beban puncak, ketidakstabilan dalam operasi berkelanjutan, serta efek berantai yang dipicu putus dan tersambungnya kembali koneksi. Hasilnya, lingkungan kini lebih terstruktur untuk mempertahankan performa dan stabilitas dalam operasi Solana nyata.
Selain itu, kami telah beralih ke arsitektur operasional yang memungkinkan perubahan konfigurasi jaringan dan upgrade platform diterapkan sepenuhnya tanpa downtime. Harga, spesifikasi, autentikasi, dan rate limit tidak berubah, sedangkan pelanggan ERPC yang sudah ada memperoleh manfaat peningkatan ini tanpa setup tambahan atau perubahan operasional.
Latar Belakang
Dalam operasi Solana nyata, waktu respons rata-rata dan latensi dalam kondisi normal merupakan persyaratan baseline yang penting. Pada saat yang sama, terdapat skenario ketika perilaku infrastruktur jaringan mendasar menentukan hasil, seperti saat beban terpusat, koneksi berumur panjang, serta fase putus dan tersambungnya kembali koneksi.
Endpoint bersama secara khusus harus mengakomodasi lonjakan pengiriman transaksi dalam waktu singkat sekaligus koneksi WebSocket dan gRPC yang selalu aktif. Dalam kondisi tersebut, perilaku pada tingkat infrastruktur—inisiasi koneksi, TLS handshake, perilaku transport, penanganan cache, dan pemulihan dari idle state—tercermin langsung pada pengalaman pengguna serta hasil eksekusi.
Meskipun responsivitas rata-rata ditetapkan sebagai baseline, hasil nyata tetap dapat ditentukan oleh faktor lain saat terjadi lonjakan atau operasi berkelanjutan. Karena itu, operasi nyata harus memenuhi kemudahan penggunaan sehari-hari dan kontinuitas dalam skenario rawan kegagalan secara bersamaan.
ERPC merancang dan mengoperasikan platform proxy Rust berperforma tinggi miliknya sendiri sebagai fondasi komunikasi Solana, dengan arsitektur yang menerapkan pendekatan sama di seluruh region sambil terus mengembangkan platform. Peningkatan ini meninjau kembali masalah yang teramati dalam operasi sebagai satu sistem terpadu—dari inisiasi koneksi hingga operasi berumur panjang—lalu menata ulang seluruh fondasi jaringan.
Perubahan bagi Pelanggan ERPC
Melalui pembaruan ini, pelanggan ERPC pertama-tama memperoleh perilaku yang lebih stabil saat inisiasi koneksi. Selama pembentukan koneksi, termasuk TLS, ketidaksesuaian kondisi dan retry yang tidak perlu menjadi lebih jarang sehingga transaksi serta stream lebih mudah memasuki pemrosesan secara andal sejak awal.
Selanjutnya, kami menata ulang perilaku infrastruktur yang cenderung memicu volatilitas saat beban puncak. Dengan memadukan penyaringan dini koneksi tidak perlu dan pembaruan serentak pada transport HTTP/1.1 serta HTTP/2, konsistensi timeout, kesehatan connection pool, perilaku cache saat terjadi contention, dan metrik observability serta troubleshooting, kami memperkuat kondisi yang membantu mencegah perilaku menjadi bias meski beban terpusat.
Kontinuitas koneksi meningkat bagi stream WebSocket dan gRPC berumur panjang serta workload monitoring yang selalu aktif. Frekuensi kejadian disconnect/reconnect/resync—dan kemungkinan dampaknya menyebar secara berantai pada hasil—telah berkurang, sehingga operasi lebih mudah dibangun dengan asumsi runtime berkelanjutan.
Peningkatan kontrol cache dan perilaku transport juga mengurangi kemungkinan refetch yang tidak perlu serta pemrosesan terbuang saat terjadi kemacetan. Bandwidth dan kapasitas pemrosesan lebih mungkin tetap dapat digunakan secara stabil, sedangkan perluasan metrik serta observability membantu mempersingkat identifikasi akar masalah dan waktu pemulihan.
Selain itu, dengan memungkinkan perubahan konfigurasi dan upgrade platform tanpa downtime, kami membentuk kondisi operasional yang memudahkan peningkatan performa, stabilitas, dan kualitas platform keseluruhan dengan frekuensi tinggi. Kemampuan terus meningkatkan platform tanpa menghentikannya semakin memperkuat kontinuitas bagi pelanggan.
Detail Peningkatan
Peningkatan ini tidak disajikan sebagai rilis yang didorong oleh nama fitur atau nomor versi tertentu. Sebaliknya, peningkatan menguraikan skenario yang cenderung mendominasi hasil Solana nyata ke dalam lapisan berikut—inisiasi koneksi, TLS, batas L4/HTTP, transport H1/H2, cache, observability, perilaku kegagalan, dan prasyarat operasional jangka panjang—lalu memperbarui platform agar seluruh lapisan terhubung tanpa kontradiksi.
Berikut penjelasan peningkatan yang disertakan berdasarkan kontribusinya terhadap pengalaman pelanggan dan hasil operasional.
Peningkatan Inisiasi Koneksi dan Penanganan TLS
Kami memperluas konteks TLS yang ditangani saat membentuk koneksi dan memperbarui struktur agar state yang diperlukan dapat dipertahankan serta diterapkan dengan tepat. Hal ini membuat ketidaksesuaian kondisi dan retry yang tidak perlu menjadi lebih jarang saat inisiasi koneksi.
Kami juga menata ulang penanganan TLS—termasuk verifikasi sertifikat dan hostname—agar persyaratan keamanan dapat dipenuhi sekaligus mengurangi kondisi ketika kegagalan handshake atau inkonsistensi penanganan menimbulkan kehilangan pada awal koneksi yang kemudian menyebar ke hasil. Ini bukan hanya peningkatan keamanan, tetapi juga menstabilkan perilaku dari awal koneksi hingga masuk ke pemrosesan bagi workload Solana.
Mekanisme yang mempermudah observasi dan troubleshooting perilaku di sekitar TLS turut diperkuat. Dalam skenario ketika inisiasi mendominasi hasil, kemampuan mereproduksi masalah, mengidentifikasi penyebab, dan segera menerapkan perbaikan menjadi kapasitas yang menjaga kualitas pengalaman.
Mempertahankan Kapasitas melalui Penyaringan Dini Koneksi Tidak Perlu
Kami memperkenalkan mekanisme penyaringan koneksi TCP pada tahap awal dan memperbarui platform agar koneksi tidak sah atau tidak perlu tidak mudah menekan traffic yang sah. Pada endpoint bersama, permintaan koneksi dapat melonjak akibat faktor eksternal atau ketimpangan sementara.
Penyaringan tahap awal membantu memastikan koneksi sah tidak mudah tertahan ketika dimulai, sehingga kapasitas lebih mungkin tetap tersedia pada beban puncak. Hasilnya, perilaku tidak mudah menjadi bias bahkan saat beban terpusat dan kondisi bagi distribusi latensi yang stabil semakin kuat.
Memperjelas Model Koneksi dengan Menata Ulang Batas L4/HTTP
Infrastruktur jaringan tidak berakhir pada HTTP. Pembentukan dan kontinuitas koneksi bergantung pada kondisi L4, dan volatilitas pada lapisan tersebut menyebar ke pengalaman protokol tingkat atas.
Dalam pembaruan ini, kami mengabstraksikan penanganan stream L4 dan menata ulang struktur agar model koneksi dapat ditangani secara lebih eksplisit. Dengan demikian, platform lebih mudah mempertahankan perilaku konsisten dalam skenario ketika jumlah koneksi terus bertambah, implementasi client berbeda-beda, dan operasi berumur panjang memicu transisi state.
Perilaku retry juga ditata ulang untuk mengurangi pola ketika volatilitas singkat menyebar ke pengalaman pengguna. Stabilitas nyata tidak terlalu bergantung pada penghapusan setiap kegagalan terpisah, melainkan pada pencegahan efek berantai kegagalan.
Peningkatan Transport HTTP/1.1 dan HTTP/2 serta Perilaku Jangka Panjang
Kami menambahkan pengukuran yang memungkinkan volume data transfer dilacak secara konsisten di HTTP/1.1 dan HTTP/2. Hal ini mempermudah identifikasi lokasi stall atau bottleneck dalam pipeline transport, sekaligus meningkatkan troubleshooting dan kecepatan penerapan perbaikan.
Kami juga menata ulang perilaku timeout penulisan body HTTP/2 agar stall dan hang yang tidak wajar lebih jarang terjadi saat beban terpusat atau streaming berumur panjang. Dalam operasi jangka panjang, faktor pentingnya bukan performa puncak dalam kondisi ideal, tetapi kemampuan mencegah perilaku runtuh selama transisi state.
Perilaku idle timeout dan penanganan connection pool juga ditinjau untuk menghapus faktor ketidakstabilan yang cenderung terakumulasi dalam runtime berkelanjutan. Pada sisi HTTP/1.1, kami menata ulang perilaku shutdown aman bagi koneksi yang memegang request tidak lengkap, sehingga sumber volatilitas pada penggunaan resource dan perilaku berkurang.
Peningkatan Kontrol Cache dan Kualitas Operasional
Kami meningkatkan kemampuan melacak alasan sebuah aset tidak di-cache sehingga perilaku cache lebih mudah dijelaskan. Dalam praktiknya, faktor yang dominan bukan apakah cache tersedia, melainkan kondisi penerapan dan kondisi ketika cache tidak digunakan.
Kami menata ulang perilaku lock, penanganan stale, dan pola revalidation agar penurunan pengalaman tidak mudah menyebar ketika contention terjadi saat beban puncak. Kontrol eviction juga disusun untuk kasus ketika jumlah aset cache bertambah, dan perilaku partial content—termasuk Range request—disempurnakan, sehingga kondisi yang mengurangi refetch serta latensi tidak perlu dalam workload nyata semakin kuat.
Peningkatan ini mengurangi kasus ketika perilaku cache menjadi outlier, sehingga pelanggan tidak perlu merancang operasi dengan ketidakpastian pada tingkat infrastruktur sebagai asumsi.
Peningkatan Perilaku Kegagalan, Logging, dan Observability
Perilaku kegagalan dan logging ditata ulang agar peristiwa yang terjadi saat muncul masalah lebih mudah dipahami. Pola ketika error di hilir menyebar ke perilaku cache atau transport dan memperburuk pengalaman dikurangi, sehingga blast radius lebih mudah dilokalisasi.
Peningkatan observability dan troubleshooting tidak dimaksudkan untuk mengklaim “tanpa insiden”, melainkan untuk mempersingkat waktu pemulihan ketika insiden terjadi. Hal ini mengurangi risiko pada skenario beban puncak dan operasi berkelanjutan.
Pembaruan Dependency dan Perbaikan Keamanan sebagai Prasyarat Operasi Jangka Panjang
Kami menyertakan pembaruan dependency dan perbaikan keamanan untuk mempertahankan prasyarat operasi platform jangka panjang. Ini mencakup pembaruan terkait minimum supported Rust version (MSRV) dan keselarasan CI, yang memperkuat fondasi agar platform dapat terus berkembang.
Kemampuan untuk terus melakukan pembaruan secara aman merupakan persyaratan kualitas jangka panjang itu sendiri.
Transisi menuju Operasi Tanpa Downtime
Sebelumnya, downtime singkat dapat terjadi saat perubahan konfigurasi jaringan atau upgrade platform. Melalui pembaruan ini, kami beralih ke arsitektur yang memungkinkan operasi tersebut diterapkan sepenuhnya tanpa downtime.
Endpoint bersama memiliki koneksi yang selalu aktif dan momen berkelanjutan ketika waktu sangat penting. Downtime singkat sekalipun dapat memicu efek berantai disconnect, reconnect, dan resync, lalu biaya tersebut menyebar ke hasil. Update tanpa downtime mengurangi kemungkinan efek berantai ini dan mencegah operasi berumur panjang terfragmentasi.
Pada saat yang sama, ERPC kini memiliki kondisi operasional yang memungkinkan masalah yang teramati segera ditindaklanjuti dengan perbaikan. Frekuensi iterasi yang lebih tinggi memungkinkan kami terus menghilangkan volatilitas dan perilaku edge case dalam operasi produksi.
Dampak pada Setiap Layanan
Solana RPC (HTTP/WebSocket)
Peningkatan inisiasi koneksi, TLS, kontrol cache, dan perilaku transport memengaruhi pembacaan data serta pengiriman transaksi. Sembari mempertahankan kemudahan penggunaan sehari-hari, faktor yang membuat hasil bias saat beban puncak dikurangi dan kondisi untuk mempertahankan kapasitas ketika macet diperkuat.
Geyser gRPC
Kontinuitas koneksi meningkat bagi penggunaan streaming berumur panjang. Transport HTTP/2, konsistensi timeout, kesehatan connection pool, dan perluasan pengukuran transport bekerja bersama untuk mengurangi kemungkinan biaya reconnect/resync menyebar ke hasil.
Shredstream (Direct Shreds)
Dengan peningkatan pengelolaan serta inisiasi koneksi yang dirancang bagi pengiriman berkelanjutan, kondisi diperkuat agar kehilangan data atau peningkatan latensi lebih kecil kemungkinannya saat terjadi kemacetan. Kontinuitas stabil bagi deteksi dan penyelesaian lebih mudah dipertahankan.
Menghubungkan R&D dengan Operasi Produksi
Fondasi sistem terdistribusi yang mencakup ERPC telah diakui sebagai proyek R&D dalam program WBSO pemerintah Belanda. Sebuah struktur telah dibangun agar masalah yang teramati secara operasional dapat dimasukkan sebagai subjek riset dan ditingkatkan melalui verifikasi serta iterasi.
Pembaruan fondasi jaringan ini merupakan salah satu iterasi yang diterapkan di seluruh region dan tercermin pada performa serta stabilitas nyata. Mempertahankan hubungan operasi dan R&D menjadi prasyarat untuk terus menghubungkan hal yang teramati di produksi dengan pembaruan berikutnya, bukan berhenti pada perbaikan satu kali.
Di ERPC, pola penggunaan aktual, variasi beban, dan perilaku failure mode dimasukkan ke siklus verifikasi serta peningkatan berulang yang secara bertahap menaikkan kualitas fondasi jaringan. Pembaruan ini dijalankan dalam kerangka terpadu R&D dan operasi produksi tersebut.
Informasi bagi Pelanggan
Pembaruan ini telah diterapkan pada seluruh region dan endpoint bersama. Pelanggan ERPC yang sudah ada tidak perlu mengubah konfigurasi atau operasi. Harga, spesifikasi, autentikasi, dan rate limit tidak berubah.
Karena endpoint bersama harus menanggung lonjakan singkat dan koneksi berumur panjang secara bersamaan, kondisi telah ditata ulang agar perilaku tidak mudah menjadi bias dalam workload campuran tersebut. Meskipun perubahan konfigurasi atau update platform terjadi selama operasi, perubahan diterapkan tanpa downtime sehingga pelanggan tidak perlu memasukkan fragmentasi koneksi atau resync ke dalam desain operasional.
Untuk pertanyaan mengenai arsitektur, optimasi sesuai workload, atau feedback operasional, silakan hubungi kami melalui Discord resmi Validators DAO.
Dengan terus menghubungkan observasi dan feedback produksi ke peningkatan, ERPC secara bertahap menaikkan kualitas fondasinya. Kami akan terus mengakumulasi peningkatan tanpa downtime dan menyediakan infrastruktur jaringan yang mempertahankan hasil Solana di lingkungan nyata.
Discord resmi Validators DAO: https://discord.gg/C7ZQSrCkYR\
Situs resmi ERPC: https://erpc.global/id
