Menghadirkan Slashing ke Solana

Pendahuluan

Slashing adalah mekanisme untuk menegakkan keamanan jaringan dengan menghukum perilaku validator yang berbahaya atau lalai. Setelah pelanggaran terverifikasi, sebagian stake yang didelegasikan dan terkait dengan validator pelanggar akan dibakar.

Ini merupakan fitur khas jaringan Proof of Stake (PoS) seperti Solana, tanpa padanan dalam Proof of Work (PoW), karena bergantung pada kemampuan protokol untuk menerapkan hukuman finansial secara langsung dengan memusnahkan aset yang di-stake. Dalam PoW, tidak ada mekanisme serupa karena blockchain tidak dapat menyita atau memusnahkan perangkat keras mining fisik milik pelaku yang tidak jujur.

Slashing memberikan beberapa manfaat utama:

• Menjadi disinsentif ekonomi langsung terhadap aktivitas berbahaya
• Mendorong staker untuk mendistribusikan stake mereka ke berbagai validator bereputasi baik sehingga meningkatkan desentralisasi
• Mendorong operator yang lebih besar untuk membangun infrastruktur heterogen yang mengurangi risiko kegagalan bersama (misalnya, membagi stake mereka antara klien Firedancer dan Agave).
• Memberikan metrik lain bagi validator untuk membedakan diri dan membangun reputasi dengan menghindari pelanggaran slashing serta mendeteksi aktivitas berbahaya dari peserta lain.

Sepanjang sejarahnya, Solana mengandalkan pendekatan konsensus manual berbasis komunitas yang disebut social slashing. Dalam model ini, jika validator berperilaku jahat, misalnya dengan mengganggu liveness atau keamanan jaringan, peserta yang jujur dapat berkoordinasi secara off-chain untuk memulai hard fork, menjalankan ulang jaringan, dan melakukan slashing terhadap stake pelanggar. Meskipun metode ini memungkinkan penilaian yang fleksibel untuk setiap kasus, koordinasi yang dibutuhkan cukup besar dan sifatnya reaktif.

Hingga saat ini, belum ada validator di Solana yang terkena slashing. Peristiwa terdekat yang menyerupai slashing terjadi pada Mei 2020, dua bulan setelah peluncuran mainnet, ketika Solana Foundation secara sukarela membakar 11,36 juta SOL dari alokasinya sendiri sebagai tanggapan atas kekhawatiran komunitas mengenai pinjaman token kepada market maker yang tidak diungkapkan. Tindakan ini mengurangi total pasokan token sebesar 2,3%, dari 500 juta menjadi 488,64 juta SOL. Meski bukan peristiwa slashing formal, pembakaran tersebut berfungsi sebagai hukuman yang diterapkan sendiri untuk memulihkan kepercayaan dan mengatasi masalah transparansi yang diangkat oleh komunitas awal.

Selama beberapa tahun, muncul seruan agar Solana mengadopsi mekanisme slashing yang lebih formal, yang sering disebut slashing terprogram, dan diterapkan langsung secara on-chain melalui program bawaan. Dalam sistem ini, jika validator melanggar aturan protokol tertentu, bukti kriptografis atas pelanggaran tersebut dapat dibuat dan dikirimkan ke program khusus yang kemudian secara otomatis memicu slashing. Model ini mengurangi ketergantungan pada koordinasi manusia dan memungkinkan penegakan terhadap pelanggaran ringan tanpa mengganggu operasi jaringan, sehingga membuka jalan bagi akuntabilitas terdesentralisasi yang dapat diskalakan.

Aktivasi feature gate SIMD-0204: Verifikasi Peristiwa yang Dapat Dikenai Slashing yang akan datang menandai langkah besar dan signifikan pertama Solana untuk menerapkan slashing terprogram formal di mainnet. Seperti yang akan dibahas nanti dalam laporan ini, peristiwa slashing terprogram di jaringan blockchain untungnya jarang terjadi dan hukumannya biasanya ringan. Namun, bahkan sekadar kemungkinan stake validator dimusnahkan secara otomatis oleh protokol menghadirkan risiko baru yang harus dipertimbangkan dengan cermat oleh semua pemangku kepentingan. Masih ada banyak pertanyaan terbuka mengenai pendekatan optimal bagi Solana untuk menerapkan slashing terprogram. Seperti semua perubahan ekonomi, parameter dan hukuman yang terkait dengan slashing memerlukan diskusi komunitas yang luas dan pada akhirnya harus disetujui melalui pemungutan suara tata kelola formal.

