教育目的のみであり、投資助言ではありません。投資は損失につながる可能性があります。
端的な答え
タイムロックとは、指定されたブロック高、タイムスタンプ、または経過期間に達するまで、取引、支出、管理操作を有効または実行可能にしない、ブロックチェーンやスマートコントラクトによって強制される規則です。操作をいつ行えるかを変えるものであり、その操作が正しいかどうかを判断するものではありません。
この用語は異なる仕組みを含みます。取引レベルのタイムロックは、チェーン上の条件が満たされるまでコインを支出不能にしたり、取引を未確定にしたりします。ガバナンスのタイムロックは、すでに承認されたコントラクト呼び出しをキューに入れ、実行者が送信できるまで最小遅延を課します。両者では時計、状態遷移、障害の形が異なります。
安全上の価値は、強制される遅延から生まれます。ガバナンスでは、監視者や利用者がキュー内のペイロードを調べ、警告し、権限のある経路で取消しや一時停止を行い、実際の退出経路があれば離脱する時間を得られます。同じシステムをタイムロックなしで変更できる特権経路があれば、この効果は失われます。
仕組み
- 仕組みが時計を定義します。 閾値にはブロック高、チェーンから得るタイムスタンプ、または過去のオンチェーン事象からの経過時間を使えます。これらはプロトコル上の値であり、正確な実時間を約束するものではありません。
- ロック対象の操作を条件に結び付けます。 絶対タイムロックは将来の高さや時刻を指定します。相対タイムロックは、支出対象出力の承認などの事象から間隔を測ります。ガバナンス制御コントラクトは、予約された操作と準備完了時刻を記録します。
- 該当するレイヤーが待機を強制します。 コンセンサス規則は早すぎる取引やスクリプト支出を拒否でき、スマートコントラクトは早すぎる関数呼び出しを拒否できます。画面を回避できるため、ウェブサイトのカウントダウンだけではタイムロックになりません。
- 満了は資格を変えるだけで、意思は変えません。 条件達成後、操作は有効または実行準備済みになり得ますが、自動で配信・実行されるとは限りません。誰かが送信する必要があり、その他の権限・有効性検査も引き続き適用されます。
- 保護範囲は権限に依存します。 ガバナンスでは、タイムロックが対象コントラクトの所有権または必要なロールを持ち、同等の特権経路もすべて遅延されなければなりません。提案者、取消者、実行者、管理者の権限が、予約、停止、実行、再設定できる主体を決めます。
ビットコインは取引レベルの違いを示します。BIP 65 の CHECKLOCKTIMEVERIFY は、絶対ブロック高または時刻の条件まで出力を支出不能にできます。BIP 68 は、対象入力のシーケンス番号にコンセンサスで強制される相対タイムロックの意味を与え、支出対象出力の経過期間から測定します。これらはガバナンスコントラクトのキューとは別の規則です。
OpenZeppelin の TimelockController はガバナンス遅延の例です。提案者は、最小遅延以上の時間を指定して識別可能な操作を予約します。タイマー満了後に待機から準備完了へ移り、その後に実行者が実行します。取消しとロール管理はコントラクトの規則に従い、最小遅延の変更自体もタイムロックを通す必要があります。
例
キューに入れたプロトコル更新
DAO が更新を承認すると、ガバナーは正確な対象アドレス、値、呼び出しデータ、依存関係、ソルトをタイムロックに予約します。監視ツールは遅延中にペイロードと提案を比較し、影響をシミュレーションできます。操作が準備完了になると、権限を持つ実行者が送信します。
この保護が成立するのは、タイムロックが更新権限を実際に管理している場合だけです。別の所有者、プロキシ管理者、セキュリティ評議会、モジュールが同じ更新を即時に導入できるなら、その回避経路を別途評価する必要があります。また、監視が間に合い、出金や移行が実行前に完了できる場合にのみ、遅延は実用的です。
遅延付き取引経路
スクリプトは期限前の支出経路と、期限後の返金経路を用意できます。チェーンは支出検証時に該当条件を強制します。閾値に達しても資金は自動では移動しません。資格を得た当事者が有効な取引を作成して配信する必要があり、承認には手数料とブロック収録も影響します。
リスクと確認項目
- 権限による回避： 別の所有者、ロール、モジュール、更新鍵、緊急経路が、待機せずに保護対象の操作を実行できます。
- 時計や境界の誤り： ブロック高、チェーン時刻、経過時間は交換可能ではなく、境界を一つ誤ると想定より早く、または遅く支出可能になります。
- 遅延不足： 待機期間が、操作の検出、分析、周知、対応に必要な時間より短い場合があります。
- 現実的な退出手段がない： 出金停止、ブリッジ遅延、流動性不足、アンボンディング、混雑により、名目上の期間内に行動できないことがあります。
- ロール侵害や停止： 悪意ある提案者や管理者は有害な呼び出しを予約でき、実行鍵の紛失や広すぎる取消権は正当な操作を止め得ます。
- ペイロードの不一致： 読みやすい提案名だけでは、予約された対象、値、呼び出しデータ、依存関係、ソルトが承認内容を実装する証明になりません。
- 実装差： 失効、取消し、バッチ、依存関係、公開実行、遅延変更の規則はコントラクトや版によって異なります。
- ロック設定の誤り： 間違ったタイムスタンプ、高さ、シーケンス値、スクリプト分岐、利用不能な鍵により、資産が想定以上に長く利用不能になることがあります。
よくある誤解
タイムロックは満了時に自動実行されますか？
通常はされません。満了は操作を実行可能にするだけです。取引は配信が必要で、ガバナンスコントラクトは実行者による呼び出しが必要です。
タイムロックはガバナンスを安全にしますか？
いいえ。対応時間は作りますが、ペイロード検証、特権鍵の保護、取消しの保証、利用者の退出保証は行いません。遅延のない並行権限が制御を無効にすることもあります。
すべてのタイムロックは実時間に基づきますか？
いいえ。ブロック高、チェーンのタイムスタンプ、相対的な経過期間などが使われます。想定ブロック間隔やタイムスタンプは正確な予定時刻ではありません。
取引とガバナンスのタイムロックは交換可能ですか？
いいえ。どちらも資格を遅らせますが、コンセンサス取引規則、スクリプト条件、アプリケーション層のガバナンスキューは異なる操作を保護するため、それぞれの仕様で確認する必要があります。
関連トピック
出典
- ガバナンス API：TimelockController - OpenZeppelin ドキュメント（参照日：2026-08-21）
- BIP 65：OP_CHECKLOCKTIMEVERIFY - Bitcoin Improvement Proposals（参照日：2026-08-21）
- BIP 68：コンセンサスで強制されるシーケンス番号による相対タイムロック - Bitcoin Improvement Proposals（参照日：2026-08-21）