ส่งต่อชื่อเรื่องเดิม:

บทความนี้ให้การตีความทางเทคนิคของ Arbitrum One โดย Luo Benben (罗奔奔), นักเอกชนชาวจีนเดิมของ Arbitrum และผู้ร่วมก่อตั้งเกอปลัส เซคิวริตี้ บริษัทตรวจสอบอัตโนมัติสัญญาอัจฉริยะ

เนื่องจากขาดความเชี่ยวชาญในการแปลภาษาของ Arbitrum และ แม้ว่า OP Rollup ในบทความหรือวัสดุที่เกี่ยวข้องกับ Layer 2 ในภาษาจีน บทความนี้พยายามเติมความว่างเป็นสาขานี้โดยการทำให้การดำเนินการของ Arbitrum รู้จักมากขึ้น โดยโครงสร้างของ Arbitrum เองมีความซับซ้อนเกินไป แม้ว่าข้อความทั้งหมดจะถูกกำหนดให้เรียบง่ายให้มากที่สุด แต่ยังเกิน 10,000 คำ ดังนั้นถูกแบ่งเป็นสองส่วน แนะนำให้เก็บรวบรวมและส่งต่อเป็นข้อมูลอ้างอิง!

การบรรยายสั้นๆเกี่ยวกับ Rollup sequencer

หลักการขยาย Rollup สามารถสรุปได้เป็นสองจุด:

การปรับปรุงต้นทุน: โอนภาระงานคำนวณและการจัดเก็บข้อมูลไปที่ offchain L1 ซึ่งหมายถึง L2 L2 เป็นโซ่ที่ใช้งานบนเซิร์ฟเวอร์เดียว กล่าวคือ ตัวจัดเรียง/ผู้ดำเนินการ

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

(Source: BNB Chain)

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

โดยพื้นฐานแล้วความปลอดภัยของ Rollup ขึ้นอยู่กับ Ethereum หากซีเควนเซอร์ไม่ทราบคีย์ส่วนตัวของบัญชี จะไม่สามารถเริ่มต้นธุรกรรมแทนบัญชีนั้นหรือแก้ไขยอดเงินสินทรัพย์ของบัญชีนั้นได้ (แม้ว่าจะพยายามก็จะถูกตรวจพบเร็วๆ)

แม้ว่าตัวเรียงลำดับ ในฐานะศูนย์กลางของระบบ อาจมีลักษณะที่เซ็นทรัลได้ ในโซลูชัน Rollup ที่เจริญแก่การใช้งานแล้ว ตัวเรียงลำดับที่เซ็นทรัลสามารถมีพฤติกรรมที่เป็นอันตรายอ่อนไหวเช่นการเซ็นเซอร์การทำธุรกรรมหรือการล้มเหลวอย่างมีประสิทธิภาพ อย่างไรก็ตาม ในโซลูชัน Rollup ที่เป็นไอเดีย จะมีมาตรการที่เกี่ยวข้องในการยับยั้งพฤติกรรมเช่นนั้น (เช่นการถอนบังคับหรือการเรียงลำดับพิสูจน์เป็นกลไกป้องกันการเซ็นเซอร์)

โปรโตคอล Loopring ตั้งฟังก์ชั่นการถอนบังคับในรหัสซอร์สของสัญญาบน L1 สำหรับผู้ใช้เรียกใช้

เพื่อป้องกันพฤติกรรมที่ไม่ดีจากผู้กำหนดลำดับ Rollup มีวิธีการยืนยันสถานะ 2 ประเภท: การพิสูจน์การทุจริตและการพิสูจน์ความถูกต้อง โซลูชัน Rollup ที่ใช้การพิสูจน์การทุจริตเรียกว่า Optimistic Rollup (OPR) ในขณะที่ผู้ใช้งานการพิสูจน์ความถูกต้องมักเรียกว่า ZK Rollup (Zero-knowledge Proof Rollup, ZKR) แทนการ Rollup ที่เรียกว่า Validity Rollup ด้วยเหตุผลทางประวัติศาสตร์

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

