---
title: "Serangan jarak jauh PoS: kunci historis, risiko bootstrap, dan checkpoint"
description: "Serangan jarak jauh PoS menyajikan riwayat alternatif yang ditandatangani dengan kewenangan validator historis. Pelajari node mana yang terpapar, apa yang harus direproduksi penyerang, serta bagaimana checkpoint subjektivitas lemah dan aturan sinkronisasi khusus protokol membatasi risiko."
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.

# Serangan jarak jauh PoS: kunci historis, risiko bootstrap, dan checkpoint

> Hanya untuk analisis edukatif mengenai keamanan protokol. Ketahanan terhadap serangan jarak jauh bergantung pada protokol dan versinya; dapatkan data bootstrap dari sumber yang diautentikasi dan diperiksa secara independen sebelum mengandalkan node yang baru disinkronkan atau lama luring.

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

## Jawaban langsung

Serangan jarak jauh pada proof-of-stake adalah upaya membuat riwayat yang bertentangan tampak tepercaya dengan menggunakan kewenangan validator yang berlaku jauh di masa lalu. Dalam bentuk yang umum, sering disebut korupsi posterior, penyerang memperoleh atau mengompromikan kunci milik validator setelah mereka keluar dan jaminannya tidak lagi dapat dikenai slashing. Karena pembuatan tanda tangan lama tidak memerlukan pengulangan konsumsi energi proof-of-work, lawan mungkin dapat membangun fork yang konsisten secara internal dengan biaya rendah dibandingkan biaya historis rantai jujur.

Sasarannya biasanya node yang tidak memiliki pandangan terbaru yang terautentikasi: node yang baru pertama kali berjalan, node yang dipulihkan dari cadangan lama, atau node yang luring melewati batas sinkronisasi aman protokol. Node yang terus mengamati jaringan sudah mengetahui leluhur yang telah mencapai finalitas atau dilindungi dengan cara lain dan semestinya menolak fork yang bertentangan dengannya. Karena itu, serangan eclipse atau sumber data yang disusupi dapat memperkuat serangan dengan menyembunyikan pandangan jaringan yang jujur dari node yang sedang melakukan sinkronisasi.

Kunci historis saja bukan alat pemalsuan universal. Riwayat alternatif harus memenuhi domain tanda tangan, transisi status, evolusi himpunan validator, aturan waktu, bukti finalitas atau pemilihan rantai, serta setiap batasan evolusi kunci atau checkpoint dalam protokol target. Sebagian protokol PoS memerlukan checkpoint subjektivitas lemah yang terbaru; protokol lain menetapkan bootstrap dari genesis atau asumsi kepercayaan dan ketersediaan yang berbeda. Analisis harus dilakukan terhadap rantai, jaringan, versi fork, klien, dan mode sinkronisasi yang tepat, bukan dengan menganggap PoS sebagai satu mekanisme yang seragam.

Checkpoint bukan sekadar nomor blok yang praktis. Checkpoint mengikat jaringan dan status konsensus tertentu pada root atau hash di epoch, slot, atau ketinggian tertentu. Setelah diautentikasi, checkpoint membatasi riwayat yang akan dipertimbangkan node. Sisa rantai kemudian dapat diverifikasi dari jangkar tersebut berdasarkan aturan protokol. Inilah subjektivitas lemah: masukan eksternal yang terbatas saat bootstrap, lalu validasi objektif dalam periode yang diasumsikan, bukan kepercayaan permanen pada head terbaru yang diumumkan oleh peer.

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

## Jalur serangan dan verifikasi

1. **Pilih titik fork lama.** Lawan mencari status historis yang kewenangan validatornya telah berganti atau sulit diautentikasi secara independen oleh node baru.
2. **Dapatkan kekuatan penandatanganan historis yang memadai.** Setelah validator keluar, kuncinya dapat dibeli, dicuri, disimpan, dipulihkan dari cadangan, atau terekspos melalui sistem penandatanganan yang disusupi. Bobot dan jenis pesan yang dibutuhkan bergantung pada protokol; memiliki satu kunci proposer lama tidak otomatis cukup.
3. **Bangun alternatif yang valid menurut protokol.** Lawan menghasilkan blok, suara, sertifikat, dan perubahan himpunan validator yang lolos pemeriksaan historis klien korban. Transisi status yang tidak valid, domain yang salah, waktu yang mustahil, atau bukti yang tidak lengkap tetap dapat membatalkan fork.
4. **Perpanjang dan sajikan fork.** Produksi tanda tangan yang murah dapat memungkinkan lawan mengisi riwayat yang panjang, tetapi jumlah blok mentah bukan penentu. Cabang harus menang atau melewati prosedur pemilihan persis yang digunakan dalam mode sinkronisasi tersebut.
5. **Kendalikan pandangan bootstrap.** Korban diisolasi dari checkpoint terbaru yang terautentikasi atau bukti peer yang jujur, lalu ditunjukkan riwayat alternatif sebagai satu-satunya atau kandidat pilihan.
6. **Dorong sistem hilir untuk bergantung padanya.** Jika node menerima status yang salah, RPC, dompet, pengindeks, pemantau bridge, atau aplikasinya dapat melaporkan saldo, peristiwa, dan keanggotaan validator yang valid menurut protokol pada fork penyerang, meskipun jaringan aktif mengikuti rantai lain.