SIMD Terkait Slashing

Beberapa SIMD berkaitan dengan peluncuran slashing terprogram di Solana. Dua SIMD pertama, SIMD-180 dan SIMD-204, dijadwalkan aktif di mainnet dalam beberapa bulan mendatang.

Pertama adalah prasyarat SIMD-0180: Menggunakan Alamat Vote Account sebagai Kunci Leader Schedule. SIMD ini mengubah kunci yang digunakan dalam leader schedule dari alamat identitas validator menjadi alamat vote account-nya. Perubahan ini penting untuk atribusi slashing yang akurat karena menciptakan hubungan langsung dan tidak ambigu antara tugas produksi blok validator dan stake yang didelegasikan kepadanya.

SIMD-0204: Verifikasi Peristiwa yang Dapat Dikenai Slashing menguraikan Program Slashing baru. Program ini memperkenalkan mekanisme on-chain yang memungkinkan siapa pun mengirimkan dan mencatat bukti perilaku yang dapat dikenai slashing, sehingga menciptakan catatan pelanggaran validator yang dapat diverifikasi dan tidak dapat diubah.

Terakhir, SIMD-0212: Slashing menguraikan penerapan slashing dalam protokol Solana. SIMD ini dibangun di atas fondasi yang diletakkan oleh SIMD-0204 untuk menerapkan hukuman terhadap pelanggaran terverifikasi. Proposal ini masih terbuka dan terus dibahas secara aktif.

Deteksi dan Atribusi Kesalahan

Program Slashing dirancang sebagai lapisan observasi murni. Program ini tidak mengubah stake atau reward; satu-satunya fungsinya adalah memverifikasi dan mencatat pelanggaran. Prototipe awal sudah aktif di Testnet, dengan contoh pengiriman (misalnya, transaksi DuplicateBlockProof) yang menunjukkan cara pelanggaran dapat dicatat.

Produksi Blok Duplikat

Dalam peluncuran awalnya, program akan berfokus pada satu jenis perilaku berbahaya: mendeteksi kejadian produksi blok duplikat. Ini terjadi ketika leader mengirimkan dua atau lebih versi blok yang berbeda untuk slot yang sama, yang merupakan pelanggaran konsensus yang jelas dan objektif. 

Sebelumnya, pada September 2022, gangguan jaringan 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 yang berbeda.

Masalah ini telah diperbaiki. Kini, bahkan ketika operator menjalankan hot spare, klien validator menyertakan perlindungan untuk berhenti beroperasi jika beberapa instans terdeteksi. Karena itu, produksi blok duplikat hampir mustahil terjadi tanpa modifikasi perangkat lunak validator yang disengaja dan berbahaya.

Produksi blok duplikat adalah contoh pelanggaran protokol yang sulit dideteksi secara real-time, tetapi mudah diverifikasi setelah terjadi. Upaya mengoordinasikan respons sinkron, yaitu menghentikan jaringan untuk mengonfirmasi bahwa semua pihak mengamati duplikat tersebut, akan menimbulkan kompleksitas yang signifikan. Sebaliknya, menangani deteksi dan slashing secara retroaktif jauh lebih praktis.

Bukti blok duplikat yang dikirimkan mencakup dua shred yang saling bertentangan untuk slot yang sama, dan keduanya ditandatangani oleh validator yang sama. Program slashing memverifikasi bukti dengan memastikan shred tersebut membentuk bukti blok duplikat yang valid, mengonfirmasi bahwa keduanya berasal dari slot yang sama dan ditandatangani dengan benar oleh validator pelanggar. Logika ini mencerminkan pendekatan yang digunakan dalam protokol gossip Solana untuk menangani bukti blok duplikat dalam proses pemilihan fork.

struct DuplicateBlockProofData {
  shred1_length: u32      // Unaligned four-byte little-endian unsigned integer,
  shred1: &[u8]           // `shred1_length` bytes representing a shred,
  shred2_length: u32      // Unaligned four-byte little-endian unsigned integer,
  shred2: &[u8]           // `shred2_length` bytes representing a shred,
}