ดังนั้น OPR ยังหมายความว่ามีการสมมติความเชื่อ: มีอย่างน้อยหนึ่งโหนดตรวจสอบระดับ L2 ซื่อสุจริงอยู่เสมอ ในขณะเดียวกัน ZKR สัญญาสร้างความมั่นใจและตรวจสอบข้อมูลที่ถูกส่งโดยตัวจัดลำดับโดยราคาประหยัดผ่านการคำนวณทางเข็มข้น

(วิธีการดำเนินการ Optimistic Rollup)

(วิธีการใช้งาน ZK Rollup)

บทความนี้จะให้ข้อมูลที่ละเอียดเกี่ยวกับโครงการชั้นนำใน Optimistic Rollup — Arbitrum One ซึ่งครอบคลุมทุกด้านของระบบ หลังจากอ่านอย่างรอบคอบคุณจะได้ความเข้าใจอย่างลึกซึ้งเกี่ยวกับ Arbitrum และ Optimistic Rollup (OPR)

ส่วนประกอบหลักและขั้นตอนการทำงานของ Arbitrum:

Core Contracts:

สัญญาที่สำคัญที่สุดใน Arbitrum รวมถึง SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge, ฯลฯ ซึ่งจะถูกกล่าวถึงโดยละเอียดในภายหลัง

Sequencer:

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

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

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

จากระบบดังกล่าว เราสามารถสรุปได้ว่า Layer 2 มีเครือข่ายของโหนดของตัวเอง แต่โหนดเหล่านี้มีจำนวนไม่มากและขาดความเห็นรัฐที่ใช้กันอย่างแพร่หลายในบล็อกเชนสาธารณะ ดังนั้น ความปลอดภัยของพวกเขาไม่ดี และพวกเขาต้องพึ่งพา Ethereum เพื่อให้มั่นใจในความเชื่อถือได้ของการเผยแพร่ข้อมูลและความถูกต้องของการเปลี่ยนสถานะ

โปรโตคอล Arbitrum Rollup:

กำหนดโครงสร้างของบล็อกที่เรียกว่า RBlocks บนเชน Rollup การดำเนินต่อของเชนการเผยแพร่ของ RBlocks และกระบวนการโหวตอุทธรณ์ ฯลฯ ผ่านชุดของสัญญา สำคัญที่จะระบุว่าเชน Rollup ที่กล่าวถึงที่นี่ไม่ใช่ ledger ที่เข้าใจกันทั่วไปเป็น Layer 2 แต่เป็นโครงสร้างข้อมูลแบบเชนแบบนามธรรมที่ตั้งอิสระโดย Arbitrum One เพื่อการใช้กลไกการพิสูจน์การทุจริต

บล็อก R สามารถมีข้อมูลจากบล็อก L2 หลายรายการและตัวแทนข้อมูล RBlock จะถูกเก็บไว้ในลำดับของสัญญาภายใน RollupCore หากมีปัญหากับบล็อก R ผู้ตรวจสอบจะท้าทายโดยใช้ข้อมูลที่เป็นผลลัพธ์จากผู้สร้างบล็อก RBlock

ผู้ตรวจสอบความถูกต้อง:

Validators in Arbitrum are actually a special subset of Layer 2 full nodes, currently with whitelist admission.

Validators สร้าง RBlocks ใหม่ (บล็อก Rollup, ที่เรียกว่า assertions ด้วย) โดยอิงจากกลุ่มของธุรกรรมที่ถูกส่งเข้าสู่สัญญา SequencerInbox โดยตัวเรียงและตรวจสอบสถานะปัจจุบันของ RBlocks chain เพื่อท้าทายข้อมูลที่ถูกส่งเข้ามาอย่างไม่ถูกต้องโดยตัวเรียง

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

Challenge:

