ชื่อเดิม: "การวิเคราะห์เชิงลึกเกี่ยวกับกลไกการรักษาความปลอดภัยของอนุญาโตตุลาการ"

ที่มา | Hackernoon

ผู้เขียน | เดอเกต

โซลูชันการขยายเลเยอร์ 2 เป็นประเด็นร้อนในชุมชน Ethereum ในปัจจุบัน และยังเป็นประเด็นร้อนที่ถูกกล่าวถึงในชุมชนเทคโนโลยีบล็อกเชนทั้งหมด Arbitrum จาก Optimistic Rollups ปัจจุบันเป็นหนึ่งในโซลูชันการขยายเลเยอร์ 2 ที่น่าสนใจที่สุด เป็นรายแรกที่ปรับใช้ mainnet รุ่นเบต้า และได้รับการสนับสนุนจากโครงการ DeFi หลัก เช่น Uniswap และ Compound

ชื่อเรื่องรอง

มีรากฐานมาจากความปลอดภัยของ Ethereum

อย่างที่เราทราบกันดีว่า ข้อได้เปรียบที่ใหญ่ที่สุดของโซลูชัน Layer 2 เมื่อเทียบกับโซลูชันการขยายอื่น ๆ คือ ความปลอดภัยนั้นขึ้นอยู่กับการรักษาความปลอดภัยของ Ethereum mainnet อย่างไรก็ตาม คนส่วนใหญ่อาจรู้ความจริงนี้ แต่พวกเขาไม่รู้ว่าทำไม Arbitrum มีรากฐานมาจากความปลอดภัยของ Ethereum อย่างไร?

ก่อนอื่น เรามาทบทวนคุณสมบัติหลักของโซลูชัน Optimistic Rollup:

• ในโซลูชัน Rollup ธุรกรรม (เป็น calldata) จะเขียนบน L1 แต่การคำนวณจริงและการจัดเก็บสัญญาจะทำบน L2 สำหรับการปรับขนาด

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

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

ความพร้อมใช้งานของข้อมูล

ความพร้อมใช้งานของข้อมูล

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

AnyTrust

กลไกทางออกฉุกเฉิน

กลไกทางออกฉุกเฉิน

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

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

ประการที่สอง ผู้ใช้สามารถส่งคำขอการทำธุรกรรมไปยังสัญญากล่องจดหมายบน L1 เพื่อบังคับให้ออก

สุดท้าย กลไก AnyTrust ช่วยให้มั่นใจได้ว่าผู้ใช้สามารถบังคับให้ L2 จัดการกับธุรกรรมการออกได้อย่างเหมาะสม

ชื่อเรื่องรอง

ทำไมระยะเวลาท้าทายถึงเจ็ดวัน

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

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

ทีมอนุญาโตตุลาการเสนอแบบจำลองนี้เพื่อคำนวณระยะเวลาท้าทายที่เหมาะสมที่สุด:

• สมมติว่าระยะเวลาท้าทายเท่ากับความยาวของบล็อก C และค่าสูงสุดที่ผู้โจมตีจะได้รับใน L2 คือ V

จากนั้นค่าที่คาดว่าผู้โจมตีจะได้รับคือ V exp(-AC)

หมายเหตุ: exp คือฟังก์ชันเอกซ์โปเนนเชียล "e" A คือค่าคงที่ A และสัญลักษณ์ "-" ก่อน AC แสดงว่า C แปรผกผันกับผลตอบแทนที่คาดไว้

• ผู้ยืนยันต้องรับประกันว่าทรัพย์สินของตนจะมีมูลค่าเกินกว่ามูลค่าของการโจมตีเพื่อรับมือกับการโจมตี สมมติว่ามากกว่า 10 ครั้ง ราคาของผู้ยืนยันคือ 10V exp(-AC)I ฉันหมายถึงอัตราทุน

• เราถือว่าเนื้อหาการถอนที่ถูกล็อคโดยผู้ใช้ที่ออกจากระบบในระหว่างช่วงเวลาท้าทายคือ CWV (W เป็นทศนิยม WV เป็นส่วนหนึ่งของสินทรัพย์ทั้งหมดใน L2 และจะมี C บล็อกความท้าทายที่ยังไม่เสร็จในแต่ละช่วงเวลา) และของผู้ใช้ ต้นทุนสินทรัพย์สำหรับ CWVI

