Kerentanan mengerikan di Solana baru saja terungkap: Peretas hampir menyebabkan jaringan lumpuh

Ketika tim maintenans Solana meminta validator untuk segera memperbarui ke Agave v3.0.14, pesan tersebut disampaikan dengan tingkat urgensi yang lebih tinggi daripada detail teknis.

Akun Solana Status menyebut rilis ini sebagai “kebutuhan mendesak”, termasuk “serangkaian patch penting” untuk validator di Mainnet Beta.

Hanya dalam satu hari, diskusi publik beralih ke pertanyaan yang lebih sulit: jika sebuah jaringan PoS perlu melakukan upgrade secara cepat, apa yang terjadi jika operator tidak melakukan koordinasi secara serempak?

Kesenjangan tersebut terlihat jelas dari data penerapan awal. Pada 11/1, sebuah akun yang banyak dibagikan menyatakan bahwa sekitar 18% stake telah dipindahkan ke v3.0.14 saat itu, yang berarti sebagian besar “berat ekonomi” jaringan masih berjalan di versi lama selama periode yang diberi label mendesak.

Dengan sebuah blockchain yang telah menghabiskan setahun untuk mempromosikan keandalan sekaligus kecepatan, fokus cerita dengan cepat bergeser dari kode itu sendiri ke pertanyaan apakah tim operasional dapat berkumpul cukup cepat saat situasi benar-benar penting.

Dalam lebih dari 10 hari berikutnya, gambaran menjadi lebih jelas dan berguna dibandingkan headline awal.

Anza, tim di balik Agave, mengumumkan ringkasan patch keamanan pada 16/1, menjelaskan mengapa v3.0.14 penting dan mengapa operator diminta untuk segera melakukan upgrade.

Pada waktu yang sama, ekosistem Solana memberi sinyal bahwa koordinasi tidak hanya bergantung pada niat baik. Kriteria staking delegated dari Solana Foundation kini secara jelas menyebutkan persyaratan versi perangkat lunak, termasuk Agave 3.0.14 dan Frankendancer 0.808.30014, sebagai bagian dari standar yang harus dipenuhi validator agar tetap menerima stake yang didelegasikan.

Secara keseluruhan, peristiwa ini menjadikan v3.0.14 sebagai studi kasus tentang apa yang “keuangan selalu aktif” butuhkan di Solana secara nyata — tidak hanya dari perangkat lunak, tetapi juga dari mekanisme insentif dan perilaku operasional di bawah tekanan waktu.

Sebuah blockchain berkecepatan tinggi tetap bergantung pada manusia yang mengoperasikan

Solana adalah blockchain proof-of-stake yang dirancang untuk memproses volume transaksi besar dengan kecepatan tinggi. Validator memberikan suara untuk blok dan menjaga keamanan ledger berdasarkan proporsi SOL yang mereka delegasikan.

Bagi pengguna yang tidak menjalankan validator sendiri, delegasi stake kepada operator adalah faktor keamanan sekaligus sinyal ekonomi, memberi insentif kepada validator yang stabil dan efisien.

Desain ini memiliki konsekuensi yang mudah terabaikan jika hanya melihat grafik harga token. Blockchain bukanlah mesin yang ditempatkan di satu lokasi. Di Solana, “jaringan” terdiri dari ribuan operator independen yang menjalankan perangkat lunak kompatibel, melakukan upgrade di waktu berbeda, di infrastruktur berbeda, dengan tingkat otomatisasi dan toleransi risiko yang berbeda pula.

Saat semuanya berjalan lancar, independensi ini membantu membatasi titik kontrol terpusat. Tetapi ketika upgrade menjadi mendesak, justru independensi tersebut yang membuat koordinasi menjadi lebih sulit.

Gambar client Solana semakin menegaskan pentingnya kolaborasi. Client paling umum saat ini adalah yang dipertahankan melalui fork Agave dari Anza. Pada saat yang sama, jaringan sedang berupaya mendiversifikasi client melalui Firedancer dari Jump Crypto, dengan Frankendancer sebagai tonggak perantara.

Diversifikasi client dapat mengurangi risiko satu bug yang menyebabkan sebagian besar stake offline sekaligus, tetapi tidak menghilangkan kebutuhan untuk upgrade keamanan secara serempak saat patch yang sensitif waktu muncul.

Inilah konteks munculnya v3.0.14. Urgensi ini bertujuan menutup jalan yang dapat menyebabkan gangguan sebelum dieksploitasi.

Perubahan dalam 10 hari berikutnya: alasan yang diumumkan secara terbuka, dan motivasi ekonomi yang terungkap

Pengumuman dari Anza mengisi bagian yang hilang dari cerita tersebut. Dua celah kerentanan serius yang potensial diungkapkan pada Desember 2025 melalui advisory keamanan di GitHub. Anza menyatakan bahwa masalah ini telah diperbaiki dengan koordinasi Firedancer, Jito, dan Solana Foundation.