ขั้นตอนพื้นฐานสามารถสรุปได้เป็นการแบ่งส่วนแบ่งส่วนแบบหลายรอบและการพิสูจน์แบบหนึ่งขั้นตอน ในช่วงแบ่งส่วน ทั้งสองฝ่ายต้องมีการแบ่งส่วนแบบหลายรอบของข้อมูลธุรกรรมที่มีปัญหาจนถึงคำสั่ง opcode ที่มีปัญหาถูกแยกและตรวจสอบว่าถูกต้อง โดยนักพัฒนา Arbitrum พิจารณาว่ารูปแบบ "การแบ่งส่วนแบบหลายรอบ-การพิสูจน์แบบหนึ่งขั้นตอน" เป็นวิธีที่ดีที่สุดในการป้องกันการโกงโดยมีการใช้แก๊สมากที่สุด ขั้นตอนทั้งหมดถูกควบคุมโดยสัญญาอัจฉริยะและไม่มีฝ่ายใดๆ สามารถโกงได้

ระยะเวลาท้าทาย:

เนื่องจากลักษณะในแง่ดีของ OP Rollup หลังจากส่ง RBlock แต่ละรายการไปยังห่วงโซ่สัญญาจะไม่ตรวจสอบอย่างแข็งขันทําให้ผู้ตรวจสอบความถูกต้องปลอมแปลงเป็นระยะเวลาหนึ่ง กรอบเวลานี้เป็นช่วงเวลาท้าทาย, ซึ่งเป็นหนึ่งสัปดาห์บน Arbitrum One mainnet. หลังจากระยะเวลาการท้าทายสิ้นสุดลง RBlock จะได้รับการยืนยันในที่สุดและสามารถเผยแพร่ข้อความที่สอดคล้องกับธุรกรรมจาก L2 ถึง L1 (เช่นการดําเนินการถอนเงินที่ดําเนินการผ่านบริดจ์อย่างเป็นทางการ)

ArbOS, Geth, WAVM：

Arbitrum uses a virtual machine called AVM, which consists of Geth and ArbOS. Geth is the most commonly used client software for Ethereum, and Arbitrum has made lightweight modifications to it. ArbOS is responsible for all L2-related special functions, such as network resource management, generating L2 blocks, and working in coordination with EVM. We consider the combination of both as a Native AVM, which is the virtual machine used by Arbitrum. WAVM is the result of compiling AVM code into Wasm. In the Arbitrum challenge process, the final “single-step proof” verifies WAVM instructions.

ที่นี่เราสามารถแสดงความสัมพันธ์และเวิร์กโฟลว์ระหว่างส่วนประกอบต่างๆโดยใช้แผนภาพด้านล่าง:

วงจรชีวิตการทำธุรกรรม L2

กระแสการประมวลผลของธุรกรรม L2 คือดังนี้:

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

Sequencer Inbox Contract

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

ในบุคลากรสมมติฐาน สิ่งที่เราเห็นว่า L2 นั้นเป็นเพียงการโปรเจกชันของชุดในกล่องจัดลำดับ ในขณะที่แหล่งแสงเป็น Soft Finality โดยที่แหล่งแสง Soft Finality ไม่เปลี่ยนแปลงได้ง่าย รูปร่างของเงาถูกกำหนดโดยเพียงชุดที่ทำหน้าที่เป็นวัตถุเท่านั้น

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

Validators จะตรวจสอบอย่างต่อเนื่องในสัญญากล่องจดหมาย Sequencer ทุกครั้งที่ตัวเรียงลำดับเผยแพร่กลุ่มข้อมูลไปยังสัญญานี้ จะเกิดเหตุการณ์บนเชนขึ้น เมื่อตรวจพบเหตุการณ์นี้ ผู้ตรวจสอบจะดาวน์โหลดข้อมูลกลุ่ม ดำเนินการด้วยตนเองและตัวเรียงลำดับจากนั้นเผยแพร่ RBlock ไปยังสัญญาโปรโตคอล Rollup บนเชน Ethereum

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

(ตัวเรียงส่งชุดคำตอบไปยังกล่องจดหมายของตัวเรียงอย่างต่อเนื่อง)

