---
title: "การหมุนเวียนผู้ลงนามมัลติซิก"
description: "ขั้นตอนที่ให้ความสำคัญกับการตรวจสอบสำหรับเปลี่ยนผู้ลงนามมัลติซิก โดยรักษาองค์ประชุม ตรวจสอบชุดเจ้าของและเกณฑ์บนเชนที่ถูกต้อง และตอบสนองต่อคีย์ที่ถูกเจาะอย่างปลอดภัย"
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>

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

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

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

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

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

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

1. **สำรวจสิทธิ์ปัจจุบัน** จากเชนและที่อยู่บัญชีที่ตรวจสอบอย่างเป็นอิสระ ให้อ่านการติดตั้งใช้งาน รายชื่อเจ้าของ เกณฑ์ nonce โมดูลที่เปิดใช้ guards, fallback handler, เส้นทางกู้คืน และ timelock ทั้งหมด โมดูลหรือกลไกกู้คืนอาจดำเนินการนอกเกณฑ์เจ้าของปกติ ส่วน guard ที่เข้มงวดอาจขวางการหมุนเวียนที่ควรถูกต้อง
2. **กำหนดสถานะเป้าหมายก่อนลงนาม** บันทึกชุดเจ้าของและเกณฑ์ที่ถูกต้องหลังการเปลี่ยนแปลง ยืนยันว่าเกณฑ์ไม่มากกว่าจำนวนเจ้าของ และมีผู้ลงนามอิสระอย่างน้อยเท่ากับเกณฑ์ที่ยังใช้งานได้ การแยกสถานที่ไม่ใช่ความเป็นอิสระ หากบุคคล คลังรหัสผ่าน บัญชีคลาวด์ หรือผู้ดูแลคนเดียวควบคุมอุปกรณ์ทั้งหมด
3. **ลงทะเบียนและยืนยันผู้ลงนามใหม่** สร้างหรือกู้คืนคีย์ใหม่ในสภาพแวดล้อมการดูแลที่กำหนด ตรวจสอบที่อยู่บนอุปกรณ์ที่เชื่อถือได้ และพิสูจน์การควบคุมด้วยโจทย์ที่ตกลงกันหรือลายเซ็นทดสอบ ยืนยันที่อยู่ผ่านช่องทางที่ยืนยันตัวตนแล้วอีกช่องทางหนึ่ง อย่าพึ่งพาเพียงข้อความแชตที่คัดลอกมาหรืออินเทอร์เฟซกระเป๋า
4. **เลือกลำดับที่มีสถานะระหว่างทางปลอดภัย** บางสัญญาเปลี่ยนเจ้าของหนึ่งรายแบบอะตอมมิกได้ ตัวอย่างเช่น Safe มี `swapOwner` และยังมี `addOwnerWithThreshold`, `removeOwner` และ `changeThreshold` หากการติดตั้งต้องใช้หลายธุรกรรม ให้วิเคราะห์ชุดเจ้าของและเกณฑ์หลังทุกขั้นตอน เพิ่มและตรวจสอบความสามารถก่อนลบ เว้นแต่การเจาะระบบที่กำลังเกิดขึ้นทำให้ลำดับนี้ไม่ปลอดภัย
5. **ถอดรหัสและจำลองธุรกรรมที่ถูกต้อง** ตรวจสอบ chain ID, ที่อยู่บัญชี, target, ตัวเลือกฟังก์ชัน, ที่อยู่เจ้าของเดิมและใหม่, เกณฑ์ผลลัพธ์, nonce, value และประเภทการดำเนินการอย่างเป็นอิสระ ให้ถือ `delegatecall` การทำงานเป็นชุด การเปลี่ยนโมดูล และการเปลี่ยน guard เป็นผลกระทบความเสี่ยงสูงคนละรายการ ผู้ลงนามทุกคนต้องอนุมัติ payload ที่ถอดรหัสแล้วและแฮชธุรกรรมเดียวกัน
6. **ดำเนินการด้วยสิทธิ์ที่มีอยู่** องค์ประชุมปัจจุบันที่ถูกต้องเป็นผู้อนุมัติการหมุนเวียน เว้นแต่เส้นทางกู้คืนที่มีเอกสารระบุไว้ต่างออกไป ในภาวะฉุกเฉิน ให้ประสานงานผ่านผู้ติดต่อที่ยืนยันตัวตนแล้วเท่านั้นและใช้ผู้ลงนามที่ไม่ถูกเจาะ หากทั้งองค์ประชุมปกติและสิทธิ์กู้คืนที่ตั้งค่าไว้ล่วงหน้าใช้ไม่ได้ การเรียกจัดการเจ้าของมาตรฐานจะกู้คืนการเข้าถึงไม่ได้
7. **ตรวจสอบและปิดการเปลี่ยนแปลง** หลังยืนยัน ให้สอบถามชุดเจ้าของและเกณฑ์โดยตรง ตรวจสอบเหตุการณ์หรือ traces ที่ปล่อยออกมาตามการติดตั้ง และยืนยันว่าที่อยู่เดิมไม่มีสิทธิ์อีกต่อไป ให้ผู้ลงนามใหม่เข้าร่วมธุรกรรมความเสี่ยงต่ำหรือมูลค่าศูนย์ที่อนุมัติแล้วและต้องใช้เกณฑ์ที่ตั้งใจไว้ ตรวจสอบธุรกรรมที่รอดำเนินการ เพิกถอนการเข้าถึง off-chain และข้อมูลสำรองของผู้ลงนามเดิม และเก็บข้อเสนอ ลายเซ็น แฮชธุรกรรม บล็อก และสถานะสุดท้ายไว้

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

