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

กฎเลือกฟอร์ก: สาขาที่ถูกต้อง น้ำหนัก และหัวเชนมาตรฐาน

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

อัปเดต

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

คำตอบโดยตรง

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

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

“เชนที่ยาวที่สุด” ไม่ใช่สูตรสากล Bitcoin เลือกเชนที่ถูกต้องและมีงานมากที่สุด โดยงาน Proof of Work ที่คาดหวังสะสมเป็นตัวตัดสิน ไม่ใช่ความสูงดิบ LMD-GHOST ของ Ethereum เริ่มจากเช็กพอยต์ justified กรองสาขาที่ใช้ได้ แล้วเลือกโหนดลูกที่มียอด attest จากข้อความล่าสุดมากที่สุดแบบ greedy รวม proposer boost ที่ใช้ได้ โดยนับเพียงข้อความล่าสุดที่มีสิทธิ์ของแต่ละ validator โปรโตคอลอื่นอาจใช้ใบรับรองความพร้อมใช้ leader lock, round หรือใบรับรอง commit ที่ชัดเจน แทนการแข่งขันต่อเนื่องของสาขาที่หนักที่สุด

ผลลัพธ์ขึ้นกับอินพุตที่เจาะจง ได้แก่ เชนและเครือข่าย เวอร์ชันฟอร์ก จุดอ้างอิงที่เชื่อถือได้ เวลาหรือ slot ปัจจุบัน บล็อกที่ทราบว่าถูกต้อง ลิงก์ parent สแนปช็อตงานหรือน้ำหนักโหวต ข้อความล่าสุด หลักฐาน equivocation เช็กพอยต์ justified และ finalized สถานะความพร้อมใช้ จังหวะเวลาของ proposer และกฎตัดสินกรณีเสมอแบบกำหนดแน่นอน ป้ายจาก block explorer หรือผล RPC รายการเดียวเป็นเพียงการสังเกตผลของโหนดหนึ่ง ไม่ใช่ตัวกฎหรือหลักฐานอิสระของอินพุต

วิธีวิเคราะห์กฎเลือกฟอร์ก

  1. กำหนดตัวตนและเวอร์ชันให้ชัด บันทึกเชน เครือข่าย consensus fork เวอร์ชัน client, genesis หรือจุดอ้างอิงที่เชื่อถือได้ ความสูงหรือ slot ปัจจุบัน และกฎที่ใช้อยู่จริง อย่านำตรรกะ mainnet ไปใช้กับ testnet, sidechain, rollup หรือข้อเสนอในอนาคต
  2. สร้างกราฟบล็อกที่ยอมรับได้ ตรวจสอบ hash, parent, หลักฐานฉันทามติ การเปลี่ยนสถานะ สถานะ execution payload และความพร้อมใช้ของข้อมูลที่กำหนด ทำเครื่องหมายโหนด unknown, optimistic, invalid และ pruned ให้ชัดเจน เพราะน้ำหนักช่วยสาขาที่ invalid ไม่ได้
  3. สร้างลำดับบรรพบุรุษและข้อจำกัดใหม่ หาบรรพบุรุษร่วมและยืนยันว่าตัวเลือกใดสืบทอดจากเช็กพอยต์ lock หรือใบรับรองที่กำหนด แยกต้นไม้ดิบที่สังเกตเห็นออกจากต้นไม้ที่ผ่านการกรองซึ่งกฎพิจารณาได้จริง
  4. ทำซ้ำอินพุตน้ำหนักทุกตัว สำหรับ PoW ให้ถอดรหัส target และรวม proof ต่อบล็อกเป็น chainwork สะสม สำหรับกฎโหวต ให้ตรวจตัวตน validator, active effective balance หรือน้ำหนักอื่น โดเมนข้อความ root เป้าหมาย slot หรือ epoch การแทนที่ข้อความล่าสุด การจัดการ equivocation และ boost ชั่วคราว
  5. ดำเนินการเลือกและตัดสินเสมอตรงตามข้อกำหนด ใช้ recursion หรือ comparator ที่ระบุในทุกจุดแตกแขนง พร้อมการปัดเศษและลำดับแบบกำหนดแน่นอนของโปรโตคอล บันทึกว่าน้ำหนักเท่ากันอนุญาตเพียงความชอบเฉพาะที่ชั่วคราวหรือไม่ แทนที่จะถือว่าเสมอคือข้อตกลงสุดท้าย
  6. กระทบยอดการเปลี่ยนหัวเชน เมื่อผู้ชนะเปลี่ยน ให้ระบุบล็อกที่ถอดและต่อ ย้อนกลับแล้ว replay สถานะ กระทบยอด receipt, log และ mempool และคำนวณความลึกของการจัดระเบียบใหม่จากบรรพบุรุษร่วม แยกป้าย head, safe, justified, committed และ finalized ออกจากกัน
  7. ทดสอบภาวะกดดันและเฝ้าระวังระบบจริง ทดสอบบล็อกล่าช้าหรือถูกกัก network partition โหวตเก่า equivocation, balancing จังหวะ proposer ความเห็นต่างของ client เช็กพอยต์อ่อน และข้อมูลที่ใช้ไม่ได้ เปรียบเทียบโหนดอิสระและแจ้งเตือนเมื่อหัวเชนแยกผิดคาด เกิดการจัดระเบียบลึก หรือขัดกับสถานะ final ก่อนดำเนินการปลายทางที่ย้อนคืนไม่ได้

