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

ภาพรวมของซีเควนเซอร์สะสม

หลักการของมาตราส่วน Rollup สามารถสรุปได้เป็นสองประเด็น:

การเพิ่มประสิทธิภาพต้นทุน: โอนงานการคำนวณและการจัดเก็บส่วนใหญ่ไปยังเลเยอร์ 2 ซึ่งดำเนินการภายใต้ L1 L2 ส่วนใหญ่ทำงานบนเซิร์ฟเวอร์เดียว เรียกว่าซีเควนเซอร์/โอเปอเรเตอร์ โดยสร้างสายโซ่ที่แยกจากกัน

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

(ที่มา: เครือ BNB)

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

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

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

(โปรโตคอล Loopring ตั้งค่าฟังก์ชันการถอนแบบบังคับในซอร์สโค้ดสัญญาบน L1 เพื่อให้ผู้ใช้สามารถโทรได้)

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

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

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

(วิธีดำเนินการสะสมในแง่ดี)

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

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

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

สัญญาหลัก:

สัญญาที่สำคัญที่สุดใน Arbitrum ได้แก่ SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge เป็นต้น สิ่งเหล่านี้จะมีรายละเอียดในส่วนต่อไปนี้

ซีเควนเซอร์:

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

ในขณะเดียวกัน ซีเควนเซอร์จะออกอากาศ L2 Block ที่สร้างขึ้นล่าสุดทันทีภายใต้ Ethereum off-chain โหนด Layer2 ใดๆ สามารถรับบล็อก L2 เหล่านี้ได้แบบอะซิงโครนัส อย่างไรก็ตาม บล็อก L2 เหล่านี้ยังไม่มีจุดสิ้นสุด ณ จุดนี้ และสามารถย้อนกลับได้โดยซีเควนเซอร์

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

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

โปรโตคอลการยกเลิกอนุญาโตตุลาการ:

นี่คือชุดสัญญาที่กำหนดโครงสร้างของบล็อก RBlock ของ Rollup chain วิธีการต่อเนื่องของ chain การเปิดตัว RBlock และกระบวนการโหมดท้าทาย โปรดทราบว่า Rollup chain ที่กล่าวถึงในที่นี้ไม่ใช่บัญชีแยกประเภท Layer 2 ที่ทุกคนเข้าใจ แต่เป็น "โครงสร้างข้อมูลแบบลูกโซ่" แบบนามธรรมที่ตั้งค่าโดย Arbitrum One อย่างอิสระเพื่อใช้กลไกป้องกันการฉ้อโกง

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

เครื่องมือตรวจสอบ:

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

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

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

ท้าทาย:

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

ช่วงเวลาท้าทาย:

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

ArbOS, เก็ท, WAVM：

เครื่องเสมือนที่ใช้โดย Arbitrum เรียกว่า AVM ซึ่งรวมถึง Geth และ ArbOS Geth เป็นซอฟต์แวร์ไคลเอนต์ที่ใช้กันมากที่สุดใน Ethereum และ Arbitrum ได้ทำการปรับเปลี่ยนเล็กน้อย ArbOS รับผิดชอบฟังก์ชันพิเศษทั้งหมดที่เกี่ยวข้องกับ L2 เช่น การจัดการทรัพยากรเครือข่าย การสร้างบล็อก L2 การทำงานกับ EVM เป็นต้น เราถือว่าการรวมกันของทั้งสองเป็น Native AVM ซึ่งเป็นเครื่องเสมือนที่ Arbitrum ใช้ WAVM เป็นผลมาจากการรวบรวมโค้ด AVM ลงใน Wasm ในกระบวนการท้าทาย Arbitrum “การพิสูจน์ขั้นตอนเดียว” สุดท้ายจะตรวจสอบคำสั่ง WAVM

ที่นี่ เราสามารถใช้รูปต่อไปนี้เพื่อแสดงความสัมพันธ์และขั้นตอนการทำงานระหว่างส่วนประกอบข้างต้น:

วงจรชีวิตของธุรกรรมบน L2

ขั้นตอนการประมวลผลของธุรกรรมบน L2 เป็นดังนี้:

1. ผู้ใช้ส่งคำแนะนำการซื้อขายไปยังซีเควนเซอร์

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

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

4. ซีเควนเซอร์จะบีบอัดข้อมูลธุรกรรมดั้งเดิมที่ประมวลผลไว้ล่วงหน้าในระดับสูง และสรุปเป็นแบทช์

5. ในบางครั้ง (ได้รับผลกระทบจากปัจจัยต่างๆ เช่น ปริมาณข้อมูลและความแออัดของ ETH) ซีเควนเซอร์จะเผยแพร่ชุดธุรกรรมไปยังสัญญา Sequencer Inbox บน L1 ณ จุดนี้ ถือได้ว่าธุรกรรมมี Hard Finality

สัญญากล่องจดหมายของซีเควนเซอร์

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

