---
title: "การทนต่อความผิดพลาดแบบไบแซนไทน์: ความปลอดภัย ความก้าวหน้า และองค์ประชุม"
description: "การทนต่อความผิดพลาดแบบไบแซนไทน์อธิบายว่าโปรโตคอลแบบกระจายยังปลอดภัยและก้าวหน้าได้เมื่อใดแม้มีความผิดพลาดตามอำเภอใจ ต้องประเมินโปรโตคอล แบบจำลองเครือข่าย ขีดจำกัด องค์ประชุม น้ำหนัก ความสิ้นสุด และการกู้คืนร่วมกัน"
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.

# การทนต่อความผิดพลาดแบบไบแซนไทน์: ความปลอดภัย ความก้าวหน้า และองค์ประชุม

> จัดทำขึ้นเพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำการลงทุน การลงทุนอาจทำให้สูญเสียเงินลงทุนได้

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

## คำตอบโดยตรง

การทนต่อความผิดพลาดแบบไบแซนไทน์ (BFT) เป็นคุณสมบัติของโปรโตคอลแบบกระจายที่ระบุชัดภายใต้แบบจำลองความผิดพลาดและเครือข่ายที่ระบุชัด โปรโตคอลยังรักษาการรับประกันที่ประกาศไว้แม้ผู้เข้าร่วมบางรายหยุดทำงาน ระงับข้อความ ส่งข้อความที่ขัดแย้งกันให้เพื่อนคนละราย หรือประพฤติตามอำเภอใจ BFT ไม่ใช่อัลกอริทึมเดียวและไม่ได้หมายความว่าทุกบริการจะพร้อมใช้ระหว่างการแบ่งเครือข่ายทุกครั้ง

ต้องแยกการรับประกันแต่ละด้าน `safety` หรือความปลอดภัยหมายถึงผู้เข้าร่วมที่ซื่อสัตย์ไม่ตัดสินค่าที่ขัดแย้งกัน `liveness` หรือความก้าวหน้าหมายถึงข้อมูลเข้าที่มีสิทธิ์สามารถนำไปสู่การตัดสินได้ในที่สุด และ `validity` หรือความถูกต้องจำกัดว่าค่าใดตัดสินได้ โปรโตคอลอาจหยุดเพื่อรักษาความปลอดภัยเมื่อการสื่อสารหรืออำนาจลงคะแนนที่ซื่อสัตย์ไม่เพียงพอ ฉันทามติที่ถูกต้องก็ไม่ได้พิสูจน์ว่าโค้ดแอป กฎตรวจสอบธุรกรรม บริดจ์ กุญแจ หรือธรรมาภิบาลถูกต้อง

ในโปรโตคอล BFT แบบยืนยันตัวตนและซิงโครไนซ์บางส่วนกลุ่มหนึ่งที่พบบ่อย รีพลิกา `n=3f+1` ตัวทนต่อรีพลิกาไบแซนไทน์ได้ไม่เกิน `f` ตัว และใบรับรองยืนยันใช้เสียง `q=2f+1` เสียง ข้อความว่า “ผิดพลาดน้อยกว่าหนึ่งในสาม” และ “องค์ประชุมมากกว่าสองในสาม” มาจากแบบจำลองนี้ โปรโตคอลแบบซิงโครไนซ์ แบบอะซิงโครนัสที่สุ่ม แบบทนต่อการหยุดทำงาน เชน Proof of Work และโครงสร้าง BFT อื่นอาจมีสมมติฐานและขีดจำกัดต่างกัน

ในระบบถ่วงน้ำหนักด้วยสเตก ขีดจำกัดหมายถึงอำนาจลงคะแนนที่โปรโตคอลกำหนด ไม่จำเป็นต้องเท่ากับจำนวนผู้ตรวจสอบ ที่อยู่ บุคคล หรือผู้ดำเนินการอิสระ ก่อนใช้สัดส่วนต้องระบุเวอร์ชันโปรโตคอล สแนปช็อตน้ำหนัก ประเภทการตัดสิน สมมติฐานเครือข่าย การเปรียบเทียบองค์ประชุม (`>` หรือ `>=`) และพฤติกรรมความผิดพลาด

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

## วิธีทำงาน

