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

กลไกการรักษาความปลอดภัยในการโยกย้ายจาก Ethereum mainnet ไปยังโซลูชันชั้นที่สองเป็นหนึ่งในปัญหาที่ผู้ใช้กังวลมากที่สุด ในโพสต์นี้ เราจะเจาะลึกกลไกการรักษาความปลอดภัยของ Arbitrum รวมถึงวิธีการที่ Arbitrum มีรากฐานมาจากความปลอดภัยของ Ethereum เหตุใดจึงมีระยะเวลาท้าทายถึง 7 วัน และวิธีป้องกันการโจมตีจากการเซ็นเซอร์

ฝังอยู่ใน Ethereum Security

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

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

1. ในโซลูชัน Rollup ธุรกรรมจะถูกเขียนใน L1 (เป็น calldata) แต่การคำนวณและการจัดเก็บสัญญาจะเสร็จสมบูรณ์ใน L2 เพื่อให้มีการขยายตัว

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

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

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

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

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

AnyTrust

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

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

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

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

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

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

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

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

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

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

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

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

หมายเหตุ: exp เป็นฟังก์ชันเลขชี้กำลัง"e", A เป็นค่าคงที่ A, AC อยู่ข้างหน้า"-"เครื่องหมายหมายความว่า C แปรผกผันกับผลตอบแทนที่คาดหวัง

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

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

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

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

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

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

เมื่อใส่ข้อมูลเหล่านี้ลงในสูตร เราจะได้รับความล่าช้าในการท้าทายที่เหมาะสมที่สุดที่ C = 62,146 บล็อก หรือ 10.79 วัน ซึ่งใกล้เคียงกับระยะเวลาท้าทายที่เหมาะสมที่สุด 7 วันที่ทีมอนุญาโตตุลาการเลือกในที่สุด

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

ในส่วนนี้ เราจะพูดถึงวิธีที่ Arbitrum ป้องกันการโจมตีจากการเซ็นเซอร์สี่ประเภทหลัก: การโจมตีแบบ Forking การโจมตีแบบหลบเลี่ยง การโจมตีแบบติดขัด และการโจมตีแบบ Speed ​​Demon

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

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

Evasion Attack: นักขุดสมรู้ร่วมคิด (หรือติดสินบน) เพื่อละเว้นความท้าทายตามปกติจากบล็อกที่พวกเขาสร้างขึ้น

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

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

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

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

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

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

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

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

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

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

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

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

ต้นฉบับ: hackernoon

เรียบเรียง : บิบาบู