นับตั้งแต่ "Summer of Inscriptions" ในปี 2023 เทคโนโลยี Layer2 ของ Bitcoin อยู่ในระดับแนวหน้าของการปฏิวัติ Web3 แม้จะเข้าสู่สนามช้ากว่าโซลูชัน Layer2 ของ Ethereum แต่ Bitcoin ได้ใช้ประโยชน์จากการอุทธรณ์ที่เป็นเอกลักษณ์ของ POW และการเปิดตัว ETF สปอตอย่างราบรื่นซึ่งปราศจากความเสี่ยง "หลักทรัพย์" เพื่อดึงดูดการลงทุนหลายพันล้านดอลลาร์ไปยังภาคที่กําลังเติบโตนี้ภายในเวลาเพียงหกเดือน ในบรรดาสิ่งเหล่านี้เมอร์ลินโดดเด่นในฐานะเอนทิตีที่สําคัญและติดตามมากที่สุดในภูมิทัศน์ Bitcoin Layer2 ซึ่งมีมูลค่ารวมหลายพันล้านที่ถูกล็อค (TVL) ด้วยแรงจูงใจในการปักหลักที่ชัดเจนและผลตอบแทนที่น่าประทับใจเมอร์ลินจึงมีชื่อเสียงอย่างรวดเร็วแซงหน้าระบบนิเวศ Blast ที่รู้จักกันดีในเวลาไม่กี่เดือน ด้วยความคึกคักที่เพิ่มขึ้นรอบ ๆ เมอร์ลินการสํารวจโครงสร้างพื้นฐานทางเทคนิคได้ดึงดูดผู้ชมที่เพิ่มขึ้น ในบทความนี้ Geek Web3 มุ่งเน้นไปที่การถอดรหัสกลยุทธ์ทางเทคนิคที่อยู่เบื้องหลัง Merlin Chain ด้วยการแกะเอกสารที่เปิดเผยต่อสาธารณะและเหตุผลเบื้องหลังการออกแบบโปรโตคอลเรามุ่งมั่นที่จะทําให้กระบวนการดําเนินงานของ Merlin ชัดเจนขึ้นและเพิ่มความเข้าใจในกรอบความปลอดภัยโดยให้มุมมองที่ชัดเจนยิ่งขึ้นว่าโซลูชัน Bitcoin Layer2 ชั้นนํานี้ทํางานอย่างไร

เครือข่ายออราเคิลที่ไม่มีศูนย์กลางของเมอร์ลิน: คณะกรรมการ DAC แบบเปิด

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

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

ในบรรดาผู้ใช้กลยุทธ์แรก Citrea ยอดเยี่ยม พวกเขามีเป้าหมายที่จะอัปโหลดการเปลี่ยนแปลงใน Layer2 states ในระยะเวลาที่แน่นอน ซึ่งเกี่ยวข้องกับการบันทึกผลลัพธ์ของการเปลี่ยนแปลงของสถานะที่เกิดขึ้นในบัญชีหลายๆ รายการพร้อมกับศาสตร์พิสัยที่เป็นศูนย์ (ZKPs) ที่เกี่ยวข้องลงบนเครือข่าย Bitcoin ภายใต้ข้อตกลงนี้ ใครก็สามารถเข้าถึง state diffs และ ZKPs จาก Bitcoin mainnet เพื่อติดตามการเปลี่ยนแปลงของสถานะของ Citrea การเชิงนี้ช่วยลดขนาดของข้อมูลที่อัปโหลดลงบนบล็อกเชนลงมากกว่า 90%

ถึงแม้ว่าสิ่งนี้สามารถบีบอัดขนาดข้อมูลได้อย่างมาก แต่จุด bottleneck ยังคงเป็นเรื่องชัดเจน หากมีจำนวนบัญชีมากเปลี่ยนสถานะของพวกเขาในช่วงเวลาสั้น ๆ Layer 2 ต้องสรุปและอัปโหลดการเปลี่ยนแปลงทั้งหมดในบัญชีเหล่านี้ไปยังโซ่ Bitcoin ต้นทางจะไม่สามารถรักษาต้นทุนการปล่อยข้อมูลสุดท้ายให้ต่ำมากได้ สิ่งนี้เป็นจริงใน Ethereum หลายรูปแบบ สามารถเห็นได้ใน ZK Rollup

