---
title: "Governance Timelock ทำงานอย่างไร"
description: "Governance Timelock เปลี่ยนการดำเนินการที่ได้รับอนุมัติให้เป็นปฏิบัติการที่สาธารณชนตรวจสอบได้และต้องรอก่อนดำเนินการ เรียนรู้การทำงานของ ID บทบาท ระยะหน่วง การหมดอายุ การยกเลิก และช่วงเวลาถอนออก"
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.

# Governance Timelock ทำงานอย่างไร

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

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

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

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

ระยะหน่วงที่ประกาศเป็นเพียงส่วนหนึ่งของการควบคุม ต้องตรวจสอบ Operation ID เวลาดำเนินการเร็วที่สุด กฎการหมดอายุหากมี ปฏิบัติการก่อนหน้า ผู้เสนอ ผู้ดำเนินการ ผู้ยกเลิก ผู้ดูแลระบบ และทุกช่องทางอื่นที่ควบคุมสัญญาเป้าหมายได้ Timelock `48-hour` ไม่ได้ทำให้มีช่วงเวลาถอนออก `48-hour` หากกำหนดเวลาปฏิบัติการล่าช้า ระบบติดตามแจ้งเตือนช้า การถอนใช้เวลานานกว่า หรือกุญแจที่มีสิทธิพิเศษชุดอื่นทำการเปลี่ยนแปลงเดียวกันได้ทันที

Timelock ไม่ได้ตัดสินว่าการดำเนินการชอบธรรมหรือปลอดภัยหรือไม่ แต่ให้เวลาผู้ใช้และระบบติดตามอัตโนมัติถอดรหัสคำสั่ง จำลองผลกระทบ ยกเลิกหรือพักการดำเนินการเมื่อมีอำนาจ แจ้งการเปลี่ยนแปลง และถอนออกจากสถานะเมื่อมีช่องทางถอนออกที่ใช้ได้จริง

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

## กลไกการทำงาน

1. **ต้องมอบอำนาจให้ Timelock** Timelock ต้องเป็นเจ้าของหรือถือบทบาทที่เกี่ยวข้องในสัญญาเป้าหมาย หาก Governor ไม่มีอำนาจเหนือเป้าหมาย การผ่านข้อเสนอก็ไม่ทำให้เกิดการเปลี่ยนแปลง หากผู้ดูแลระบบอีกชุดยังมีอำนาจคู่ขนาน ช่องทางนั้นอาจข้ามระยะหน่วงได้
2. **ผู้เสนอกำหนดเวลาปฏิบัติการตามรายละเอียดที่แน่นอน** ใน `TimelockController` ของ OpenZeppelin ID ของปฏิบัติการเดี่ยวคือแฮชของ `target`, `value`, `data`, `predecessor` และ `salt` ส่วนปฏิบัติการแบบชุดจะแฮชอาร์เรย์ที่เกี่ยวข้องพร้อม dependency และ salt เดียวกัน การเปลี่ยนฟิลด์ใดก็ตามจะสร้าง Operation ID ใหม่ Salt ใช้แยกการดำเนินการที่เหมือนกันทุกประการในด้านอื่น
3. **ระยะหน่วงขั้นต่ำเริ่มเมื่อกำหนดเวลา** การลงคะแนนสำเร็จไม่ได้หมายความว่า Timelock เริ่มนับเวลาเสมอไป การกำหนดเวลาจะบันทึก timestamp ที่พร้อมดำเนินการโดยใช้ระยะหน่วงไม่น้อยกว่าค่าขั้นต่ำปัจจุบันของสัญญา ปฏิบัติการ OpenZeppelin เปลี่ยนสถานะจาก `Unset` เป็น `Waiting` จากนั้นเป็น `Ready` และสุดท้ายเป็น `Done` หลังดำเนินการสำเร็จ
4. **ตรวจสอบ dependency และสิทธิเมื่อดำเนินการ** ปฏิบัติการก่อนหน้าต้องอยู่ในสถานะ `Done` แล้ว ผู้เรียกต้องผ่านเงื่อนไขของผู้ดำเนินการ และการเรียกสัญญาเป้าหมายต้องสำเร็จ ผู้ดำเนินการเปลี่ยน payload ที่กำหนดเวลาไว้ไม่ได้ การมอบบทบาทผู้ดำเนินการให้ `address(0)` ทำให้ทุกคนดำเนินการได้หลังครบกำหนด ซึ่งช่วยให้ระบบพร้อมใช้งานมากขึ้น แต่ก็เปิดให้บัญชีใดก็ได้เลือกจังหวะที่แน่นอนในการดำเนินการทันทีที่เข้าเงื่อนไข
5. **การยกเลิกทำให้ปฏิบัติการที่รอดำเนินการกลับสู่สถานะเริ่มต้น** ในสัญญา OpenZeppelin รุ่นปัจจุบัน บัญชีที่มี `CANCELLER_ROLE` ยกเลิกปฏิบัติการได้ขณะที่ยังรอดำเนินการ รวมถึงเมื่อพร้อมแล้วแต่ยังไม่ได้ดำเนินการ การกำหนดเวลาใหม่จะเริ่มนับเวลาใหม่ การกำหนดบทบาทจึงสำคัญ เพราะรุ่นเก่าและ Timelock แบบอื่นอาจให้สิทธิยกเลิกแก่ผู้เสนอหรือผู้ดูแลระบบ
6. **การหมดอายุขึ้นอยู่กับแต่ละ implementation** `TimelockController` ของ OpenZeppelin ไม่มีการหมดอายุตามระยะผ่อนผันในตัว ปฏิบัติการที่พร้อมแล้วจะคงสถานะพร้อมจนกว่าจะดำเนินการหรือยกเลิก ในทางกลับกัน Timelock ของ Compound v2 กำหนดให้ดำเนินการไม่เกิน `eta + GRACE_PERIOD` และซอร์สโค้ดกำหนด `GRACE_PERIOD` ไว้ที่ `14 days` ส่วน Governor Bravo จะระบุว่าข้อเสนอที่เข้าคิวหมดอายุเมื่อพ้นขอบเขตนี้
7. **การดูแลระบบต้องถูกหน่วงเวลาด้วย** OpenZeppelin อนุญาตให้เรียก `updateDelay` ผ่านการเรียกจาก Timelock กลับมาหาตัวเองเท่านั้น การติดตั้งแบบดูแลตัวเองจะบังคับให้เปลี่ยนบทบาทผ่านปฏิบัติการที่กำหนดเวลาเช่นกัน ผู้ดูแลระบบภายนอกชั่วคราวที่ใช้ระหว่างการตั้งค่าควรสละบทบาทหลังตั้งค่าเสร็จ มิฉะนั้นจะยังเป็นช่องทางความไว้วางใจอีกช่องทางหนึ่ง

