---
title: "ความเสี่ยงของโมดูลมัลติซิก: สิทธิ์ใดข้ามเกณฑ์การลงนามได้"
description: "โมดูลที่เปิดใช้งานอาจดำเนินการจากบัญชีมัลติซิกได้โดยไม่ต้องรวบรวมลายเซ็นตามเกณฑ์ปกติของเจ้าของ เรียนรู้วิธีตรวจสอบโมดูล Guard, Fallback Handler, การอัปเกรด และเส้นทางกู้คืน"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

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

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

<a id="answer"></a>

## คำตอบโดยตรง

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

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

<a id="mechanism"></a>

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

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

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

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

<a id="example"></a>

## ตัวอย่าง

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

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

<a id="risks"></a>

## ความเสี่ยง

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

<a id="misconceptions"></a>

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

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

<a id="related"></a>

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

- [ความเสี่ยงต่อ storage จาก delegatecall](/th/crypto/delegatecall-storage-risk/)
- [การจัดการคีย์ส่วนตัว](/th/crypto/private-key-management/)
- [กระเป๋ามัลติซิก](/th/crypto/multisig-wallet/)
- [การติดตามอัปเกรด proxy](/th/crypto/proxy-upgrade-monitoring/)
- [ลายเซ็นกระเป๋า](/th/crypto/wallet-signature/)

<a id="sources"></a>

## แหล่งที่มา

- [โมดูล Safe](https://docs.safe.global/advanced/smart-account-modules) - Safe Ecosystem Foundation (เข้าถึง: 2026-08-21)
- [Guard ของ Safe](https://docs.safe.global/advanced/smart-account-guards) - Safe Ecosystem Foundation (เข้าถึง: 2026-08-21)
- [Fallback Handler ของ Safe](https://docs.safe.global/advanced/smart-account-fallback-handler) - Safe Ecosystem Foundation (เข้าถึง: 2026-08-21)
- [ModuleManager.sol](https://github.com/safe-fndn/safe-smart-account/blob/main/contracts/base/ModuleManager.sol) - Safe Ecosystem Foundation (เข้าถึง: 2026-08-21)

Source: https://wiki.fcontext.com/th/crypto/multisig-module-risk/index.mdx