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

การหมุนเวียนผู้ลงนามมัลติซิก

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

อัปเดต

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

คำตอบโดยตรง

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

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

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

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

  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 และข้อมูลสำรองของผู้ลงนามเดิม และเก็บข้อเสนอ ลายเซ็น แฮชธุรกรรม บล็อก และสถานะสุดท้ายไว้

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

สมมติว่าบัญชี 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 หรือเชื่อถือบริการ “กู้คืน” ที่ไม่ได้ร้องขอไม่อาจทดแทนองค์ประชุม

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

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

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

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

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

แหล่งที่มา

การนำทาง

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