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

# กลไกฉันทามติ: ความถูกต้อง การเลือกฟอร์ก และ finality

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

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

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

กลไกฉันทามติคือโปรโตคอลที่ทำให้สำเนาระบบซึ่งไม่ขัดข้องบรรลุการตัดสินที่สอดคล้องกันเกี่ยวกับบันทึกตามลำดับหรือสถานะ แม้มีความล่าช้า การทำงานพร้อมกัน และความขัดข้องที่แบบจำลองครอบคลุม ในบล็อกเชน กลไกที่สมบูรณ์อาจรวมการเลือกผู้เสนอ การตรวจบล็อกและการเปลี่ยนสถานะ คะแนนเสียงหรือหลักฐาน การเลือกฟอร์ก การ commit หรือ finality การกู้คืน และกฎสมาชิก กลไกนี้ไม่ใช่เพียง “คอมพิวเตอร์หลายเครื่องเก็บไฟล์เดียวกัน” เกณฑ์คะแนนเสียง การขุด staking หรือตารางแรงจูงใจอย่างใดอย่างหนึ่ง

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

ความถูกต้องของธุรกรรมกับการเลือกประวัติอย่างเป็นทางการเป็นคนละเรื่อง โหนดเต็มจะปฏิเสธการเปลี่ยนสถานะที่ฝ่าฝืนกฎปัจจุบันด้วยตนเอง หากธุรกรรมสองรายการที่แต่ละรายการถูกต้องใช้ input เดียวกัน การเรียงลำดับหรือการเลือกฟอร์กจะตัดสินว่ารายการใดเข้าในประวัติอย่างเป็นทางการ ทรัพยากรเสียงข้างมากทำให้ทั้งสองรายการถูกต้องพร้อมกันไม่ได้ เช่นเดียวกัน การตกลงบนไบต์ไม่ได้พิสูจน์ว่าข้อเท็จจริงจาก oracle คำกล่าวอ้างของบริดจ์ การคำนวณแอป หรือข้ออ้างทางกฎหมายเป็นจริง

Proof of Work และ Proof of Stake มักให้การต้านทาน Sybil อิทธิพลในการเสนอ หรือน้ำหนักคะแนนที่ระบุความรับผิดได้ แต่ชื่อของมันไม่ได้กำหนดโปรโตคอลฉันทามติทั้งหมด Bitcoin ผสาน proof of work กับการตรวจสอบและการเลือกเชนตามงานสะสม Gasper ของ Ethereum ผสาน attestation ถ่วงน้ำหนักด้วย stake การเลือก LMD-GHOST และ finality ของ checkpoint แบบ Casper FFG ส่วน BFT แบบเป็นรอบอย่าง CometBFT มีข้อความ เกณฑ์ สมมติฐานเวลา และ finality ต่างกัน อัตราร้อยละเหล่านี้ใช้แทนกันไม่ได้

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

## วิธีวิเคราะห์

