---
title: "Toleransi kesalahan Byzantine: keamanan, kelangsungan, dan kuorum"
description: "Toleransi kesalahan Byzantine menjelaskan kapan protokol terdistribusi tetap aman dan terus maju meski menghadapi kesalahan arbitrer. Protokol, model jaringan, batas kesalahan, kuorum, bobot, finalitas, dan pemulihan harus dinilai bersama."
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.

# Toleransi kesalahan Byzantine: keamanan, kelangsungan, dan kuorum

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

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

## Jawaban langsung

Toleransi kesalahan Byzantine (BFT) adalah sifat protokol terdistribusi tertentu dalam model kesalahan dan jaringan tertentu: protokol tetap memenuhi jaminannya meski sebagian peserta berhenti, menahan pesan, mengirim pesan yang saling bertentangan kepada rekan berbeda, atau bertindak secara arbitrer. BFT bukan satu algoritme dan tidak berarti semua layanan selalu tersedia dalam setiap partisi jaringan.

Jaminannya harus dipisahkan. `safety` (keamanan) berarti peserta jujur tidak memutuskan nilai yang bertentangan; `liveness` (kelangsungan) berarti masukan yang memenuhi syarat pada akhirnya dapat menghasilkan keputusan; `validity` (validitas) membatasi nilai yang boleh diputuskan. Protokol dapat berhenti untuk menjaga keamanan ketika komunikasi atau bobot suara jujur tidak cukup. Konsensus yang benar juga tidak membuktikan kebenaran kode aplikasi, aturan validitas transaksi, bridge, kunci, atau tata kelola.

Dalam kelas umum protokol BFT terautentikasi dan sinkron parsial, `n=3f+1` replika menoleransi paling banyak `f` replika Byzantine dan sertifikat commit memakai `q=2f+1` suara. Ungkapan “kesalahan kurang dari sepertiga” dan “kuorum lebih dari dua pertiga” berasal dari model ini. Protokol sinkron, protokol asinkron acak, protokol crash-fault, rantai Proof of Work, dan konstruksi BFT lain dapat memiliki asumsi serta ambang berbeda.

Dalam sistem berbobot stake, ambang mengacu pada kekuatan suara yang ditetapkan protokol, bukan selalu jumlah validator, alamat, orang, atau operator independen. Sebelum menerapkan pecahan, sebutkan versi tepat, snapshot bobot, jenis keputusan, asumsi jaringan, perbandingan kuorum (`>` atau `>=`), dan perilaku kesalahan.

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

## Cara kerja

1. **Tentukan keputusan.** Pastikan apakah node mengurutkan transaksi, melakukan commit blok, memfinalkan checkpoint, memilih pemimpin, menerima transisi status, atau memilih fork. Keputusan tersebut tidak dapat dipertukarkan.
2. **Nyatakan model sistem dan lawan.** Catat keanggotaan, autentikasi, perubahan izin, bobot suara, korupsi adaptif, kompromi kunci, equivocating, crash, kehilangan pesan, penyensoran, denial of service, dan kemungkinan kesalahan berkorelasi.
3. **Nyatakan model jaringan.** Bedakan sinkroni, sinkroni parsial, dan asinkroni. Untuk sinkroni parsial, tentukan apa yang hanya dijamin setelah waktu stabilisasi global yang tidak diketahui dan bagaimana timeout menyesuaikan diri.
4. **Turunkan aturan kuorum.** Gunakan ambang dan aturan penguncian atau pemungutan suara yang tepat. Dalam kasus klasik `n=3f+1`, dua kuorum `2f+1` beririsan pada sedikitnya `f+1` replika; jika paling banyak `f` bersifat Byzantine, irisan mengandung replika jujur.
5. **Telusuri setiap fase dan sertifikat.** Verifikasi proposal, suara, kunci, perubahan view atau putaran, commit, pemilihan fork, dan pemulihan. Supermayoritas bertanda tangan hanya berarti jika tinggi, putaran, nilai, induk, domain, epoch keanggotaan, dan sertifikat sebelumnya divalidasi.
6. **Pisahkan bukti keamanan dan kelangsungan.** Buktikan keputusan bertentangan mana yang selalu dikecualikan, lalu uji apakah kemajuan kembali setelah asumsi komunikasi dan partisipasi jujur terpenuhi. Timeout adalah alat penjadwalan, bukan bukti bahwa rekan diam berniat jahat.
7. **Verifikasi implementasi dan operasi.** Cocokkan keragaman klien, penyimpanan kunci, failover penanda tangan, perlindungan replay, sinkronisasi status, penanganan bukti, perubahan anggota, pemantauan, kebijakan konfirmasi, dan pemulihan insiden dengan model yang dibuktikan.