เพื่อให้เข้าใจในลักษณะทางกายภาพ L2 ที่เราเห็นเป็นเพียงการฉายภาพชุดใน SequencerInbox และแหล่งกำเนิดแสงคือ STF เนื่องจาก STF ของแหล่งกำเนิดแสงไม่เปลี่ยนแปลงได้ง่าย รูปร่างของเงาจึงถูกกำหนดโดยชุดที่ทำหน้าที่เป็นวัตถุเท่านั้น

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

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

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

（ซีเควนเซอร์จะส่งแบทช์ไปยังกล่องจดหมายของซีเควนอย่างต่อเนื่อง)

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

สัญญา SequencerInbox มีหน้าที่หลัก 2 ประการ:

เพิ่ม Sequencer L2Batch จาก Origin()

ซีเควนเซอร์จะเรียกใช้ฟังก์ชันนี้ทุกครั้งเพื่อส่งข้อมูลแบทช์ไปยังสัญญา Sequencer Inox

บังคับให้รวม ()

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

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

ราคาก๊าซ

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

ค่าใช้จ่ายในการเผยแพร่ข้อมูลที่เกิดขึ้นจากการครอบครองทรัพยากร Layer1

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

ต้นทุนที่เกิดขึ้นโดยผู้ใช้ที่ครอบครองทรัพยากรเลเยอร์ 2

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

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

หลักฐานการฉ้อโกงในแง่ดี

เมื่อนึกถึงข้างต้น L2 เป็นเพียงการฉายภาพของชุดอินพุตธุรกรรมที่ส่งโดยซีเควนเซอร์ในกล่องด่วน นั่นคือ:

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

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

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

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

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

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

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

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

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

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

แม้ว่าการพิสูจน์การฉ้อโกงไม่สามารถสรุปได้กระชับเท่ากับการพิสูจน์ความรู้เป็นศูนย์ แต่ Arbitrum ใช้กระบวนการโต้ตอบแบบผลัดกัน "หลายรอบของการแบ่งส่วน-การพิสูจน์ในขั้นตอนเดียว" ท้ายที่สุด สิ่งที่ต้องพิสูจน์ก็คือรหัสการทำงานของเครื่องเสมือนเพียงรหัสเดียว และค่าใช้จ่ายก็ค่อนข้างน้อย

โปรโตคอลการสะสม

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

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

นอกจากนี้ สัญญา ChallengeManager.sol ยังรับผิดชอบในการจัดการความท้าทาย และใช้สัญญาชุด OneStepProver เพื่อพิจารณาหลักฐานการฉ้อโกง

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

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

RBlock ประกอบด้วยสถานะสุดท้ายหลังจากการดำเนินการของบล็อก L2 ตั้งแต่หนึ่งบล็อกขึ้นไปนับตั้งแต่ RBlock ครั้งล่าสุด RBlocks เหล่านี้ก่อให้เกิด Rollup Chain อย่างเป็นทางการ (โปรดทราบว่าบัญชีแยกประเภท L2 นั้นแตกต่างออกไป) ภายใต้สถานการณ์ในแง่ดี Rollup Chain นี้ไม่ควรมีการ fork เนื่องจากการ fork หมายความว่า Validator ได้ส่ง Rollup Blocks ที่ขัดแย้งกัน

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

บล็อกสีน้ำเงินหมายเลข 111 ที่มุมขวาล่างของภาพจะถูกเฉือนในที่สุดเนื่องจากบล็อกหลักหมายเลข 104 (สีเหลือง) ไม่ถูกต้อง

นอกจากนี้ ผู้ตรวจสอบ A ที่เสนอ Rollup Block หมายเลข 106 แต่ B ไม่เห็นด้วยและท้าทายมัน

หลังจากที่ B เริ่มต้นการท้าทาย สัญญา ChallengeManager จะรับผิดชอบในการตรวจสอบการแบ่งส่วนของขั้นตอนการท้าทาย:

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

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

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

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

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

การพิสูจน์ขั้นตอนเดียวคือหัวใจหลักของการพิสูจน์การฉ้อโกงโดยอนุญาโตตุลาการทั้งหมด เรามาดูกันว่าหลักฐานขั้นตอนเดียวพิสูจน์อะไรได้บ้าง

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

ดังนั้นการเปลี่ยนสถานะบน L2 จึงเป็นการทำงานร่วมกันของ ArbOS+Geth Core

โหนดไคลเอ็นต์ของ Arbitrum (ซีเควน ตัวตรวจสอบ โหนดเต็ม ฯลฯ) รวบรวมโปรแกรมประมวลผล ArbOS+Geth Core ที่กล่าวถึงข้างต้นเป็นโค้ดเครื่องเนทิฟที่โฮสต์โหนดสามารถประมวลผลได้โดยตรง (สำหรับ x86/ARM/PC/Mac/etc )

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

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

อย่างไรก็ตาม WASM ทำงานช้ากว่ารหัสเครื่อง Native เล็กน้อย ดังนั้นโหนด/สัญญาของ Arbitrum จะใช้ WAVM เมื่อสร้างและตรวจสอบหลักฐานการฉ้อโกงเท่านั้น

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

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

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

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

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

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