ใน Bitcoin Core ปัจจุบัน การจัดลำดับตัวเลือกจะเปรียบเทียบ nChainWork ก่อน ตัวเลือกที่มีงานเท่ากันจึงเรียงตามลำดับแรกสุดที่เปิดใช้งานได้ พร้อมกฎตัดสินสำรองภายใน ฟิลด์ RPC ชื่อ blocks คือความสูงของเชนงานมากที่สุดที่ตรวจสอบสมบูรณ์ ส่วน bestblockhash ระบุ tip ของเชนนั้น ในข้อกำหนด fork choice ปัจจุบันของ Ethereum ฟังก์ชัน get_head(store) เริ่มจาก justified_checkpoint เดินตามต้นไม้ที่กรองแล้ว และเลือกโหนดลูกที่ทำให้ (get_weight(store, child), child.root) สูงสุดในแต่ละขั้น รายละเอียดเหล่านี้เฉพาะเจาะจงต่อโปรโตคอลและเวอร์ชัน ไม่ใช่นิยามทั่วไปของฉันทามติ

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

1. การสลับตามงานสะสมของ Bitcoin

สาขาที่ถูกต้องสองสาขามีบรรพบุรุษร่วม C หัวเชนปัจจุบันมี chainwork(A)=240 และ chainwork(B)=235 โหนดจึงเลือก A แม้หน้าจอความสูงแบบง่ายจะทำให้สองสาขาดูใกล้เคียงกัน บล็อกใหม่ที่ถูกต้องเพิ่มงาน 10 ให้สาขา B:

chainwork(B') = 235 + 10 = 245

เพราะ 245 > 240 สาขา B จึงเป็นตัวเลือกที่มีงานมากที่สุด โหนดตัดบล็อกของ A หลัง C ต่อ B ไปถึง B' และกระทบยอดธุรกรรม จำนวนบล็อกดิบไม่เพียงพอเมื่อ target ต่อบล็อกต่างกัน และงานเท่ากันเป็นเพียงกรณีเสมอชั่วคราว ไม่ใช่หลักฐาน finality

2. ต้นไม้ย่อยที่สังเกตเห็นและหนักที่สุดแบบ greedy

ใช้ต้นไม้ LMD-GHOST แบบง่ายซึ่งมีรากเป็นเช็กพอยต์ justified J โหนดลูกคือ A และ B ข้อความล่าสุดที่มีสิทธิ์ของ validator ให้น้ำหนักทั้งต้นไม้ย่อย A เท่ากับ 61 และต้นไม้ย่อย B เท่ากับ 39 ขั้น greedy แรกจึงเลือก A โดย A มีโหนดลูก A_1 และ A_2 ซึ่งมีน้ำหนักต้นไม้ย่อย 34 และ 27 ขั้นถัดไปจึงเลือก A_1

การหาหัวเชนทำโดยเลือกโหนดลูกที่หนักที่สุดซ้ำ ๆ ไม่ใช่นับความยาวสาขาหรือเลือก leaf ที่มีโหวตตรงแบบแยกเดี่ยวมากที่สุด กฎใช้งานจริงยังมีการกรองความเหมาะสม สแนปช็อต balance การจัดการ equivocation จังหวะ proposer และการตัดสินเสมอ ซึ่งละไว้ในต้นไม้เพื่อการสอนนี้

3. การแทนที่ข้อความล่าสุด

สมมติว่าข้อความล่าสุดที่มีสิทธิ์ให้น้ำหนักสาขา A เริ่มต้น 55 และสาขา B 45 ต่อมา validator ที่มีน้ำหนัก 20 ส่งข้อความใหม่กว่าซึ่งมีสิทธิ์และสนับสนุนลูกหลานของ B การนับข้อความล่าสุดจะถอนแรงสนับสนุนเดิมของ validator จาก A แล้วเพิ่มให้ B:

A: 55 - 20 = 35; B: 45 + 20 = 65

น้ำหนักถูกนับครั้งเดียว ไม่ใช่ทั้งสองสาขา เส้นทางที่เลือกจึงเปลี่ยนได้ นี่ไม่ใช่การอนุญาตให้โหวตขัดแย้งกัน หากหลักฐาน attester slashing ที่ถูกต้องชี้ equivocation ปัจจุบัน store ของ Ethereum จะติดตาม validator ที่ทำผิดและไม่นับน้ำหนักนั้นในคะแนน attest ปกติ

4. การกรองเช็กพอยต์และ proposer boost

สมมติว่าโหนดเห็นน้ำหนักข้อความล่าสุดดิบ 70 บนสาขาที่ขัดกับเช็กพอยต์ finalized ของตน และน้ำหนัก 30 บนลูกหลานที่ใช้ได้ สาขาที่ขัดแย้งจะถูกตัดออกก่อนเลือกหัวเชน เสียงข้างมากจากน้ำหนักดิบไม่สามารถข้ามข้อจำกัดของเช็กพอยต์ finalized ด้วย fork choice ปกติ

ต่อไปพิจารณาโหนดลูกที่ใช้ได้สองโหนดใน slot ปัจจุบัน ซึ่งมีน้ำหนัก attest 35 และ 50 ในค่า Ethereum ที่อ้างถึง proposer boost ที่มาทันเวลามีค่า 40% ของน้ำหนัก committee หนึ่งชุด ไม่ใช่ 40 เปอร์เซ็นต์ของ stake ทั้งหมด หากน้ำหนัก committee เท่ากับ 100 และ boost ใช้กับโหนดลูกน้ำหนัก 35 คะแนนเปรียบเทียบจะเป็น 35 + 40 = 75 จึงชนะ 50 ในขั้นนั้น Boost เป็นของชั่วคราวและเฉพาะ fork ไม่ใช่โหวต validator เพิ่มเติมหรือ finality

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

ชุดตัวเลือกและหลักฐาน

  • เปรียบเทียบน้ำหนักสาขาก่อนตรวจ parent การเปลี่ยนสถานะ หลักฐาน สถานะ payload หรือข้อมูลที่กำหนด
  • ถือ execution ที่ unknown หรือ optimistic ข้อมูลที่ใช้ไม่ได้ หรือมุมมอง headers-only ว่าเป็นสถานะที่ตรวจสอบครบแล้ว
  • ใช้ความสูงบล็อก timestamp จำนวนธุรกรรม fee หรือความนิยมใน explorer แทนน้ำหนักที่โปรโตคอลกำหนด
  • รวม difficulty ที่แสดง แทนการคำนวณ proof ต่อบล็อกและ chainwork สะสมใหม่ภายใต้ target ที่ถูกต้อง
  • นับทุกโหวตในอดีต แทนข้อความล่าสุดที่มีสิทธิ์ของ validator แต่ละรายภายใต้สแนปช็อตน้ำหนักที่ถูกต้อง
  • ละเลยโดเมนข้อความ root, slot, epoch ความตรงเวลา signature, equivocation และหลักฐาน slashing
  • เปรียบเทียบสาขาดิบที่ตัวกรองเช็กพอยต์ lock ใบรับรอง หรือความพร้อมใช้ของโปรโตคอลทำให้ไม่มีสิทธิ์
  • ใช้ข้อกำหนดในอนาคต พารามิเตอร์ของเครือข่ายอื่น หรือการปรับแต่ง implementation เป็นกฎฉันทามติปัจจุบัน

การเลือกและความล้มเหลวในการปฏิบัติงาน

  • อธิบายกฎ Bitcoin ว่าเป็น “ความสูงยาวที่สุด” ดิบ หรือกฎ Ethereum ว่าเป็นโหวตหัวเชนสองในสามแบบง่าย
  • แทน recursion แบบ greedy ของต้นไม้ย่อยด้วยคะแนน leaf ทั่วทั้งต้นไม้ หรือละ proposer boost การปัดเศษ และการตัดสินเสมอด้วย root
  • สมมติว่าโหนดซึ่งมีลำดับรับข้อมูล นาฬิกา หรือมุมมองข้อความต่างกัน ต้องรายงานหัวเชนเดียวกันทันที
  • ไม่ตัดและ replay สถานะ receipt, log, index และรายการ mempool อย่างถูกต้องระหว่างการจัดระเบียบใหม่
  • ปล่อยให้ implementation ของ client เห็นต่างเรื่องความถูกต้อง ความเหมาะสมของเช็กพอยต์ ข้อความล่าสุด เวลา หรือการตัดสินเสมอ
  • พลาดภาวะ balancing, withholding, equivocation, partition, eclipse โหวตล่าช้า และ proposer reorganization
  • เชื่อ RPC, explorer, relay, ตระกูล client, cloud หรือผู้ดำเนินการ validator รายเดียวว่าเป็นมุมมองฉันทามติอิสระ

Finality และความไม่สอดคล้องกับแอปพลิเคชัน

  • เรียกหัวเชนที่เลือกว่า final ย้อนคืนไม่ได้ หรือปลอดภัย โดยไม่มีหลักฐาน finality แยกต่างหากตามโปรโตคอล
  • ปล่อยเงินฝาก ข้อความ bridge หรือการซื้อขายที่ย้อนคืนไม่ได้บนหัวเชนชั่วคราว โดยไม่มีนโยบายตามมูลค่า
  • สมมติว่าบรรพบุรุษ finalized รับประกันความถูกต้องหรือความพร้อมใช้ของทุกหัวเชน payload, oracle หรือผลแอปที่ใหม่กว่า
  • ใช้จำนวน confirmation คงที่กับเชนที่มีโมเดลงาน โหวต เช็กพอยต์ และการกู้คืนต่างกัน
  • ถือเช็กพอยต์ฉุกเฉิน จุดอ้างอิง weak subjectivity หรือ social recovery เป็นอินพุต fork choice ปกติที่ไม่มีขอบเขตความไว้วางใจ

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

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

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

แหล่งข้อมูล

การนำทาง

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