Pelapor membuat bukti dan menyimpannya dalam buffer account on-chain, lalu mengirimkan transaksi ke program slashing di alamat `S1ashing11111111111111111111111111111111111` yang mereferensikan buffer account tersebut. Setelah bukti berhasil diverifikasi, hasilnya disimpan di Program Derived Address (PDA) `report_account` milik program Slashing untuk referensi mendatang. Hal ini memudahkan pembuatan dasbor yang menampilkan data terkait slashing hanya dengan menjalankan panggilan getProgramAccounts pada program slashing. Validator dapat menggunakannya untuk memeriksa apakah mereka telah dilaporkan melakukan pelanggaran dan mengambil tindakan korektif sesuai kebutuhan.

Anza diperkirakan akan merilis alat yang memungkinkan pengamatan peristiwa tersebut, pembuatan bukti, dan pengiriman bukti secara on-chain. Kemungkinan akan ada beberapa implementasi, termasuk versi yang ditanamkan dalam perangkat lunak validator. Hanya satu peserta jujur yang perlu melaporkan pelanggaran dalam satu epoch karena setiap kombinasi unik antara pelanggar dan slot hanya dapat dilaporkan sekali. Program memverifikasi apakah laporan untuk slot dan pelanggar yang sama sudah ada. Jika laporan yang cocok ditemukan, pengiriman baru akan ditolak. Laporan dapat dikirimkan hingga satu epoch setelah pelanggaran terjadi berdasarkan slot tempat pelanggaran tersebut berlangsung (yaitu hingga 432.000 slot kemudian, sebagaimana dilacak oleh sysvar `Clock`).

Reward Pelapor Pelanggaran

Pertanyaan umum dalam desain slashing adalah apakah pihak yang melaporkan pelanggaran (yaitu whistleblower) harus mendapatkan reward. Meski pemberian reward kepada whistleblower tampak sebagai mekanisme insentif yang sederhana, pendekatan ini menghadirkan sejumlah tantangan penting.

Di Solana, tempat leader mengendalikan penyertaan transaksi, reward whistleblower menciptakan risiko frontrunning. Misalnya, validator mengirimkan bukti slashing yang valid kepada leader blok saat ini. Dalam kasus tersebut, leader dapat menyalin bukti itu, mengirimkannya sendiri, dan menyensor transaksi asli sehingga dapat mengambil reward tanpa melakukan pekerjaannya. Hal ini merusak model insentif dan membuka peluang penyalahgunaan.

Ethereum menawarkan reward kecil bagi whistleblower: 1/512 dari saldo efektif validator yang terkena slashing. Untuk validator dengan saldo penuh 32 ETH, jumlahnya setara dengan 0,0625 ETH. Reward tersebut dicetak sebagai ETH baru, tetapi diimbangi oleh jumlah lebih besar yang dibakar dari stake validator yang terkena slashing. Nilainya sengaja dibuat rendah karena ditujukan untuk mendorong integritas dan partisipasi jujur, bukan perilaku oportunistis yang didorong oleh keuntungan.

Pelanggaran Voting

Versi mendatang dari Program Slashing diperkirakan akan memperluas dukungan untuk berbagai jenis pelanggaran voting, seperti pelanggaran lockout dan pelanggaran switching proof.

Pelanggaran lockout terjadi ketika validator memberikan suara pada dua fork terpisah tanpa menunggu waktu yang sesuai hingga tower lockout-nya berakhir. Dalam algoritma konsensus Solana saat ini, TowerBFT, setelah validator memberikan suara untuk fork tertentu pada suatu slot, validator tersebut tidak dapat memberikan suara pada fork pesaing selama jangka waktu tertentu karena "terkunci". Jika validator kemudian memberikan suara untuk fork lain sebelum periode lockout-nya berakhir, validator tersebut melanggar aturan lockout.

Bot Votalizer, yang dikembangkan oleh pendiri bersama Solana Michael Vines, saat ini beroperasi di Discord Solana Tech dan melacak pelanggaran lockout ketika terjadi di seluruh jaringan. Dalam praktiknya, validator jarang melakukan pelanggaran tersebut secara tidak sengaja karena tindakan itu biasanya memerlukan modifikasi klien validator secara sengaja. Perlindungan bawaan memastikan klien mengambil vote on-chain terbarunya dan mencegah tindakan yang akan mengakibatkan pelanggaran lockout.

