ข้อความหลัก: ในบทความก่อนหน้านี้ เราได้กล่าวถึงสัญญา Sequencer Inbox ได้รับการออกแบบมาโดยเฉพาะเพื่อรับชุดข้อมูลธุรกรรมที่เผยแพร่โดยซีเควนเซอร์ในเลเยอร์ 1 ในเวลาเดียวกัน เราชี้ให้เห็นว่า Sequencer Inbox เรียกอีกอย่างว่า "fast box" โดยที่คู่กันคือ Delayed Inbox (เรียกว่า Inbox) ต่อไป เราจะให้คำอธิบายโดยละเอียดเกี่ยวกับส่วนประกอบที่เกี่ยวข้องกับการส่งข้อความข้ามสายโซ่ เช่น กล่องขาเข้าที่ล่าช้า
ธุรกรรมข้ามสายโซ่สามารถแบ่งออกเป็น 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 วงจรชีวิตของมันประกอบด้วยสามขั้นตอน:
การส่งตั๋วบน L1: สร้างตั๋วการฝากเงินโดยใช้วิธี createRetryableTicket() ในสัญญากล่องจดหมายเข้าล่าช้าและส่ง
การไถ่ถอนอัตโนมัติบน L2: ในกรณีส่วนใหญ่ ซีเควนเซอร์สามารถแลกตั๋วให้กับผู้ใช้โดยอัตโนมัติโดยไม่ต้องดำเนินการด้วยตนเองอีกต่อไป
การไถ่ถอนด้วยตนเองบน L2: ในบางกรณี Edge เช่น ราคาน้ำมันที่เพิ่มขึ้นอย่างกะทันหันใน L2 ซึ่งน้ำมันที่ชำระล่วงหน้าในตั๋วไม่เพียงพอ การไถ่ถอนอัตโนมัติอาจล้มเหลว ในกรณีเช่นนี้ ผู้ใช้จำเป็นต้องมีการแทรกแซงด้วยตนเอง โปรดทราบว่าหากการแลกอัตโนมัติล้มเหลว จะต้องแลกตั๋วด้วยตนเองภายใน 7 วัน มิฉะนั้นตั๋วอาจถูกลบ (ส่งผลให้สูญเสียเงินทุนอย่างถาวร) หรือต้องชำระค่าธรรมเนียมเพื่อต่ออายุสัญญาเช่า
นอกจากนี้ ในกระบวนการถอนตัวของสะพานอย่างเป็นทางการของ Arbitrum แม้ว่าจะมีความคล้ายคลึงกันแบบสมมาตรกับพฤติกรรมการฝากเงินในแง่ของกระบวนการ แต่ไม่มีแนวคิดของการลองใหม่ได้ สิ่งนี้สามารถเข้าใจได้จากมุมมองของ Rollup Protocol และจากการตรวจสอบความแตกต่างบางประการ:
ไม่มีการไถ่ถอนอัตโนมัติในระหว่างการถอน เนื่องจาก EVM ไม่มีตัวจับเวลาหรือระบบอัตโนมัติ แม้ว่าการไถ่ถอนอัตโนมัติสามารถทำได้บน L2 ด้วยความช่วยเหลือของซีเควนเซอร์ ผู้ใช้บน L1 จำเป็นต้องโต้ตอบกับสัญญากล่องขาออกด้วยตนเองเพื่ออ้างสิทธิ์ในทรัพย์สินของตน
นอกจากนี้ยังไม่มีปัญหาเรื่องการหมดอายุของตั๋วในระหว่างการถอนเงิน ตราบใดที่ระยะเวลาท้าทายผ่านไป ก็สามารถอ้างสิทธิ์ในทรัพย์สินได้ตลอดเวลา
ธุรกรรมข้ามสายโซ่ที่เกี่ยวข้องกับสินทรัพย์ ERC-20 มีความซับซ้อน เราสามารถพิจารณาคำถามหลายประการ:
เราไม่ได้ตั้งใจที่จะตอบคำถามเหล่านี้ทั้งหมดเนื่องจากคำถามเหล่านี้ซับซ้อนเกินกว่าจะตอบให้ครอบคลุม คำถามเหล่านี้มีขึ้นเพื่อแสดงให้เห็นถึงความซับซ้อนของธุรกรรมข้ามสายโซ่ ERC-20
ปัจจุบัน โซลูชันการปรับขนาดจำนวนมากใช้รายการที่อนุญาต + โซลูชันรายการด้วยตนเอง เพื่อหลีกเลี่ยงปัญหาที่ซับซ้อนและเงื่อนไขขอบเขตต่างๆ
Arbitrum ใช้ระบบเกตเวย์เพื่อแก้ไขจุดบกพร่องส่วนใหญ่ของธุรกรรมข้ามสายโซ่ ERC20 โดยมีลักษณะดังต่อไปนี้:
เพื่อแสดงให้เห็นถึงความจำเป็นของเกตเวย์แบบกำหนดเอง ลองพิจารณาตัวอย่างที่ค่อนข้างง่ายของการถ่ายโอน WETH แบบข้ามสายโซ่
WETH เทียบเท่ากับ ERC20 ของ ETH เนื่องจาก Ether ทำหน้าที่เป็นสกุลเงินหลัก ฟังก์ชันที่ซับซ้อนมากมายใน dApps จึงเป็นไปไม่ได้ที่จะบรรลุโดยตรง ดังนั้นจึงจำเป็นต้องมี ERC20 ที่เทียบเท่ากับ WETH ด้วยการฝาก ETH บางส่วนในสัญญา WETH พวกมันจะถูกล็อคอยู่ภายในสัญญา ทำให้เกิดจำนวน WETH ที่เทียบเท่ากัน
ในทำนองเดียวกัน สามารถเผา WETH เพื่อถอน ETH ได้ เห็นได้ชัดว่าจำนวนหมุนเวียนของ WETH และจำนวน ETH ที่ถูกล็อคจะรักษาอัตราส่วน 1: 1 ไว้เสมอ
ถ้าเราโยง WETH ไปยัง 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
จากนี้ จะเห็นได้ว่าท้ายที่สุดแล้วซีเควนเซอร์ไม่สามารถเซ็นเซอร์ธุรกรรมในทิศทางหรือเลเยอร์ใดๆ ได้อย่างถาวร
ฟังก์ชั่นหลักหลายประการของกล่องขาเข้าแบบช้ามีดังนี้:
อย่างไรก็ตาม สิ่งสำคัญที่ควรทราบคือฟังก์ชัน forceInclusion() จริงๆ แล้วอยู่ในสัญญากล่องด่วน เพื่อความชัดเจน เราได้พูดคุยถึงเรื่องนี้ที่นี่ควบคู่ไปกับฟังก์ชันกล่องช้า
กล่องขาออกเกี่ยวข้องกับการถอนเงินเท่านั้นและสามารถเข้าใจได้ว่าเป็นระบบบันทึกและจัดการพฤติกรรมการถอน:
ด้านล่างนี้เราจะอธิบายขั้นตอนการฝากและถอนเงินโดยใช้ ETH เป็นตัวอย่าง กระบวนการสำหรับโทเค็น ERC20 นั้นคล้ายคลึงกัน โดยมีการเพิ่มเกตเวย์ แต่เราจะไม่อธิบายรายละเอียดในที่นี้
ผู้ใช้เรียกใช้ฟังก์ชัน withdrawEth() ของสัญญา ArbSys บน L2 และเบิร์นจำนวน ETH ที่สอดคล้องกันบน L2
ซีเควนเซอร์ส่งคำขอถอนเงินไปยังกล่องด่วน
โหนด Validator จะสร้าง Rollup Block ใหม่ตามลำดับธุรกรรมในกล่องด่วน ซึ่งจะมีธุรกรรมการถอนเงินข้างต้น
หลังจากที่ Rollup Block ผ่านช่วงเวลาท้าทายและได้รับการยืนยันแล้ว ผู้ใช้สามารถเรียกใช้ฟังก์ชัน Outbox.execute Transaction() บน L1 เพื่อพิสูจน์ว่าพารามิเตอร์ได้รับจากสัญญา ArbSys ที่กล่าวถึงข้างต้น
หลังจากที่สัญญากล่องจดหมายออกได้รับการยืนยันว่าถูกต้อง จำนวน ETH ที่เกี่ยวข้องในบริดจ์จะถูกปลดล็อคและส่งไปยังผู้ใช้
การใช้สะพานอย่างเป็นทางการของ Rollup ในแง่ดีเกี่ยวข้องกับการรอช่วงเวลาท้าทาย เพื่อหลีกเลี่ยงปัญหานี้ เราสามารถใช้สะพานข้ามสายโซ่ส่วนตัวของบุคคลที่สามได้:
ฟังก์ชัน forceInclusion() ใช้เพื่อต่อต้านการเซ็นเซอร์ซีเควนเซอร์ สามารถนำไปใช้กับธุรกรรม L2 ในพื้นที่, ธุรกรรม L1 ถึง L2 และธุรกรรม L2 ถึง L1 เนื่องจากการเซ็นเซอร์ที่เป็นอันตรายของซีเควนเซอร์ส่งผลกระทบอย่างมากต่อประสบการณ์การทำธุรกรรม เราจึงมักเลือกที่จะถอนตัวจาก L2 ด้านล่างนี้เป็นตัวอย่างของการใช้ forceInclusion() สำหรับการบังคับถอน:
ในบริบทของการถอน ETH เฉพาะขั้นตอนที่ 1 และ 2 เท่านั้นที่เกี่ยวข้องกับการเซ็นเซอร์ซีเควนเซอร์ ดังนั้นเราจึงต้องแก้ไขสองขั้นตอนนี้เท่านั้น:
สุดท้ายผู้ใช้สามารถถอนตัวออกจากกล่องขาออกได้ และขั้นตอนที่เหลือจะเหมือนกับในกระบวนการถอนเงินปกติ
นอกจากนี้ยังมีบทช่วยสอนโดยละเอียดในพื้นที่เก็บข้อมูลบทช่วยสอนอนุญาโตตุลาการที่แนะนำผู้ใช้เกี่ยวกับวิธีการดำเนินการธุรกรรม L2 ในพื้นที่และธุรกรรม L2 ถึง L1 โดยใช้ forceInclusion() ผ่าน Arb SDK
Пригласить больше голосов
ข้อความหลัก: ในบทความก่อนหน้านี้ เราได้กล่าวถึงสัญญา Sequencer Inbox ได้รับการออกแบบมาโดยเฉพาะเพื่อรับชุดข้อมูลธุรกรรมที่เผยแพร่โดยซีเควนเซอร์ในเลเยอร์ 1 ในเวลาเดียวกัน เราชี้ให้เห็นว่า Sequencer Inbox เรียกอีกอย่างว่า "fast box" โดยที่คู่กันคือ Delayed Inbox (เรียกว่า Inbox) ต่อไป เราจะให้คำอธิบายโดยละเอียดเกี่ยวกับส่วนประกอบที่เกี่ยวข้องกับการส่งข้อความข้ามสายโซ่ เช่น กล่องขาเข้าที่ล่าช้า
ธุรกรรมข้ามสายโซ่สามารถแบ่งออกเป็น 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 วงจรชีวิตของมันประกอบด้วยสามขั้นตอน:
การส่งตั๋วบน L1: สร้างตั๋วการฝากเงินโดยใช้วิธี createRetryableTicket() ในสัญญากล่องจดหมายเข้าล่าช้าและส่ง
การไถ่ถอนอัตโนมัติบน L2: ในกรณีส่วนใหญ่ ซีเควนเซอร์สามารถแลกตั๋วให้กับผู้ใช้โดยอัตโนมัติโดยไม่ต้องดำเนินการด้วยตนเองอีกต่อไป
การไถ่ถอนด้วยตนเองบน L2: ในบางกรณี Edge เช่น ราคาน้ำมันที่เพิ่มขึ้นอย่างกะทันหันใน L2 ซึ่งน้ำมันที่ชำระล่วงหน้าในตั๋วไม่เพียงพอ การไถ่ถอนอัตโนมัติอาจล้มเหลว ในกรณีเช่นนี้ ผู้ใช้จำเป็นต้องมีการแทรกแซงด้วยตนเอง โปรดทราบว่าหากการแลกอัตโนมัติล้มเหลว จะต้องแลกตั๋วด้วยตนเองภายใน 7 วัน มิฉะนั้นตั๋วอาจถูกลบ (ส่งผลให้สูญเสียเงินทุนอย่างถาวร) หรือต้องชำระค่าธรรมเนียมเพื่อต่ออายุสัญญาเช่า
นอกจากนี้ ในกระบวนการถอนตัวของสะพานอย่างเป็นทางการของ Arbitrum แม้ว่าจะมีความคล้ายคลึงกันแบบสมมาตรกับพฤติกรรมการฝากเงินในแง่ของกระบวนการ แต่ไม่มีแนวคิดของการลองใหม่ได้ สิ่งนี้สามารถเข้าใจได้จากมุมมองของ Rollup Protocol และจากการตรวจสอบความแตกต่างบางประการ:
ไม่มีการไถ่ถอนอัตโนมัติในระหว่างการถอน เนื่องจาก EVM ไม่มีตัวจับเวลาหรือระบบอัตโนมัติ แม้ว่าการไถ่ถอนอัตโนมัติสามารถทำได้บน L2 ด้วยความช่วยเหลือของซีเควนเซอร์ ผู้ใช้บน L1 จำเป็นต้องโต้ตอบกับสัญญากล่องขาออกด้วยตนเองเพื่ออ้างสิทธิ์ในทรัพย์สินของตน
นอกจากนี้ยังไม่มีปัญหาเรื่องการหมดอายุของตั๋วในระหว่างการถอนเงิน ตราบใดที่ระยะเวลาท้าทายผ่านไป ก็สามารถอ้างสิทธิ์ในทรัพย์สินได้ตลอดเวลา
ธุรกรรมข้ามสายโซ่ที่เกี่ยวข้องกับสินทรัพย์ ERC-20 มีความซับซ้อน เราสามารถพิจารณาคำถามหลายประการ:
เราไม่ได้ตั้งใจที่จะตอบคำถามเหล่านี้ทั้งหมดเนื่องจากคำถามเหล่านี้ซับซ้อนเกินกว่าจะตอบให้ครอบคลุม คำถามเหล่านี้มีขึ้นเพื่อแสดงให้เห็นถึงความซับซ้อนของธุรกรรมข้ามสายโซ่ ERC-20
ปัจจุบัน โซลูชันการปรับขนาดจำนวนมากใช้รายการที่อนุญาต + โซลูชันรายการด้วยตนเอง เพื่อหลีกเลี่ยงปัญหาที่ซับซ้อนและเงื่อนไขขอบเขตต่างๆ
Arbitrum ใช้ระบบเกตเวย์เพื่อแก้ไขจุดบกพร่องส่วนใหญ่ของธุรกรรมข้ามสายโซ่ ERC20 โดยมีลักษณะดังต่อไปนี้:
เพื่อแสดงให้เห็นถึงความจำเป็นของเกตเวย์แบบกำหนดเอง ลองพิจารณาตัวอย่างที่ค่อนข้างง่ายของการถ่ายโอน WETH แบบข้ามสายโซ่
WETH เทียบเท่ากับ ERC20 ของ ETH เนื่องจาก Ether ทำหน้าที่เป็นสกุลเงินหลัก ฟังก์ชันที่ซับซ้อนมากมายใน dApps จึงเป็นไปไม่ได้ที่จะบรรลุโดยตรง ดังนั้นจึงจำเป็นต้องมี ERC20 ที่เทียบเท่ากับ WETH ด้วยการฝาก ETH บางส่วนในสัญญา WETH พวกมันจะถูกล็อคอยู่ภายในสัญญา ทำให้เกิดจำนวน WETH ที่เทียบเท่ากัน
ในทำนองเดียวกัน สามารถเผา WETH เพื่อถอน ETH ได้ เห็นได้ชัดว่าจำนวนหมุนเวียนของ WETH และจำนวน ETH ที่ถูกล็อคจะรักษาอัตราส่วน 1: 1 ไว้เสมอ
ถ้าเราโยง WETH ไปยัง 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
จากนี้ จะเห็นได้ว่าท้ายที่สุดแล้วซีเควนเซอร์ไม่สามารถเซ็นเซอร์ธุรกรรมในทิศทางหรือเลเยอร์ใดๆ ได้อย่างถาวร
ฟังก์ชั่นหลักหลายประการของกล่องขาเข้าแบบช้ามีดังนี้:
อย่างไรก็ตาม สิ่งสำคัญที่ควรทราบคือฟังก์ชัน forceInclusion() จริงๆ แล้วอยู่ในสัญญากล่องด่วน เพื่อความชัดเจน เราได้พูดคุยถึงเรื่องนี้ที่นี่ควบคู่ไปกับฟังก์ชันกล่องช้า
กล่องขาออกเกี่ยวข้องกับการถอนเงินเท่านั้นและสามารถเข้าใจได้ว่าเป็นระบบบันทึกและจัดการพฤติกรรมการถอน:
ด้านล่างนี้เราจะอธิบายขั้นตอนการฝากและถอนเงินโดยใช้ ETH เป็นตัวอย่าง กระบวนการสำหรับโทเค็น ERC20 นั้นคล้ายคลึงกัน โดยมีการเพิ่มเกตเวย์ แต่เราจะไม่อธิบายรายละเอียดในที่นี้
ผู้ใช้เรียกใช้ฟังก์ชัน withdrawEth() ของสัญญา ArbSys บน L2 และเบิร์นจำนวน ETH ที่สอดคล้องกันบน L2
ซีเควนเซอร์ส่งคำขอถอนเงินไปยังกล่องด่วน
โหนด Validator จะสร้าง Rollup Block ใหม่ตามลำดับธุรกรรมในกล่องด่วน ซึ่งจะมีธุรกรรมการถอนเงินข้างต้น
หลังจากที่ Rollup Block ผ่านช่วงเวลาท้าทายและได้รับการยืนยันแล้ว ผู้ใช้สามารถเรียกใช้ฟังก์ชัน Outbox.execute Transaction() บน L1 เพื่อพิสูจน์ว่าพารามิเตอร์ได้รับจากสัญญา ArbSys ที่กล่าวถึงข้างต้น
หลังจากที่สัญญากล่องจดหมายออกได้รับการยืนยันว่าถูกต้อง จำนวน ETH ที่เกี่ยวข้องในบริดจ์จะถูกปลดล็อคและส่งไปยังผู้ใช้
การใช้สะพานอย่างเป็นทางการของ Rollup ในแง่ดีเกี่ยวข้องกับการรอช่วงเวลาท้าทาย เพื่อหลีกเลี่ยงปัญหานี้ เราสามารถใช้สะพานข้ามสายโซ่ส่วนตัวของบุคคลที่สามได้:
ฟังก์ชัน forceInclusion() ใช้เพื่อต่อต้านการเซ็นเซอร์ซีเควนเซอร์ สามารถนำไปใช้กับธุรกรรม L2 ในพื้นที่, ธุรกรรม L1 ถึง L2 และธุรกรรม L2 ถึง L1 เนื่องจากการเซ็นเซอร์ที่เป็นอันตรายของซีเควนเซอร์ส่งผลกระทบอย่างมากต่อประสบการณ์การทำธุรกรรม เราจึงมักเลือกที่จะถอนตัวจาก L2 ด้านล่างนี้เป็นตัวอย่างของการใช้ forceInclusion() สำหรับการบังคับถอน:
ในบริบทของการถอน ETH เฉพาะขั้นตอนที่ 1 และ 2 เท่านั้นที่เกี่ยวข้องกับการเซ็นเซอร์ซีเควนเซอร์ ดังนั้นเราจึงต้องแก้ไขสองขั้นตอนนี้เท่านั้น:
สุดท้ายผู้ใช้สามารถถอนตัวออกจากกล่องขาออกได้ และขั้นตอนที่เหลือจะเหมือนกับในกระบวนการถอนเงินปกติ
นอกจากนี้ยังมีบทช่วยสอนโดยละเอียดในพื้นที่เก็บข้อมูลบทช่วยสอนอนุญาโตตุลาการที่แนะนำผู้ใช้เกี่ยวกับวิธีการดำเนินการธุรกรรม L2 ในพื้นที่และธุรกรรม L2 ถึง L1 โดยใช้ forceInclusion() ผ่าน Arb SDK