﻿---
title: "Masalah Jenderal Bizantium: Kesepakatan di Tengah Pesan yang Bertentangan"
description: "Masalah Jenderal Bizantium menanyakan cara peserta jujur bersepakat ketika peserta bermasalah dapat mengirim informasi yang bertentangan. Tugas kesepakatan, kanal, autentikasi, batas kegagalan, ambang, algoritma, dan penerapan harus dianalisis 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.

# Masalah Jenderal Bizantium: Kesepakatan di Tengah Pesan yang Bertentangan

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

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

## Jawaban langsung

Masalah Jenderal Bizantium menanyakan cara peserta yang tidak gagal dan berkomunikasi melalui pesan dapat mencapai keputusan yang konsisten ketika sebagian peserta bertindak sewenang-wenang, termasuk menyampaikan klaim berbeda kepada penerima berbeda. Kisah militer itu adalah analogi untuk konsistensi interaktif dalam sistem terdistribusi, bukan peristiwa sejarah dan bukan satu algoritma konsensus blockchain tertentu.

Dalam rumusan dengan jenderal pemimpin, `IC1` mensyaratkan semua letnan setia menjalankan perintah yang sama, sedangkan `IC2` mensyaratkan setiap letnan setia menjalankan perintah pemimpin ketika pemimpin itu setia. Kesepakatan saja tidak cukup: aturan yang selalu memilih MUNDUR akan menghasilkan kesepakatan, tetapi melanggar perintah SERANG yang valid dari pemimpin setia.

Dalam model “pesan lisan” pada makalah, dengan paling banyak `m` pengkhianat, solusi hanya ada ketika `n>3m`, atau setara dengan `n>=3m+1` untuk jumlah peserta bulat. Model ini mengasumsikan pesan peserta setia dikirim dengan benar, penerima mengetahui pengirim setiap pesan, dan ketiadaan pesan yang diharapkan dapat dideteksi. “Lisan” berarti isi tanpa autentikasi dapat dipalsukan sebagai laporan peserta lain, bukan berarti kurir yang tidak andal dapat menghilang selamanya tanpa terdeteksi.

Model “pesan bertanda tangan” menambahkan tanda tangan yang tidak dapat dipalsukan dan dapat diverifikasi publik, sehingga hasil ketahanannya berubah. Tanda tangan tidak membuat isi menjadi benar, menjamin pengiriman, menyelesaikan terminasi sepenuhnya asinkron, melindungi kunci curian, atau membuktikan keamanan protokol modern. Masalah Jenderal Bizantium, masalah Dua Jenderal atau serangan terkoordinasi, FLP, protokol BFT, Proof of Work, dan Proof of Stake saling berkaitan tetapi merupakan model atau konstruksi yang berbeda.

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

## Cara menganalisisnya

1. **Definisikan tugas kesepakatan.** Nyatakan peserta, masukan, keluaran, serta sifat kesepakatan, validitas, dan terminasi secara tepat. Untuk rumusan dengan pemimpin, tuliskan `IC1` dan `IC2` secara eksplisit, bukan sekadar mengatakan “mencapai konsensus”.
2. **Definisikan identitas dan kanal.** Nyatakan apakah pesan titik ke titik diautentikasi, dikirim secara andal, diurutkan, dilindungi dari pemutaran ulang, dan dapat dikaitkan dengan pengirim; apakah penghilangan dapat dideteksi; serta apakah siaran merupakan primitif atau dilakukan lewat pengiriman berulang.
3. **Definisikan waktu.** Pisahkan sinkron dengan batas penundaan, sinkron parsial setelah waktu stabilisasi yang tidak diketahui, dan asinkron penuh. Jangan menambahkan pembawa pesan yang menghilang ke satu model lalu mempertahankan teorema yang dibuktikan untuk model lain.
4. **Definisikan anggaran kegagalan.** Catat jumlah peserta `n`, jumlah maksimum peserta Bizantium `m`, apakah korupsi statis atau adaptif, serta apakah kegagalan mencakup penghilangan, pernyataan bercabang, kolusi, pencurian kunci, atau kanal bermasalah.
5. **Lacak informasi secara rekursif.** Untuk setiap peserta setia, daftarkan klaim langsung dan klaim yang diteruskan, termasuk jalur pengirim, nilai bawaan saat pesan hilang, dan aturan pemecah seri deterministik. Bandingkan hal yang dapat dibedakan dua peserta setia dari pandangan lokal mereka.
6. **Periksa teorema dan algoritma bersama-sama.** Cocokkan batas bawah dan kecukupan dengan model lisan atau bertanda tangan yang tepat, konektivitas, dan anggaran kegagalan. Pertidaksamaan ambang saja bukan implementasi ataupun bukti.
7. **Petakan model ke penerapan.** Verifikasi mekanisme `OM(m)`, `SM(m)`, atau mekanisme lain pada protokol yang diterapkan, domain pesan, putaran, penguncian, sertifikat, perubahan keanggotaan, batas waktu, perilaku klien, aturan finalitas, dan kebijakan konfirmasi aplikasi.

