*ส่งต่อชื่อดั้งเดิม：สำรวจ Canonical Ethereum Bridge และระบบพิสูจน์ของ Eclipse

ภาพรวมของ Canonical Bridge ของเรา

Eclipse ประกอบด้วยสามชั้น:

1. การดำเนินการ: ทางแยกของไคลเอ็นต์ Solana Labs (v1.17) สำหรับการดำเนินการธุรกรรม SVM
2. ข้อตกลง: Canonical Bridge ของเราซึ่งกำหนดกฎ fork-choice ของ Eclipse มีอยู่บน Ethereum ซึ่งจะมีการส่งหลักฐานการฉ้อโกงด้วย
3. ความพร้อมใช้งานของข้อมูล: Eclipse เผยแพร่ข้อมูลที่จำเป็นในการสร้างหลักฐานการฉ้อโกงเป็นข้อมูลหยดบน Celestia

แผนภาพด้านล่างแสดงให้เห็นว่าโมดูลเหล่านี้โต้ตอบกันอย่างไร:

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

1. เงินจะถูกฝากผ่านสะพานของเรา
2. data blobs ของแบตช์ของบล็อกของ Eclipse ถูกโพสต์บน Celestia
3. มีการจัดการการถอนเงินผ่านสะพานและ
4. หลักฐานการฉ้อโกงจะถูกสร้างขึ้นในสถานการณ์ที่เลวร้ายที่สุด

การฝากเงินผ่าน Native Ethereum Bridge ของ Eclipse

ขั้นตอนเมื่อผู้ใช้ฝากเข้าสู่ Eclipse ผ่านทาง Ethereum Bridge ดั้งเดิมสรุปได้ดังนี้:

1. ผู้ใช้เรียก สัญญา Deposit Bridge ของ Eclipse บน Ethereum
2. จากภายในตัวดำเนินการ SVM ของ Eclipse [1] ตัวส่งต่อ [2] จะสังเกตเงินฝากและที่อยู่ปลายทางของผู้ใช้
3. จากนั้นผู้ส่งต่อจะเรียกโปรแกรมบริดจ์ SVM ซึ่งมีหน้าที่รับผิดชอบในการโอนเงินฝากของผู้ใช้ไปยังที่อยู่ปลายทางที่เกี่ยวข้อง
4. ผู้ส่งต่อตรวจสอบธุรกรรมการฝากเงินผ่านไคลเอนต์ zk-light (ที่จะนำไปใช้)
5. ในที่สุด บล็อกที่มีธุรกรรมการโอนเงินภายหลังการฝากเงินที่ตามมาจะได้รับการสรุปและเผยแพร่ผ่าน ปลั๊กอิน Solana Geyser

แผนภาพด้านล่างแสดงปฏิสัมพันธ์ระหว่าง Ethereum, Celestia และ SVM Executor ในระหว่างขั้นตอนการฝากเงินที่อธิบายไว้ข้างต้น:

การเผยแพร่สล็อตของ Eclipse ไปยัง Celestia ในรูปแบบ Data Blobs

โฟลว์สำหรับการเผยแพร่แบทช์ของสล็อตของ Eclipse ไปยัง Celestia เนื่องจาก data blobs สรุปไว้ด้านล่าง:

1. ตัวดำเนินการ SVM จะเผยแพร่แต่ละช่อง Eclipse ไปยังคิวข้อความผ่าน Geyser
2. ตัวดำเนินการ SVM โพสต์แบตช์ของสล็อตของ Eclipse ไปยัง Celestia เป็น data blobs
3. ชุดเครื่องมือตรวจสอบ Celestia จะสร้าง ข้อผูกพัน กับ data blobs ที่ส่งมา ซึ่งสามารถใช้เพื่อพิสูจน์การรวมธุรกรรมบนห่วงโซ่ของ Eclipse กับรูทข้อมูล
4. รากข้อมูลที่อยู่ในส่วนหัวของบล็อก Celestia ทุกอันจะถูกส่งต่อไปยังสัญญาบริดจ์ของ Eclipse บน Ethereum ผ่านทาง Blobstream

แผนภาพด้านล่างจาก Celestia อธิบายว่าความมุ่งมั่นของข้อมูลภายในบล็อก Celestia ที่กำหนดถูกจัดเก็บไว้ในส่วนหัวของบล็อกอย่างไร:

การถอนและส่งหลักฐานการฉ้อโกงไปยัง Ethereum Bridge ของ Eclipse

เช่นเดียวกับ L2 อื่นๆ ที่ใช้หลักฐานการฉ้อโกง (Arbitrum, Fuel และอื่นๆ อีกมากมาย) การถอนออกจาก Eclipse ต้องใช้ระยะเวลาที่ท้าทาย ซึ่งผู้ตรวจสอบสามารถส่งหลักฐานการฉ้อโกงได้ในกรณีของการเปลี่ยนสถานะที่ไม่ถูกต้อง:

1. ในจังหวะปกติ ผู้ดำเนินการ SVM จะโพสต์ความมุ่งมั่นในยุค (จำนวนชุดที่กำหนดไว้ล่วงหน้า) ของสล็อตของ Eclipse ไปยัง Ethereum พร้อมด้วยหลักประกัน
2. สัญญาบริดจ์ของ Eclipse ดำเนินการตรวจสอบขั้นพื้นฐานเพื่อให้แน่ใจว่าข้อมูลที่โพสต์มีรูปแบบที่ดี (อธิบายไว้ในส่วนการออกแบบป้องกันการฉ้อโกง)
3. หากแบทช์ที่ส่งผ่านการตรวจสอบพื้นฐานเหล่านี้ จะมีหน้าต่างที่กำหนดไว้ล่วงหน้าซึ่งในระหว่างนั้นผู้ตรวจสอบสามารถโพสต์หลักฐานการฉ้อโกงได้ ในกรณีที่ข้อผูกมัดของแบทช์บ่งบอกถึงการเปลี่ยนแปลงสถานะที่ไม่ถูกต้อง
4. หากผู้ตรวจสอบโพสต์หลักฐานการฉ้อโกงที่ประสบความสำเร็จ พวกเขาจะชนะหลักประกันของผู้ดำเนินการ แบตช์ที่โพสต์จะถูกปฏิเสธ และสถานะมาตรฐานของ Eclipse L2 จะถูกย้อนกลับไปยังข้อผูกพันแบตช์ที่ถูกต้องล่าสุด ที่นี่ การกำกับดูแลของ Eclipse จะมีความสามารถในการเลือกผู้ดำเนินการคนใหม่
5. หากระยะเวลาท้าทายผ่านไปโดยไม่มีหลักฐานการฉ้อโกงที่ประสบความสำเร็จ ผู้ดำเนินการจะกู้คืนหลักประกันพร้อมกับรางวัล
6. ด้วยเหตุนี้ สัญญาบริดจ์ Eclipse จะดำเนินการธุรกรรมการถอนใดๆ ที่รวมอยู่ในแบตช์ที่สรุปผลให้เสร็จสิ้น

การออกแบบป้องกันการฉ้อโกง

ในส่วนสุดท้ายนี้ เราจะให้รายละเอียดเกี่ยวกับการออกแบบระบบป้องกันการฉ้อโกงของ Eclipse ซึ่งได้รับแรงบันดาลใจจาก Anatoly Yakovenko และ John Adler โดยทั่วไป สำหรับการพิสูจน์การฉ้อโกง ผู้ตรวจสอบจะต้อง:

1. ระบุธุรกรรมที่มีการเปลี่ยนสถานะที่ไม่ถูกต้อง
2. ระบุอินพุตสำหรับธุรกรรมดังกล่าวด้วยการเปลี่ยนสถานะที่ไม่ถูกต้อง
3. แสดงให้เห็นว่าการดำเนินการธุรกรรมดังกล่าวอีกครั้งด้วยอินพุตที่กำหนดส่งผลให้เอาต์พุตไม่เท่ากับสิ่งที่กระทำบนเชน