มากมายจาก Bitcoin Layer 2 จะเลือกทางที่สองโดยตรง: ใช้วิธี DA solution ภายใต้เครือข่าย Bitcoin โดยตรง ไม่ว่าจะเป็นการสร้างชั้น DA โดยตนเอง หรือใช้ Celestia, EigenDA, ฯลฯ B^Square, BitLayer และตัวละครหลักของบทความนี้, Merlin, ใช้วิธีการขยาย DA นอกเครือข่ายนี้

บทความก่อนหน้าในเว็บ geek web3——“การวิเคราะห์เทคโนโลยีเวอร์ชัน B^2 แผนการขยาย: ความจำเป็นของ DA และชั้นการตรวจสอบภายใต้ Bitcoin Chain”, เราได้กล่าวถึงว่า B^2 ลอกแบบ Celestia โดยตรงและสร้างเครือข่าย DA ที่รองรับฟังก์ชันการสุ่มข้อมูลในเครือข่าย ที่เรียกว่า B^2 Hub ข้อมูล DA เช่น ข้อมูลธุรกรรมหรือสถานะต่าง ๆ ถูกเก็บไว้ใต้เครือข่าย Bitcoin และเฉพาะ datahash / merkle root ถูกอัปโหลดไปยัง Bitcoin mainnet.

นี่เป็นการจัดการ Bitcoin ในลักษณะกระดานป้ายข้อความที่ไม่มีความเชื่อถือ: ใครก็สามารถอ่านข้อมูลจากเชน Bitcoin ได้ หลังจากที่คุณได้รับข้อมูล DA จากผู้ให้ข้อมูลออฟเชน คุณสามารถตรวจสอบว่ามันเข้ากันกับข้อมูลในเชนหรือไม่ นั่นคือ hash(data1) == datahash1? หากมีความเข้ากันระหว่างทั้งสองอย่าง หมายความว่าข้อมูลที่ได้จากผู้ให้ข้อมูลออฟเชนถูกต้อง

ชั้น DA ใน Bitcoin's Layer2 อธิบาย:

(Image Source: Geek web3)

ระบบนี้ให้ความมั่นใจว่าข้อมูลจากโหนดออฟเชนสอดคล้องกับ "คำใบ้" หรือ พิสูจน์บน Layer1 ซึ่งช่วยป้องกันปัญหาที่อาจเกิดขึ้นจาก DA layer ให้ข้อมูลเท็จ. อย่างไรก็ตาม ความกังวลขึ้นมาอย่างมีนัยสำคัญหากผู้สร้างข้อมูล - ตัวโปรแกรม ไม่ได้แจกจ่ายข้อมูลจริงๆ ที่เกี่ยวข้องกับ datahash. สมมติว่า ตัวโปรแกรมเพียงส่ง datahash ไปยัง blockchain ของ Bitcoin ในขณะที่ปิดเอาข้อมูลที่เกี่ยวข้องไว้จากการเข้าถึงสาธารณะ จะเกิดอะไรขึ้น?

พิจารณาสถานการณ์ที่ ZK-Proof และ StateRoot เท่านั้นที่เปิดเผย แต่ข้อมูล DA ที่ใช้เปรียบ (เช่น state diffs หรือข้อมูลการทำธุรกรรม) ไม่ได้เผยแพร่ ในขณะที่เป็นไปได้ที่จะตรวจสอบ ZK-Proof และให้ความแน่ใจว่าการเปลี่ยนจาก Prev_Stateroot เป็น New_Stateroot เป็นที่ถูกต้อง มันทิ้งไว้ว่าบัญชีไหนที่มีการเปลี่ยนแปลง ภายใต้สถานการณ์เหล่านี้ แม้ว่าทรัพย์สินของผู้ใช้จะยังคงปลอดภัย สภาพจริงของเครือข่ายยังคงไม่ชัดเจน ไม่มีใครรู้ว่าธุรกรรมไหนได้รวมเข้าสู่บล็อกเชนหรือสถานะสัญญาได้รับการอัพเดต ทำให้ Layer2 ไม่สามารถใช้งานได้อย่างมีประสิทธิภาพ เกือบเหมือนว่ามันได้ล็อคอิน

