เช่นที่ทราบกันดี fraud proofs เป็นวิธีการเทคนิคที่ใช้กันอย่างแพร่หลายในพื้นที่บล็อกเชน มันเกิดขึ้นในชุมชน Ethereum และได้รับการนำมาใช้โดย Ethereum Layer 2 solutions ที่มีชื่อเสียงอย่าง Arbitrum และ Optimism หลังจาก Bitcoin ecosystem เติบโตขึ้นในปี 2023 Robin Linus ได้เสนอวิธีการแก้ปัญหาที่เรียกว่า BitVM ซึ่ง โดยใช้เทคโนโลยี Bitcoin ที่มีอยู่เช่น Taproot มุ่งเน้นที่ fraud proofs และให้ระบบรักษาความปลอดภัยใหม่สำหรับ Bitcoin Layer 2 หรือ bridges

BitVM ได้เปิดตัวเวอร์ชันทฤษฎีหลายรุ่น ตั้งแต่ BitVM0 แรกที่ใช้วงจรวางเกตเป็นพื้นฐาน ไปจนถึงเวอร์ชันใหม่เช่น BitVM2 ซึ่งเน้นที่ ZK Fraud Proofs และวงจรการยืนยัน Groth16 และเส้นทางการนำไปปฏิบัติทางเทคนิคที่เกี่ยวข้องกับ BitVM ได้ก้าวไปข้างหน้าและเจริญเติบโต ดึงดูดความสนใจจากมืออาชีพในอุตสาหกรรมมากมาย โครงการเช่น Bitlayer, Citrea, BOB, Fiamma และ Goat Network ใช้ BitVM เป็นหนึ่งในเทคโนโลยีหลักของพวกเขา การปฏิบัติต่างกันตามพื้นฐานนี้

เนื่องจากความขาดแคลนและความซับซ้อนของข้อมูลอธิบายเกี่ยวกับ BitVM ในสาธารณะ เราจึงเริ่มเผยแพร่ความรู้เกี่ยวกับ BitVM ผ่านชุดบทความ โดยมุ่งเน้นที่การเชื่อมโยงที่ลึกซึ้งระหว่าง BitVM และการพิสูจน์การฉ้อโกง บทความนี้จะเน้นที่การพิสูจน์การฉ้อโกงและ ZK Fraud Proofs โดยใช้ภาษาที่เข้าใจง่ายเพื่ออธิบายแนวคิดเหล่านี้

(กลไกการป้องกันฉ้อโกงแบบโต้ตอบของหลักของความเชื่อมั่น)

OutputRoot และ StateRoot

Optimism เป็นโครงการ Optimistic Rollup ที่รู้จักอย่างดี โดยโครงสร้างพื้นฐานประกอบด้วย sequencer (พร้อมกับโมดูลหลักที่ประกอบด้วย op-node, op-geth, op-batcher และ op-proposer) และสมาร์ทคอนแทร็กต์บนเชน Ethereum

หลังจากตัวจัดลำดับประมวลผลชุดข้อมูลธุรกรรม ข้อมูล DA นี้จะถูกส่งไปยัง Ethereum ในขณะที่คุณสามารถเรียกใช้ไคลเอ็นต์โหนด Optimism ได้ คุณสามารถดาวน์โหลดข้อมูลที่ถูกอัปโหลดโดยตัวจัดลำดับไปยังเครื่องที่อยู่ในพื้นที่ของคุณ จากนั้นคุณสามารถดำเนินการทำธุรกรรมเหล่านี้ในเครื่องที่อยู่ในพื้นที่ของคุณและคำนวณแฮชเซตสถานะปัจจุบันของ Optimism (รวมถึงแต่ไม่จำกัดเพียงการดำเนินการสมดุลปัจจุบันของแต่ละบัญชี ฯลฯ)

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

เมื่อกล่าวถึงคำว่า "state set" บล็อกเชนที่ใช้ EVM โดยทั่วไปจะใช้โครงสร้างข้อมูลแบบ Merkle Tree เพื่อบันทึก state set ซึ่งเรียกว่า World State Trie หลังจากที่ดำเนินธุรกรรมแล้ว สถานะของบัญชีบางบัญชีจะเปลี่ยนแปลงและ World State Trie ก็จะเปลี่ยนแปลงไปด้วย ทำให้เกิดการเปลี่ยนแปลงใน final hash ของมัน อีเทอร์เรียมเรียก final hash ของ World State Trie ว่า StateRoot ซึ่งแทนการเปลี่ยนแปลงใน state set

