timelock とは
注：この文書は英語の原文からの自動翻訳です。
timelock とは
timelock とは、スマートコントラクト に組み込まれた仕組みで、変更が提案された瞬間と、実際にそれが実行できる瞬間との間に強制的な遅延を課すものです。この遅延期間の間、誰でも — ユーザー、トークン保有者、セキュリティ研究者 — が保留中の変更を検査し、その影響を評価し、変更が有効になる前に（資金の引き出しなどの）行動を取るかどうかを判断できます。
timelock は、新しい法律が施行される前の公示期間のようなものだと考えてください。法律は可決されますが、市民には施行可能になる前にそれを読み、理解し、調整するための定められた期間 — たとえば 30 日間 — があります。timelock はスマートコントラクトの変更に対して同じことを行います：今後の変更を透明にし、コミュニティに対応する時間を与えるのです。
要約： timelock は、スマートコントラクトの変更の実行を一定期間遅らせるセキュリティパターンで、関係者に変更が適用される前にレビュー、対応、または退出する時間を与えます。
timelock の仕組み
queue-and-execute パターン
timelock コントラクトは二段階のプロセスで動作します：
- Queue（キュー登録） — 権限を持つ当事者（通常は admin key の保有者、multisig ウォレット、またはガバナンスコントラクト）が、提案されたトランザクションを timelock コントラクトに提出します。そのトランザクションはタイムスタンプ付きでオンチェーンに記録され、待機期間に入ります。
- Execute（実行） — 遅延期間が経過した後、再び timelock コントラクトを呼び出すことでトランザクションを実行できます。遅延が経過していなければ、実行の呼び出しはリバートします。一部の timelock 実装には grace period（猶予期間） も含まれます — これは遅延後の最大の期間で、その間にトランザクションを実行しなければ期限切れになります。
このパターンは、たとえ攻撃者が admin key を侵害しても、即座に変更を行うことはできないことを意味します。遅延は、コミュニティが悪意あるトランザクションをキュー内で検知し、保護的な行動を取るための期間を与えます。
遅延期間
timelock の遅延は、プロジェクトや制御される変更の深刻度によって異なります。一般的な範囲は次のとおりです：
- 24〜48 時間 — 日常的なパラメータ調整（手数料変更、報酬率）向け。
- 2〜7 日 — 重要なコントラクトアップグレードやコアプロトコルロジックの変更向け。
- 14〜30 日 — 新しいコントラクトへの移行や基本的な経済パラメータの変更などの重大な変更向け。
適切な遅延は、セキュリティ（遅延が長いほど反応時間が増える）と運用上の機動性（遅延が短いほどバグ修正のような正当なニーズへの迅速な対応が可能になる）とのトレードオフによって決まります。
timelock の透明性
キュー登録されたすべてのトランザクションはオンチェーンに記録されるため、監視ツールやコミュニティメンバーは、timelock キューへの新しいエントリに対するアラートを設定できます。いくつかのブロックチェーン分析プラットフォームや通知サービスは、DeFi プロトコルや DAO 向けに特化した timelock 監視を提供しています。この透明性こそが timelock のセキュリティ価値の源です — それは一方的な admin 権限を、観測可能で期間が区切られた admin 権限へと変えます。
crypto AI プロジェクトにとって timelock が重要な理由
突然の変更からユーザーを守る
crypto AI プロジェクトは、しばしばスマートコントラクトを通じて多額のユーザー資金、計算リソース、データへのコミットメントを管理します。timelock がなければ、admin key の保有者はコントラクトのルールを即座に変更できてしまいます — 報酬の付け替え、手数料構造の改変、ユーザーに害を及ぼす形でのコントラクトロジックのアップグレードなどです。timelock は、そうした変更が事前に可視化されることを保証し、ユーザーにポジションを引き出したり調整したりする選択肢を与えます。
侵害された鍵による被害の制限
十分に保護された admin keys でさえ、フィッシング、ソーシャルエンジニアリング、インフラ侵害を通じて侵害される可能性があります。timelock は第二の防御線として機能します：たとえ攻撃者が admin アクセスを得ても、timelock の遅延が許す以上の速さで変更を実行することはできません。コミュニティとプロジェクトチームは、その遅延期間に、不正なトランザクションをキュー内で検知し、対応を調整し、（一部の実装では）保留中の変更をキャンセルできます。
運用の成熟度のシグナル
プロジェクトカードをレビューする評価者にとって、重要なコントラクト機能に timelock が存在することは、チームが運用セキュリティを真剣に検討したシグナルです。timelock を multisig の admin key と組み合わせるプロジェクトは、多層的なセキュリティ — 単一の仕組みに依存するのではなく、複数の独立したセーフガード — を示しています。
DecAIHub のプロジェクトカードでどこに現れるか
- Admin keys — admin が制御する機能に timelock があるかないかは、チームがどれだけの一方的な権限を保持しているかを評価するうえで重要な要素です。「admin keys は 48 時間 timelock 付きの multisig が保有」と記すプロジェクトカードは、「admin keys は timelock なしの単一 EOA が保有」とは意味的に異なるセキュリティ態勢を表します。
- スマートコントラクトアーキテクチャ — timelock はより広範なスマートコントラクトセキュリティ設計の一部です。ロジックを変更する能力が必要でありながら危険でもあるアップグレードパターン（proxy コントラクト、beacon コントラクト）と並んで現れることがよくあります。
- ガバナンス — オンチェーンガバナンスを持つプロジェクトでは、timelock は通常、ガバナンス投票と承認された提案の実行の間に置かれます。この最終的な遅延は、可決された提案に反対し退出する時間を必要とする少数の関係者を保護します。
timelock だけでは証明できないこと
- コードのセキュリティ — timelock は変更を遅らせますが、それらを監査するわけではありません。欠陥のあるアップグレードは、正しいアップグレードと同じくらい簡単に timelock を通過できます。timelock は 不意打ち から守るものであって、悪い設計 から守るものではありません。
- 変更が捕捉されること — timelock は、誰かがキューを積極的に監視している場合にのみ価値があります。コミュニティメンバー、セキュリティ研究者、監視ツールのいずれも見ていなければ、悪意あるキュー登録トランザクションは遅延期間を気づかれずに通過し得ます。
- 分散化 — 単一の admin key への timelock は透明性を加えますが、制御を分散させるわけではありません。真の分散化には、timelock を分散ガバナンス（multisig、DAO 投票、トークン保有者ガバナンス）と組み合わせることが必要です。
- 保護の不可逆性 — timelock をデプロイしたチームは、ガバナンスアクションを通じてそれを削除したり遅延を短縮したりできる場合があります。timelock の恒久性は、timelock 自体が改変から保護されているかどうかに依存します。
混同しないでください
| 用語 | 区別 |
|---|---|
| ベスティング | ベスティングは、割り当てられたトークンの時間ベースのリリーススケジュールです。timelock は、スマートコントラクトの変更に対するセキュリティ遅延です。ベスティングはトークンがいつ保有者に利用可能になるかを制御し、timelock はコントラクトの改変がいつ有効になるかを制御します。 |
| multisig | multisig は、アクションを承認するために複数の署名を必要とします。timelock は、承認後の遅延を強制します。両者は補完的なレイヤーです — multisig は誰が行えるかを統制し、timelock はいつ行えるかを統制します。 |
| ガバナンス遅延（Governance delay） | 一部のガバナンスシステムには、timelock と同様に機能する組み込みの投票期間があります。timelock は決定が下された後に適用される特定のスマートコントラクト機構であり、ガバナンス遅延は決定そのものにかかる時間（投票期間、定足数）です。 |
よくある質問
timelock は回避できますか？
適切に実装された timelock では、いいえ — 遅延はスマートコントラクトレベルで強制され、どの当事者もそれをスキップできません。ただし、実装上のバグ、proxy コントラクトの構成、または緊急オーバーライド機構（「guardian」鍵と呼ばれることがあります）が回避経路を導入することがあります。プロジェクトの timelock を評価する際は、緊急オーバーライドが存在するか、誰がそれを制御しているかを知ることが重要です。
典型的な timelock の遅延はどのくらいですか？
普遍的な標準はありません。遅延は、変更の種類とプロジェクトのリスク許容度に応じて、数時間から数週間に及びます。短い遅延（24 時間）はより迅速な運用対応を可能にしますが、コミュニティに与える反応時間は少なくなります。長い遅延（7 日以上）は強力な保護を提供しますが、正当な問題に対応するプロジェクトの能力を遅くします。確立されたほとんどの DeFi プロトコルは、日常的な変更には 24〜72 時間を、重大なアップグレードにはより長い遅延を用います。
timelock は multisig とどのように相互作用しますか？
timelock と multisig は補完的なセキュリティレイヤーです。multisig は、単一の鍵保有者が変更を開始できないことを保証します。timelock は、multisig が変更を承認した後でさえ、それが即座に有効にならないことを保証します。両者は合わさって、分散された承認と公開レビューの時間の両方を提供します — これは高価値のスマートコントラクトシステムで一般的に用いられる構成です。
外部リンク
- OpenZeppelin TimelockController Documentation — Solidity スマートコントラクトで最も広く使われている timelock 実装の技術リファレンス。
No comments to display
No comments to display