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

การยืนยันบล็อก

คู่มือที่เริ่มจากการตรวจสอบความลึกของการยืนยันใน PoW สถานะ safe และ finalized ใน PoS การแทนที่ธุรกรรมใน mempool การจัดระเบียบเชนใหม่ และนโยบายเครดิตเงินฝากของแพลตฟอร์ม

อัปเดต

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

คำตอบโดยตรง

การยืนยันบล็อกคือข้อความที่ขึ้นกับผู้สังเกตและโปรโตคอลว่า ธุรกรรมถูกรวมไว้ในบล็อกบนเชนที่ผู้สังเกตถือว่าเป็น canonical ในขณะนั้น ตามหลักการนับแบบรวมที่ Bitcoin Core ใช้กันทั่วไป บล็อกที่รวมธุรกรรมจะนับเป็นการยืนยันครั้งที่หนึ่ง เมื่อความสูงที่รวมธุรกรรมคือ h และความสูงของเชนที่ดีที่สุดคือ H ความลึกจะเท่ากับ H - h + 1 บางบริการแสดงเฉพาะบล็อกที่สืบทอดต่อมาเป็น H - h จึงต้องระบุหลักการนับให้ชัดเจน

ความลึกของ Proof-of-Work ช่วยลดความเสี่ยงจากการจัดระเบียบเชนใหม่ภายใต้สมมติฐานที่ระบุไว้ แต่ไม่มีจุดมหัศจรรย์ที่ทำให้เกิด finality อย่างสมบูรณ์ ระบบ Proof-of-Stake อาจแสดงสถานะที่โปรโตคอลกำหนดโดยตรง Ethereum แยก latest, safe และ finalized ออกจากกัน จำนวนบล็อก slot หรือนาทีที่กำหนดตายตัวไม่สามารถใช้แทนป้ายสถานะเหล่านี้ได้ สถานะที่แพลตฟอร์มตรวจพบ เครดิตให้ ซื้อขายได้ และถอนได้ เป็นนโยบายภายในคนละขั้น แม้จะถึงเกณฑ์ของเชนแล้วก็ตาม

คาดว่าจะรอ
1.2 min
ช่วงภาพประกอบ
54s - 1.5 min

ผลลัพธ์เป็นการประมาณทางการศึกษา โดยไม่รวมกฎของสถานที่ ภาษี เวลาแฝง พฤติกรรมของ Oracle และพารามิเตอร์เฉพาะโปรโตคอลอื่นๆ เว้นแต่จะแสดงไว้

