Solana Turbine: Penjelasan Propagasi Blok

Propagasi blok Solana Turbine menjelaskan bagaimana data blok dibagi menjadi "shreds" dan didistribusikan ke seluruh validator. Angka-angka dalam artikel ini adalah nilai historis atau target kecuali jika diberi tanggal secara eksplisit; waktu slot aktual, topologi, kehilangan paket, dan perilaku implementasi bervariasi.

Pendahuluan: Mengapa Propagasi Blok Menentukan Kecepatan Blockchain

Mengirim blok lengkap ke ribuan validator sekaligus akan mengharuskan setiap validator mengunduh seluruh blok dari satu sumber, menciptakan hambatan bandwidth yang semakin buruk seiring penskalaan jaringan. Solana (SOL), blockchain Lapisan 1 berkinerja tinggi (jaringan buku besar terdistribusi yang mencatat dan memvalidasi transaksi tanpa otoritas pusat), memecahkan masalah ini dengan Turbine, protokol propagasi blok khususnya.

Materi Solana awal menyebutkan throughput teoretis mendekati 65.000 TPS dan durasi slot target mendekati 400 milidetik. Itu adalah referensi desain daripada pengukuran langsung yang dijamin, dan slot tidak selalu menghasilkan blok. Turbine adalah mekanisme propagasi data blok yang dijelaskan dalam kerangka kerja arsitektur historis Solana.

Propagasi blok berada di bawah mekanisme konsensus: validator (server yang menyimpan salinan buku besar, memverifikasi transaksi, dan memilih validitas blok) tidak dapat memilih validitas blok sampai mereka telah menerima dan merekonstruksinya dari "shreds". Ketergantungan itu berarti kecepatan Turbine adalah enabler langsung dari kinerja konsensus Solana. Setiap interaksi kontrak pintar di Solana, mulai dari swap keuangan terdesentralisasi (DeFi) hingga mint NFT, bergantung pada blok tersebut mencapai validator cukup cepat untuk dikonfirmasi dalam slot berikutnya.

Selanjutnya akan dibahas definisi Turbine, mekanisme lima langkah, parameter teknis, kontribusi kinerja, pertukaran keamanan, dan perbandingan langsung dengan Ethereum dan Avalanche.

Dalam Artikel Ini

• Apa Itu Propagasi Blok Solana Turbine?
• Istilah Penting: Panduan Referensi Cepat Terminologi Turbine
• Cara Turbine Menyebarkan Blok: Panduan Langkah demi Langkah
• Parameter Teknis Turbine
• Turbine dan Kinerja Solana: Menghubungkan Propagasi Blok ke TPS
• Apakah Turbine Aman? Model Keamanan dan Vektor Serangan yang Diketahui
• Solana Turbine vs. Ethereum dan Blockchain Lapisan 1 Lainnya
• Turbine dalam Arsitektur Solana: Semua 8 Inovasi
• Evolusi Turbine: Dari 2017 Whitepaper hingga Hari Ini
• Pertanyaan yang Sering Diajukan Tentang Solana Turbine
• Kesimpulan: Mengapa Turbine Penting untuk Masa Depan Solana
• Bacaan Lebih Lanjut dan Sumber Primer

Apa Itu Propagasi Blok Solana Turbine?

Definisi

Solana Turbine adalah protokol propagasi blok Solana, mekanisme di mana blok yang baru diproduksi dipecah menjadi ribuan paket data berukuran tetap yang disebut "shreds" dan didistribusikan ke seluruh jaringan validator melalui struktur pohon hierarkis yang disebut "neighborhood tree". Pengkodean penghapusan Reed-Solomon memulihkan paket apa pun yang hilang dalam transit, memastikan validator dapat merekonstruksi blok lengkap bahkan dalam kondisi jaringan yang buruk.

Turbine ada karena siaran naif tidak dapat diskalakan. Jika pemimpin blok (validator yang ditunjuk untuk menghasilkan blok untuk slot tertentu) mengirim seluruh blok langsung ke setiap validator secara bersamaan, setiap validator perlu mengunduh seluruh blok secara independen. Dengan lebih dari 2.000 validator aktif di jaringan Solana, pendekatan itu akan membutuhkan bandwidth O(n) dari satu sumber, yang berarti biaya bandwidth tumbuh secara linier dengan setiap validator yang ditambahkan ke jaringan.

Turbine mencapai penskalaan bandwidth O(log n) dengan meminjam prinsip inti dari protokol BitTorrent. Protokol distribusi file peer-to-peer BitTorrent mentransfer file besar secara efisien dengan memecahnya menjadi bagian-bagian kecil dan menyebarkan bagian-bagian tersebut ke banyak node secara bersamaan alih-alih menyajikannya dari satu server. Turbine menerapkan ide yang sama untuk propagasi blok blockchain: alih-alih pemimpin blok mengirimkan blok lengkap ke setiap validator, ia memecah blok menjadi "shreds" dan merutekannya melalui pohon validator berlapis, dengan setiap lapisan meneruskan "shreds" ke hilir.

Analogi ini memiliki batasan yang perlu diperhatikan. BitTorrent beroperasi sebagai "swarm" peer-to-peer datar di mana semua peserta diperlakukan sama. Turbine menggunakan pohon hierarkis dengan penempatan berbobot saham, yang berarti validator dengan SOL yang dipertaruhkan lebih banyak ditempatkan lebih dekat ke bagian atas pohon dan menerima "shreds" lebih awal. Perbedaan itu penting untuk memahami efisiensi Turbine dan pertukaran keamanannya.