การปฏิบัตินี้เรียกว่า "การเก็บข้อมูล" ในเดือนสิงหาคม 2023 ดังรักราดจากมูลนิธิ Ethereum เริ่มการสนทนาบนทวิตเตอร์เกี่ยวกับแนวคิดที่รู้จักกันดีเรื่อง "DAC"

ในการติดตั้ง Ethereum Layer2 หลายรูปแบบที่ใช้โซลูชันการให้ข้อมูลนอกเชนที่เรียกว่า DA มักจะมีโหนดไม่กี่โหนดที่มีสิทธิพิเศษที่รวมกันเป็นคณะกรรมการที่รู้จักว่า Data Availability Committee (DAC) คณะกรรมการนี้ทำหน้าที่เป็นคนรับประกันโดยการยืนยันว่า Sequencer ได้ปล่อยข้อมูล DA ที่สมบูรณ์จริงๆ (ข้อมูลธุรกรรมหรือ state diff) นอกเชน สมาชิก DAC จากนั้นสร้างลายเซ็นเชิงกลุ่ม หากลายเซ็นเชิงกลุ่มนี้ได้รับความเห็นชอบที่จำเป็น (เช่น 2 จาก 4) สัญญาที่เกี่ยวข้องบน Layer1 ถูกออกแบบให้สมมติว่า Sequencer ประสบการณ์มาตรฐานการตรวจสอบของ DAC และได้ปล่อยข้อมูล DA ทั้งหมดนอกเชน

คณะกรรมการ Ethereum Layer2 DAC ส่วนใหญ่ปฏิบัติตามรูปแบบ Proof of Authority (POA) ซึ่ง จํากัด การเป็นสมาชิกไปยังกลุ่มโหนดที่เลือกซึ่งผ่าน KYC หรือได้รับการแต่งตั้งอย่างเป็นทางการ แนวทางนี้ทําให้ DAC เป็นจุดเด่นของ "การรวมศูนย์" และ "บล็อกเชนแบบกลุ่ม" อย่างมีประสิทธิภาพ นอกจากนี้ในบาง Ethereum Layer2s ที่ใช้แนวทาง DAC ซีเควนเซอร์จะแจกจ่ายข้อมูล DA ไปยังโหนดสมาชิก DAC เท่านั้นโดยมีการเผยแพร่ภายนอกน้อยที่สุด ดังนั้นใครก็ตามที่กําลังมองหาข้อมูล DA จะต้องได้รับการอนุมัติจาก DAC ซึ่งคล้ายกับการดําเนินงานภายในบล็อกเชนของกลุ่ม

ชัดเจนว่า DACs ต้องเป็นระบบที่กระจายอำนาจ แม้ว่า Layer2 อาจจะไม่จำเป็นต้องอัปโหลดข้อมูล DA โดยตรงไปยัง Layer1 สมาชิก DAC ความเข้าถึงควรเปิดเผยให้ทุกคนเพื่อป้องกันการแข่งขันและความผิดปกติโดยบุคคลบางราย (สำหรับข้อมูลเพิ่มเติมเกี่ยวกับปัญหานี้ อ่านเพิ่มเติมในการอภิปรายก่อนหน้าของ Dankrad ในทวิตเตอร์)

