MSTR Cat

ブロックチェーン/レベル IV · プロトコルを深く知る/4.1 Script/レッスン 4

タイムロック：CLTVとCSV

巻き戻すことのできない時計、そしてそれを正直に保つ中央値

用意するものトランザクションの詳細を確認できるブロックエクスプローラー（例：mempool.spaceやblockchain.com）Unixタイムスタンプを扱える電卓BIP65、BIP68、およびBIP113の仕様書

問い

  1. 新しいトランザクションでいつでも回避できるのに、なぜ支出を遅らせるためのトランザクションフィールドが存在するのでしょうか？
  2. 1人のマイナーは、他の全員のコンセンサスを壊すことなく、どのように時刻について嘘をつけるのでしょうか？
  3. 特定の年まで待つことと、今から2年待つことの違いは何でしょうか？

探究

  1. すべてのビットコイントランザクションにはnLockTimeフィールドがあります。これは4バイトの値で、ある時点より前にそのトランザクションがマイニングされるのを防ぎます。値が500,000,000未満であればブロック高を、それ以上であればUnixタイムスタンプを表します。しかし、この仕組みはその特定のトランザクションにしか適用されません。ユーザーはいつでも、同じ入力でロックタイムを0にした新しいトランザクションを作成し、即座にコインを使うことができます。nLockTimeはアウトプット自体を拘束しないため、それだけでは将来の条件に対する安全性を提供しません。
  2. BIP65でピーター・トッドが提案し、2015年12月に有効化されたOP_CHECKLOCKTIMEVERIFY（CLTV）が、この状況を変えました。CLTVは、トランザクションのnLockTimeをスタック上の値と比較するスクリプトオペコードです。ロックタイムが要求値より小さければ、実行は失敗します。このチェックはアウトプットのロッキングスクリプト内で行われるため、その未使用トランザクションアウトプット（UTXO）を使用しようとするすべての試みがこの条件を満たさなければなりません。これにより絶対タイムロックが実現します。コインは、全体のコンセンサス上の特定の時刻またはブロック高に達するまで使用できません。
  3. 相対タイムロックは、絶対的な時点ではなく経過期間を測るという点で異なる動作をします。BIP68は、それまでこの目的には使われていなかったトランザクション入力のnSequenceフィールドを再解釈し、相対的な遅延をエンコードします。BIP112で定義され、2016年7月にBIP68とともに有効化されたOP_CHECKSEQUENCEVERIFY（CSV）は、入力のシーケンス値を要求される期間と比較します。これにより、「このアウトプットは承認から144ブロック経過するまで使用できない」といった条件をスクリプトで強制できます。遅延はそのUTXOが承認された時点を基準とするため、時間ベースのリカバリーパスや支払いチャネルの有効期限に最適です。
  4. 時刻ベースのロックは、マイナーにタイムスタンプを操作する動機も与えました。マイナーはブロックのタイムスタンプを最大2時間先に設定でき、タイムロック付きトランザクションを本来より早く、より多く取り込むことができたのです。2016年7月に相対タイムロックと同時に有効化されたBIP113は、Median Time Past（MTP）を導入しました。現在、タイムロックのチェックはブロック自体のタイムスタンプではなく、過去11ブロックのタイムスタンプの中央値と比較されます。これにより、単一のマイナーが時計を大きく動かすことはできなくなりました。MTPは通常、実際の時刻より約1時間遅れており、すべてのタイムロック計算に安定した検証可能な基準を提供します。
  5. これらの仕組みは、ペイメントチャネルや相続プロトコルといった複雑なアプリケーションの基盤となっています。Lightningチャネルでは、送金途中の支払いに絶対タイムロック（CLTV）が使われ、請求されなかった支払いは期限後に返金されます。一方、当事者自身のアウトプットに設定された相対的な遅延（CSV）は、古いチャネル状態を持ち出した相手にペナルティを科す時間をもう一方に与えます。相続の場合、スクリプトでマルチシグの要件とタイムロックを組み合わせることができます。たとえば、日常的なアクセスには2つの鍵が必要でも、1年間動きがなければ、3つ目の鍵（相続人）がCSV条件によって定足数に加わる、といった形です。これらのパラメータはウォレット作成時に固定され、資金がロックされた後は変更できません。
  6. タイムロックは恒久的な制約です。設定された時点で解除されますが、発動後に再ロックしたり遅延を延長したりする仕組みはありません。スクリプトが100ブロックのシーケンス値をエンコードしている場合、コインは承認からその相対的な高さに達した時点でちょうど使用可能になります。エンコードを誤ると、意図より長く資金にアクセスできなくなったり、逆に早く解除されすぎたりすることがあります。実際に確かめるには、ブロックエクスプローラーで最近のトランザクションを開き、nLockTimeフィールドを確認してください。ほとんどのウォレットはこれを現在のブロック高に設定するため、そのトランザクションはそれより低い高さのブロックには含められません。これにより、マイナーが手数料を得るために最新のブロックを書き換える動機（「フィースナイピング」）が1つなくなります。

重要な事実

  • nLockTimeの値が500,000,000未満の場合はブロック高として解釈され、500,000,000以上の場合はUnixタイムスタンプとして解釈されます。
  • OP_CHECKLOCKTIMEVERIFY（BIP65）は2015年12月に有効化され、スクリプトレベルで絶対タイムロックを強制します。
  • OP_CHECKSEQUENCEVERIFY（BIP112）とBIP68は2016年7月に有効化され、nSequenceフィールドによる相対タイムロックが可能になりました。
  • BIP113で導入されたMedian Time Past（MTP）は、マイナーによる時刻操作を防ぐため、過去11ブロックのタイムスタンプの中央値を使用します。
  • CSVの遅延は、使用される特定のUTXOが承認されたブロック高または時刻を基準に測られます。
  • ウォレットは、フィースナイピングのリスクを軽減するため、通常nLockTimeを現在のブロック高に設定します。

演習 九・六・三・一

9集める説明が見つかるタイムロックの用途（Lightning、ボールト、相続、エスクロー、アトミックスワップなど）を9つ挙げ、それぞれが絶対ロックと相対ロックのどちらを使っているかを記録してください。
6まとめる9つを目的別に6つに分類してください：返金、ペナルティ期間、相続、貯蓄ロック、契約期限、その他。
3絞り込む6つを、タイムロックが支出トランザクションの中だけでなく、アウトプットのスクリプト内に置かれなければならない3つの理由に絞り込んでください。
1結晶化するMTPが、タイムロックをマイナーへの信頼に依存するモデルから決定論的なコンセンサスルールへとどのように変えるのかを、1文で説明してください。

事実確認

日付、数字、主張は、下記に記載された公表資料と照合して確認しました。

インタラクティブ版で開く →

EN PT ES ZH KO RU DE FR MS