กลไกการทำงาน

  1. ระบุเชนและเครือข่าย สินทรัพย์ ตัวระบุธุรกรรม โหนดหรือ API เวลาที่สังเกต โมเดลฉันทามติ และหลักการนับ ตรวจสอบผู้รับ จำนวนเงิน และ memo หรือ tag ก่อนถือว่าแฮชที่ตรงกันคือการชำระเงินที่ต้องการ
  2. แยกสถานะลงนามแล้ว เผยแพร่แล้ว ได้รับการยอมรับจาก mempool ภายในของโหนดหนึ่ง และกระจายไปในเครือข่ายออกจากกัน Mempool เป็นมุมมองตามนโยบาย ไม่ใช่คิวฉันทามติส่วนกลาง ตรวจสอบสถานะค่าธรรมเนียม ธุรกรรมบรรพบุรุษที่ยังไม่ยืนยัน Replace-by-Fee หรือการแทนที่ด้วย nonce เดิม และการใช้จ่ายที่ขัดแย้งกัน
  3. ตรวจสอบการรวมธุรกรรมด้วยแฮชและความสูงของบล็อก ดัชนีธุรกรรม และลำดับบรรพบุรุษของเชน canonical ไม่ใช่ดูเพียงความสูงหรือป้ายจาก block explorer สำหรับเชนแบบบัญชี ให้ตรวจสอบสถานะ receipt, log และการเปลี่ยนแปลง state ที่เกิดขึ้นจริงด้วย เพราะการประมวลผลที่รวมในบล็อกยังอาจ revert ได้
  4. ใช้โมเดลฉันทามติให้ถูกต้อง สำหรับ PoW ให้ระบุหลักการนับ คำนวณความลึก และเปรียบเทียบมุมมองอิสระต่อเชนที่ดีที่สุดกับงานสะสม สำหรับ PoS ให้สอบถามสถานะ head, safe, justified หรือ finalized ที่โปรโตคอลกำหนด อย่าอนุมานจากระยะห่างของบล็อกหรือ slot ที่กำหนดตายตัว
  5. ติดตามวงจรชีวิตเป็นสถานะที่ชัดเจน ได้แก่ สร้างแล้ว เผยแพร่แล้ว mempool ภายในยอมรับแล้ว รวมในบล็อกแล้ว มีความลึกแบบ canonical หรือสถานะ safe/finalized ถูกจัดระเบียบใหม่ รวมใหม่ ถูกแทนที่ หรือขัดแย้งกัน การจัดระเบียบเชนใหม่ไม่ได้รับประกันว่าธุรกรรมเดิมจะกลับเข้า mempool ทุกแห่ง
  6. แยกบัญชีของแพลตฟอร์มออกเป็น ตรวจพบแล้ว ถึงเกณฑ์เครือข่ายแล้ว เครดิตแล้ว ซื้อขายได้ และถอนได้ ใช้นโยบายปัจจุบันของแพลตฟอร์มที่เจาะจงตามสินทรัพย์ เครือข่าย จำนวนเงิน และภาวะเหตุขัดข้อง การบำรุงรักษา การกำกับดูแล และการตรวจสอบโดยเจ้าหน้าที่อาจเพิ่มความล่าช้าอีกชั้นหนึ่ง
  7. เปรียบเทียบโหนดหรือผู้ให้บริการอิสระ และติดตามต่อไปจนถึงสถานะที่กำหนด บันทึกแฮช ความสูง เวลา ป้าย RPC และ snapshot ของนโยบาย พร้อมซักซ้อมกรณีแทนที่ การจัดระเบียบใหม่ finality ล่าช้า โหนดล้าสมัย bridge relay และแพลตฟอร์มหยุดให้บริการ

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

  • หลักการนับ ธุรกรรม Bitcoin อยู่ในบล็อก canonical h = 900,000 และปลายเชนที่ดีที่สุดอยู่ที่ H = 900,005 ความลึกแบบรวมคือ 900,005 - 900,000 + 1 = 6 confirmations ส่วนหน้าจอที่นับเฉพาะบล็อกที่สืบทอดต่อมาจะแสดง 900,005 - 900,000 = 5 ความแตกต่างนี้เป็นเรื่องคำศัพท์ หากทั้งสองค่าหมายถึงแฮชบล็อกและลำดับบรรพบุรุษเดียวกัน
  • การจัดระเบียบใหม่และการรวมใหม่ ธุรกรรมมี 1 confirmation ในบล็อก 900,000 จากนั้นบล็อกนั้นออกจากเชนที่ดีที่สุด และธุรกรรมกลับเป็น 0 หากยังใช้ได้และไม่มีธุรกรรมขัดแย้ง หากรวมใหม่ที่ 900,003 และปลายเชนถึง 900,006 ความลึกแบบรวมคือ 900,006 - 900,003 + 1 = 4 confirmations แต่ถ้าธุรกรรมขัดแย้งที่ได้รับการยืนยันเข้ามาแทน Bitcoin Core อาจรายงานจำนวนการยืนยันติดลบ
  • ป้าย PoS ไม่ใช่จำนวนบล็อก สมมติว่าธุรกรรม Ethereum อยู่ใน execution block 20,000,000 ขณะที่โหนดหนึ่งรายงาน latest = 20,000,020, safe = 20,000,012 และ finalized = 19,999,980 โดยทั้งหมดอยู่ในลำดับบรรพบุรุษเดียวกัน ความลึกเชิงตัวเลขจาก latest คือ 20,000,020 - 20,000,000 + 1 = 21 ธุรกรรมอยู่ในสถานะ safe แต่ยังไม่ finalized ต้องตรวจสอบลำดับแฮชและป้ายฉันทามติของไคลเอนต์ เพราะความสูงเพียงอย่างเดียวไม่เพียงพอ
  • เกณฑ์ของเชนเทียบกับเครดิตของแพลตฟอร์ม นโยบายของแพลตฟอร์มกำหนด 6 confirmations เงินฝากในบล็อก 900,000 อยู่ที่ 5/6 เมื่อปลายเชนเป็น 900,004 และถึง 6/6 ที่ 900,005 หากแพลตฟอร์มกำหนด 15-minute compliance hold ต่อจากนั้น สิทธิ์ตามเชนกับเวลาที่เครดิต ซื้อขาย หรือถอนได้ยังเป็นคนละสถานะ ช่วงพักนี้ไม่ใช่การยืนยันครั้งที่เจ็ด