ข้อเสนอของ Celestia เกี่ยวกับ BlobStream มีจุดประสงค์พื้นฐานที่จะแทนที่ DAC แบบกระจายกลางด้วย Celestia ภายใต้โมเดลนี้ ซีเควนเซอร์ระดับ 2 ของ Ethereum จะโพสต์ข้อมูล DA ไปยังบล็อกเชนของ Celestia หากสุดยอดสามส่วนสองของโหนดของ Celestia ตรวจสอบข้อมูลเหล่านี้ สัญญาชั้น 2 ที่เชี่ยวชาญบน Ethereum จะตรวจสอบว่าซีเควนเซอร์ได้เผยแพร่ข้อมูล DA อย่างถูกต้อง ซึ่งจะทำให้โหนดของ Celestia เป็นผู้รับรอง ด้วยระบบโหนดที่มีอยู่หลายร้อยโหนด การกำหนดค่า DAC ขนาดใหญ่นี้ถือว่ามีระดับการกระจายที่สูง

โซลูชั่น DA ที่ Merlin นำมาใช้นั้นจริง ๆ มีความใกล้เคียงกับ Celestia's BlobStream โดยทั้งสองระบบเปิดการเข้าถึง DAC ผ่าน POS ทำให้มีการกระจายอำนาจมากขึ้น ใครก็สามารถเริ่มทำงานเป็น DAC node ได้เพียงแค่เขาวางเงินมัดจำสินทรัพย์เพียงพอ ในเอกสารของ Merlin กล่าวถึง DAC node ที่กล่าวถึงข้างต้นถูกเรียกว่า Oracle และได้ระบุว่าจะสนับสนุนการมัดจำสินทรัพย์ของ BTC, MERL และ แม้แต่ BRC-20 tokens เพื่อให้สามารถสร้างกลไกการมัดจำที่ยืดหยุ่นและยังสนับสนุนการมัดจำแบบพร็อกซี่ที่คล้ายกับ Lido (ข้อตกลงการมัดจำ POS ของเครื่อง Oracle พื้นฐานๆ หนึ่งในเรื่องราวหลักถัดไปของ Merlin และอัตราดอกเบี้ยของการมัดจำที่ให้บริการเป็นอย่างสูง)

ที่นี่เราจะอธิบายกระบวนการของ Merlin โดยสั้นๆ (รูปด้านล่าง):

1. หลังจากที่ตัวจัดเรียงได้รับคำขอธุรกรรมจำนวนมาก มันจะรวมพวกและสร้างชุดข้อมูล (ชุดข้อมูล) ซึ่งถูกส่งให้โหนด Prover และโหนด Oracle (DAC ที่ไม่ centralize)

2. โหนด Merlin's Prover ถูกกระจายและใช้บริการ Prover ของ lumoz เป็นบริการ หลังจากได้รับชุดข้อมูลหลายชุด พูลขุดแร่ Prover จะสร้างพิสูจน์ศูนย์ศูนย์ที่สอดคล้องกัน ต่อมา ZKP จะถูกส่งไปยังโหนด Oracle เพื่อการตรวจสอบ

3. โหนด Oracle จะตรวจสอบว่า ZK Proof ที่ส่งโดยพูลการขุด ZK ของ Lmuoz สอดคล้องกับข้อมูล Batch ที่ส่งโดย Sequencer หากสองอย่างสามารถจับคู่กันและไม่มีข้อผิดพลาดอื่น ๆ การตรวจสอบจะผ่าน ในระหว่างขั้นตอนนี้ โหนด Oracle แบบกระจายจะสร้างลายเซ็นต์หลายรูปแบบผ่านลายเซ็นต์เขตสูงสุดและประกาศต่อโลกภายนอกว่าตัวประสานได้ส่งข้อมูล DA ออกมาอย่างสมบูรณ์และ ZKP ที่สอดคล้องกันถูกต้องและผ่านการตรวจสอบของโหนด Oracle

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

(แผนภาพหลักการทำงานของเมอร์ลิน ที่มา: เน็ตไทยเว็บ3)

