Cosmos Interchain Security: Provider, Consumer, Reward, dan Slashing

Interchain Security (ICS) menghubungkan chain Cosmos yang terpisah melalui protokol Inter-Blockchain Communication (IBC). Chain provider mengelola set validator, sedangkan chain consumer memakai validator provider yang memenuhi syarat untuk membuat dan mengonfirmasi bloknya sendiri. Kedua chain tetap memiliki state machine, buku besar, biaya, token, tata kelola, dan aturan aplikasi masing-masing.

“Berbagi keamanan” tidak berarti koin delegator berpindah ke consumer. ATOM yang didelegasikan tetap di-bond menurut aturan staking provider. Consumer mendapatkan partisipasi validator yang didukung stake provider dan dapat melaporkan bukti pelanggaran validator tertentu kepada provider. Karena itu, saldo wallet, token consumer, dan stake yang di-bond pada provider adalah tiga hal berbeda.

ICS juga bukan sekadar jembatan token IBC. IBC menyediakan komunikasi terautentikasi antar-chain, sedangkan ICS memakai aplikasi cross-chain validation khusus untuk menyampaikan perubahan set validator dan bukti pelanggaran. Transfer token dapat memakai ICS-20 tanpa berbagi set validator. Sebaliknya, berbagi validator tidak otomatis membuat semua aplikasi atau token consumer aman.

Ikhtisar Interchain Security · Istilah Interchain Security

Consumer tidak harus menyalin seluruh set validator provider. Dengan Partial Set Security (PSS), consumer dapat memilih subset. Konfigurasi Top N memilih validator berdasarkan persentase tertentu dari voting power provider. Konfigurasi opt-in membiarkan validator yang memenuhi syarat memilih sendiri untuk melayani consumer tertentu. Konfigurasi chain saat ini menentukan aturan yang berlaku.

Pengaturan power shaping dapat mengecilkan atau menyeimbangkan ulang set consumer. Misalnya, chain dapat membatasi jumlah validator, batas voting power seorang validator pada consumer, atau menggunakan allowlist dan denylist. Pengaturan ini mengubah set validator consumer, bukan distribusi stake yang di-bond pada provider.

Chain Top N biasanya perlu persetujuan tata kelola provider karena sebagian validator mungkin diwajibkan ikut. Chain opt-in dapat diluncurkan tanpa memaksa validator berpartisipasi. Jangan menyimpulkan jalur peluncuran hanya dari sebutan “chain Cosmos”. Periksa chain ID dan consumer ID, status peluncuran, aturan Top N atau opt-in, parameter power shaping, serta proses tata kelola provider saat ini; fitur dan dokumentasi dapat berubah.

Partial Set Security · Power shaping · Permissionless ICS

Validator provider yang ikut consumer biasanya menjalankan node consumer terpisah dan mengikuti software serta petunjuk peluncurannya. Validator dapat menetapkan consensus key khusus untuk tiap consumer alih-alih memakai ulang key provider. Pemisahan key mengurangi kemungkinan key penandatangan provider terekspos jika node consumer diretas, tetapi tidak menghapus risiko operasional, software, atau penandatanganan.

Aturan partisipasi menentukan siapa yang harus menjalankan node consumer. Pada Top N, kewajiban dapat mengikuti voting power provider dan ambang batas yang ditetapkan. Pada opt-in, validator umumnya memilih sendiri. Batas power atau daftar validator dapat mengubah set akhirnya. Validator perlu memeriksa kelayakan, penetapan key, hash binary, waktu mulai, dan pemantauan untuk setiap consumer.

Delegator biasanya tidak menjalankan node consumer sendiri. Stake provider mereka mendukung validator yang mengambil pekerjaan tambahan, dan penalti consumer dapat berdampak pada stake itu. Jadi memeriksa identitas serta uptime validator di provider saja tidak cukup; aturan partisipasi dan pelanggaran untuk tiap consumer juga penting.

Pedoman validator dan urutan startup · Penetapan key

Jika stake atau kelayakan berubah di provider, set validator consumer mungkin perlu diperbarui. ICS mengirim perubahan set lewat kanal Cross-Chain Validation (CCV). Relayer membawa pesan antar-chain; setiap chain memeriksa bukti dan menerapkan perubahannya sendiri sesuai protokol. Relayer bukan validator consumer dan tidak menentukan tanda tangan mana yang sah.

Koordinasi ini dapat membuat waktu bergabung atau keluar lebih rumit dibandingkan chain mandiri. Desain CCV terdahulu menjelaskan paket perubahan set validator dan pemberitahuan maturity untuk melindungi proses unbonding lintas chain. Implementasi berkembang, sehingga penjelasan umum ICS tidak dapat menjanjikan tambahan waktu undelegasi provider yang seragam. Perilaku tepat bergantung pada versi protokol dan parameter chain.

Sebelum mengubah delegasi atau menarik stake, baca dokumentasi terbaru provider dan consumer, lalu periksa catatan unbonding yang masih tertunda. Bedakan periode staking normal dari koordinasi khusus ICS. Relayer yang terlambat atau client yang tertinggal juga dapat menunda paket tanpa mengubah aturan dasarnya.

Ikhtisar CCV dalam spesifikasi IBC · Pedoman validator

Consumer dapat mengirim bukti pelanggaran validator kepada provider. Dokumentasi ICS membedakan downtime dari equivocation seperti double signing. Aturan chain, versi protokol, dan parameter infraction consumer menentukan cara bukti diproses; tindakannya dapat berupa jail, pemotongan stake, atau keduanya.

