---
title: "Nothing at Stake: ekuivokasi, slashing, finalitas, dan risiko kunci lama"
description: "Nothing at Stake adalah masalah insentif proof of stake ketika mendukung riwayat yang bersaing dapat memiliki biaya marjinal rendah. Analisis pesan yang dapat dikenai slashing, hasil ekspektasian, irisan kuorum, penegakan bukti, pilihan fork, dan asumsi subjektivitas lemah secara terpisah."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Nothing at Stake: ekuivokasi, slashing, finalitas, dan risiko kunci lama

> Hanya untuk tujuan edukasi; bukan merupakan nasihat investasi atau rekomendasi investasi. Investasi dapat mengakibatkan kerugian.

<a id="answer"></a>

## Jawaban langsung

Nothing at Stake adalah masalah insentif proof of stake: jika membuat tanda tangan tambahan berbiaya rendah dan protokol tidak membebankan biaya efektif atas dukungan yang tidak kompatibel, validator dapat memperoleh lebih banyak dengan membantu setiap riwayat yang bersaing daripada memilih satu. Jika banyak validator mengikuti insentif pribadi ini, fork dapat mempertahankan dukungan, konvergensi dapat melemah, dan penyerang dapat memperoleh tanda tangan yang mahal untuk direproduksi dalam proof of work.

Istilah tersebut tidak berarti bahwa setiap sistem proof of stake tidak memiliki anggaran keamanan atau bahwa setiap suara pada fork yang kalah merupakan pelanggaran. Modal terikat, imbalan yang terlewat, slashing, penundaan penarikan, aturan pilihan fork, dan aturan finalitas dapat mengubah hasil. Pesan bertanda tangan dan konflik yang dapat dihukum bergantung pada protokol dan versi; pembaruan suara biasa, pesan terlambat, atau fork jujur sementara dapat diizinkan.

Tiga pertanyaan harus dipisahkan. Pertama, dapatkah validator yang saat ini masih terikat melakukan ekuivokasi berbiaya rendah di antara cabang terbaru? Kedua, dapatkah bobot suara yang tidak tersedia atau berlawanan menghentikan kemajuan tanpa menciptakan dua riwayat final? Ketiga, dapatkah kunci lama membuat riwayat alternatif panjang setelah stake dapat ditarik? Risiko insentif dan konsensus ini saling terkait, tetapi bukti, ambang, dan pertahanannya berbeda.

Ethereum merupakan contoh yang berguna, bukan templat universal. Spesifikasi konsensusnya membuat dua proposal berbeda untuk slot yang sama dapat dikenai slashing, demikian pula atestasi berupa pemungutan suara ganda atau surround vote. Pilihan fork dapat mengabaikan pengaruh validator yang berekuivokasi, sedangkan finalitas menggunakan suara supermayoritas dan penalti. Keluarga proof of stake lain menggunakan pemilihan pemimpin, pilihan rantai, checkpoint, asumsi ketersediaan, atau model keamanan formal yang berbeda.

<a id="mechanism"></a>

## Cara menganalisis Nothing at Stake