Meskipun pelanggaran lockout disebutkan secara eksplisit dalam SIMD Slashing dan dokumentasi awal sebagai contoh pelanggaran voting yang mungkin ditangani oleh program slashing, pembaruan konsensus Alpenglow yang direncanakan akan menghapus Tower BFT sehingga konsep lockout tidak lagi ada. Karena itu, pelanggaran voting diperkirakan baru akan diperkenalkan setelah Alpenglow diluncurkan.

Pelanggaran voting Alpenglow yang lebih baru dan dapat dideteksi oleh rancangan program slashing mungkin mencakup tindakan seperti mengirimkan vote yang saling bertentangan untuk slot yang sama, misalnya memberikan `NotarVote` dan `SkipVote` sekaligus.

Jenis Pelanggaran Mendatang

Slashing terprogram harus dikaitkan dengan kejadian pelanggaran yang dapat diverifikasi dan tidak ambigu. Sayangnya, hal ini membuat penegakan terhadap masalah yang lebih subjektif atau sistemis, seperti produksi blok lambat yang disengaja atau bentuk ekstraksi MEV yang merugikan, menjadi jauh lebih sulit.

Di berbagai jaringan blockchain sejenis, jenis perilaku yang biasanya mengakibatkan slashing berbeda-beda menurut protokol. Contoh umumnya meliputi:

• Penandatanganan Ganda: Menghasilkan dua blok yang saling bertentangan pada ketinggian atau slot yang sama.
• Downtime: Menjadi offline dan gagal berpartisipasi dalam konsensus.
• Surround Voting: Memberikan vote yang bertentangan dengan vote sebelumnya untuk mencoba memanipulasi atau mengganggu kestabilan jaringan.

Sebuah proposal slashing baru, yang diajukan tahun lalu oleh 0xIchigo dari Helius, menyarankan hukuman terhadap validator dalam supermajoritas yang tidak berpartisipasi dalam pemungutan suara tata kelola formal untuk mendorong keterlibatan yang lebih besar. Meskipun pendekatan ini memenuhi persyaratan untuk dapat diverifikasi secara objektif, beberapa komentator menyampaikan kekhawatiran. Sebagian menunjukkan bahwa batasan hukum dapat menghalangi validator tertentu untuk memberikan suara. Yang lain berpendapat bahwa slashing harus dibatasi secara ketat pada perilaku yang menimbulkan ancaman langsung terhadap keamanan atau integritas jaringan.

Penerapan Hukuman

Setelah Solana memiliki mekanisme on-chain yang andal untuk melaporkan dan memverifikasi pelanggaran yang dapat dikenai slashing, prioritas berikutnya adalah penerapan ekonomi slashing dengan menetapkan parameter dan formula hukuman yang tepat untuk berbagai jenis pelanggaran.

Pedoman masih terus dibahas secara aktif. Konten dalam bagian ini mencerminkan proposal saat ini yang ditujukan untuk memberikan informasi, mendorong dialog, dan berkembang berdasarkan masukan komunitas. Karena keputusan ini secara langsung memengaruhi aspek ekonomi pengoperasian validator Solana, setiap perubahan akan melalui perdebatan publik komunitas dan harus disetujui melalui proses tata kelola formal.

Saat menentukan hukuman slashing, prinsip utamanya adalah menghindari hukuman yang terlalu berat terhadap kesalahan operator yang jarang dan hanya terjadi sekali. Idealnya, sistem hukuman harus memiliki batas toleransi untuk insiden ringan yang tidak memengaruhi konsensus, disertai perlindungan yang sesuai, alih-alih menerapkan hukuman berat atas kesalahan yang jujur.

Pertimbangan saat ini untuk batas toleransi ini adalah garis Nakamoto Coefficient (NC), yang ditetapkan pada tingkat stake validator terkecil dalam superminoritas (yaitu sekitar 1% dari stake). 

Dalam fungsi yang diusulkan, yang menentukan jumlah setiap delegasi yang dikenai slashing per vote account, tidak ada stake yang dikenai slashing jika total stake yang melakukan pelanggaran berada di bawah garis NC. Sebaliknya, jika konsensus terancam, yang berarti lebih dari sepertiga total stake terlibat dalam pelanggaran, protokol harus merespons dengan tegas dengan mengenakan slashing terhadap 100% stake pelanggar.