1. Oracle nodes perform special processing on the calculation process of verifying ZK Proof, generate Commitment commitments, and send them to the Bitcoin chain, allowing anyone to challenge the “commitment”.The process here is basically the same as bitVM’s fraud proof protocol. If the challenge is successful, the Oracle node that issued the Commitment will be financially punished. Of course, the data that Oracle wants to publish to the Bitcoin chain also includes the hash of the current Layer 2 state - StateRoot, as well as ZKP itself, which must be published to the Bitcoin chain for external detection.

References:“การตีความแบบมินิมอลของ BitVM: วิธีการตรวจสอบข้อพิสูจน์การฉ้อโกงบน BTC Chain”

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

References:การวิเคราะห์เทคโนโลยีรุ่นใหม่ B^2: ความจำเป็นของ DA และชั้นการตรวจสอบภายใต้ Bitcoin Chain

การวิเคราะห์โมเดลความปลอดภัย: การวิเคราะห์โมเดลความปลอดภัยแบบโต้ตอบ ZKRollup+Cobo’s MPC service

ข้างต้นเราได้บรรยายกระบวนการทำงานของ Merlin อย่างสั้น ๆ แล้ว และฉันเชื่อว่าคุณได้รู้จักโครงสร้างพื้นฐานของมันไปแล้ว ไม่ยากที่จะเห็นว่า Merlin, B^Square, BitLayer, และ Citrea มีระบบรักษาความปลอดภัยเหมือนกันโดยพื้นฐาน—โมเดลความปลอดภัยแบบ optimistic ZK-Rollup

เมื่ออ่านคำนี้ครั้งแรก ผู้สนใจ Ethereum หลายคนอาจรู้สึกแปลก คืออะไร "optimistic ZK-Rollup"? ในการเข้าใจของ Ethereum community, "theoretical model" ของ ZK Rollup นั้น พึงพอใจบนความเชื่อถือได้ของการคำนวณทางกายภาพและไม่ต้องการการสมมติการเชื่อมั่น คำว่า "optimistic" นำเสนอการสมมติการเชื่อมั่นอย่างชัดเจนซึ่งหมายความว่าคนบ่อยๆ จะมีทัศนคติที่ดีกับ Rollup ว่ามันไม่มีข้อผิดพลาดและเชื่อถือได้ หากเกิดข้อผิดพลาด ผู้ดำเนิน Rollup สามารถถูกลงโทษผ่านการพิสูจน์การโกง นี้เป็นต้นกำเนิดของชื่อ Optimistic Rollup หรือรู้จักกันในนาม OP Rollup

สำหรับนิวมัติซึ่งเป็นฐานของ Rollup ในระบบ Ethereum จะมีแนวโน้มที่จะเป็น ZK-Rollup ที่เติบโตเป็นอย่างมาก แต่มันก็ตรงตามสถานการณ์ปัจจุบันของ Bitcoin Layer 2 อย่างแท้จริงเนื่องจาก จำกัดทางเทคนิค ซึ่ง Bitcoin chain ไม่สามารถยืนยัน ZK Proof อย่างสมบูรณ์ได้ มันสามารถยืนยันเฉพาะขั้นตอนบางขั้นตอนของกระบวนการคำนวณของ ZKP ภายใต้เงื่อนไขพิเศษ ภายใต้เงื่อนไขนี้ Bitcoin chain จริง ๆ สามารถรองรับเพียง protocol การพิสูจน์การโกง คน ๆ แสดงว่ามีข้อผิดพลาดในขั้นตอนการคำนวณบางขั้นตอนของ ZKP ในขณะที่อยู่ในกระบวนการยืนยันแบบ off-chain และถูกท้าทายผ่านการพิสูจน์การโกง แน่นอนว่าสิ่งนี้ไม่สามารถเปรียบเทียบกับ Ethereum-style ZK Rollup แต่มันเป็นสิ่งที่ดีที่สุดที่ Bitcoin Layer 2 สามารถทำได้ในปัจจุบัน โมเดลความปลอดภัยที่เชื่อถือได้และปลอดภัยที่สุด

