การตีความทางเทคนิค: Merlin Chain ทำงานอย่างไร
ผู้เขียนต้นฉบับ: เฟาสต์, geek web3
ตั้งแต่ฤดูร้อนแห่งจารึกในปี 2023 จนถึงปัจจุบัน Bitcoin Layer 2 ถือเป็นจุดเด่นของ Web3 ทั้งหมดมาโดยตลอด แม้ว่าการเพิ่มขึ้นของสาขานี้จะช้ากว่า Ethereum Layer 2 มาก แต่ด้วยเสน่ห์อันเป็นเอกลักษณ์ของ POW และการใช้งาน Spot ETFs อย่างราบรื่น Bitcoin ซึ่งไม่จำเป็นต้องกังวลเกี่ยวกับความเสี่ยงของ "การแปลงสินทรัพย์เป็นหลักทรัพย์" กลับกลายเป็นเลเยอร์ 2 ในเวลาเพียงครึ่งปี เส้นทางอนุพันธ์นี้ดึงดูดความสนใจของเงินทุนมูลค่าหลายหมื่นล้านดอลลาร์
ในเส้นทาง Bitcoin Layer 2 นั้น Merlin ซึ่งมีทรัพย์สินนับพันล้านดอลลาร์ใน TVL นั้นเป็นเส้นทางที่มีปริมาณมากที่สุดและมีผู้ติดตามมากที่สุดอย่างไม่ต้องสงสัย ด้วยแรงจูงใจในการปักหลักที่ชัดเจนและผลตอบแทนจำนวนมาก เมอร์ลินเกือบจะลุกขึ้นจากพื้นดินทันทีภายในไม่กี่เดือน ทำให้เกิดตำนานทางนิเวศวิทยาที่เหนือกว่าบลาสต์ เมื่อ Merlin ได้รับความนิยมมากขึ้นเรื่อยๆ การอภิปรายเกี่ยวกับโซลูชันทางเทคนิคของ Merlin ก็กลายเป็นหัวข้อที่สร้างความกังวลให้กับผู้คนมากขึ้นเรื่อยๆ
ในบทความนี้ Geek Web3 จะมุ่งเน้นไปที่โซลูชันทางเทคนิคของ Merlin Chain และตีความเอกสารที่เผยแพร่และแนวคิดการออกแบบโปรโตคอล เรามุ่งมั่นที่จะให้ผู้คนเข้าใจขั้นตอนการทำงานทั่วไปของ Merlin มากขึ้น และมีความเข้าใจที่ชัดเจนยิ่งขึ้นเกี่ยวกับโมเดลความปลอดภัย ช่วยให้ทุกคนเข้าใจ "Head Bitcoin Layer 2" นี้ทำงานอย่างไรในลักษณะที่ใช้งานง่ายยิ่งขึ้น
เครือข่ายออราเคิลแบบกระจายอำนาจของ Merlin: คณะกรรมการ DAC นอกเครือข่ายแบบเปิด
สำหรับเลเยอร์ 2 ทั้งหมด ไม่ว่าจะเป็น Ethereum Layer 2 หรือ Bitcoin Layer 2 ต้นทุน DA และการปล่อยข้อมูลถือเป็นหนึ่งในปัญหาที่สำคัญที่สุดที่ต้องแก้ไข เนื่องจากเครือข่าย Bitcoin เองมีปัญหามากมายและไม่รองรับการรับส่งข้อมูลขนาดใหญ่โดยธรรมชาติ การใช้พื้นที่ DA อันมีค่านี้จึงกลายเป็นปัญหายากที่ทดสอบจินตนาการของโครงการเลเยอร์ 2
ข้อสรุปหนึ่งที่ชัดเจน: หากเลเยอร์ 2 "โดยตรง" เผยแพร่ข้อมูลธุรกรรมที่ยังไม่ได้ประมวลผลไปยังบล็อก Bitcoin ก็จะไม่ได้รับปริมาณงานที่สูงหรือค่าธรรมเนียมการจัดการต่ำ โซลูชันกระแสหลักที่สุดคือการบีบอัดขนาดข้อมูลให้เล็กที่สุดเท่าที่จะเป็นไปได้ผ่านการบีบอัดสูงแล้วอัปโหลดไปยังบล็อก Bitcoin หรือเผยแพร่ข้อมูลโดยตรงภายใต้ห่วงโซ่ Bitcoin
ในบรรดาเลเยอร์ 2 ที่ใช้แนวคิดแรก แนวคิดที่มีชื่อเสียงที่สุดน่าจะเป็น Citrea พวกเขาวางแผนที่จะเปลี่ยนแปลงการเปลี่ยนแปลงสถานะของเลเยอร์ 2 ในช่วงเวลาหนึ่ง (สถานะต่าง) นั่นคือผลลัพธ์ของการเปลี่ยนแปลงสถานะในหลายบัญชี พร้อมกับหลักฐาน ZK ที่เกี่ยวข้องอัปโหลดไปยังห่วงโซ่ Bitcoin ด้วยกัน ในกรณีนี้ ทุกคนสามารถดาวน์โหลด state diff และ ZKP จาก Bitcoin mainnet จากนั้นตรวจสอบการเปลี่ยนแปลงในสถานะ Citrea วิธีนี้สามารถบีบอัดขนาดข้อมูลบนลูกโซ่ได้มากกว่า 90%
แม้ว่าสิ่งนี้จะสามารถบีบอัดขนาดข้อมูลได้อย่างมาก แต่ปัญหาคอขวดก็ยังคงชัดเจน หากบัญชีจำนวนมากเปลี่ยนสถานะในช่วงเวลาสั้น ๆ เลเยอร์ 2 จะต้องสรุปและอัปโหลดการเปลี่ยนแปลงทั้งหมดในบัญชีเหล่านี้ไปยังห่วงโซ่ Bitcoin ไม่สามารถรักษาต้นทุนการเปิดเผยข้อมูลขั้นสุดท้ายให้ต่ำมากได้ โซ่ สามารถดูได้จาก ZK Rollup
Bitcoin Layer 2 จำนวนมากใช้เส้นทางที่สอง: ใช้โซลูชัน DA โดยตรงจากห่วงโซ่ Bitcoin หรือสร้างเลเยอร์ DA ด้วยตัวเอง หรือใช้ Celestia, EigenDA ฯลฯ B^Square, BitLayer และตัวเอกของบทความนี้ Merlin ต่างก็ใช้โซลูชันการขยาย DA แบบออฟไลน์นี้
ในบทความก่อนหน้าของ Geekweb3 - "การวิเคราะห์แผนงานทางเทคนิคใหม่ของ B^ 2: ความจำเป็นของ DA และเลเยอร์การตรวจสอบภายใต้ห่วงโซ่ Bitcoin" เราได้กล่าวถึงว่า B^ 2 เลียนแบบ Celestia โดยตรงและสร้างการสนับสนุนนอกเครือข่ายเครือข่าย DA พร้อมฟังก์ชันการสุ่มตัวอย่างข้อมูล มีชื่อว่า B^2 Hub "ข้อมูล DA" เช่น ข้อมูลธุรกรรมหรือค่าต่างสถานะจะถูกเก็บไว้ภายใต้ห่วงโซ่ Bitcoin และมีเพียง datahash / merkle root เท่านั้นที่ถูกอัปโหลดไปยัง Bitcoin mainnet
สิ่งนี้ถือว่า Bitcoin เป็นเหมือนกระดานข่าวที่ไม่น่าเชื่อถือ: ใครๆ ก็สามารถอ่านดาต้าแฮชจากเครือข่าย Bitcoin ได้ หลังจากที่คุณได้รับข้อมูล DA จากผู้ให้บริการข้อมูลนอกเครือข่ายแล้ว คุณสามารถตรวจสอบได้ว่าข้อมูลดังกล่าวสอดคล้องกับข้อมูลแฮชแบบออนไลน์หรือไม่ ซึ่งก็คือแฮช (ข้อมูล 1) == datahash 1? - หากทั้งสองมีความสอดคล้องกัน แสดงว่าข้อมูลที่ผู้ให้บริการข้อมูลนอกเครือข่ายมอบให้คุณนั้นถูกต้อง
กระบวนการข้างต้นสามารถรับประกันได้ว่าข้อมูลที่มอบให้กับคุณโดยโหนดนอกเครือข่ายนั้นเชื่อมโยงกับ "เบาะแส" บางอย่างในเลเยอร์ 1 ซึ่งป้องกันเลเยอร์ DA จากการให้ข้อมูลเท็จอย่างเป็นอันตราย แต่นี่เป็นสถานการณ์เลวร้ายที่สำคัญมาก: สมมติว่าแหล่งที่มาของข้อมูล Sequencer ไม่ได้ส่งข้อมูลที่เกี่ยวข้องกับดาต้าแฮชเลย แต่ส่งดาต้าแฮชไปที่ห่วงโซ่ Bitcoin เท่านั้น แต่จงใจระงับข้อมูลที่เกี่ยวข้องเพื่อป้องกันใครก็ตาม จากการอ่าน เอาล่ะ ตอนนี้ฉันควรทำอย่างไร?
สถานการณ์ที่คล้ายกันรวมถึงแต่ไม่จำกัดเฉพาะ: การปล่อย ZK-Proof และ StateRoot เท่านั้น แต่ไม่ใช่ข้อมูล DA ที่เกี่ยวข้อง (state diff หรือข้อมูลธุรกรรม) แม้ว่าผู้คนจะสามารถตรวจสอบ ZKProof และยืนยันว่ากระบวนการคำนวณจาก Prev_Stateroot ถึง New_Stateroot นั้นถูกต้อง แต่ แต่ฉันไม่รู้ว่าสถานะของบัญชีใดมีการเปลี่ยนแปลง ในกรณีนี้ แม้ว่าทรัพย์สินของผู้ใช้จะปลอดภัย แต่ทุกคนก็ไม่สามารถแน่ใจถึงสถานะที่แท้จริงของเครือข่ายได้เลย พวกเขาไม่ทราบว่าธุรกรรมใดบ้างที่ได้รับการบรรจุในห่วงโซ่และสถานะสัญญาใดที่ได้รับการอัปเดตในขณะนี้ โดยพื้นฐานแล้วเทียบเท่ากับการปิดระบบ
นี่คือ " การระงับข้อมูล " จริงๆ Dankrad จาก Ethereum Foundation ครั้งหนึ่งเคยพูดคุยสั้นๆ เกี่ยวกับปัญหาที่คล้ายกันบน Twitter ในเดือนสิงหาคม 2023 แน่นอนว่าเขากำหนดเป้าหมายไปที่สิ่งที่เรียกว่า "DAC" เป็นหลัก
Ethereum Layer 2 จำนวนมากที่ใช้โซลูชัน DA นอกเครือข่ายมักจะตั้งค่า โหนดหลายโหนดโดยมีสิทธิ์พิเศษในการจัดตั้งคณะกรรมการ โดยมีชื่อเต็มว่า Data Availability Committee (DAC) คณะกรรมการ DAC นี้ทำหน้าที่เป็นผู้ค้ำประกันและกล่าวอ้างต่อโลกภายนอกว่า Sequencer ได้เผยแพร่ข้อมูล DA ที่สมบูรณ์ (ข้อมูลธุรกรรมหรือสถานะต่าง) นอกเครือข่ายแล้ว จากนั้นโหนด DAC จะร่วมกันสร้างหลายลายเซ็น ตราบใดที่หลายลายเซ็นตรงตามข้อกำหนดเกณฑ์ (เช่น 2/4) สัญญาที่เกี่ยวข้องในเลเยอร์ 1 จะเป็นค่าเริ่มต้น The Sequencer ผ่านการตรวจสอบของคณะกรรมการ DAC และตามความเป็นจริง เผยแพร่ข้อมูลนอกเครือข่าย DA ที่สมบูรณ์
คณะกรรมการ DAC ของ Ethereum Layer 2 โดยพื้นฐานแล้วเป็นไปตามโมเดล POA โดยอนุญาตให้มีเพียงไม่กี่โหนดที่ผ่านการ KYC หรือการแต่งตั้งอย่างเป็นทางการเพื่อเข้าร่วมคณะกรรมการ DAC ซึ่งทำให้ DAC มีความหมายเหมือนกันกับ "การรวมศูนย์" และ "ห่วงโซ่พันธมิตร" นอกจากนี้ ในบาง Ethereum Layer 2 ที่ใช้โหมด DAC ตัวซีเควนเซอร์จะส่งข้อมูล DA ไปยังโหนดสมาชิก DAC เท่านั้น และแทบไม่เคยอัปโหลดข้อมูลไปยังที่อื่นเลย ใครก็ตามที่ต้องการรับข้อมูล DA จะต้องได้รับอนุญาตจากคณะกรรมการ DAC เลย ไม่มีความแตกต่างที่สำคัญจากห่วงโซ่พันธมิตร
ไม่ต้องสงสัยเลยว่า DAC ควรได้รับการกระจายอำนาจ เลเยอร์ 2 ไม่จำเป็นต้องอัปโหลดข้อมูล DA ไปยังเลเยอร์ 1 โดยตรง อย่างไรก็ตาม สิทธิ์ในการเข้าถึงของคณะกรรมการ DAC ควรเปิดกว้างสู่โลกภายนอก เพื่อป้องกันไม่ให้คนบางคนสมรู้ร่วมคิดทำชั่ว . (สำหรับการอภิปรายเกี่ยวกับฉากชั่วร้ายของ DAC โปรดดูคำพูดก่อนหน้าของ Dankrad บน Twitter)
BlobStream ที่เสนอก่อนหน้านี้โดย Celestia ใช้ Celestia เพื่อแทนที่ DAC แบบรวมศูนย์ สามารถเผยแพร่ข้อมูล DA ไปยัง Celestia chain ได้ หาก 2/3 ของโหนด Celestia ลงนาม เลเยอร์จะปรับใช้บน Ethereum 2 สัญญาพิเศษจะถือว่า ว่าเครื่องคัดแยกได้เปิดเผยข้อมูล DA ตามความเป็นจริงแล้ว ซึ่งจริงๆ แล้วทำให้โหนด Celestia ทำหน้าที่เป็นผู้ค้ำประกันได้ เมื่อพิจารณาว่า Celestia มีโหนด Validator หลายร้อยโหนด เราจึงคิดว่า DAC ขนาดใหญ่นี้มีการกระจายอำนาจค่อนข้างมาก
จริงๆ แล้วโซลูชัน DA ที่ Merlin นำมาใช้นั้นค่อนข้างใกล้เคียงกับ BlobStream ของ Celestia ซึ่งทั้งสองอย่างนี้เปิดให้เข้าถึง DAC ผ่าน POS ทำให้มีการกระจายอำนาจมากขึ้น ใครก็ตามที่เดิมพันสินทรัพย์เพียงพอสามารถเรียกใช้โหนด DAC ได้ ในเอกสารของ Merlin โหนด DAC ที่กล่าวถึงข้างต้นเรียกว่า Oracle และระบุว่าจะสนับสนุนการจำนำสินทรัพย์ของ BTC, MERL และแม้แต่โทเค็น BRC-20 เพื่อใช้กลไกการจำนำที่ยืดหยุ่น และยังสนับสนุนคำมั่นสัญญาพร็อกซีที่คล้ายกับ Lido (ข้อตกลงจำนำ POS ของออราเคิลโดยพื้นฐานแล้วเป็นหนึ่งในเรื่องเล่าหลักถัดไปของ Merlin และอัตราดอกเบี้ยจำนำที่ให้ไว้นั้นค่อนข้างสูง)
เราจะอธิบายขั้นตอนการทำงานของ Merlin โดยย่อ (ภาพด้านล่าง):
หลังจากที่ซีเควนเซอร์ได้รับคำขอธุรกรรมจำนวนมาก มันจะรวมคำขอเหล่านั้นและสร้างชุดข้อมูล ซึ่งจะถูกส่งผ่านไปยังโหนด Prover และโหนด Oracle (DAC แบบกระจายอำนาจ)
โหนด Prover ของ Merlin มีการกระจายอำนาจและใช้ Prover ของ lumoz เป็นบริการ หลังจากได้รับข้อมูลหลายชุด กลุ่มการขุดของ Prover จะสร้างหลักฐานที่ไม่มีความรู้ที่เกี่ยวข้อง หลังจากนั้น ZKP จะถูกส่งไปยังโหนด Oracle เพื่อตรวจสอบ
โหนด Oracle จะตรวจสอบว่า ZK Proof ที่ส่งโดยพูลการขุด ZK ของ Lmuoz สอดคล้องกับชุดข้อมูลที่ส่งโดย Sequencer หรือไม่ หากทั้งสองรายการสามารถจับคู่ได้และไม่มีข้อผิดพลาดอื่นๆ การตรวจสอบจะผ่าน ในระหว่างกระบวนการนี้ โหนด Oracle ที่กระจายอำนาจจะสร้างลายเซ็นหลายรายการผ่านลายเซ็นตามเกณฑ์ และประกาศต่อโลกภายนอกว่าซีเควนเซอร์ได้ส่งข้อมูล DA ออกไปเรียบร้อยแล้ว และ ZKP ที่เกี่ยวข้องนั้นถูกต้องและผ่านการตรวจสอบโหนด Oracle แล้ว
ซีเควนเซอร์รวบรวมผลลัพธ์ที่มีลายเซ็นหลายรายการจากโหนด Oracle เมื่อจำนวนลายเซ็นตรงตามข้อกำหนดเกณฑ์ ข้อมูลลายเซ็นจะถูกส่งไปยังห่วงโซ่ Bitcoin พร้อมกับดาต้าแฮชของข้อมูล DA (ชุดข้อมูล) และจะถูกส่งต่อไปยังภายนอก โลกสำหรับการอ่านและการยืนยัน
โหนด Oracle ดำเนินการประมวลผลพิเศษในกระบวนการคำนวณในการตรวจสอบ ZK Proof สร้างข้อผูกพัน และส่งไปยังห่วงโซ่ Bitcoin ทำให้ใครก็ตามสามารถท้าทาย "ข้อผูกพัน" โดยพื้นฐานแล้ว กระบวนการในที่นี้เหมือนกับโปรโตคอลป้องกันการฉ้อโกงของ bitVM หากการท้าทายสำเร็จ โหนด Oracle ที่ออก Commitment จะถูกลงโทษทางการเงิน แน่นอนว่าข้อมูลที่ Oracle ต้องการเผยแพร่ไปยัง Bitcoin chain ยังรวมถึงแฮชของสถานะเลเยอร์ 2 ปัจจุบัน - StateRoot รวมถึง ZKP เองด้วย ซึ่งจะต้องเผยแพร่ไปยัง Bitcoin chain เพื่อการตรวจจับจากภายนอก
มีรายละเอียดหลายประการที่ต้องอธิบายอย่างละเอียด ประการแรกแผนงานของ Merlin ระบุว่า Oracle จะสำรองข้อมูล DA ไปยัง Celestia ในอนาคต ด้วยวิธีนี้ โหนดของ Oracle จึงสามารถกำจัดข้อมูลประวัติในเครื่องได้อย่างเหมาะสมโดยไม่จำเป็นต้องเก็บข้อมูลอยู่ ในท้องถิ่น ในเวลาเดียวกัน Commitment ที่สร้างโดย Oracle Network นั้นเป็นรากของ Merkle Tree จริงๆ การเปิดเผยรูทต่อโลกภายนอกนั้นไม่เพียงพอ แพลตฟอร์ม DA ของบุคคลที่สาม แพลตฟอร์มนี้อาจเป็น Celestia หรือ EigenDA หรือเลเยอร์ DA อื่นๆ
การวิเคราะห์โมเดลความปลอดภัย: บริการ MPC ของ ZKRolup+Cobo ในแง่ดี
ข้างต้นเราได้อธิบายขั้นตอนการทำงานของ Merlin ไว้โดยย่อแล้ว และฉันเชื่อว่าคุณได้เข้าใจโครงสร้างพื้นฐานของมันแล้ว ไม่ใช่เรื่องยากที่จะเห็นว่า Merlin, B^Square, BitLayer และ Citrea โดยพื้นฐานแล้วใช้รูปแบบการรักษาความปลอดภัยแบบเดียวกัน นั่นคือ ZK-Rollup ในแง่ดี
เมื่ออ่านคำนี้เป็นครั้งแรก ผู้ที่ชื่นชอบ Ethereum หลายคนอาจรู้สึกแปลก ๆ "ZK-Rollup ในแง่ดี" คืออะไร? ในความเข้าใจของชุมชน Ethereum “แบบจำลองเชิงทฤษฎี” ของ ZK Rollup นั้นขึ้นอยู่กับความน่าเชื่อถือของการคำนวณการเข้ารหัสอย่างสมบูรณ์ และไม่จำเป็นต้องมีการสันนิษฐานเกี่ยวกับความไว้วางใจ คำว่า การมองโลกในแง่ดี บ่งบอกถึงสมมติฐานของความไว้วางใจอย่างแม่นยำ ซึ่งหมายความว่าคนส่วนใหญ่ มองในแง่ดีว่า Rollup ไม่มีข้อผิดพลาดและเชื่อถือได้ เมื่อเกิดข้อผิดพลาด ผู้ดำเนินการ Rollup อาจถูกลงโทษผ่านการพิสูจน์การฉ้อโกง นี่คือที่มาของชื่อ Optimistic Rollup หรือที่เรียกว่า OP Rollup
สำหรับระบบนิเวศ Ethereum ที่ฐานของ Rollup การมองโลกในแง่ดีของ ZK-Rollup อาจดูไม่ชัดเจนนัก แต่ก็สอดคล้องกับสถานการณ์ปัจจุบันของ Bitcoin Layer 2 อย่างแน่นอน เนื่องจากข้อจำกัดทางเทคนิค Bitcoin chain ไม่สามารถตรวจสอบ ZK Proof ได้อย่างสมบูรณ์ และสามารถตรวจสอบได้เพียงบางขั้นตอนของกระบวนการคำนวณ ZKP ภายใต้สถานการณ์พิเศษเท่านั้น ภายใต้สมมติฐานนี้ Bitcoin chain สามารถรองรับได้เฉพาะโปรโตคอลป้องกันการฉ้อโกงเท่านั้น ชี้ให้เห็นว่ามีข้อผิดพลาดในขั้นตอนการคำนวณบางอย่างของ ZKP ในระหว่างกระบวนการตรวจสอบนอกเครือข่าย และถูกท้าทายผ่านการพิสูจน์การฉ้อโกง แน่นอนว่าสิ่งนี้ไม่สามารถเทียบได้กับ ZK Rollup ในรูปแบบ Ethereum แต่อยู่ใกล้แค่เอื้อมแล้ว ของ Bitcoin Layer 2 รูปแบบการรักษาความปลอดภัยที่เชื่อถือได้และปลอดภัยที่สุด
ภายใต้โครงการ ZK-Rollup ในแง่ดีข้างต้น สมมติว่ามีคน N คนในเครือข่ายเลเยอร์ 2 ที่มีอำนาจในการเริ่มการท้าทาย ตราบใดที่หนึ่งในผู้ท้าทาย N มีความซื่อสัตย์และเชื่อถือได้ สามารถตรวจพบข้อผิดพลาดได้ และเริ่มต้นการพิสูจน์การฉ้อโกงที่ การเปลี่ยนสถานะของเลเยอร์ 2 นั้นปลอดภัย แน่นอนว่า Optimistic Rollup ซึ่งมีระดับความสมบูรณ์ค่อนข้างสูง จำเป็นต้องตรวจสอบให้แน่ใจว่าสะพานการถอนเงินนั้นได้รับการคุ้มครองโดยโปรโตคอลป้องกันการฉ้อโกง อย่างไรก็ตาม ปัจจุบัน Bitcoin Layer 2 เกือบทั้งหมดไม่สามารถบรรลุสมมติฐานนี้ได้และจำเป็นต้องพึ่งพา multi- Signature/MPC แล้วจะเลือกได้อย่างไร โซลูชัน Multi-Signature/MPC กลายเป็นปัญหาที่เกี่ยวข้องอย่างใกล้ชิดกับความปลอดภัยของเลเยอร์ 2
Merlin เลือกบริการ MPC ของ Cobo สำหรับโซลูชันการเชื่อมโยง โดยใช้มาตรการต่างๆ เช่น การแยกกระเป๋าเงินร้อนและเย็น สินทรัพย์ในการเชื่อมโยงได้รับการจัดการร่วมกันโดย Cobo และ Merlin Chain พฤติกรรมการถอนเงินใดๆ จะต้องได้รับการจัดการร่วมกันโดยผู้เข้าร่วม MPC ของ Cobo และ Merlin Chain ซึ่งโดยพื้นฐานแล้วผ่านการอนุมัติสินเชื่อของสถาบันทำให้มั่นใจในความน่าเชื่อถือของสะพานการถอน แน่นอนว่านี่เป็นเพียงมาตรการชั่วคราวในขั้นตอนนี้ เมื่อโครงการค่อยๆ ดีขึ้น สะพานการถอนจะถูกแทนที่ด้วย "สะพานในแง่ดี" ด้วยสมมติฐานความน่าเชื่อถือ 1/N โดยการแนะนำ BitVM และโปรโตคอลป้องกันการฉ้อโกง การดำเนินการนี้จะยากขึ้น ขนาดใหญ่ (ปัจจุบันบริดจ์เลเยอร์ 2 อย่างเป็นทางการเกือบทั้งหมดต้องใช้ลายเซ็นหลายลายเซ็น)
โดยรวมแล้ว เราสามารถแยกแยะได้ว่า Merlin ได้แนะนำ DAC ที่ใช้ POS, ZK-Rollup ในแง่ดีที่ใช้ BitVM และการดูแลสินทรัพย์ MPC ที่ใช้ Cobo เพื่อแก้ไขปัญหา DA โดยการเปิดสิทธิ์ DAC โดยแนะนำ BitVM และโปรโตคอลป้องกันการฉ้อโกง Sure ความปลอดภัยของการเปลี่ยนสถานะ มั่นใจในความน่าเชื่อถือของสะพานถอนเงินโดยการแนะนำบริการ MPC ของแพลตฟอร์มการดูแลทรัพย์สินที่มีชื่อเสียง Cobo
โซลูชันการส่งการยืนยัน ZKP แบบสองขั้นตอนที่อิงจาก Lumoz
ก่อนหน้านี้ เราได้แยกแยะโมเดลความปลอดภัยของ Merlin และแนะนำแนวคิดของการรวม ZK ในแง่ดี ในแผนงานด้านเทคโนโลยีของ Merlin มีการพูดถึง Prover แบบกระจายอำนาจด้วย ดังที่เราทุกคนทราบกันดีว่า Prover มีบทบาทสำคัญในสถาปัตยกรรม ZK-Rollup โดยมีหน้าที่สร้าง ZKProof สำหรับแบทช์ที่เผยแพร่โดย Sequencer อย่างไรก็ตาม กระบวนการสร้างการพิสูจน์ความรู้เป็นศูนย์นั้นใช้ทรัพยากรฮาร์ดแวร์อย่างมาก ปัญหายุ่งยาก
เพื่อ เร่งการสร้าง ZK proofs การทำงานแบบขนานและการแบ่งงานถือเป็นการดำเนินการขั้นพื้นฐาน ที่สุด จริงๆ แล้วสิ่งที่เรียกว่าการทำให้เป็นคู่ขนานหมายถึงการแบ่งงานสร้างการพิสูจน์ ZK ออกเป็นส่วนต่างๆ ซึ่งเสร็จสมบูรณ์โดย Prover ที่ต่างกัน ตามลำดับ สุดท้าย ผู้รวบรวมจะรวมการพิสูจน์หลายรายการไว้เป็นทั้งหมด
เพื่อเร่งกระบวนการสร้างหลักฐาน ZK Merlin จะใช้ Prover ของ Lumoz เป็นโซลูชันบริการ ซึ่งจริงๆ แล้วเป็นการรวบรวมอุปกรณ์ฮาร์ดแวร์จำนวนมากมารวมกันเพื่อสร้างกลุ่มการขุด จากนั้นจึงจัดสรรงานการประมวลผลให้กับอุปกรณ์ต่างๆ และจัดสรร สิ่งจูงใจที่เกี่ยวข้องนั้นค่อนข้างคล้ายกับการขุด POW
ในโซลูชัน Prover แบบกระจายอำนาจนี้ มีสถานการณ์การโจมตีประเภทหนึ่ง หรือที่เรียกกันทั่วไปว่าเป็นการโจมตีแบบรุกหน้า: สมมติว่าผู้รวบรวมซึ่งก็คือผู้รวบรวมได้ก่อตั้ง ZKP ขึ้นมา และส่ง ZKP ออกไปด้วยความหวังว่าจะได้รับรางวัล หลังจากที่ผู้รวบรวมรายอื่นเห็นเนื้อหาของ ZKP พวกเขาก็เผยแพร่เนื้อหาเดียวกันต่อหน้าเขา โดยอ้างว่าเขาสร้าง ZKP ก่อน จะแก้ไขสถานการณ์นี้อย่างไร
บางทีวิธีแก้ปัญหาตามสัญชาตญาณที่สุดที่ทุกคนนึกถึงคือการกำหนดหมายเลขงานที่กำหนดให้กับผู้รวบรวมแต่ละราย ตัวอย่างเช่น เฉพาะผู้รวบรวม A เท่านั้นที่สามารถรับภารกิจที่ 1 ได้ และคนอื่นๆ จะไม่ได้รับรางวัลแม้ว่าพวกเขาจะทำภารกิจที่ 1 สำเร็จก็ตาม แต่แนวทางนี้มีปัญหาคือไม่สามารถต้านทานความเสี่ยงจุดเดียวได้ หาก Aggregator A เกิดความล้มเหลวด้านประสิทธิภาพหรือถูกตัดการเชื่อมต่อ งานที่ 1 จะค้างและไม่สามารถดำเนินการให้เสร็จสิ้นได้ นอกจากนี้ วิธีการจัดสรรงานให้กับหน่วยงานเดียวนี้ไม่สามารถปรับปรุงประสิทธิภาพการผลิตผ่านกลไกแรงจูงใจในการแข่งขันได้ และไม่ใช่แนวทางที่ดี
Polygon zkEVM เคยเสนอวิธีการที่เรียกว่า Proof of Efficiency ในบล็อก ซึ่งชี้ให้เห็นว่าควรใช้วิธีการแข่งขันเพื่อส่งเสริมการแข่งขันระหว่างผู้รวบรวมต่างๆ และสิ่งจูงใจควรได้รับการจัดสรรตามลำดับก่อนหลัง อันดับแรก -สามารถรับรางวัล Proof ได้จากการส่ง Aggregator ไปที่ chain แน่นอนว่าเขาไม่ได้พูดถึงวิธีแก้ปัญหา MEV front-running
Lumoz ใช้วิธีการส่งหลักฐาน ZK สำหรับการยืนยันแบบสองขั้นตอน หลังจากที่ Aggregator สร้างหลักฐาน ZK แล้ว ก็ไม่จำเป็นต้องส่งเนื้อหาทั้งหมดออกไปก่อน แต่จะเผยแพร่เฉพาะแฮช ZKP หรืออีกนัยหนึ่งคือเผยแพร่แฮช (ZKP+Aggregator ที่อยู่). ด้วยวิธีนี้ แม้ว่าผู้อื่นจะเห็นค่าแฮช แต่พวกเขาก็ไม่ทราบเนื้อหา ZKP ที่เกี่ยวข้อง และไม่สามารถข้ามไปข้างหน้าได้โดยตรง
หากมีคนคัดลอกแฮชทั้งหมดและเผยแพร่ก่อน ก็ไม่มีประโยชน์ เนื่องจากแฮชนั้นมีที่อยู่ของผู้รวบรวม X ที่เฉพาะเจาะจง แม้ว่าผู้รวบรวม A จะเผยแพร่แฮชก่อน เมื่อภาพต้นฉบับของแฮชถูกเปิดเผย ทุกคนจะ ดูว่าที่อยู่ของผู้รวบรวมที่อยู่ในนั้นคือ X's ไม่ใช่ A's
ด้วยแผนการส่ง ZKP สำหรับการยืนยันสองขั้นตอนนี้ Merlin (Lumoz) สามารถแก้ไขปัญหาที่เกิดขึ้นในกระบวนการส่ง ZKP ได้ ดังนั้นจึงบรรลุสิ่งจูงใจในการสร้างการพิสูจน์ความรู้เป็นศูนย์ที่มีการแข่งขันสูง ซึ่งจะเป็นการเพิ่มความเร็วของการสร้าง ZKP
Phantom ของ Merlin: การทำงานร่วมกันแบบหลายสายโซ่
ตามแผนงานทางเทคนิคของ Merlin พวกเขาจะสนับสนุนการทำงานร่วมกันระหว่าง Merlin และ EVM chain อื่นๆ โดยพื้นฐานแล้วเส้นทางการใช้งานจะเหมือนกับแนวคิด Zetachain ก่อนหน้านี้ หาก Merlin ถูกใช้เป็น Source Chain และใช้ EVM Chain อื่นๆ เป็น Target Chain เมื่อ Merlin หลังจากที่โหนดตรวจพบคำขอการดำเนินงานข้ามสายโซ่ที่ออกโดยผู้ใช้ มันจะทริกเกอร์เวิร์กโฟลว์ที่ตามมาบนห่วงโซ่เป้าหมาย
ตัวอย่างเช่น บัญชี EOA ที่ควบคุมโดยเครือข่าย Merlin สามารถใช้งานบน Polygon ได้ เมื่อผู้ใช้ออกคำสั่งการทำงานร่วมกันแบบข้ามสายโซ่บน Merlin Chain เครือข่าย Merlin จะแยกวิเคราะห์เนื้อหาก่อน และสร้างข้อมูลธุรกรรมที่จะดำเนินการกับเป้าหมาย chain จากนั้น Oracle Network จะดำเนินการประมวลผลลายเซ็น MPC ในธุรกรรม และสร้างลายเซ็นดิจิทัลของธุรกรรม หลังจากนั้น โหนด Relayer ของ Merlin จะเผยแพร่ธุรกรรมบน Polygon และดำเนินการต่อมาให้เสร็จสิ้นผ่านทรัพย์สินของ Merlin ในบัญชี EOA บนเครือข่ายเป้าหมาย
เมื่อการดำเนินการที่ผู้ใช้ร้องขอเสร็จสิ้น สินทรัพย์ที่เกี่ยวข้องจะถูกส่งต่อโดยตรงไปยังที่อยู่ของผู้ใช้บนห่วงโซ่เป้าหมาย ในทางทฤษฎี สินทรัพย์ดังกล่าวสามารถถ่ายโอนโดยตรงไปยัง Merlin Chain ได้ โซลูชันนี้มีประโยชน์ที่ชัดเจนบางประการ: สามารถหลีกเลี่ยงค่าธรรมเนียมการจัดการและการสึกหรอที่เกิดจากสัญญาสะพานข้ามสายโซ่ เมื่อสินทรัพย์แบบเดิมข้ามสายโซ่ และความปลอดภัยของการดำเนินงานข้ามสายโซ่ได้รับการรับประกันโดยตรงจาก Oracle Network ของ Merlin และมี ไม่จำเป็นต้องพึ่งพาโครงสร้างพื้นฐานภายนอก ตราบใดที่ผู้ใช้ไว้วางใจ Merlin Chain พฤติกรรมการทำงานร่วมกันแบบข้ามสายโซ่ดังกล่าวก็ถือว่าไม่มีปัญหา
สรุป
ในบทความนี้ เราจะอธิบายโดยย่อเกี่ยวกับโซลูชันทางเทคนิคทั่วไปของ Merlin Chain ซึ่งเราเชื่อว่าสามารถช่วยให้ผู้คนเข้าใจขั้นตอนการทำงานทั่วไปของ Merlin ได้มากขึ้น และมีความเข้าใจที่ชัดเจนยิ่งขึ้นเกี่ยวกับโมเดลความปลอดภัยของ Merlin Chain เมื่อพิจารณาว่าระบบนิเวศของ Bitcoin ในปัจจุบันเต็มไปด้วยความผันผวน เราเชื่อว่าการทำให้วิทยาศาสตร์ทางเทคนิคเป็นที่นิยมนั้นมีคุณค่าและเป็นที่ต้องการของสาธารณชนทั่วไป เราจะดำเนินการติดตามผลระยะยาวในโครงการต่างๆ เช่น Merlin, bitLayer และ B^Square ในอนาคต เราจะให้การวิเคราะห์เชิงลึกเพิ่มเติมเกี่ยวกับโซลูชันทางเทคนิค ดังนั้นโปรดคอยติดตาม!