Hasil FLP menyatakan bahwa protokol konsensus deterministik tidak dapat menjamin terminasi dalam model yang sepenuhnya asinkron meski hanya ada satu kemungkinan proses crash. Hasil itu tidak menyatakan keamanan mustahil atau konsensus terdistribusi tidak pernah bekerja. Sinkroni parsial, pengacakan, pendeteksi kegagalan, asumsi ekonomi, atau jaminan yang lebih lemah mengubah kondisi ketidakmungkinan tersebut dengan cara berbeda.

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

## Contoh perhitungan

### 1. Empat replika berbobot sama

Misalkan `n=4`, `f=1`, dan `q=3`. Dua himpunan yang masing-masing berisi tiga suara beririsan pada sedikitnya `3+3-4=2` replika. Dengan paling banyak satu replika Byzantine, sedikitnya satu replika dalam irisan bersifat jujur. Jika aturan node jujur melarang suara untuk nilai bertentangan dalam riwayat tinggi dan putaran terkait, dua sertifikat commit yang bertentangan tidak dapat terbentuk.

Jika dua replika offline, hanya `2` suara tersisa dan tidak ada sertifikat `q=3`. Ini kegagalan kelangsungan, bukan otomatis kegagalan keamanan: protokol yang aman menunggu alih-alih menurunkan ambang secara lokal.

### 2. Tujuh replika berbobot sama

Misalkan `n=7`, `f=2`, dan `q=5`. Dua kuorum beririsan pada sedikitnya `5+5-7=3=f+1` replika. Karena paling banyak `2` bersifat Byzantine, irisan mengandung replika jujur. Dua replika Byzantine tidak dapat sendiri membuat sertifikat lima suara, tetapi tiga replika yang offline atau menahan suara hanya menyisakan `4` dan dapat menghentikan kemajuan.

Aritmetika ambang diperlukan tetapi tidak cukup. Jika implementasi jujur menerima suara dari tinggi salah, memakai ulang keanggotaan, melanggar kunci, atau menandatangani dengan kunci terkompromi, asumsi bukti tidak lagi menggambarkan sistem yang diterapkan.

### 3. Kekuatan suara berbobot

Misalkan bobot `40`, `30`, `20`, dan `10`, total `100`, serta sertifikat memerlukan lebih dari `2/3` secara ketat, di sini sedikitnya `67`. Koalisi `40+30=70` dapat membuat sertifikat; `30+20+10=60` tidak dapat, walau berisi tiga dari empat validator. Jika validator berbobot `40` offline, hanya `60` tersisa dan finalitas berhenti.

Dua himpunan bernilai sedikitnya `67` beririsan sedikitnya `67+67-100=34`. Jadi sertifikat bertentangan berarti sedikitnya bobot `34` berpartisipasi dalam keduanya atau asumsi lain gagal. Dalam sebagian protokol, equivocating sedikit di atas sepertiga dapat merusak keamanan; “perlu dua pertiga untuk menyerang” bukan batas minimum universal.

### 4. Sinkroni parsial dan timeout

Misalkan timeout putaran adalah `1 s`, `2 s`, `4 s`, dan `8 s`. Sebelum waktu stabilisasi yang tidak diketahui, pesan dapat tiba setelah setiap timeout sehingga putaran berganti tanpa keputusan. Jika sesudah stabilisasi latensi di bawah `3 s`, putaran `4 s` atau lebih lama dapat memberi pengusul jujur dan kuorum cukup waktu untuk maju, dengan asumsi lain tetap terpenuhi.

Angka tersebut menggambarkan kemajuan eventual, bukan rumus timeout universal. Waktu terlalu singkat menimbulkan perubahan view yang tidak perlu; terlalu panjang memperlambat pemulihan. Keamanan tidak boleh bergantung pada tebakan batas latensi sebelum stabilisasi.

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

## Risiko dan kegagalan peninjauan

### Model dan bukti