## ตัวอย่างแบบครบถ้วน

สมมติว่าบัญชี `3-of-5` มีเจ้าของ `A`, `B`, `C`, `D` และ `E` และต้องเปลี่ยน `B` เป็น `F` ทีมตรวจสอบก่อนว่า `F` ควบคุมที่อยู่ที่เสนออย่างถูกต้องและยังเป็นอิสระจากเจ้าของรายอื่น สำหรับการติดตั้ง Safe ที่รองรับ ทีมเตรียม `swapOwner(prevOwner, B, F)` การเรียกนี้เป็นธุรกรรม Safe ในตัวเอง จึงต้องมีการยืนยันที่ถูกต้อง `3` รายการจากชุดเจ้าของปัจจุบัน ผลลัพธ์ที่ถอดรหัสแล้วต้องรักษาจำนวนเจ้าของ `5` และเกณฑ์ `3`

หลังธุรกรรมได้รับการยืนยัน ทีมอ่าน `getOwners` และ `getThreshold` ตรวจสอบว่าไม่มี `B` และมี `F` จากนั้นให้ `F` กับเจ้าของอีกสองรายดำเนินการทดสอบมูลค่า `0` ที่อนุมัติแล้ว ทีมยังตรวจสอบธุรกรรมที่รอดำเนินการด้วย เพราะลายเซ็นหรือการอนุมัติล่วงหน้าจาก `B` อาจไม่ผ่านการตรวจสอบเจ้าของหลังถูกลบอีกต่อไป ดังนั้นข้อเสนอที่ได้รับผลกระทบต้องถูกยกเลิกหรือสร้างใหม่ ไม่ใช่สันนิษฐานว่ายังดำเนินการได้

หาก `B` อาจถูกเจาะ ทีมจะไม่ขอให้ผู้ลงนามรายนั้นอนุมัติการลบ เจ้าของรายอื่นที่ไม่ถูกเจาะสามรายดำเนินการเปลี่ยน จากนั้นตรวจสอบโมดูล สิทธิ์กู้คืน allowances, session keys และธุรกรรมที่ดำเนินการไปแล้ว เพราะการลบ `B` ไม่ย้อนการกระทำก่อนหน้าและไม่เพิกถอนสิทธิ์ที่มอบผ่านเส้นทางอื่น หากมีเจ้าของที่ไม่ถูกเจาะน้อยกว่า `3` ราย มีเพียงเส้นทางกู้คืนหรือการดูแลระบบที่ตั้งค่าไว้ก่อนเท่านั้นที่อาจช่วยได้ การแชร์วลี seed หรือเชื่อถือบริการ "กู้คืน" ที่ไม่ได้ร้องขอไม่อาจทดแทนองค์ประชุม

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

## ความเสี่ยงและการควบคุม