Untuk kasus di antara kedua titik ekstrem tersebut, proposal saat ini memperkenalkan fungsi hukuman kuadratik dengan tingkat pertumbuhan lambat. Formula yang digunakan untuk menghitung proporsi stake yang akan dikenai slashing untuk setiap vote account adalah sebagai berikut:

v = vote account yang dapat dikenai slashing

TSS = Total Stake yang Dapat Dikenai Slashing

TS = Total Stake

Garis NC = Garis Nakamoto Coefficient

Dengan formula ini, persentase stake validator pelanggar yang akan dikenai slashing dapat dihitung sebagai berikut:

• 1,2% ketika 4,66% stake melakukan pelanggaran (yaitu (3 * (0,0466 - 0,01) / 1)²)
• 7,3% ketika 10% stake melakukan pelanggaran (yaitu (3 * (0,1 - 0,01) / 1)²)

Bagan di bawah menggambarkan kurva yang diusulkan beserta dua alternatifnya (agresif dan linear).

Total stake yang dapat dikenai slashing (TSS) dihitung menggunakan bobot berdasarkan jenis pelanggaran. Pelanggaran voting diberi bobot hukuman 1 karena tingkat keparahannya lebih rendah. Pelanggaran blok duplikat diberi bobot 10 karena dianggap lebih berat.

Keunggulan utama hukuman slashing kuadratik yang saling berkorelasi, seperti yang saat ini diusulkan, adalah kemampuannya mendorong pihak yang menjalankan beberapa validator, seperti bursa atau penyedia staking-as-a-service, untuk mempertahankan infrastruktur independen berkualitas tinggi guna meminimalkan risiko kegagalan luas yang saling berkorelasi.

Alternatif untuk Slashing Tradisional

Slashing terhadap stake yang didelegasikan menimbulkan pertanyaan penting mengenai keadilan dan akuntabilitas. Dalam model staking saat ini, sebagian besar, bahkan mungkin seluruh, stake pada mayoritas validator nonprivat merupakan hasil delegasi. Artinya, ketika slashing terjadi, biasanya delegatorlah yang menanggung sebagian besar hukuman, bukan operator validator yang melakukan pelanggaran. Bahkan staker yang cermat dan memilih validator bereputasi baik dapat terkena slashing tanpa kesalahan mereka sendiri jika validator bertindak jahat atau salah mengonfigurasi node-nya.

Untuk mengatasi ketidakseimbangan ini, beberapa desain slashing alternatif telah diusulkan. Salah satu pendekatannya adalah mewajibkan semua validator mempertahankan tingkat minimum self-stake. Hal ini memastikan operator memiliki kepentingan finansial langsung dan tidak dapat membebankan seluruh biaya slashing kepada delegator mereka. Versi yang lebih ketat dari pendekatan ini adalah hanya mengenakan slashing terhadap self-stake, sekaligus secara otomatis menghentikan staking semua delegator yang terkait dengan validator yang terkena slashing. Delegator akan kehilangan reward, tetapi tetap mempertahankan pokok mereka sehingga dapat mengalokasikan kembali stake ke validator lain dengan dampak jangka panjang yang minimal.

Pendekatan lain adalah membekukan account selama periode tertentu. Selama periode tersebut, account tidak dapat memperoleh reward, mengubah kepemilikan, atau menarik dana. Durasi pembekuan akan meningkat sesuai tingkat keparahan pelanggaran. Sebagai alternatif, protokol dapat mengenakan slashing terhadap reward mendatang, sehingga mengurangi penghasilan validator dan delegatornya selama jangka waktu tertentu tanpa menyentuh pokok stake.

Sebagian pihak mengusulkan agar stake yang terkena slashing didistribusikan kembali kepada validator jujur sebagai bentuk penguatan positif, bukan dibakar. Namun, pembakaran SOL pada dasarnya memberikan hasil serupa karena mengurangi total pasokan sehingga meningkatkan porsi relatif kepemilikan jaringan bagi setiap holder.

Pertimbangan

Penerapan slashing di Solana membawa beberapa implikasi penting. Dalam bagian ini, kami membahas dua area penting: periode cooldown serta risiko, asuransi, dan beban operasional yang ditimbulkannya bagi peserta ekosistem.

Periode Cooldown