1. **กำหนดสิ่งที่ตัดสิน** ตรวจว่าผู้เข้าร่วมกำลังเรียงธุรกรรม ยืนยันบล็อก ทำให้จุดตรวจสอบสิ้นสุด เลือกผู้นำ ยอมรับการเปลี่ยนสถานะ หรือเลือกฟอร์ก การตัดสินเหล่านี้ใช้แทนกันไม่ได้
2. **ระบุแบบจำลองระบบและฝ่ายตรงข้าม** บันทึกสมาชิก การยืนยันตัวตน การเปลี่ยนสิทธิ์ น้ำหนัก การยึดครองแบบปรับตัว กุญแจรั่ว การลงคะแนนขัดแย้ง การหยุดทำงาน ข้อความสูญหาย การเซ็นเซอร์ การปฏิเสธบริการ และความผิดพลาดที่อาจสัมพันธ์กัน
3. **ระบุแบบจำลองเครือข่าย** แยกการซิงโครไนซ์ การซิงโครไนซ์บางส่วน และอะซิงโครนัส สำหรับแบบบางส่วน ให้ระบุว่าสิ่งใดรับประกันเฉพาะหลังเวลาที่เครือข่ายเสถียรซึ่งไม่ทราบล่วงหน้า และปรับเวลาหมดอายุอย่างไร
4. **คำนวณกฎองค์ประชุม** ใช้ขีดจำกัดและกฎล็อกหรือลงคะแนนที่แน่นอน ในกรณีดั้งเดิม `n=3f+1` องค์ประชุม `2f+1` สองชุดตัดกันอย่างน้อย `f+1` รีพลิกา เมื่อมีรีพลิกาไบแซนไทน์ไม่เกิน `f` จุดตัดย่อมมีรีพลิกาที่ซื่อสัตย์
5. **ติดตามทุกขั้นและใบรับรอง** ตรวจข้อเสนอ เสียง ล็อก การเปลี่ยนมุมมองหรือรอบ การยืนยัน การเลือกฟอร์ก และการกู้คืน เสียงข้างมากพิเศษที่ลงนามมีความหมายต่อเมื่อตรวจความสูง รอบ ค่า พาเรนต์ โดเมน ยุคสมาชิก และใบรับรองก่อนหน้าแล้ว
6. **แยกหลักฐานความปลอดภัยและความก้าวหน้า** พิสูจน์ว่าการตัดสินที่ขัดแย้งใดถูกกันออกทุกช่วงที่เกี่ยวข้อง แล้วทดสอบว่ากลับมาก้าวหน้าเมื่อสมมติฐานด้านการสื่อสารและการมีส่วนร่วมที่ซื่อสัตย์เป็นจริง เวลาหมดอายุเป็นเครื่องมือจัดตาราง ไม่ใช่หลักฐานว่าเพื่อนที่เงียบมีเจตนาร้าย
7. **ตรวจการใช้งานและการปฏิบัติการ** เปรียบเทียบความหลากหลายของไคลเอนต์ การเก็บกุญแจ การสลับผู้ลงนาม การป้องกันรีเพลย์ การซิงค์สถานะ การจัดการหลักฐาน การเปลี่ยนสมาชิก การติดตาม นโยบายยืนยันของแอป และการกู้คืนกับแบบจำลองที่พิสูจน์ไว้

ผล FLP ระบุว่าโปรโตคอลฉันทามติแบบกำหนดแน่นอนไม่สามารถรับประกันการจบในแบบจำลองอะซิงโครนัสอย่างสมบูรณ์ แม้มีโอกาสที่กระบวนการเดียวจะหยุดทำงาน ผลนี้ไม่ได้บอกว่าความปลอดภัยเป็นไปไม่ได้หรือฉันทามติแบบกระจายทำงานไม่ได้เลย การซิงโครไนซ์บางส่วน การสุ่ม ตัวตรวจจับความล้มเหลว สมมติฐานทางเศรษฐกิจ หรือการรับประกันที่อ่อนลง เปลี่ยนเงื่อนไขเฉพาะของความเป็นไปไม่ได้ด้วยวิธีต่างกัน

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

## ตัวอย่างการคำนวณ

### 1. รีพลิกาน้ำหนักเท่ากันสี่ตัว

