Memenangkan Persaingan Milidetik: Shred, LaserStream, dan Keunggulan di Solana

Apa itu shred?

Shred adalah unit dasar yang memungkinkan propagasi data berperforma tinggi di Solana dan memberikan akses awal ke perubahan status on-chain.

Solana dirancang untuk kecepatan dan throughput maksimum. Untuk mencapainya, Solana tidak dapat mengirimkan blok sebagai satu unit besar melalui jaringan. Sebaliknya, blok dibagi menjadi paket-paket lebih kecil yang dikenal sebagai shred—unit atomik propagasi data di Solana. 

Shred ini mewakili bagian-bagian data transaksi sebelum dirangkai menjadi sebuah blok. Setiap shred berukuran sekitar 1,2 KB dan dioptimalkan agar sesuai dengan Maximum Transmission Unit (MTU) paket jaringan standar guna memastikan pengiriman secepat kilat tanpa fragmentasi. 

Ada dua jenis shred:

Data Shred

Data shred merangkum data transaksi inti dari sebuah blok yang dibagi menjadi bagian-bagian berukuran tetap. Data shred mencakup batch entri terserialisasi, yaitu kelompok transaksi yang diawali dengan jumlah untuk pemrosesan yang efisien.

Coding Shred

Coding shred menyediakan redundansi menggunakan Reed-Solomon erasure coding, teknik koreksi galat maju yang menghasilkan data paritas. Teknik ini memungkinkan shred yang hilang atau rusak untuk direkonstruksi. Coding shred diatur dalam set Forward Error Correction (FEC) bersama data shred, biasanya dengan rasio seimbang (misalnya 32 data shred berbanding 32 coding shred) agar mampu menoleransi kehilangan paket hingga 50%. Leader dapat menyesuaikan rasio ini berdasarkan kondisi jaringan untuk mempertahankan keandalan yang tinggi.

Bagaimana shred dipropagasikan di Solana?

Proses dimulai ketika leader (yaitu validator yang saat ini bertanggung jawab memproduksi blok) mengelompokkan dan menserialisasi transaksi menjadi entri. Entri tersebut kemudian dibagi, atau di-shred, menjadi segmen-segmen lebih kecil yang disebut shred. Semua shred ditandatangani oleh leader menggunakan sistem lama (yaitu menandatangani setiap shred satu per satu) atau skema berbasis Merkle (yaitu menandatangani root Merkle dari seluruh set FEC), sebagaimana ditetapkan dalam spesifikasi shred Solana. Proses ini memastikan keaslian dan integritas data. 

Shred dikirimkan ke validator lain menggunakan Turbine, sistem propagasi berlapis berbasis fanout milik Solana. Dalam Turbine, leader mengirimkan shred ke root node, yang mendistribusikannya ke lapisan validator berikutnya dalam struktur menyerupai pohon. Setiap lapisan meneruskan shred ke lapisan berikutnya dengan fanout 200 node per lapisan, biasanya melalui 2 hingga 3 hop tergantung jumlah validator aktif. Struktur pohon ini meminimalkan bandwidth sekaligus mendistribusikan transaksi ke seluruh jaringan dalam hitungan milidetik.

Pengacakan berbobot stake memprioritaskan pengiriman ke validator dengan stake lebih tinggi. Turbine pertama-tama mengurutkan validator berdasarkan jumlah stake yang mereka miliki (yaitu bobot stake). Validator dengan stake lebih tinggi ditempatkan lebih awal dalam daftar ini. Setelah pengacakan deterministik, validator tersebut cenderung berada di lapisan awal pohon yang lebih dekat dengan leader. Dengan demikian, lebih sedikit hop berarti latensi lebih rendah. Jadi, validator dengan stake lebih besar menerima shred lebih cepat.   

Catatan: Turbine akan digantikan oleh Rotor pada masa mendatang setelah Alpenglow diterapkan. Bahkan setelah perubahan ini, stake validator akan tetap memengaruhi peer tujuan broadcast validator tersebut.

Bagaimana shred dirangkai kembali menjadi blok?