แผนภูมิต่อไปนี้แสดงโครงสร้างของ stateRoot ของ Ethereum อย่างชัดเจน ดังที่เราเห็น ยอดคงเหลือของบัญชีที่แตกต่างกัน โค้ดแฮชที่เกี่ยวข้องกับบัญชีสมาร์ทคอนแทรค และข้อมูลอื่น ๆ ถูกรวบรวมไว้ทั้งหมดใน World State Trie จากนั้นสร้าง stateRoot จากนั้น

ระบบบัญชีและโครงสร้างข้อมูลของ Optimism สอดคล้องกับ Ethereum โดยทั่วไปโดยใช้ StateRoot field เพื่อแสดงการเปลี่ยนแปลงในเซตสถานะและ OP sequencer อัพโหลด key field ที่ชื่อ OutputRoot ไปยัง Ethereum เป็นระยะ ๆ ซึ่งคำนวณขึ้นจาก StateRoot และสอง field อื่น ๆ

เมื่อกลับมาสู่คำถามเริ่มต้น หากคุณเรียกใช้ไคลเอ็นต์โหนด OP และคำนวณ StateRoot และ OutputRoot ปัจจุบันในระดับท้องถิ่น หากคุณพบว่าผลลัพธ์ที่คุณคำนวณไม่ตรงกับผลลัพธ์ที่อัปโหลดโดยตัวจัดลำดับ OP คุณสามารถเริ่มต้นการพิสูจน์การฉ้อโกง ดังนั้น กลไกที่เฉพาะเจาะจงเบื้องหลังคืออะไร? ต่อไป เราจะแนะนำการตรวจสอบสถานะเครื่องเสมือน MIPS และการพิสูจน์การฉ้อโกงแบบโต้ตอบตามลำดับ

เครื่องมือเสมือน MIPS และต้นไม้เมอร์เคิลเมมโอรี

ตามที่กล่าวไว้ข้างต้น สมมติว่าคุณพบว่า OutputRoot ที่ถูกส่งเข้ามาโดยตัวจัดลำดับ OP ไม่ถูกต้อง และคุณต้องการเริ่มกระบวนการ 'ท้าทาย' กระบวนการท้าทายต้องการทำการติดต่อซ้ำต่อเนื่องบนเชน หลังจากนั้นสัญญาฉลากฉลองที่เกี่ยวข้องจะกำหนดว่าตัวจัดลำดับ OP อัปโหลด OutputRoot ที่ไม่ถูกต้องหรือไม่

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

1. สัญญาอัจฉริยะบน Ethereum ไม่สามารถรับพารามิเตอร์ที่ต้องการสำหรับการพิสูจน์การทุจริยา

2. ขีดจำกัดของแก๊สบล็อกของ Ethereum ถูก และมันไม่สนับสนุนงานคำนวณที่ซับซ้อนมาก ดังนั้นเราไม่สามารถที่จะปรับใช้ไคลเอ็นต์โหนด OP บนเชนได้ทั้งหมด

ปัญหาแรกคือการต้องการให้สมาร์ทคอนแทรกบนเชื่อมต่อออกจากเดต้า ซึ่งสามารถแก้ไขได้โดยใช้อัลกอริทึมที่คล้ายกับออราเคิล อ.พี. ได้ลงทะเบียนสัญญา PreimageOracle บนเชนอีเธอเรียม และสัญญาที่เกี่ยวข้องกับการพิสูจน์การฉ้อโกงสามารถอ่านข้อมูลที่จำเป็นจากสัญญานี้ได้ทฤษฎี ใครก็สามารถอัปโหลดข้อมูลไปยังสัญญานี้ได้ แต่ระบบการพิสูจน์การฉ้อโกงของอ.พี. มีวิธีการที่จะตรวจสอบว่าข้อมูลที่เกี่ยวข้องถูกต้องหรือไม่ แม้กระทั่งกระบวนการนี้จะไม่ถูกอธิบายต่อไป เนื่องจากมันไม่สำคัญต่อหัวข้อหลักของบทความนี้