Kerentanan utama dalam model staking saat ini muncul ketika validator melakukan pelanggaran yang dapat dikenai slashing, tetapi menghentikan staking sebelum pelanggaran diamati dan dilaporkan. Tanpa mekanisme untuk menunda penarikan, pelaku jahat berpotensi memanfaatkan kesenjangan waktu ini untuk menghindari hukuman.

Periode cooldown yang tetap membuat stake dapat dikenai slashing bahkan setelah dinonaktifkan akan memitigasi masalah ini. Cooldown ini harus lebih lama dari waktu terburuk yang diperlukan validator atau pengamat eksternal untuk mendeteksi dan mengoordinasikan respons slashing, terutama dalam kondisi adversarial seperti serangan DDoS tingkat jaringan atau kolusi antarvalidator berbahaya. Dalam praktiknya, periode cooldown harus berlangsung selama beberapa hari.

Ketergantungan Solana pada snapshot stake yang telah dihitung sebelumnya memperburuk masalah ini. Beberapa komponen protokol penting, termasuk leader schedule dan aturan pemilihan fork, bergantung pada nilai stake yang dihitung lebih awal. Akibatnya, stake yang telah dinonaktifkan atau bahkan ditarik sepenuhnya masih dapat memengaruhi konsensus.

Misalnya, leader schedule ditentukan dari snapshot stake sebelumnya yang diambil satu epoch lebih awal pada batas epoch. Hal ini menciptakan jendela waktu ketika validator dapat melakukan pelanggaran yang dapat dikenai slashing setelah menonaktifkan stake pada epoch sebelumnya dan menariknya pada awal epoch saat ini. Ketika pelanggaran terungkap, tidak ada lagi stake aktif yang dapat dihukum.

Salah satu solusinya adalah memperkenalkan periode cooldown tambahan ketika stake masih dapat dikenai slashing, tetapi tidak lagi diperhitungkan dalam bobot stake protokol. Staker yang menonaktifkan stake mereka pada epoch N baru dapat menarik stake pada awal epoch N+3. Meskipun meningkatkan keamanan, penundaan ini menciptakan pengalaman pengguna yang buruk karena memaksa staker menunggu tambahan ~2-4 hari sebelum dapat menarik stake sepenuhnya. Salah satu cara mengatasinya adalah memperpendek epoch agar penundaan waktu nyata untuk penghentian staking tetap serupa dengan standar saat ini. Namun, pengurangan durasi epoch dapat menimbulkan implikasi protokol yang tidak terduga dan perlu dinilai dengan cermat.

Risiko, Asuransi, dan Beban Operasional

Penerapan slashing di Solana membawa implikasi bagi berbagai peserta ekosistem, terutama pihak yang menyimpan, mengelola, atau membangun produk keuangan di atas SOL yang di-stake. Bahkan sekadar potensi slashing dapat menghadirkan risiko finansial, kompleksitas operasional, dan kekhawatiran reputasi, terutama bagi institusi yang beroperasi di bawah batasan fidusia atau regulasi. Risiko tersebut dapat ditangani melalui perlindungan seperti asuransi atau obligasi.

Pemangku kepentingan yang berpotensi terdampak meliputi:

• Protokol liquid staking
• Stake pool
• Penyedia staking kustodial
• Protokol restaking
• Protokol DeFi
• ETF staking

Bagi sebagian entitas tersebut, peristiwa slashing dapat menimbulkan konsekuensi berantai. Misalnya, liquid staking token (LST) didukung oleh asumsi bahwa validator yang mendasarinya beroperasi dengan aman. Jika validator terkena slashing, hal itu dapat memicu perubahan harga LST yang tajam atau, dalam kasus ekstrem, depeg jika kepercayaan terhadap validator tempat SOL yang mendasarinya di-stake runtuh. Hal ini dapat memicu likuidasi jika LST digunakan sebagai jaminan dalam protokol pinjaman.

Penyedia staking di ekosistem lain umumnya menawarkan asuransi slashing untuk memitigasi risiko tersebut. Di Ethereum, misalnya, banyak penyedia menawarkan perlindungan terjangkau terhadap kerugian akibat slashing, dengan tingkat perlindungan yang berbeda sesuai paket pertanggungan.

Risiko slashing juga menghadirkan tanggung jawab operasional baru di seluruh rantai nilai staking. Pihak yang terdampak meliputi:

• Operator layanan staking, yang kini harus memantau perilaku validator dan memitigasi risiko secara proaktif
• Platform kustodial dan bursa kripto, yang bergantung pada operator pihak ketiga dan mungkin perlu menyeleksi serta mendiversifikasi kumpulan validator mereka
• Manajer aset institusional, yang mungkin mencari perlindungan kerugian sendiri untuk melindungi dari kerugian terkait slashing yang disebabkan oleh operator eksternal

Perbandingan dengan Jaringan Sejenis

Bagian ini membahas penerapan slashing pada jaringan Proof of Stake sejenis seperti Ethereum dan Cosmos. Jaringan ini telah menerapkan slashing terprogram selama bertahun-tahun sehingga menyediakan data dunia nyata yang berharga mengenai frekuensi peristiwa slashing serta dampaknya terhadap keamanan jaringan dan perilaku validator.

Ethereum

Protokol Proof of Stake Ethereum, yang diperkenalkan bersama peluncuran Beacon Chain pada Desember 2020, telah menyertakan slashing sebagai mekanisme penegakan inti sejak hari pertama. Ethereum menetapkan empat pelanggaran spesifik yang dapat dikenai slashing, yang semuanya berpusat pada equivocation:

• Mengusulkan beberapa blok untuk slot yang sama
• Mengirimkan attestation yang saling bertentangan untuk target checkpoint yang sama
• Memberikan attestation untuk head block yang berbeda dengan source checkpoint dan target checkpoint yang sama
• Membuat dua attestation ketika salah satunya “mengelilingi” yang lain dalam hal source vote dan target vote

Setiap pelanggaran tersebut memiliki struktur hukuman yang sama. Ketika validator terkena slashing, hukuman langsung sebesar 1/32 dari saldo efektifnya diterapkan dan dibatasi hingga 1 ETH karena saldo efektif maksimum adalah 32 ETH. Validator kemudian dikeluarkan secara paksa dari kumpulan aktif dan ditempatkan dalam antrean keluar selama sekitar 36 hari.

Selama periode ini, validator tidak aktif dan tidak dapat menarik dana. Validator terus kehilangan reward yang seharusnya diperoleh jika aktif sehingga secara efektif mengalami biaya peluang yang berkelanjutan. Setelah 18 hari, hukuman korelasi tambahan diterapkan dan dirancang untuk meningkat sebanding dengan jumlah validator yang terkena slashing dalam jangka waktu 36 hari. Jika hanya beberapa validator yang terkena slashing, hukumannya ringan. Namun, dalam peristiwa slashing massal, baik akibat perilaku menyimpang yang terkoordinasi maupun kegagalan infrastruktur bersama, hukuman akan meningkat drastis dan dalam skenario terburuk dapat mengakibatkan hilangnya hampir seluruh saldo yang di-stake oleh validator.

Meskipun menjadi bagian inti protokol Ethereum, slashing sangat jarang terjadi dalam praktiknya. Hingga Mei 2025, hanya 484 validator, kurang dari 0,05% dari total kumpulan validator, yang terkena slashing dalam 131 insiden. Insiden tersebut sering kali berasal dari satu kesalahan yang memengaruhi beberapa validator dan biasanya disebabkan oleh kesalahan operator atau bug perangkat lunak, bukan niat jahat.

Peristiwa slashing terbesar terjadi pada November 2023, ketika Bitcoin Suisse mengalami slashing terhadap 100 validator akibat pelanggaran terkait inaktivitas, dan masing-masing kehilangan 1 ETH.

Hingga saat ini, tidak ada insiden slashing di Ethereum yang mengancam integritas protokol secara keseluruhan. Hal ini menunjukkan bahwa meskipun slashing merupakan pencegah penting, penerapannya jarang terjadi dan ekosistem validator sebagian besar telah menginternalisasi perilaku yang diperlukan untuk menghindari hukuman tersebut.

Cosmos

Cosmos dan chain berbasis Cosmos SDK, seperti Cosmos Hub, menerapkan slashing sebagai mekanisme keamanan bawaan yang menargetkan dua kesalahan utama: penandatanganan ganda dan downtime berkepanjangan. Aturan slashing ini digunakan untuk menegakkan properti keamanan dan liveness protokol.