• ช่วงเวลาท้าทายที่เหมาะสมควรกำหนดเมื่อต้นทุนสินทรัพย์รวมของผู้ยืนยันและผู้ใช้ที่ถอนออกต่ำที่สุด นั่นคือ เมื่อหาค่าของ C แล้ว 10V exp(-AC)I+CWVI จะน้อยที่สุด ทั้ง V และ I ปรากฏในทั้งสองคำ ไม่มีผลกับจุดต่ำสุดและสามารถละเว้นได้ เราเพียงแค่หาความแตกต่างด้วยความเคารพต่อ C ตั้งค่าอนุพันธ์ที่เป็นผลลัพธ์เป็น 0 และรับ C = ln(10A / W) / A

ตอนนี้เราเสียบตัวเลขที่เหมาะสมลงในสมการด้านบนเพื่อให้ได้ระยะเวลาการท้าทายที่เหมาะสมโดยประมาณ

สมมติว่าอัตราความสำเร็จของการตรวจสอบต่อเนื่องภายในหนึ่งช่วงตึกสูงถึง 99.99% นั่นคือ A = -ln(0.99) = 0.01

นอกจากนี้ สมมติว่าการถอนรายวันคือ 1% ของมูลค่าทั้งหมด และเปอร์เซ็นต์การถอนของแต่ละบล็อกคือประมาณ W=0.000002 โดยอิงจากสมมติฐานที่ว่าเวลาในการสร้างบล็อกคือ 15 วินาที

ชื่อเรื่องรอง

วิธีป้องกันการโจมตีจากการเซ็นเซอร์

ในส่วนนี้ เราจะหารือเกี่ยวกับวิธีที่ Arbitrum ป้องกันการโจมตีจากการเซ็นเซอร์สี่ประเภทหลัก: การโจมตีแบบฟอร์กกิ้ง การโจมตีหลบเลี่ยง การโจมตีแบบติดขัด และการโจมตีแบบปีศาจเร็ว

การโจมตีด้วยฟอร์กกิ้ง: นักขุดสมรู้ร่วมคิด (หรือติดสินบน) เพื่อทิ้งบล็อกที่มีความท้าทายปกติ เพื่อยอมรับเชนทางเลือกที่ไม่มีการท้าทาย

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

การโจมตีแบบหลบเลี่ยง: นักขุดสมรู้ร่วมคิด (หรือติดสินบน) เพื่อเพิกเฉยต่อความท้าทายทั่วไปในบล็อกที่พวกเขาผลิต

เราถือว่าการผูกขาดควบคุม 90% ของพลังการขุดและมีกำหนดเวลา 50 บล็อก จากนั้นผู้ผูกขาดจำเป็นต้องแพ็คบล็อกติดต่อกัน 50 บล็อกเพื่อทำการโจมตีให้สำเร็จ ความน่าจะเป็นนี้คือ 0.9 ยกกำลัง 50 หรือ 0.5% ระยะเวลาท้าทายที่แท้จริงนั้นมากกว่า 50 ช่วงตึก ดังนั้นความน่าจะเป็นที่จะโจมตีสำเร็จจึงน้อยมาก ในการออกแบบของ Arbitrum ผู้โจมตีจะจ่ายค่าปรับจำนวนมากหากการโจมตีล้มเหลว ดังนั้นผู้ผูกขาดจึงเปิดการโจมตีแบบหลบเลี่ยงอย่างไม่คุ้มค่า

การโจมตีแบบติดขัด: ผู้โจมตีเปิดใช้ "การโจมตีแบบปฏิเสธการให้บริการแบบเก่า (DoS)" เพื่อป้องกันไม่ให้ฝ่ายใดฝ่ายหนึ่งออกธุรกรรมใด ๆ (ไม่สามารถออกธุรกรรมที่มีความท้าทายได้)

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

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

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

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

ข้อดีและความเสี่ยงของโหมดซีเควนเซอร์

โหมด Sequencer เป็นคุณสมบัติทางเลือกของ Arbitrum และ Offchain Labs รันโหนด Sequencer เพียงตัวเดียวบน mainnet เวอร์ชันที่วางจำหน่าย

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

ในขณะเดียวกัน ซีเควนเซอร์ที่ประพฤติตัวดีสามารถป้องกันการโจมตีจากแนวหน้าได้อย่างมีประสิทธิภาพ

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

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

ลิงก์ไปยังบทความนี้:https://www.8btc.com/article/6655971
พิมพ์ซ้ำ โปรดระบุแหล่งที่มาของบทความ