สำหรับปัญหาครั้งที่สอง ทีมพัฒนา OP เขียนเครื่องจำลองเสมือน MIPS ใน Solidity เพื่อนำมาใช้ในการดำเนินการบางอย่างของลูกค้าโหนด OP ซึ่งเพียงพอสำหรับระบบการป้องกันการทุจริต MIPS เป็นสถาปัตยกรรมชุดคำสั่ง CPU ที่ทั่วไป และโค้ดของตัวจัดลำดับ OP เขียนขึ้นด้วยภาษาระดับสูง เช่น Golang/Rust เราสามารถคอมไพล์โปรแกรม Golang/Rust เป็นโปรแกรม MIPS และประมวลผลผ่านเครื่องจำลอง MIPS บนโซ่ Ethereum

ทีมพัฒนา OP เขียนโปรแกรมที่เรียบง่ายใน Golang เพื่อพิสูจน์การฉ้อโกงซึ่งเลียนแบบโมดูลในโหนด OP ที่ดําเนินธุรกรรมสร้างบล็อกและสร้าง OutputRoot อย่างไรก็ตามโปรแกรมที่เรียบง่ายนี้ยังไม่สามารถ "ดําเนินการได้อย่างสมบูรณ์" กล่าวอีกนัยหนึ่งแต่ละบล็อก OP มีธุรกรรมมากมาย หลังจากประมวลผลธุรกรรมชุดนี้ OutputRoot จะถูกสร้างขึ้น แม้ว่าคุณจะรู้ว่า OutputRoot ของความสูงของบล็อกใดไม่ถูกต้อง แต่การเรียกใช้ธุรกรรมทั้งหมดในบล็อกบน on-chain นั้นจะไม่สมจริงเพื่อพิสูจน์ว่า OutputRoot ที่เกี่ยวข้องนั้นไม่ถูกต้อง นอกจากนี้ในระหว่างการดําเนินการของแต่ละธุรกรรมชุดของ MIPS opcodes จะถูกประมวลผลตามลําดับ มันจะเป็นไปไม่ได้เลยที่จะเรียกใช้ opcodes ทั้งชุดนี้บนเครื่องเสมือน MIPS ที่ใช้ในสัญญาแบบ on-chain เนื่องจากค่าโสหุ้ยการคํานวณและปริมาณการใช้ก๊าซจะใหญ่เกินไป

(หลักการทำงานของชุดคำสั่ง MIPS)

เพื่อแก้ไขปัญหานี้ทีม Optimism ได้ออกแบบระบบป้องกันการฉ้อโกงแบบโต้ตอบเพื่อวิเคราะห์ขั้นตอนการประมวลผลธุรกรรมของ OP อย่างลึกซึ้ง โดยการสังเกตกระบวนการคํานวณทั้งหมดของ OutputRoot ระบบจะระบุว่า MIPS opcode เครื่องเสมือน MIPS ของ OP ซีเควนเซอร์ทําผิดพลาด หากข้อผิดพลาดได้รับการยืนยันสามารถสรุปได้ว่า OutputRoot ที่ซีเควนเซอร์ให้มานั้นไม่ถูกต้อง

ดังนั้นปัญหาก็เป็นเรื่องชัดเจน: กระบวนการของตัวจัดการการจัดห่อ OP sequencer ซึ่งทำการจัดการธุรกรรมเป็นบล็อกสามารถแยกออกเป็นการประมวลผลลำดับของคำสั่ง MIPS opcodes จำนวนมาก หลังจากทุกคำสั่ง MIPS opcode ถูกปฏิบัติ ฮาชสถานะของเครื่องจำลองเปลี่ยนแปลง บันทึกเหล่านี้สามารถรวมเข้าไปในต้นไม้เมอร์เคิล

ในกระบวนการป้องกันการโกงแบบโต้ตอบ จุดมุ่งหมายคือการกำหนดว่าหลังจาก MIPS opcode ใดที่สถานะแฮชเวชชินเนอร์ของเครื่องจำลองเสมือนเปลี่ยนแปลง, แล้วทำให้สถานะของเครื่องจำ MIPS บนเชน, ดำเนินการ opcode และสังเกตว่าสถานะที่เกิดขึ้นตรงกับสถานะที่เสนอโดยเซควานเซอร์ โดยเพราะมีการดำเนินการ MIPS opcode เพียงหนึ่งรหัสบนเชน, ความซับซ้อนต่ำและกระบวนการคำนวณสามารถดำเนินได้ในเชน Ethereum อย่างไรก็ตาม, เพื่อให้สามารถทำได้นี้ เราต้องอัปโหลดข้อมูลสถานะของเครื่องจำ MIPS เช่น ข้อมูลหน่วยความจำบางส่วน ไปยังเชน