Turbine dirancang oleh Anatoly Yakovenko, salah satu pendiri Solana Labs, dan diperkenalkan dalam "whitepaper Solana asli oleh Anatoly Yakovenko (2017)" (https://solana.com/solana-whitepaper.pdf).). Protokol ini telah diproduksi secara berkelanjutan sejak peluncuran beta Mainnet Solana pada Maret 2020.

Istilah Penting: Panduan Referensi Cepat Terminologi Turbine

Sebelum meninjau cara kerja Turbine, berikut adalah istilah inti yang akan Anda temui di seluruh artikel ini.

Cara Turbine Menyebarkan Blok: Panduan Langkah demi Langkah

Turbine menyebarkan blok melalui proses lima langkah: pemimpin blok memecah blok (shred), pengodean Reed-Solomon menghasilkan paket redundansi, dan pecahan (shred) yang dihasilkan mengalir melalui pohon lingkungan berbobot-stake hingga setiap validator memegang cukup pecahan untuk merekonstruksi blok lengkap. Setiap langkah di bawah ini mencakup satu tahap dari proses tersebut secara penuh.

Langkah 1: Pemimpin Blok Memproduksi Blok

Setiap blok dimulai dengan pemimpin blok (juga disebut produsen blok), Node validator yang ditunjuk untuk slot tertentu dan dipilih sebelumnya melalui jadwal pemimpin deterministik Solana. Berdasarkan dokumentasi jadwal pemimpin Solana, jadwal tersebut diturunkan dari jam Proof of History (PoH), mekanisme pencatatan waktu kriptografi Solana. Karena jadwal pemimpin bersifat publik dan deterministik, validator mana pun dapat memverifikasi siapa pemimpin blok berikutnya sebelum slot dimulai.

Pemimpin blok mengumpulkan transaksi yang diteruskan oleh Gulf Stream (protokol penerusan transaksi Solana, yang mendorong transaksi yang belum dikonfirmasi ke calon pemimpin berikutnya sebelum blok saat ini difinalisasi) dan menyusunnya menjadi blok yang lengkap. Setelah disusun, pemimpin blok memulai proses Turbine.

Langkah 2: Blok Dipecah Menjadi Paket Data

Pemimpin blok memecah blok yang telah selesai menjadi paket data berukuran tetap yang disebut shreds, masing-masing berukuran sekitar 1,5 KB, sesuai dokumentasi teknis Solana. Fragmen data blok asli ini disebut data shreds. Sebuah blok Solana ukuran penuh dapat menghasilkan ribuan data shreds tergantung pada ukuran blok.

Bayangkan pemecahan (shredding) ini seperti membagi file besar menjadi ribuan lampiran email kecil dan merutekan masing-masing melalui jalur yang berbeda: file lengkap terpasang kembali di tujuan bahkan jika beberapa lampiran tiba terlambat. Keuntungan utamanya adalah transmisi paralel. Karena setiap validator di dalam pohon menerima dan meneruskan shreds yang berbeda secara bersamaan, jaringan tidak menunggu satu transfer sekuensial besar sebelum mulai mendistribusikan data.

Shredding pada Turbine bukanlah sharding. Sharding membagi status Blockchain atau pemrosesan transaksi di beberapa sub-jaringan paralel, dengan subset validator yang berbeda memvalidasi bagian status yang berbeda pula. Turbine memecah blok semata-mata untuk efisiensi transmisi: seluruh jaringan validator Solana memvalidasi status blok lengkap yang sama. Fragmentasi ini adalah mekanisme pengiriman, bukan strategi partisi.

Langkah 3: Pengodean Reed-Solomon Menghasilkan Redundansi Shreds

Pengodean penghapusan Reed-Solomon menghasilkan kategori shreds kedua yang disebut coding shreds, yang merupakan paket redundansi yang memungkinkan validator mana pun untuk merekonstruksi blok penuh bahkan jika sebagian dari data shreds asli hilang dalam perjalanan. Perbedaannya penting: data shreds membawa konten blok yang sebenarnya; coding shreds membawa redundansi yang diturunkan secara matematis yang dapat mengisi kekosongan.

Analogi yang berguna: pengodean penghapusan Reed-Solomon berfungsi seperti kode QR. Bahkan jika sebagian dari kode QR tertutup atau rusak, informasi redundan yang cukup tetap terenkode di bagian yang tersisa untuk mendekode pesan lengkap. Analogi kode QR memiliki satu batasan yang perlu dicatat: kode QR adalah objek statis, sementara pengodean penghapusan Turbine beroperasi pada tumpukan streaming shreds dengan ambang batas pemulihan numerik tertentu.

Menurut implementasi Solana, validator dapat merekonstruksi blok penuh selama mereka menerima kira-kira dua pertiga dari total shreds (gabungan data plus coding). Itu berarti protokol menoleransi sekitar sepertiga kehilangan paket sebelum rekonstruksi gagal. Pengodean Reed-Solomon adalah teknologi matang dengan penggunaan produksi selama beberapa dekade dalam CD, DVD, komunikasi satelit, dan aplikasi lainnya, yang mendukung klaim bahwa mekanisme toleransi kesalahan Turbine bertumpu pada teknik yang terbukti daripada desain eksperimental. Parameter teknis dikutip dari Whitepaper Solana dan dokumentasi resmi Turbine Solana.

Langkah 4: Shreds Didistribusikan Melalui Pohon Lingkungan

Pohon lingkungan (juga disebut pohon fanout) adalah struktur perutean hierarkis di mana Turbine mendistribusikan shreds, mengorganisir validator Solana ke dalam lapisan-lapisan di mana setiap lapisan menerima shreds dari lapisan di atasnya dan mentransmisikannya kembali ke hilir. Struktur di bawah ini menunjukkan bagaimana pohon tersebut menskala di dua lapisan:

Lapisan 0 (Pemimpin Blok)
        |
        +-- Lapisan 1: ~200 validator (masing-masing menerima subset unik dari shreds)
                |
                +-- Lapisan 2: hingga ~40.000 validator (200 x 200, setiap validator Lapisan 1 meneruskan ke ~200 lainnya)

Pohon lingkungan mencakup set validator aktif penuh Solana (sekitar 2.000 lebih validator per statistik jaringan Solana Foundation) dalam dua hingga tiga lapisan, mengingat faktor fanout sekitar 200 per lapisan. Dengan dua lapisan, pohon tersebut secara matematis menjangkau hingga 40.000 validator (200 x 200), yang jauh melebihi set aktif saat ini.

Bayangkan struktur ini seperti jaringan penyortiran pos: pusat utama mengirimkan tumpukan ke pusat penyortiran regional, yang mengirim ke kantor pos lokal, yang mengirim ke alamat individu. Setiap lapisan hanya menangani sebagian kecil dari total beban, dan tidak ada satu pun Node yang menanggung biaya bandwidth penuh. Namun, tidak seperti sistem pos yang netral, pohon lingkungan Turbine berbobot-stake. Validator dengan stake SOL yang lebih besar di bawah model Mekanisme Konsensus berbasis Proof of Stake Solana (Tower BFT) diposisikan lebih dekat ke puncak pohon, memastikan mereka menerima shreds lebih awal.

Topologi pohon juga diacak di setiap slot menggunakan keacakan yang dapat diverifikasi yang diturunkan dari jam PoH, yang berarti sumber keacakan yang dapat diverifikasi secara independen oleh validator mana pun tanpa memercayai pihak pusat. Karena pohon berubah setiap slot, validator musuh tidak dapat memprediksi validator mana yang akan menjadi tetangga mereka di putaran berikutnya. Pengacakan itu adalah pertahanan utama Turbine terhadap serangan eclipse, di mana penyerang mencoba mengelilingi validator target dan menahan shreds.

Hasilnya adalah penskalaan bandwidth O(log n), yang berarti persyaratan bandwidth tumbuh lambat dibandingkan dengan jumlah validator. Properti ini membuat desain Turbine semakin berharga seiring bertambahnya jumlah validator Solana.

Langkah 5: Validator Merekonstruksi Blok dan Melakukan Voting

Setelah validator menerima cukup shreds untuk memenuhi ambang batas pengodean penghapusan (sekitar dua pertiga dari total shreds untuk blok tersebut), ia merekonstruksi blok lengkap dan mengirimkan suaranya ke Tower BFT (Tower Byzantine Fault Tolerance), Mekanisme Konsensus berbasis Proof of Stake milik Solana. Validator tidak dapat memberikan suara sampai rekonstruksi selesai, itulah sebabnya kecepatan propagasi Turbine secara langsung membatasi throughput konsensus.

Proses propagasi dirancang berdasarkan irama slot target Solana, tetapi waktu aktual dan cakupan validator bervariasi tergantung pada kondisi jaringan dan implementasi. Jika propagasi selesai dalam jendela tersebut, konsensus berlanjut dan slot berikutnya dimulai. Jika tidak, slot tersebut mungkin dilewati, yang untuk sementara mengurangi throughput.

Apa yang Terjadi Saat Shreds Hilang?

Fakta Kunci

Ketika shreds hilang dalam perjalanan, pengodean penghapusan Reed-Solomon Solana memungkinkan validator untuk merekonstruksi blok lengkap dari coding shreds yang mereka terima, selama total kehilangan paket tetap di bawah kira-kira sepertiga dari semua shreds yang ditransmisikan untuk blok tersebut.

Analogi kode QR juga berlaku di sini: selama pola yang tersisa cukup, pesan lengkap akan terdekode. Ketika kehilangan paket tetap di bawah ambang batas pemulihan, validator merekonstruksi blok dari kombinasi data shreds dan coding shreds mana pun yang tiba.

Ketika kehilangan paket melebihi ambang batas tersebut, validator mengeluarkan permintaan perbaikan ke validator tetangga yang memegang shred yang hilang. Mekanisme perbaikan tersebut menambah latensi tetapi tidak segera menyebabkan lompatan slot (slot skip) kecuali perbaikan tidak dapat diselesaikan dalam jendela slot.

Di bawah kemacetan jaringan yang parah, di mana kehilangan paket tersebar luas di seluruh jaringan alih-alih terisolasi pada satu jalur, beberapa validator mungkin gagal merekonstruksi blok mereka dalam jendela slot. Kaskade tersebut berkontribusi pada lompatan slot dan, dalam kasus ekstrem, pada jenis degradasi jaringan yang dialami Solana selama peristiwa kemacetan besar pada tahun 2021 dan 2022. Solana Labs sejak itu telah menyempurnakan penanganan kemacetan Turbine sebagai tanggapan terhadap peristiwa-peristiwa tersebut. Hubungan antara kemacetan dan lompatan slot dibahas di bagian keamanan di bawah ini.

Parameter Teknis Turbine

Tabel berikut merangkum parameter operasional utama Turbine, yang diambil dari dokumentasi resmi Solana dan Whitepaper Solana. Parameter dapat diperbarui oleh Solana Labs seiring berkembangnya protokol; verifikasi nilai saat ini di dokumentasi resmi Turbine Solana.

Turbine dan Performa Solana: Menghubungkan Propagasi Blok ke TPS

Whitepaper Solana dan komentar selanjutnya telah mengutip throughput teoritis mendekati 65.000 TPS. Throughput yang diamati tergantung pada tanggal, beban kerja, penyertaan suara, penyaringan, dan versi perangkat lunak, sehingga rentang TPS non-vote langsung tidak boleh disajikan tanpa metodologi pengukurannya. Turbine adalah salah satu komponen dari hasilnya, bukan jaminan TPS yang independen.

Rantai kausalnya bekerja sebagai berikut. Turbine mempropagasikan shred dengan cukup cepat sehingga validator di seluruh jaringan merekonstruksi blok dan memberikan suara dalam jendela slot sekitar 400ms. Konsensus berlanjut. Slot berikutnya dimulai. Solana mempertahankan irama slotnya. Karena setiap slot dapat berisi ribuan transaksi, mempertahankan irama itulah yang menghasilkan TPS tinggi. Ganggu irama tersebut dengan penundaan propagasi dan TPS turun; pertahankan dan TPS tetap tinggi.

Pembedaan antara TPS teoritis dan yang diamati layak mendapatkan perhatian eksplisit. Angka TPS mentah Solana (yang dapat mencapai angka lebih tinggi) mencakup transaksi suara validator, yang merupakan pesan konsensus internal yang tidak mewakili transaksi yang diajukan pengguna. TPS non-vote, angka yang lebih sebanding dengan throughput pada blockchain lain, biasanya berjalan pada 2.000 hingga 4.000 di bawah beban dunia nyata pada 2024-2025, menurut dokumentasi performa Solana Labs. Angka 65.000 adalah batas teoritis dengan asumsi kondisi ideal; itu bukan deskripsi perilaku jaringan rata-rata.

Desain bandwidth O(log n) Turbine juga mencegah lapisan propagasi menjadi penghambat saat jumlah validator bertambah. Dengan pendekatan broadcast naif, menggandakan jumlah validator menggandakan bandwidth yang dibutuhkan dari setiap node pengirim. Dengan struktur pohon Turbine, menggandakan jumlah validator hanya menambah satu lapisan tambahan (sekitar 200 validator lebih banyak per node yang ada), yang berarti persyaratan bandwidth tumbuh perlahan alih-alih secara linier.

Poin Penting

Turbine tidak mengeksekusi transaksi; ia mempropagasikan data blok. Performa propagasi dapat memengaruhi voting dan throughput, tetapi Turbine tidak menjamin angka TPS tetap, irama slot, atau waktu finalitas.

Apakah Turbine Aman? Model Keamanan dan Vektor Serangan yang Diketahui

Turbine menggabungkan tiga mekanisme keamanan inti: perutean acak yang mengacak ulang setiap slot, penempatan pohon tertimbang Staking, dan redundansi Reed-Solomon. Setiap mekanisme menangani permukaan serangan tertentu, meskipun masing-masing juga memperkenalkan pertukaran yang layak untuk pemeriksaan jujur.

Bagaimana Perutean Acak Melindungi Terhadap Validator Merugikan

Pohon lingkungan diacak ulang setiap slot menggunakan keacakan yang dapat diverifikasi yang diturunkan dari jam Proof of History, yang berarti validator yang merugikan tidak dapat memprediksi validator mana yang akan menjadi tetangga mereka di slot berikutnya. Hal ini penting karena vektor serangan utama terhadap pohon distribusi berlapis adalah serangan gerhana (eclipse attack): aktor jahat menempatkan validator di sekitar validator target dan menahan shred, mencegah validator tersebut merekonstruksi blok dan oleh karena itu menghalanginya untuk memberikan suara.

Karena topologi pohon berubah setiap slot, penyerang tidak dapat mempertahankan pengepungan itu secara andal. Pemimpin blok diketahui sebelumnya (melalui jadwal pemimpin deterministik), tetapi jalur propagasinya tidak. Asimetri tersebut adalah desain keamanan yang disengaja: transparansi tentang siapa yang menghasilkan blok, dikombinasikan dengan opacity tentang bagaimana blok tersebut berpindah.

Perlindungan ini memiliki batas. Penyerang dengan stake yang cukup berpotensi muncul di beberapa posisi di seluruh pengacakan berturut-turut, mempertahankan keberadaan statistik di dekat validator target. Perutean acak meningkatkan biaya dan kompleksitas serangan gerhana tanpa membuatnya mustahil terhadap musuh yang memiliki sumber daya mumpuni.

Penimbangan-Stake dan Kekhawatiran Sentralisasi

Penimbangan-Stake menempatkan validator dengan stake lebih tinggi lebih dekat ke puncak pohon lingkungan, yang berarti mereka menerima shred lebih awal daripada validator dengan stake lebih rendah, yang menciptakan keunggulan struktural untuk operasi Staking besar. Validator yang menerima shred terlebih dahulu dapat memulai rekonstruksi dan voting sebelum rekan-rekan mereka yang memiliki stake lebih rendah, yang diterjemahkan menjadi keunggulan waktu ringan dalam proses konsensus.

Kritik jujurnya: validator dengan konsentrasi stake yang cukup besar secara teoritis dapat menggunakan akses awal tersebut untuk mencoba strategi penahanan blok, menunda suara mereka untuk mendapatkan keunggulan informasi. Aturan finalitas konsensus Tower BFT dirancang untuk membatasi viabilitas strategi semacam itu, dan konsentrasi stake didistribusikan ke sekitar 2.000 lebih validator aktif (menurut statistik jaringan Solana Foundation), yang membatasi konsentrasi ekstrem. Solana Foundation juga menjalankan program delegasi stake yang dirancang untuk mendistribusikan stake secara lebih luas di seluruh validator yang lebih kecil. Namun, keunggulan struktural bagi validator besar itu nyata dan patut diperhitungkan dalam penilaian profil desentralisasi Solana.

Turbine, Kemacetan Jaringan, dan Pemadaman Historis

Sebagian besar pemadaman jaringan besar Solana antara tahun 2021 dan 2022 disebabkan oleh kemacetan pipa pemrosesan transaksi alih-alih kegagalan spesifik Turbine, meskipun kemacetan ekstrem dapat menekan lapisan propagasi blok. Ketika volume transaksi membanjiri pipa pemrosesan Solana selama periode tersebut, volume blok yang dihasilkan dan di-shred juga meningkat, dan lapisan propagasi menghadapi lebih banyak batch shred secara simultan daripada yang dapat diserap oleh bandwidth jaringan dengan bersih.

Hasilnya adalah kehilangan paket yang meluas yang melebihi ambang pemulihan pengkodean penghapusan di banyak validator secara bersamaan, berkontribusi pada gelombang lompatan slot daripada kegagalan individu yang terisolasi. Solana Labs sejak itu telah melakukan perbaikan rekayasa pada penanganan kemacetan, termasuk perubahan pada cara jaringan mengelola penyerapan transaksi dan bagaimana Turbine menangani propagasi di bawah beban tinggi. Untuk status rekayasa saat ini, lihat blog rekayasa Solana Labs. Sejarah pemadaman adalah fakta dari catatan produksi Turbine, bukan risiko teoretis, dan itu adalah konteks yang relevan bagi siapa pun yang mengevaluasi ketahanan teknis Solana.

Solana Turbine vs. Ethereum dan Blockchain Lapisan-1 Lainnya

Solana menyebarkan blok lebih cepat daripada Ethereum terutama karena Turbine menggunakan pohon lingkungan bertingkat untuk mendistribusikan serpihan secara paralel, sementara Ethereum menggunakan protokol gosip di mana validator menyiarkan blok ke subset acak dari rekan-rekan yang menyiarkan kembali ke rekan-rekan mereka, sebuah topologi yang secara fundamental lebih lambat dalam skala besar. Tabel di bawah membandingkan Solana, Ethereum, dan Avalanche di seluruh dimensi yang paling penting untuk propagasi blok.

Satu perbedaan yang perlu diperjelas: Solana sendiri menggunakan protokol gosip untuk berbagi informasi klaster dan metadata protokol, tetapi Turbine menggantikan gosip untuk tugas spesifik propagasi blok. Pohon bertingkat Turbine-lah yang mengungguli topologi datar gosip untuk distribusi blok dalam skala besar.

Protokol gosip Ethereum (di mana validator menyiarkan blok ke subset acak dari rekan-rekan, yang menyiarkan kembali ke rekan-rekan mereka, menyebarkan blok melalui jaringan selama beberapa putaran) lebih mudah diimplementasikan dan menghasilkan pemilihan rekan yang lebih seragam yang tidak menguntungkan validator mana pun berdasarkan saham. Desain itu mencerminkan prioritas Ethereum terhadap desentralisasi luas dan partisipasi tanpa izin. Perbandingannya adalah kecepatan propagasi: beberapa putaran gosip di seluruh kumpulan validator yang besar menghasilkan waktu blok yang diukur dalam detik daripada milidetik.

Turbine berbeda dari protokol BitTorrent dalam dua cara yang tidak sepenuhnya ditangkap oleh tabel di atas. BitTorrent menggunakan kawanan peer-to-peer datar di mana semua peserta setara; Turbine menggunakan pohon bertingkat dengan posisi hub yang tertimbang saham. BitTorrent tidak memiliki batasan waktu pada perakitan file; Turbine harus mengirimkan dalam jendela slot 400ms atau kehilangan konsensus. Perbedaan tersebut adalah respons desain terhadap persyaratan khusus blockchain yang tidak dihadapi oleh model BitTorrent.

Propagasi DAG Snowflake/Snowball Avalanche mengambil pendekatan yang berbeda: polling acak berulang dari subset validator kecil untuk mencapai konsensus probabilistik tanpa model pemimpin blok tunggal. Desain tersebut memberikan penskalaan bandwidth sub-linear melalui pengambilan sampel daripada melalui pohon, dan ia menghasilkan finalitas yang lebih cepat daripada Ethereum sambil tetap berbeda secara fundamental dari pendekatan berbasis serpihan Turbine. Setiap desain membuat perbedaan trade-off antara kecepatan dan desentralisasi di satu sisi, dan toleransi kesalahan dan kompleksitas di sisi lain. Tabel menyajikan trade-off tersebut; menyatakan satu arsitektur lebih unggul akan salah merepresentasikan ruang desain.

Turbine dalam Arsitektur Solana: Semua 8 Inovasi

Turbine adalah salah satu dari delapan inovasi arsitektural yang diperkenalkan oleh Anatoly Yakovenko dalam whitepaper Solana tahun 2017, yang masing-masing dirancang untuk mengatasi hambatan kinerja yang berbeda dalam infrastruktur blockchain. Daftar lengkapnya:

• Proof of History (PoH): Mekanisme pencatatan waktu kriptografis Solana, fungsi penundaan yang dapat diverifikasi yang menciptakan catatan historis urutan peristiwa tanpa mengharuskan validator untuk berkomunikasi untuk menyetujui waktu. PoH bukanlah mekanisme konsensus; itu adalah jam. Ini mendefinisikan struktur slot di mana Turbine beroperasi.
• Tower BFT: Mekanisme konsensus berbasis Bukti Stake Solana, varian dari Practical Byzantine Fault Tolerance (PBFT) yang menggunakan jam PoH untuk mengurangi overhead pesan dalam mencapai finalitas.
• Turbine: Propagasi blok, subjek artikel ini. Turbine mendistribusikan blok yang baru diproduksi ke semua validator melalui serpihan dan pohon lingkungan.
• Gulf Stream: Protokol penerusan transaksi Solana. Gulf Stream mendorong transaksi yang belum dikonfirmasi ke pemimpin blok berikutnya yang diantisipasi sebelum blok saat ini selesai, mengurangi waktu yang dibutuhkan pemimpin untuk merakit blok.
• Sealevel: Mesin eksekusi kontrak pintar paralel Solana, yang memproses ribuan kontrak pintar yang tidak tumpang tindih secara bersamaan alih-alih secara berurutan.
• Pipelining: Pipeline pemrosesan transaksi yang menetapkan tahap validasi transaksi yang berbeda ke perangkat keras khusus, memungkinkan beberapa blok divalidasi secara bersamaan pada tahap pemrosesan yang berbeda.
• Cloudbreak: Basis data akun yang diskalakan secara horizontal di Solana, dioptimalkan untuk pembacaan dan penulisan bersamaan di seluruh perangkat keras penyimpanan validator.
• Archivers: Node penyimpanan buku besar terdistribusi yang mengurangi beban data blockchain historis dari validator ke lapisan penyimpanan terpisah, mengurangi persyaratan perangkat keras validator.

Gulf Stream dan Turbine beroperasi secara berurutan di seluruh siklus hidup transaksi. Gulf Stream merutekan transaksi yang belum dikonfirmasi ke pemimpin blok yang diantisipasi sebelum produksi blok dimulai; Turbine kemudian mendistribusikan blok yang dihasilkan ke semua validator setelah produksi selesai. Bersama-sama, kedua protokol ini menangani siklus hidup transaksi penuh dari pengiriman ke distribusi di seluruh jaringan.

Delapan inovasi ini diperkenalkan oleh Anatoly Yakovenko, salah satu pendiri Solana Labs, dalam whitepaper Solana asli yang diterbitkan pada tahun 2017.

Perspektif Validator

Posisi pohon lingkungan Turbine memengaruhi persyaratan perangkat keras validator. Validator yang diposisikan di Lapisan 1 (lebih dekat ke pemimpin blok) menerima serpihan terlebih dahulu dan harus meneruskannya ke sekitar 200 validator Lapisan 2, membutuhkan bandwidth unggah yang lebih tinggi daripada validator Lapisan 2 yang hanya meneruskan ke sub-lingkungan yang ditugaskan. Tingkat Stake menentukan posisi pohon: validator dengan saham lebih tinggi menempati posisi Lapisan 1 dan harus melakukan provisi sesuai. Operator harus berkonsultasi dengan rekomendasi perangkat keras saat ini dari Solana Labs, karena spesifikasi minimum telah berkembang sejak peluncuran mainnet.

Evolusi Turbine: Dari Whitepaper 2017 hingga Hari Ini

Turbine pertama kali ditentukan dalam whitepaper Solana asli yang ditulis oleh Anatoly Yakovenko dari Solana Labs pada tahun 2017, menjadikannya salah satu keputusan arsitektur pendiri protokol daripada fitur yang ditambahkan kemudian. Spesifikasi 2017 menetapkan desain inti: fragmentasi blok berbasis serpihan, pohon fanout untuk distribusi, dan pengkodean penghapusan Reed-Solomon untuk toleransi kesalahan.

Beta mainnet Solana diluncurkan pada Maret 2020, yang menerapkan Turbine ke dalam produksi untuk pertama kalinya. Penerapan awal mengonfirmasi properti inti desain tersebut tetapi juga menyingkap kondisi dunia nyata yang tidak sepenuhnya diantisipasi oleh spesifikasi teoretis, khususnya interaksi antara kemacetan transaksi dan beban propagasi.

Menyusul peristiwa stres jaringan tahun 2021 dan 2022, Solana Labs melakukan penyempurnaan teknik pada penanganan kemacetan Turbine, termasuk penyesuaian pada cara antrean dan transmisi batch shred dalam kondisi beban jaringan tinggi. Penyempurnaan ini tidak mengubah arsitektur fundamental protokol tetapi meningkatkan perilakunya pada batas ekstrem dari amplop operasional.

Turbine kini telah beroperasi dalam produksi berkelanjutan selama lebih dari empat tahun di jaringan yang memproses jutaan transaksi setiap hari. Rekam jejak produksi tersebut mendukung jawaban yang jelas terhadap pertanyaan apakah Turbine merupakan pendekatan yang terbukti atau eksperimental: ini adalah protokol produksi yang telah teruji dalam skala besar, dengan silsilah teknik terdokumentasi yang dapat ditelusuri ke spesifikasi tahun 2017. Untuk parameter protokol saat ini dan perubahan teknik terkini, lihat blog teknik Solana Labs.

Pertanyaan Umum Tentang Propagasi Blok Solana Turbine

Pertanyaan-pertanyaan berikut membahas kueri yang paling umum tentang desain dan kinerja Solana Turbine.

Apa itu Solana Turbine?

Turbine adalah protokol yang digunakan Solana untuk mengirimkan blok yang baru diproduksi ke setiap validator di jaringan dalam jendela slot 400ms. Protokol ini bekerja dengan memecah blok menjadi shred dan merutekannya melalui pohon lingkungan hierarkis, dengan pengodean penghapusan Reed-Solomon yang menangani setiap paket yang hilang saat transit. Hasilnya adalah distribusi blok yang cepat dan hemat bandwidth yang berskala seiring bertambahnya set validator.

Apa itu shred di Solana?

Shred adalah paket data fundamental yang digunakan oleh Turbine untuk transmisi blok, dengan ukuran sekitar 1,5 KB. Ada dua jenis: shred data, yang membawa konten blok asli, dan shred pengodean, yang merupakan paket redundansi yang dihasilkan oleh pengodean penghapusan Reed-Solomon yang memungkinkan rekonstruksi blok bahkan ketika beberapa shred data hilang saat transit.

Leader blok membagi blok menjadi shred data dan menghasilkan shred pengodean melalui pengodean Reed-Solomon. Shred tersebut mengalir melalui pohon lingkungan: leader blok mengirimkannya ke sekitar 200 validator Lapisan 1, yang masing-masing meneruskannya ke sekitar 200 validator Lapisan 2, mencakup seluruh set validator aktif dalam dua hingga tiga lapisan dan selesai dalam jendela slot sekitar 400ms.

Solana menggunakan pohon lingkungan hierarkis Turbine, yang mendistribusikan shred secara paralel di banyak validator secara bersamaan, mencapai penskalaan bandwidth O(log n). Ethereum menggunakan protokol gosip yang membutuhkan beberapa putaran berurutan dari penyiaran ulang rekan acak untuk mencapai cakupan jaringan penuh, menghasilkan waktu blok sekitar 12 detik dibandingkan dengan waktu slot Solana yang sekitar 400ms. Kedua desain tersebut mencerminkan prioritas arsitektur yang disengaja.

Turbine menyertakan perutean acak (pohon lingkungan mengacak ulang setiap slot menggunakan keacakan yang dapat diverifikasi), redundansi Reed-Solomon (mentoleransi kehilangan paket sekitar sepertiga), dan penentuan posisi tertimbang stake. Perutean acak membuat serangan eclipse jauh lebih sulit dilakukan. Penimbangan stake memperkenalkan pertukaran sentralisasi ringan: validator dengan stake lebih tinggi menerima shred lebih awal, menciptakan keuntungan struktural yang sebagian diimbangi oleh aturan konsensus Tower BFT.

Ketika kehilangan paket tetap di bawah sekitar sepertiga dari total shred, pengodean penghapusan Reed-Solomon memungkinkan validator untuk merekonstruksi blok lengkap dari shred data dan shred pengodean yang tersisa. Di atas ambang batas tersebut, validator mengirimkan permintaan perbaikan ke validator tetangga yang memegang shred yang hilang. Jika perbaikan tidak dapat selesai dalam jendela slot, slot tersebut mungkin dilewati.

Penimbangan stake Turbine memang menciptakan keuntungan struktural bagi validator dengan stake tinggi, yang menerima shred lebih awal dan menempati posisi yang lebih tinggi di pohon lingkungan. Ini adalah sebuah pertukaran (trade-off) yang nyata. Faktor mitigasi mencakup distribusi Solana di 2.000 lebih validator aktif, aturan konsensus Tower BFT yang membatasi nilai akses shred dini, dan program delegasi stake Solana Foundation yang bertujuan untuk memperluas distribusi stake.

Turbine dirancang oleh Anatoly Yakovenko, salah satu pendiri Solana Labs, dan pertama kali dispesifikasikan dalam Whitepaper Solana yang diterbitkan pada tahun 2017. Solana Labs (organisasi teknik, berbeda dari Solana Foundation yang menangani tata kelola ekosistem) memelihara dan terus mengembangkan protokol tersebut.

Gulf Stream dan Turbine adalah protokol berurutan dalam siklus hidup transaksi Solana. Gulf Stream merutekan transaksi yang belum dikonfirmasi ke depan ke leader blok yang diantisipasi sebelum produksi blok dimulai, sehingga leader dapat mulai menyusun blok tanpa menunggu transaksi tiba. Turbine kemudian mendistribusikan blok yang sudah jadi keluar ke semua validator setelah produksi selesai.

Maksimum teoretis Solana adalah sekitar 65.000 TPS, menurut Whitepaper Solana, dalam kondisi ideal. Dalam kondisi dunia nyata, TPS non-vote yang diamati biasanya berkisar antara 2.000 hingga 4.000 transaksi per detik per 2024-2025, menurut dokumentasi kinerja Solana Labs. Angka TPS mentah yang terkadang dikutip pada angka yang lebih tinggi mencakup transaksi vote validator, yang merupakan pesan konsensus internal alih-alih transaksi pengguna.

Panduan Solana Terkait

• Node RPC Solana
• Slot dan waktu blok Solana

Jelajahi SOL di Bybit

Pembaca dapat meninjau informasi pasar SOL saat ini atau pasar Spot SOL/USDT. Tautan ini memberikan informasi dan akses pasar; tautan tersebut tidak memvalidasi klaim teknis atau menyiratkan bahwa SOL cocok untuk setiap pembaca.

Turbine adalah mekanisme teknik yang membuat waktu slot sekitar 400ms Solana dapat dicapai: tanpa propagasi blok yang cepat dan hemat bandwidth, validator Solana tidak dapat menerima dan memberikan suara pada blok dengan cukup cepat untuk mempertahankan ritme slot yang dibutuhkan oleh throughput tinggi. Desain ini menyelesaikan kendala skalabilitas yang nyata, masalah bandwidth O(n) dari siaran naif, melalui kombinasi fragmentasi berbasis shred, distribusi pohon hierarkis, dan toleransi kesalahan Reed-Solomon.

Desain ini membawa pertukaran (trade-off) yang layak dipahami. Penentuan posisi pohon tertimbang stake memberikan keuntungan struktural bagi validator besar. Perutean acak memitigasi serangan eclipse tetapi tidak menghilangkannya dari musuh dengan sumber daya yang memadai. Lapisan propagasi dapat tertekan di bawah kemacetan jaringan yang ekstrem, seperti yang ditunjukkan oleh rekam jejak pemadaman Solana tahun 2021-2022. Tidak ada satu pun dari hal ini yang bersifat menggugurkan; semuanya adalah pertukaran arsitektur yang dilakukan sebagai imbalan atas kecepatan dan efisiensi bandwidth yang disediakan oleh protokol.

Turbine telah beroperasi dalam produksi sejak 2020 dan telah disempurnakan sebagai respons terhadap kondisi dunia nyata. Seiring bertambahnya jumlah validator Solana, properti penskalaan O(log n) menjadi semakin penting: setiap penggandaan set validator hanya menambah satu lapisan pohon, bukan menggandakan biaya bandwidth. Properti itulah yang membuat desain ini tahan lama dalam skala besar. Kecepatan dan keandalan propagasi blok Turbine juga merupakan hal yang membuat Solana menjadi lapisan infrastruktur yang layak untuk aplikasi keuangan terdesentralisasi (DeFi) frekuensi tinggi, di mana latensi propagasi secara langsung memengaruhi hasil konfirmasi transaksi.

Poin Penting

Turbine adalah fondasi teknis yang membuat klaim kecepatan Solana kredibel. Memahami bagaimana ia memecah blok menjadi shred, merutekannya melalui pohon lingkungan berbobot Stake, dan memulihkan paket yang hilang melalui pengkodean penghapusan Reed-Solomon adalah cara paling jelas untuk mengevaluasi apakah klaim performa tersebut berdasar pada arsitektur yang kuat. Desain ini memiliki keunggulan nyata dan pengorbanan (trade-off) nyata; keduanya layak dipertimbangkan dalam penilaian teknis yang jujur terhadap infrastruktur Solana.

Bacaan Lebih Lanjut dan Sumber Utama

Sumber-sumber utama berikut memberikan dasar teknis untuk klaim yang dibuat dalam artikel ini.

• Propagasi Blok Turbine (Solana Docs): Dokumentasi teknis resmi untuk Turbine, dikelola oleh tim teknis Solana Labs.
• Whitepaper asli Solana oleh Anatoly Yakovenko (2017): Spesifikasi awal untuk Turbine dan delapan inovasi arsitektur Solana lainnya.
• Blog teknis Solana Labs: Pembaruan teknis terbaru, peningkatan protokol, dan post-mortem dari Solana Labs.
• Solana GitHub: kode sumber turbine:): Kode sumber bagi pengembang yang ingin memeriksa implementasi Turbine secara langsung.
• Statistik jaringan Solana Foundation: Jumlah validator saat ini, data distribusi Stake, dan metrik kesehatan jaringan.

Artikel ini hanya untuk tujuan edukasi dan bukan merupakan nasihat keuangan atau investasi. Investasi Mata Uang Kripto mengandung risiko yang signifikan. Selalu lakukan riset Anda sendiri sebelum membuat keputusan investasi apa pun.