Validator yang menandatangani dua blok berbeda pada ketinggian yang sama akan langsung dihukum. Setiap peserta dapat mengirimkan bukti pelanggaran secara on-chain. Setelah diverifikasi, 5% token yang di-stake oleh validator secara otomatis dikenai slashing dan validator ditempatkan dalam status tombstoned, yang berarti dihapus secara permanen dari kumpulan validator aktif dan tidak dapat masuk kembali. Setelah berstatus tombstoned, validator dan delegatornya harus menunggu periode unbonding berakhir sebelum stake mereka dapat didelegasikan kembali. Meskipun operator validator yang berstatus tombstoned dapat meluncurkan ulang menggunakan kunci baru, mereka harus membangun kembali reputasi dan delegasinya dari awal.

Cosmos juga menegakkan liveness melalui slashing otomatis untuk downtime berkepanjangan. Jika validator menandatangani kurang dari 5% dari 10.000 blok terakhir, validator dianggap tidak aktif dan dikenai slashing sebesar 0,01% dari stake. Meski relatif ringan, penegakan ini ketat dan tidak dapat dinegosiasikan sehingga memastikan validator mempertahankan uptime dan berpartisipasi secara andal dalam konsensus.

Menariknya, beberapa validator memilih menerima hukuman ringan ini sebagai biaya untuk menutup operasi secara sukarela karena menganggap kerugiannya tidak signifikan.

Meskipun jaringan Cosmos SDK menggunakan parameter slashing default yang sama, setiap chain dapat mengubah atau memperluas aturan tersebut agar mencerminkan asumsi keamanan dan model risikonya sendiri. Fleksibilitas ini memungkinkan setiap jaringan menyesuaikan sistem slashing berdasarkan ukuran kumpulan validator, tujuan desentralisasi, atau toleransi kesalahan yang diharapkan. Aktivitas slashing di 57 mainnet berbasis Cosmos SDK memberikan gambaran penegakan yang lebih luas di seluruh ekosistem:

• 12.143 slashing terkait downtime
• 111 slashing akibat penandatanganan ganda
• 326 pelanggaran lainnya
• Total 12.580 insiden slashing

Angka tersebut menunjukkan bahwa meskipun penandatanganan ganda jarang terjadi dan dihukum berat, slashing akibat downtime lebih sering terjadi dan terutama dianggap sebagai biaya operasional rutin. 

Kesimpulan

Slashing tetap menjadi salah satu topik yang paling diperdebatkan dan sarat emosi dalam industri blockchain. Setiap kali muncul bentuk baru pelanggaran validator atau ketidakselarasan insentif, seruan untuk menerapkan slashing segera mengikuti. Alasannya mudah dipahami. Secara sekilas, slashing tampak sebagai pencegah yang kuat dengan menawarkan mekanisme on-chain langsung untuk menghukum pelaku jahat dan menjaga integritas jaringan.

Namun, seperti yang ditunjukkan artikel ini, slashing terprogram bukan solusi universal untuk pelanggaran. Efektivitasnya bergantung pada pelanggaran yang tidak ambigu dan dapat dibuktikan, dua kondisi yang tidak selalu mudah dipenuhi dalam situasi dunia nyata yang kompleks. Slashing dalam kasus ketika bukti tidak jelas atau terbuka untuk penafsiran berisiko menghukum pihak yang jujur, mengganggu kepercayaan, dan berpotensi menimbulkan lebih banyak kerugian daripada pelanggaran yang hendak dicegah.

Dapat dikatakan bahwa manfaat terbesar bentuk slashing otomatis bagi jaringan adalah dampak psikologisnya terhadap pemangku kepentingan. Bahkan sekadar kemungkinan mengalami kerugian ekonomi akibat pelanggaran apa pun, betapa pun jarangnya, dapat mendorong staker yang menghindari risiko untuk menyebarkan delegasi mereka ke beberapa validator sekaligus memotivasi operator agar berinvestasi dalam infrastruktur yang beragam dan independen.

Referensi Lanjutan

• Slashing: Solusi Universal atau Kotak Pandora? - Tim Roughgarden, Accelerate Conference
• Batas Ekonomi Konsensus Permissionless - Eric Budish, Andrew Lewis-Pye, Tim Roughgarden 
• Liveness yang Akuntabel - Andrew Lewis-Pye, Joachim Neu, Tim Roughgarden, Luca Zanolini