Turbine: Propagasi Blok di Solana

Apa yang dibahas dalam artikel ini?

Ketersediaan data sangat penting bagi blockchain. Ketersediaan data memastikan semua informasi yang diperlukan dapat diakses dengan mudah oleh node untuk keperluan validasi, sehingga integritas dan keamanan jaringan tetap terjaga. Namun, memastikan ketersediaan data sekaligus mempertahankan performa tinggi merupakan tantangan besar, terutama saat jaringan berkembang.

Solana menjawab tantangan ini dengan desain arsitektur unik yang memungkinkan pembuatan dan propagasi blok secara berkelanjutan. Hal ini dimungkinkan oleh beberapa inovasi utama seperti pemilihan leader, Gulf Stream (menghilangkan kebutuhan akan mempool), dan Turbine (mekanisme propagasi blok).

Sifat Solana yang berkelanjutan memerlukan sistem efisien untuk memastikan semua validator segera menerima state terbaru. Dalam pendekatan sederhana, leader akan mengirimkan semua blok secara langsung ke setiap validator lain. Namun, mengingat throughput Solana yang tinggi, metode ini akan meningkatkan kebutuhan bandwidth dan sumber daya lainnya secara signifikan, sekaligus melemahkan desentralisasi.

Bandwidth adalah sumber daya yang terbatas, dan Turbine merupakan solusi cerdas Solana untuk mengoptimalkan propagasi informasi dari leader suatu blok ke seluruh jaringan. Turbine dirancang secara khusus untuk mengurangi beban egress (pengiriman data keluar) dari leader ke jaringan.

Dalam artikel ini, kita akan membahas cara kerja Turbine serta peran pentingnya dalam lanskap inklusi transaksi Solana yang lebih luas. Kita juga akan membandingkan Turbine dengan solusi ketersediaan data lainnya dan membahas peluang riset yang masih terbuka dalam bidang ini.

Apa itu Turbine?

Turbine adalah mekanisme propagasi blok berlapis yang digunakan oleh cluster Solana untuk menyiarkan entri ledger ke semua node. Gagasan inti di balik Turbine telah lama menjadi perhatian para akademisi, sebagaimana ditunjukkan oleh makalah yang diterbitkan pada 2004 serta riset yang lebih baru.

Tidak seperti blockchain tradisional yang mengirimkan blok ke semua node secara berurutan atau melalui flooding, Turbine menggunakan pendekatan yang lebih terstruktur untuk meminimalkan overhead komunikasi dan mengurangi beban pada setiap node. Secara umum, Turbine memecah blok menjadi bagian-bagian yang lebih kecil dan menyebarkannya melalui hierarki node. Dengan demikian, setiap node tidak perlu terhubung dengan semua node lainnya dan hanya perlu berkomunikasi dengan beberapa node terpilih. Hal ini menjadi semakin penting saat ukuran jaringan bertambah karena metode propagasi tradisional tidak lagi praktis akibat besarnya volume komunikasi yang diperlukan. Dengan demikian, Turbine memastikan penyebaran data yang cepat dan efisien di seluruh Solana. Kecepatan propagasi dan verifikasi blok sangat penting untuk mempertahankan throughput tinggi dan keamanan jaringan Solana.

Selain itu, Turbine menangani masalah ketersediaan data dengan memastikan semua node dapat mengakses data yang diperlukan untuk memvalidasi transaksi secara efisien. Hal ini dilakukan tanpa memerlukan bandwidth yang sangat besar, yang sering menjadi hambatan pada jaringan blockchain lain.

Turbine memberikan kontribusi besar terhadap kemampuan Solana menangani volume transaksi tinggi serta mempertahankan struktur jaringan yang ramping dan efisien dengan mengurangi hambatan bandwidth dan memastikan propagasi blok yang cepat. Protokol inovatif ini merupakan salah satu fondasi yang memungkinkan Solana memenuhi janjinya sebagai jaringan yang cepat, aman, dan skalabel.

Sekarang, mari kita pelajari lebih jauh mekanisme Turbine dan cara Turbine mempropagasikan blok ke seluruh jaringan Solana.