Setelah diterima oleh validator, shred dirangkai kembali dengan terlebih dahulu memverifikasi tanda tangannya untuk memastikan keaslian, lalu menggunakan Reed-Solomon erasure coding untuk merekonstruksi data shred yang hilang atau rusak dari coding shred yang tersedia dalam set FEC. 

Data shred yang telah direkonstruksi kemudian melalui proses deshredding. Artinya, payload-nya digabungkan secara berurutan menggunakan indeks shred untuk membentuk kembali batch entri terserialisasi. 

Batch tersebut kemudian dideserialisasi menjadi transaksi dan entri individual yang dapat dirangkai menjadi blok lengkap.

Mengapa shred penting? 

Shred penting karena mempersempit jendela reaksi di jaringan yang sangat mengutamakan ketepatan waktu. 

Shred sangat penting untuk memaksimalkan keunggulan performa tinggi Solana, khususnya dalam aplikasi sensitif terhadap latensi seperti perdagangan berfrekuensi tinggi, desk request-for-quote (RFQ), mesin likuidasi, dan pembaruan oracle. 

Shred memberikan visibilitas paling awal terhadap peristiwa on-chain yang sedang terjadi. Ini berbeda dari sebagian besar blockchain lain, tempat aplikasi harus menunggu hingga produksi dan konfirmasi blok selesai, yang dapat menambah penundaan mulai dari ratusan milidetik hingga beberapa detik. 

Shred mentah bisa sulit digunakan karena penerima harus memverifikasi keasliannya, merekonstruksi data shred yang hilang, melakukan deshredding dan deserialisasi menjadi transaksi serta entri, lalu menguraikannya untuk menemukan peristiwa yang dapat ditindaklanjuti seperti swap atau perubahan akun.

Jika Anda menginginkan keunggulan latensi dari shred tanpa membangun pipeline tersebut, Preprocessed Transactions akan melakukan deshredding untuk Anda dan melakukan streaming transaksi yang telah ditandatangani melalui WebSocket hingga 8 md sebelum tingkat komitmen processed.

Namun, “tampilan awal” terhadap transaksi tertunda dan pembaruan akun ini menawarkan keunggulan yang tak tertandingi dan secara langsung menghasilkan tingkat keberhasilan lebih tinggi dalam situasi kompetitif.

Sebagai contoh, bot likuidasi yang memantau rasio jaminan dapat mendeteksi dan menindak posisi rentan menggunakan shred jauh sebelum pesaing yang memakai metode lebih lambat seperti WebSockets, sehingga memenangkan likuidasi. 

Demikian pula, trader arbitrase yang mengidentifikasi inefisiensi pasar dan agregator DEX berlatensi rendah yang memberikan kuotasi harga dapat memanfaatkan keunggulan latensi ini karena milidetik menentukan profitabilitas.

Hierarki Latensi Shred

Penting untuk dicatat bahwa latensi shred tidak seragam di semua sumber.

Validator dengan Stake Tinggi

Validator dengan jumlah stake signifikan menerima prioritas tertinggi dalam pohon propagasi Turbine. Validator tersebut sering menerima shred langsung dari leader atau melalui lapisan fanout awal dan memperoleh manfaat dari Stake-Weighted Quality of Service (SWQoS).

Validator dengan Stake

Validator dengan jumlah stake sedang mengalami penundaan moderat akibat prioritas yang lebih rendah dalam antrean propagasi karena shred perlu melewati hop tambahan. Keterlibatan validator tersebut dalam konsensus memastikan akses yang andal, meskipun latensi dapat sedikit bervariasi berdasarkan posisi jaringan dan distribusi stake saat ini. Dibandingkan validator dengan stake tinggi, validator dengan stake rendah kurang ideal untuk operasi sangat kompetitif dan sensitif terhadap waktu.

Validator Tanpa Stake

Validator tanpa stake tidak memiliki keunggulan kualitas layanan yang dimiliki node dengan stake dan tidak cocok untuk melakukan streaming data Solana secara real-time bagi operasi yang sangat sensitif terhadap latensi. Validator ini menerima shred paling akhir dalam fanout Turbine.