(ข้อมูลเฉพาะของชุดข้อมูล ฟิลด์ข้อมูลสอดคล้องกับข้อมูลชุดข้อมูล ขนาดของข้อมูลส่วนนี้มีขนาดใหญ่มากและภาพหน้าจอไม่ได้แสดงทั้งหมด)

สัญญา SequencerInbox มีฟังก์ชันหลักสองฟังก์ชัน

เพิ่ม Sequencer L2Batch จาก Origin() ตัวจัดเรียงจะเรียกฟังก์ชันนี้ทุกครั้งเพื่อส่งข้อมูล Batch ไปยังสัญญา Sequencer Inox

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

ฟังก์ชันทั้งสองด้านบนจะเรียกใช้ "bridge.enqueueSequencerMessage()" เพื่ออัพเดทพารามิเตอร์สะสม accumulator ในสัญญาสะพาน

การกำหนดราคาก๊าซ

โดยอย่างชัดเจน ธุรกรรม L2 ไม่สามารถเป็นฟรีได้ เนื่องจากนี้จะทำให้เกิดการโจมตี DoS อีกทั้งยังมีค่าใช้จ่ายในการดำเนินการสำหรับตัวจัดลำดับ L2 เอง และจะมีค่าใช้จ่ายเพิ่มเติมสำหรับการส่งข้อมูลใน L1 เมื่อผู้ใช้เริ่มต้นทำธุรกรรมในเครือข่าย Layer 2 โครงสร้างค่า Gas มีดังนี้:

ค่าใช้จ่ายในการเผยแพร่ข้อมูลที่สร้างโดยการเรียกใช้ทรัพยากร Layer1 มากที่สุดมาจากชุดที่ถูกส่งโดย sequencer (แต่ละชุดประกอบด้วยธุรกรรมจากผู้ใช้หลายคน) และค่าใช้จ่ายจะถูกแบ่งปันในที่สุดระหว่างผู้เริ่มธุรกรรม อัลกอริทึมการกำหนดราคาสำหรับค่าธรรมเนียมการทำธุรกรรมที่เกิดจากการเผยแพร่ข้อมูลเป็นไปได้ Sequencer ปรับราคาโดยขึ้นอยู่กับเงินกำไรและขาดทุนล่าสุด ขนาดชุด และราคาก๊าส Ethereum ปัจจุบัน

ค่าใช้จ่ายที่ผู้ใช้ต้องจ่ายสำหรับการใช้ทรัพยากร Layer2 จะถูกกำหนดโดยการตั้งขีดจำกัดสูงสุดในการประมวลผลแก๊สต่อวินาทีเพื่อให้มั่นใจว่าระบบจะทำงานอย่างมีความเสถียร (ในปัจจุบัน Arbitrum One คือ 7 ล้าน) ราคาแนะนำของแก๊สสำหรับทั้ง L1 และ L2 ถูกติดตามและปรับเปลี่ยนโดย ArbOS และสูตรไม่ได้ถูกอธิบายที่นี่

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

หลักฐานการทุจริตในแง่ดี

เมื่อมองกลับไปที่ข้อความก่อนหน้า จะเห็นได้ว่า Layer2 (L2) พื้นที่เชิงร่างกายที่สำคัญก็คือการโปรเจคชันของชุดข้อมูลนำเข้าธุรกรรมที่ถูกส่งโดยตัวเรียงลำดับในกล่องจดหมายของตัวเรียงลำดับ:

ข้อมูลนำเข้าธุรกรรม -> ฟังก์ชันการเปลี่ยนสถานะ (STF) -> ผลลัพธ์ของสถานะ

อินพุตถูกกําหนดแล้วและ STF ไม่สามารถเปลี่ยนแปลงได้ดังนั้นผลลัพธ์เอาต์พุตจะถูกกําหนดด้วย หลักฐานการทุจริตและระบบโปรโตคอล Arbitrum Rollup เผยแพร่สถานะเอาต์พุตซึ่งแสดงโดย RBlock (หรือที่เรียกว่าการยืนยัน) ไปยัง Layer1 และให้หลักฐานในแง่ดีสําหรับมัน

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

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

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

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