Bagaimana Turbine mempropagasikan blok?

Sebelum sebuah blok dipropagasikan (yaitu dikirimkan ke validator lain dalam jaringan), leader menyusun dan mengurutkan blok berdasarkan stream transaksi yang masuk. Setelah disusun, blok siap dikirimkan melalui Turbine ke seluruh jaringan. Proses ini disebut propagasi blok. Pesan vote kemudian diteruskan antark validator, dan pesan tersebut dienkapsulasi dalam data blok untuk memenuhi status commitment “confirmed” atau “finalized”. Blok confirmed adalah blok yang telah menerima supermayoritas vote ledger, sedangkan blok finalized adalah blok yang telah dikonfirmasi dan memiliki lebih dari 31 blok confirmed yang dibangun di atas blok target. Perbedaan status commitment dijelaskan lebih lanjut di sini. Bagian konsensus ini akan dibahas dalam artikel mendatang.

Walaupun leader menyusun dan mengusulkan blok secara utuh, data sebenarnya dikirimkan sebagai shred (bagian blok) ke validator lain dalam jaringan. Shred adalah unit atomik yang dikirimkan antark validator.

Secara umum, Turbine mengambil shred dan mengirimkannya ke sekumpulan validator yang telah ditentukan. Validator tersebut kemudian meneruskan shred itu ke kumpulan validator baru. Diagram berikut menjelaskan proses propagasi shred yang berkelanjutan:

Dalam contoh ini, Validator 1 adalah slot leader yang ditunjuk. Selama slot-nya (validator ditetapkan sebagai leader untuk 4 slot berturut-turut), Validator 1 menyusun dan mengusulkan sebuah blok. Validator 1 terlebih dahulu memecah blok menjadi subblok yang disebut shred melalui proses bernama shredding. Shredding membagi data blok menjadi data shred berukuran Maximum Transmission Unit (MTU) (jumlah maksimum data yang dapat dikirimkan dari satu node ke node berikutnya tanpa memecahnya menjadi unit yang lebih kecil) dan menghasilkan recovery shred terkait melalui skema erasure coding Reed-Solomon. Skema ini membantu pemulihan data dan memastikan integritas data selama transmisi, yang sangat penting untuk menjaga keamanan dan keandalan jaringan.

Proses shredding dan propagasi ini memastikan distribusi data blok yang cepat dan efisien di seluruh Solana, sekaligus mempertahankan throughput tinggi dan keamanan jaringan.

Erasure Coding

Sebelum shred dipropagasikan melalui Turbine Tree, shred terlebih dahulu dienkode menggunakan erasure coding Reed-Solomon, yaitu skema deteksi dan koreksi kesalahan berbasis polinomial. Erasure coding digunakan sebagai metode perlindungan data agar data asli dapat dipulihkan meskipun beberapa bagiannya hilang atau rusak selama transmisi. Erasure coding Reed-Solomon merupakan jenis khusus algoritma Forward Error Correction (FEC).

Karena Turbine pada dasarnya bergantung pada serangkaian transmisi ulang paket oleh validator downstream, validator tersebut dapat bersifat jahat (node Byzantine adversarial) dengan memilih untuk menyiarkan ulang data yang salah, atau menerima data yang tidak lengkap (kehilangan paket jaringan). Karena struktur pohon transmisi ulang Turbine, setiap kehilangan paket di seluruh jaringan akan berlipat ganda, dan kemungkinan paket gagal mencapai tujuannya meningkat pada setiap hop.

Secara umum, jika leader mengirimkan 33% paket blok sebagai erasure code, jaringan dapat kehilangan 33% paket mana pun tanpa kehilangan blok tersebut. Leader dapat menyesuaikan angka ini (tingkat FEC) secara dinamis berdasarkan kondisi jaringan dengan mempertimbangkan variabel seperti kehilangan paket di seluruh jaringan yang baru diamati dan kedalaman pohon.

Agar lebih sederhana, mari kita telaah grup shred dengan tingkat FEC 4:4.

