Sejarah Lengkap Gangguan Solana: Penyebab, Perbaikan, dan Pelajaran yang Dipetik

Pendahuluan

Seperti semua sistem terdistribusi, Solana beroperasi dengan kenyataan bahwa satu kelemahan implementasi atau edge case yang tidak jelas dapat menyebabkan kegagalan di seluruh jaringan. Gangguan, meski menghambat operasi, merupakan bagian yang tidak terhindarkan dalam pemeliharaan infrastruktur terdistribusi yang kompleks—baik pada blockchain terdesentralisasi, bursa tersentralisasi, maupun penyedia layanan cloud besar seperti Amazon atau Microsoft.

Pertanyaannya bukan apakah kegagalan akan terjadi, melainkan kapan—dan bagaimana jaringan berkembang untuk beradaptasi serta memperkuat diri terhadap insiden mendatang. Terlepas dari pengujian simulasi yang ketat, testnet berinsentif, dan program bug bounty yang aktif, tidak ada sistem—sebaik apa pun rancangannya—yang dapat mengantisipasi setiap kemungkinan mode kegagalan. Pelajaran paling berharga berasal dari operasi di dunia nyata.

Selama lima tahun terakhir, Solana telah mengalami tujuh insiden gangguan terpisah, lima di antaranya disebabkan oleh bug klien dan dua lainnya oleh ketidakmampuan jaringan menangani banjir spam transaksi. Versi awal Solana belum memiliki mekanisme utama untuk mengelola kemacetan, seperti biaya prioritas dan pasar biaya lokal, yang kemudian terbukti sangat penting untuk mengurangi tekanan jaringan. Ketiadaan mekanisme tersebut menyebabkan penurunan performa dan kemacetan berkepanjangan sepanjang 2022 karena jaringan pada dasarnya memberikan insentif terhadap spam.

Artikel ini akan menganalisis setiap gangguan Solana secara mendetail, termasuk akar penyebab, peristiwa pemicu, dan langkah-langkah yang diambil untuk mengatasinya. Selain itu, kami akan membahas aspek-aspek utama restart jaringan, pelaporan bug, serta konsep dasar kegagalan liveness dan safety. Meskipun sebaiknya dibaca secara berurutan, setiap bagian dirancang agar dapat berdiri sendiri sehingga pembaca dapat langsung menuju topik atau insiden gangguan yang paling mereka minati.

Liveness dan Safety

Menurut teorema CAP, yang juga dikenal sebagai Teorema Brewer, sistem terdistribusi hanya dapat mencapai dua dari tiga properti berikut:

• Konsistensi - Setiap pembacaan melihat seluruh penulisan sebelumnya.
• Ketersediaan - Setiap permintaan menerima respons.
• Toleransi partisi - Sistem terus beroperasi meskipun terjadi partisi jaringan.

Bagi blockchain, toleransi partisi sangat penting—gangguan jaringan tidak dapat dihindari. Hal ini memaksa pilihan antara AP (Ketersediaan + Toleransi Partisi) dan CP (Konsistensi + Toleransi Partisi). Seperti kebanyakan chain PoS dengan finalitas cepat, Solana memprioritaskan konsistensi daripada ketersediaan sehingga menjadikannya sistem CP. Solana berhenti saat terjadi kegagalan kritis alih-alih menyajikan data lama atau mengizinkan penulisan yang tidak aman. Meski ini berarti perangkat lunak node dapat memasuki kondisi yang tidak dapat dipulihkan dan memerlukan intervensi manual, langkah tersebut memastikan dana pengguna tetap aman.

Kegagalan Liveness: terjadi ketika blockchain berhenti berkembang sehingga transaksi tidak dapat dikonfirmasi dan blok tidak dapat diproduksi akibat validator tidak aktif, partisi jaringan, atau konsensus yang terhenti. Dalam konteks teorema CAP, kondisi ini berarti hilangnya ketersediaan.

Kegagalan Safety: terjadi ketika status final blockchain diubah atau mengalami fork secara tidak semestinya. Hal ini dapat menyebabkan riwayat yang bertentangan atau pengeluaran ganda, dan sering kali disebabkan oleh bug konsensus atau serangan berbahaya. Dalam konteks teorema CAP, kondisi ini berarti hilangnya konsistensi. 

Solana memprioritaskan safety daripada liveness. Karena itu, jaringan akan berhenti saat mengalami tekanan jaringan ekstrem atau kegagalan konsensus, bukan mengambil risiko kerusakan status. Meskipun gangguan menghambat operasi dan dapat memengaruhi aplikasi, pengguna, serta validator, dampaknya tetap lebih baik daripada konsekuensi fatal akibat ledger yang tidak konsisten atau rusak.

Restart Jaringan