ดังนั้น หากเราสร้าง Rollup โดยไม่มีฟังก์ชันการถอน ทฤษฎีของมันก็สามารถที่จะไม่ซิงโครไนซ์สถานะกับ L1 ได้ และไม่จำเป็นต้องมีระบบพิสูจน์สถานะ เช่นพิสูจน์การทุจริต (แม้ว่าอาจทำให้เกิดปัญหาอื่นๆ) แต่ในการใช้งานจริง ๆ นี้ ก็ชัดเจนว่าไม่สามารถทำได้

ในพิสูจน์ที่เรียกว่าเต็มไปด้วยความหวัง สัญญาไม่ตรวจสอบว่าสถานะเอาท์พุทที่ส่งไปยัง L1 ถูกต้องหรือไม่ แต่มีความหวังว่าทุกอย่างถูกต้อง ระบบพิสูจน์ที่เต็มไปด้วยความหวังสมมติว่ามี Validator คนซื่อสัตย์อย่างน้อยหนึ่งคนเสมอ หากเกิดสถานะที่ไม่ถูกต้อง จะถูกท้าทายผ่านพิสูจน์การปลอม

ข้อดีของการออกแบบนี้คือไม่จำเป็นต้องยืนยัน RBlock ที่ออกให้กับ L1 ทุกอันโดยใช้แก๊สอย่างมีความเชื่อมั่น ในความเป็นจริงสำหรับ OPR มันเป็นสิ่งที่ไม่เป็นจริงที่จะต้องการยืนยันข้อความทุกอย่างเพราะทุก Rblock ประกอบด้วยบล็อก L2 หรือมากกว่าหนึ่งบล็อก L2 และทุกธุรกรรมจะต้องถูกดำเนินการใหม่ใน L1 มันไม่ต่างจากการดำเนินธุรกรรม L2 โดยตรงบน L1 ซึ่งเสียความหมายของการขยายขอบของชั้นที่ 2

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

แม้ว่าการพิสูจน์การทุจริตไม่สามารถบรรยายระดับสูงเท่ากับการพิสูจน์ที่ไม่มีความรู้ใด ๆ แต่ Arbitrum ใช้กระบวนการจำลอง “multi-round subdivision - single-step proof” ที่เป็นกระบวนการแบบโต้ตอบ โดยที่เกือบทั้งหมดจะต้องพิสูจน์เพียงแค่เพียง opcode ของเครื่องจำลองเท่านั้น ซึ่งส่งผลให้มีค่าใช้จ่ายที่ต่ำลง

โปรโตคอล Rollup

เรามาดูที่ทางเข้าก่อนเพื่อเริ่มท้าทายและเริ่มพิสูจน์กัน นั่นคือว่าโปรโตคอล Rollup ทำงานอย่างไร

สัญญาหลักของโปรโตคอล Rollup คือ RollupProxy.sol โดยใช้โครงสร้างข้อมูลที่เหมือนกัน โครงสร้าง Dual Agent ที่หายากใช้สำหรับตัวแทนหนึ่งที่สอดคล้องกับการประมวลผลของ RollupUserLogic.sol และ RollupAdminLogic.sol ซึ่งไม่สามารถแยกแยะได้ดีโดยเครื่องมือเช่น Scan

นอกจากนี้ สัญญา ChallengeManager.sol รับผิดชอบการจัดการความท้าทาย และสัญญาชุด OneStepProver ถูกใช้ในการกำหนดพิสูจน์การฉ้อโกง

(Source: เว็บไซต์อย่างเป็นทางการของ L2BEAT)