Data shred adalah bagian blok dari blok asli yang disusun oleh leader, sedangkan recovery shred adalah blok hasil erasure coding yang dibuat oleh Reed-Solomon.

Blok di Solana biasanya menggunakan FEC 32:32 (32 dari 64 paket dapat hilang tanpa perlu dikirimkan ulang). Sebagaimana dijelaskan dalam dokumentasi Solana, berikut adalah asumsi jaringan konservatif yang digunakan:

• Tingkat kehilangan paket 15%
• 50 ribu TPS menghasilkan 6.400 shred per detik

Tingkat FEC 32:32 menghasilkan tingkat keberhasilan blok sebesar ~99%. Selain itu, leader dapat meningkatkan tingkat FEC jika ingin memperbesar kemungkinan keberhasilan blok.

Turbine saat ini menggunakan UDP untuk propagasi blok, yang memberikan manfaat latency sangat besar. Menurut seorang operator validator, transmisi data sebesar 6 MB + erasure coding dari us-east-1 ke eu-north-1 menggunakan UDP membutuhkan 100 md, sedangkan TCP membutuhkan 900 md.

Turbine Tree

Turbine Tree adalah topologi jaringan terstruktur yang digunakan Solana untuk memfasilitasi propagasi shred (data blok yang telah dienkode) secara efisien di antara validator. Setelah shred dienkode dengan benar ke dalam grup shred masing-masing, shred siap disebarkan melalui Turbine Tree untuk memberi tahu validator lain dalam jaringan tentang state terbaru.

Setiap grup shred dikirimkan melalui paket jaringan ke root node khusus yang mengelola validator mana saja yang menjadi bagian dari lapisan pertama (berjarak 1 hop). Langkah-langkah berikut kemudian dijalankan:

1. Pembuatan Daftar: Root node mengumpulkan semua validator aktif ke dalam sebuah daftar, lalu mengurutkannya berdasarkan stake yang dimiliki setiap validator dalam jaringan. Validator dengan bobot stake lebih tinggi diprioritaskan untuk menerima shred lebih awal, sehingga dapat merespons lebih cepat dengan pesan vote mereka sendiri untuk konsensus.
2. Pengacakan Daftar: Daftar ini kemudian diacak secara deterministik. Proses ini menciptakan “Turbine Tree” yang dihasilkan dari kumpulan node validator untuk setiap shred menggunakan seed yang berasal dari ID slot leader, slot, indeks shred, dan jenis shred. Pohon baru dibuat saat runtime untuk setiap grup shred guna mengurangi potensi risiko keamanan yang terkait dengan struktur pohon statis.
3. Pembentukan Lapisan: Node kemudian dibagi menjadi beberapa lapisan, dimulai dari bagian teratas daftar. Pembagian didasarkan pada nilai DATA_PLANE_FANOUT, yang menentukan lebar dan kedalaman Turbine Tree. Nilai ini memengaruhi seberapa cepat shred dapat dipropagasikan melalui jaringan. Saat ini, DATA_PLANE_FANOUT bernilai 200, sehingga sebagian besar validator hanya berjarak 2–3 hop (leader -> root -> L1 -> L2).

Karena Turbine Tree diketahui oleh semua pihak, setiap validator mengetahui secara tepat ke mana mereka bertanggung jawab meneruskan shred tersebut. Turbine Tree biasanya merupakan pohon dengan 2 atau 3 hop (tergantung jumlah validator aktif), berdasarkan nilai DATA_PLANE_FANOUT saat ini sebesar 200.

Selain itu, node dapat beralih ke gossip dan repair jika tidak menerima cukup shred atau jika tingkat kehilangan melampaui tingkat FEC. Dalam implementasi saat ini, node yang tidak memiliki cukup shred untuk merekonstruksi blok akan mengirimkan permintaan kepada leader untuk transmisi ulang. Dalam Turbine deterministik, node mana pun yang menerima blok secara lengkap dapat mengirimkan repair shred yang diperlukan node peminta, sehingga mendorong transmisi data lebih jauh ke area pohon yang meminta data.