Semakin awal posisi Anda dalam pohon, semakin banyak waktu yang Anda miliki untuk bereaksi sebelum seluruh jaringan menyusul. 

Variabilitas Global 

Yang penting, Turbine tidak bergantung pada lokasi. Propagasi global dapat memperbesar variabilitas latensi karena jarak fisik dan kondisi jaringan menimbulkan penundaan di luar hop Turbine. 

Misalnya, shred yang bergerak antarwilayah (misalnya dari leader yang berbasis di AS ke validator Asia Pasifik) dapat mengalami penundaan akibat perutean lintas benua, transmisi ulang paket, atau bahkan masalah peering—termasuk untuk validator dengan stake tinggi di lapisan awal Turbine.

Penyebaran geografis ini menciptakan peluang untuk optimasi. Meskipun satu validator dengan stake tinggi mungkin unggul secara lokal, validator tersebut dapat tertinggal secara global jika tidak ditempatkan secara optimal. Hal ini dapat diatasi dengan jaringan shred terdistribusi yang menggabungkan shred tercepat dari berbagai sumber, sehingga mengurangi varians dan menghasilkan kecepatan penerimaan yang konsisten. Dalam skenario global, sistem semacam ini dapat secara konsisten mengungguli validator dengan stake tertinggi.

Akses yang andal ke shred dari sumber yang dioptimalkan sangat penting untuk mempertahankan keunggulan kompetitif bagi developer yang membangun sistem sangat sensitif terhadap latensi. Namun, hal ini memerlukan infrastruktur tangguh untuk menangani pemulihan, verifikasi, dan distribusi global secara efektif. Selain itu, sebagian besar alat streaming data real-time populer di Solana saat ini belum memanfaatkan shred.

Streaming Data di Solana

Di Solana, developer yang ingin melakukan streaming data real-time memiliki beberapa opsi. Masing-masing memiliki kompromi tersendiri dalam hal latensi, keandalan, dan kompleksitas:

Webhook

Webhook memungkinkan pembaruan berbasis peristiwa dengan mengirimkan data ke aplikasi Anda saat terjadi perubahan pada akun atau program tertentu. Webhook mudah diintegrasikan secara terprogram dan bahkan dapat disiapkan tanpa menulis kode langsung di Dasbor Helius. Developer dapat melakukan streaming data yang telah diuraikan dan mudah dibaca untuk jenis transaksi tertentu, payload transaksi mentah, serta mengirimkan pembaruan ini langsung ke channel Discord tertentu sebagai pesan terformat.

Meskipun webhook sangat andal dan digunakan oleh banyak perusahaan terkemuka di Solana, webhook mengirimkan notifikasi setelah transaksi dikonfirmasi. Artinya, webhook dapat tertinggal ratusan milidetik dari data tingkat shred sehingga terlalu lambat untuk operasi sangat sensitif terhadap latensi seperti perdagangan berfrekuensi tinggi atau likuidasi.

WebSockets Standar

API JSON RPC Solana mendukung langganan WebSocket, seperti accountSubscribe untuk perubahan akun, logSubscribe untuk log transaksi, dan programSubscribe untuk peristiwa program. WebSockets mempertahankan koneksi persisten antara klien dan penyedia RPC serta melakukan streaming pembaruan segera setelah transaksi dan perubahan akun diproses. WebSockets bersifat dua arah dan cocok untuk memantau akun atau peristiwa tertentu secara real-time sekaligus mengurangi overhead polling.

Namun, seperti webhook, WebSockets mengirimkan data setelah shred dirangkai kembali (yaitu pada tingkat komitmen processed, confirmed, atau finalized), sehingga menambah latensi antara 400 md hingga 30 detik, bergantung pada tingkat komitmennya. 

WebSockets juga dianggap sebagai jenis koneksi yang rapuh. Artinya, koneksi dapat terputus akibat berbagai masalah sehingga memerlukan logika percobaan ulang khusus. Pemutusan koneksi dapat menyebabkan kehilangan data permanen kecuali dilengkapi dengan polling, yang mengurangi keandalan real-time. 

