Lompat ke konten
Financial Context Wiki

Bagaimana timelock tata kelola bekerja?

Timelock tata kelola mengubah tindakan yang disetujui menjadi operasi yang dapat diamati publik dan harus menunggu sebelum dieksekusi. Pelajari cara kerja ID, peran, penundaan, kedaluwarsa, pembatalan, dan jendela keluar.

Diperbarui

Hanya untuk tujuan edukasi; bukan nasihat investasi. Investasi dapat mengakibatkan kerugian.

Jawaban langsung

Timelock tata kelola adalah pengendali eksekusi, bukan pemungutan suara tambahan. Setelah tata kelola mengesahkan suatu payload, pengusul yang disetujui menjadwalkan operasi yang persis. Kontrak mencatat kapan operasi itu boleh dieksekusi dan menolak eksekusi sebelum waktunya. Penundaan ini membuat peningkatan, perubahan parameter, transfer perbendaharaan, atau perubahan peran yang tertunda dapat diamati sebelum berlaku.

Durasi penundaan yang ditampilkan hanyalah satu bagian dari pengendalian. Tinjau ID operasi, waktu eksekusi paling awal, aturan kedaluwarsa jika ada, pendahulu, pengusul, pelaksana, pembatal, administrator, dan setiap jalur lain yang dapat mengendalikan target. Timelock 48-hour tidak memberikan jendela keluar 48-hour jika operasi terlambat dijadwalkan, pemantauan terlambat, penarikan memerlukan waktu lebih lama, atau kunci istimewa lain dapat langsung melakukan perubahan yang sama.

Timelock tidak menentukan apakah suatu tindakan sah atau aman. Timelock menyediakan waktu bagi orang dan pemantau otomatis untuk mendekode panggilan, menyimulasikan dampaknya, membatalkan atau menjeda jika berwenang, mengomunikasikan perubahan, dan keluar dari posisi jika jalur keluar yang nyata tersedia.

Cara kerjanya

  1. Wewenang diberikan kepada timelock. Timelock harus memiliki target atau memegang peran yang relevan pada kontrak target. Jika governor tidak mempunyai wewenang atas target, disahkannya proposal tidak mengubah apa pun; jika administrator terpisah mempertahankan wewenang paralel, jalur tersebut dapat melewati penundaan.
  2. Pengusul menjadwalkan operasi yang persis. Dalam TimelockController OpenZeppelin, ID operasi tunggal adalah hash dari target, value, data, predecessor, dan salt; operasi batch melakukan hash terhadap array yang bersesuaian beserta dependensi dan salt yang sama. Perubahan pada bidang mana pun menghasilkan ID operasi yang berbeda. Salt membedakan tindakan yang selain itu identik.
  3. Penundaan minimum dimulai ketika penjadwalan dilakukan. Pemungutan suara yang berhasil belum tentu memulai timelock. Penjadwalan mencatat stempel waktu siap dengan penundaan yang sekurang-kurangnya sama dengan minimum kontrak saat itu. Operasi OpenZeppelin berpindah dari Unset ke Waiting, kemudian Ready, dan akhirnya Done setelah berhasil dieksekusi.
  4. Dependensi dan izin diperiksa saat eksekusi. Operasi pendahulu harus sudah berstatus Done. Pemanggil harus memenuhi aturan pelaksana dan panggilan target harus berhasil. Pelaksana tidak dapat mengubah payload yang telah dijadwalkan. Memberikan peran pelaksana kepada address(0) membuat eksekusi terbuka bagi siapa saja setelah jatuh tempo. Hal ini meningkatkan ketersediaan, tetapi memungkinkan akun mana pun memilih tepat kapan operasi yang sudah memenuhi syarat dieksekusi.
  5. Pembatalan mengembalikan operasi tertunda ke keadaan awal. Dalam kontrak OpenZeppelin saat ini, akun dengan CANCELLER_ROLE dapat membatalkan operasi selama masih tertunda, termasuk ketika sudah siap tetapi belum dieksekusi. Penjadwalan ulang memulai penghitung waktu baru. Susunan peran sangat penting: versi lama dan timelock lain dapat memberikan hak pembatalan kepada pengusul atau administrator.
  6. Kedaluwarsa bergantung pada implementasi. TimelockController OpenZeppelin tidak memiliki kedaluwarsa masa tenggang bawaan; operasi yang siap akan tetap siap sampai dieksekusi atau dibatalkan. Sebaliknya, Timelock Compound v2 mengharuskan eksekusi paling lambat pada eta + GRACE_PERIOD, dan kode sumbernya menetapkan GRACE_PERIOD sebesar 14 days. Governor Bravo menandai proposal yang sudah masuk antrean sebagai kedaluwarsa setelah batas tersebut.
  7. Administrasi juga harus ditunda. OpenZeppelin hanya mengizinkan updateDelay melalui panggilan dari timelock kepada dirinya sendiri. Penerapan yang dikelola sendiri juga memaksa perubahan peran melalui operasi terjadwal. Administrator eksternal sementara yang digunakan saat penyiapan harus melepaskan peran tersebut setelah konfigurasi; jika tidak, peran itu tetap menjadi jalur kepercayaan tersendiri.