ใน RollupProxy, ชุดของ RBlocks (ที่เรียกว่า assertions โดยผู้ตรวจสอบหลายคน) ที่ถูกส่งมาโดยผู้ตรวจสอบที่แตกต่างกันถูกบันทึกแทนด้วยบล็อกในแผนภาพ: สีเขียวสำหรับการยืนยัน, สีน้ำเงินสำหรับการยืนยันไม่ได้, และสีเหลืองสำหรับการปฏิเสธ

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

เพื่อเสนอหรือยอมรับข้อความ ผู้ตรวจสอบจำเป็นต้องเป็นเจ้าของจำนวน ETH ที่แน่นอน ซึ่งจะกลายเป็น Staker ซึ่งนี้จะทำให้มั่นใจได้ว่าจะมีพื้นฐานเศรษฐศาสตร์สำหรับพฤติกรรมที่ซื่อสัตย์ในหมวดของผู้ตรวจสอบ โดยที่ผู้แพ้จะต้องสละสิทธิ์ในกรณีที่มีการท้าทายหรือหลักฐานการทุจริต

บล็อกสีฟ้าที่มีหมายเลข 111 ที่มุมล่างขวาของแผนภูมิจะถูกพิสูจน์ว่าไม่ถูกต้องในที่สุดเพราะบล็อกที่เป็นพ่อแม่ คือ บล็อกหมายเลข 104 ไม่ถูกต้อง (สีเหลือง)

นอกจากนี้ Validator A ได้เสนอ Rollup Block 106 ซึ่ง Validator B ไม่เห็นด้วยและท้าทาย

หลังจากที่ B เริ่มเรียกความท้าทาย สัญญา ChallengeManager มีหน้าที่ตรวจสอบการแบ่งส่วนของขั้นตอนท้าทาย

1. การแบ่งส่วนเป็นกระบวนการที่สองฝ่ายเข้ามาทำงานร่วมกัน ฝ่ายหนึ่งแบ่งส่วนข้อมูลประวัติศาสตร์ที่อยู่ในบล็อก Rollup บางอย่าง และอีกฝ่ายชี้แจงส่วนใดของข้อมูลเสี้ยงปัญหา กระบวนการที่คล้ายกับการแยกชั้น (ซึ่งจริงๆแล้ว N/K) ที่ยังเล็กลงเรื่อยๆ และเรียงลำดับขอบเขต

2. ต่อมาจะสามารถระบุได้อีกว่าธุรกรรมและผลลัพธ์ของมันมีปัญหาอย่างไร จากนั้นแบ่งแยกต่อไปเพื่อหาคำสั่งของเครื่องที่เฉพาะเจาะจงภายในธุรกรรมนั้นที่ถูกโต้แย้ง

3. สัญญา ChallengeManager จะตรวจสอบว่า "กลุ่มข้อมูล" ที่สร้างขึ้นหลังจากแบ่งย่อยข้อมูลต้นฉบับนั้นถูกต้องหรือไม่

4. เมื่อฝ่ายท้าทายและฝ่ายถูกท้าทายระบุคำสั่งเครื่องที่ต้องการท้าทาย ฝ่ายท้าทายเรียกใช้ oneStepProveExecution() เพื่อส่งพิสูจน์การฉ้อโกงขั้นตอนเดียว โดยแสดงให้เห็นว่าผลการดำเนินการของคำสั่งเครื่องนี้ไม่ถูกต้อง

การพิสูจน์ในขั้นตอนเดียว

Single-step proof is the core of the entire Arbitrum fraud proof. Let’s take a look at what the single-step proof specifically proves.

นี่ต้องการความเข้าใจ WAVM ก่อน Wasm Arbitrum Virtual Machine เป็นเครื่องจำลองที่คอมไพล์โดยโมดูล ArbOS และโมดูลหลักของ Geth (Ethereum client) ตั้งแต่ L2 แตกต่างมากจาก L1 โมดูลหลักของ Geth ต้นฉบับจึงต้องปรับเปลี่ยนเล็กน้อยและทำงานร่วมกับ ArbOS

ดังนั้น การเปลี่ยนสถานะบน L2 นั้นจริง ๆ แล้วเป็นผลงานร่วมระหว่าง ArbOS+Geth Core

