---
title: "Hard Fork กับ Soft Fork: ความเข้ากันได้ การเปิดใช้ และการแยกเชน"
description: "Hard fork และ soft fork อธิบายความสัมพันธ์ด้านความเข้ากันได้ที่ต่างกันระหว่างกฎฉันทามติเก่ากับใหม่ ควรวิเคราะห์ชุดบล็อกที่ถูกต้อง การเปิดใช้ การบังคับใช้ของโหนด ผู้ผลิตบล็อก ความพร้อมด้านปฏิบัติการ ความเสี่ยง replay และการแยกเชนที่เกิดขึ้นจริงแยกจากกัน"
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.

# Hard Fork กับ Soft Fork: ความเข้ากันได้ การเปิดใช้ และการแยกเชน

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

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

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

Hard fork และ soft fork จำแนกการเปลี่ยนกฎฉันทามติตามวิธีที่โหนดซึ่งอัปเกรดแล้วและยังไม่อัปเกรดตัดสินบล็อก ให้ `V_old` เป็นชุดบล็อกที่กฎเก่ายอมรับ และ `V_new` เป็นชุดที่กฎใหม่ยอมรับ Soft fork จำกัดความถูกต้องให้ `V_new subset V_old` กล่าวคือทุกบล็อกที่ถูกต้องตามกฎใหม่ย่อมถูกต้องตามกฎเก่าด้วย แต่โหนดเก่าไม่ได้บังคับใช้ข้อจำกัดที่เพิ่มขึ้น Hard fork ยอมรับบล็อกใหม่อย่างน้อยหนึ่งแบบที่โหนดเก่าปฏิเสธ: `exists b: b in V_new and b not in V_old` ชุดกฎของ hard fork อาจเป็นการขยายหรืออาจเปรียบเทียบกันไม่ได้ คำว่า "hard" ไม่ได้หมายถึงแค่บล็อกใหญ่ขึ้นหรือฟังก์ชันที่รุนแรงกว่า

ความเข้ากันได้นี้ไม่สมมาตร เมื่อ soft fork สำเร็จ โหนดที่ยังไม่อัปเกรดสามารถอยู่บนเชนเดียวกัน เพราะยอมรับบล็อกจากนักขุดหรือผู้ตรวจสอบที่อัปเกรดแล้ว แต่โหนดเก่าอาจยอมรับสิ่งที่โหนดใหม่ปฏิเสธและจึงให้หลักประกันที่อ่อนกว่า สำหรับ hard fork เมื่อผู้ผลิตที่อัปเกรดสร้างบล็อกนอกชุดเดิม โหนดเก่าจะตามไม่ได้ หากผู้มีบทบาททางเศรษฐกิจสนับสนุนกฎทั้งสองชุด อาจเกิดสองเครือข่ายที่คงอยู่ แต่หากด้านหนึ่งไม่มีแรงสนับสนุนจริงก็ไม่จำเป็นต้องมีสินทรัพย์สองรายการ

คำเรียกเหล่านี้อธิบายกฎ ไม่ได้บอกความชอบธรรมของธรรมาภิบาล ความปลอดภัย การสนับสนุนทางเศรษฐกิจ หรือวิธีเปิดใช้ ข้อเสนออาจเรียกว่า hard fork ก่อนเปิดใช้ การเปลี่ยนที่เปิดใช้แล้วอาจไม่ทำให้แยกถาวร และความไม่เข้ากันของการติดตั้งที่ไม่ได้ตั้งใจอาจแยกเชนโดยไม่มีการลงคะแนน สัญญาณจากผู้ผลิตช่วยประสานความพร้อม แต่ไม่ทำให้บล็อกที่กฎของ full node ปฏิเสธกลายเป็นบล็อกที่ถูกต้อง

อย่าสับสน fork ของฉันทามติกับ fork ชั่วคราวภายใต้กฎเดียวกัน การจัดระเบียบเชนใหม่ fork ของคลังซอฟต์แวร์ หรือการอัปเกรดแอป คำถามด้านปฏิบัติการคือแต่ละโหนด กระเป๋าเงิน ศูนย์ซื้อขาย ผู้รับฝาก Oracle และสัญญาจะยอมรับเครือข่าย ชุดกฎ เงื่อนไขเปิดใช้ และประวัติเชนใด

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

## วิธีวิเคราะห์ fork ของโปรโตคอล