ในกรณีของ Eclipse (1) Celestia รวบรวมกลุ่มของบล็อกที่ผู้ดำเนินการ SVM ของ Eclipse โพสต์ เพื่อให้สามารถพิสูจน์การรวมธุรกรรมผ่านพยานของ Merkle สำหรับ (2) ซึ่งแตกต่างจาก L2 ที่ใช้ EVM ซึ่งโพสต์ Merkle root ไปยังแผนผังสถานะส่วนกลาง ด้วยเหตุผลด้านประสิทธิภาพ Eclipse จะไม่อัปเดตแผนผังสถานะส่วนกลางแบบทีละธุรกรรม แต่เราจะอธิบายว่าเรามั่นใจได้อย่างไร ความถูกต้องของอินพุตโดยละเอียดเพิ่มเติมด้านล่าง สุดท้าย ในกรณีของ (3) ตัวตรวจสอบของ Eclipse จะสร้าง zk-proof ของเอาต์พุตสำหรับธุรกรรมที่กำหนด ซึ่งแตกต่างจาก แนวทางเกมการตรวจสอบเชิงโต้ตอบ ที่ใช้กันทั่วไปใน L2 ที่ใช้ EVM

ธุรกรรม Eclipse ทั้งหมดสามารถแสดงเป็นรายการบัญชีอินพุต ดำเนินธุรกรรม และสร้างรายการบัญชีเอาต์พุตที่เป็นผลลัพธ์:

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

ข้อมูลธุรกรรมที่โพสต์ไปยัง Celestia

1. ข้อมูลธุรกรรม (โพสต์โดยซีเควนเซอร์)
2. ข้อมูลธุรกรรม (โพสต์โดยผู้ดำเนินการ SVM) ซึ่งมีดังต่อไปนี้:
   1. จำนวนธุรกรรม [3]
   2. ตำแหน่งเนมสเปซ Celestia ของข้อมูลธุรกรรม
   3. แฮชของบัญชี [4] สำหรับแต่ละอินพุต โดยมีจำนวนธุรกรรมที่เกิดขึ้นในแต่ละรายการ
   4. รายการ sysvars ที่ใช้และมูลค่าของแต่ละรายการ โดยมีจำนวนธุรกรรมส่งผลให้แต่ละรายการ (ถ้ามี) [5]
   5. เอาท์พุตธุรกรรม หากธุรกรรมสำเร็จ มิฉะนั้น ตัวบ่งชี้ว่าธุรกรรมล้มเหลว (เนื่องจากไม่สามารถแยกวิเคราะห์หรือเนื่องจากไม่สามารถดำเนินการได้)

ภาระผูกพันแบบแบตช์ที่โพสต์ไปยัง Ethereum Bridge

นอกจากนี้ ชุดข้อมูลธุรกรรมที่โพสต์ไปยัง Celestia ยังมีข้อผูกพันที่ถ่ายทอดไปยังสัญญา Ethereum ข้อผูกพันประกอบด้วย:

1. ตำแหน่งเนมสเปซ Celestia ของข้อมูลธุรกรรมของธุรกรรมล่าสุดที่รวมอยู่ในแบทช์
2. ตำแหน่งเนมสเปซ Celestia ของข้อมูลการดำเนินการ [6] ของธุรกรรมที่รวมไว้ทั้งหมด
3. รายการการฝาก การถอน และการแทนที่ ซึ่งแต่ละรายการมาพร้อมกับจำนวนธุรกรรมของธุรกรรม Eclipse ที่เกี่ยวข้อง

เกณฑ์สำหรับชุดที่ไม่ถูกต้อง

ตามที่อธิบายไว้ข้างต้น มีหลายวิธีที่จะพบว่าแบทช์ไม่ถูกต้อง:

1. ตำแหน่งเนมสเปซ Celestia ที่เชื่อมโยงรายการใดรายการหนึ่งมีรูปแบบไม่ถูกต้องหรือไม่ได้ชี้ไปยังข้อมูลประเภทที่ต้องการ
2. มีธุรกรรมบน Celestia ที่ไม่มีข้อมูลการดำเนินการที่เกี่ยวข้อง ซึ่งอาจเกิดจากสาเหตุสองประการ:
   1. ธุรกรรมซึ่งควรจะเป็นรายการล่าสุดในชุด ไม่มีข้อมูลการดำเนินการที่เกี่ยวข้อง
      1. ในกรณีเช่นนี้ ผู้ตรวจสอบจะตรวจสอบว่าเป็นกรณีนี้ และสัญญาสะพาน Ethereum จะตรวจสอบว่ารายการล่าสุดในรายการข้อมูลการดำเนินการไม่สอดคล้องกับข้อมูลธุรกรรมที่ถูกต้อง
   2. ข้อมูลการดำเนินการของธุรกรรมอื่นหายไป
      1. ผู้ตรวจสอบจะโพสต์ตำแหน่งเนมสเปซ Celestia ของข้อมูลธุรกรรมของธุรกรรมที่ละเมิดและธุรกรรมก่อนหน้าและต่อไปนี้ตามลำดับที่ดำเนินการสำเร็จ ต่อไปนี้ สัญญาบริดจ์จะตรวจสอบว่าธุรกรรมนี้ถูกข้ามไป