กำหนด `n=4`, `f=1` และ `q=3` ชุดเสียงสามเสียงสองชุดตัดกันอย่างน้อย `3+3-4=2` รีพลิกา เมื่อมีรีพลิกาไบแซนไทน์ไม่เกินหนึ่ง จุดตัดมีรีพลิกาที่ซื่อสัตย์อย่างน้อยหนึ่ง หากกฎของโหนดซื่อสัตย์ห้ามลงคะแนนให้ค่าขัดแย้งในประวัติความสูงและรอบที่เกี่ยวข้อง ใบรับรองยืนยันที่ขัดแย้งกันสองใบจะเกิดพร้อมกันไม่ได้

หากรีพลิกาสองตัวออฟไลน์ จะเหลือเพียง `2` เสียงและสร้างใบรับรอง `q=3` ไม่ได้ นี่เป็นความล้มเหลวด้านความก้าวหน้า ไม่ใช่ความปลอดภัยโดยอัตโนมัติ โปรโตคอลที่ปลอดภัยจะรอแทนการลดขีดจำกัดเฉพาะที่

### 2. รีพลิกาน้ำหนักเท่ากันเจ็ดตัว

กำหนด `n=7`, `f=2` และ `q=5` องค์ประชุมสองชุดตัดกันอย่างน้อย `5+5-7=3=f+1` รีพลิกา เพราะมีไบแซนไทน์ไม่เกิน `2` จุดตัดจึงมีรีพลิกาที่ซื่อสัตย์ รีพลิกาไบแซนไทน์สองตัวสร้างใบรับรองห้าเสียงเองไม่ได้ แต่ถ้าสามตัวไม่พร้อมใช้หรือระงับเสียง จะเหลือเพียง `4` เสียงและหยุดความก้าวหน้าได้

เลขคณิตของขีดจำกัดจำเป็นแต่ไม่เพียงพอ หากการใช้งานที่ซื่อสัตย์รับเสียงจากความสูงผิด ใช้ชุดสมาชิกซ้ำ ละเมิดกฎล็อก หรือลงนามด้วยกุญแจที่รั่ว สมมติฐานในบทพิสูจน์จะไม่ตรงกับระบบที่ใช้งาน

### 3. อำนาจลงคะแนนถ่วงน้ำหนัก

สมมติว่าน้ำหนักคือ `40`, `30`, `20` และ `10` รวม `100` และใบรับรองต้องมากกว่า `2/3` อย่างเคร่งครัด ซึ่งในที่นี้คืออย่างน้อย `67` กลุ่ม `40+30=70` สร้างใบรับรองได้ แต่ `30+20+10=60` ทำไม่ได้แม้มีผู้ตรวจสอบสามในสี่ หากผู้ตรวจสอบน้ำหนัก `40` ออฟไลน์ จะเหลือ `60` และความสิ้นสุดหยุดลง

ชุดที่มีอย่างน้อย `67` สองชุดตัดกันอย่างน้อย `67+67-100=34` ดังนั้นใบรับรองที่ขัดแย้งหมายถึงน้ำหนักอย่างน้อย `34` เข้าร่วมทั้งสองชุด หรือสมมติฐานอื่นล้มเหลว ในบางโปรโตคอล การลงคะแนนขัดแย้งมากกว่าหนึ่งในสามเพียงเล็กน้อยอาจทำลายความปลอดภัยได้ คำว่า “ต้องมีสองในสามจึงโจมตีได้” จึงไม่ใช่ขั้นต่ำสากล

### 4. การซิงโครไนซ์บางส่วนและเวลาหมดอายุ

สมมติเวลาหมดอายุแต่ละรอบเป็น `1 s`, `2 s`, `4 s` และ `8 s` ก่อนเวลาที่เสถียรซึ่งไม่ทราบล่วงหน้า ข้อความอาจมาถึงหลังเวลาหมดอายุปัจจุบันทุกครั้ง ทำให้เปลี่ยนรอบโดยไม่มีการตัดสิน หลังเครือข่ายเสถียร หากความหน่วงต่ำกว่า `3 s` รอบ `4 s` หรือหลังจากนั้นอาจให้เวลาผู้เสนอที่ซื่อสัตย์และองค์ประชุมก้าวหน้า โดยยังต้องเป็นไปตามสมมติฐานอื่น

