Firedancer diluncurkan ke mainnet, tetapi Solana masih belum mencapai standar keamanan Ethereum

Setelah tujuh tahun pengembangan, Firedancer resmi beroperasi di mainnet Solana pada bulan 12/2025, setelah menghasilkan lebih dari 50.000 blok dalam 100 hari pengujian dengan sejumlah validator kecil.

Tonggak sejarah yang diumumkan secara resmi oleh akun Solana pada tanggal 12/12 bukan hanya peningkatan performa. Ini adalah upaya serius pertama untuk menghilangkan bottleneck arsitektur yang telah menyebabkan kegagalan jaringan paling serius: ketergantungan hampir mutlak pada satu client validator tunggal.

Sejak bertahun-tahun, Solana mempromosikan kemampuan finalitas di bawah satu detik dan throughput ribuan transaksi per detik. Tetapi kecepatan menjadi tidak berarti ketika 70%–90% kekuatan konsensus jaringan berjalan dengan perangkat lunak yang sama. Satu kesalahan serius dalam client dominan sudah cukup untuk menghentikan seluruh blockchain, terlepas dari kapasitas teoretisnya yang tinggi.

Ethereum telah belajar pelajaran ini sejak beralih ke proof-of-stake dan menganggap keberagaman client sebagai kebutuhan infrastruktur yang tak bisa dinegosikan. Solana berusaha mengikuti jalur tersebut, tetapi berasal dari tingkat konsentrasi yang jauh lebih tinggi.

Apa itu Firedancer dan apa yang membedakannya

Firedancer bukanlah patch atau fork dari client Agave yang ditulis dalam Rust. Ini adalah penulisan ulang dari awal dalam C/C++, dikembangkan oleh Jump Crypto, dengan arsitektur modular yang terinspirasi dari sistem transaksi berkecepatan tinggi.

Dua client tidak berbagi kode sumber, tidak menggunakan bahasa pemrograman yang sama, dan tidak memiliki tim pemeliharaan yang tumpang tindih. Independensi ini menciptakan “zona error” terpisah: satu kesalahan dalam pengelolaan memori atau scheduler transaksi dari Agave, secara teori, tidak akan membuat validator yang menjalankan Firedancer crash.

Dengan jaringan yang telah mengalami tujuh kali gangguan dalam lima tahun, di mana lima di antaranya berasal dari kesalahan client, pemisahan ini adalah poin kunci.

Masalah “sendirian” yang belum bisa diatasi Solana

Riwayat gangguan Solana adalah ilustrasi utama dari risiko satu client saja. Pada bulan 6/2022, jaringan berhenti selama lebih dari empat jam setelah bug dalam fitur durable-nonce menyebabkan validator kehilangan sinkronisasi, memaksa restart yang terkoordinasi.

Kegagalan lain diidentifikasi dari kebocoran memori, duplikasi transaksi berlebihan, dan kondisi kontestasi dalam pembuatan blok. Analisis seluruh riwayat gangguan menunjukkan 5/7 berasal dari kesalahan validator atau client, bukan dari desain konsensus.

Throughput tinggi menjadi tidak berarti jika hanya satu kesalahan implementasi yang cukup untuk melumpuhkan proses pembuatan blok.

Data ini mengonfirmasi tingkat paparan tersebut. Laporan kesehatan jaringan Solana Foundation bulan 6/2025 menunjukkan Agave dan varian Jito menguasai sekitar 92% dari staking SOL. Hingga bulan 10/2025, persentase ini menurun tetapi tetap di atas 70%, sementara Frankendancer meningkat menjadi sekitar 21%.

Frankendancer adalah model hybrid: menggunakan lapisan jaringan Firedancer dikombinasikan dengan backend konsensus dari Agave. Proporsi ini meningkat secara bertahap dari sekitar 8% pada bulan 6, menunjukkan penerimaan solusi semi-bercampur. Namun, baru dengan Firedancer sepenuhnya di mainnet bulan 12 yang benar-benar mengubah permainan.

Sekarang, validator dapat menjalankan stack yang benar-benar independen, menghilangkan ketergantungan bersama yang sebelumnya menyebabkan kesalahan client menyebar ke seluruh jaringan.

Model acuan dari Ethereum

Dokumen tentang keberagaman client Ethereum memperingatkan bahwa client mana pun yang menguasai lebih dari dua pertiga kekuatan konsensus dapat secara sepihak menyelesaikan blok yang salah. Bahkan, hanya dengan melewati sepertiga saja sudah cukup untuk mencegah finalitas jika client tersebut berhenti berfungsi atau berperilaku tidak normal.

Komunitas Ethereum menganggap menjaga semua client di bawah 33% sebagai persyaratan keamanan mutlak, bukan optimalisasi performa. Posisi awal Solana, dengan satu client mendekati 90%, berada di luar zona aman ini.

Apa yang benar-benar diubah Firedancer

Firedancer melakukan redeploy seluruh pipeline validator Solana dengan arsitektur paralel yang kuat, primitive jaringan yang dapat dikustomisasi, dan pengelolaan memori yang berorientasi pada performa di bawah beban besar.

