จัดทำขึ้นเพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำการลงทุน การลงทุนอาจทำให้สูญเสียเงินลงทุนได้
คำตอบโดยตรง
Governance Timelock เป็นตัวควบคุมการดำเนินการ ไม่ใช่การลงคะแนนอีกครั้ง หลังระบบกำกับดูแลอนุมัติ payload แล้ว ผู้เสนอที่ได้รับสิทธิจะกำหนดเวลาปฏิบัติการตามรายละเอียดที่แน่นอน สัญญาจะบันทึกเวลาที่ปฏิบัติการเริ่มดำเนินการได้และปฏิเสธการดำเนินการก่อนถึงเวลานั้น ระยะหน่วงนี้ทำให้การอัปเกรด การเปลี่ยนพารามิเตอร์ การโอนเงินคลัง หรือการเปลี่ยนบทบาทที่รอดำเนินการเป็นสิ่งที่ตรวจสอบได้ก่อนมีผลจริง
ระยะหน่วงที่ประกาศเป็นเพียงส่วนหนึ่งของการควบคุม ต้องตรวจสอบ Operation ID เวลาดำเนินการเร็วที่สุด กฎการหมดอายุหากมี ปฏิบัติการก่อนหน้า ผู้เสนอ ผู้ดำเนินการ ผู้ยกเลิก ผู้ดูแลระบบ และทุกช่องทางอื่นที่ควบคุมสัญญาเป้าหมายได้ Timelock 48-hour ไม่ได้ทำให้มีช่วงเวลาถอนออก 48-hour หากกำหนดเวลาปฏิบัติการล่าช้า ระบบติดตามแจ้งเตือนช้า การถอนใช้เวลานานกว่า หรือกุญแจที่มีสิทธิพิเศษชุดอื่นทำการเปลี่ยนแปลงเดียวกันได้ทันที
Timelock ไม่ได้ตัดสินว่าการดำเนินการชอบธรรมหรือปลอดภัยหรือไม่ แต่ให้เวลาผู้ใช้และระบบติดตามอัตโนมัติถอดรหัสคำสั่ง จำลองผลกระทบ ยกเลิกหรือพักการดำเนินการเมื่อมีอำนาจ แจ้งการเปลี่ยนแปลง และถอนออกจากสถานะเมื่อมีช่องทางถอนออกที่ใช้ได้จริง
กลไกการทำงาน
- ต้องมอบอำนาจให้ Timelock Timelock ต้องเป็นเจ้าของหรือถือบทบาทที่เกี่ยวข้องในสัญญาเป้าหมาย หาก Governor ไม่มีอำนาจเหนือเป้าหมาย การผ่านข้อเสนอก็ไม่ทำให้เกิดการเปลี่ยนแปลง หากผู้ดูแลระบบอีกชุดยังมีอำนาจคู่ขนาน ช่องทางนั้นอาจข้ามระยะหน่วงได้
- ผู้เสนอกำหนดเวลาปฏิบัติการตามรายละเอียดที่แน่นอน ใน
TimelockControllerของ OpenZeppelin ID ของปฏิบัติการเดี่ยวคือแฮชของtarget,value,data,predecessorและsaltส่วนปฏิบัติการแบบชุดจะแฮชอาร์เรย์ที่เกี่ยวข้องพร้อม dependency และ salt เดียวกัน การเปลี่ยนฟิลด์ใดก็ตามจะสร้าง Operation ID ใหม่ Salt ใช้แยกการดำเนินการที่เหมือนกันทุกประการในด้านอื่น - ระยะหน่วงขั้นต่ำเริ่มเมื่อกำหนดเวลา การลงคะแนนสำเร็จไม่ได้หมายความว่า Timelock เริ่มนับเวลาเสมอไป การกำหนดเวลาจะบันทึก timestamp ที่พร้อมดำเนินการโดยใช้ระยะหน่วงไม่น้อยกว่าค่าขั้นต่ำปัจจุบันของสัญญา ปฏิบัติการ OpenZeppelin เปลี่ยนสถานะจาก
Unsetเป็นWaitingจากนั้นเป็นReadyและสุดท้ายเป็นDoneหลังดำเนินการสำเร็จ - ตรวจสอบ dependency และสิทธิเมื่อดำเนินการ ปฏิบัติการก่อนหน้าต้องอยู่ในสถานะ
Doneแล้ว ผู้เรียกต้องผ่านเงื่อนไขของผู้ดำเนินการ และการเรียกสัญญาเป้าหมายต้องสำเร็จ ผู้ดำเนินการเปลี่ยน payload ที่กำหนดเวลาไว้ไม่ได้ การมอบบทบาทผู้ดำเนินการให้address(0)ทำให้ทุกคนดำเนินการได้หลังครบกำหนด ซึ่งช่วยให้ระบบพร้อมใช้งานมากขึ้น แต่ก็เปิดให้บัญชีใดก็ได้เลือกจังหวะที่แน่นอนในการดำเนินการทันทีที่เข้าเงื่อนไข - การยกเลิกทำให้ปฏิบัติการที่รอดำเนินการกลับสู่สถานะเริ่มต้น ในสัญญา OpenZeppelin รุ่นปัจจุบัน บัญชีที่มี
CANCELLER_ROLEยกเลิกปฏิบัติการได้ขณะที่ยังรอดำเนินการ รวมถึงเมื่อพร้อมแล้วแต่ยังไม่ได้ดำเนินการ การกำหนดเวลาใหม่จะเริ่มนับเวลาใหม่ การกำหนดบทบาทจึงสำคัญ เพราะรุ่นเก่าและ Timelock แบบอื่นอาจให้สิทธิยกเลิกแก่ผู้เสนอหรือผู้ดูแลระบบ - การหมดอายุขึ้นอยู่กับแต่ละ implementation
TimelockControllerของ OpenZeppelin ไม่มีการหมดอายุตามระยะผ่อนผันในตัว ปฏิบัติการที่พร้อมแล้วจะคงสถานะพร้อมจนกว่าจะดำเนินการหรือยกเลิก ในทางกลับกัน Timelock ของ Compound v2 กำหนดให้ดำเนินการไม่เกินeta + GRACE_PERIODและซอร์สโค้ดกำหนดGRACE_PERIODไว้ที่14 daysส่วน Governor Bravo จะระบุว่าข้อเสนอที่เข้าคิวหมดอายุเมื่อพ้นขอบเขตนี้ - การดูแลระบบต้องถูกหน่วงเวลาด้วย OpenZeppelin อนุญาตให้เรียก
updateDelayผ่านการเรียกจาก Timelock กลับมาหาตัวเองเท่านั้น การติดตั้งแบบดูแลตัวเองจะบังคับให้เปลี่ยนบทบาทผ่านปฏิบัติการที่กำหนดเวลาเช่นกัน ผู้ดูแลระบบภายนอกชั่วคราวที่ใช้ระหว่างการตั้งค่าควรสละบทบาทหลังตั้งค่าเสร็จ มิฉะนั้นจะยังเป็นช่องทางความไว้วางใจอีกช่องทางหนึ่ง
สำหรับทุกการดำเนินการในคิว ให้สร้างบันทึกควบคุมขึ้นใหม่จากสถานะและ event ของสัญญา ได้แก่ Chain ID ที่อยู่ Timelock และเป้าหมาย Operation ID, payload ที่ถอดรหัสแล้ว ผู้เสนอ ธุรกรรมและเวลาที่กำหนด ระยะหน่วงขั้นต่ำ เวลาที่พร้อม เวลาหมดอายุหากมี ปฏิบัติการก่อนหน้า นโยบายผู้ดำเนินการ อำนาจยกเลิก และสถานะธุรกรรมสุดท้าย อย่าอนุมานข้อมูลเหล่านี้จากเว็บไซต์กำกับดูแลเพียงอย่างเดียว
ตัวอย่างโดยละเอียด
สมมติว่าข้อเสนอจะลดเกณฑ์การชำระบัญชีของตลาดสินเชื่อจาก 75% เป็น 60% การลงคะแนนสิ้นสุด Monday 12:00 UTC แต่ผู้เสนอเพิ่งกำหนดเวลาปฏิบัติการใน Tuesday 18:00 UTC ระยะหน่วงที่กำหนดคือ 48 hours ดังนั้นเวลาดำเนินการเร็วที่สุดคือ Thursday 18:00 UTC ไม่ใช่ Wednesday 12:00 UTC
ปฏิบัติการกำหนดสัญญาจัดการความเสี่ยงเป็น target กำหนด value ของโทเคนดั้งเดิมเป็นศูนย์ ใช้การเปลี่ยนพารามิเตอร์ที่เข้ารหัสเป็น data ไม่มีปฏิบัติการก่อนหน้า และเปิดเผย salt เมื่อนำฟิลด์เหล่านี้มาคำนวณแฮชใหม่ ผลต้องตรงกับ Operation ID ที่ event แสดง ที่อยู่ตลาด เกณฑ์ หรือ salt ที่ต่างออกไปถือเป็นคนละปฏิบัติการ แม้คำอธิบายบนหน้าจอจะดูเหมือนกัน
ดังนั้นผู้ใช้มีเวลา 48 hours นับจากการกำหนดเวลา แต่เวลาถอนออกที่ใช้ได้จริงสั้นกว่า หากการแจ้งเตือนมาถึงหลังการกำหนดเวลา 6 hours และคิว unstaking หรือถอนเงินใช้เวลา 24 hours จะเหลือเวลาสำรองเพียง 18 hours:
usable response time = ready time - detection time - exit settlement time
หาก Multisig ฉุกเฉินสั่งพักการถอนได้ทันที อำนาจนี้อาจลดความเสียหายระหว่างเหตุการณ์ แต่ก็อาจทำให้ถอนออกก่อนการเปลี่ยนแปลงในคิวไม่ได้เช่นกัน จึงต้องตรวจสอบอำนาจนี้แยกต่างหาก หลังดำเนินการให้ตรวจสถานะ storage จริงของเป้าหมายและ event ที่ปล่อยออกมา ธุรกรรมดำเนินการของ Timelock อาจสำเร็จทั้งที่ยังมีความเข้าใจผิดเกี่ยวกับผลทางเศรษฐกิจที่คาดไว้
ความเสี่ยงและการควบคุม
- อำนาจที่ใช้ข้าม Timelock แจกแจงเจ้าของ ผู้ดูแล Proxy บทบาทควบคุมการเข้าถึง Upgrade Beacon คณะทำงานฉุกเฉิน โมดูล และผู้ดำเนินการข้ามเชน เส้นทางที่มีสิทธิพิเศษและสั้นที่สุดเป็นตัวกำหนดระยะหน่วงที่แท้จริง
- การเปลี่ยน payload หรือถอดรหัสไม่ถูกต้อง คำนวณ Operation ID ใหม่จากฟิลด์ดิบ ตรวจหา implementation ของ Proxy ถอดรหัส selector และ argument ทุกรายการ และจำลองการทำงานของทั้งชุด ข้อความข้อเสนอที่คนอ่านเข้าใจไม่ใช่ payload ที่นำไปดำเนินการ
- การแจ้งเตือนไม่เพียงพอ ตั้งการแจ้งเตือนจาก event การกำหนดเวลาและยกเลิกบนเชน ไม่ใช่เฉพาะโพสต์ในฟอรัม วัดระยะเวลาแจ้งเตือนจากการกำหนดเวลาที่ได้รับการยืนยันไปจนถึงบล็อกหรือ timestamp แรกที่ดำเนินการได้ แล้วหักเวลาตรวจพบและเวลาชำระการถอนออก
- การยกเลิกล้มเหลว ยืนยันว่าบัญชีใดยกเลิกได้ บัญชียังใช้งานได้หรือไม่ ต้องใช้เกณฑ์เท่าใด และยังยกเลิกได้หรือไม่หลังปฏิบัติการพร้อมแล้ว ควรซ้อมส่งธุรกรรมก่อนเกิดเหตุ
- ผู้ดำเนินการล้มเหลวหรือเล่นกับจังหวะเวลา ผู้ดำเนินการแบบจำกัดสิทธิอาจไม่พร้อมใช้งานหรือจงใจชะลอการดำเนินการ การเปิดให้ทุกคนดำเนินการช่วยเพิ่มความพร้อมใช้งาน แต่ทำให้บุคคลที่สามดำเนินการได้ทันทีเมื่อครบกำหนด ราคา การอัปเดต Oracle และสถานะของผู้ใช้ที่เกี่ยวข้องจึงต้องปลอดภัย ณ ขอบเขตเวลานั้น
- ปฏิบัติการเก่าค้างอยู่ในคิว หากไม่มีการหมดอายุ ปฏิบัติการเก่าที่พร้อมแล้วอาจดำเนินการได้ตลอดไป ต้องติดตามและยกเลิกปฏิบัติการที่เลิกใช้โดยชัดเจน หากมีระยะผ่อนผัน ให้ติดตามเวลาสิ้นสุดอย่างแม่นยำและบังคับให้เริ่มวงจรกำกับดูแลใหม่หลังหมดอายุ
- ความเสี่ยงจาก dependency และการทำงานแบบชุด ตรวจสอบ ID ของปฏิบัติการก่อนหน้าและลำดับในชุดแบบ atomic การเรียกเพียงรายการเดียวที่ revert อาจขัดขวางทั้งชุด และ dependency ที่ไม่ถูกต้องอาจทำให้ปฏิบัติการที่ใช้ได้ติดตาย
- การดูแลระบบที่ไม่ปลอดภัย ให้การลดระยะหน่วง การมอบบทบาท และการเปลี่ยน Timelock อยู่ภายใต้ Timelock เอง นำผู้ดูแลที่ใช้ตอนติดตั้งออก รักษาผู้เสนอและผู้ดำเนินการที่ใช้งานได้อย่างน้อยอย่างละหนึ่งราย และหลีกเลี่ยงการตั้งค่าที่ทำให้การควบคุมถูกล็อกถาวร
- ไม่มีทางออกที่เชื่อถือได้ เปรียบเทียบระยะหน่วงกับคิวถอนเงิน Finality ของ Bridge สภาพคล่องตลาด อำนาจพักระบบ และความแออัด ระยะหน่วงที่ประกาศไม่ช่วยคุ้มครองผู้ใช้หากสินทรัพย์ออกจากระบบไม่ได้ก่อนดำเนินการ
มาตรฐานด้านการปฏิบัติงานคือไทม์ไลน์ที่มีหลักฐานรองรับ ไม่ใช่เพียงตัวนับถอยหลังบนหน้าจอ เก็บถาวร event การกำหนดเวลา คำสั่งที่ถอดรหัสแล้ว ผลการจำลอง ผู้ถือบทบาท แผนยกเลิก เวลาดำเนินการเร็วที่สุดและช้าที่สุด ช่องทางสื่อสาร และความแตกต่างของสถานะหลังดำเนินการ
ความเข้าใจผิดที่พบบ่อย
- “ระยะหน่วงเริ่มเมื่อการลงคะแนนสิ้นสุด” โดยทั่วไปจะเริ่มเมื่อการดำเนินการที่ผ่านมติถูกกำหนดเวลา เว้นแต่ implementation ที่ติดตั้งจะผูกสองช่วงเวลานี้ไว้โดยชัดเจน
- “ทุกคนดำเนินการได้ ดังนั้นทุกคนจึงแก้ข้อเสนอได้” ผู้ดำเนินการแบบเปิดเรียกใช้ได้เฉพาะ payload ที่กำหนดเวลาไว้แล้วและมี Operation ID รวมถึงเงื่อนไขตรงกันเท่านั้น
- “พร้อมหมายความว่าต้องดำเนินการทันที” พร้อมหมายถึงมีสิทธิดำเนินการ แต่ยังต้องมีธุรกรรม สิทธิครบถ้วน dependency ที่เสร็จสิ้น และการเรียกเป้าหมายที่สำเร็จ
- “Timelock ทุกแบบมีช่วงเวลาดำเนินการ” การหมดอายุแตกต่างกันตาม implementation โดย Compound v2 ใช้ระยะผ่อนผัน ส่วน
TimelockControllerของ OpenZeppelin จะไม่ทำให้ปฏิบัติการที่พร้อมแล้วหมดอายุเป็นค่าเริ่มต้น - “Timelock ที่ยาวนานขจัดความเสี่ยงด้านการกำกับดูแล” ระยะหน่วงช่วยได้ก็ต่อเมื่อการติดตาม การทำความเข้าใจ การยกเลิกหรือพัก การสื่อสาร และการถอนออกทำได้จริงก่อนดำเนินการ ผู้ดูแลระบบคู่ขนานและการถอนที่ถูกระงับอาจลบประโยชน์ทั้งหมด
หัวข้อที่เกี่ยวข้อง
แหล่งที่มา
- Governance API: TimelockController - OpenZeppelin Documentation (เข้าถึง: 2026-08-20)
- Access Control: Delayed operation - OpenZeppelin Documentation (เข้าถึง: 2026-08-20)
- Timelock.sol - Compound Finance (เข้าถึง: 2026-08-20)
- GovernorBravoDelegate.sol - Compound Finance (เข้าถึง: 2026-08-20)