ตัวเลขนี้แสดงความก้าวหน้าในที่สุด ไม่ใช่สูตรเวลาหมดอายุสากล เวลาสั้นทำให้เปลี่ยนมุมมองโดยไม่จำเป็น เวลายาวทำให้กู้คืนช้า ความปลอดภัยต้องไม่ขึ้นกับการเดาขีดจำกัดความหน่วงก่อนเครือข่ายเสถียร

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

## ความเสี่ยงและข้อผิดพลาดในการตรวจ

### แบบจำลองและบทพิสูจน์

- กล่าวเพียง “BFT” โดยไม่ระบุโปรโตคอล เวอร์ชัน การตัดสิน แบบจำลองความผิดพลาด แบบจำลองเครือข่าย กฎสมาชิก และขีดจำกัด
- ใช้ `n=3f+1` หรือสัดส่วนหนึ่งในสามกับบัญชีแยกประเภทแบบกระจายทุกชนิด แม้บทพิสูจน์ใช้สมมติฐานอื่น
- ปะปนความปลอดภัย ความก้าวหน้า ความถูกต้อง ความพร้อมใช้ ความสอดคล้อง ความสิ้นสุด การเลือกฟอร์ก และความถูกต้องของธุรกรรม
- อ้างว่า FLP ทำให้ฉันทามติเป็นไปไม่ได้โดยตัดเงื่อนไขแบบกำหนดแน่นอน อะซิงโครนัสสมบูรณ์ และรับประกันการจบออก
- นับโหนดหรือที่อยู่เมื่อโปรโตคอลนับสเตก น้ำหนักที่มอบหมาย คณะกรรมการ ยุค หรือทรัพยากรอื่น
- ปัด “สองในสาม” อย่างกำกวมหรือไม่ตรวจว่าการใช้งานใช้ `>`, `>=`, น้ำหนักจำนวนเต็ม หรือสแนปช็อตตัวหารใด
- ตรวจเพียงขนาดองค์ประชุมโดยไม่ตรวจจุดตัด ล็อก ใบรับรอง การเปลี่ยนมุมมอง การปรับสมาชิก และการย้ายสถานะ
- สมมติว่าบทพิสูจน์ครอบคลุมการยึดครองแบบปรับตัว การขโมยกุญแจ ความผิดพลาดสัมพันธ์กัน การปฏิเสธบริการ หรือประวัติระยะไกลโดยไม่มีหลักฐาน

### การใช้งานและการปฏิบัติการ

- รับลายเซ็นที่ไม่ได้ผูกกับเชน โดเมน ความสูง รอบ ค่า พาเรนต์ ยุคสมาชิก และประเภทข้อความ
- เล่นซ้ำเสียงหรือใบรับรองเก่าข้ามรอบ ความสูง ฟอร์ก เครือข่าย การอัปเกรด หรือการเปลี่ยนชุดผู้ตรวจสอบ
- อนุญาตการลงนามซ้ำ การย้อนล็อก การสลับผู้ลงนามที่ไม่ปลอดภัย หรือรีพลิกาที่ทำงานสองตัวใช้ตัวตนผู้ตรวจสอบเดียวกัน
- ถือว่าเวลาหมดอายุเป็นหลักฐานเจตนาร้ายและตัดสินเรื่องความปลอดภัยจากนาฬิกาท้องถิ่นเพียงอย่างเดียว
- มองข้ามความผิดพลาดสัมพันธ์กันจากไคลเอนต์ คลาวด์ ภูมิภาค เครือข่าย ฮาร์ดแวร์ การจัดการกุญแจ หรือผู้ดำเนินการเดียวกัน
- สมมติว่าการตัดสเตกป้องกันความผิดพลาด ฟื้นความก้าวหน้า ย้อนการกระทำที่สิ้นสุดแล้ว หรือชดเชยทุกคน
- ทดสอบเฉพาะการทำงานปกติ ไม่ทดสอบการแบ่งเครือข่าย ความล่าช้า การเรียงใหม่ การลงคะแนนขัดแย้ง ผู้เสนอล้มเหลว การเริ่มใหม่ และการเปลี่ยนสมาชิก

### แอปพลิเคชันและธรรมาภิบาล

