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

หลักฐานข้อผิดพลาด (Fraud Proof)

คู่มือที่คำนึงถึง deployment สำหรับหลักฐานข้อผิดพลาดแบบ optimistic, claim ที่มีข้อโต้แย้ง, การแบ่งครึ่ง execution trace, การตรวจสอบหนึ่งขั้น, clock, bond, data availability, finality ของการถอน และการตรวจสอบเชิงปฏิบัติการ

อัปเดต

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

คำตอบโดยตรง

หลักฐานข้อผิดพลาด ซึ่งมักเรียกว่า fraud proof คือกระบวนการตามโปรโตคอลสำหรับโต้แย้ง claim แบบ optimistic เกี่ยวกับการคำนวณหรือ state ผู้เสนอ claim ไม่ได้พิสูจน์ทุก state transition ก่อนที่ claim จะได้รับการยอมรับ แต่ challenger ที่มีสิทธิ์สามารถเสนอ trace ที่ขัดแย้งกันภายใน clock ที่กำหนด และสัญญาบน settlement chain จะตัดสินข้อพิพาทตาม verifier ที่ระบุ การออกแบบเชิงโต้ตอบหลายแบบจะแบ่งช่วง trace ที่ยาวให้แคบลงซ้ำๆ จนเหลือคำสั่งเดียวที่เป็นข้อพิพาท แล้วดำเนินการกรณีฐานนั้นบนเชน

ชื่อเรียกไม่ได้พิสูจน์ว่าระบบที่ deploy แล้วเป็นแบบ permissionless พร้อมใช้งาน หรือปลอดภัย ความปลอดภัยต้องอาศัยข้อมูล derivation ที่ถูกต้องและพร้อมใช้ challenger ที่ถูกต้องอย่างน้อยหนึ่งรายซึ่งสร้าง claim ขึ้นใหม่และดำเนินการทันเวลาได้ การเข้าถึง settlement chain และ gas ที่เพียงพอ โปรแกรมพิสูจน์และสัญญาที่ถูกต้อง ตลอดจน governance ที่ไม่สามารถข้ามผลตัดสินได้ claim ที่ผ่านเกมอาจอนุญาตการถอนตามกฎของ deployment นั้น แต่ไม่ได้พิสูจน์ย้อนหลังว่าธุรกรรม L2 ทุกธุรกรรม ข้อความจาก frontend หรือผลลัพธ์ทางเศรษฐกิจถูกต้อง

1
ลำดับ

