---
title: "Serangan Eclipse: Isolasi, Deteksi, dan Pertahanan Node"
description: "Pelajari cara serangan eclipse mengisolasi node blockchain, mengapa data valid tetap dapat menciptakan pandangan jaringan yang keliru, serta cara keragaman peer dan pemeriksaan independen mengurangi 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 Eclipse: Isolasi, Deteksi, dan Pertahanan Node

> Hanya untuk tujuan edukasi; bukan saran investasi. Investasi dapat mengakibatkan kerugian.

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

## Jawaban langsung

**Serangan eclipse** mengisolasi node sasaran dari peer yang jujur dengan menguasai semua atau cukup banyak koneksi jaringannya. Penyerang kemudian dapat menunda, menahan, atau meneruskan blok dan transaksi secara selektif sehingga korban melihat gambaran jaringan yang dibentuk oleh penyerang.

Node korban mungkin tetap memvalidasi tanda tangan, bukti kerja, dan semua aturan konsensus lainnya. Namun, hal itu tidak membuat pandangannya lengkap atau mutakhir. Node yang memvalidasi sepenuhnya dapat menolak data tidak valid, tetapi tetap tertahan pada cabang yang valid namun usang, dicegah melihat transaksi yang bertentangan, atau disesatkan tentang apa yang telah diterima jaringan yang lebih luas.

Serangan ini berbeda dari serangan mayoritas terhadap seluruh jaringan. Penyerang menyasar satu node atau sekelompok kecil node pada lapisan peer-to-peer dan tidak perlu menguasai sebagian besar daya penambangan atau stake jaringan. Serangan Sybil dapat mendukung serangan eclipse dengan menyediakan banyak identitas atau alamat yang dikuasai penyerang, tetapi keduanya bukan konsep yang sama: Sybil menggambarkan penggandaan identitas, sedangkan eclipse menggambarkan keberhasilan mengisolasi pandangan informasi korban.

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

## Cara isolasi berlangsung

Klien peer-to-peer menemukan dan menyimpan alamat kandidat, memilih peer keluar, menerima sebagian peer masuk, serta menyambung kembali setelah kegagalan atau mulai ulang. Algoritma tepatnya berbeda menurut klien dan versi. Penyerang mencari cara untuk membuat cukup banyak keputusan tersebut condong ke infrastruktur yang dikuasainya.

Jalur serangan yang umum memiliki 4 tahap:

1. **Menyiapkan peer yang dikuasai penyerang.** Penyerang menjalankan node atau identitas yang dapat dijangkau pada alamat yang kemungkinan dianggap berbeda oleh aturan pemilihan peer milik korban.
2. **Membiaskan kumpulan kandidat.** Peer berbahaya mengiklankan alamat yang dikuasai penyerang atau mencoba menyingkirkan entri jujur dari pengelola alamat korban dengan cara lain. Kelayakan praktis bergantung pada desain bucket, aturan kelompok jaringan, batas laju, dan kualitas alamat yang telah tersimpan.
3. **Memicu atau menunggu penyambungan ulang.** Mulai ulang, pergantian koneksi, penolakan layanan, atau gangguan perutean dapat membuat sasaran mengganti peer yang jujur. Isolasi lebih mudah ketika sasaran memiliki sedikit jalur independen atau memulai dengan basis data alamat yang lemah.
4. **Memonopoli dan menyaring.** Setelah koneksi penting korban mengarah kepada penyerang, penyerang hanya meneruskan blok dan transaksi pilihannya, sering kali tetap mematuhi aturan konsensus agar tidak langsung ditolak.

Studi USENIX tahun 2015 mendemonstrasikan kelas serangan ini terhadap implementasi peer-to-peer Bitcoin pada saat itu dan menjelaskan dampak yang mencakup pengeluaran ganda berbasis konfirmasi, dukungan bagi penambangan egois, dan fork yang merugikan. Estimasi sumber daya dan perincian klien dalam studi tersebut bersifat historis, bukan nilai universal untuk Bitcoin Core saat ini atau jaringan lain.