Enhanced WebSockets

Enhanced WebSockets merupakan peningkatan signifikan dibandingkan WebSockets standar, dengan sejumlah optimasi performa dan kemampuan pemfilteran yang lebih baik. Secara khusus, penguraian peristiwa yang lebih baik dan lebih sedikit noise membuatnya lebih ramah bagi developer untuk penggunaan produksi.

Enhanced WebSockets dapat mengurangi latensi dibandingkan WebSockets standar dan sangat baik untuk aplikasi streaming umum. Misalnya, ada perbedaan performa yang nyata saat melakukan streaming data Pump AMM dengan Enhanced WebSockets dibandingkan menggunakan WebSockets standar maupun webhook. 

Namun, secara mendasar Enhanced WebSockets masih mengirimkan data setelah shred dirangkai kembali. Sekali lagi, hal ini membatasi kegunaannya untuk aplikasi yang mengutamakan setiap milidetik. Selain itu, meskipun telah ditingkatkan, Enhanced WebSockets tidak memiliki pemutaran ulang atau failover otomatis sehingga penanganan kesenjangan harus dilakukan secara manual. 

Yellowstone gRPC

Yellowstone gRPC adalah protokol streaming berlatensi rendah dari validator ke klien yang dapat menyediakan akses ke data pada tingkat shred. Hal ini membuatnya jauh lebih cepat daripada WebSockets dan webhook karena dapat mengirimkan pembaruan lebih cepat untuk tingkat komitmen masing-masing. 

Yellowstone menawarkan streaming dua arah dengan pembuatan dan pembatalan langganan secara langsung, serta kemampuan pemfilteran tingkat lanjut untuk mengontrol secara presisi data yang Anda terima sebagai respons terhadap pembaruan transaksi, akun, atau program tertentu.

Yellowstone ideal bagi pengguna yang tidak menginginkan batas laju maupun kredit serta membutuhkan jaminan perangkat keras terisolasi untuk konfigurasi node khusus. Namun, ada beberapa kompromi utama:

1. Beban Infrastruktur

Anda memerlukan node khusus sendiri untuk memanfaatkan potensi penuh Yellowstone gRPC. Hal ini memerlukan akses ke perangkat keras, konfigurasi yang tepat, pengelolaan berkelanjutan atas perangkat keras tersebut, dan keahlian khusus untuk men-debug masalah terkait perangkat keras.

2. Variabilitas Latensi

Hanya karena Yellowstone gRPC dapat mengirimkan data pada tingkat shred, bukan berarti pengirimannya selalu paling optimal. Latensi dapat bervariasi bergantung pada penyedia Anda dan apakah node khusus Anda dipasangkan dengan sumber yang dioptimalkan untuk shred (yaitu validator dengan stake tinggi). Jika dipasangkan dengan validator yang memiliki stake sedang hingga rendah, validator tersebut tidak akan secara konsisten berada di lapisan pertama Turbine. Akibatnya, Anda tetap menerima banyak shred di bagian hilir.

3. Risiko Kegagalan

Mengandalkan satu node khusus menciptakan satu titik kegagalan. Risiko ini diperburuk oleh fakta bahwa Yellowstone gRPC tidak memiliki kemampuan pemutaran ulang bawaan.

4. Kebutuhan Sumber Daya

Membebani node khusus dengan panggilan RPC intensif sekaligus melakukan streaming data melalui Yellowstone dapat menurunkan performa. 

Selama ini, bagi banyak tim, Yellowstone gRPC menjadi layanan streaming pilihan untuk data real-time di Solana. Layanan ini cepat dan cocok bagi pengguna tingkat lanjut, tetapi sulit dioperasikan untuk menyediakan cakupan global berlatensi rendah yang konsisten tanpa akses ke sekumpulan node khusus di seluruh dunia.

LaserStream

LaserStream menggabungkan kecepatan penerimaan tingkat shred dengan keandalan dan jangkauan layanan yang tersebar secara global, tanpa biaya atau kerepotan operasional untuk menjalankan beberapa node khusus. 