ความเสี่ยง

  • ตรวจสอบผิดเชน เครือข่าย หรือสินทรัพย์
  • ใช้แฮชธุรกรรม ผู้รับ memo หรือ tag ผิด
  • ถือว่าธุรกรรมที่ลงนามแล้วแต่ยังไม่เผยแพร่กำลังรอการยืนยัน
  • ถือว่า mempool ของโหนดเดียวเป็นสถานะของทั้งเครือข่าย
  • มองข้ามการปฏิเสธตามนโยบาย การนำออก หรือการไม่กระจายธุรกรรม
  • มองข้ามการแทนที่แบบ RBF, nonce เดิม หรือธุรกรรมขัดแย้ง
  • อ่านธุรกรรมบรรพบุรุษ ธุรกรรมลูก หรือค่าธรรมเนียมแบบแพ็กเกจที่ยังไม่ยืนยันผิด
  • สับสนระหว่างการนับแบบรวมกับการนับเฉพาะบล็อกที่สืบทอดต่อมา
  • เชื่อถือโหนดที่ล้าสมัย กำลังซิงก์ หรือถูกแยกออกจากเครือข่าย
  • เปรียบเทียบความสูงโดยไม่ตรวจสอบแฮชบล็อกและลำดับบรรพบุรุษ
  • สูญเสียการยืนยันจากการจัดระเบียบ PoW ใหม่ระยะสั้น
  • ถือว่าความลึกคงที่ให้ความปลอดภัยสมบูรณ์สำหรับทุกมูลค่าและคู่ปรับ
  • สับสนระหว่างเวลาที่ผ่านไป slot, epoch และจำนวนบล็อกที่ผลิต
  • ถือว่าบล็อก head ของ PoS อยู่ในสถานะ safe
  • ถือว่าบล็อก safe อยู่ในสถานะ finalized
  • มองข้าม finality ที่ล่าช้าขณะที่เชนยังผลิตบล็อก
  • ถือว่าการประมวลผลที่รวมแล้วแต่ revert เป็นความสำเร็จของแอปพลิเคชัน
  • สับสนระหว่าง log ของโทเค็นหรือ UI ของ explorer กับ state ที่เกิดขึ้นจริง
  • ถือว่าการตรวจพบ เครดิต สิทธิ์ซื้อขาย และสิทธิ์ถอนของแพลตฟอร์มเป็นสถานะเดียวกัน
  • ถือว่าการยืนยันบนเชนต้นทางคือการเสร็จสิ้นของ bridge ผู้ออกสินทรัพย์ หรือกระบวนการปลายทาง

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

  • แฮชธุรกรรมที่ค้นหาได้หรือรายการใน mempool ภายในหมายถึงได้รับการยืนยันแล้ว
  • หลักการนับหนึ่งแบบและเกณฑ์หกการยืนยันใช้ได้กับทุกเชน จำนวนเงิน และบริการ
  • การจ่ายค่าธรรมเนียมสูงขึ้นทำให้บล็อกถัดไปหรือ finality ของ PoS มาถึงเร็วขึ้น
  • จำนวนบล็อกหรือ slot ของ Ethereum ที่กำหนดตายตัวเท่ากับ safe หรือ finalized
  • การรวมในเชนหรือ finality รับประกันว่าการประมวลผลสัญญาสำเร็จ รายละเอียดผู้รับถูกต้อง แพลตฟอร์มให้เครดิต หรือ bridge ทำงานเสร็จ

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

แหล่งข้อมูล

การนำทาง

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