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

Finality ของบล็อกเชน: หลักฐาน สมมติฐาน และชั้นการชำระบัญชี

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

อัปเดต

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

คำตอบโดยตรง

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

ความถูกต้อง สถานะ canonical และ finality เป็นคนละเรื่อง บล็อกที่ถูกต้องต้องผ่านกฎการเปลี่ยนสถานะและการอนุญาต Fork choice เลือก head canonical ปัจจุบันจากตัวเลือกที่ถูกต้อง ส่วนการทำให้ final ใช้เงื่อนไขเพิ่ม เช่น ใบรับรอง commit หรือ checkpoint ที่ final แล้ว กับบรรพบุรุษของ head นั้น ธุรกรรมอาจสำเร็จในบล็อกที่ถูกต้องแต่ภายหลังแพ้ fork choice; head อาจเป็น canonical แต่ยังไม่ final; และเหตุการณ์ที่ final บนเชนต้นทางยังอาจล้มเหลวใน bridge ตลาดซื้อขาย หรือแอปได้

ระบบ Proof of Work มักให้การชำระแบบความน่าจะเป็น ไม่ใช่บิต finality ที่ชัดเจน เมื่อมีงานที่ถูกต้องสะสมเหนือบล็อกมากขึ้น การแทนที่บล็อกมักมีโอกาสน้อยลงและต้นทุนสูงขึ้นภายใต้สมมติฐานเรื่อง hash power และเครือข่าย โปรโตคอลแบบ BFT อาจให้ finality แบบกำหนดแน่นอนภายใต้เงื่อนไข: หลังมีใบรับรอง commit ที่ถูกต้อง การตัดสินใจขัดแย้งสองรายการไม่อาจ commit พร้อมกันได้หากน้ำหนักที่ผิดพลาดต่ำกว่าขอบเขตที่พิสูจน์ไว้ Finality ของ PoS ยังอาจเป็นแบบรับผิดชอบหรือเชิงเศรษฐกิจ เพราะคะแนนเสียงขัดแย้งชี้น้ำหนักที่ slash ได้ คำเหล่านี้อธิบายหลักฐานต่างชนิดกัน

ไม่มีโปรโตคอลใดทำให้ประวัติเปลี่ยนไม่ได้อย่างเด็ดขาด การรั่วไหลของกุญแจครั้งใหญ่ การเกินขอบเขตความผิดพลาด บั๊กไคลเอนต์ การที่ implementation ยอมรับ transition ไม่ถูกต้อง การแทรกแซงด้าน governance หรือ social recovery อาจข้ามขอบเขตแบบจำลองได้ ดังนั้น “finalized” ควรหมายถึงเส้นทาง reorganization ปกติของโปรโตคอลไม่สามารถแทนที่การตัดสินใจนี้ภายใต้สมมติฐานดังกล่าว ส่วนการกู้คืนพิเศษและอำนาจต้องบันทึกแยก

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

  1. ระบุวัตถุและขอบเขต กำหนดว่าเป็นธุรกรรม บล็อก checkpoint, state root ข้อความข้ามเชน หรือการถอน พร้อมบันทึกเชน เครือข่าย ชั้น เวอร์ชัน ความสูงหรือ slot, hash และ checkpoint ที่เชื่อถือ
  2. ตรวจความถูกต้องก่อนสถานะ รันซ้ำหรือตรวจ transition และสายบรรพบุรุษที่เกี่ยวข้อง ด้วยกฎจริง quorum คะแนนงาน หรือป้ายใน UI ไม่อาจทำให้วัตถุไม่ถูกต้อง final ได้
  3. แยกการเลือก head จาก finalization สร้าง fork choice และเส้นทาง canonical ปัจจุบันใหม่ แล้วหา ancestor ที่ finalized หรือ committed บันทึกว่าเพียงสังเกต ยืนยัน justified, safe, committed หรือ finalized
  4. ทำหลักฐานซ้ำได้ สำหรับ PoW ให้ตรวจ header, target และ chainwork สะสมเหนือบล็อก สำหรับโปรโตคอลลงคะแนนให้ตรวจสิทธิผู้ลงนาม snapshot น้ำหนัก domain ข้อความ ต้นทางและเป้าหมาย ความสูง รอบ อสมการ quorum ลายเซ็น lock และสายบรรพบุรุษใบรับรอง
  5. ระบุสมมติฐาน safety และ liveness กำหนดน้ำหนัก Byzantine หรือ offline, synchrony ความล่าช้า การลงคะแนนสองทาง กุญแจรั่ว ความสัมพันธ์ของไคลเอนต์ การเปลี่ยนสมาชิก ความพร้อมของ slashing และสิ่งที่เกิดเมื่อ finalization หยุด ระบบอาจรักษา safety ขณะเสีย liveness
  6. ทำแผนที่ทุกชั้นการชำระ ติดตามการรับของ sequencer การรัน L2 การเผยแพร่ข้อมูล การรวมใน L1, finality ของ L1 การจบ proof หรือ dispute การรันข้อความ bridge การเครดิตของตลาด และการกระทำของแอป ป้ายคล้ายกันต่างชั้นไม่จำเป็นต้องเป็นเงื่อนไขเดียวกัน
  7. กำหนดและเฝ้าดูนโยบายแอป ระบุหลักฐานที่รับได้ตามมูลค่าและผลกระทบ สอบถาม node อิสระ จัดการ reorganization และสัญญาณเตือน finality ขัดแย้ง หยุดการกระทำปลายทางที่ย้อนกลับไม่ได้เมื่อสมมติฐานล้ม และบันทึกผู้มีอำนาจกู้คืน