3. มีธุรกรรมที่มีข้อมูลการดำเนินการไม่ถูกต้อง ซึ่งอาจเกิดจากสาเหตุต่อไปนี้:
   1. จำนวนธุรกรรมที่เกี่ยวข้องกับแฮชของบัญชีหรือ sysvar ไม่ได้สร้างผลลัพธ์ที่อ้างสิทธิ์
      1. ในกรณีนี้ ผู้ตรวจสอบจะโพสต์ตำแหน่งเนมสเปซ Celestia ของข้อมูลการดำเนินการสำหรับธุรกรรมที่กำหนดพร้อมกับจำนวนที่สอดคล้องกัน และสัญญาบริดจ์จะตรวจสอบว่าค่าที่กำหนดไม่ถูกต้อง
   2. จำนวนธุรกรรมที่เกี่ยวข้องกับแฮชของบัญชีหรือ sysvar ล้าสมัย
      1. ผู้ตรวจสอบจะโพสต์ตำแหน่งเนมสเปซ Celestia ของข้อมูลการดำเนินการสำหรับธุรกรรมที่ใหม่กว่า การแก้ไขค่าที่ต้องการ และสัญญาบริดจ์จะตรวจสอบว่าสิ่งนี้ใหม่กว่าจริง ๆ
   3. ผลลัพธ์ของธุรกรรมไม่ถูกต้อง หรือธุรกรรมใช้อินพุตที่ไม่อยู่ในรายการ:
      1. ในกรณีนี้ จำเป็นต้องมีหลักฐาน zk ของการดำเนินการที่ถูกต้องของธุรกรรม หรือการพิสูจน์ zk ว่าธุรกรรมใช้อินพุตที่ไม่อยู่ในรายการเป็นสิ่งจำเป็น สามารถรับได้สองวิธี:
         1. ผู้ตรวจสอบจะโพสต์หลักฐานหรือ
         2. ผู้ตรวจสอบจะโพสต์ดัชนีของธุรกรรมที่อ้างว่าเป็นการฉ้อโกง และสัญญาสะพาน Eclipse ใช้สิ่งนี้เพื่อขอหลักฐาน zk จาก Bonsai ของ RISC Zero
   4. มีการฝากเงินจาก Ethereum มากกว่า N แบตช์ที่แล้ว แต่ไม่มีเงินฝากที่เกี่ยวข้องในรายการธุรกรรม (รวมอยู่ในข้อผูกพันของแบตช์ที่โพสต์ในสัญญาบริดจ์) สำหรับแบตช์ N ที่ผ่านมา อีกทางหนึ่ง มีการฝากเงินในรายการธุรกรรมที่ไม่มีธุรกรรมการฝาก Ethereum ที่เกี่ยวข้อง หรือมีธุรกรรมอยู่แต่ได้รวมอยู่ในชุด Eclipse อื่นแล้ว
      1. สัญญาบริดจ์ในทุกกรณีสามารถระบุได้ว่าสิ่งนี้เกิดขึ้นและถือว่าชุดงานดังกล่าวไม่ถูกต้อง
   5. มีการฝากหรือถอนเงินโดยไม่มีรายการที่สอดคล้องกันในรายการธุรกรรม
      1. ในกรณีเช่นนี้ ผู้ตรวจสอบจะโพสต์ตำแหน่งเนมสเปซ Celestia ของข้อมูลการดำเนินการที่กำหนด และสัญญาบริดจ์จะตรวจสอบข้อเท็จจริงนี้เพื่อตัดสินว่าธุรกรรมนั้นไม่ถูกต้อง
   6. มีการฝากหรือถอนในรายการธุรกรรมที่มีธุรกรรม Eclipse ที่เกี่ยวข้องไม่ดำเนินการตามที่คาดไว้ หรือจำนวนธุรกรรมไม่อยู่ในช่วงการนับธุรกรรมที่คาดไว้ ในกรณีเช่นนี้ อาจเกิดเหตุการณ์อย่างใดอย่างหนึ่งต่อไปนี้:
      1. บริดจ์จะตัดสินว่าเป็นกรณีนี้โดยอัตโนมัติและปฏิเสธแบทช์ที่เกี่ยวข้อง
      2. ผู้ตรวจสอบจะสังเกตเห็นการเปลี่ยนแปลงสถานะที่ไม่ถูกต้องและโพสต์หลักฐานการทำธุรกรรมที่ละเมิด ซึ่งจากนั้นจะได้รับการตรวจสอบโดยสัญญาบริดจ์

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