สำหรับทุกการดำเนินการในคิว ให้สร้างบันทึกควบคุมขึ้นใหม่จากสถานะและ event ของสัญญา ได้แก่ Chain ID ที่อยู่ Timelock และเป้าหมาย Operation ID, payload ที่ถอดรหัสแล้ว ผู้เสนอ ธุรกรรมและเวลาที่กำหนด ระยะหน่วงขั้นต่ำ เวลาที่พร้อม เวลาหมดอายุหากมี ปฏิบัติการก่อนหน้า นโยบายผู้ดำเนินการ อำนาจยกเลิก และสถานะธุรกรรมสุดท้าย อย่าอนุมานข้อมูลเหล่านี้จากเว็บไซต์กำกับดูแลเพียงอย่างเดียว

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

## ตัวอย่างโดยละเอียด

สมมติว่าข้อเสนอจะลดเกณฑ์การชำระบัญชีของตลาดสินเชื่อจาก `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 อาจสำเร็จทั้งที่ยังมีความเข้าใจผิดเกี่ยวกับผลทางเศรษฐกิจที่คาดไว้

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

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

- **อำนาจที่ใช้ข้าม 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 การกำหนดเวลา คำสั่งที่ถอดรหัสแล้ว ผลการจำลอง ผู้ถือบทบาท แผนยกเลิก เวลาดำเนินการเร็วที่สุดและช้าที่สุด ช่องทางสื่อสาร และความแตกต่างของสถานะหลังดำเนินการ

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

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

- **"ระยะหน่วงเริ่มเมื่อการลงคะแนนสิ้นสุด"** โดยทั่วไปจะเริ่มเมื่อการดำเนินการที่ผ่านมติถูกกำหนดเวลา เว้นแต่ implementation ที่ติดตั้งจะผูกสองช่วงเวลานี้ไว้โดยชัดเจน
- **"ทุกคนดำเนินการได้ ดังนั้นทุกคนจึงแก้ข้อเสนอได้"** ผู้ดำเนินการแบบเปิดเรียกใช้ได้เฉพาะ payload ที่กำหนดเวลาไว้แล้วและมี Operation ID รวมถึงเงื่อนไขตรงกันเท่านั้น
- **"พร้อมหมายความว่าต้องดำเนินการทันที"** พร้อมหมายถึงมีสิทธิดำเนินการ แต่ยังต้องมีธุรกรรม สิทธิครบถ้วน dependency ที่เสร็จสิ้น และการเรียกเป้าหมายที่สำเร็จ
- **"Timelock ทุกแบบมีช่วงเวลาดำเนินการ"** การหมดอายุแตกต่างกันตาม implementation โดย Compound v2 ใช้ระยะผ่อนผัน ส่วน `TimelockController` ของ OpenZeppelin จะไม่ทำให้ปฏิบัติการที่พร้อมแล้วหมดอายุเป็นค่าเริ่มต้น
- **"Timelock ที่ยาวนานขจัดความเสี่ยงด้านการกำกับดูแล"** ระยะหน่วงช่วยได้ก็ต่อเมื่อการติดตาม การทำความเข้าใจ การยกเลิกหรือพัก การสื่อสาร และการถอนออกทำได้จริงก่อนดำเนินการ ผู้ดูแลระบบคู่ขนานและการถอนที่ถูกระงับอาจลบประโยชน์ทั้งหมด

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

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

- [DAO](/th/crypto/dao/)
- [การโจมตีระบบกำกับดูแล](/th/crypto/governance-attack/)
- [การพักโปรโตคอลฉุกเฉิน](/th/crypto/protocol-emergency-pause/)
- [สัญญา Proxy](/th/crypto/proxy-contract/)
- [Timelock](/th/crypto/timelock/)

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

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

- [Governance API: TimelockController](https://docs.openzeppelin.com/contracts/5.x/api/governance#TimelockController) - OpenZeppelin Documentation (เข้าถึง: 2026-08-20)
- [Access Control: Delayed operation](https://docs.openzeppelin.com/contracts/5.x/access-control#delayed_operation) - OpenZeppelin Documentation (เข้าถึง: 2026-08-20)
- [Timelock.sol](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Timelock.sol) - Compound Finance (เข้าถึง: 2026-08-20)
- [GovernorBravoDelegate.sol](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/GovernorBravoDelegate.sol) - Compound Finance (เข้าถึง: 2026-08-20)

Source: https://wiki.fcontext.com/th/crypto/governance-timelock-operation/index.mdx