Untuk setiap tindakan yang dijadwalkan, susun kembali catatan pengendalian dari status dan peristiwa kontrak: ID chain, alamat timelock dan target, ID operasi, payload yang telah didekode, pengusul, transaksi dan waktu penjadwalan, penundaan minimum, waktu siap, waktu kedaluwarsa jika ada, pendahulu, kebijakan pelaksana, wewenang pembatalan, dan status transaksi akhir. Jangan menyimpulkan bidang-bidang ini hanya dari situs web tata kelola.

Contoh terperinci

Anggaplah sebuah proposal menurunkan ambang likuidasi pasar pinjaman dari 75% menjadi 60%. Pemungutan suara berakhir pada Monday 12:00 UTC, tetapi pengusul baru menjadwalkan operasi pada Tuesday 18:00 UTC. Penundaan yang dijadwalkan adalah 48 hours, sehingga waktu eksekusi paling awal adalah Thursday 18:00 UTC, bukan Wednesday 12:00 UTC.

Operasi tersebut mencantumkan kontrak pengelola risiko sebagai target, nilai token native nol sebagai value, perubahan parameter yang dienkode sebagai data, tanpa pendahulu, dan salt yang diungkapkan. Hash yang dihitung ulang dari bidang-bidang tersebut harus sama dengan ID operasi yang dipancarkan. Alamat pasar, ambang, atau salt yang berbeda menghasilkan operasi yang berbeda, meskipun deskripsi pada antarmuka tampak sama.

Karena itu, pengguna memiliki 48 hours sejak penjadwalan, tetapi waktu keluar yang benar-benar dapat digunakan lebih singkat. Jika peringatan tiba 6 hours setelah penjadwalan dan antrean unstaking atau penarikan memerlukan 24 hours, hanya tersisa penyangga 18 hours:

usable response time = ready time - detection time - exit settlement time

Jika multisig darurat dapat langsung menjeda penarikan, multisig tersebut dapat mengurangi kerugian saat insiden, tetapi juga dapat membuat pengguna tidak bisa keluar sebelum perubahan yang dijadwalkan. Tinjau wewenang itu secara terpisah. Setelah eksekusi, verifikasi penyimpanan aktual target dan peristiwa yang dipancarkan; transaksi eksekusi timelock dapat berhasil meskipun hasil ekonomi yang diharapkan masih disalahpahami.