ในเชิงการปฏิบัติของรหัส สัญญาอัจฉริยะบนเชน Ethereum ที่เกี่ยวข้องกับการป้องกันการฉ้อโกง จะดำเนินการกระบวนการการดำเนินการ MIPS opcode สุดท้ายผ่านฟังก์ชันที่เรียกว่า Step:

พารามิเตอร์ในฟังก์ชันด้านบน _stateData และ _proof แทนรายการข้อมูลที่ขึ้นอยู่กับการดำเนินการของ MIPS opcode เดียว เช่น สถานะของเครื่องมือเสมือน MIPS register state, memory state hash ฯลฯ แผนภาพแสดงด้านล่าง:

เราสามารถป้อนพารามิเตอร์ของสภาพแวดล้อมเครื่องเสมือน MIPS เหล่านี้ผ่าน _stateData และ _proof, รัน MIPS instruction เดี่ยวอยู่บนเชื่อมโยง และได้ผลลัพธ์ที่เชื่อถือได้ หากผลลัพธ์ที่ได้ที่เชื่อถือได้บนเชื่อมโยงแตกต่างจากผลลัพธ์ที่ถูกส่งไปโดย sequencer แสดงว่า sequencer มีความผิดปกติ

เรามักอ้างถึงการแฮชของ _stateData เป็น statehash ซึ่งสามารถเข้าใจได้โดยรวมว่าเป็นการแฮชของสถานะเครื่องจำลอง MIPS ทั้งหมด ในฟิลด์หลาย ๆ ใน _stateData memRoot เป็นการออกแบบที่เฉลียวฉลาดที่สุด ตามที่เรารู้ชัดว่า ระหว่างการดำเนินการของโปรแกรม มีการใช้หน่วยความจำจำนวนมาก และ CPU จะตอบสนองกับข้อมูลในที่อยู่หน่วยความจำบางตำแหน่งโดยการอ่านและเขียน ดังนั้น เมื่อเราดำเนินการด้วย MIPS opcode บนเชนผ่านฟังก์ชัน VM.Step เราต้องให้ข้อมูลจากที่อยู่หน่วยความจำบางตำแหน่งในเครื่องจำลอง MIPS

OP ใช้สถาปัตยกรรม 32 บิตสำหรับเครื่องจำลอง MIPS และหน่วยความจำของมันประกอบด้วยที่อยู่ 2^27 ที่สามารถจัดองค์ประกอบในต้นไม้เมอร์เคิลทวีตระดับ 28 ระดับ โหนดใบในระดับต่ำสุดมีจำนวน 2^27 โหนดแต่ละโหนดบันทึกข้อมูลจากที่อยู่หน่วยความจำเซิร์ฟเวอร์ ฮาชที่คำนวณจากข้อมูลทั้งหมดในใบคือ memRoot แผนภูมิด้านล่างแสดงโครงสร้างของต้นไม้เมอร์เคิลที่บันทึกข้อมูลหน่วยความจำเครื่องจำลอง MIPS:

เราต้องให้เนื้อหาจากที่อยู่หน่วยความจำบางจุด และเนื้อหานี้ถูกอัปโหลดไปยังเชน Ethereum ผ่านฟิลด์ _proof ในฟังก์ชันขั้นตอน นอกจากนี้ เราต้องอัปโหลดพิสูจน์ Merkle โดยใช้ต้นไม้ Merkle หน่วยความจำเพื่อพิสูจน์ว่าข้อมูลที่คุณ (หรือตัวจัดเรียง) มีจริงอยู่ในต้นไม้ Merkle หน่วยความจำ แทนที่จะถูกปลอม

Interactive fraud proof

ในส่วนก่อนหน้าเราได้แก้ปัญหาอันที่สองโดยการสมบูรณ์การดำเนินการบนเชนของ MIPS opcodes และการยืนยันสถานะเครื่องเสมือน แต่ฉลาดอย่างไรยังไง ผู้ท้าทายและตัวจัดลำดับสามารถชี้บอก MIPS opcode ที่ถูกขัดแย้งได้อย่างแน่นอนหรือไม่?