1. **Tetapkan konteks protokol.** Catat `protocol`, `version`, `network`, `epoch`, `slot`, `validator set`, dan waktu observasi. Identifikasi `fork choice`, `finality gadget`, `reward rule`, `penalty rule`, serta `withdrawal delay` yang aktif; label “PoS” tidak menentukan satu pun di antaranya.
2. **Definisikan tindakan bertanda tangan.** Daftarkan proposal blok, atestasi, prevote, precommit, sertifikat, atau pesan lain beserta domainnya. Bedakan dua pesan yang sekadar mendukung turunan berbeda dari `double proposal`, `double vote`, atau `surround vote` yang secara formal dapat dikenai slashing menurut aturan yang dirujuk.
3. **Modelkan hasil tanpa penalti.** Perkirakan probabilitas cabang, imbalan cabang kanonis, biaya tambahan penandatanganan dan propagasi, suap, peluang yang terlewat, serta imbalan pesan yang bertentangan. Bandingkan `EV(honest)` dengan `EV(equivocate)` alih-alih menganggap penggunaan listrik rendah membuktikan penyimpangan menguntungkan.
4. **Modelkan kerugian yang dapat ditegakkan.** Identifikasi saldo terikat, probabilitas deteksi, jangka validitas bukti, jalur pelaporan, risiko penyertaan dan sensor, penalti awal, penalti terkorelasi, pengeluaran, waktu penarikan, serta pendapatan masa depan yang hilang. Penalti dalam dokumentasi tidak setara dengan pelaksanaan `slashing evidence` yang andal.
5. **Pisahkan pilihan fork dari finalitas.** Rekonstruksi pengaruh suara terbaru, ekuivokasi, dan waktu pesan terhadap head, lalu hitung bobot yang diperlukan untuk membenarkan atau memfinalkan checkpoint. Analisis `safety threshold` dan `liveness threshold` secara terpisah: menahan suara dapat menghentikan finalitas tanpa menghasilkan finalitas yang bertentangan.
6. **Uji asumsi kunci lama dan sinkronisasi.** Tentukan kapan stake yang sudah keluar tidak lagi dapat dihukum, riwayat final mana yang ditolak node online, cara node baru atau lama offline memperoleh `weak-subjectivity checkpoint`, serta cara memverifikasi kebaruan dan asalnya. Ini adalah masalah long-range, bukan sekadar pemungutan suara ganda terbaru.
7. **Uji ketahanan operasi dan kontrol.** Uji kunci duplikat, node failover, penanda tangan jarak jauh, rollback basis data, bug klien, hosting terkorelasi, pool staking, kustodi terdelegasi, partisi, serangan eclipse, dan sensor bukti. Hitung jalur kontrol dan perangkat lunak yang independen, bukan hanya pengenal validator.

Hasilnya harus berupa penilaian insentif dan konsensus yang mencantumkan versi, bukan putusan berdasarkan istilah. Tunjukkan pesan persis yang dapat ditandatangani kunci, bukti konflik yang dapat diverifikasi secara objektif, masa jaminan masih dapat ditagih, ambang yang melindungi keamanan, ambang yang memungkinkan kemajuan, dan status tepercaya yang dibutuhkan node saat sinkronisasi.

<a id="example"></a>

## Contoh perhitungan

### 1. Strategi tanpa penalti dapat menguntungkan kedua cabang

Misalkan tepat satu dari dua cabang menjadi kanonis: cabang A dengan probabilitas `0.55` dan cabang B dengan probabilitas `0.45`. Tanda tangan pada cabang kanonis menghasilkan `1.00 unit`, sedangkan tanda tangan pada cabang yang kalah tidak menghasilkan apa pun. Dengan mengabaikan semua penalti dan biaya operasi tambahan, hanya menandatangani A menghasilkan `EV(A only) = 0.55 * 1.00 = 0.55 units`. Menandatangani keduanya menghasilkan `EV(sign both) = (0.55 + 0.45) * 1.00 = 1.00 unit`.

Perhitungan ini menggambarkan masalah insentif, bukan perkiraan imbal hasil staking. Asumsinya adalah tanda tangan pada cabang kanonis mendapat imbalan siapa pun pemenangnya, tindakan diizinkan atau penalti tidak ditegakkan, hasil cabang saling eksklusif, dan validator tidak mengalami kerugian harga, reputasi, latensi, atau pendapatan masa depan.

### 2. Slashing yang dapat ditegakkan dapat membalikkan hasil

Pertahankan imbalan bruto kanonis `1.00 unit` dan tambahkan suap `0.02 unit` untuk ekuivokasi. Misalkan bukti valid mencapai mekanisme penalti dengan probabilitas `0.80` dan total kerugian yang dapat diatribusikan adalah `5.00 units`. Hasil yang disederhanakan adalah `EV(equivocate) = 1.00 + 0.02 - (0.80 * 5.00) = -2.98 units`, lebih rendah daripada `0.55 units` dari hanya menandatangani A.

Hasil berubah jika deteksi, penyertaan, jaminan yang dapat ditagih, atau pendapatan masa depan berbeda. Penalti nyata dapat bergantung pada saldo efektif, pelanggaran terkorelasi, waktu, dan status protokol. Operator harus memodelkan distribusi hasil dan memastikan jalur implementasinya; mengalikan tiga angka pilihan tidak membuktikan sistem yang sudah diterapkan selaras dengan insentif.