Pihak yang bertahan harus menjalankan jalur ini secara terbalik: autentikasi jangkar, konfirmasi identitas rantai dan jaringannya, verifikasi bahwa kandidat merupakan turunannya, jalankan seluruh pemeriksaan konsensus dan transisi status, lalu bandingkan status yang telah mencapai finalitas atau terpilih di berbagai infrastruktur independen. Unduhan yang berhasil bukan bukti bahwa riwayat terpilih bersifat kanonis.

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

## Contoh terperinci

Anggap himpunan validator `V_old` mengendalikan sebuah rantai PoS hipotetis pada epoch `120,000`. Bertahun-tahun kemudian, lebih dari `2/3` bobot historis tersebut telah keluar dan tidak lagi terpapar sanksi protokol. Lawan memperoleh kunci-kunci lama itu dan memulai riwayat yang bertentangan tepat setelah checkpoint `C_old`.

Pada cabang buatan, lawan menandatangani suara yang dibutuhkan protokol hipotetis tersebut, mengubah keanggotaan validator berikutnya, dan melanjutkan hingga epoch `420,000`. Jaringan jujur juga telah mencapai epoch `420,000`, sehingga nomor epoch yang sama atau berkas yang lebih panjang tidak memberi tahu node bootstrap cabang mana yang kanonis secara sosial dan operasional. Apakah cabang buatan itu dapat diterima pun bergantung pada setiap aturan historis protokol.

Node `N_live` telah mengamati checkpoint final yang asli, `C_recent`, pada epoch `419,936`. Karena fork serangan bukan turunan `C_recent`, `N_live` menolaknya. Sebaliknya, node `N_new` memulai dari genesis, hanya terhubung ke peer lawan, dan tidak memiliki jangkar terbaru yang terautentikasi. Jika protokol dan mode sinkronisasinya tidak dapat membedakan kedua riwayat hanya dari bukti internal masing-masing, node tersebut mungkin menerima cabang serangan.

Memberikan pasangan terautentikasi `C_recent = (root, 419,936)` kepada `N_new` mengubah batas keputusannya. Klien harus mensyaratkan jalur sinkronisasi memuat checkpoint yang persis sama dan berhenti secara aman jika persyaratan itu tidak dapat dipenuhi. Epoch dan ambang `2/3` dalam contoh ini menggambarkan satu desain bergaya finalitas; keduanya bukan parameter PoS universal atau pengaturan terkini jaringan tertentu.

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

## Kontrol dan daftar pemeriksaan

### Desain protokol

- Dokumentasikan model keamanan jarak jauh secara tepat: korupsi posterior, pergantian validator, kompromi kunci adaptif, isolasi jaringan, dan ketersediaan data.
- Tentukan status final mana yang tidak boleh dibatalkan dan bagaimana aturan pemilihan fork menangani konflik dengan jangkar yang dipercaya secara lokal.
- Batasi proses keluar, penarikan, dan pergantian himpunan validator agar asumsi keamanan tetap bermakna sementara penandatanganan ganda tetap dapat dideteksi dan dihukum.
- Tentukan periode subjektivitas lemah atau asumsi keamanan sinkronisasi alternatif sebagai nilai yang diturunkan dari status terkini dan konstanta protokol, bukan angka kalender yang berlaku selamanya.
- Pertimbangkan tanda tangan dengan evolusi kunci atau yang tetap aman terhadap kompromi kunci berikutnya jika didukung desain protokol; penghapusan kunci biasa merupakan praktik kebersihan yang berguna, tetapi bukan pertahanan konsensus yang lengkap.
- Uji sinkronisasi pertama, sinkronisasi checkpoint, pemulihan snapshot, dan pemulihan setelah lama luring secara terpisah. Aturan pemilihan fork yang aman saat jaringan aktif tidak otomatis membuat bootstrap aman.

### Bootstrap dan operasi node

- Sebelum sinkronisasi, catat root checkpoint atau hash blok, epoch atau ketinggian, ID rantai, jaringan, versi fork, waktu perolehan, dan penyedia.
- Dapatkan jangkar melalui kanal terautentikasi dan bandingkan beberapa sumber yang benar-benar independen. Sejumlah situs web yang didukung satu node atau operator tidak bersifat independen.
- Tolak checkpoint yang kedaluwarsa, rusak, berasal dari jaringan yang salah, atau saling bertentangan. Jangan diam-diam beralih ke sinkronisasi tanpa jangkar setelah validasi gagal.
- Wajibkan rantai hasil sinkronisasi memuat jangkar yang persis sama dan verifikasi seluruh turunannya dengan klien konsensus dan eksekusi yang dimaksud.
- Gunakan keberagaman peer, klien, operator, dan RPC; pantau kondisi eclipse, perbedaan root final, rollback yang tidak wajar, dan kegagalan finalitas berkepanjangan.
- Periksa ulang jangkar setelah memulihkan basis data atau cadangan lama, lalu perbarui dalam periode aman yang didokumentasikan protokol.

