ข้ามไปยังเนื้อหา
Financial Context Wiki

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

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

อัปเดต

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

คำตอบโดยตรง

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 และสัญญาจะยอมรับเครือข่าย ชุดกฎ เงื่อนไขเปิดใช้ และประวัติเชนใด

วิธีวิเคราะห์ 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”: ข้อเสนอกฎ เงื่อนไขเปิดใช้ การเบี่ยงออกของเชนที่สังเกตพบ และการอยู่รอดทางเศรษฐกิจของหนึ่งหรือหลายสาขา ไม่มีเหตุการณ์ใดพิสูจน์เหตุการณ์ถัดไปโดยอัตโนมัติ

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

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 กฎเปลี่ยนสถานะครั้งเดียวก็สร้างความไม่เข้ากันได้ และการสนับสนุนทั้งสองประวัติอย่างต่อเนื่องอาจรักษาสองเครือข่ายไว้

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

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

  • เรียกปลายเชนคู่แข่งชั่วคราวทุกครั้งว่า 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 ว่าใช้จ่ายได้ทันทีโดยไม่ตรวจระยะรอ การล็อก สถานะสัญญา และนโยบายผู้รับฝาก
  • สรุปภาษี บัญชี หรือมูลค่าก่อนกำหนดความเป็นเจ้าของ การควบคุม สภาพคล่อง และกฎท้องถิ่น

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

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

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

แหล่งที่มา

การนำทาง

ค้นหาในวิกิ...