### 3. Irisan kuorum melindungi keamanan tetapi dapat mengekspos liveness

Pertimbangkan `100 stake units` dan aturan yang memerlukan sedikitnya `67 units` untuk suara finalitas. Dua kuorum semacam itu beririsan setidaknya `67 + 67 - 100 = 34 units`. Karena itu, dua finalisasi yang bertentangan mengharuskan setidaknya 34 unit berpartisipasi dalam kedua sertifikat kuorum; protokol yang dapat dipertanggungjawabkan dapat membuat irisan tersebut terbukti layak dikenai slashing.

Ambang yang sama memiliki implikasi liveness berbeda. Jika `34 units` menahan suara valid, hanya `66 units` yang tersisa, kurang dari 67, sehingga finalitas dapat terhenti. Ke-34 unit itu tidak memfinalkan dua cabang sendiri. Kegagalan keamanan, bukti yang dapat diatribusikan, dan kegagalan kemajuan tidak boleh digambarkan sebagai peristiwa yang sama.

### 4. Kunci lama menciptakan masalah sinkronisasi berbeda

Misalkan node online telah memfinalkan checkpoint `epoch 39,900`, sedangkan node baru tidak memiliki status tepercaya. Penyerang memperoleh kunci yang mengendalikan cukup stake sekitar `epoch 10,000` setelah validator tersebut keluar dan jaminannya tidak lagi dapat ditagih, lalu membuat riwayat alternatif hingga `epoch 40,000`. Tanda tangan historis berbiaya rendah relevan, tetapi slashing validator terbaru mungkin tidak lagi mencegah kunci lama tersebut.

Node online menolak riwayat yang bertentangan dengan pandangan finalnya. Node baru membutuhkan checkpoint terbaru yang diautentikasi atau aturan protokol setara untuk membedakan riwayat sebelum melanjutkan verifikasi objektif. Karena itu, subjektivitas lemah dan waktu penarikan termasuk dalam peninjauan, tetapi tetap terpisah secara analitis dari ekuivokasi langsung oleh validator terikat.

<a id="risks"></a>

## Risiko dan kegagalan peninjauan

### Kesalahan protokol dan bukti

- Menyebut setiap suara pada fork nonkanonis dapat dikenai slashing tanpa memeriksa bidang bertanda tangan dan domain yang tepat.
- Memperlakukan fork, reorganisasi, proposal terlewat, suara terlambat, dan ekuivokasi terbukti sebagai peristiwa yang dapat dipertukarkan.
- Menerapkan ketentuan proposer dan attester Ethereum pada protokol dengan pesan atau aturan finalitas berbeda.
- Menghilangkan identitas rantai, versi fork, epoch, atau slot saat membandingkan tanda tangan yang diduga bertentangan.
- Menganggap dua tanda tangan saja membuktikan pelanggaran tanpa identitas validator, domain, silsilah, dan kriptografi valid.
- Mencampuradukkan pengaruh pilihan fork dengan pembenaran, finalisasi, atau penyelesaian tingkat aplikasi.
- Membaca teorema keamanan tanpa asumsi sinkronisitas, kejujuran, ketersediaan, dan lawannya.

### Kesalahan insentif dan penegakan

- Menyatakan tanda tangan murah tanpa menghitung kerugian terikat, imbalan terlewat, dan pendapatan masa depan.
- Memperlakukan slashing nominal maksimum sebagai kerugian ekspektasian yang dapat ditagih dalam setiap keadaan.
- Menganggap bukti selalu diamati, disebarkan, disertakan, dan diproses sebelum penarikan.
- Mengabaikan sensor proposer, partisi jaringan, isolasi eclipse, dan kedaluwarsa jangka bukti.
- Menggunakan nilai ekspektasian ilustratif sebagai bukti ketika probabilitas, suap, dan kerugian belum diukur.
- Mengabaikan penalti terkorelasi, pergerakan harga token, lindung nilai, suap eksternal, dan keuntungan serangan.
- Menganggap kunci lama validator yang sudah keluar masih didukung jaminan yang saat ini dapat dikenai slashing.