LaserStream mencapainya melalui:

• Penerimaan dari Berbagai Sumber: LaserStream menerima shred dengan latensi terendah dan secara konsisten mengungguli pesaing di seluruh dunia.
• Cakupan Global: LaserStream tersedia di berbagai wilayah di seluruh dunia, sehingga developer dapat menggunakan endpoint yang paling dekat dengan infrastruktur mereka. Setiap wilayah menjalankan beberapa server untuk redundansi, dengan failover otomatis.
• Tanpa Kesenjangan:  Pemutaran ulang historis LaserStream memungkinkan developer memutar ulang data blockchain terbaru hingga 48 jam ke belakang. Fitur ini berguna untuk menangani pemutusan koneksi dan memastikan kontinuitas data. 
• Pengalaman yang Ramah bagi Developer: LaserStream adalah pengganti langsung untuk Yellowstone gRPC—tanpa migrasi, tanpa sintaks baru, tanpa kerepotan.

Singkatnya, LaserStream merupakan peningkatan yang dapat diskalakan, berlatensi rendah, dan toleran terhadap kegagalan dibandingkan Yellowstone gRPC dan WebSockets. LaserStream secara konsisten menyediakan peristiwa on-chain segera setelah terjadi di jaringan, tanpa mengharuskan Anda memiliki stake bernilai jutaan atau mengoperasikan sendiri infrastruktur berperforma tinggi. 

LaserStream adalah cara termudah untuk memanfaatkan kekuatan shred bagi streaming data berlatensi sangat rendah di Solana.

Klien dan Performa

LaserStream menyediakan klien dalam Go, Rust, dan JavaScript/TypeScript. Klien ini menangani pemutaran ulang otomatis saat koneksi terputus dengan terus melacak slot yang telah di-streaming. Jika koneksi terputus karena alasan apa pun, klien akan otomatis terhubung kembali dan melanjutkan streaming dari slot terakhir yang diproses.

Klien JavaScript LaserStream sangat menarik karena menggunakan binding Rust native. Berkat hal ini, klien tersebut menawarkan throughput 1,3 GB/dtk. Ini merupakan peningkatan 40x dibandingkan klien JavaScript Yellowstone gRPC saat ini, yang memiliki batas maksimum 30 MB/dtk. 

Seiring Solana terus berkembang, klien JavaScript Yellowstone gRPC akan kesulitan mengimbanginya. Ruang performa yang tersedia pada klien JavaScript LaserStream memastikan aplikasi Anda dapat diskalakan dengan aman bersama jaringan saat permintaan meningkat. 

Keberhasilan di Dunia Nyata

DFlow, agregator DEX berlatensi rendah, baru-baru ini mengintegrasikan LaserStream untuk memasok data ke mesin harganya. Keputusan untuk melakukan integrasi didasarkan pada kemampuan untuk berkembang secara global tanpa perlu mengkhawatirkan node khusus, sekaligus menghemat kapasitas engineering agar dapat berfokus pada perutean dan kode bisnis. 

Sejak integrasi tersebut, DFlow dilaporkan telah menghemat lebih dari delapan jam overhead engineering berulang, mempertahankan uptime 100% dengan streaming data tanpa gangguan, dan meningkatkan kecepatan kuotasi berkat konfirmasi transaksi yang lebih cepat. 

Streaming Lebih Cepat, Mulai Hari Ini.

Milidetik bukan sekadar latensi—melainkan peluang. Dengan LaserStream, Anda tidak hanya mengikuti kecepatan jaringan. Anda selalu selangkah lebih maju. 

Menginginkan data subdetik untuk perdagangan, likuidasi, atau oracle? Gunakan LaserStream dan dapatkan akses ke data Solana tercepat yang tersedia. 

Sebagai alternatif, bagi pengguna tingkat lanjut yang tertarik dengan pengiriman shred mentah, hubungi kami dengan mengisi formulir berikut.

Referensi Lebih Lanjut

• LaserStream
• Modul Shred Agave
• Spesifikasi Shred Solana