โปรแกรมประมวลผลของ Arbitrum's node client (sequencer, validator, full node, etc.) จะคอมไพล์โปรแกรม ArbOS+Geth Core ดังกล่าวเป็นรหัสเครื่องเข้าที่เฉพาะสำหรับโฮสต์โหนดที่สามารถประมวลผลโดยตรง (สำหรับ x86/ARM/PC/Mac/etc.)

หากคุณเปลี่ยนภาษาเป้าหมายที่ได้หลังจากคอมไพล์เป็น Wasm คุณจะได้ WAVM ที่ใช้โดยตรวจสอบเมื่อสร้างพิสูจน์การฉ้อโกง และสัญญาเพื่อตรวจสอบพิสูจน์ขั้นตอนเดียวยังจำลองฟังก์ชันของเครื่องจำลอง WAVM ด้วย

ดังนั้นทำไมจึงจำเป็นต้องคอมไพล์เป็น Wasm bytecode เมื่อสร้างการพิสูจน์การทุจริต? เหตุผลหลักคือต้องใช้สัญญาของการพิสูจน์การทุจริตขั้นตอนเดียว จำเป็นต้องใช้สัญญาอัจฉริยะ Ethereum เพื่อจำลองเครื่องจำลองเสมือนเสมือนเครื่องจำลอง VM ที่สามารถจัดการกับชุดคำสั่งบางชุด และ WASM ง่ายต่อการจำลองบนสัญญา

อย่างไรก็ตาม WASM ทำงานช้ากว่ารหัสเครื่องเชื่อมต่อธรรมชาติเล็กน้อย ดังนั้นโหนด/สัญญาของ Arbitrum จะใช้ WAVM เท่านั้นเมื่อสร้างและตรวจสอบพิสูจน์การประพฤติอันไม่ดี

หลังจากรอบก่อนหน้าของการแบ่งส่วนแบบโต้ตอบ การพิสูจน์ขั้นตอนเดียวสุดท้ายได้พิสูจน์คำสั่งขั้นตอนเดียวในชุดคำสั่ง WAVM

ตามที่เห็นในรหัสด้านล่าง OneStepProofEntry ก่อนที่จะเรียกใช้ prover ที่เกี่ยวข้อง เช่น Mem, Math, เป็นต้น เพื่อส่งคำสั่งขั้นตอนเดียวเข้าสู่สัญญา prover

ผลลัพธ์สุดท้ายหลังจากการแฮชจะถูกส่งกลับไปยัง ChallengeManager หากแฮชไม่สอดคล้องกับแฮชหลังจากการดำเนินการคำสั่งที่บันทึกบน Rollup Block แสดงว่าการท้าทายเป็นประสบความสำเร็จ หากพวกเขาสอดคล้องกันแสดงว่าไม่มีปัญหากับผลการดำเนินการของคำสั่งนี้ที่บันทึกบน Rollup Block และการท้าทายล้มเหลว

ข้อความปฏิเสธความรับผิดชอบ：

1. บทความนี้ถูกคัดลอกมาจาก [GateGeek Web3], All copyrights belong to the original author [Luo Benben, นายทะเลทรัพย์เก่าของ Arbitrum, ผู้มีความเชี่ยวชาญด้านเทคนิค, ผู้มีส่วนร่วมใน web3]. หากมีข้อบกพร่องต่อการพิมพ์ฉบับนี้ โปรดติดต่อGate Learnทีม และพวกเขาจะดำเนินการโดยเร็ว
2. คำประกาศความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่เป็นที่สร้างสรรค์ของคำแนะนำในการลงทุนใดๆ
3. การแปลบทความเป็นภาษาอื่นๆ โดยทีม Gate Learn จะดำเนินการ การคัดลอก การกระจาย หรือการลอกเลียนบทความที่ถูกแปลถ้าไม่ได้ระบุไว้ ถือเป็นการละเมิดกฏหมาย