### Kesalahan operasi, konsentrasi, dan pemulihan

- Menjalankan kunci penandatanganan yang sama pada node failover tanpa perlindungan slashing bersama yang tahan lama.
- Memulihkan penanda tangan atau basis data slashing dari cadangan lama dan membuat ulang konflik yang pernah ditandatangani.
- Menghitung kunci validator sebagai operator independen meski berbagi kustodi, klien, cloud, atau kontrol tata kelola.
- Menganggap delegator tidak menanggung kerugian yang disebabkan operator, pool, atau dependensi restaking.
- Memercayai satu penjelajah, penyedia, atau checkpoint bawaan saat memulihkan node yang lama offline.
- Mengklaim partisipasi staking tinggi membuktikan keamanan tanpa menganalisis distribusi, ambang, dan kontrol stake.

<a id="misconceptions"></a>

## Kesalahpahaman umum

- **Secara harfiah tidak ada yang berisiko dalam proof of stake.** Sistem yang dirancang baik dapat membuat modal terikat, imbalan, dan partisipasi masa depan menghadapi kerugian; pertanyaannya adalah apakah biaya tersebut memadai dan dapat ditegakkan untuk penyimpangan terkait.
- **Setiap pesan validator pada dua fork adalah pemungutan suara ganda.** Kelayakan slashing bergantung pada bidang pesan, domain, dan aturan konflik protokol; pembaruan pilihan fork yang jujur memerlukan ruang.
- **Slashing menjamin konsensus.** Slashing memberi pertanggungjawaban dan insentif, tetapi keamanan dan liveness juga bergantung pada ambang, jaringan, implementasi, keamanan kunci, dan asumsi perilaku jujur.
- **Sepertiga stake dapat memfinalkan dua cabang sendiri.** Dalam desain finalitas dua pertiga, sekitar sepertiga umumnya dapat menghentikan kemajuan; finalitas bertentangan memerlukan supermayoritas yang tumpang tindih dan partisipasi yang dapat dikenai slashing pada irisannya.
- **Nothing at Stake dan serangan long-range sama.** Keduanya memanfaatkan tanda tangan murah, tetapi yang pertama menyangkut dukungan langsung pada cabang bersaing, sedangkan yang kedua dapat memakai kunci historis terhadap node tanpa status tepercaya terbaru.

<a id="related"></a>

## Topik terkait

- [Proof of stake](/id/crypto/proof-of-stake/)
- [Slashing](/id/crypto/slashing/)
- [Aturan pilihan fork](/id/crypto/fork-choice-rule/)
- [Finalitas](/id/crypto/finality/)
- [Serangan long-range](/id/crypto/long-range-attack/)

<a id="sources"></a>

## Sumber

- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (diakses: 2026-08-19)
- [Formal Barriers to Longest-Chain Proof-of-Stake Protocols](https://economics.princeton.edu/working-papers/formal-barriers-to-longest-chain-proof-of-stake-protocols/) - Princeton University (diakses: 2026-08-19)
- [Ethereum Consensus Specifications: Validator](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/validator.md) - Ethereum Foundation (diakses: 2026-08-19)
- [Ethereum Consensus Specifications: Beacon Chain](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (diakses: 2026-08-19)
- [Casper the Friendly Finality Gadget](https://eips.ethereum.org/assets/eip-2982/arxiv-1710.09437-Casper-the-Friendly-Finality-Gadget.pdf) - Ethereum Improvement Proposals (diakses: 2026-08-19)
- [Ethereum Proof-of-Stake Attack and Defense](https://ethereum.org/developers/docs/consensus-mechanisms/pos/attack-and-defense/) - Ethereum.org (diakses: 2026-08-19)
- [Weak Subjectivity](https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) - Ethereum.org (diakses: 2026-08-19)
- [Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol](https://eprint.iacr.org/2016/889) - IACR Cryptology ePrint Archive (diakses: 2026-08-19)

Source: https://wiki.fcontext.com/id/crypto/nothing-at-stake/index.mdx