1. **กำหนดตัวตนและขอบเขต.** บันทึก `chain`, `network`, `client version` ข้อเสนอเปิดใช้ บล็อกกำเนิดหรือ checkpoint ที่ final แล้ว แฮชบล็อกปัจจุบัน และเลเยอร์ที่ได้รับผล ชื่อเดียวกันบน testnet, mainnet, execution, consensus หรือแอปอาจหมายถึงกฎต่างกัน
2. **เปรียบเทียบความถูกต้องของฉันทามติ.** แจกแจงกฎบล็อก ธุรกรรม ลายเซ็น การเปลี่ยนสถานะ Gas เวลา finality หรือ fork choice ที่เปลี่ยนไป จัดตัวอย่างเป็น `valid`, `invalid` หรือ `unknown` ในทั้งสองเวอร์ชัน อย่าสรุปความเข้ากันได้จากบันทึกรุ่นเพียงอย่างเดียว
3. **พิสูจน์ความสัมพันธ์ของชุด.** ทดสอบว่าวัตถุที่ถูกต้องตามกฎใหม่ทั้งหมดยังถูกต้องตามกฎเก่าหรือไม่ ถ้าใช่อาจเข้ากันแบบ soft fork แต่หากมีบล็อกใหม่ที่ถูกต้องเพียงหนึ่งบล็อกซึ่งกฎเก่าถือว่าไม่ถูกต้อง โหนดเหล่านั้นต้องเปลี่ยนผ่านแบบ hard fork และต้องทดสอบวัตถุที่เคยถูกต้องแต่กฎใหม่ปฏิเสธด้วย
4. **ทำซ้ำกระบวนการเปิดใช้.** ตรวจสอบความสูง epoch เวลามัธยฐาน เกณฑ์สัญญาณ ระยะหน่วง lock-in เงื่อนไข total difficulty หรือตัวกระตุ้นธรรมาภิบาลจากข้อกำหนดและโค้ดที่ใช้งาน สัญญาณ lock-in การเปิดใช้ และการบังคับใช้เป็นคนละสถานะ
5. **ทำแผนที่พฤติกรรมผู้มีส่วนร่วม.** วัดน้ำหนักการผลิตบล็อกที่อัปเกรด และระบุ full node, relay, กระเป๋าเงิน ศูนย์ซื้อขาย ผู้รับฝาก Bridge ผู้ออก stablecoin, Oracle และสัญญาของแต่ละด้าน Hashrate หรือ stake เพียงอย่างเดียวไม่ได้กำหนดการยอมรับทางเศรษฐกิจ
6. **ติดตามการแยกและธุรกรรม.** ติดตามแฮชของบล็อกแม่และความถูกต้องตามกฎทั้งสอง ตรวจสอบนโยบายการยืนยัน ความต่างของ mempool การป้องกัน replay รูปแบบที่อยู่ ตัวระบุเชน โดเมนลายเซ็น เส้นทางถอน และธุรกรรมจะทำงานบนทั้งสองสาขาหรือไม่
7. **กำหนดการควบคุมปฏิบัติการ.** หยุดหรือยืดเวลาชำระเมื่อสายบรรพบุรุษไม่ชัดเจน อัปเกรดและสำรองข้อมูลอย่างรอบคอบ กระทบยอดคงเหลือและหนี้สินแยกตามสาขา ทดสอบการลงนามและกู้คืนแบบออฟไลน์ และเริ่มใหม่เมื่อผ่านเกณฑ์เชน โหนด คู่สัญญา และ finality ที่ระบุไว้

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

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

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

### 1. ความเข้ากันได้ของชุดที่ถูกต้อง

สมมติว่ากฎเก่ายอมรับรูปแบบบล็อก `100` แบบ และกฎใหม่ยอมรับเพียง `80` แบบ หาก `80` แบบนั้นอยู่ภายในชุดเก่าทั้งหมด ความสัมพันธ์เป็น soft fork ส่วนรูปแบบเดิมที่เหลือ `20` แบบถูกโหนดใหม่ปฏิเสธ ตัวเลขนี้อธิบายชุด ไม่ใช่ความน่าจะเป็นหรือเกณฑ์ลงคะแนน

ต่อไปสมมติว่ากฎใหม่ยอมรับรูปแบบบล็อกที่โหนดเก่าทุกตัวปฏิเสธ แม้บล็อกอื่นเกือบทั้งหมดจะถูกต้องตามกฎทั้งสอง ตัวอย่างค้านเพียงหนึ่งรายการก็ทำลายการยอมรับย้อนหลังและทำให้การเปลี่ยนไม่เข้ากันแบบ hard fork การแยกจะคงอยู่หรือไม่ขึ้นอยู่กับผู้ผลิต ผู้ใช้ และโครงสร้างพื้นฐานหลังบล็อกนั้นปรากฏ

### 2. การเปิดใช้ BIP 34 ไม่ใช่คำนิยาม