1. **ระบุการตัดสินและขอบเขต** บอกว่าสำเนาระบบตัดสินค่าเดียว บันทึกธุรกรรมตามลำดับ บล็อกในแต่ละความสูง checkpoint หรือสถานะแอป พร้อมระบุเชน เครือข่าย เลเยอร์ เวอร์ชัน และจุดเริ่มที่เชื่อถือ
2. **กำหนดผู้เข้าร่วมและอิทธิพล** แยกผู้เสนอ ผู้ลงคะแนน โหนดตรวจสอบเต็ม ไคลเอนต์เบา และผู้สังเกต บันทึกวิธีเข้าออกของตัวตน อิทธิพลอิงพลังแฮช stake สมาชิกเท่ากัน หรือน้ำหนักอื่น และสิ่งที่ป้องกันการสร้างตัวตนซ้ำราคาถูก
3. **แยกขั้นตอนโปรโตคอล** บันทึกความถูกต้องของธุรกรรมและสถานะ การสร้างและกระจายข้อเสนอ คะแนนหรือหลักฐาน การเลือกฟอร์ก commit finality และการกู้คืน บล็อกที่ถูกต้องอาจแพ้การเลือกฟอร์ก และหัวเชนอย่างเป็นทางการอาจยังไม่ final
4. **ระบุแบบจำลองระบบ** กำหนดช่องทางที่ยืนยันตัวตน ความซิงโครนัสหรือบางส่วน สมมติฐานความล่าช้าและหมดเวลา การหยุดทำงานและความขัดข้องแบบไบแซนไทน์ การส่งคะแนนขัดแย้ง การละเว้น การยึดครองแบบปรับตัว การขโมยกุญแจ การแบ่งเครือข่าย และจำนวนหรือน้ำหนักที่ขัดข้องสูงสุด `f`
5. **ติดตามการตัดสินหนึ่งครั้ง** ไล่ตามโดเมนข้อความ ความสูง รอบ พาเรนต์ ล็อก ใบรับรอง และสถานะเฉพาะที่จากข้อเสนอถึงการตัดสิน แสดงการจัดการเมื่อข้อความมาช้า ผู้เสนอส่งข้อเสนอขัดแย้ง รอบหมดเวลา หรือมีสองสาขาที่ถูกต้อง
6. **ตรวจ safety และ liveness แยกกัน** หาเงื่อนไขจุดตัด quorum การเติบโตของเชน หรือเงื่อนไขอื่นด้วยชุดผู้เข้าร่วมและภาพน้ำหนักที่ตรงกัน จากนั้นทดสอบว่าเหลือการเชื่อมต่อและการมีส่วนร่วมที่ซื่อสัตย์พอให้เดินหน้าหรือไม่ อย่าสรุป liveness จากเกณฑ์ safety
7. **จับคู่บทพิสูจน์กับการใช้งานจริง** ตรวจเวอร์ชันไคลเอนต์ การเปลี่ยนพารามิเตอร์ การกระจุกของสมาชิกและ stake การดูแลกุญแจ ความหลากหลายของ peer บทบาท builder หรือ sequencer checkpoint กฎ weak subjectivity การจัดการ reorg และนโยบายยืนยันของแอป

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

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

## ตัวอย่างพร้อมวิธีคิด

### 1. ความถูกต้องไม่ใช่ลำดับอย่างเป็นทางการ

ผลลัพธ์ที่ยังไม่ใช้ `U` มีค่า 1 BTC ธุรกรรม `T_B` ใช้มันจ่ายให้ Bob ส่วน `T_C` ใช้ผลลัพธ์เดียวกันจ่ายให้ Carol เมื่อเทียบกับสถานะพาเรนต์เดียวกัน แต่ละรายการอาจมีลายมือชื่อและรูปแบบถูกต้อง แต่ประวัติที่ถูกต้องใช้ `U` สองครั้งไม่ได้

หากบล็อกถูกต้องสองบล็อกที่แข่งขันกันมีธุรกรรมคนละรายการ การตรวจสอบจะเก็บทั้งสองสาขาเป็นตัวเลือกไว้เฉพาะที่ และการเลือกฟอร์กเลือกสาขาอย่างเป็นทางการ เมื่อ `T_B` เข้าในประวัติที่เลือก `T_C` จะขัดกับสถานะผลลัพธ์ ฉันทามติเลือกลำดับ ไม่ได้เปลี่ยนลายมือชื่อผิดให้ถูกหรือตัดสินว่าใครสมควรได้รับเงินในทางศีลธรรม

### 2. งานสะสม ไม่ใช่จำนวนโหนด

สมมติว่าสาขาที่ถูกต้องแบบ Bitcoin สองสาขามีคะแนนงานสะสม `W_A=240` และ `W_B=235` ในหน่วยสมมติเดียวกัน โหนดตรวจสอบเลือก A ตามกฎงานสะสม แม้ได้ยิน B ก่อนจาก peer มากกว่า จำนวน peer ไม่ใช่น้ำหนักฉันทามติ

หากต่อมา B เพิ่มงาน 10 หน่วยแต่ A ไม่เพิ่ม จะเป็น `W_B=245` เทียบกับ `W_A=240` และโหนดอาจจัดสายใหม่ไป B หลังตรวจสาขา เลขอย่างง่ายนี้แสดงว่า confirmation แบบ PoW เป็นเชิงความน่าจะเป็น ประวัติที่ลึกขึ้นมีต้นทุนแทนที่สูงขึ้นเรื่อย ๆ ไม่ได้ย้อนกลับไม่ได้ในเชิงตรรกะหลังจำนวนบล็อกตายตัว

### 3. Quorum BFT ถ่วงน้ำหนักกับการหยุดของ liveness

