โครงสร้างส่วนประกอบของอนุญาโตตุลาการ ตีความโดยอดีตเอกอัครราชทูตด้านเทคนิคอนุญาโตตุลาการ (ตอนที่ 2)

ในบทความก่อนหน้านี้ “โครงสร้างส่วนประกอบของ Arbitrum ตีความโดยอดีตทูตด้านเทคนิคของ Arbitrum (ตอนที่ 1)” เราได้แนะนำบทบาทของส่วนประกอบสำคัญใน Arbitrum รวมถึงซีเควนเซอร์, เครื่องมือตรวจสอบ, สัญญากล่องจดหมายของซีเควนเซอร์, Rollup Block และบทบาทของ หลักฐานการฉ้อโกงแบบไม่โต้ตอบ ในบทความวันนี้ เราจะเน้นไปที่การอธิบายองค์ประกอบที่เกี่ยวข้องกับการส่งข้อความข้ามสายโซ่ และการเข้าสู่ธุรกรรมต่อต้านการเซ็นเซอร์ในองค์ประกอบหลักของ Arbitrum

ข้อความหลัก: ในบทความก่อนหน้านี้ เราได้กล่าวถึงสัญญา Sequencer Inbox ได้รับการออกแบบมาโดยเฉพาะเพื่อรับชุดข้อมูลธุรกรรมที่เผยแพร่โดยซีเควนเซอร์ในเลเยอร์ 1 ในเวลาเดียวกัน เราชี้ให้เห็นว่า Sequencer Inbox เรียกอีกอย่างว่า "fast box" และในทางตรงกันข้าม มี "slow box" หรือ Delayed Inbox (เรียกว่า Inbox) ด้านล่างนี้ เราจะให้การตีความโดยละเอียดขององค์ประกอบที่เกี่ยวข้องกับการส่งข้อความข้ามสายโซ่ รวมถึงกล่องขาเข้าที่ล่าช้า

หลักการของ cross-chain และการเชื่อมโยง

ธุรกรรมข้ามสายโซ่สามารถแบ่งออกเป็นธุรกรรมจาก L1 ถึง L2 (เงินฝาก) และธุรกรรมจาก L2 ถึง L1 (ถอนออก) สิ่งสำคัญที่ควรทราบคือคำว่า "การฝากเงิน" และ "การถอนเงิน" ในที่นี้อาจไม่จำเป็นต้องเกี่ยวข้องกับการโอนสินทรัพย์แบบข้ามสายโซ่ พวกเขาสามารถอ้างถึงการส่งข้อความโดยไม่ต้องโอนทรัพย์สินโดยตรง ดังนั้นข้อกำหนดเหล่านี้จึงเป็นเพียงการแสดงสองทิศทางของการดำเนินการที่เกี่ยวข้องกับ cross-chain เท่านั้น

เมื่อเปรียบเทียบกับธุรกรรม L2 เพียงอย่างเดียว ธุรกรรมข้ามสายโซ่เกี่ยวข้องกับการแลกเปลี่ยนข้อมูลระหว่างสองระบบที่แตกต่างกัน L1 และ L2 ทำให้กระบวนการซับซ้อนมากขึ้น

นอกจากนี้ เมื่อเราพูดถึงการดำเนินการแบบ cross-chain มันมักจะหมายถึงการข้ามระหว่างเครือข่ายสองเครือข่ายที่ไม่เกี่ยวข้องกันโดยสิ้นเชิงโดยใช้สะพานข้ามสายโซ่ในโมเดลแบบรวมศูนย์ ความปลอดภัยของการดำเนินการข้ามสายโซ่ดังกล่าวขึ้นอยู่กับผู้ดำเนินการของสะพานข้ามสายโซ่ และในอดีต เหตุการณ์ของการโจรกรรมเกิดขึ้นบ่อยครั้งในสะพานข้ามสายโซ่ที่ใช้พยานหลักฐาน

ในทางกลับกัน การดำเนินการแบบ cross-chain ระหว่าง Rollup และ ETH mainnet นั้นแตกต่างโดยพื้นฐานจากกระบวนการ cross-chain ที่กล่าวมาข้างต้น เนื่องจากสถานะของ Layer2 ถูกกำหนดโดยข้อมูลที่บันทึกไว้ใน Layer1 ตราบใดที่คุณใช้สะพานข้ามสายโซ่ Rollup อย่างเป็นทางการ มันก็จะมีโครงสร้างที่ปลอดภัยในการดำเนินงาน