Restart jaringan Solana melibatkan identifikasi slot blok terakhir yang dikonfirmasi secara optimistis dan reboot node dari snapshot status lokal tepercaya pada slot tersebut. Karena slot restart tidak ditentukan secara on-chain, operator validator harus mencapai konsensus off-chain untuk menyepakati titik rollback yang aman. Koordinasi ini berlangsung secara terbuka di saluran #mb-validators pada Discord Solana Tech, tempat operator validator profesional berkomunikasi secara real-time. Sebagian besar operator memiliki sistem peringatan otomatis yang langsung memberi tahu mereka saat produksi blok berhenti sehingga respons dapat dilakukan dengan cepat.

Setelah konsensus tentang slot restart yang tepat tercapai, operator menggunakan alat ledger untuk membuat snapshot lokal baru, melakukan reboot pada validator mereka, dan menunggu setidaknya 80% dari total stake kembali online. Setelah itu, jaringan baru melanjutkan produksi dan validasi blok. Memastikan bahwa maksimal hanya 20% stake yang offline saat cluster dimulai ulang memberikan margin keamanan yang memadai agar jaringan tetap online jika node mengalami fork atau kembali offline segera setelah restart.

Pelaporan Bug

Program bug bounty memberikan imbalan kepada peneliti keamanan yang mengidentifikasi dan melaporkan kerentanan perangkat lunak. Ini adalah lapisan pertahanan penting karena secara proaktif memberikan insentif untuk menemukan bug sebelum dapat dieksploitasi. Peneliti keamanan dan developer yang menemukan potensi kerentanan pada klien Agave dianjurkan untuk melaporkannya melalui saluran keamanan yang tepat. Panduan pengungkapan mendetail tersedia di repositori GitHub Agave. 

Imbalan ditawarkan untuk laporan kerentanan kritis yang valid, dengan pembayaran berdasarkan tingkat keparahan:

• Kehilangan Dana: Hingga 25.000 SOL
• Pelanggaran Konsensus atau Safety: Hingga 12.500 SOL
• Liveness atau Hilangnya Ketersediaan: Hingga 5.000 SOL

Selain itu, klien FireDancer memiliki program bug bounty terpisah yang diselenggarakan melalui Immunefi, dengan imbalan maksimum sebesar $500.000 USDC untuk temuan kritis.

Insiden Gangguan

Bagian-bagian berikut menyajikan analisis kronologis yang mendetail tentang gangguan dan periode penurunan performa Solana, dimulai sejak peluncuran Mainnet Beta pada 16 Maret 2020. Pembahasan ini akan menyoroti insiden utama, akar penyebabnya, dan peningkatan jaringan yang dilakukan setelahnya, sekaligus memberikan wawasan tentang evolusi Solana dalam meningkatkan stabilitas dan ketahanannya dari waktu ke waktu.

Bug Turbine: Desember 2020

Waktu henti: Sekitar enam jam

Masalah utama: Bug propagasi blok

Perbaikan: 

• Melacak blok berdasarkan hash, bukan nomor slot
• Memperbaiki bagian di Turbine agar kesalahan dapat dideteksi lebih awal
• Menyebarkan kesalahan yang pertama kali terdeteksi ke semua validator melalui gossip

Gangguan ini disebabkan oleh masalah perbaikan blok dan pemrosesan kode yang telah diketahui sebelumnya, yang dipicu oleh bug yang belum teridentifikasi pada Turbine, mekanisme propagasi blok Solana. Kegagalan terjadi ketika sebuah validator mengirimkan dua blok berbeda untuk slot yang sama dan menyebarkannya ke dua partisi terpisah (A dan B), sementara partisi ketiga secara independen mendeteksi inkonsistensi tersebut.

Karena setiap partisi hanya memiliki stake minoritas, tidak satu pun dapat mencapai konsensus supermayoritas untuk melanjutkan chain. Masalah dasarnya berasal dari cara struktur data internal Solana melacak blok dan status yang dihitungnya. Sistem menggunakan nomor slot Proof of History (PoH), yaitu pengidentifikasi u64, untuk merujuk status dan blok pada slot tersebut. Setelah jaringan terpecah menjadi beberapa partisi, node keliru menganggap blok A dan B sebagai blok yang sama sehingga menghalangi perbaikan dan sinkronisasi blok yang semestinya.

Setiap partisi menganggap partisi lainnya memiliki blok yang sama, sehingga menimbulkan konflik mendasar:

• Node yang memiliki blok A menolak fork yang berasal dari blok B
• Node yang memiliki blok B menolak fork yang berasal dari blok A

Karena transisi status berbeda di antara partisi, validator tidak dapat memperbaiki atau menyelaraskan fork sehingga finalitas tidak dapat tercapai.

