ข้ามไปยังเนื้อหา
Financial Context Wiki

ความเสี่ยงของโมดูลมัลติซิก: สิทธิ์ใดข้ามเกณฑ์การลงนามได้

โมดูลที่เปิดใช้งานอาจดำเนินการจากบัญชีมัลติซิกได้โดยไม่ต้องรวบรวมลายเซ็นตามเกณฑ์ปกติของเจ้าของ เรียนรู้วิธีตรวจสอบโมดูล Guard, Fallback Handler, การอัปเกรด และเส้นทางกู้คืน

อัปเดต

จัดทำขึ้นเพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำการลงทุน การลงทุนอาจทำให้สูญเสียเงินลงทุนได้

คำตอบโดยตรง

โมดูลที่เปิดใช้งานเป็นเส้นทางอนุญาตแยกต่างหาก ในบัญชีอัจฉริยะแบบ Safe โมดูลที่ได้รับอนุมัติสามารถเรียก execTransactionFromModule และดำเนินการ CALL หรือ DELEGATECALL โดยไม่ต้องรวบรวมลายเซ็น M-of-N ตามปกติของเจ้าของสำหรับการกระทำนั้น ดังนั้นเกณฑ์ที่แสดงจึงอธิบายเพียงเส้นทางดำเนินการหนึ่งเส้นทาง ไม่ใช่ขอบเขตความปลอดภัยทั้งหมดของบัญชี

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

วิธีการทำงาน

เจ้าของอนุมัติ enableModule ผ่านธุรกรรม Safe ปกติก่อน บัญชีจะเก็บโมดูลไว้ในทะเบียนโมดูลที่เปิดใช้งาน ต่อมาโมดูลจะตรวจสอบผู้เรียกและกฎของตนเอง แล้วเรียก execTransactionFromModule; บัญชีตรวจว่าผู้เรียกเปิดใช้งานอยู่และดำเนินการตามคำขอ ความปลอดภัยจึงขึ้นกับโค้ด การกำหนดค่า ผู้ดูแลระบบ คีย์อัปเกรด และการพึ่งพาภายนอกของโมดูลด้วย

Transaction Guard และ Module Guard เป็นการควบคุมคนละประเภท Transaction Guard ตรวจการเรียก execTransaction ปกติ ส่วน Module Guard ตรวจการเรียกที่เริ่มจากโมดูล Guard ปฏิเสธการดำเนินการได้ แต่ Guard ที่เสียหรือจำกัดมากเกินไปก็ทำให้บริการหยุดชะงักได้ ต้องยืนยันว่าติดตั้งชนิดใด ตรวจอะไร และกู้คืนหรือถอดออกอย่างไร

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

ตัวอย่าง

คลังใช้เกณฑ์เจ้าของ 3-of-5 และเปิดโมดูลวงเงินสำหรับการชำระเงินประจำ โมดูลอัปเกรดได้และผู้ดูแลการอัปเกรดเป็น Hot Wallet เพียงใบเดียว หากคีย์นั้นถูกยึด ผู้โจมตีอาจอัปเกรดโมดูล ใช้เส้นทางดำเนินการของโมดูล และโอนสินทรัพย์โดยไม่ต้องได้ลายเซ็น 3 ราย เกณฑ์ 3-of-5 ยังอยู่เหมือนเดิมแต่ไม่ควบคุมเส้นทางนี้

การตรวจสอบควรระบุที่อยู่โมดูลและ implementation ที่ยืนยันแล้ว proxy และผู้ดูแล วงเงินใช้จ่าย เป้าหมายและ function selector ที่อนุญาต การอนุญาต DELEGATECALL, Module Guard ที่ติดตั้ง, Fallback Handler และธุรกรรมที่แน่นอนสำหรับปิดโมดูล ตรวจสอบค่าจากสัญญาบัญชีและ proxy ที่เกี่ยวข้องในทุกเชน ไม่ใช่อาศัยเพียงหน้าจอกระเป๋า

ความเสี่ยง

  • ความเสี่ยงด้านอำนาจ: โมดูลที่มีช่องโหว่หรือเป็นอันตรายอาจโอนสินทรัพย์ อนุมัติผู้ใช้จ่าย เปลี่ยนสถานะผ่าน DELEGATECALL หรือเรียกสัญญาที่มีสิทธิพิเศษอื่น หน้าจอที่มีฟังก์ชันจำกัดไม่ได้พิสูจน์ว่าสิทธิ์บนเชนจำกัดด้วย
  • ความเสี่ยงด้านการควบคุมและอัปเกรด: proxy ของโมดูล ผู้ดูแล oracle ผู้ดำเนินระบบอัตโนมัติ หรือคีย์กู้คืน อาจลดโครงสร้างที่ดูเหมือน 3-of-5 ให้เหลือชุดควบคุมจริงที่เล็กกว่า ต้องไล่ทุกเส้นทางอัปเกรดและกำหนดค่าจนถึงผู้ลงนามสุดท้ายและระยะหน่วง
  • ความเสี่ยงด้านความพร้อมใช้: Guard ที่ผิดพลาดอาจบล็อกธุรกรรมที่ถูกต้อง ขณะที่โมดูลที่ถูกยึดอาจทำงานเร็วกว่าที่เจ้าของจะประสานการถอดออก ทดสอบการปิดและกู้คืน เฝ้าดูการเปลี่ยนโมดูล Guard และ Handler และรักษาเส้นทางตอบสนองที่ไม่พึ่งส่วนประกอบที่จะถอด

ความเข้าใจผิดที่พบบ่อย

  • ความเข้าใจผิด 1: “บัญชีเป็น 3-of-5 ดังนั้นทุกการโอนต้องมี 3 ลายเซ็น” เกณฑ์ใช้กับเส้นทางปกติที่เจ้าของอนุมัติ โมดูลที่เปิดใช้งานอาจใช้นโยบายอนุญาตต่างออกไป
  • ความเข้าใจผิด 2: “Guard เดียวปกป้องทุกเส้นทางดำเนินการ” Transaction Guard ปกติและ Module Guard ครอบคลุมจุดเข้าแตกต่างกัน และขอบเขตขึ้นกับสัญญาที่ติดตั้งกับกฎของมัน
  • ความเข้าใจผิด 3: “ลบโมดูลในหน้าจอแล้วความเสี่ยงสิ้นสุด” ยืนยันทะเบียนโมดูลที่เปิดใช้งานบนเชน storage ของ Handler และ Guard, implementation ของ proxy และธุรกรรมเปลี่ยนแปลงที่ดำเนินแล้วในทุกเชน

หัวข้อที่เกี่ยวข้อง

แหล่งที่มา

การนำทาง

ค้นหาในวิกิ...