Teknik pembuktian utamanya adalah ketakterbedaan. Peserta setia hanya melihat pesan lokalnya; jika dua eksekusi tampak sama baginya tetapi validitas menuntut keputusan berbeda, tidak ada aturan deterministik yang selalu dapat memilih dengan benar. Protokol berhasil dengan menambahkan cukup peserta independen, bukti terautentikasi, asumsi waktu, keacakan, atau struktur lain sehingga eksekusi yang relevan dapat dibedakan atau jaminannya berubah.

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

## Contoh terurai

### 1. Mengapa tiga jenderal dengan pesan lisan tidak dapat menoleransi satu pengkhianat

Ambil `n=3` dan `m=1`. Syarat `n>3m` menjadi `3>3`, yang salah. Misalkan pemimpin A memberi tahu letnan B `ATTACK` dan letnan C `RETREAT`. B tidak dapat membedakan apakah A pengkhianat yang memberi perintah berbeda atau C pengkhianat yang berbohong tentang perkataan A; C menghadapi ketidakpastian simetris.

Setiap pilihan deterministik yang mempertahankan perintah pemimpin setia dalam eksekusi terkait ketika A setia dapat memaksa B dan C memilih berbeda ketika A berkhianat. Penerusan pesan tidak menciptakan sumber independen keempat, sehingga `IC1` dan `IC2` tidak dapat dijamin bersamaan.

### 2. Empat jenderal dengan pesan lisan dan satu pengkhianat

Dengan `OM(1)`, `n=4`, dan `m=1`, pemimpin mengirim perintah kepada tiga letnan; masing-masing meneruskan nilai yang diterimanya kepada dua lainnya; setiap letnan setia menerapkan aturan mayoritas dan nilai bawaan yang sama. Jika pemimpin setia dan mengirim `v`, letnan setia melihat nilai seperti `v`, `v`, dan kemungkinan `x` dari pengkhianat, lalu memilih `v`.

Jika pemimpin adalah satu-satunya pengkhianat, ketiga letnan setia dan meneruskan persis yang mereka terima. Karena itu mereka merekonstruksi himpunan klaim pemimpin kepada para letnan yang sama dan menerapkan aturan deterministik yang sama. Mereka mungkin tidak mengetahui “niat sebenarnya” pemimpin, tetapi memenuhi kesepakatan.

### 3. Batas bawah umum pesan lisan

Untuk `n=7` dan `m=2`, `7>6` benar, sehingga prasyarat jumlah peserta terpenuhi dan konstruksi pesan lisan rekursif dapat menoleransi paling banyak dua pengkhianat berdasarkan asumsinya. Untuk `n=6`, `6>6` salah. Untuk `n=10` dan `m=3`, `10>9` benar. Lolos dari pertidaksamaan itu perlu, tetapi putaran, penerusan, mayoritas, nilai bawaan, dan kanal yang benar tetap dibutuhkan.

### 4. Perubahan yang dihasilkan tanda tangan

Dalam contoh tiga jenderal dengan `SM(1)`, pemimpin pengkhianat menandatangani `ATTACK` untuk B dan `RETREAT` untuk C. Letnan setia meneruskan kedua perintah bertanda tangan, sehingga masing-masing memperoleh himpunan yang sama `{ATTACK, RETREAT}` dan menerapkan nilai bawaan yang ditentukan, misalnya `RETREAT`. Pernyataan bercabang pemimpin dapat dikaitkan dengannya.

Dalam model ini, tanda tangan mencegah perintah peserta setia dipalsukan atau diubah tanpa terdeteksi. Tanda tangan tidak mengungkap perintah mana yang mencerminkan niat nyata pengkhianat, tidak menjamin pengiriman tepat waktu, dan tidak mencegah penyerang yang menguasai kunci privat sah menandatangani keduanya.

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

## Risiko dan kegagalan peninjauan

### Masalah dan model

- Menceritakan alegori tanpa syarat kesepakatan, validitas, dan terminasi yang tepat.
- Menganggap masalah itu pengepungan historis, satu algoritma, atau sinonim blockchain.
- Mencampurnya dengan masalah Dua Jenderal yang berpusat pada pengetahuan bersama melalui kanal tidak andal.
- Menambahkan kehilangan pesan permanen yang tidak terdeteksi sambil mengutip teorema yang asumsi pesan lisannya mengecualikan hal tersebut.
- Menerapkan `n>3m` pada semua protokol terautentikasi, asinkron, berbobot, tanpa izin, atau berbasis sumber daya.
- Menyamakan kerusakan, penghilangan, pernyataan bercabang, komputasi sewenang-wenang, kanal bermasalah, dan kompromi kunci.
- Mengasumsikan jumlah peserta sama dengan entitas independen, stake, daya hash, atau bobot komite.
- Mengabaikan perbedaan antara pemimpin setia dan pemimpin pengkhianat dalam syarat validitas.