- ถือว่าค่าที่ฉันทามติยืนยันเป็นสถานะแอปที่ถูกต้องโดยไม่ดำเนินการแบบกำหนดแน่นอนและตรวจการเปลี่ยนสถานะ
- บันทึกเงินฝาก สร้างสินทรัพย์ผ่านบริดจ์ หรือชำระธุรกรรมก่อนเงื่อนไขความสิ้นสุดที่แอปต้องการอย่างแท้จริง
- ถือว่าความสิ้นสุดของโปรโตคอลเหมือนกับการย้อนกลับไม่ได้ทางสังคมหลังกุญแจรั่ว ซอฟต์แวร์ผิดพลาด หรือธรรมาภิบาลแทรกแซง
- มองข้ามการเซ็นเซอร์และความล่าช้าในการรวม เพราะบล็อกของผู้ใช้อื่นยังคงสิ้นสุด
- อนุมานการกระจายศูนย์ ความปลอดภัยของสินทรัพย์ มูลค่าโทเค็น หรือการบังคับใช้ทางกฎหมายจากป้าย BFT หรือจำนวนผู้ตรวจสอบที่โฆษณา

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

## ความเข้าใจผิดที่พบบ่อย

- **BFT หมายถึงเครือข่ายไม่เคยหยุด** โปรโตคอล BFT จำนวนมากยอมเสียความก้าวหน้าโดยตั้งใจเมื่อมีความผิดพลาดมากเกินไปหรือเครือข่ายแบ่ง เพื่อรักษาความปลอดภัย
- **ผู้เข้าร่วมซื่อสัตย์มากกว่า 51% เพียงพอเสมอ** ขีดจำกัดขึ้นกับโปรโตคอล BFT แบบซิงโครไนซ์บางส่วนดั้งเดิมมักต้องการอำนาจลงคะแนนที่เกี่ยวข้องมากกว่าสองในสามเพื่อก้าวหน้า
- **ผู้โจมตีต้องมีสองในสามเสมอจึงทำลายความปลอดภัยได้** สองในสามสร้างใบรับรองเองได้ แต่ใบรับรองขัดแย้งสองใบอาจเผยการลงคะแนนขัดแย้งเพียงมากกว่าหนึ่งในสามเล็กน้อย
- **ที่อยู่ผู้ตรวจสอบมากขึ้นเพิ่มความทนทานโดยอัตโนมัติ** เจ้าของร่วม การมอบอำนาจ ไคลเอนต์ โครงสร้างพื้นฐาน กุญแจ และขอบเขตความผิดพลาดเป็นตัวกำหนดความเป็นอิสระ
- **การตัดสเตกคือบทพิสูจน์ BFT** นั่นเป็นการตอบสนองทางเศรษฐกิจในระบบ PoS บางระบบ ความปลอดภัยมาจากกฎและสมมติฐาน และบทลงโทษไม่ได้ย้อนผลภายนอก

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

## หัวข้อที่เกี่ยวข้อง

- [ปัญหานายพลไบแซนไทน์](/th/crypto/byzantine-generals-problem/)
- [กลไกฉันทามติ](/th/crypto/consensus-mechanism/)
- [ความสิ้นสุด](/th/crypto/finality/)
- [Proof of Stake](/th/crypto/proof-of-stake/)
- [ผู้ตรวจสอบ](/th/crypto/validator/)

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

## แหล่งข้อมูล

- [The Byzantine Generals Problem](https://lamport.azurewebsites.net/pubs/byz.pdf) - ACM Transactions on Programming Languages and Systems (เข้าถึงเมื่อ: 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 (เข้าถึงเมื่อ: 2026-08-18)
- [Consensus in the Presence of Partial Synchrony](https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf) - Journal of the ACM (เข้าถึงเมื่อ: 2026-08-18)
- [Practical Byzantine Fault Tolerance](https://pmg.csail.mit.edu/papers/osdi99.pdf) - USENIX OSDI (เข้าถึงเมื่อ: 2026-08-18)
- [CometBFT Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT (เข้าถึงเมื่อ: 2026-08-18)
- [HotStuff: BFT Consensus with Linearity and Responsiveness](https://arxiv.org/abs/1803.05069) - arXiv (เข้าถึงเมื่อ: 2026-08-18)
- [Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org (เข้าถึงเมื่อ: 2026-08-18)
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (เข้าถึงเมื่อ: 2026-08-18)

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