ภายใต้โครงการ ZK-Rollup ในแง่ดีข้างต้นสมมติว่ามีคน N ในเครือข่าย Layer 2 ที่มีอํานาจในการเริ่มต้นความท้าทาย ตราบใดที่หนึ่งในผู้ท้าชิง N มีความซื่อสัตย์และเชื่อถือได้และสามารถตรวจจับข้อผิดพลาดและเริ่มการพิสูจน์การฉ้อโกงได้ตลอดเวลาการเปลี่ยนสถานะเลเยอร์ 2 นั้นปลอดภัย แน่นอนว่า Rollup ในแง่ดีที่มีระดับความสําเร็จค่อนข้างสูงจําเป็นต้องตรวจสอบให้แน่ใจว่าสะพานถอนได้รับการคุ้มครองโดยโปรโตคอลหลักฐานการฉ้อโกง อย่างไรก็ตาม Bitcoin Layer 2 เกือบทั้งหมดในปัจจุบันไม่สามารถบรรลุหลักฐานนี้ได้และจําเป็นต้องพึ่งพาหลายลายเซ็น / MPC ดังนั้นวิธีการเลือกหลายลายเซ็น? การลงนามในโซลูชัน MPC ได้กลายเป็นปัญหาที่เกี่ยวข้องกับความปลอดภัยของเลเยอร์ 2 อย่างใกล้ชิด

เมอร์ลินเลือกบริการ MPC ของ Cobo สําหรับโซลูชันสะพาน การใช้มาตรการต่างๆเช่นการแยกกระเป๋าเงินร้อนและเย็นสินทรัพย์สะพานได้รับการจัดการร่วมกันโดย Cobo และ Merlin Chain พฤติกรรมการถอนเงินใด ๆ จะต้องได้รับการจัดการร่วมกันโดยผู้เข้าร่วม MPC ของ Cobo และ Merlin Chain โดยพื้นฐานแล้วความน่าเชื่อถือของสะพานถอนเงินได้รับการรับประกันผ่านการรับรองเครดิตของสถาบัน . แน่นอนว่านี่เป็นเพียงมาตรการหยุดยั้งในขั้นตอนนี้ เมื่อโครงการค่อยๆดีขึ้นสะพานถอนสามารถถูกแทนที่ด้วย "สะพานมองโลกในแง่ดี" ด้วยสมมติฐานความน่าเชื่อถือ 1 / N โดยการแนะนํา BitVM และโปรโตคอลป้องกันการฉ้อโกง อย่างไรก็ตามการดําเนินการนี้จะยากขึ้น ขนาดใหญ่ (สะพานเลเยอร์ 2 อย่างเป็นทางการเกือบทั้งหมดในปัจจุบันอาศัยลายเซ็นหลายลายเซ็น)

โดยรวมเราสามารถจัดเรียงมันได้, Merlin ได้แนะนำ POS-based DAC, BitVM-based optimistic ZK-Rollup และ Cobo-based MPC asset custody solution, แก้ปัญหา DA โดยการเปิด DAC permissions; การรักษาความปลอดภัยของการเปลี่ยนสถานะด้วยการนำเสนอ BitVM และ fraud proof protocols; การรักษาความเชื่อถือของสะพานถอนเงินโดยการนำเสนอบริการ MPC ของแพลตฟอร์มการรักษาสินทรัพย์ชื่อดัง Cobo

กลยุทธ์การส่ง ZKP ที่ใช้การตรวจสอบสองขั้นตอนของ Lumoz

ในการสนทนาก่อนหน้าที่ผ่านมา เราได้ศึกษาถึงกรอบความปลอดภัยของ Merlin และสำรวจแนวคิดนวัตกรรมของ optimistic ZK-rollups องค์ประกอบสำคัญในแนวทางเทคโนโลยีของ Merlin คือ Prover แบบกระจายบทบาทนี้มีความสำคัญภายในโครงสร้าง ZK-Rollup ที่มีหน้าที่ในการสร้าง ZK Proofs สำหรับชุดที่ถูกปล่อยตามลำดับการทำงาน การสร้างพิสูจน์ที่ไม่มีความรู้เป็นสิ่งที่ใช้ทรัพยากรมาก ซึ่งเป็นความท้าทายที่สำคัญ

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