Klien modern dapat menaikkan biaya isolasi melalui penyimpanan alamat yang diacak dan disegmentasi, keragaman sumber peer, koneksi uji, koneksi keluar atau relai blok yang dilindungi, anchor yang bertahan setelah mulai ulang, aturan pengusiran, serta batas relai alamat. Semua ini merupakan mitigasi berlapis, bukan bukti bahwa serangan eclipse mustahil dilakukan.

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

## Contoh pembayaran dan respons

Misalkan node milik pedagang menerima pembayaran dan menampilkan `6 confirmations`. Penyerang yang telah mengisolasi node tersebut dapat menunjukkan cabang valid yang dikelolanya secara privat dan memuat pembayaran itu, sementara transaksi yang bertentangan diterima di jaringan yang jujur. Jika pedagang menyerahkan barang yang tidak dapat ditarik kembali hanya berdasarkan node terisolasi, angka yang ditampilkan tidak membuktikan bahwa jaringan yang jujur telah mengonfirmasi pembayaran tersebut.

Respons insiden harus mempertahankan bukti sebelum melakukan perubahan yang mengganggu operasi:

- Catat ujung rantai yang dilaporkan, kerja kumulatif, hash blok terbaru, daftar peer, arah koneksi, jenis jaringan, sistem otonom yang dipetakan bila tersedia, dan stempel waktu blok terakhir yang diterima.
- Bandingkan ujung rantai dan status transaksi dengan node yang dioperasikan secara independen serta dijangkau melalui jalur jaringan dan administratif yang benar-benar terpisah. Penjelajah blok publik hanya berguna jika infrastrukturnya juga independen.
- Jeda penyelesaian bernilai tinggi atau penyerahan otomatis ketika pandangan independen berbeda. Lebih banyak konfirmasi dari pandangan terisolasi yang sama tidak menyelesaikan masalah.
- Beralihlah ke perangkat lunak dan konfigurasi yang diketahui baik, selidiki DNS, perutean, firewall, proxy, dan kemungkinan kompromi host, lalu bangun ulang status peer sesuai prosedur pemulihan klien yang terdokumentasi.
- Sambungkan kembali secara bertahap dan pastikan peer, kelompok jaringan, kedatangan blok, kerja rantai, serta pengamatan transaksi menjadi beragam. Jangan memulihkan begitu saja basis data peer yang mungkin telah diracuni.
- Pertahankan log dan eskalasikan kepada tim keamanan node atau protokol. Dugaan serangan eclipse dapat tumpang tindih dengan gangguan biasa, insiden perutean, atau penyusupan host yang lebih luas.

Pada Bitcoin Core 30.0, `getpeerinfo` menampilkan kolom seperti `network`, `mapped_as`, `inbound`, `last_block`, `synced_headers`, `synced_blocks`, dan `connection_type`. Kolom-kolom ini membantu penyelidikan, tetapi tidak ada satu kolom pun yang membuktikan isolasi. Pemantauan harus menetapkan kondisi dasar normal dan menghubungkan konsentrasi peer dengan pengamatan rantai yang independen.

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

## Risiko dan kontrol