สิ่งนี้เน้นย้ำสาระสำคัญของ Rollup ซึ่งจากมุมมองของผู้ใช้ ปรากฏเป็นเครือข่ายอิสระ แต่ในความเป็นจริง สิ่งที่เรียกว่า "Layer2" เป็นเพียงหน้าต่างแสดงผลที่รวดเร็วที่เปิดโดย Rollup ให้กับผู้ใช้ และโครงสร้างที่เหมือนลูกโซ่ที่แท้จริง ยังคงบันทึกไว้ใน Layer1 ดังนั้นเราจึงสามารถพิจารณา L2 ว่าเป็นครึ่งเชนหรือ "เชนที่สร้างขึ้นบนเลเยอร์ 1"

ลองใหม่ได้

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

ตั๋วที่ลองซ้ำได้เป็นเครื่องมือพื้นฐานที่ใช้ในสะพานทางการของ Arbitrum ระหว่างการฝากเงิน ซึ่งใช้ได้กับทั้งการฝาก ETH และ ERC20 วงจรชีวิตประกอบด้วยสามขั้นตอน:

1. การส่งตั๋วบน L1: ใช้วิธี 'createRetryableTicket()' ในสัญญากล่องจดหมายเข้าล่าช้าเพื่อสร้างตั๋วการฝากเงินและส่ง
2. การไถ่ถอนอัตโนมัติบน L2: ในกรณีส่วนใหญ่ ซีเควนเซอร์สามารถแลกตั๋วให้กับผู้ใช้ได้โดยอัตโนมัติ โดยไม่ต้องดำเนินการด้วยตนเองเพิ่มเติม
3. การไถ่ถอนด้วยตนเองบน L2: ในบางกรณีที่รุนแรง เช่น ราคาน้ำมันที่เพิ่มขึ้นอย่างกะทันหันใน L2 หากน้ำมันที่ชำระล่วงหน้าบนตั๋วไม่เพียงพอ การไถ่ถอนอัตโนมัติจะไม่สามารถเกิดขึ้นได้ ในสถานการณ์สมมตินี้ ผู้ใช้จำเป็นต้องมีการแทรกแซงด้วยตนเอง โปรดทราบว่าหากการแลกอัตโนมัติล้มเหลว ผู้ใช้จะต้องแลกตั๋วด้วยตนเองภายใน 7 วัน มิฉะนั้น ตั๋วจะถูกลบ (ส่งผลให้สูญเสียเงินทุนอย่างถาวร) หรือผู้ใช้จำเป็นต้องจ่ายค่าธรรมเนียมบางอย่างเพื่อต่ออายุพื้นที่จัดเก็บของตั๋ว

นอกจากนี้ เกี่ยวกับกระบวนการถอนเงินบนสะพานอย่างเป็นทางการของ Arbitrum แม้ว่ากระบวนการจะมีความคล้ายคลึงกันแบบสมมาตรบางอย่างเมื่อเปรียบเทียบกับการฝากเงิน แต่ไม่มีแนวคิดในการลองตั๋วซ้ำ สิ่งนี้สามารถเข้าใจได้จากมุมมองของ Rollup Protocol เอง และสามารถเน้นความแตกต่างบางประการได้:

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

เกตเวย์ข้ามสายโซ่สำหรับสินทรัพย์ ERC-20

การผูกมัดข้ามสินทรัพย์ ERC-20 นั้นซับซ้อน เราสามารถคิดถึงคำถามหลายประการ:

• จะปรับใช้โทเค็นที่ปรับใช้บน L1 บน L2 ได้อย่างไร
• สัญญาที่เกี่ยวข้องกับ L2 จำเป็นต้องปรับใช้ล่วงหน้าด้วยตนเอง หรือระบบสามารถปรับใช้สัญญาสินทรัพย์สำหรับโทเค็นที่ข้ามไปแล้ว แต่ยังไม่ได้ปรับใช้สัญญาโดยอัตโนมัติหรือไม่
• สำหรับสินทรัพย์ ERC-20 ใน L1 ที่อยู่สัญญาที่เกี่ยวข้องใน L2 คืออะไร มันควรจะสอดคล้องกับ L1 หรือไม่?
• โทเค็นที่ออกโดยกำเนิดบน L2 สามารถเชื่อมโยงข้ามกับ L1 ได้อย่างไร
• โทเค็นที่มีฟังก์ชันพิเศษ เช่น โทเค็นรีเบสที่มีปริมาณที่ปรับได้และโทเค็นที่มีดอกเบี้ยเติบโตเอง จะสามารถเชื่อมโยงข้ามสายโซ่ได้อย่างไร