เพื่อเพิ่มความเร็วในกระบวนการสร้าง ZK proof, Merlin จะใช้ Lumoz's Prover ในรูปแบบบริการเพื่อรวมอุปกรณ์ฮาร์ดแวร์จำนวนมากเข้าด้วยกันเพื่อสร้างพูลขุดเหมือง แล้วแบ่งงานคำนวณให้กับอุปกรณ์ต่าง ๆ และแบ่งส่วนแรงขันตอน ที่คล้ายกับการขุด POW

ในโซลูชัน Prover แบบไม่centralized นี้ มีประเภทหนึ่งของสถานการณ์การโจมตีที่รู้จักกันดีว่าเป็น front-running attack: สมมติว่า Aggregator ได้สร้าง ZKP และส่ง ZKP เพื่อรับรางวัล หลังจากที่ Aggregator คนอื่นเห็นเนื้อหาของ ZKP พวกเขาเผยแพร่เนื้อหาเดียวกันก่อนเขา อ้างว่าเขาสร้าง ZKP ก่อนอื่น ๆ อย่างไรเพื่อแก้ไขสถานการณ์นี้?

บางทีวิธีการที่ทุกคนคิดถึงอย่างอุดมคติคือการกำหนดหมายเลขงานที่กำหนดให้กับแต่ละตัวรวม ตัวอย่างเช่น ตัวรวม A เท่านั้นที่สามารถรับงาน 1 และคนอื่น ๆ จะไม่ได้รับรางวัล แม้ว่าพวกเขาจะทำงานเสร็จงาน 1 แต่มีปัญหาหนึ่งในวิธีการนี้คือว่ามันไม่สามารถต้านความเสี่ยงจุดเดียวได้ หากตัวรวม A มีปัญหาในการทำงานหรือตัดการเชื่อมต่องาน 1 จะติดและไม่สามารถเสร็จสิ้น นอกจากนี้วิธีการนี้ในการจัดสรรงานให้กับหน่วยงานเดี่ยวตัวเองไม่สามารถเพิ่มประสิทธิภาพในการผลิตผลผลิตผ่านกลไกสร้างแรงจูงใจที่แข่งขันและไม่ใช่วิธีการที่ดี

Polygon zkEVM เคยเสนอวิธีที่เรียกว่า Proof of efficiency ในบล็อก ซึ่งชี้แจงว่าควรใช้มาตรการแข่งขันเพื่อส่งเสริมการแข่งขันระหว่าง Aggregators ที่แตกต่างกัน และควรจัดสรรสิทธิพลิกลำดับ Aggregator ที่ส่ง ZK-Proof ไปยังเชนก่อนสุด จะได้รับรางวัล แน่นอนว่าเขาไม่ได้กล่าวถึงวิธีการแก้ไขปัญหา MEV front-running อย่างไร

Lumoz นำเสนอวิธีการยืนยันแบบสองขั้นตอนด้วยวิธีการส่งใบรับรอง ZK หลังจากที่ Aggregator สร้างใบรับรอง ZK มันไม่จำเป็นต้องส่งเนื้อหาทั้งหมดออกไปทันที แต่เพียงแค่เผยแพร่แค่แค่เฮช ZKP กล่าวคือ เผยแพร่เฮช (ZKP+ที่อยู่ Aggregator) โดยวิธีนี้ แม้แต่คนอื่นจะเห็นค่าเฮชก็ไม่รู้เนื้อหา ZKP ที่เกี่ยวข้องและไม่สามารถข้ามไปข้ามไปได้โดยตรง