กำหนดน้ำหนัก validator รวม `100` และการ commit แบบ CometBFT ต้องมี precommit `>2/3` ให้บล็อกเดียวกันในความสูงและรอบเดียวกัน น้ำหนักจำนวนเต็ม `67` ผ่าน quorum น้ำหนัก 67 สองชุดจะตัดกันอย่างน้อย `34` เพราะ 67 + 67 - 100 = 34 หากน้ำหนักไบแซนไทน์ต่ำกว่าหนึ่งในสาม จุดตัดจะมีน้ำหนักซื่อสัตย์ซึ่งตามโปรโตคอลต้องไม่ลงนาม commit ที่ขัดแย้งกัน

เกณฑ์เดียวกันเผยขอบเขต liveness หากน้ำหนัก 34 ออฟไลน์ จะเหลือ `66` และสร้าง commit ไม่ได้ แม้ validator ออนไลน์ทั้งหมดซื่อสัตย์ โปรโตคอลหยุดโดยยังรักษา safety ได้ คะแนนธรรมาภิบาลหรือจำนวนผู้ให้บริการแทนน้ำหนักฉันทามติที่หายไปไม่ได้

### 4. การเลือกฟอร์กกับ finality ของ checkpoint ต่างกัน

ในลำดับ Gasper แบบย่อ กำหนด checkpoint เป็น `C_0` `C_1` และลูกโดยตรง `C_2` คะแนนซึ่งแทนยอดคงเหลือที่มีผลและทำงานอยู่ `67/100` สามารถสร้างลิงก์ supermajority จาก `C_0` ไป `C_1` ทำให้ `C_1` justified ลิงก์ถัดไปที่ผ่านเกณฑ์จาก `C_1` ไป `C_2` สามารถทำให้ checkpoint ก่อนหน้า final ตามกฎ FFG ที่ใช้

ระหว่าง checkpoint นั้น LMD-GHOST ใช้ attestation ล่าสุดของ validator เลือกหัวเชนจากลูกหลานที่เป็นไปได้ของ checkpoint ที่ justified ส่วนข้อจำกัด checkpoint ที่ final จะกรองสาขาขัดแย้ง การเลือกหัวเชน justification และ finalization จึงเกี่ยวข้องแต่เป็นคนละการเปลี่ยนสถานะ คำว่า “67% ลงคะแนนให้บล็อกนี้” อธิบายสิ่งใดสิ่งหนึ่งไม่ครบ

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

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

### แบบจำลองและการรับประกัน

- กล่าวว่า “เครือข่ายบรรลุฉันทามติ” โดยไม่กำหนดการตัดสิน safety liveness validity และการยุติ
- ถือว่า Proof of Work, Proof of Stake, การขุด, staking หรือร้อยละคะแนนเป็นข้อกำหนดโปรโตคอลทั้งหมด
- ใช้ `51%` `2/3` หรือ `n=3f+1` กับทุกแบบจำลองความขัดข้อง เวลา น้ำหนัก และ finality
- ปะปนการหยุด พฤติกรรมไบแซนไทน์ กุญแจถูกขโมย ช่องทางขัดข้อง ซอฟต์แวร์ที่สัมพันธ์กัน และการยึดธรรมาภิบาล
- อ้าง FLP เป็นข้อห้ามฉันทามติจริง แทนผลที่มีขอบเขตแบบกำหนดแน่นอน อะซิงโครนัสเต็มรูปแบบ และรับประกันการยุติ
- นับโหนดหรือกุญแจโดยไม่วัดผู้ให้บริการอิสระ น้ำหนัก ไคลเอนต์ คลาวด์ และการดูแลกุญแจ
- สมมติว่าสถานะ official, safe, justified, committed และ finalized ใช้แทนกันได้
- สรุปความจริงภายนอก ลำดับยุติธรรม ความเป็นส่วนตัว การกระจายศูนย์ หรือมูลค่าจากการตกลงของสำเนา

### โปรโตคอลและการติดตั้ง

- รับบล็อกหรือคะแนนที่ไม่ผูกกับเชน เวอร์ชัน ความสูง รอบ พาเรนต์ payload ผู้ส่ง และยุคสมาชิก
- ปล่อยให้การติดตั้งต่างกันเรื่องการเปลี่ยนสถานะ serialization โดเมนลายมือชื่อ การเลือก กฎกรณีเสมอ หรือการปัดเศษ
- ตรวจใบรับรอง quorum โดยไม่สร้างภาพน้ำหนักที่มีสิทธิและวิธีจัดการผู้ลงนามซ้ำ
- เล่นซ้ำคะแนน งาน หรือใบรับรองข้ามฟอร์ก เครือข่าย รอบ การอัปเกรด หรือการเปลี่ยนชุด validator
- อัปเดตล็อก checkpoint ที่ justified หรือใบรับรองสูงสุดผิดระหว่างหมดเวลา เปลี่ยนมุมมอง หรือกู้คืน
- ถือว่าหัวเชนที่เห็นเฉพาะที่หรือป้ายจาก RPC ตัวเดียวเป็นหลักฐานอิสระของ finality เครือข่าย
- ทดสอบเฉพาะเส้นทางปกติ ไม่ทดสอบความล่าช้า การแบ่งเครือข่าย การส่งคะแนนขัดแย้ง ข้อเสนอไม่ถูกต้อง reorg และการกู้คืน