เราจะไม่ตอบคำถามเหล่านี้ทั้งหมดเพราะมันซับซ้อนเกินกว่าจะเปิดเผย คำถามเหล่านี้ใช้เพื่ออธิบายความซับซ้อนของ cross-chain ERC20 เท่านั้น

ปัจจุบัน โซลูชันการปรับขนาดจำนวนมากใช้โซลูชันรายการที่อนุญาตและรายการด้วยตนเอง เพื่อหลีกเลี่ยงปัญหาที่ซับซ้อนและเงื่อนไขขอบเขตต่างๆ

Arbitrum ใช้ระบบ Gateway เพื่อแก้ปัญหาการติดขัดของ ERC20 cross-chain ส่วนใหญ่ มันมีคุณสมบัติดังต่อไปนี้:

• ส่วนประกอบเกตเวย์ปรากฏเป็นคู่ที่ L1 และ L2
• เราเตอร์เกตเวย์มีหน้าที่รับผิดชอบในการดูแลรักษาการจับคู่ที่อยู่ระหว่างโทเค็น L1<->โทเค็น L2 นอกจากนี้ การแมประหว่างโทเค็นบางตัว<->เกตเวย์บางตัว
• ตัวเกตเวย์สามารถแบ่งออกเป็นเกตเวย์ ERC20 มาตรฐาน, เกตเวย์แบบกำหนดเองทั่วไป, เกตเวย์แบบกำหนดเอง ฯลฯ เพื่อแก้ปัญหาประเภทและฟังก์ชันต่างๆ ของปัญหาการเชื่อมโยง ERC20

ลองใช้ cross-chain ของ WETH ที่ค่อนข้างง่ายเป็นตัวอย่างเพื่อแสดงให้เห็นถึงความจำเป็นในการปรับแต่งเกตเวย์

WETH เทียบเท่ากับ ERC20 ของ ETH เนื่องจากเป็นสกุลเงินหลัก Ether จึงไม่สามารถใช้ฟังก์ชันที่ซับซ้อนใน dApps จำนวนมากได้ ดังนั้นจึงจำเป็นต้องมี ERC20 ที่เทียบเท่ากัน โอน ETH บางส่วนไปยังสัญญา WETH ซึ่งจะถูกล็อคไว้ในสัญญา และ WETH ในปริมาณเท่ากันจะถูกสร้างขึ้น

ในทำนองเดียวกัน สามารถเผา WETH และ ETH ก็สามารถถอนออกได้ แน่นอนว่าอัตราส่วนของการหมุนเวียน WETH และ ETH ที่ถูกล็อคจะเป็น 1:1 เสมอ

ถ้าเราโยง WETH ไปยัง L2 โดยตรง เราจะพบปัญหาแปลกๆ:

• เป็นไปไม่ได้ที่จะแกะ WETH ลงใน ETH บน L2 เนื่องจากไม่มี ETH ที่สอดคล้องกันสำหรับการล็อคบน L2
• สามารถใช้ฟังก์ชัน Wrap ได้ แต่หาก WETH ที่สร้างขึ้นใหม่เหล่านี้ถูกข้ามกลับไปที่ L1 จะไม่สามารถแยกส่วนออกเป็น ETH บน L1 ได้เนื่องจากสัญญา WETH บน L1 และ L2 ไม่ใช่ "สมมาตร"

เห็นได้ชัดว่าสิ่งนี้ฝ่าฝืนหลักการออกแบบของ WETH ดังนั้น เมื่อ WETH เป็นแบบ cross-chain ไม่ว่าจะเป็นการฝากหรือถอนเงิน จะต้องแกะมันออกเป็น ETH ก่อน จากนั้นจึงข้ามไปอีกด้านหนึ่ง จากนั้นจึงรวมเข้ากับ WETH นี่คือบทบาทของ WETH Gateway

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

กล่องจดหมายล่าช้า