`BIP 34` กำหนดให้ใส่ความสูงบล็อกในธุรกรรม coinbase และใช้กลไกความพร้อมแบบเลื่อน เมื่อ `750 of 1,000` บล็อกก่อนหน้าเป็นเวอร์ชัน 2 ขึ้นไป โหนดปฏิเสธบล็อกเวอร์ชัน 2 ที่ไม่ถูกต้อง หลัง `950 of 1,000` โหนดปฏิเสธเวอร์ชัน 1 และ BIP ระบุว่าบล็อก `227,835` เป็นบล็อกเวอร์ชัน 1 สุดท้าย

เกณฑ์เหล่านี้ประสานการนำไปใช้ แต่ไม่ได้เป็นเหตุผลที่ทำให้เป็น soft fork ความเข้ากันได้มาจากโหนดใหม่จำกัดสิ่งที่ยอมรับ ขณะที่ไคลเอนต์เก่ายังยอมรับบล็อกที่ทำตามกฎ ต่อมา `BIP 9` แยกสถานะการนำไปใช้กับ version bit ชัดเจน แสดงว่าความสัมพันธ์ของกฎและกลไกเปิดใช้เป็นคนละเรื่อง

### 3. Segregated Witness ในรูปแบบ soft fork

`BIP 141` เพิ่มข้อมูล `witness` และผูก commitment ของต้นไม้ข้อมูลผ่านธุรกรรม coinbase เข้ากับโครงสร้าง commitment เดิม โหนดเก่ายอมรับบล็อกที่ทำตามกฎได้โดยไม่เข้าใจหรือตรวจสอบกฎ witness ใหม่ ขณะที่โหนดที่อัปเกรดบังคับใช้กฎนั้น

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

### 4. DAO Fork ของ Ethereum

EIP-779 บันทึก DAO Fork ที่บล็อก mainnet `1,920,000` เป็นการเปลี่ยนสถานะแบบไม่ปกติซึ่งย้ายยอดคงเหลือจากรายชื่อบัญชี `L` ไปยังสัญญา `WithdrawDAO` โดยไม่เปลี่ยน opcode ของ EVM รูปแบบธุรกรรม หรือโครงสร้างบล็อก

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

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

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

### ข้อผิดพลาดด้านการจำแนกและข้อกำหนด

- เรียกปลายเชนคู่แข่งชั่วคราวทุกครั้งว่า hard fork ทั้งที่ทุกโหนดใช้กฎเดียวกันและ fork choice ปกติแก้ได้
- นิยามการผ่อนกฎทั้งหมดเป็น hard fork และการจำกัดทั้งหมดเป็น soft fork โดยไม่ทดสอบชุดบล็อกที่ถูกต้องจริง
- ถือว่าการยอมรับย้อนหลังเท่ากับความปลอดภัยเต็มรูปแบบ ทั้งที่โหนดเก่าไม่บังคับข้อจำกัดใหม่
- อนุมานฉันทามติจากชื่อแบรนด์ roadmap บันทึกรุ่น หรือสาขาคลังโค้ด แทนโค้ดและพารามิเตอร์ที่ใช้งานจริง
- ปะปนการอัปเกรด mainnet, testnet, execution, consensus, Bridge, Rollup และแอป
- ถือว่าข้อเสนอ รุ่นไคลเอนต์ เกณฑ์สัญญาณ lock-in และการเปิดใช้เป็นเหตุการณ์เดียวกัน
- ถือสัญญาณของผู้ผลิตเป็นคะแนนเสียงที่ผูกมัดผู้ใช้ ศูนย์ซื้อขาย ผู้รับฝาก หรือ full node

### ความเสี่ยงด้านการแยกและธุรกรรม

- สมมติว่าการเปิดใช้รับประกันการแยก หรือการแยกรับประกันสินทรัพย์สองรายการที่มีสภาพคล่องและคงอยู่
- ใช้เพียงความสูงทั้งที่สาขาอาจมีบล็อกต่างกันที่ความสูงเดียวกัน ต้องตรวจแฮชและบรรพบุรุษ
- ส่งธุรกรรมระหว่างแยกโดยไม่ตรวจ replay protection ตัวระบุเชน โดเมนลายเซ็น และการสร้างธุรกรรมเฉพาะสาขา
- รับรองเงินฝากบนสาขาหนึ่ง แต่ชำระหนี้สินหรือถอนบนอีกสาขา
- พึ่ง explorer, RPC หรือป้ายผู้รับฝากเพียงรายเดียว ทั้งที่ผู้ให้บริการอาจใช้กฎต่างกันหรือล่าช้า
- ละเลยการจัดระเบียบใหม่ finality ที่หยุดชะงัก การแบ่ง peer การขุดส่วนน้อย การลงคะแนนขัดแย้ง หรือข้อมูลไม่พร้อมใช้
- สมมติว่า ticker ที่อยู่สัญญา ยอด stablecoin ราคา Oracle หรือสิทธิจาก Bridge มีการรับรองจากผู้ออกรายเดียวกันบนทั้งสองสาขา