Tidak ada satu tingkat hukuman yang berlaku untuk semua chain. Dokumentasi resmi saat ini juga tidak sepenuhnya selaras mengenai downtime: pedoman validator menggambarkan jail di provider tanpa slash untuk Hub, sedangkan halaman fitur slashing menjelaskan jail dan slash berdasarkan parameter consumer. Karena itu, jangan menyimpulkan akibat finansial hanya dari label “ICS”; periksa implementasi, konfigurasi, dan proses bukti chain yang dimaksud. Bukti double signing yang valid dapat menyebabkan slash, jail, dan tombstone di provider.

Jika stake provider dipotong, validator dan delegator dapat menanggung dampak ekonomi sesuai aturan staking provider. Jail dapat mengeluarkan validator dari set aktif provider dan akibatnya dari set consumer juga. Jangan anggap pelanggaran consumer hanya memengaruhi reward token consumer.

Slashing yang dipicu consumer · Pedoman validator Interchain Security

Consumer dapat mengirim bagian tertentu dari reward blok atau biaya kepada provider sebagai imbalan atas keamanan. Aset tersebut dikirim berkala melalui kanal transfer IBC. Provider hanya menerima denom yang masuk daftar izinnya, sedangkan kelayakan ditentukan aturan chain. Dokumentasi saat ini menyebut validator mungkin perlu berpartisipasi terus selama sejumlah epoch tertentu sebelum menerima reward; delegator kemudian dapat ikut sesuai aturan distribusi provider.

Contoh hipotetis sederhana: anggap consumer mencatat 12.000 unit biaya dan reward inflasi yang memenuhi syarat selama satu periode, lalu tata kelola menetapkan bagian provider sebesar 25%. Hitungannya menghasilkan 3.000 unit yang dikirim ke arah pool reward provider. Angka ini tidak menentukan nilai dolar, alokasi akhir per validator, waktu distribusi, atau imbal hasil mendatang. Jika ada batas voting power, bobot distribusi mungkin mengikuti voting power consumer setelah dibentuk, bukan voting power asli di provider.

Token reward bisa bergejolak, kurang likuid, atau mahal untuk diklaim. APY yang terlihat dapat mencampurkan asumsi tentang aktivitas consumer, porsi reward, validator yang memenuhi syarat, komisi, distribusi provider, denom yang diterima, dan lamanya opt-in. Perlakukan reward consumer sebagai arus protokol yang berubah-ubah, bukan APY terjamin atau kompensasi pasti atas risiko slash.

Aturan distribusi reward · Reward validator chain consumer

Menggunakan validator provider dapat membuat consumer lebih sulit diserang daripada hanya mengandalkan set validator baru yang kecil. Namun consumer tidak menjadi sama dengan provider. Consumer tetap memiliki software aplikasi, tata kelola, desain ekonomi, client dan kanal IBC, dependensi operasional, serta smart contract atau modulnya sendiri.

Set validator hanyalah salah satu bagian model keamanan. Subset consumer bisa lebih terkonsentrasi atau memiliki ketersediaan berbeda dari seluruh set provider. Masalah client atau relayer dapat menunda koordinasi; bug software consumer dapat merugikan chain meskipun validator provider bertindak benar. Tata kelola dapat mengubah parameter, sementara nilai token dapat turun terpisah dari mekanisme validasi.

Klaim “diamankan oleh Cosmos Hub” adalah awal pemeriksaan, bukan penilaian risiko lengkap. Tanyakan provider mana yang terlibat, validator mana yang ikut, bagaimana voting power mereka dibentuk, bukti apa yang dapat memicu slash, reward apa yang dikirim, dan bagaimana proses keluar atau peralihan. Keamanan bergantung pada konfigurasi dan periode operasional yang konkret.

Istilah dan varian keamanan Interchain · Tata kelola chain consumer

Mulailah dengan memastikan chain ID, consumer ID, dan provider yang tepat. Periksa apakah aturan Top N atau opt-in berlaku, apakah batas power atau daftar mengubah set validator, serta apakah daftar yang dipublikasikan mencerminkan pembaruan terbaru. Jumlah validator saja tidak menunjukkan distribusi voting power.

Jika Anda validator atau delegator, pastikan apakah validator harus opt-in, consensus key apa yang dipakai di consumer, binary mana yang dijalankan, dan bagaimana downtime atau double signing ditangani. Baca parameter jail dan slash yang aktif. Saat mendelegasikan, bedakan stake yang di-bond pada provider dari reward consumer yang ditampilkan wallet.

Terakhir, periksa daftar denom reward yang diterima, jumlah epoch untuk memenuhi syarat, aturan distribusi dan komisi, kewenangan tata kelola consumer, status client dan relayer, serta prosedur undelegasi atau changeover saat ini. Bandingkan dengan staking provider saja dan transfer token; ketiganya menjawab pertanyaan yang berbeda.

[Delegasi dan slashing Cosmos Hub](/learn/cosmos-staking-delegation-unbonding-slashing-validator-commission-explained) · [Transfer IBC dan risiko relayer](/learn/cosmos-ibc-transfer-clients-channels-packet-timeouts-relayer-risks-explained) · Staking kripto vs. pinjaman DeFi

Sumber primer: Ikhtisar Interchain Security; istilah; Partial Set Security; Power shaping; distribusi reward; slashing yang dipicu consumer; pedoman validator; spesifikasi CCV IBC.