สิ่งที่ตรงกันข้ามกับกล่องจดหมายที่รวดเร็วหรือที่เรียกว่า Sequencer Inbox คือกล่องจดหมายที่ช้า (ชื่อเต็มกล่องจดหมายล่าช้า) ทำไมต้องแยกระหว่างเร็วและช้า? เนื่องจากกล่องขาเข้าแบบรวดเร็วมีไว้สำหรับการรับชุดของธุรกรรม L2 ที่เผยแพร่โดยซีเควนเซอร์ และธุรกรรมใดๆ ที่ไม่ได้ประมวลผลล่วงหน้าโดยซีเควนเซอร์ภายในเครือข่าย L2 ไม่ควรปรากฏในสัญญากล่องขาเข้าแบบรวดเร็ว

ฟังก์ชั่นแรกของกล่องจดหมายที่ช้าคือจัดการกระบวนการฝากจาก L1 ถึง L2 ผู้ใช้เริ่มการฝากเงินผ่านกล่องจดหมายที่ช้า และเมื่อซีเควนเซอร์สังเกตสิ่งนี้ จะสะท้อนไปที่ L2 ในที่สุด บันทึกการฝากเงินนี้จะรวมอยู่ในลำดับธุรกรรม L2 โดยซีเควนเซอร์ และส่งไปยังสัญญากล่องจดหมายแบบรวดเร็ว (Sequencer Inbox)

ในสถานการณ์สมมตินี้ ไม่เหมาะสมสำหรับผู้ใช้ที่จะส่งธุรกรรมการฝากเงินไปยังกล่องจดหมายที่รวดเร็ว (Sequencer Inbox) โดยตรง เนื่องจากธุรกรรมที่ส่งไปยังกล่องจดหมายที่รวดเร็วอาจขัดขวางการเรียงลำดับธุรกรรมปกติใน Layer2 ซึ่งส่งผลต่อการดำเนินงานของซีเควนเซอร์

ฟังก์ชั่นที่สองของกล่องจดหมายที่ช้าคือทนต่อการเซ็นเซอร์ ธุรกรรมที่ส่งโดยตรงไปยังสัญญากล่องจดหมายที่ช้าโดยทั่วไปจะรวมเข้ากับกล่องจดหมายที่รวดเร็วภายใน 10 นาทีโดยซีเควนเซอร์ อย่างไรก็ตาม หากตัวจัดลำดับละเว้นคำขอของคุณอย่างประสงค์ร้าย กล่องขาเข้าที่ช้าจะมีคุณสมบัติบังคับรวม:

หากธุรกรรมถูกส่งไปยังกล่องจดหมายล่าช้า และหลังจากผ่านไป 24 ชั่วโมง รายการดังกล่าวยังคงไม่ถูกรวมเข้ากับลำดับธุรกรรมโดยตัวจัดลำดับ ผู้ใช้สามารถทริกเกอร์ฟังก์ชันการรวมกำลังบน Layer1 ได้ด้วยตนเอง การดำเนินการนี้บังคับให้ธุรกรรมที่ถูกละเลยโดยซีเควนเซอร์ถูกบังคับรวมไว้ในกล่องจดหมายที่รวดเร็ว (กล่องจดหมายของซีเควน) ต่อจากนั้นโหนด Arbitrum One ทั้งหมดจะถูกตรวจพบและรวมไว้ในลำดับธุรกรรมของ Layer2

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

จากนี้ จะเห็นได้ว่าไม่ว่าทิศทางและระดับของธุรกรรมใดก็ตาม ในที่สุดตัวจัดลำดับจะไม่สามารถเซ็นเซอร์คุณได้อย่างถาวร

ฟังก์ชั่นหลักหลายประการของกล่องจดหมายที่ช้า (Inbox):

• ฝากETH(): ฟังก์ชั่นที่ง่ายที่สุดสำหรับการฝาก ETH
• createRetryableTicket(): ใช้สำหรับฝาก ETH, ERC20 และข้อความ ให้ความยืดหยุ่นที่มากกว่าเมื่อเทียบกับการฝาก ETH() โดยอนุญาตข้อกำหนด เช่น ที่อยู่รับใน L2 หลังจากการฝากเงิน
• forceInclusion(): ฟังก์ชันนี้ ซึ่งเป็นฟีเจอร์บังคับรวม ซึ่งใครๆ ก็สามารถเรียกใช้ได้ ฟังก์ชันตรวจสอบว่าธุรกรรมที่ส่งไปยังสัญญากล่องจดหมายที่ช้านั้นไม่ได้รับการประมวลผลหลังจาก 24 ชั่วโมงหรือไม่ หากตรงตามเงื่อนไข ข้อความนั้นจะรวมข้อความไว้ด้วย

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