Solusi untuk masalah ini adalah memungkinkan layanan melacak blok berdasarkan hash, bukan nomor slot. Jika sejumlah blok untuk slot yang sama menciptakan partisi, blok tersebut diperlakukan sama seperti partisi dengan blok yang menempati slot berbeda. Node akan dapat memperbaiki semua kemungkinan fork, dan konsensus akan dapat menyelesaikan partisi tersebut.

Meskipun bug menjadi penyebab awal gangguan, sebagian besar waktu henti terjadi karena menunggu bobot stake yang memadai kembali online, sebab Solana memerlukan partisipasi stake minimal 80% untuk melanjutkan produksi blok.

IDO Grape Protocol: September 2021

Waktu henti: Tujuh belas jam 

Masalah utama: Luapan memori akibat transaksi bot

Perbaikan: 

• Mengabaikan write lock pada program
• Pembatasan laju penerusan transaksi
• Perilaku percobaan ulang RPC yang dapat dikonfigurasi
• Prioritas transaksi vote TPU

Pada 14 September 2021, Solana mengalami kemacetan jaringan besar setelah Grape Protocol meluncurkan initial DEX offering (IDO) on-chain di platform urun dana Raydium AcceleRaytor. Dalam waktu 12 menit sejak IDO dimulai, jaringan kewalahan menghadapi banjir transaksi berbasis bot yang belum pernah terjadi sebelumnya dan berhenti memproduksi rooted slot. Bot tersebut secara efektif melancarkan serangan distributed denial-of-service (DDoS), mendorong beban transaksi melampaui kapasitas jaringan.

Pada puncak kemacetan:

• Beberapa validator menerima lebih dari 300.000 transaksi per detik.
• Data transaksi mentah melampaui 1 Gbps, dengan 120.000 paket per detik.
• Lalu lintas terkadang melampaui batas fisik antarmuka jaringan, menyebabkan kehilangan paket di port switch bahkan sebelum mencapai validator.

Salah satu bot menyusun transaksinya untuk menerapkan write lock pada 18 account utama, termasuk program token SPL global dan program Serum DEX yang kini sudah tidak aktif. Tindakan ini memblokir semua transaksi yang berinteraksi dengan account tersebut dan secara drastis mengurangi kemampuan pemrosesan paralel Solana. Alih-alih mengeksekusi transaksi secara independen, jaringan mengalami bottleneck dan memproses transaksi secara berurutan—sehingga memperburuk kemacetan.

Perbaikan yang mengabaikan write lock pada program sebenarnya telah dikembangkan dan dijadwalkan untuk dirilis. Kemudian, reboot jaringan mengaktifkan peningkatan ini dan menghapus vektor serangan tersebut secara permanen.

Selama acara IDO, validator menerima banjir transaksi berbasis bot dan kemudian meneruskan kelebihan transaksi kepada leader berikutnya sehingga memperparah kemacetan. Reboot jaringan memperkenalkan pembatasan laju penerusan transaksi agar badai transaksi di masa depan tidak membuat leader kewalahan.

Node RPC Solana secara otomatis mencoba kembali transaksi yang gagal, fitur yang dirancang untuk meningkatkan keandalan. Namun, mekanisme percobaan ulang ini memperburuk banjir transaksi saat terjadi kemacetan ekstrem karena transaksi lama terus beredar dan menghalangi pemulihan jaringan. Solana 1.8 memperkenalkan perilaku percobaan ulang RPC yang dapat dikonfigurasi, sehingga aplikasi dapat mengoptimalkan percobaan ulang dengan waktu kedaluwarsa yang lebih singkat dan strategi exponential backoff.

Saat terjadi kemacetan berat, leader Solana gagal menyertakan transaksi vote yang sangat penting untuk mempertahankan konsensus. Akibatnya, tidak adanya vote yang dikonfirmasi membuat konsensus terhenti dan menghentikan produksi root block baru. Versi klien Solana berikutnya memperkenalkan mekanisme untuk memprioritaskan transaksi vote agar tidak tersisih oleh transaksi reguler pada kejadian mendatang.

Bug Kedua: Luapan Integer

Saat jaringan dimulai ulang, muncul masalah kedua. Validator melaporkan jumlah stake aktif yang berfluktuasi drastis. Masalah ini berasal dari bug yang secara keliru mengalikan persentase stake dengan 100 hingga melampaui nilai maksimum yang mungkin. Mekanisme inflasi telah menciptakan begitu banyak token SOL baru hingga menyebabkan luapan pada integer unsigned 64-bit. Bug ini segera diidentifikasi dan diperbaiki sebelum restart kedua.

Kemacetan Tinggi: Januari 2022

Waktu henti: Tidak ada

Akar penyebab: Transaksi duplikat yang berlebihan Perbaikan parsial:

• Rilis Solana 1.8.12 dan 1.8.14
• Optimalisasi deduplikasi SigVerify
• Peningkatan performa cache eksekutor