หลายคนอาจจะได้อ่านคำอธิบายเบื้องต้นเกี่ยวกับการพิสูจน์การฉ้อโกงแบบอินเทอร์แอคทีฟออนไลน์และได้ยินเกี่ยวกับวิธีการค้นหาทวิภาคิสซึ่งอยู่เบื้องหลัง ทีม OP ได้พัฒนาโปรโตคอลที่เรียกว่า Fault Dispute Game (FDG) โปรโตคอล FDG ประกอบด้วยบทบาทสองประการคือ challenger และ defender

หากเราพบว่า OutputRoot ที่ถูกส่งเข้ามาโดย sequencer on-chain ไม่ถูกต้อง เราสามารถทำหน้าที่เป็นผู้ท้าทายใน FDG โดย sequencer ทำหน้าที่เป็นผู้ป้องกัน เพื่อช่วยในการระบุ MIPS opcode ที่ต้องการประมวลผล on-chain โปรโตคอล FDG ต้องการผู้ร่วมเพื่อสร้าง Merkle tree ที่เรียกว่า GameTree ในท้องถิ่น โครงสร้างเฉพาะของมันคือ

เราสามารถเห็นได้ว่า GameTree มีโครงสร้างที่ซับซ้อนพอสมควร ประกอบด้วยโครงสร้างต้นไม้ระดับที่หนึ่งและระดับย่อยระดับที่สอง กล่าวอีกนัยหนึ่ง โหนดใบของต้นไม้ระดับที่หนึ่งมี subtree

เหมือนกับที่กล่าวไว้แล้ว ทุกบล็อกที่สร้างขึ้นโดยตัวจัดเรียงมี OutputRoot และโหนดใบของต้นไม้ระดับแรกใน GameTree แทน OutputRoots ของบล็อกที่แตกต่างกัน ผู้ท้าทายและผู้ปกป้องจำเป็นต้องมีปฏิสัมพันธ์ภายในต้นไม้เมอร์เคิลที่เกิดจาก OutputRoots เพื่อกำหนดว่า OutputRoot ของบล็อกไหนอยู่ในข้อพิพาท

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

หลังจากมีการจับคู่หลายครั้งบนเชื่อมโยง ฝ่ายที่เกี่ยวข้องสุดท้ายก็หาจุดที่ถูกโค้ดที่ถูกโค้ดที่ถูกโค้ดได้อย่างแน่นอน และกำหนดรหัสที่ต้องโดดเด่น MIPS ที่เฉพาะเจาะจงที่จำเป็นต้องทำงานบนเชื่อมโยง

ในจุดนี้ เราได้เสร็จสิ้นกระบวนการทั้งหมดของการสุญญากาศประกันการป้องกันการฉ้อโกงแบบโต้ตอบ สรุปได้ว่า กลไกหลัก 2 ของการสุญญากาศประกันการป้องกันการฉ้อโกงแบบโต้ตอบ คือ:

1. FDG (Fault Dispute Game) จะค้นหา MIPS opcode ที่ต้องการ executed บน-chain พร้อมกับข้อมูลสถานะ VM ณ จุดในเวลานั้น;

2. เครื่องจำลองเสมือน MIPS ที่นำมาปฏิบัติบนเชือก Ethereum จะดำเนินการโค้ดโอพคอด โดยทำให้ได้ผลลัพธ์สุดท้าย

ZK Fraud Proof

ZK Fraud Proof ตามที่เราเห็น วิธีการป้องกันฉ้อโกงแบบดัชนีมีการปฏิสัมพันธ์ที่ซับซ้อนมาก ต้องการการปฏิสัมพันธ์หลายรอบในกระบวนการ FDG และการเล่นคำสั่งแต่ละคำสั่งบนเชื่อมโยงโซ่ อย่างไรก็ตาม วิธีนี้มีความท้าทายหลายประการ

ต้องเรียกใช้การจินตนาการหลายรอบบนโซ่ Ethereum ซึ่งทำให้เกิดการจินตนาการที่หลายรายการซึ่งมีค่า gas สูงมาก 2. กระบวนการการชี้ของหลายรายการใช้เวลานานและเมื่อการจินตนาการเริ่มต้น Rollup ไม่สามารถประมวลผลธุรกรรมได้อย่างปกติ 3. การนำเสนอ VM ที่เฉพาะเชิงบนโซ่เพื่อเล่นคำสั่งอย่างกลับอย่างซับซ้อน มีความยากลำบากและมีความยากในการพัฒนาสูง