กล่องขาออก

กล่องขาออกเกี่ยวข้องกับการถอนเงินเท่านั้นและสามารถเข้าใจได้ว่าเป็นระบบบันทึกและจัดการพฤติกรรมการถอน:

• เรารู้ว่าการถอนเงินบนสะพานอย่างเป็นทางการของ Arbitrum ต้องรอประมาณ 7 วันเพื่อให้ระยะเวลาท้าทายสิ้นสุดลง และการถอนจะสามารถทำได้หลังจากที่ Rollup Block สิ้นสุดลงเท่านั้น หลังจากช่วงเวลาท้าทายสิ้นสุดลง ผู้ใช้จะส่ง Merkle Proof ที่เกี่ยวข้องไปยังสัญญา Outbox บน Layer1 ซึ่งจะสื่อสารกับสัญญาสำหรับฟังก์ชันอื่นๆ (เช่น การปลดล็อคสินทรัพย์ที่ถูกล็อคในสัญญาอื่น) และสุดท้ายก็ทำการถอนออกให้เสร็จสิ้น
• สัญญา OutBox จะบันทึกข้อความข้ามสายโซ่จาก L2 ถึง L1 ที่ได้รับการประมวลผลเพื่อป้องกันไม่ให้บุคคลอื่นส่งคำขอถอนเงินที่ดำเนินการซ้ำแล้วซ้ำอีก บันทึกความสอดคล้องระหว่างดัชนีการใช้จ่ายและข้อมูลคำขอถอนเงินโดยใช้ 'การแมป (uint256 => bytes32) การใช้จ่ายสาธารณะ' หากการแมป[spentIndex] != bytes32(0) คำขอจะถูกถอนออก หลักการคล้ายกับตัวนับธุรกรรม Nonce เพื่อป้องกันการโจมตีซ้ำ

ด้านล่างนี้เราจะใช้ ETH เป็นตัวอย่างเพื่ออธิบายขั้นตอนการฝากและถอนเงินอย่างครบถ้วน ข้อแตกต่างเพียงอย่างเดียวระหว่าง ERC20 และ ETH คือแต่ก่อนใช้ Gateway เราจะไม่อธิบายอย่างละเอียด

การฝาก ETH

1. ผู้ใช้เรียกใช้ฟังก์ชันDepositETH() ของกล่องที่ช้า

2. ฟังก์ชั่นนี้จะยังคงเรียก 'bridge.enqueueDelayedMessage()' ต่อไป บันทึกข้อความในสัญญาบริดจ์ และส่ง ETH ไปยังสัญญาบริดจ์ เงินฝาก ETH ทั้งหมดจะถูกเก็บไว้ในสัญญาบริดจ์ ซึ่งเทียบเท่ากับที่อยู่การฝากเงิน

3. ซีเควนเซอร์จะตรวจสอบข้อความการฝากในกล่องที่ช้าและสะท้อนถึงการดำเนินการฝากไปยังฐานข้อมูล L2 ผู้ใช้สามารถดูสินทรัพย์ที่พวกเขาฝากไว้ในเครือข่าย L2

4. ตัวจัดลำดับจะรวมบันทึกเงินฝากไว้ในชุดธุรกรรม และส่งไปยังสัญญากล่องด่วนบน L1

การถอน ETH

1. ผู้ใช้เรียกใช้ฟังก์ชัน withdrawEth() ของสัญญา ArbSys บน L2 และหมายเลข ET ที่สอดคล้องกันจะถูกเบิร์นบน L2

2. ซีเควนเซอร์ส่งคำขอถอนเงินไปยังกล่องด่วน

3. โหนด Validator จะสร้าง Rollup Block ใหม่ตามลำดับธุรกรรมในกล่องด่วน ซึ่งจะมีธุรกรรมการถอนเงินข้างต้น