### Ketergantungan aplikasi

- Jangan melepaskan deposit, pesan bridge, atau transaksi yang tidak dapat dibatalkan hanya karena satu RPC yang baru disinkronkan melaporkan keberhasilan.
- Cocokkan identitas rantai, checkpoint final, dan garis leluhur peristiwa di beberapa node independen sebelum mengambil tindakan berdampak besar.
- Pisahkan riwayat konsensus dari kebenaran aplikasi: rantai kanonis tidak membuktikan kebenaran oracle, keamanan kontrak, ketersediaan data di luar protokol, atau solvabilitas kustodian.
- Siapkan kebijakan penghentian untuk checkpoint final atau jangkar tepercaya yang saling bertentangan. Kondisi tersebut dapat menandakan kegagalan konsensus, data bootstrap yang rusak, atau jaringan yang salah, dan tidak boleh diselesaikan otomatis dengan memilih cabang yang lebih panjang.

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

## Kesalahpahaman umum

- **Semua rantai PoS rentan dengan cara yang sama.** Ketahanan terhadap serangan jarak jauh bergantung pada evolusi validator, tanda tangan, finalitas, pemilihan fork, checkpoint, dan asumsi sinkronisasi protokol.
- **Kunci lama dapat menulis ulang transaksi apa pun tanpa batasan.** Penyerang tetap harus menghasilkan riwayat yang diterima seluruh aturan validasi korban; kewenangan historis hanya diperlukan dalam beberapa konstruksi serangan dan mungkin tidak memadai.
- **Rantai dengan lebih banyak blok, epoch, atau tanda tangan adalah rantai yang asli.** Pemilihan menggunakan validitas, bobot, sertifikat, dan jangkar khusus protokol, bukan perbandingan panjang yang universal.
- **Finalitas saja memungkinkan node yang memulai dari genesis mengenali rantai yang diakui komunitas.** Dua riwayat final yang masing-masing valid secara internal dapat ambigu bagi node tanpa pandangan terbaru yang terautentikasi; finalitas melindungi node yang sudah mengetahui checkpoint terkait.
- **Slashing selalu mencegah serangan.** Validator yang telah menarik seluruh dananya mungkin tidak memiliki jaminan tersisa untuk dipotong, dan bukti harus dapat dikaitkan dengan pelaku serta diproses selama sanksi masih dapat diterapkan.
- **Checkpoint berarti memercayai satu perusahaan selamanya.** Kepercayaan dapat dibatasi pada satu jangkar terbaru tertentu dan dikurangi melalui distribusi terautentikasi, pemeriksaan silang independen, dan verifikasi lokal setelahnya.
- **Menghapus kunci validator yang telah keluar menyelesaikan masalah protokol.** Penghapusan aman mengurangi risiko kompromi, tetapi aturan konsensus dan bootstrap yang kuat harus mampu menoleransi tersedianya sebagian kunci historis.

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

## Topik terkait

- [Finalitas](/id/crypto/finality/)
- [Aturan pemilihan fork](/id/crypto/fork-choice-rule/)
- [Proof-of-stake](/id/crypto/proof-of-stake/)
- [Antrean keluar dan penarikan validator](/id/crypto/validator-exit-withdrawal-queue/)
- [Subjektivitas lemah](/id/crypto/weak-subjectivity/)

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

## Sumber

- [Subjektivitas lemah Ethereum](https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) - Ethereum.org (diakses: 2026-08-21)
- [Spesifikasi konsensus Ethereum: panduan subjektivitas lemah](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/weak-subjectivity.md) - Ethereum Foundation (diakses: 2026-08-21)
- [Serangan dan pertahanan proof-of-stake Ethereum](https://ethereum.org/developers/docs/consensus-mechanisms/pos/attack-and-defense/) - Ethereum.org (diakses: 2026-08-21)
- [Casper, perangkat finalitas yang ramah](https://arxiv.org/abs/1710.09437) - arXiv (diakses: 2026-08-21)
- [Ouroboros Genesis: blockchain proof-of-stake yang dapat dikomposisi dengan ketersediaan dinamis](https://eprint.iacr.org/2018/378) - IACR Cryptology ePrint Archive (diakses: 2026-08-21)
- [Desain Ouroboros Genesis](https://ouroboros-consensus.cardano.intersectmbo.org/docs/references/miscellaneous/genesis_design/) - Intersect (diakses: 2026-08-21)

Source: https://wiki.fcontext.com/id/crypto/long-range-attack/index.mdx