### ความเสี่ยงด้านธรรมาภิบาลและปฏิบัติการ

- นำเสนอความเข้ากันได้เป็นหลักฐานว่าการเปลี่ยนชอบธรรม กระจายศูนย์ ปลอดภัย หรือมีแรงสนับสนุนทางเศรษฐกิจ
- อัปเกรดโหนดจริงโดยไม่มี binary ที่สร้างซ้ำได้ ข้อมูลสำรอง ขอบเขต rollback การทดสอบย้ายฐานข้อมูล และการตรวจแฮชอิสระ
- สมมติว่าการ downgrade ปลอดภัยเสมอหลังเพิ่มข้อมูลสถานะ รูปแบบกระเป๋าเงิน หรือเงื่อนไข slashing ใหม่
- ย้าย private key หรือ "รับเหรียญจาก fork" ด้วยซอฟต์แวร์ที่ไม่ตรวจสอบ ซึ่งอาจเปิดเผยความลับหรือ replay ลายเซ็น
- ถือยอด snapshot ว่าใช้จ่ายได้ทันทีโดยไม่ตรวจระยะรอ การล็อก สถานะสัญญา และนโยบายผู้รับฝาก
- สรุปภาษี บัญชี หรือมูลค่าก่อนกำหนดความเป็นเจ้าของ การควบคุม สภาพคล่อง และกฎท้องถิ่น

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

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

- **Hard fork สร้างเหรียญใหม่เสมอ.** สินทรัพย์ที่สองต้องมีการผลิตบล็อกต่อเนื่อง ผู้ใช้ โครงสร้างพื้นฐาน และตลาด การอัปเกรดจำนวนมากจบที่ประวัติเดียว
- **Soft fork ไม่มีความเสี่ยงเพราะโหนดเก่ายังทำงาน.** โหนดอาจตามเชนได้แต่ไม่บังคับกฎใหม่และให้การตรวจสอบที่อ่อนกว่า
- **เสียงข้างมากของ hashrate หรือ stake เปลี่ยนกฎใดก็ได้เอง.** Full node ปฏิเสธบล็อกที่ผิดกฎของตน น้ำหนักมีผลเฉพาะระหว่างบล็อกที่ยอมรับ
- **Hard หมายถึงมีข้อขัดแย้ง ส่วน soft หมายถึงเห็นพ้องทั้งหมด.** คำนี้จำแนกความเข้ากันได้ ไม่ใช่ฉันทามติทางสังคมหรือคุณภาพธรรมาภิบาล
- **ทุก fork ใน explorer คือการอัปเกรดโปรโตคอล.** บล็อกคู่แข่งที่ใช้กฎเดียวกันและการจัดระเบียบใหม่เกิดได้โดยไม่เปลี่ยนกฎฉันทามติ

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

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

- [กลไกฉันทามติ](/th/crypto/consensus-mechanism/)
- [Full node](/th/crypto/full-node/)
- [กฎ fork choice](/th/crypto/fork-choice-rule/)
- [การจัดระเบียบเชนใหม่](/th/crypto/chain-reorg/)
- [Bitcoin](/th/crypto/bitcoin/)

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

## แหล่งที่มา

- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (เข้าถึงเมื่อ: 2026-08-19)
- [Bitcoin Developer Guide: Block Chain](https://developer.bitcoin.org/devguide/block_chain.html) - Bitcoin Project (เข้าถึงเมื่อ: 2026-08-19)
- [BIP 34: Block v2, Height in Coinbase](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki) - Bitcoin BIPs (เข้าถึงเมื่อ: 2026-08-19)
- [BIP 66: Strict DER signatures](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki) - Bitcoin BIPs (เข้าถึงเมื่อ: 2026-08-19)
- [BIP 9: Version bits with timeout and delay](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki) - Bitcoin BIPs (เข้าถึงเมื่อ: 2026-08-19)
- [BIP 141: Segregated Witness (Consensus layer)](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) - Bitcoin BIPs (เข้าถึงเมื่อ: 2026-08-19)
- [BIP 50: March 2013 Chain Fork Post-Mortem](https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki) - Bitcoin BIPs (เข้าถึงเมื่อ: 2026-08-19)
- [EIP-779: Hardfork Meta: DAO Fork](https://eips.ethereum.org/EIPS/eip-779) - Ethereum Improvement Proposals (เข้าถึงเมื่อ: 2026-08-19)

Source: https://wiki.fcontext.com/th/crypto/hard-fork-soft-fork/index.mdx