ความคิดที่พรากจากกัน

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

หากต้องการมีส่วนร่วมกับ Eclipse Testnet โปรดปฏิบัติตามคำแนะนำของเรา ที่นี่ คุณสามารถติดต่อเราได้ทาง Twitter หรือ Discord หากมีคำถามเฉพาะเกี่ยวกับ Testnet, Bridge หรือคำถามด้านเทคนิค

เชิงอรรถ

[1]: โหนดที่คำนวณผลลัพธ์ของธุรกรรม SVM และใช้เอาต์พุตสุดท้ายกับสถานะใหม่ของ Eclipse

[2]: ตัวดำเนินการที่ส่งผ่านเหตุการณ์ออนไลน์ระหว่าง Ethereum และ Eclipse

[3]: โปรดทราบว่าผู้ดำเนินการ ไม่ใช่ซีเควนเซอร์ โพสต์สิ่งนี้ หากรวมอยู่ในข้อมูลที่โพสต์โดยซีเควนเซอร์ มันจะเพิ่มความยุ่งยากที่ซีเควนเซอร์สามารถข้ามไปนับได้ ทำให้เป็นไปไม่ได้ที่ผู้ดำเนินการจะทำงานได้อย่างถูกต้อง สิ่งนี้สามารถชดเชยได้ในการออกแบบที่ป้องกันการฉ้อโกง แต่จะเพิ่มความซับซ้อนเป็นพิเศษ ข้อได้เปรียบประการที่สองของการมีเพียงผู้ดำเนินการที่โพสต์การนับคือ ช่วยให้สามารถโพสต์การแทนที่ธุรกรรมไปยัง Celestia ได้อย่างง่ายดาย หากต้องการ

[4]: บัญชี SVM สามารถแสดงด้วยแฮชที่ไม่ซ้ำใคร วิธีเดียวที่จะแก้ไขแฮชนี้คือผ่านธุรกรรม

[5]: เพื่อดำเนินการนี้โดยไม่ต้องมีการแฮชมากเกินไป เราจะเรียกใช้การติดตามในแต่ละโปรแกรมที่ดำเนินการเพื่อดูว่าส่วนใดของ sysvar ที่ใช้แต่ละอันที่เข้าถึงได้จริง สิ่งนี้เป็นไปได้ แต่จะต้องมีการแก้ไขล่าม BPF ของ Solana

[6]: รวมถึงข้อมูลสำหรับธุรกรรมที่พยายามดำเนินการซึ่งล้มเหลวในการดำเนินการ

ข้อสงวนสิทธิ์：

1. บทความนี้พิมพ์ซ้ำจาก [[กระจกเงา] ลิขสิทธิ์ทั้งหมดเป็นของผู้แต่งต้นฉบับ [Eclipse] หากมีการคัดค้านการพิมพ์ซ้ำนี้ โปรดติดต่อทีมงาน Gate Learn แล้วพวกเขาจะจัดการโดยเร็วที่สุด
2. การปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่ถือเป็นคำแนะนำในการลงทุนใดๆ
3. การแปลบทความเป็นภาษาอื่นดำเนินการโดยทีมงาน Gate Learn เว้นแต่จะกล่าวถึง ห้ามคัดลอก แจกจ่าย หรือลอกเลียนแบบบทความที่แปลแล้ว