ซีเควนเซอร์จะสั่งธุรกรรม L2 และเผยแพร่ข้อมูลธุรกรรมหรือข้อผูกพัน

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

  1. ระบุ deployment ให้แน่นอน ได้แก่ chain ID ของ L1 และ L2, เวอร์ชัน rollup และระบบหลักฐานข้อผิดพลาด, block hash, factory, portal หรือ bridge, โปรแกรมพิสูจน์, VM, ประเภทเกม, implementation และที่อยู่ admin, รูปแบบสิทธิ์, bond, ความลึกสูงสุด, clock, ระยะหน่วงก่อนครบกำหนด, สถานะ pause และนโยบาย finality คำว่า fraud proof ไม่ใช่ข้อกำหนดร่วมของทุก rollup
  2. สร้าง claim ขึ้นใหม่จาก input ที่ยืนยันแล้ว บันทึก anchor state, L1 head, บล็อก L2 หรือ output root ที่เป็นข้อพิพาท, ข้อมูล batch และ blob, การกำหนดค่า chain และ rollup, pre-state, withdrawals root และกฎ derivation ที่แน่นอน state root เพียงอย่างเดียวไม่พอสำหรับสร้าง transition ซ้ำ และข้อมูลที่ไม่พร้อมใช้อาจทำให้ช่องทาง challenge ที่เปิดอยู่ใช้การไม่ได้
  3. ตรวจสอบว่าเกมถูกสร้างและมีผลต่อวัตถุที่ต้องการ ตรวจ root claim, claimant, บล็อกและเวลาที่สร้าง, ประเภทเกม, สถานะ respected หรือ blacklist, bond, คุณสมบัติของ challenger และกฎการยอมรับจริงของ portal แยก claim ที่ยัง pending ผลของเกม และ output ที่พร้อมใช้ถอนออกจากกัน
  4. ดำเนินการซ้ำด้วยโหนดและ implementation ของหลักฐานข้อผิดพลาดที่เป็นอิสระ เปรียบเทียบ trace ที่ถูกต้องกับทุก claim ที่เป็นข้อพิพาท และเก็บ preimage, state witness และเวอร์ชัน client ไว้ ในเกมเชิงโต้ตอบ ให้โจมตีหรือป้องกันช่วงที่ถูกต้องจนความลึกสูงสุดระบุคำสั่งเดียว แล้วส่ง witness ของกรณีฐานไปยัง verifier ของ VM บนเชน
  5. ติดตาม clock ของแต่ละทีมและทุกธุรกรรม บันทึกเวลาที่เหลือ การต่อเวลา การ inclusion บน L1 และความเสี่ยง reorganization, calldata, gas, replacement, bond ที่เสี่ยง, claim ที่ขนานกัน และฝ่ายที่ต้องตอบสนอง ระยะเวลาท้าทายตามเวลาจริงไม่จำเป็นต้องเป็นการนับถอยหลังคงที่ชุดเดียว และผลที่ถูกต้องอาจแพ้ได้เพราะพลาดการเดินเกมหรือธุรกรรมถูก censor
  6. เชื่อมผลตัดสินกับผลตามโปรโตคอล ระบุว่า claim ใดถูกโต้แย้งสำเร็จ ทีมใดชนะ bond และต้นทุนกระจายอย่างไร output ที่ไม่ถูกต้องถูกกันออกหรือไม่ และต้องสร้าง output, proof หรือการถอนที่พึ่งพาอยู่ใหม่หรือไม่ การริบ bond เป็นแรงจูงใจ ไม่ใช่ค่าชดเชยความเสียหายจาก bridge ที่อาจเกิดขึ้นทั้งหมด
  7. กระทบยอด finality และการถอนแยกกัน ตรวจสอบผลเกม ระยะหน่วงก่อน proof ครบกำหนดและหลังการตัดสินตามที่กำหนด ประเภทเกมที่ respected การตรวจ blacklist และ pause, proof การ inclusion ของการถอน, receipt การ finalize และ finality ของ L1 เก็บข้อมูลและหลักฐาน ติดตาม upgrade และซ้อมขั้นตอน challenge, forced inclusion, การพิสูจน์ใหม่ และ emergency exit

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

  • การแบ่งครึ่ง trace trace เพื่อการเรียนรู้มี 1,048,576 = 2^20 instructions หากแต่ละรอบที่ไม่มีข้อโต้แย้งแบ่งช่วงข้อพิพาทครึ่งหนึ่ง 20 bisections จะแยกเหลือหนึ่งคำสั่ง เพราะ 2^20 / 2^20 = 1 เกมจริงอาจแบ่ง output trace และ execution trace แยกกัน แตกแขนงเป็น DAG หรือต้องมีการเดินเกมเพิ่มเติม ดังนั้นนี่เป็นตัวอย่างความซับซ้อน ไม่ใช่จำนวนรอบของ deployment ใด
  • clock ของแต่ละทีมที่เป็นอิสระ เกมสมมติให้แต่ละทีม 84 hours defender ใช้ 30 hours และ challenger ใช้ 22 hours จึงเหลือ 54 hours และ 62 hours ตามลำดับ เวลาจริงที่ผ่านไปไม่ใช่เพียง 84 hours เพราะเฉพาะ clock ของทีมที่เกี่ยวข้องเท่านั้นที่เดิน และการต่อเวลาตามโปรโตคอล ความล่าช้าในการ inclusion และ claim ที่ขนานกันอาจเปลี่ยนเส้นตายได้
  • บัญชี bond และ gas ภายใต้กฎสมมติที่ระบุไว้อย่างชัดเจน root ที่ไม่ถูกต้องมี bond 2 ETH challenger ที่ชนะวาง 0.5 ETH ได้เงินต้นนั้นคืนพร้อมรางวัล 1.4 ETH และจ่าย gas บน L1 0.08 ETH ส่วน 0.6 ETH จาก bond ของฝ่ายแพ้เข้าสู่ treasury กำไรสุทธิของ challenger คือ 1.4 - 0.08 = 1.32 ETH เงิน 0.5 ETH ที่คืนมาเป็นเงินต้น ไม่ใช่กำไร และ 1.4 + 0.6 = 2 ETH ผู้รับ bond และการปฏิบัติต่อผู้ร่วมรับประโยชน์โดยไม่ออกต้นทุนขึ้นอยู่กับสัญญา
  • clock ของการถอน สมมติว่าพิสูจน์การถอนเมื่อ 2026-08-01 12:00 UTC ระยะหน่วงก่อน proof ครบกำหนดที่ตั้งไว้คือ 7 days เกมที่เกี่ยวข้องตัดสินเมื่อ 2026-08-06 18:00 UTC และช่วงเว้นหลังการตัดสินคือ 1 day เงื่อนไขทั้งสองสิ้นสุดที่ 2026-08-08 12:00 UTC และ 2026-08-07 18:00 UTC เวลาที่เร็วที่สุดที่ผ่านทั้งสองเงื่อนไขคือ 2026-08-08 12:00 UTC เมื่อเพิ่มนโยบาย finality ของ L1 อีก 20 minutes การเสร็จสมบูรณ์ทางเศรษฐกิจคือ 2026-08-08 12:20 UTC โดยสมมติว่าไม่มี pause, blacklist, การพิสูจน์ใหม่ หรือ reorganization

