ในบทความก่อนหน้านี้ “โครงสร้างส่วนประกอบของ Arbitrum ตีความโดยอดีตทูตด้านเทคนิคของ Arbitrum (ตอนที่ 1)” เราได้แนะนำบทบาทของส่วนประกอบสำคัญใน Arbitrum รวมถึงซีเควนเซอร์, เครื่องมือตรวจสอบ, สัญญากล่องจดหมายของซีเควนเซอร์, Rollup Block และบทบาทของ หลักฐานการฉ้อโกงแบบไม่โต้ตอบ ในบทความวันนี้ เราจะเน้นไปที่การอธิบายองค์ประกอบที่เกี่ยวข้องกับการส่งข้อความข้ามสายโซ่ และการเข้าสู่ธุรกรรมต่อต้านการเซ็นเซอร์ในองค์ประกอบหลักของ Arbitrum
ข้อความหลัก: ในบทความก่อนหน้านี้ เราได้กล่าวถึงสัญญา Sequencer Inbox ได้รับการออกแบบมาโดยเฉพาะเพื่อรับชุดข้อมูลธุรกรรมที่เผยแพร่โดยซีเควนเซอร์ในเลเยอร์ 1 ในเวลาเดียวกัน เราชี้ให้เห็นว่า Sequencer Inbox เรียกอีกอย่างว่า "fast box" และในทางตรงกันข้าม มี "slow box" หรือ Delayed Inbox (เรียกว่า Inbox) ด้านล่างนี้ เราจะให้การตีความโดยละเอียดขององค์ประกอบที่เกี่ยวข้องกับการส่งข้อความข้ามสายโซ่ รวมถึงกล่องขาเข้าที่ล่าช้า
ธุรกรรมข้ามสายโซ่สามารถแบ่งออกเป็นธุรกรรมจาก 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 วงจรชีวิตประกอบด้วยสามขั้นตอน:
นอกจากนี้ เกี่ยวกับกระบวนการถอนเงินบนสะพานอย่างเป็นทางการของ Arbitrum แม้ว่ากระบวนการจะมีความคล้ายคลึงกันแบบสมมาตรบางอย่างเมื่อเปรียบเทียบกับการฝากเงิน แต่ไม่มีแนวคิดในการลองตั๋วซ้ำ สิ่งนี้สามารถเข้าใจได้จากมุมมองของ Rollup Protocol เอง และสามารถเน้นความแตกต่างบางประการได้:
การผูกมัดข้ามสินทรัพย์ ERC-20 นั้นซับซ้อน เราสามารถคิดถึงคำถามหลายประการ:
เราจะไม่ตอบคำถามเหล่านี้ทั้งหมดเพราะมันซับซ้อนเกินกว่าจะเปิดเผย คำถามเหล่านี้ใช้เพื่ออธิบายความซับซ้อนของ cross-chain ERC20 เท่านั้น
ปัจจุบัน โซลูชันการปรับขนาดจำนวนมากใช้โซลูชันรายการที่อนุญาตและรายการด้วยตนเอง เพื่อหลีกเลี่ยงปัญหาที่ซับซ้อนและเงื่อนไขขอบเขตต่างๆ
Arbitrum ใช้ระบบ Gateway เพื่อแก้ปัญหาการติดขัดของ ERC20 cross-chain ส่วนใหญ่ มันมีคุณสมบัติดังต่อไปนี้:
ลองใช้ cross-chain ของ WETH ที่ค่อนข้างง่ายเป็นตัวอย่างเพื่อแสดงให้เห็นถึงความจำเป็นในการปรับแต่งเกตเวย์
WETH เทียบเท่ากับ ERC20 ของ ETH เนื่องจากเป็นสกุลเงินหลัก Ether จึงไม่สามารถใช้ฟังก์ชันที่ซับซ้อนใน dApps จำนวนมากได้ ดังนั้นจึงจำเป็นต้องมี ERC20 ที่เทียบเท่ากัน โอน ETH บางส่วนไปยังสัญญา WETH ซึ่งจะถูกล็อคไว้ในสัญญา และ WETH ในปริมาณเท่ากันจะถูกสร้างขึ้น
ในทำนองเดียวกัน สามารถเผา WETH และ ETH ก็สามารถถอนออกได้ แน่นอนว่าอัตราส่วนของการหมุนเวียน WETH และ ETH ที่ถูกล็อคจะเป็น 1:1 เสมอ
ถ้าเราโยง WETH ไปยัง 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 เป็นตัวอย่างเพื่ออธิบายขั้นตอนการฝากและถอนเงินอย่างครบถ้วน ข้อแตกต่างเพียงอย่างเดียวระหว่าง ERC20 และ ETH คือแต่ก่อนใช้ Gateway เราจะไม่อธิบายอย่างละเอียด
ผู้ใช้เรียกใช้ฟังก์ชันDepositETH() ของกล่องที่ช้า
ฟังก์ชั่นนี้จะยังคงเรียก 'bridge.enqueueDelayedMessage()' ต่อไป บันทึกข้อความในสัญญาบริดจ์ และส่ง ETH ไปยังสัญญาบริดจ์ เงินฝาก ETH ทั้งหมดจะถูกเก็บไว้ในสัญญาบริดจ์ ซึ่งเทียบเท่ากับที่อยู่การฝากเงิน
ซีเควนเซอร์จะตรวจสอบข้อความการฝากในกล่องที่ช้าและสะท้อนถึงการดำเนินการฝากไปยังฐานข้อมูล L2 ผู้ใช้สามารถดูสินทรัพย์ที่พวกเขาฝากไว้ในเครือข่าย L2
ตัวจัดลำดับจะรวมบันทึกเงินฝากไว้ในชุดธุรกรรม และส่งไปยังสัญญากล่องด่วนบน L1
ผู้ใช้เรียกใช้ฟังก์ชัน withdrawEth() ของสัญญา ArbSys บน L2 และหมายเลข ET ที่สอดคล้องกันจะถูกเบิร์นบน L2
ซีเควนเซอร์ส่งคำขอถอนเงินไปยังกล่องด่วน
โหนด Validator จะสร้าง Rollup Block ใหม่ตามลำดับธุรกรรมในกล่องด่วน ซึ่งจะมีธุรกรรมการถอนเงินข้างต้น
หลังจากที่ Rollup Block ผ่านช่วงเวลาท้าทายซึ่งได้รับการยืนยันแล้ว ผู้ใช้สามารถเรียกใช้ฟังก์ชัน Outbox.execute Transaction() บน L1 เพื่อพิสูจน์ว่าพารามิเตอร์ได้รับจากสัญญา ArbSys ที่กล่าวถึงข้างต้น
หลังจากที่สัญญากล่องจดหมายออกได้รับการยืนยันว่าถูกต้อง จำนวน ETH ที่เกี่ยวข้องในบริดจ์จะถูกปลดล็อคและส่งไปยังผู้ใช้
เมื่อใช้สะพานอย่างเป็นทางการของ Optimistic Rollup เพื่อถอนเงินสด จะมีปัญหาในการรอช่วงท้าทาย เราสามารถใช้สะพานข้ามสายโซ่ส่วนตัวของบุคคลที่สามเพื่อลบปัญหานี้:
ฟังก์ชัน Force Inclusion() ใช้เพื่อต้านทานการเซ็นเซอร์ของซีเควนเซอร์ ธุรกรรม L2 ในพื้นที่ ธุรกรรม L1 ถึง L2 และธุรกรรม L2 ถึง L1 สามารถดำเนินการได้โดยใช้ฟังก์ชันนี้ การเซ็นเซอร์ที่เป็นอันตรายของซีเควนเซอร์ส่งผลกระทบร้ายแรงต่อประสบการณ์การทำธุรกรรม ในกรณีส่วนใหญ่เราจะเลือกถอนเงินและออกจาก L2 ดังนั้น ข้อมูลต่อไปนี้จึงใช้การถอนแบบบังคับเป็นตัวอย่างเพื่อแนะนำการใช้งานของforceInclusion
เมื่อมองย้อนกลับไปที่ขั้นตอนการถอน ETH มีเพียงขั้นตอนที่ 1 และ 2 เท่านั้นที่เกี่ยวข้องกับการเซ็นเซอร์ซีเควนเซอร์ ดังนั้นจึงจำเป็นต้องเปลี่ยนเพียงสองขั้นตอนนี้เท่านั้น:
ผู้ใช้สามารถถอนเงินในกล่องจดหมายออกได้ และขั้นตอนที่เหลือจะเหมือนกับการถอนเงินปกติ
นอกจากนี้ ยังมีบทช่วยสอนโดยละเอียดเกี่ยวกับการใช้ Arb SDK ในบทช่วยสอนอนุญาโตตุลาการเพื่อเป็นแนวทางแก่ผู้ใช้เกี่ยวกับวิธีการดำเนินการธุรกรรม L2 ในพื้นที่และธุรกรรม L2 ถึง L1 ผ่านฟังก์ชัน forceInclusion()
ในบทความก่อนหน้านี้ “โครงสร้างส่วนประกอบของ Arbitrum ตีความโดยอดีตทูตด้านเทคนิคของ Arbitrum (ตอนที่ 1)” เราได้แนะนำบทบาทของส่วนประกอบสำคัญใน Arbitrum รวมถึงซีเควนเซอร์, เครื่องมือตรวจสอบ, สัญญากล่องจดหมายของซีเควนเซอร์, Rollup Block และบทบาทของ หลักฐานการฉ้อโกงแบบไม่โต้ตอบ ในบทความวันนี้ เราจะเน้นไปที่การอธิบายองค์ประกอบที่เกี่ยวข้องกับการส่งข้อความข้ามสายโซ่ และการเข้าสู่ธุรกรรมต่อต้านการเซ็นเซอร์ในองค์ประกอบหลักของ Arbitrum
ข้อความหลัก: ในบทความก่อนหน้านี้ เราได้กล่าวถึงสัญญา Sequencer Inbox ได้รับการออกแบบมาโดยเฉพาะเพื่อรับชุดข้อมูลธุรกรรมที่เผยแพร่โดยซีเควนเซอร์ในเลเยอร์ 1 ในเวลาเดียวกัน เราชี้ให้เห็นว่า Sequencer Inbox เรียกอีกอย่างว่า "fast box" และในทางตรงกันข้าม มี "slow box" หรือ Delayed Inbox (เรียกว่า Inbox) ด้านล่างนี้ เราจะให้การตีความโดยละเอียดขององค์ประกอบที่เกี่ยวข้องกับการส่งข้อความข้ามสายโซ่ รวมถึงกล่องขาเข้าที่ล่าช้า
ธุรกรรมข้ามสายโซ่สามารถแบ่งออกเป็นธุรกรรมจาก 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 วงจรชีวิตประกอบด้วยสามขั้นตอน:
นอกจากนี้ เกี่ยวกับกระบวนการถอนเงินบนสะพานอย่างเป็นทางการของ Arbitrum แม้ว่ากระบวนการจะมีความคล้ายคลึงกันแบบสมมาตรบางอย่างเมื่อเปรียบเทียบกับการฝากเงิน แต่ไม่มีแนวคิดในการลองตั๋วซ้ำ สิ่งนี้สามารถเข้าใจได้จากมุมมองของ Rollup Protocol เอง และสามารถเน้นความแตกต่างบางประการได้:
การผูกมัดข้ามสินทรัพย์ ERC-20 นั้นซับซ้อน เราสามารถคิดถึงคำถามหลายประการ:
เราจะไม่ตอบคำถามเหล่านี้ทั้งหมดเพราะมันซับซ้อนเกินกว่าจะเปิดเผย คำถามเหล่านี้ใช้เพื่ออธิบายความซับซ้อนของ cross-chain ERC20 เท่านั้น
ปัจจุบัน โซลูชันการปรับขนาดจำนวนมากใช้โซลูชันรายการที่อนุญาตและรายการด้วยตนเอง เพื่อหลีกเลี่ยงปัญหาที่ซับซ้อนและเงื่อนไขขอบเขตต่างๆ
Arbitrum ใช้ระบบ Gateway เพื่อแก้ปัญหาการติดขัดของ ERC20 cross-chain ส่วนใหญ่ มันมีคุณสมบัติดังต่อไปนี้:
ลองใช้ cross-chain ของ WETH ที่ค่อนข้างง่ายเป็นตัวอย่างเพื่อแสดงให้เห็นถึงความจำเป็นในการปรับแต่งเกตเวย์
WETH เทียบเท่ากับ ERC20 ของ ETH เนื่องจากเป็นสกุลเงินหลัก Ether จึงไม่สามารถใช้ฟังก์ชันที่ซับซ้อนใน dApps จำนวนมากได้ ดังนั้นจึงจำเป็นต้องมี ERC20 ที่เทียบเท่ากัน โอน ETH บางส่วนไปยังสัญญา WETH ซึ่งจะถูกล็อคไว้ในสัญญา และ WETH ในปริมาณเท่ากันจะถูกสร้างขึ้น
ในทำนองเดียวกัน สามารถเผา WETH และ ETH ก็สามารถถอนออกได้ แน่นอนว่าอัตราส่วนของการหมุนเวียน WETH และ ETH ที่ถูกล็อคจะเป็น 1:1 เสมอ
ถ้าเราโยง WETH ไปยัง 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 เป็นตัวอย่างเพื่ออธิบายขั้นตอนการฝากและถอนเงินอย่างครบถ้วน ข้อแตกต่างเพียงอย่างเดียวระหว่าง ERC20 และ ETH คือแต่ก่อนใช้ Gateway เราจะไม่อธิบายอย่างละเอียด
ผู้ใช้เรียกใช้ฟังก์ชันDepositETH() ของกล่องที่ช้า
ฟังก์ชั่นนี้จะยังคงเรียก 'bridge.enqueueDelayedMessage()' ต่อไป บันทึกข้อความในสัญญาบริดจ์ และส่ง ETH ไปยังสัญญาบริดจ์ เงินฝาก ETH ทั้งหมดจะถูกเก็บไว้ในสัญญาบริดจ์ ซึ่งเทียบเท่ากับที่อยู่การฝากเงิน
ซีเควนเซอร์จะตรวจสอบข้อความการฝากในกล่องที่ช้าและสะท้อนถึงการดำเนินการฝากไปยังฐานข้อมูล L2 ผู้ใช้สามารถดูสินทรัพย์ที่พวกเขาฝากไว้ในเครือข่าย L2
ตัวจัดลำดับจะรวมบันทึกเงินฝากไว้ในชุดธุรกรรม และส่งไปยังสัญญากล่องด่วนบน L1
ผู้ใช้เรียกใช้ฟังก์ชัน withdrawEth() ของสัญญา ArbSys บน L2 และหมายเลข ET ที่สอดคล้องกันจะถูกเบิร์นบน L2
ซีเควนเซอร์ส่งคำขอถอนเงินไปยังกล่องด่วน
โหนด Validator จะสร้าง Rollup Block ใหม่ตามลำดับธุรกรรมในกล่องด่วน ซึ่งจะมีธุรกรรมการถอนเงินข้างต้น
หลังจากที่ Rollup Block ผ่านช่วงเวลาท้าทายซึ่งได้รับการยืนยันแล้ว ผู้ใช้สามารถเรียกใช้ฟังก์ชัน Outbox.execute Transaction() บน L1 เพื่อพิสูจน์ว่าพารามิเตอร์ได้รับจากสัญญา ArbSys ที่กล่าวถึงข้างต้น
หลังจากที่สัญญากล่องจดหมายออกได้รับการยืนยันว่าถูกต้อง จำนวน ETH ที่เกี่ยวข้องในบริดจ์จะถูกปลดล็อคและส่งไปยังผู้ใช้
เมื่อใช้สะพานอย่างเป็นทางการของ Optimistic Rollup เพื่อถอนเงินสด จะมีปัญหาในการรอช่วงท้าทาย เราสามารถใช้สะพานข้ามสายโซ่ส่วนตัวของบุคคลที่สามเพื่อลบปัญหานี้:
ฟังก์ชัน Force Inclusion() ใช้เพื่อต้านทานการเซ็นเซอร์ของซีเควนเซอร์ ธุรกรรม L2 ในพื้นที่ ธุรกรรม L1 ถึง L2 และธุรกรรม L2 ถึง L1 สามารถดำเนินการได้โดยใช้ฟังก์ชันนี้ การเซ็นเซอร์ที่เป็นอันตรายของซีเควนเซอร์ส่งผลกระทบร้ายแรงต่อประสบการณ์การทำธุรกรรม ในกรณีส่วนใหญ่เราจะเลือกถอนเงินและออกจาก L2 ดังนั้น ข้อมูลต่อไปนี้จึงใช้การถอนแบบบังคับเป็นตัวอย่างเพื่อแนะนำการใช้งานของforceInclusion
เมื่อมองย้อนกลับไปที่ขั้นตอนการถอน ETH มีเพียงขั้นตอนที่ 1 และ 2 เท่านั้นที่เกี่ยวข้องกับการเซ็นเซอร์ซีเควนเซอร์ ดังนั้นจึงจำเป็นต้องเปลี่ยนเพียงสองขั้นตอนนี้เท่านั้น:
ผู้ใช้สามารถถอนเงินในกล่องจดหมายออกได้ และขั้นตอนที่เหลือจะเหมือนกับการถอนเงินปกติ
นอกจากนี้ ยังมีบทช่วยสอนโดยละเอียดเกี่ยวกับการใช้ Arb SDK ในบทช่วยสอนอนุญาโตตุลาการเพื่อเป็นแนวทางแก่ผู้ใช้เกี่ยวกับวิธีการดำเนินการธุรกรรม L2 ในพื้นที่และธุรกรรม L2 ถึง L1 ผ่านฟังก์ชัน forceInclusion()