- **บัญชีหรือที่อยู่ผิด** ตรวจสอบ chain ID, ที่อยู่มัลติซิก การติดตั้ง และที่อยู่เจ้าของใหม่บนอุปกรณ์และจากแหล่งข้อมูลอิสระ การวางยาพิษที่อยู่และข้อผิดพลาดจากการคัดลอกอาจมอบการควบคุมให้ผู้โจมตี
- **สูญเสียองค์ประชุม** สร้างแบบจำลองทุกสถานะระหว่างทาง การลบเจ้าของเร็วเกินไป การเพิ่มเกณฑ์สูงกว่าจำนวนผู้ลงนามที่มี หรือการหมุนเวียนอุปกรณ์ที่สัมพันธ์กันหลายเครื่องพร้อมกันอาจทำให้บัญชีใช้ไม่ได้
- **การกระจุกตัวชั่วคราว** เกณฑ์ที่ต่ำลงหรือผู้ลงนามที่เพิ่งเพิ่มอาจสร้างช่วงเวลาที่ฝ่ายน้อยลงควบคุมบัญชี ให้เลือกการเปลี่ยนแบบอะตอมมิกเมื่อรองรับ และอย่าลดเกณฑ์เพียงเพื่อทำให้พิธีง่ายขึ้น
- **การดูแลที่สัมพันธ์กัน** ที่อยู่ต่างกันไม่เป็นอิสระหาก seed อุปกรณ์ ข้อมูลสำรอง การสื่อสาร หรือผู้ดูแลใช้โดเมนความล้มเหลวเดียวกัน ทดสอบการกู้คืนโดยไม่รวมศูนย์ความลับ
- **สิทธิ์ที่ซ่อนอยู่** โมดูล guards, fallback handlers, session keys, timelocks และสัญญากู้คืนอาจข้ามหรือขวางเส้นทางเจ้าของ สำรวจและตรวจสอบก่อนและหลังการหมุนเวียน
- **การแข่งขันกับผู้ลงนามที่ถูกเจาะ** ก่อนยืนยันการลบ ผู้ลงนามที่น่าสงสัยอาจส่งธุรกรรมตัดหน้า ถอนสินทรัพย์ เปลี่ยนการกำหนดค่า หรืออนุมัติธุรกรรมอื่น ใช้ขั้นตอนตอบสนองเหตุการณ์ การส่งธุรกรรมแบบส่วนตัวเมื่อเหมาะสม และการติดตามสถานะต่อเนื่อง อย่าสันนิษฐานว่าธุรกรรมที่ส่งไปชนะการแข่งขันแล้ว
- **การอนุมัติที่รอดำเนินการล้าสมัย** การเปลี่ยนเจ้าของและเกณฑ์อาจทำให้ลายเซ็นที่รวบรวมไว้ใช้ไม่ได้ หรือเปลี่ยนว่าการอนุมัติใดเพียงพอ ประเมินธุรกรรมในคิวทุกธุรกรรมเทียบกับสถานะสุดท้ายอีกครั้งและยกเลิกข้อเสนอที่ล้าสมัย
- **การสรุปว่าสำเร็จผิดพลาด** การแจ้งว่าสำเร็จจากอินเทอร์เฟซไม่พิสูจน์สถานะที่ต้องการ รอให้ครบตามนโยบายยืนยัน จากนั้นอ่านสถานะสัญญาและตรวจสอบ payload ของธุรกรรม เหตุการณ์ และผลการดำเนินการ
- **การยุติสิทธิ์ไม่ครบถ้วน** การลบเจ้าของ on-chain ไม่ได้ลบคีย์ที่คัดลอกไว้ การเข้าถึงขององค์กร ข้อมูลรับรอง relayer รายการคลังรหัสผ่าน หรือสิทธิ์ในสัญญาและเชนอื่น เพิกถอนแต่ละรายการแยกกันและเก็บร่องรอยการตรวจสอบ

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

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