ความเสี่ยง

  • ตรวจสอบ L1, L2, deployment, ประเภทเกม หรือเวอร์ชันสัญญาผิดรายการ
  • สร้างใหม่จาก anchor และ L1 head ที่ล้าสมัย ไม่เป็น canonical หรือไม่ถูกต้อง
  • ขาดข้อมูล batch, blob, preimage, state witness หรือการกำหนดค่า
  • สมมติว่า commitment หรือ input ของ proof ที่มีอยู่หมายถึงข้อมูล derivation ทั้งหมดพร้อมใช้
  • ซอฟต์แวร์ challenger สร้าง trace ที่ถูกต้องแตกต่างกันเพราะข้อบกพร่องของ client
  • ข้อบกพร่องในโปรแกรมหลักฐานข้อผิดพลาด VM, preimage oracle หรือ verifier ของขั้นตอนบนเชน
  • proposer, challenger หรือช่องทางสร้างเกมที่ permissioned ไม่พร้อมใช้งานหรือถูกควบคุม
  • ไม่มี watcher ที่ซื่อสัตย์ตรวจพบและเปิดข้อพิพาทก่อนเส้นตายที่เกี่ยวข้อง
  • การ censor, ความแออัดของ L1, reorganization หรือ gas ที่พุ่งสูงขัดขวางการเดินเกมทันเวลา
  • อ่าน chess clock, การต่อเวลา, ความลึกสูงสุด หรือเวลา inclusion ของธุรกรรมผิด
  • โจมตีหรือป้องกัน claim, ช่วง trace, ตำแหน่ง หรือคำสั่งผิดรายการ
  • ข้อกำหนด bond หรือเงินทุนหมุนเวียนทำให้การเข้าร่วมแบบ permissionless ไม่สามารถทำได้จริง
  • การกระจาย bond, พฤติกรรมผู้รับประโยชน์โดยไม่ออกต้นทุน หรือแรงจูงใจต่างจากสมมติฐานความปลอดภัย
  • เกมหลายเกม claim ซ้ำ หรือ implementation ที่ขัดกันถูกตัดสินอย่างไม่คาดคิด
  • governance เปลี่ยนประเภทเกมที่ respected, verifier, threshold หรือระยะหน่วง
  • อำนาจ pause หรือ blacklist ของ guardian ปิดกั้นการถอนที่มิฉะนั้นจะถูกต้อง
  • ถือว่าการตัดสินเกมเป็น finality ของการถอนหรือ settlement ในทันที
  • พิสูจน์การถอนกับเกมที่ถูกยกเลิกแล้วไม่พิสูจน์ใหม่
  • สมมติว่าการปฏิเสธ output ที่ไม่ถูกต้องซ่อมแซมผลกระทบ downstream ต่อแอปหรือ bridge ทั้งหมด
  • นำรูปแบบ proof และ finality ของ optimistic rollup หนึ่งไปเหมารวมกับระบบอื่น

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

  • claim แบบ optimistic ที่ไม่ถูกท้าทายได้รับการพิสูจน์ทางวิทยาการเข้ารหัสแล้วว่าถูกต้อง
  • ทุกคนท้าทายทุกระบบที่ deploy แล้วได้โดยไม่ต้องมีสิทธิ์ เงินทุน หรือโครงสร้างพื้นฐาน
  • หลักฐานข้อผิดพลาดทำงานได้แม้ข้อมูล derivation ไม่พร้อมใช้
  • การชนะข้อพิพาททำให้การถอนที่พึ่งพาทั้งหมด final ทันทีและชดเชยความเสียหายทั้งหมด
  • ช่วงเวลาท้าทายเจ็ดวัน เกมแบบทวิภาค และ watcher ที่ซื่อสัตย์หนึ่งรายเป็นค่าคงที่สากลของ rollup

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

แหล่งข้อมูล

การนำทาง

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