ถ้าใครบางคนเพียงแค่คัดลอกแฮชทั้งหมดและเผยแพร่ในตอนแรก ก็ไม่มีประโยชน์เพราะแฮชมีที่อยู่ของตัวรวมที่เฉพาะเจาะจง X แม้ว่าตัวรวม A จะเผยแพร่แฮชก่อนแต่เมื่อภาพต้นฉบับของแฮชเปิดเผย ทุกคนก็จะเห็นว่าที่อยู่ของตัวรวมที่รวมอยู่ในนั้นคือ X ไม่ใช่ A

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

Merlin’s Phantom: ความสามารถในการทำงานร่วมกันของหลายๆ โซน

ตามแผนเทคโนโลยีของ Merlin พวกเขายังจะสนับสนุนความสามารถในการทำงานร่วมกันระหว่าง Merlin และเครือข่าย EVM อื่น ๆ และเส้นทางการปฏิบัติของมันเบื้องต้นเหมือนกับความคิดเห็น Zetachain ก่อนหน้านี้ หาก Merlin ถูกใช้เป็นเครือข่ายต้นฉบับและเครือข่าย EVM อื่น ๆ ถูกใช้เป็นเครือข่ายเป้าหมายเมื่อโหนด Merlin รับรู้คำขอการทำงานร่วมกันข้ามเครือข่ายที่ออกโดยผู้ใช้ มันจะเริ่มกระตุ้นงานต่อมาบนเครือข่ายเป้าหมาย

ตัวอย่างเช่นบัญชี EOA ที่ควบคุมโดยเครือข่าย Merlin สามารถถูกใช้งานบน Polygon ขณะที่ผู้ใช้ส่งคำสั่งความสามารถในการทำงานข้ามเครือข่ายบน Merlin Chain เครือข่าย Merlin จะแยกวิเคราะห์เนื้อหาของมันและสร้างข้อมูลธุรกรรมที่จะทำงานบนเครือข่ายเป้าหมาย และจากนั้นเครือข่าย Oracle จะดำเนินการประมวลผลลายมาตรข้อความ MPC บนธุรกรรมเพื่อสร้างหมายเลขธุรกรรม ซึ่งเป็นการลงลายมือลายเท้า Merlin's Relayer node จากนั้นจะปลดปล่อยธุรกรรมบน Polygon ทำการดำเนินการต่อไปผ่านทรัพยากร Merlin ในบัญชี EOA บนเครือข่ายเป้าหมาย เช่น

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

สรุป

ในบทความนี้ เราจะอธิบายโดยสั้น ๆ เกี่ยวกับวิธีการทางเทคนิคทั่วไปของ Merlin Chain ซึ่งเราเชื่อว่าจะทำให้มีคนมากขึ้นเข้าใจกระบวนการทำงานทั่วไปของ Merlin และมีความเข้าใจชัดเจนกว่าเกี่ยวกับโมเดลความปลอดภัยของมัน โดยพิจารณาถึงว่าระบบ Bitcoin ปัจจุบันกำลังพัฒนาอย่างต่อเนื่อง เราเชื่อว่ากิจกรรมการทำเทคโนโลยีประเภทนี้มีค่าและจำเป็นสำหรับประชาชนทั่วไป เราจะดำเนินการติดตาม Merlin, bitLayer, B^Square และโครงการอื่น ๆ ในอนาคตเพื่อวิเคราะห์อย่างละเอียดเรื่องวิธีการทางเทคนิคของมันอย่างยาวนาน ดังนั้นโปรดติดตาม!

Disclaimer:

1. บทความนี้ถูกคัดลอกมาจาก [Gategeek web3] ลิขสิทธิ์เป็นของผู้เขียนต้นฉบับ [Faust] หากคุณมีข้อขัดแย้งใด ๆ เกี่ยวกับการนำเสนอซ้ำ โปรดติดต่อGate Learn Team, ทีมจะดำเนินการให้เร็วที่สุดตามขั้นตอนที่เกี่ยวข้อง

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

3. รูปภาษาอื่น ๆ ของบทความถูกแปลโดยทีม Gate Learn โดยไม่ต้องอ้างอิงGate.io, การคัดลอก การกระจาย หรือการลอกเลียนแบบบทความที่ถูกแปล ถูกห้าม