- **"การหมุนเวียนหมายถึงย้ายสินทรัพย์ทั้งหมดไปยังกระเป๋าใหม่"** มัลติซิกแบบ smart account จำนวนมากอัปเดตเจ้าของที่ที่อยู่บัญชีเดิม การย้ายระบบเป็นอีกการดำเนินการหนึ่ง และอาจจำเป็นเฉพาะกับการติดตั้งหรือแผนรับมือเหตุการณ์บางแบบ
- **"เพิ่มผู้ลงนามใหม่ก่อนปลอดภัยเสมอ"** วิธีนี้ช่วยรักษาความพร้อมใช้งาน แต่อาจขยายชุดผู้มีสิทธิ์ชั่วคราว ระหว่างการเจาะที่กำลังเกิดขึ้น การเปลี่ยนแบบอะตอมมิกหรือลำดับฉุกเฉินแบบอื่นอาจปลอดภัยกว่า
- **"เกณฑ์ `3-of-5` หมายถึงบุคคลที่ระบุไว้สามคนใดก็พร้อมใช้งาน"** สัญญานับบัญชีเจ้าของที่ถูกต้อง ไม่ใช่บุคคล แผนก หรืออุปกรณ์ การดูแลร่วมกันและคีย์ที่เข้าถึงไม่ได้ลดความเป็นอิสระและความพร้อมใช้งานที่แท้จริง
- **"การลบเจ้าของที่ถูกเจาะจะย้อนความเสียหาย"** หลังยืนยัน การลบจะป้องกันการใช้เส้นทางเจ้าของนั้นในอนาคต แต่ไม่ย้อนธุรกรรมที่ดำเนินการแล้วหรือเพิกถอนสิทธิ์ที่สร้างไว้ที่อื่น
- **"อินเทอร์เฟซกระเป๋าเป็นหลักฐานเพียงพอ"** อินเทอร์เฟซและบริการจัดทำดัชนีอาจล้าสมัย กำหนดค่าผิด หรือเป็นอันตราย ถอดรหัสธุรกรรมและอ่านสถานะสัญญาสุดท้ายจาก endpoint ที่ตรวจสอบอย่างเป็นอิสระ
- **"เมื่อไม่มีองค์ประชุม ฝ่ายสนับสนุนรีเซ็ตกระเป๋าได้"** มัลติซิกที่ดูแลเองมีเพียงเส้นทางสิทธิ์ที่เข้ารหัสหรือตั้งค่าไว้ล่วงหน้าบนเชน หากไม่มีองค์ประชุมที่ถูกต้องหรือเส้นทางกู้คืน อาจสูญเสียการเข้าถึงอย่างถาวร

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

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

- [กระเป๋าฮาร์ดแวร์](/th/crypto/hardware-wallet/)
- [กระเป๋ามัลติซิก](/th/crypto/multisig-wallet/)
- [การจัดการคีย์ส่วนตัว](/th/crypto/private-key-management/)
- [ความเสี่ยงในการกู้คืนเจ้าของ smart account](/th/crypto/smart-account-owner-recovery-risk/)
- [การจำลองธุรกรรม](/th/crypto/transaction-simulation/)

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

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

- [บัญชีอัจฉริยะ Safe ทำงานอย่างไร](https://docs.safe.global/advanced/smart-account-overview) - Safe Documentation (เข้าถึง: 2026-08-21)
- [addOwnerWithThreshold](https://docs.safe.global/reference-smart-account/owners/addOwnerWithThreshold) - Safe Documentation (เข้าถึง: 2026-08-21)
- [removeOwner](https://docs.safe.global/reference-smart-account/owners/removeOwner) - Safe Documentation (เข้าถึง: 2026-08-21)
- [swapOwner](https://docs.safe.global/reference-smart-account/owners/swapOwner) - Safe Documentation (เข้าถึง: 2026-08-21)
- [changeThreshold](https://docs.safe.global/reference-smart-account/owners/changeThreshold) - Safe Documentation (เข้าถึง: 2026-08-21)
- [OwnerManager.sol](https://github.com/safe-fndn/safe-smart-account/blob/main/contracts/base/OwnerManager.sol) - Safe Ecosystem Foundation (เข้าถึง: 2026-08-21)
- [คำแนะนำสำหรับการจัดการคีย์: ส่วนที่ 1 - ทั่วไป](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final) - NIST (เข้าถึง: 2026-08-21)

Source: https://wiki.fcontext.com/th/crypto/multisig-signer-rotation/index.mdx