จำนวน confirmation เป็นข้อสังเกต ไม่ใช่กฎ finality สากล ใน Bitcoin Core ค่า confirmations ขึ้นกับตำแหน่งบล็อกใน active chain ปัจจุบัน ส่วน chainwork บันทึกงานคาดหมายสะสม ใน Ethereum การเลือก head แบบ LMD-GHOST กับ justification และ finalization ของ checkpoint แบบ Casper FFG เป็น transition แยกกัน ใน CometBFT การ commit ต้องมี voting power มากกว่าสองในสาม precommit บล็อกเดียวกัน ณ ความสูงและรอบเดียวกัน ทุกสถานะต้องตีความในโปรโตคอลของตน

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

1. การชำระ Proof of Work แบบความน่าจะเป็น

White paper Bitcoin จำลองผู้โจมตีที่มีสัดส่วน hash power q=0.10 พยายามไล่ตามเชนสุจริตหลังตามหลัง z=6 ภายใต้สมมติฐานว่าการทดลอง hash เป็นอิสระและใช้การแจกแจง Poisson ความน่าจะเป็นที่คำนวณได้คือ:

P=0.0002428 = 0.02428%

ผลลัพธ์มีค่าน้อยแต่ไม่ใช่ศูนย์ และไม่ใช่หลักประกัน “หก confirmation” สากล นโยบายจริงต้องพิจารณามูลค่าธุรกรรม chainwork ที่สังเกต ความกระจุกของ hash power ความเสี่ยง eclipse หรือ partition แรงจูงใจค่าธรรมเนียม และความน่าเชื่อถือของสมมติฐานว่าสัดส่วนคงที่

2. Justification และ finalization ของ Ethereum

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

Head อาจเดินเลย C_2 ขณะที่ส่วนใหม่ยังไม่ final หาก balance 34 offline จะเหลือเพียง 66 และ finalization ทันทีหยุด แม้ fork choice และการผลิตบล็อกอาจดำเนินต่อ หลังไม่มี finality เกินสี่ epoch กลไก inactivity leak ของ Ethereum เริ่มลงโทษการไม่เข้าร่วม เพื่อให้ supermajority ที่ active กู้ finality ได้ในที่สุด

3. Safety เทียบกับ liveness ใน CometBFT

สมมติ voting power รวม 100 และ commit ต้องการ >2/3 precommit สำหรับบล็อกเดียวกัน ณ ความสูงและรอบเดียวกัน น้ำหนักจำนวนเต็ม 67 commit ได้ เซต commit น้ำหนัก 67 สองเซตทับซ้อนอย่างน้อย 67 + 67 - 100 = 34 หากน้ำหนัก Byzantine ต่ำกว่าหนึ่งในสามและ validator สุจริตทำตามกฎ lock จะสร้าง commit ขัดแย้งสองรายการไม่ได้

หากน้ำหนัก 34 ใช้งานไม่ได้ จะมีเพียง 66 ลงคะแนน จึงไม่เกิด commit โปรโตคอลอาจรักษา safety ขณะที่ finality หยุด “ไม่มีบล็อก final ที่ขัดแย้ง” กับ “บล็อกใหม่ยัง final ต่อเนื่อง” เป็นหลักประกันคนละข้อ

4. สถานะ OP Stack และเวลาถอน

Sequencer ของ OP Stack อาจแสดงบล็อก L2 เป็น unsafe ก่อน เมื่อบล็อกหาได้ทั้งหมดจากข้อมูลบนเชน L1 canonical ปัจจุบัน rollup node อาจทำเครื่องหมาย safe เมื่อ input L1 ที่เกี่ยวข้องได้รับสัญญาณ finality ของ L1 บล็อก L2 ที่ derive แล้วจึงเป็น finalized ได้

สถานะนี้เกี่ยวกับการ derive จาก input ที่ final แล้ว Output ของ optimistic rollup หรือการถอน L2 ไป L1 มีกระบวนการ proof และ dispute แยก และอาจใช้คำว่า “finalized” หลังผ่านเงื่อนไข challenge เท่านั้น แอปที่รวม confirmation จาก sequencer การรวมข้อมูล L1, finality ของ consensus L1 และการรันถอนเป็นเวลาเดียวอาจปล่อยมูลค่าเร็วเกินไป

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