- Menyebut “BFT” tanpa protokol, versi, keputusan, model kesalahan, model jaringan, aturan anggota, dan ambang.
- Menerapkan `n=3f+1` atau sepertiga pada semua ledger terdistribusi walau buktinya memakai asumsi lain.
- Menyamakan keamanan, kelangsungan, validitas, ketersediaan, konsistensi, finalitas, pemilihan fork, dan kebenaran transaksi.
- Mengklaim FLP membuat konsensus mustahil tanpa mempertahankan syarat deterministik, sepenuhnya asinkron, dan terminasi terjamin.
- Menghitung node atau alamat ketika protokol menghitung stake, bobot delegasi, komite, epoch, atau sumber daya lain.
- Membulatkan “dua pertiga” secara ambigu atau mengabaikan `>`, `>=`, bobot bilangan bulat, dan snapshot penyebut.
- Memeriksa ukuran kuorum tanpa irisan, kunci, sertifikat, perubahan view, rekonfigurasi, dan transfer status.
- Menganggap bukti mencakup korupsi adaptif, pencurian kunci, kesalahan berkorelasi, denial of service, atau riwayat jarak jauh tanpa dasar.

### Implementasi dan operasi

- Menerima tanda tangan tanpa mengikat rantai, domain, tinggi, putaran, nilai, induk, epoch anggota, dan jenis pesan.
- Memutar ulang suara atau sertifikat lama lintas putaran, tinggi, fork, jaringan, peningkatan, atau perubahan validator.
- Mengizinkan tanda tangan ganda, regresi kunci, failover tidak aman, atau dua replika aktif berbagi identitas validator.
- Menganggap habisnya timeout sebagai bukti niat jahat dan membuat keputusan keamanan hanya dari jam lokal.
- Mengabaikan kesalahan berkorelasi dari klien, cloud, wilayah, jaringan, perangkat keras, pengelolaan kunci, atau operator yang sama.
- Menganggap slashing mencegah kesalahan, memulihkan kelangsungan, membatalkan tindakan final, atau mengganti rugi semua pihak.
- Hanya menguji operasi normal, bukan partisi, latensi, pengurutan ulang, equivocating, kegagalan pengusul, restart, dan perubahan anggota.

### Aplikasi dan tata kelola

- Menganggap nilai yang sudah di-commit sebagai status aplikasi valid tanpa eksekusi deterministik dan validasi transisi.
- Mengkredit deposit, mencetak aset bridge, atau menyelesaikan perdagangan sebelum syarat finalitas tepat yang dibutuhkan aplikasi.
- Menyamakan finalitas protokol dengan ireversibilitas sosial setelah kompromi kunci, kegagalan perangkat lunak, atau intervensi tata kelola.
- Mengabaikan penyensoran dan latensi inklusi karena blok pengguna lain terus difinalkan.
- Menyimpulkan desentralisasi, keamanan aset, nilai token, atau kekuatan hukum dari label BFT atau jumlah validator yang diiklankan.

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

## Kesalahpahaman umum

- **BFT berarti jaringan tidak pernah berhenti.** Banyak protokol sengaja mengorbankan kelangsungan saat kesalahan berlebihan atau partisi untuk menjaga keamanan.
- **Peserta jujur di atas 51% selalu cukup.** Ambang bergantung pada protokol; BFT sinkron parsial klasik sering memerlukan lebih dari dua pertiga kekuatan terkait untuk maju.
- **Penyerang selalu memerlukan dua pertiga untuk merusak keamanan.** Dua pertiga dapat membuat sertifikat sendiri, tetapi dua sertifikat bertentangan dapat memperlihatkan hanya sedikit di atas sepertiga equivocating.
- **Lebih banyak alamat validator otomatis meningkatkan toleransi.** Kepemilikan bersama, delegasi, klien, infrastruktur, kunci, dan domain kegagalan menentukan independensi.
- **Slashing adalah bukti BFT.** Itu respons ekonomi dalam sebagian sistem PoS; keamanan berasal dari aturan dan asumsi, sedangkan hukuman tidak membatalkan akibat eksternal.

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

## Topik terkait

- [Masalah jenderal Byzantine](/id/crypto/byzantine-generals-problem/)
- [Mekanisme konsensus](/id/crypto/consensus-mechanism/)
- [Finalitas](/id/crypto/finality/)
- [Proof of Stake](/id/crypto/proof-of-stake/)
- [Validator](/id/crypto/validator/)

<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-18)
- [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-18)
- [Consensus in the Presence of Partial Synchrony](https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf) - Journal of the ACM (diakses: 2026-08-18)
- [Practical Byzantine Fault Tolerance](https://pmg.csail.mit.edu/papers/osdi99.pdf) - USENIX OSDI (diakses: 2026-08-18)
- [CometBFT Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT (diakses: 2026-08-18)
- [HotStuff: BFT Consensus with Linearity and Responsiveness](https://arxiv.org/abs/1803.05069) - arXiv (diakses: 2026-08-18)
- [Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org (diakses: 2026-08-18)
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (diakses: 2026-08-18)

Source: https://wiki.fcontext.com/id/crypto/byzantine-fault-tolerance/index.mdx