Benchmark yang dipresentasikan pada konferensi teknik menunjukkan Firedancer memproses dari 600.000 hingga lebih dari 1.000.000 transaksi per detik dalam lingkungan terkendali, secara signifikan melampaui Agave. Tetapi batas performa bukan yang utama; yang penting adalah pemisahan zona error.

Berdasarkan dokumen dan panduan deployment, Firedancer dirancang modular: jaringan, partisipasi konsensus, dan eksekusi transaksi adalah komponen terpisah. Kesalahan pengelolaan memori di allocator Rust dari Agave tidak menyebar ke kode C++ Firedancer; kesalahan logika dalam scheduler blok dari Agave juga tidak mempengaruhi model eksekusi “tile” dari Firedancer.

Dua client bisa gagal secara independen, membantu jaringan tetap berjalan jika distribusi stake tidak membuat mayoritas super menjadi runtuh secara bersamaan.

Implementasi Frankendancer berfungsi sebagai “landasan”: menggantikan lapisan jaringan dan pembuatan blok dari Agave dengan Firedancer, tetapi mempertahankan konsensus dan eksekusi. Pendekatan ini memungkinkan peningkatan performa tanpa menempatkan seluruh jaringan dalam risiko konsensus yang belum teruji.

Namun, selama validator masih bergantung pada Agave untuk konsensus, satu kesalahan di lapisan bersama tetap bisa menyetop rantai. Dengan Firedancer sepenuhnya di mainnet, ketergantungan ini sudah dihilangkan.

Tim validator yang menjalankan Firedancer selama 100 hari menghasilkan lebih dari 50.000 blok, menunjukkan bahwa client dapat berpartisipasi dalam konsensus, membuat blok yang valid, dan mempertahankan status tanpa komponen Agave. Catatan produksinya masih terbatas, tetapi sudah cukup membuka jalan untuk pengembangan lebih lanjut.

Mengapa organisasi peduli terhadap perangkat lunak validator

Keterkaitan antara keberagaman client dan penerimaan organisasi bukan hanya teori. Banyak analisis menunjukkan Firedancer menyelesaikan kekhawatiran utama investor institusional tentang keandalan dan skalabilitas, dan bahwa cadangan multi-client adalah tingkat ketahanan yang dibutuhkan bagi aplikasi penting.

Dalam penilaian kesiapan organisasi, gangguan sebelumnya dianggap sebagai hambatan terbesar, sementara Firedancer digambarkan sebagai solusi potensial. Keandalan dipandang sebagai faktor utama dalam kompetisi antara Solana dan layer-1 lainnya.

Rangkaian logika ini mirip dengan kampanye keberagaman client Ethereum. Untuk manajemen risiko, pertanyaan utama adalah: apa yang terjadi jika terjadi kegagalan?

Sebuah jaringan di mana 90% validator berjalan dengan client yang sama memiliki risiko satu titik kegagalan, tidak peduli seberapa tersebar token atau jumlah validator secara administratif. Sebaliknya, jaringan tanpa client yang melebihi 33% dapat kehilangan satu client secara serius dan tetap beroperasi. Perbedaan ini bersifat binari dalam keputusan pengembangan produk yang terkelola.

Sekitar 767 juta USD aset dunia nyata yang ditokenisasi di Solana baru langkah awal, sementara Ethereum menyimpan lebih dari 12,5 miliar USD. Celah ini mencerminkan tidak hanya efek jaringan atau komunitas pengembang, tetapi juga kepercayaan terhadap waktu aktif.

Firedancer menawarkan jalan bagi Solana untuk memperkecil jarak ini dengan mencapai tingkat keberagaman client yang dianggap standar minimum infrastruktur produksi Ethereum.

Kurva adopsi ke depan

Peralihan dari dominasi 70% Agave ke jaringan multi-client yang seimbang tidak akan terjadi secara cepat. Validator menghadapi biaya konversi: Firedancer membutuhkan penyesuaian perangkat keras yang berbeda, proses operasional yang berbeda, dan karakteristik performa yang berbeda pula.

Catatan produksi 100 hari, meskipun positif, masih pendek dibandingkan beberapa tahun operasi Agave. Para pengelola yang berhati-hati akan menunggu data lebih banyak sebelum memindahkan stake.

Namun, struktur insentif sudah condong ke arah diversifikasi. Laporan kesehatan validator dari Solana Foundation secara terbuka menampilkan distribusi client, memberikan tekanan reputasi yang mendorong operator besar untuk menghindari konsentrasi pada satu implementasi saja.

Riwayat gangguan jaringan adalah pengingat jelas akan risiko. Dan cerita menarik bagi organisasi, dari ETF, penerbitan RWA, hingga uji coba pembayaran perusahaan, bergantung pada bukti bahwa Solana mampu mengatasi masalah keandalan.

Arsitektur sudah siap. Saat ini, Solana memiliki dua client produksi, berbeda bahasa, sumber kode terpisah, dan zona error yang terisolasi. Ketahanan jaringan kini bergantung pada kecepatan pergeseran stake, dari model “sendirian” awal ke distribusi yang tak bisa dilenyapkan satu client pun secara sepihak.

Ini adalah pertanyaan utama bagi organisasi yang menilai apakah Solana bisa menjadi infrastruktur produksi yang sesungguhnya dan memiliki jalan nyata untuk melewati kegagalan client berikutnya tanpa harus melakukan reboot seluruh jaringan.