คำนิยามและหลักฐาน

  • เรียก execution, receipt, confirmation, checkpoint หรือป้าย UI ที่สำเร็จทุกอย่างว่า “final”
  • ละเชน เครือข่าย เวอร์ชัน hash วัตถุ ความสูงหรือ slot ชั้น และผู้สังเกต
  • ถือ head ของ fork choice ปัจจุบันเป็น ancestor ที่ final หรือคิดว่า finalization เลือก head ล่าสุด
  • นับบล็อกหรือนาทีโดยไม่ตรวจ ancestor, target งาน คะแนนเสียง หรือใบรับรอง
  • เปรียบเทียบ “สอง confirmation” หรือ “finality สิบนาที” ระหว่างโปรโตคอลที่หลักฐานและแบบจำลองความผิดพลาดต่างกัน
  • ตรวจลายเซ็นโดยไม่ตรวจสิทธิ น้ำหนัก domain ต้นทาง เป้าหมาย ความสูง และรอบ
  • ถือว่าต้นทุนเศรษฐกิจ หลักฐานที่ slash ได้ และการลงโทษจริงเป็นหลักประกันเดียวกัน
  • อธิบายความเสี่ยงเชิงความน่าจะเป็นเป็นศูนย์ หรือ safety แบบกำหนดแน่นอนตามเงื่อนไขเป็นความย้อนกลับไม่ได้เด็ดขาด

ความผิดพลาดของโปรโตคอลและการปฏิบัติการ

  • เกินขอบเขต Byzantine สูญเสียน้ำหนัก online ที่ต้องใช้เพื่อ liveness หรือซ่อน network partition
  • ปล่อยให้ implementation ต่างกันเรื่องความถูกต้อง fork choice, transition การปัดเศษ quorum หรือสายบรรพบุรุษใบรับรอง
  • รับคะแนนเสียง commit, checkpoint หรือข้อมูล weak subjectivity ที่เก่า replay หรือมาจากเครือข่ายอื่น
  • รวมกุญแจ stake, hash power ไคลเอนต์ relay คลาวด์ หรือมุมมอง RPC ไว้หลังตัวตนที่ดูเหมือนแยกกัน
  • สมมติว่า inactivity leak, timeout หรือ view change กู้ความคืบหน้าทันทีและไม่มีผลกระทบ
  • ไม่เตือน finality ล่าช้า ใบรับรองขัดแย้ง reorganization ลึก การลงคะแนนสองทาง หรือ final root ต่างกัน
  • ใช้ governance ฉุกเฉินหรือ social recovery โดยไม่บันทึกอำนาจ การประสานงาน release ไคลเอนต์ และหลักประกันที่กระทบ

ความไม่ตรงกันของชั้นและแอป

  • ถือการรวมโดย sequencer เป็น safety L2 การเผยแพร่ L1, finality L1 การรับ proof และการถอนเสร็จพร้อมกัน
  • ปล่อยสินทรัพย์ bridge ก่อนเหตุการณ์ต้นทางและเส้นทางตรวจของ bridge ผ่านนโยบาย
  • เครดิตเงินฝากหรือทำ trade ย้อนกลับไม่ได้จากสถานะ RPC รายเดียวโดยไม่กระทบยอดอิสระ
  • สมมติว่า finality ของเชนรับประกันความจริงของ oracle ความถูกต้องของ contract การมีข้อมูล สภาพคล่องของตลาด หรือการชำระตามกฎหมาย
  • ใช้เกณฑ์ confirmation คงที่เดียวกับทุกมูลค่า คู่สัญญา แรงจูงใจโจมตี และต้นทุนกู้คืน

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

  • ธุรกรรมสำเร็จคือ final แล้ว ความสำเร็จบอกเพียง transition หนึ่งในประวัติผู้สมัคร ส่วน canonical และ final ต้องมีหลักฐานเพิ่ม
  • เพิ่ม confirmation แล้วความเสี่ยง PoW จะเป็นศูนย์แน่นอน ความน่าจะเป็นในแบบจำลองลดมากได้ แต่ยังขึ้นกับสมมติฐานและไม่กลายเป็นสิ่งเป็นไปไม่ได้เชิงตรรกะ
  • สองในสามหมายถึง finality เสมอ อสมการ ชนิดข้อความ snapshot น้ำหนัก ความสูง รอบ ความสัมพันธ์ต้นทาง-เป้าหมาย และกฎ lock เฉพาะแต่ละโปรโตคอล
  • Finality รับประกันว่าเครือข่ายเดินหน้าต่อ Safety อาจยังอยู่แม้การเข้าร่วมหรือการเชื่อมต่อไม่พอจนสร้าง finalization ใหม่ไม่ได้
  • Finality ของ L1 ทำให้ทุกการกระทำ L2 หรือ bridge เสร็จ การ derive หลักฐาน validity หรือ fraud ช่วง challenge และการรันปลายทางเพิ่มเวลาและเส้นทางล้มเหลวแยกกัน

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

แหล่งข้อมูล

การนำทาง

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