Antara 6 dan 12 Januari 2022, mainnet Solana mengalami kemacetan jaringan parah yang menyebabkan penurunan performa dan gangguan parsial. Gangguan tersebut dipicu oleh bot yang mengirim spam berupa transaksi duplikat secara berlebihan sehingga kapasitas jaringan turun drastis. Pemrosesan blok memerlukan waktu lebih lama dari perkiraan, menyebabkan leader berikutnya mengalami fork dan semakin mengurangi throughput. Pada puncaknya, tingkat keberhasilan transaksi turun hingga 70%. Klien kesulitan menangani transaksi jaringan yang semakin kompleks dan membutuhkan komputasi tinggi, sehingga keterbatasannya dalam memenuhi permintaan terlihat jelas.

Ketidakstabilan tambahan terjadi pada 21 hingga 23 Januari, dengan kemacetan yang terus berlanjut. Pada 22 Januari, endpoint RPC publik (https://api.mainnet-beta.solana.com) menjadi offline akibat penyalahgunaan karena panggilan RPC batch berisi spam membuat sistem kewalahan.

Untuk mengatasi masalah ini, rilis Solana 1.8.12 secara khusus menargetkan kehabisan cache program, sedangkan versi 1.8.14 memperkenalkan peningkatan pada cache Sysvar, pembuangan SigVerify, dan deduplikasi SigVerify.

Spam Candy Machine: April / Mei 2022 

Waktu henti: Delapan jam

Masalah utama: Spam transaksi dari account bot

Perbaikan:

• Pajak bot pada program Candy Machine
• Peningkatan memori di Solana v1.10

Pada 30 April 2022, Solana mengalami lonjakan permintaan transaksi yang belum pernah terjadi sebelumnya. Beberapa node melaporkan telah mencapai enam juta permintaan per detik dan menghasilkan lalu lintas lebih dari 100 Gbps per node. Lonjakan ini didorong oleh bot yang mencoba mendapatkan NFT yang baru dicetak melalui program Metaplex Candy Machine. Mekanisme pencetakan ini beroperasi berdasarkan siapa cepat dia dapat, sehingga menciptakan insentif ekonomi yang kuat untuk membanjiri jaringan dengan transaksi dan memenangkan pencetakan.

Ketika volume transaksi melonjak, validator kehabisan memori dan mengalami crash, yang akhirnya menghentikan konsensus. Throughput voting yang tidak memadai menghalangi finalisasi blok-blok sebelumnya sehingga fork yang ditinggalkan tidak dapat dibersihkan. Akibatnya, validator kewalahan oleh banyaknya fork yang harus dievaluasi, melampaui kapasitas bahkan setelah restart dan memerlukan intervensi manual untuk memulihkan jaringan.

Meski gangguan ini memiliki kemiripan dengan insiden September 2021, Solana menunjukkan ketahanan yang lebih baik. Walaupun menerima permintaan transaksi 10.000% lebih banyak daripada gangguan sebelumnya, jaringan tetap beroperasi jauh lebih lama. Hal ini mencerminkan peningkatan yang dilakukan komunitas validator untuk merespons tantangan penskalaan sebelumnya.

Restart jaringan membutuhkan waktu kurang dari 1,5 jam setelah snapshot kanonis disepakati. Solana v1.10 menyertakan peningkatan penggunaan memori untuk memperpanjang waktu node dapat bertahan saat konsensus melambat atau terhenti. 

Namun, masalah mendasar masih belum terselesaikan. Leader masih memproses transaksi yang memperebutkan data account yang sama berdasarkan siapa cepat dia dapat tanpa pencegahan spam yang efektif, sehingga pengguna tidak dapat memprioritaskan urgensi transaksi mereka. Untuk mengatasinya, tiga mekanisme jangka panjang diusulkan sebagai solusi praktis.

Adopsi QUIC: Sebelumnya, Solana mengandalkan protokol jaringan UDP (User Datagram Protocol) untuk mengirim transaksi melalui Gulf Stream dari node RPC kepada leader saat ini. Meskipun cepat dan efisien, UDP tidak berbasis koneksi serta tidak memiliki kontrol aliran dan konfirmasi penerimaan. Karena itu, tidak ada cara yang berarti untuk mencegah atau mengurangi perilaku abusif. Untuk mengendalikan lalu lintas jaringan, protokol penerimaan transaksi validator (yaitu Fetch Stage TPU) diimplementasikan ulang dengan QUIC.

QUIC berupaya menawarkan keunggulan terbaik dari TCP dan UDP. QUIC memfasilitasi komunikasi asinkron yang cepat seperti UDP, tetapi dilengkapi sesi aman dan strategi kontrol aliran tingkat lanjut seperti TCP. Hal ini memungkinkan penerapan batas pada setiap sumber lalu lintas agar jaringan dapat berfokus memproses transaksi asli. QUIC juga memiliki konsep stream terpisah, sehingga jika satu transaksi dibuang, transaksi lainnya tidak akan terblokir. QUIC akhirnya diintegrasikan ke dalam klien Solana Labs pada rilis 1.13.4.

Kualitas Layanan Berbobot Stake (SWQoS): Sistem baru yang memprioritaskan lalu lintas jaringan berdasarkan stake yang dimiliki validator diperkenalkan untuk memastikan validator dengan stake lebih tinggi dapat mengirim transaksi secara lebih efisien. Dalam mekanisme ini, validator dengan 3% dari total stake dapat mengirim hingga 3% dari total paket kepada leader. SWQoS berfungsi sebagai langkah resistansi Sybil sehingga pelaku berbahaya lebih sulit membanjiri jaringan dengan transaksi berkualitas rendah. Pendekatan ini menggantikan model siapa cepat dia dapat sebelumnya, yang menerima transaksi tanpa pandang bulu dan tanpa mempertimbangkan sumbernya.

Pengenalan Biaya Prioritas: Setelah diterima, transaksi tetap bersaing untuk mengakses data account bersama. Sebelumnya, persaingan ini diselesaikan hanya berdasarkan siapa cepat dia dapat sehingga pengguna tidak dapat menunjukkan urgensi transaksi mereka. Karena siapa pun dapat mengirimkan transaksi, pembobotan stake tidak cocok untuk menentukan prioritas pada tahap ini. Untuk mengatasinya, instruksi baru ditambahkan ke program Compute Budget agar pengguna dapat menentukan biaya tambahan yang dipungut saat eksekusi dan penyertaan dalam blok. Rasio biaya terhadap unit komputasi menentukan prioritas eksekusi transaksi sehingga urutan transaksi menjadi lebih dinamis dan didorong oleh pasar.

Pajak Bot Candy Machine

Metaplex dengan cepat memperkenalkan pajak bot hard-coded sebesar 0,01 SOL pada transaksi pencetakan yang berinteraksi dengan program Candy Machine untuk melawan spam berbasis bot. Mekanisme antispam ini mengenakan biaya minimal guna mencegah aktivitas berbahaya tanpa menghukum pengguna sah yang melakukan kesalahan tidak disengaja. Pajak tersebut diterapkan dalam skenario tertentu, termasuk:

• Mencoba mencetak saat Candy Machine belum aktif
• Mencoba mencetak saat tidak ada item yang tersisa
• Transaksi yang instruksi terakhirnya bukan mint atau set collection
• Menggunakan ID koleksi yang salah
• Instruksi Set Collection yang tidak cocok
• Ketidakcocokan signer-payer antara instruksi collection set dan mint
• Transaksi mencurigakan yang melibatkan program terlarang
• Mencoba mencetak dari Candy Machine yang dilindungi AllowList tanpa memiliki token allowlist yang diwajibkan

Pencegah berbasis ekonomi ini terbukti sangat efektif. Dana para sniper pencetakan cepat terkuras dan aktivitas spam berhenti. Dalam beberapa hari pertama, para pelaku bot secara kolektif kehilangan lebih dari 426 SOL.

Bug Durable Nonce: Juni 2022 

Waktu henti: Empat setengah jam

Masalah utama: Bug durable nonce yang menyebabkan kegagalan konsensus 

Perbaikan: 

• Penonaktifan sementara transaksi durable nonce
• Pembaruan Solana 1.10.23

Bug runtime memungkinkan transaksi durable nonce tertentu diproses dua kali—sekali sebagai transaksi reguler dan sekali lagi sebagai transaksi nonce—jika menggunakan blockhash terbaru, bukan durable nonce, di kolom recent_blockhash. Hal ini menimbulkan perilaku nondeterministik di antara validator karena beberapa node menolak eksekusi kedua sementara yang lain menerimanya. Yang terpenting, karena lebih dari sepertiga validator menerima blok tersebut, mayoritas dua pertiga yang diwajibkan tidak dapat mencapai konsensus.

Tidak seperti transaksi standar, transaksi durable nonce tidak kedaluwarsa dan memerlukan mekanisme unik untuk mencegah eksekusi ganda. Transaksi ini diproses secara serial menggunakan nilai nonce on-chain yang terkait dengan setiap account, yang dirotasi setiap kali transaksi durable nonce diproses. Setelah dirotasi, transaksi nonce yang sama seharusnya tidak berlaku lagi.

Untuk mengurangi masalah tersebut, transaksi durable nonce dinonaktifkan sementara. Perbaikan kemudian diterapkan di Solana 1.10.23, yang mencegah eksekusi duplikat dengan memisahkan domain nonce dan blockhash. Pembaruan ini memastikan bahwa ketika account nonce dimajukan, blockhash di-hash dengan string tetap sehingga blockhash tidak valid sebagai nilai nonce. Akibatnya, transaksi yang telah dieksekusi sebagai transaksi reguler tidak dapat dieksekusi kembali sebagai transaksi durable, dan sebaliknya. Selain itu, jenis DurableNonce baru menggantikan nilai blockhash sebelumnya dalam status account nonce, menambahkan keamanan jenis dan mencegah masalah serupa di masa mendatang.

Baca artikel blog Helius kami sebelumnya untuk memahami lebih lanjut durable nonce dan penggunaannya.

Bug Blok Duplikat: September 2022

Waktu henti: Delapan setengah jam

Masalah utama: Bug pada aturan pemilihan fork menyebabkan kegagalan konsensus

Perbaikan: 

• Patch klien

Gangguan ini dipicu oleh validator yang secara keliru menghasilkan blok duplikat pada ketinggian blok yang sama. Hal ini terjadi karena node utama validator dan node cadangannya aktif secara bersamaan, menggunakan identitas node yang sama tetapi mengusulkan blok berbeda. Kondisi ini berlangsung setidaknya selama 24 jam sebelum gangguan, dan selama periode tersebut jaringan menangani slot leader duplikat validator dengan benar.

Cluster akhirnya berhenti ketika jaringan mengalami fork yang tidak dapat dipulihkan akibat bug dalam logika pemilihan fork. Bug ini menghalangi produsen blok membangun di atas blok sebelumnya sehingga konsensus gagal.

Fork merupakan kejadian rutin di Solana, dan validator biasanya menyelesaikannya dengan menyelaraskan diri pada fork yang memiliki mayoritas vote (fork terberat). Ketika validator memilih fork yang salah, validator tersebut harus beralih ke fork terberat agar tetap sinkron dengan jaringan. Namun, dalam kasus ini, validator tidak dapat kembali ke bank terberat jika slotnya sama dengan slot terakhir yang mereka vote. Kelemahan ini membuat validator tetap terjebak, menghalangi perkembangan konsensus, dan pada akhirnya menghentikan jaringan.

Dalam contoh di atas, validator C yang bermasalah menghasilkan blok duplikat untuk slot leader 5 hingga 8. Ketika validator G mengambil alih sebagai leader berikutnya, validator tersebut hanya melihat salah satu duplikat dan memperpanjang fork-nya sesuai blok itu. Namun, leader berikutnya, validator D, mendeteksi kedua blok duplikat dari validator C dan memutuskan untuk membuangnya, lalu membangun fork-nya di atas slot 4.

Seiring jaringan berkembang, fork yang dibangun validator G memperoleh vote dari mayoritas stake dan menetapkan dirinya sebagai chain kanonis. Setelah menyadari fork-nya kalah, validator D mencoba beralih ke fork validator G. Namun, transisi gagal akibat bug dalam logika pemilihan fork. Masalah ini muncul karena leluhur bersama kedua fork—blok duplikat pada slot 5—tidak ditangani dengan benar, sehingga validator D tidak dapat mengenali fork mayoritas. Akibatnya, validator D tetap terjebak di fork-nya sendiri dan tidak dapat bergabung kembali dengan chain utama.

Masalah ini diselesaikan setelah ditinjau oleh tim inti. Sebuah patch digabungkan ke branch master dan di-backport ke semua branch rilis.

Blok Besar Membuat Turbine Kewalahan: Februari 2023

Waktu henti: Hampir 19 jam

Masalah utama: Kegagalan logika deduplikasi dalam layanan penerusan shred

Perbaikan:

• Berbagai peningkatan pada logika deduplikasi dan pemfilteran Turbine
• Menambahkan patch klien yang memaksa produsen blok membatalkan proses jika menghasilkan blok besar

Layanan penerusan shred khusus milik sebuah validator mengalami malafungsi dan mengirimkan blok yang luar biasa besar (hampir 150.000 shred), beberapa kali lipat lebih besar daripada blok standar, selama slot leader-nya. Hal ini membuat filter deduplikasi validator kewalahan sehingga data terus-menerus diteruskan kembali. Masalah semakin parah ketika blok baru diproduksi dan akhirnya memenuhi kapasitas protokol.

Lonjakan lalu lintas jaringan yang tidak normal membuat Turbine kewalahan sehingga data blok harus dikirim melalui protokol fallback Block Repair yang jauh lebih lambat. Meskipun Turbine dirancang untuk menahan blok besar dengan memfilternya, layanan penerusan shred beroperasi sebelum logika pemfilteran ini sehingga mengurangi efektivitasnya. Selama periode penurunan performa, leader blok otomatis beralih ke mode hanya vote, yaitu mekanisme keamanan yang membuat leader tidak menyertakan transaksi ekonomi non-vote.

Akar masalahnya adalah kegagalan logika deduplikasi di dalam layanan penerusan shred yang tidak dapat mencegah pengiriman ulang shred secara berlebihan. Selain itu, filter deduplikasi dalam pipeline transmisi ulang awalnya tidak dirancang untuk mencegah perulangan di dalam pohon Turbine sehingga memperburuk masalah.

Jaringan dimulai ulang secara manual dengan downgrade ke versi perangkat lunak validator stabil terakhir yang diketahui. Untuk mengurangi masalah tersebut, Solana v1.13.7 dan v1.14.17 memperkenalkan peningkatan pada logika deduplikasi, meningkatkan kemampuannya mencegah saturasi filter dan memastikan performa jaringan yang lebih tangguh.

Perulangan Kompilasi Ulang Tanpa Akhir: Februari 2024

Waktu henti: Hampir lima jam

Masalah utama: Bug yang menyebabkan perulangan kompilasi ulang tanpa akhir di cache JIT

Perbaikan: 

• Menonaktifkan legacy loader v1.17.20

Validator Agave melakukan kompilasi just-in-time (JIT) terhadap semua program sebelum mengeksekusi transaksi yang merujuknya. Untuk mengoptimalkan performa, output JIT dari program yang sering digunakan disimpan dalam cache sehingga mengurangi kompilasi ulang yang tidak perlu. Sebagai bagian dari Agave v1.16, mekanisme caching yang ada, LoadedPrograms, digantikan dengan implementasi baru bernama ExecutorsCache, yang memperkenalkan sejumlah efisiensi.

LoadedPrograms menyediakan tampilan global yang menyadari fork terhadap program dalam cache, mengurangi duplikasi data akuntansi, dan memungkinkan thread eksekusi transaksi memuat program baru secara kooperatif sehingga mencegah konflik kompilasi. Fitur utama sistem ini adalah melacak slot tempat program mulai aktif (dikenal sebagai ketinggian slot efektif) untuk mendeteksi invalidasi cache saat data program on-chain diperbarui.

Ketinggian slot efektif sebagian besar program berasal dari slot deployment yang disimpan dalam account on-chain program tersebut. Namun, program yang di-deploy menggunakan legacy loader tidak menyimpan slot deployment ini dalam account-nya. Sebagai solusi sementara, LoadedPrograms menetapkan ketinggian slot efektif nol untuk program tersebut.

Pengecualian terjadi ketika instruksi deploy terdeteksi, yang menandakan bahwa bytecode program telah diganti. Dalam kasus ini, LoadedPrograms untuk sementara menyisipkan entri dengan ketinggian slot efektif yang benar. Namun, karena tidak ada transaksi yang merujuk entri ini, entri tersebut sangat rentan dikeluarkan dari cache. Ketika dikeluarkan, output JIT dibuang dan program ditandai sebagai belum dimuat, tetapi ketinggian slot efektifnya tetap dipertahankan.

Jika transaksi kemudian merujuk program yang belum dimuat ini, LoadedPrograms akan mengompilasinya kembali dan menyisipkan ulang entri pada ketinggian slot efektifnya. Biasanya, hal ini akan membuat program tersedia untuk dieksekusi pada iterasi berikutnya. Namun, untuk program legacy loader, output JIT baru diberi ketinggian slot sentinel nol sehingga ditempatkan di belakang entri sebelumnya yang belum dimuat. Akibatnya, LoadedPrograms tidak pernah mengenali program tersebut sebagai sudah dimuat dan memicu perulangan kompilasi ulang tanpa henti pada setiap iterasi.

Di Agave v1.16, LoadedPrograms tidak mendukung pemuatan kooperatif sehingga transaksi pemicu dapat dimasukkan ke dalam blok. Blok ini kemudian disebarkan ke seluruh jaringan, menyebabkan setiap validator memutarnya ulang dan memasuki perulangan kompilasi ulang tanpa akhir yang sama. Karena lebih dari 95% stake cluster menjalankan Agave v1.17 saat gangguan terjadi, sebagian besar validator terhenti pada blok ini dan menghentikan jaringan.

Bug ini telah diidentifikasi pada minggu sebelumnya saat investigasi terhadap gangguan cluster Devnet, dan sebuah patch dijadwalkan untuk diterapkan. Mitigasi yang dipilih adalah melakukan backport perubahan ke Agave v1.17 dan segera menghapus feature gate saat jaringan dimulai ulang. Langkah ini menonaktifkan legacy loader yang memicu bug tersebut sehingga mencegah kejadian lebih lanjut.

Patch Kerentanan Terkoordinasi: Agustus 2024

Waktu henti: Tidak ada

Masalah utama: Asumsi penyelarasan alamat ELF yang salah

Perbaikan: 

• Pembaruan patch 

Pada 5 Agustus, engineer inti Anza menerima peringatan tentang kerentanan di klien Agave yang dilaporkan oleh peneliti eksternal. Penyerang dapat mengeksploitasi kelemahan ini untuk membuat validator leader mengalami crash dan menghentikan seluruh jaringan. Sebagai tanggapan, engineer Anza segera mengembangkan patch yang kemudian diaudit oleh beberapa perusahaan keamanan pihak ketiga.

Program Solana dikompilasi menggunakan LLVM menjadi Executable and Linkable Format (ELF). Kerentanan tersebut berasal dari asumsi penyelarasan alamat yang salah dalam file ELF yang dihasilkan. Meskipun sanitasi ELF biasanya menerapkan berbagai pemeriksaan integritas, proses tersebut tidak memvalidasi penyelarasan bagian .text. Kelalaian ini dapat memungkinkan file ELF yang dibuat secara berbahaya menentukan bagian .text yang tidak selaras sehingga virtual machine melompat ke alamat yang tidak valid. Hal ini akan menyebabkan segmentation fault pada host dan membuat validator mengalami crash.

Penyerang dapat mengeksploitasi kerentanan ini dengan:

• Membuat program Solana berbahaya yang menggunakan opcode CALL_REG.
• Memanipulasi file ELF agar bagian .text tidak selaras.
• Melakukan deployment dan memanggil program di jaringan untuk memicu crash pada validator.

Proses Pembaruan Patch

Pembaruan patch yang dirilis secara publik akan segera mengungkap kerentanan tersebut kepada semua orang. Hal ini dapat memberi penyerang cukup waktu untuk merekayasa balik kerentanan dan menghentikan jaringan sebelum jumlah stake yang memadai melakukan upgrade. Sejumlah besar validator harus mengadopsi setiap rilis patch secepat mungkin untuk menghindari skenario tersebut.

Pada 7 Agustus, beberapa anggota Solana Foundation telah menghubungi validator melalui pesan pribadi di berbagai platform komunikasi, memberi tahu mereka tentang patch kritis yang akan datang dan membagikan pesan yang di-hash untuk mengonfirmasi tanggal serta pengidentifikasi unik insiden tersebut. Beberapa anggota terkemuka Anza, Jito, dan Solana Foundation membagikan hash ini di X, GitHub, dan LinkedIn untuk memverifikasi keakuratan pesan. Contoh hash yang dibagikan: 

trent.sol

@trentdotsol

07ff4f17c96a632726e209b4afbbcf4e6ba089989cb485b8abbe85da3f558cd9

7 Agu 2024, 2.35 PM

Sepanjang hari berikutnya, anggota inti terus menghubungi validator dan menekankan pentingnya urgensi serta kerahasiaan. Pada waktu yang telah ditentukan, 8 Agustus pukul 14.00 UTC, operator validator menerima pesan lanjutan berisi petunjuk untuk mengunduh, memverifikasi, dan menerapkan patch. Patch di-host di repositori Github milik engineer Anza yang dikenal, bukan di repositori utama Agave. Petunjuk tersebut mencakup verifikasi file patch yang diunduh terhadap shasum yang disediakan.

Pada pukul 20.00 UTC tanggal 8 Agustus, supermayoritas stake telah menerima patch sehingga keamanan jaringan terjamin. Setelah itu, kerentanan dan patch terkait diungkapkan secara publik, disertai imbauan agar semua validator yang tersisa melakukan upgrade.

Distribusi patch secara diam-diam dan koordinasi validator di balik layar memunculkan kekhawatiran tentang desentralisasi Solana. Tidak lama setelah insiden tersebut, direktur eksekutif Solana Foundation, Dan Albert, menanggapi kritik ini dalam wawancara media.

“Menurut saya, penting untuk tidak menyamakan sentralisasi dengan kemampuan berkoordinasi. Ada 1.500 node penghasil blok di seluruh dunia yang dioperasikan oleh hampir sebanyak itu individu…. Kemampuan untuk berkomunikasi secara sukarela dengan mereka, atau sebagian dari mereka, tidak boleh disamakan dengan sentralisasi.”

Kesimpulan

Saat artikel ini ditulis, Solana telah melewati lebih dari setahun tanpa gangguan dan mencapai tonggak penting untuk menghapus label “beta” dari mainnet-beta. Frekuensi gangguan tampaknya menurun seiring kematangan jaringan, dan kehadiran Firedancer diharapkan meningkatkan keberagaman klien sehingga mengurangi risiko bug atau edge case yang belum ditemukan menyebabkan seluruh cluster berhenti. Namun, beberapa pemimpin komunitas, termasuk pendiri Helius Mert Mumtaz, memperkirakan bahwa gangguan akan terus terjadi. Waktu yang akan membuktikannya.

Terima kasih banyak kepada Zantetsu (Shinobi Systems) dan OxIchigo yang telah meninjau versi awal tulisan ini.

Referensi Lebih Lanjut

• Waktu Aktif dan Status Solana