Risiko dan pengendalian

  • Wewenang untuk melewati timelock. Daftar semua pemilik, administrator proxy, peran kontrol akses, beacon peningkatan, dewan darurat, modul, dan pelaksana lintas chain. Jalur istimewa terpendek menentukan penundaan efektif.
  • Penggantian payload atau pendekodean yang buruk. Hitung ulang ID operasi dari bidang mentah, identifikasi implementasi proxy, dekode setiap selector dan argumen, lalu simulasikan seluruh batch. Teks proposal yang mudah dibaca bukanlah payload yang dieksekusi.
  • Pemberitahuan tidak memadai. Buat peringatan dari peristiwa penjadwalan dan pembatalan on-chain, bukan hanya unggahan forum. Ukur waktu pemberitahuan dari penjadwalan yang telah dikonfirmasi hingga blok atau stempel waktu paling awal yang dapat dieksekusi, lalu kurangi waktu deteksi dan penyelesaian keluar.
  • Kegagalan pembatalan. Pastikan akun mana yang dapat membatalkan, apakah akun itu aktif, ambang yang diperlukan, dan apakah pembatalan tetap dapat dilakukan setelah operasi siap. Latih transaksi tersebut sebelum terjadi insiden.
  • Kegagalan pelaksana atau permainan waktu. Pelaksana terbatas dapat tidak tersedia atau sengaja menunda eksekusi. Eksekusi terbuka meningkatkan ketersediaan, tetapi memungkinkan pihak ketiga mengeksekusi tepat ketika operasi jatuh tempo. Karena itu, harga terkait, pembaruan oracle, dan posisi pengguna harus aman pada batas waktu tersebut.
  • Operasi lama dalam antrean. Jika tidak ada kedaluwarsa, operasi lama yang sudah siap dapat tetap bisa dieksekusi tanpa batas waktu. Pantau dan batalkan secara tegas operasi yang ditinggalkan. Jika ada masa tenggang, pantau waktu berakhirnya secara tepat dan wajibkan siklus tata kelola baru setelah kedaluwarsa.
  • Risiko dependensi dan batch. Verifikasi ID pendahulu dan urutan batch atomik. Satu panggilan yang revert dapat menggagalkan seluruh batch atomik; dependensi yang keliru dapat membuat operasi yang sebenarnya valid macet permanen.
  • Administrasi tidak aman. Jadikan pengurangan penundaan, pemberian peran, dan penggantian timelock tunduk pada timelock itu sendiri. Hapus administrator penerapan, pertahankan setidaknya satu pengusul dan pelaksana yang berfungsi, serta hindari konfigurasi yang mengunci kendali secara permanen.
  • Tidak ada jalur keluar yang layak. Bandingkan penundaan dengan antrean penarikan, finalitas bridge, likuiditas pasar, wewenang penjeda, dan kemacetan. Penundaan yang dipublikasikan tidak melindungi pengguna jika aset tidak dapat keluar sebelum eksekusi.

Standar operasionalnya adalah linimasa berbasis bukti, bukan sekadar hitung mundur yang ditampilkan. Arsipkan peristiwa penjadwalan, panggilan yang didekode, hasil simulasi, pemegang peran, rencana pembatalan, waktu eksekusi paling awal dan paling akhir, saluran komunikasi, serta perbedaan status setelah eksekusi.

Kesalahpahaman umum

  • “Penundaan dimulai ketika pemungutan suara berakhir.” Biasanya penundaan dimulai ketika tindakan yang berhasil dijadwalkan, kecuali implementasi yang digunakan secara tegas menghubungkan kedua momen tersebut.
  • “Siapa pun dapat mengeksekusi, jadi siapa pun dapat mengubah proposal.” Pelaksana terbuka hanya dapat memicu payload yang sudah dijadwalkan dan memiliki ID operasi serta kondisi yang cocok.
  • “Siap berarti tindakan harus langsung dieksekusi.” Siap berarti memenuhi syarat. Eksekusi tetap memerlukan transaksi, izin, dependensi yang terpenuhi, dan panggilan target yang berhasil.
  • “Setiap timelock memiliki jendela eksekusi.” Kedaluwarsa berbeda-beda menurut implementasi. Compound v2 menggunakan masa tenggang; TimelockController OpenZeppelin secara default tidak membuat operasi siap menjadi kedaluwarsa.
  • “Timelock yang panjang menghilangkan risiko tata kelola.” Penundaan hanya membantu jika pemantauan, pemahaman, pembatalan atau penjedaaan, komunikasi, dan keluar semuanya dapat dilakukan sebelum eksekusi. Administrator paralel dan penarikan yang terblokir dapat meniadakan manfaatnya.

Topik terkait

Sumber

Navigasi

Cari di wiki...