- **Pengeluaran ganda terhadap penerima:** korban dapat diperlihatkan konfirmasi pada cabang yang dikuasai penyerang. Wajibkan pengamatan independen untuk penyerahan bernilai tinggi atau tidak dapat dibatalkan, serta tetapkan batas yang mencerminkan risiko penyelesaian.
- **Gangguan penambangan atau validator:** operator yang terisolasi dapat bekerja berdasarkan informasi usang, kehilangan pendapatan, atau membantu cabang yang merugikan. Pantau kerja rantai, kemutakhiran ujung rantai, dan keragaman peer dari luar node produksi.
- **Penyensoran selektif:** penyerang dapat menyembunyikan transaksi atau menunda blok tanpa mengirim data tidak valid. Buat peringatan untuk jeda kedatangan blok yang tidak biasa dan perbedaan di antara pengamat independen.
- **Kegagalan bridge, oracle, dan RPC:** layanan off-chain yang memercayai satu node hulu dapat meneruskan status usang atau melewatkan reorganisasi. Gunakan beberapa sumber data dengan administrasi dan jaringan yang independen, disertai aturan kuorum dan kemutakhiran yang jelas.
- **Keyakinan semu dari jumlah koneksi:** 20 peer yang dikuasai satu organisasi, satu jaringan, atau satu sumber alamat dapat memberikan independensi lebih rendah daripada kumpulan kecil yang beragam. Ukur keragaman, bukan hanya jumlah.
- **Sentralisasi akibat peer tetap:** satu peer tepercaya yang dikonfigurasi secara manual dapat melewati kumpulan kandidat yang diracuni, tetapi menciptakan satu titik kegagalan. Jika anchor tetap sesuai digunakan, pakailah beberapa jalur yang dioperasikan secara independen dan pertahankan koneksi acak.

Operator node harus selalu memperbarui rilis klien yang masih didukung, memahami pengaturan baku pengelolaan peer yang khusus untuk kliennya, melindungi akses administratif, serta memantau topologi masuk dan keluar. Operator pembayaran dan protokol harus memisahkan penandatanganan, penyiaran, pengamatan rantai, dan keputusan penyerahan agar satu node terisolasi tidak dapat mengizinkan tindakan yang tidak dapat dibatalkan seorang diri.

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

## Kesalahpahaman umum

- **Node penuh tidak dapat ditipu.** Node penuh menolak data yang tidak sesuai konsensus; node tersebut tidak otomatis mengetahui bahwa peer yang jujur menahan rantai valid yang lebih baik darinya.
- **Jumlah konfirmasi yang tinggi selalu memadai.** Konfirmasi hanya bermakna terhadap pandangan rantai yang diamati. Independensi jalur pengamatan penting ketika isolasi mungkin terjadi.
- **Lebih banyak peer selalu menyelesaikan masalah.** Peer tambahan hanya membantu jika kepemilikan, jalur jaringan, sumber penemuan, dan pola kegagalannya cukup independen.
- **Serangan eclipse dan Sybil sama.** Sumber daya Sybil dapat mempermudah isolasi, tetapi serangan eclipse adalah kendali yang dihasilkan atas pandangan peer korban.
- **Satu penjelajah blok yang cocok membuktikan node sehat.** Penjelajah tersebut mungkin berbagi penyedia hulu, jalur jaringan, atau ranah administratif dengan sistem yang terdampak.
- **Setiap node yang tertinggal sedang diserang.** Cacat perangkat lunak, kemacetan, pemeliharaan, gangguan perutean, dan kehabisan sumber daya dapat menimbulkan gejala serupa. Perlakukan eclipse sebagai hipotesis yang perlu diuji dengan beberapa sinyal.

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

## Topik terkait

- [Node Penuh](/id/crypto/full-node/)
- [Jaringan Peer-to-Peer](/id/crypto/peer-to-peer-network/)
- [Serangan Sybil](/id/crypto/sybil-attack/)
- [Konfirmasi Blok](/id/crypto/block-confirmation/)
- [Reorganisasi Rantai](/id/crypto/chain-reorg/)

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

## Sumber

- [Eclipse Attacks on Bitcoin's Peer-to-Peer Network](https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/heilman) - USENIX Association (diakses: 2026-08-20)
- [Bitcoin Core RPC: getpeerinfo](https://bitcoincore.org/en/doc/30.0.0/rpc/network/getpeerinfo/) - Bitcoin Core (diakses: 2026-08-20)
- [Bitcoin Core: connection_types.cpp](https://github.com/bitcoin/bitcoin/blob/v30.0/src/node/connection_types.cpp) - Bitcoin Core (diakses: 2026-08-20)

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