### Algoritma dan implementasi

- Hanya memeriksa mayoritas akhir tanpa melacak jalur pengirim rekursif dan pandangan lokal setiap peserta setia.
- Menggunakan nilai bawaan untuk pesan hilang, aturan seri, cuplikan keanggotaan, atau urutan pesan yang berbeda antarimplementasi.
- Menerima pesan tanpa mengikat protokol, rantai, tugas, ketinggian, putaran, nilai, pengirim, dan era keanggotaan.
- Memutar ulang atau menggabungkan pesan lintas eksekusi, putaran, fork, jaringan, atau perubahan keanggotaan.
- Menganggap tanda tangan membuktikan kebenaran, kebaruan, konteks wewenang, pengiriman, ketersediaan, atau penitipan kunci yang jujur.
- Mengutip `OM(m)` atau `SM(m)` tanpa menerapkan putaran, penerusan, verifikasi, dan konektivitas yang diwajibkan.
- Hanya menguji satu posisi pengkhianat, bukan kasus pemimpin, letnan, kolusi, penghilangan, dan pernyataan bercabang.

### Penerapan dan interpretasi

- Mengklaim protokol konsensus “menyelesaikan Bizantium” tanpa asumsi keamanan, keaktifan, dan jaringan yang tepat.
- Menganggap kesepakatan atas byte sebagai bukti bahwa eksekusi aplikasi atau fakta di luar rantai benar.
- Mengabaikan klien, operator, cloud, sistem kunci, atau tata kelola bersama yang mengorelasikan peserta yang secara nama terpisah.
- Mengkreditkan deposit, mencetak aset jembatan, atau menyelesaikan tindakan permanen sebelum syarat finalitas tercapai.
- Menyimpulkan desentralisasi, keamanan aset, kebenaran hukum, atau nilai token dari label toleransi kegagalan.

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

## Kesalahpahaman umum

- **Masalah ini sekadar serangan 51%.** Masalahnya menyangkut perilaku sewenang-wenang dan bertentangan dalam model kesepakatan tertentu; serangan mayoritas sumber daya bergantung pada protokol tertentu.
- **Mayoritas selalu menyelesaikannya.** Dalam model pesan lisan klasik, toleransi terhadap `m` pengkhianat membutuhkan total peserta lebih dari tiga kali jumlah tersebut, bukan sekadar satu peserta jujur lebih banyak.
- **Tanda tangan digital membuktikan pesan benar.** Tanda tangan dapat mengautentikasi kunci dan melindungi integritas; kunci jahat atau terkompromi tetap dapat menandatangani isi palsu atau bertentangan.
- **Pengiriman tidak andal sudah dicakup oleh hasil pesan lisan awal.** Hasil itu memiliki asumsi eksplisit tentang pengiriman, identitas pengirim, dan penghilangan yang terdeteksi; model waktu dan kanal lain memerlukan hasil lain.
- **Kesepakatan berarti sistem mengetahui kenyataan.** Node setia dapat menyepakati keluaran aplikasi yang tidak valid atau data eksternal yang salah jika aturan validasi terpisah tidak mencegahnya.

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

## Topik terkait

- [Toleransi Kegagalan Bizantium](/id/crypto/byzantine-fault-tolerance/)
- [Mekanisme konsensus](/id/crypto/consensus-mechanism/)
- [Finalitas](/id/crypto/finality/)

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

## Sumber

- [The Byzantine Generals Problem](https://lamport.azurewebsites.net/pubs/byz.pdf) - ACM Transactions on Programming Languages and Systems (diakses: 2026-08-19)
- [Reaching Agreement in the Presence of Faults](https://lamport.azurewebsites.net/pubs/reaching.pdf) - Journal of the ACM (diakses: 2026-08-19)
- [Impossibility of Distributed Consensus with One Faulty Process](https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf) - Journal of the ACM (diakses: 2026-08-19)
- [Consensus in the Presence of Partial Synchrony](https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf) - Journal of the ACM (diakses: 2026-08-19)
- [Practical Byzantine Fault Tolerance](https://pmg.csail.mit.edu/papers/osdi99.pdf) - USENIX OSDI (diakses: 2026-08-19)
- [CometBFT Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT (diakses: 2026-08-19)
- [HotStuff: BFT Consensus with Linearity and Responsiveness](https://arxiv.org/abs/1803.05069) - arXiv (diakses: 2026-08-19)
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (diakses: 2026-08-19)

Source: https://wiki.fcontext.com/id/crypto/byzantine-generals-problem/index.mdx