### การใช้งานและแอปพลิเคชัน

- กระจุกพลังแฮช stake ไคลเอนต์ relay builder sequencer คลาวด์ หรือระบบลงนามไว้หลังตัวตนที่ดูแยกกัน
- ตั้งเวลาหมดหรือช่วงบล็อกสั้นกว่าเวลาส่งต่อและตรวจจริง ทำลาย liveness หรือเพิ่มฟอร์ก
- ให้เครดิตเงินฝาก สร้างสินทรัพย์บริดจ์ หรือทำสิ่งที่ย้อนกลับไม่ได้ก่อน finality ของต้นทางและแอปที่ต้องการ
- สมมติว่า slashing รางวัล หรือราคาโทเค็นสร้างงบความปลอดภัยที่พอและเปลี่ยนเป็นเงินได้เสมอ
- ใช้ social recovery หรือธรรมาภิบาลโดยไม่ยอมรับว่าใครประสานงาน ไคลเอนต์ติดตั้งเชนใด และการรับประกันเดิมใดเปลี่ยนไป

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

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

- **ฉันทามติกับการตรวจสอบเหมือนกัน** การตรวจสอบปฏิเสธข้อมูลที่ผิดกฎ ส่วนฉันทามติเลือกการตัดสินที่สอดคล้องกันจากตัวเลือกซึ่งอาจถูกต้องเฉพาะที่
- **โหนดมากขึ้นปลอดภัยขึ้นโดยอัตโนมัติ** อิทธิพล ความเป็นอิสระ โทโพโลยี ความหลากหลายของซอฟต์แวร์ และแบบจำลองความขัดข้องสำคัญกว่าจำนวนดิบ
- **ผู้โจมตี 51% ปลอมลายมือชื่อใครก็ได้** ทรัพยากรเสียงข้างมากอาจเปิดทางให้เซ็นเซอร์หรือ reorg ในบางโปรโตคอล แต่ไม่เปิดเผยกุญแจหรืออนุญาตการใช้จ่ายที่ไม่ถูกต้อง
- **สองในสามหมายถึง finality เสมอ** อสมการ ข้อความ รอบ ภาพน้ำหนัก กฎล็อก และเงื่อนไข finality ขึ้นอยู่กับโปรโตคอล
- **บล็อกเร็วพิสูจน์ฉันทามติแข็งแรง** ช่วงสั้นอาจเพิ่มการแข่งขันการส่งต่อและแรงกดดันทรัพยากร ต้องประเมิน latency ร่วมกับ safety liveness และ finality

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

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

- [ความทนทานต่อความขัดข้องแบบไบแซนไทน์](/th/crypto/byzantine-fault-tolerance/)
- [ปัญหานายพลไบแซนไทน์](/th/crypto/byzantine-generals-problem/)
- [Finality](/th/crypto/finality/)
- [กฎการเลือกฟอร์ก](/th/crypto/fork-choice-rule/)
- [Proof of Stake](/th/crypto/proof-of-stake/)

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

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

- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (เข้าถึงเมื่อ: 2026-08-19)
- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (เข้าถึงเมื่อ: 2026-08-19)
- [Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org (เข้าถึงเมื่อ: 2026-08-19)
- [Ethereum Consensus Specifications: Fork Choice](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/fork-choice.md) - Ethereum Foundation (เข้าถึงเมื่อ: 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 (เข้าถึงเมื่อ: 2026-08-19)
- [Consensus in the Presence of Partial Synchrony](https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf) - Journal of the ACM (เข้าถึงเมื่อ: 2026-08-19)
- [CometBFT Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT (เข้าถึงเมื่อ: 2026-08-19)
- [HotStuff: BFT Consensus in the Lens of Blockchain](https://arxiv.org/abs/1803.05069) - arXiv (เข้าถึงเมื่อ: 2026-08-19)

Source: https://wiki.fcontext.com/th/crypto/consensus-mechanism/index.mdx