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

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

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

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

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

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

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

ลองใหม่ได้

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

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

1. การส่งตั๋วบน L1: สร้างตั๋วการฝากเงินโดยใช้วิธี createRetryableTicket() ในสัญญากล่องจดหมายเข้าล่าช้าและส่ง

2. การไถ่ถอนอัตโนมัติบน L2: ในกรณีส่วนใหญ่ ซีเควนเซอร์สามารถแลกตั๋วให้กับผู้ใช้โดยอัตโนมัติโดยไม่ต้องดำเนินการด้วยตนเองอีกต่อไป

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

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

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

• นอกจากนี้ยังไม่มีปัญหาเรื่องการหมดอายุของตั๋วในระหว่างการถอนเงิน ตราบใดที่ระยะเวลาท้าทายผ่านไป ก็สามารถอ้างสิทธิ์ในทรัพย์สินได้ตลอดเวลา

ERC-20 เกตเวย์ข้ามเครือข่ายสินทรัพย์

ธุรกรรมข้ามสายโซ่ที่เกี่ยวข้องกับสินทรัพย์ ERC-20 มีความซับซ้อน เราสามารถพิจารณาคำถามหลายประการ:

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

เราไม่ได้ตั้งใจที่จะตอบคำถามเหล่านี้ทั้งหมดเนื่องจากคำถามเหล่านี้ซับซ้อนเกินกว่าจะตอบให้ครอบคลุม คำถามเหล่านี้มีขึ้นเพื่อแสดงให้เห็นถึงความซับซ้อนของธุรกรรมข้ามสายโซ่ ERC-20

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

Arbitrum ใช้ระบบเกตเวย์เพื่อแก้ไขจุดบกพร่องส่วนใหญ่ของธุรกรรมข้ามสายโซ่ ERC20 โดยมีลักษณะดังต่อไปนี้:

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

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

WETH เทียบเท่ากับ ERC20 ของ ETH เนื่องจาก Ether ทำหน้าที่เป็นสกุลเงินหลัก ฟังก์ชันที่ซับซ้อนมากมายใน dApps จึงเป็นไปไม่ได้ที่จะบรรลุโดยตรง ดังนั้นจึงจำเป็นต้องมี ERC20 ที่เทียบเท่ากับ WETH ด้วยการฝาก 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 ดังนั้นเมื่อทำการข้าม cross-chain ของ WETH ไม่ว่าจะฝากหรือถอนออก จำเป็นต้องแกะมันเข้าไปใน ETH ก่อน จากนั้นจึงข้ามมันไป และห่อกลับเข้าไปใน WETH นี่คือจุดที่ WETH Gateway เข้ามามีบทบาท

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

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

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

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

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

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

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

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

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

ฟังก์ชั่นหลักหลายประการของกล่องขาเข้าแบบช้ามีดังนี้:

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

อย่างไรก็ตาม สิ่งสำคัญที่ควรทราบคือฟังก์ชัน forceInclusion() จริงๆ แล้วอยู่ในสัญญากล่องด่วน เพื่อความชัดเจน เราได้พูดคุยถึงเรื่องนี้ที่นี่ควบคู่ไปกับฟังก์ชันกล่องช้า

กล่องขาออก

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

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

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

การฝาก ETH

1. ผู้ใช้เรียกใช้ฟังก์ชันDepositETH() ของกล่องจดหมายล่าช้า
2. ฟังก์ชันนี้จะเรียกbridge.enqueueDelayedMessage() ซึ่งบันทึกข้อความในสัญญาบริดจ์และส่ง ETH ไปยังสัญญาบริดจ์ เงิน ETH ที่ฝากไว้ทั้งหมดจะถือเป็นสัญญาบริดจ์ ซึ่งทำหน้าที่เป็นที่อยู่สำหรับการฝากเงิน
3. ซีเควนเซอร์จะตรวจสอบข้อความการฝากในกล่องขาเข้าล่าช้า และสะท้อนถึงการดำเนินการฝากในฐานข้อมูล L2 ผู้ใช้สามารถดูสินทรัพย์ที่ฝากไว้บนเครือข่าย L2
4. ตัวจัดลำดับจะรวมบันทึกเงินฝากในชุดของธุรกรรม และส่งไปยังสัญญา Fast Inbox บน L1

การถอน ETH

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

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

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

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

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

การถอนเงินที่รวดเร็ว

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

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

บังคับถอนตัว

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

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

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

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

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

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

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