4. หลังจากที่ Rollup Block ผ่านช่วงเวลาท้าทายซึ่งได้รับการยืนยันแล้ว ผู้ใช้สามารถเรียกใช้ฟังก์ชัน Outbox.execute Transaction() บน L1 เพื่อพิสูจน์ว่าพารามิเตอร์ได้รับจากสัญญา ArbSys ที่กล่าวถึงข้างต้น

5. หลังจากที่สัญญากล่องจดหมายออกได้รับการยืนยันว่าถูกต้อง จำนวน ETH ที่เกี่ยวข้องในบริดจ์จะถูกปลดล็อคและส่งไปยังผู้ใช้

ถอนเงินสดด่วน

เมื่อใช้สะพานอย่างเป็นทางการของ Optimistic Rollup เพื่อถอนเงินสด จะมีปัญหาในการรอช่วงท้าทาย เราสามารถใช้สะพานข้ามสายโซ่ส่วนตัวของบุคคลที่สามเพื่อลบปัญหานี้:

• การแลกเปลี่ยนล็อคอะตอม วิธีนี้จะแลกเปลี่ยนทรัพย์สินระหว่างทั้งสองฝ่ายภายในเครือข่ายของตนเท่านั้นและเป็นการแลกเปลี่ยนแบบอะตอมมิก ตราบใดที่ฝ่ายหนึ่งจัดหา Preimage ทั้งสองฝ่ายก็จะได้รับทรัพย์สินที่พวกเขาสมควรได้รับอย่างแน่นอน แต่ปัญหาคือสภาพคล่องค่อนข้างหายากและคุณจำเป็นต้องค้นหาคู่สัญญาที่ใช้วิธีการแบบ peer-to-peerF
• พยานเดินข้ามสะพานโซ่ สะพานข้ามโซ่ประเภททั่วไปคือสะพานพยาน ผู้ใช้ส่งคำขอถอนเงินของตนเอง และปลายทางการถอนเงินจะชี้ไปที่ผู้ดำเนินการของบริดจ์บุคคลที่สามหรือกลุ่มสภาพคล่อง หลังจากที่พยานค้นพบว่ามีการส่งธุรกรรมข้ามเชนไปยังสัญญากล่องด่วน L1 แล้ว เขาสามารถโอนเงินไปยังผู้ใช้ทางฝั่ง L1 ได้โดยตรง วิธีการนี้ใช้ระบบฉันทามติอื่นในการตรวจสอบเลเยอร์ 2 และดำเนินการตามข้อมูลที่ส่งไปยังเลเยอร์ 1 ปัญหาคือระดับความปลอดภัยในโหมดนี้ไม่สูงเท่ากับระดับความปลอดภัยใน Rollup Bridge อย่างเป็นทางการ \

ถูกบังคับให้ถอนตัว

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

เมื่อมองย้อนกลับไปที่ขั้นตอนการถอน ETH มีเพียงขั้นตอนที่ 1 และ 2 เท่านั้นที่เกี่ยวข้องกับการเซ็นเซอร์ซีเควนเซอร์ ดังนั้นจึงจำเป็นต้องเปลี่ยนเพียงสองขั้นตอนนี้เท่านั้น:

• เมื่อเรียก 'inbox.sendL2Message()' ในสัญญากล่องที่ช้าบน L1 พารามิเตอร์อินพุตคือพารามิเตอร์ที่ต้องป้อนเมื่อเรียก withdrawEth() บน L2 ข้อความนี้จะถูกแชร์ไปยังสัญญาสะพานบน L1
• หลังจากช่วงเวลารอที่บังคับรวม 24 ชั่วโมง ระบบจะเรียกการบังคับ Inclusion() ในกล่องด่วนเพื่อดำเนินการบังคับรวม Fast Box Contract จะตรวจสอบว่ามีข้อความที่เกี่ยวข้องในบริดจ์หรือไม่

ผู้ใช้สามารถถอนเงินในกล่องจดหมายออกได้ และขั้นตอนที่เหลือจะเหมือนกับการถอนเงินปกติ

นอกจากนี้ ยังมีบทช่วยสอนโดยละเอียดเกี่ยวกับการใช้ Arb SDK ในบทช่วยสอนอนุญาโตตุลาการเพื่อเป็นแนวทางแก่ผู้ใช้เกี่ยวกับวิธีการดำเนินการธุรกรรม L2 ในพื้นที่และธุรกรรม L2 ถึง L1 ผ่านฟังก์ชัน forceInclusion()

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

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