Celah pertama terkait dengan sistem gossip Solana — mekanisme di mana validator berbagi pesan jaringan meskipun proses pembuatan blok terganggu. Menurut Anza, bug dalam penanganan beberapa jenis pesan dapat menyebabkan validator crash dalam kondisi tertentu. Jika dieksploitasi secara terkoordinasi dan cukup banyak stake yang terhenti, ketersediaan seluruh cluster jaringan bisa menurun secara signifikan.

Celah kedua terkait dengan proses voting — pusat dari mekanisme konsensus. Menurut Anza, langkah verifikasi yang hilang dapat memungkinkan penyerang membanjiri validator dengan pesan voting tidak valid, mengganggu proses voting normal dan berpotensi menghambat konsensus secara besar-besaran.

Patch ini memastikan bahwa pesan voting diverifikasi dengan benar sebelum diproses dalam pembuatan blok.

Pengungkapan ini mengubah pandangan tentang cerita “penyebaran lambat” awal. Upgrade ini mendesak karena menutup dua jalur potensial menuju gangguan besar: satu melalui crash validator, satu lagi melalui gangguan mekanisme voting secara besar-besaran.

Pertanyaan tentang kemampuan operasional tetap penting, tetapi menjadi lebih spesifik: seberapa cepat tim tersebar dapat melakukan patch saat skenario kesalahan sudah jelas dan bersifat sistemik?

Sejalan dengan itu, regulasi delegasi stake dari Solana membuat mekanisme kolaborasi menjadi lebih jelas. Kriteria dari Solana Foundation mencakup persyaratan versi perangkat lunak dan standar respons. Jadwal pengumuman versi wajib yang mencantumkan Agave 3.0.14 dan Frankendancer 0.808.30014 sebagai versi yang harus dipenuhi dalam beberapa epoch.

Bagi operator yang menerima delegasi dari Foundation, upgrade menjadi masalah ekonomi: ketidakpatuhan dapat menyebabkan pencabutan stake yang didelegasikan sampai standar terpenuhi.

Itulah kenyataan operasional di balik konsep “keuangan selalu aktif”. Ia dibangun dari kode sumber, tetapi dipertahankan oleh motivasi ekonomi, dashboard monitoring, dan standar yang mendorong ribuan aktor independen berkumpul dalam kerangka waktu singkat akibat insiden keamanan.

Namun, meskipun sudah diumumkan secara terbuka dan memiliki motivasi ekonomi, penerapan cepat tetap tidak mulus. Anza menyatakan bahwa operator perlu membangun dari kode sumber sesuai panduan instalasi mereka.

Build dari source tidak otomatis berisiko, tetapi meningkatkan tuntutan operasional karena validator bergantung pada pipeline build, pengelolaan dependency, dan pengujian internal sebelum perubahan di-deploy ke lingkungan produksi.

Persyaratan ini menjadi sangat penting dalam upgrade mendesak, saat waktu untuk pengujian dan penjadwalan maintenance dipadatkan, sementara kesalahan dapat menyebabkan hilangnya reward langsung dan kerusakan reputasi di pasar yang kompetitif.

Peristiwa v3.0.14 juga tidak mengganggu siklus rilis luas Solana.

Pada 19/1, repositori Agave merilis v3.1.7, yang diberi label sebagai testnet dan direkomendasikan untuk devnet serta maksimal 10% mainnet beta, menunjukkan pipeline yang terus berubah yang harus dipantau dan direncanakan oleh operator. Pada 22/1, roadmap rilis v3.1 dari Agave terus diperbarui dengan rencana implementasi yang diperkirakan.

Tingkat kesiapan ini menjadi indikator yang dapat diukur melalui metrik tertentu.

Salah satu metrik adalah kecepatan konvergensi versi di bawah tekanan, yaitu seberapa cepat stake berpindah ke versi yang direkomendasikan saat ada peringatan mendesak. Laporan awal tentang v3.0.14 menunjukkan biaya dari lambatnya proses migrasi.

Indikator kedua adalah ketahanan terhadap kesalahan simultan secara luas. Diversifikasi client melalui Firedancer dan Frankendancer membantu mengurangi risiko satu perangkat lunak tunggal yang bisa membuat jaringan down, tetapi hanya jika distribusi client pengganti cukup besar.

Indikator ketiga adalah tingkat sinkronisasi motivasi ekonomi, di mana kriteria delegasi dan persyaratan versi mengubah “keamanan bersih” menjadi kondisi ekonomi yang wajib bagi banyak operator.

Peristiwa v3.0.14 dimulai dengan label “kebutuhan mendesak” dan kekhawatiran tentang kecepatan penerapan, lalu secara bertahap menjadi pandangan yang lebih jelas tentang bagaimana Solana memperbaiki bug, berkoordinasi, dan menegakkan standar di tim validator yang tersebar.

Vương Tiễn