เพื่อแก้ไขปัญหาเหล่านี้ Optimism ได้แนะนําแนวคิดของ ZK Fraud Proof แนวคิดหลักคือเมื่อผู้ท้าชิงยกความท้าทายพวกเขาระบุธุรกรรมที่พวกเขาเชื่อว่าจําเป็นต้องเล่นซ้ําในห่วงโซ่ ซีเควนเซอร์ Rollup ให้หลักฐาน ZK สําหรับธุรกรรมที่ท้าทาย ซึ่งจะได้รับการตรวจสอบโดยสัญญาอัจฉริยะบนห่วงโซ่ Ethereum หากการตรวจสอบสําเร็จจะสรุปได้ว่าไม่มีข้อผิดพลาดในการประมวลผลธุรกรรมและโหนด Rollup ไม่ใช่ความผิด

ในแผนภูมิ Challengerอ้างถึงฝ่ายที่เสนอท้า challenge และDefenderเป็นตัวเรียงลำดับ OP ภายใต้เงื่อนไขปกติ ตัวเรียงลำดับ OP จะสร้างบล็อกขึ้นโดยขึ้นอยู่กับธุรกรรมที่ได้รับและส่งค่ายืนยันสถานะของบล็อกต่าง ๆ ไปยัง Ethereum ยืนยันสถานะเหล่านี้สามารถเห็นได้ง่ายๆ ว่าเป็นค่าแฮชของบล็อก ผู้ท้าทายสามารถท้าทายตามค่าแฮชของบล็อก หลังจากยอมรับท้าทาย ผู้ป้องกันจะสร้าง ZK proof เพื่อแสดงให้เห็นว่าผลลัพธ์การสร้างบล็อกถูกต้อง ในแผนภูมิบอนไซ เป็นเครื่องมือสร้างหลักฐาน ZK เมื่อเทียบกับการพิสูจน์การฉ้อโกงแบบโต้ตอบข้อได้เปรียบที่ใหญ่ที่สุดของ ZK Fraud Proof คือแทนที่การโต้ตอบหลายรอบด้วยการสร้างหลักฐาน ZK รอบเดียวและการตรวจสอบแบบ on-chain สิ่งนี้ช่วยประหยัดเวลาและลดต้นทุนก๊าซได้อย่างมาก นอกจากนี้ ไม่เหมือนกับ ZK Rollups OP Rollups ที่ใช้ ZK Fraud Proof ไม่จําเป็นต้องสร้างหลักฐานทุกครั้งที่มีการผลิตบล็อก แต่พวกเขาสร้างหลักฐาน ZK ชั่วคราวเมื่อถูกท้าทายซึ่งช่วยลดต้นทุนการคํานวณสําหรับโหนด Rollup

แนวคิดของ ZK Fraud Proof ยังได้รับการนำมาใช้โดย BitVM2 โครงการที่ใช้ BitVM2 เช่น Bitlayer, Goat Network, ZKM และ Fiama การนำ ZK Proof verification program ผ่าน Bitcoin scripts ทำให้ขนาดของโปรแกรมที่ต้องนำเข้า on-chain ที่ต้องการมีขนาดเล็กลงอย่างมีนัยสำคัญ เนื่องจากมีข้อจำกัดในพื้นที่ บทความนี้จะไม่ไปอธิบายโดยละเอียดเกี่ยวกับหัวข้อนี้ ติดตามบทความของเราในอนาคตเกี่ยวกับ BitVM2 เพื่อเข้าใจเส้นทางการนำมาใช้งานอย่างลึกซึ้ง!

ข้อความปฏิเสธความรับผิดชอบ:

1. บทความนี้ทําซ้ําจาก [GodRealmX] ลิขสิทธิ์เป็นของผู้เขียนต้นฉบับ [Shew & Noah], if you have any objections to the reprint, please contact the Gate Learnทีม และทีมจะดำเนินการในทันทีตามขั้นตอนที่เกี่ยวข้องเท่าที่เป็นไปได้

2. ข้อจํากัดความรับผิดชอบ: มุมมองและความคิดเห็นที่แสดงในบทความนี้แสดงถึงมุมมองส่วนตัวของผู้เขียนเท่านั้นและไม่ถือเป็นคําแนะนําการลงทุนใด ๆ

3. รุ่นอื่น ๆ ของบทความถูกแปลโดยทีม Gate Learn และไม่ได้กล่าวถึงในGate.ioบทความที่แปลแล้วต้องไม่ทําซ้ําแจกจ่ายหรือลอกเลียนแบบ