Membandingkan Propagasi Blok Solana dan Ethereum

Propagasi blok di Solana berbeda dari Ethereum. Berikut beberapa perbedaan utamanya:

• Kebutuhan bandwidth ideal Solana (>1 Gbps) jauh lebih tinggi daripada Ethereum (geth merekomendasikan >25 Mbps). Kebutuhan bandwidth yang lebih tinggi ini disebabkan oleh ukuran blok Solana yang lebih besar dan waktu blok yang lebih singkat. Desain Solana memungkinkan penggunaan seluruh bandwidth secara efektif untuk mempercepat transmisi data, sehingga mengurangi latency. Walaupun terdapat lonjakan bandwidth hingga 1 Gbps, Solana tidak terus-menerus menggunakan 1 Gbps. Arsitektur Solana secara khusus memungkinkan terjadinya lonjakan kebutuhan bandwidth.
• Solana menggunakan Turbine untuk propagasi data blok, sedangkan Ethereum menggunakan protokol gossip standar. Di Ethereum, propagasi data blok dilakukan secara langsung: setiap node berkomunikasi dengan setiap full node lain dalam jaringan. Saat terdapat blok baru, client akan memverifikasinya dengan mengirimkan blok tersebut kepada peer mereka dan menyetujui transaksi yang ada di dalam blok. Mekanisme ini sesuai untuk Ethereum karena ukuran bloknya lebih kecil dan waktu bloknya lebih panjang dibandingkan Solana. Untuk data rollup Ethereum L2 (selain validium), propagasinya juga mengikuti protokol gossip, dengan data blok disimpan dalam field “calldata” pada blok Ethereum L1.
• Ethereum menggunakan TCP (melalui protokol DevP2P) untuk propagasi blok, sedangkan Solana menggunakan UDP (dengan dukungan sebagian komunitas untuk beralih ke QUIC). Ada beberapa kompromi yang perlu dipertimbangkan antara UDP dan QUIC:
• Sifat satu arah UDP menghasilkan latency yang lebih rendah dibandingkan QUIC, yang memerlukan stream QUIC. Diskusi masih berlangsung mengenai implementasi stream satu arah ke dalam QUIC.
• Para pendukung QUIC menegaskan bahwa meskipun alur kontrol khusus dapat dibuat di atas UDP, hal tersebut memerlukan upaya rekayasa yang besar. QUIC mengurangi beban ini dengan mendukung fitur tersebut secara native. Tujuan akhirnya sama, tetapi batas atas performa QUIC (latency, throughput, dan sebagainya) setara dengan kondisi UDP murni saat ini.

Perbedaan ini menegaskan keputusan arsitektur unik yang diambil oleh Solana dan Ethereum, yang berkontribusi terhadap performa, skalabilitas, dan ketahanan jaringan masing-masing. Untuk analisis lebih mendalam tentang TCP, UDP, dan QUIC, baca artikel kami mengenai Solana dan QUIC.

Pertanyaan Riset Mendatang

Propagasi blok dan ketersediaan data tetap menjadi area riset terbuka, dengan banyak tim mengembangkan pendekatan unik mereka sendiri. Walaupun metriknya dapat berkembang, kami ingin memberikan gambaran umum tentang berbagai pendekatan dan kompromi yang menyertainya:

• Sejumlah diskusi muncul mengenai posisi Turbine sebagai mekanisme “ketersediaan data” (DA). Turbine berfungsi sebagai mekanisme ketersediaan data karena seluruh data blok dipublikasikan dan diunduh oleh semua validator lain di Solana. Namun, Turbine belum mendukung data availability sampling (DAS), fitur yang membantu light node memverifikasi state dengan kebutuhan hardware yang lebih rendah. Hal ini menjadi fokus pengembangan aktif bagi tim seperti Celestia. Seperti Turbine, DAS juga menggunakan erasure code, tetapi secara khusus bertujuan mendeteksi dan mencegah serangan penahanan data.
• Untuk L2 Solana Virtual Machine (SVM) seperti Eclipse, Turbine kehilangan relevansinya karena tidak ada kumpulan validator untuk saling meneruskan data. Dalam kasus Eclipse, data blok dipublikasikan ke Celestia untuk ketersediaan data – hal ini memungkinkan pengamat eksternal menjalankan fraud proof untuk memastikan eksekusi dan transisi state yang benar. Eclipse akan menjadi salah satu implementasi pertama SVM di luar jaringan Solana itu sendiri. Pyth juga telah melakukan fork SVM untuk jaringan oracle miliknya yang disebut “Pythnet” dan secara efektif berjalan sebagai sidechain tersendiri.
• Di Solana, full node mengelola propagasi blok sekaligus terlibat dalam bagian lain dari stack blockchain terintegrasi, seperti pengurutan transaksi dan konsensus. Bagaimana metrik kuantitatif Turbine jika dioperasikan sebagai komponen modular pada hardware khusus?
• Turbine memprioritaskan node dengan bobot stake lebih tinggi untuk menerima data blok terlebih dahulu. Apakah hal ini akan menyebabkan sentralisasi MEV yang lebih besar seiring waktu?
• Bagaimana berbagai pendekatan ketersediaan data seperti EigenDA (relayer unicast tunggal yang dapat diskalakan secara horizontal) dan Celestia (data availability sampling) dibandingkan dengan Turbine di lingkungan produksi dalam hal throughput mentah dan minimalisasi kepercayaan?
• Firedancer bertujuan meningkatkan propagasi data lebih jauh dan dioptimalkan untuk koneksi bandwidth 10 Gbps yang andal. Bagaimana performa optimasi tingkat sistem yang mereka buat untuk Turbine di lingkungan produksi, baik pada hardware kelas konsumen maupun hardware kelas profesional?
• Saat ini, semua node di Solana merupakan full node (implementasi light client masih dalam pengembangan). Sreeram Kannan (EigenLayer) baru-baru ini menjelaskan implementasi DAS-S di atas Turbine. Apakah akan ada dukungan untuk versi DAS bagi Turbine? Dapatkah light client dengan DAS diimplementasikan untuk mempertahankan throughput data tinggi sekaligus memenuhi minimalisasi kepercayaan dengan kebutuhan sumber daya yang jauh lebih rendah?

Kesimpulan

Selamat! Dalam artikel ini, kita telah membahas Turbine dan cara kerjanya dalam lanskap inklusi transaksi Solana yang lebih luas. Kita membandingkan Turbine dengan solusi ketersediaan data lainnya dan membahas berbagai peluang riset yang terbuka dalam bidang ini. Protokol Turbine milik Solana menjadi bukti komitmen jaringan untuk mencapai throughput tinggi dan latency rendah dengan memanfaatkan topologi jaringan terstruktur guna menyebarkan data blok secara efisien di antara validator.

Upaya menemukan cara untuk meningkatkan ketersediaan data dan menjadikan propagasi blok lebih efisien mendorong inovasi dalam komunitas blockchain yang lebih luas. Analisis perbandingan mekanisme propagasi blok Solana dan Ethereum menyoroti keunggulan dan kompromi masing-masing, sekaligus mendorong diskusi yang lebih mendalam mengenai bagaimana solusi blockchain baru seperti EigenDA, Celestia, dan Firedancer dapat membentuk ekosistem ini pada masa mendatang.

Solusi untuk propagasi data dan ketersediaan data yang efisien masih jauh dari selesai. Namun, pendekatan Solana dan komitmennya yang teguh untuk mengoptimalkan performa jaringan tanpa mengorbankan keamanan serta minimalisasi kepercayaan sangat disambut baik.

Terima kasih kepada @dubbel06 dan @jon_charb atas tinjauan dan komentarnya.

Sumber Daya Tambahan / Bacaan Lebih Lanjut

• Propagasi Blok Turbine
• Memahami Erasure Coding
• Blok Ethereum
• Peningkatan Jaringan Pyth Perseus
• Pengantar EigenDA: Ketersediaan Data Hyperscale untuk Rollup
• Firedancer