Soft Fork

アンナとパヴェルが、それぞれ自分のコンピューターで Bitcoin を検証しているとしましょう。アンナはソフトウェアを更新しましたが、パヴェルはまだです。そこへ BIP66 に似た変更が加わります。特定のビットコインを使う権限を示すデジタル署名について、データの記録形式がより厳密に定められ、以前は認められた一部の形式が使えなくなるのです。 新たに要求された形式の有効な署名がある支払いは、両者のこの検査に通ります。しかし、以前は許されていたものの今は禁止された形式の署名なら、アンナは拒否し、パヴェルはまだ受け入れる可能性があります。ここでは、支払いがほかのすべてのルールを満たすと仮定しています。これが Soft Fork の要点です。新しいルールは、古いルールが禁じたものを認めることなく、禁止する場合を増やします。 マイナーが厳しくなったルールを満たすブロックを作る限り、両者はそのチェーンを追い続けられます。ただし、パヴェル自身は追加条件を確認していません。Soft Fork なら全ノードを同時に更新せずに Bitcoin を変更できますが、古いソフトウェアが新しいものと同じ範囲を検証するわけではありません。それ自体で第二の通貨が生まれるわけでもありません。 [1] [6]

Full Node は Bitcoin のルールを独立して確認するコンピューターです。有効な分岐の中から選ぶときは、支持者の票ではなく、採掘によって示された累積作業量を比べます。更新済みのマイナーが旧ルールにも合うブロックを作る限り、古いノードもチェーンを追えます。ただし、追加された条件は確認しません。新ルールに違反する分岐の累積作業量が多ければ、古いノードは受け入れ、更新済みノードは拒否することがあります。新しい保証を自分で確認するには、検証用ソフトウェアの更新が必要です。ウォレットで支払いを受け取れたり、新しいアドレス形式を認識できたりしても、ネットワークの全ルールを確認しているとは限りません。 [1] [12]

BIP は番号の付いた技術提案です。公表だけでネットワークが変わるわけではありません。ソフトウェアを開発して検証し、それを使うかどうかは利用者が決めます。Mainnet は実際のビットコインを送る主ネットワークです。有効化は、更新済みノードがいつから新しいルールを要求するかを定めます。 つまり、プログラムにコードが入っていることと、ブロック検証でそのコードを使うことは別です。ここで扱う有効化手順では、lock-in は後の有効化に必要な条件を満たした段階を意味し、ルール自体はまだ適用されない場合があります。ノードが新ルールを確認するのは ACTIVE になってからです。状態は、自分が追う分岐の過去のブロックから計算します。有効化の境界付近で再編成が起き、その履歴が変われば、計算結果も変わることがあります。そのため、有効化の設定が異なるプログラム同士は、同じ時点でも別のブロックを受け入れる可能性があります。 [2] [15]

マイナーは直前のブロックに続けて新しいブロックを作ります。その直前のブロックを親ブロックとも呼びます。親を確認しなければ、ほかのノードが拒否する分岐に作業を費やすおそれがあります。2015 年 7 月の BIP66 有効化では、一部のマイナーが新しいバージョンを示しながら、親ブロックを十分に検証していませんでした。その結果、無効なブロックに続けて採掘し、7 月 4 日には 6 ブロックの無効な分岐を作りました。翌日にも、より短い分岐ができました。更新済みの検証ノードはどちらも拒否しました。バージョン番号やビットはマイナーの申告であり、準備したブロック、その親、含まれる取引を実際に検証した証明ではありません。 [6] [14]

自分のノードが実際にどのルールを適用しているか知りたいときは、ソフトウェアのバージョンと、そのノード自身が返す情報から確認します。バージョンに応じて、getdeploymentinfo と getblockchaininfo は導入した変更やチェーンの情報を返します。そのバージョンの文書、有効化の高さ、ログも併せて見ることで、準備済みのルールと適用済みのルールを区別できます。Web のブロックエクスプローラーは別のサービスの見方であり、自分のコンピューターの検証内容を証明するものではありません。 Hashrate は採掘の計算能力を表しますが、ノードのルールを無視する権限ではありません。ACTIVE の更新済みノードは、新条件に違反するブロックを、その背後に採掘能力の過半数があっても拒否します。チェーンの分裂が続くかどうかは、各分岐の累積作業量や経済的な利用にも左右されます。有効な制約を単に取り除くと、現在は無効なブロックを再び認めるため、Hard Fork に当たります。有効化前なら調整した新しいソフトウェアで設定を変更できますが、その変更も他人のノードに自動で入るわけではありません。 [1] [15] [16]

更新前のルールが受け入れるすべてのブロックを V(旧) とします。変更が Soft Fork であるためには、V(新) がその内側に収まる必要があります。新ノードは追加のケースを拒否しますが、新ルールを満たすブロックは旧ルールの検査にも通ります。この名前が表すのはルールの互換関係であって、変更が小さいこと、安全であること、社会的な合意があることではありません。古いノードに見える上限を増やしたり、従来は無効だった支出を認めたりすると、許される範囲が広がり、通常は Hard Fork が必要です。 [1] [17]

ルールを厳しくすることで、新しい機能を加えることもできます。BIP66 は署名データの符号化形式である DER を厳密に定めました。BIP65 と BIP112 は、それまで何も条件を課さなかった一部の NOP 命令に、支出の時間条件を加えました。SegWit は witness プログラムと、署名などを含む witness という検証データを導入しました。Taproot は後に、その予約済みバージョン 1 を使いました。古いノードは対応する新しい条件を確認しません。Anyone-can-spend はその限られた見方を指し、更新済みのノードを回避して他人のコインを使えるという意味ではありません。また、SegWit は witness commitment により witness データをブロックに暗号学的に結び付けます。この結び付きは、マイナーの報酬を含む先頭の coinbase 取引に記録され、従来の基本ブロックのルールとの互換性を保ちます。 [6] [5] [7] [8] [12]

ビットは 0 または 1 の値です。ブロックヘッダーのバージョン欄 nVersion では、個々のビットでマイナーの準備状況を示せます。BIP9 は各導入に名前、使用するビット、開始時刻、期限を割り当てます。 当初の mainnet の手順は、2016 ブロックごとの期間を評価します。STARTED 中に少なくとも 1916 ブロック、つまり 95 % がシグナルを出すと、次の期間は LOCKED_IN になります。さらに一期間待つと ACTIVE です。期限までに条件を満たせなければ、FAILED で終わる場合があります。開始前の状態は DEFINED と呼びます。 各ノードは、過去のブロックからこの状態の移り変わりを計算します。そのため、あるブロック自身の nVersion が、そのブロックへの新ルールの適用を決めるわけではありません。シグナルは移行の調整に使うもので、個々のブロックが有効かを投票するものではありません。lock-in 後のシグナルは、この手順の結果を変えません。 [2]

Versionbits によってマイナーは準備状況を示せますが、他のノードのルールを書き換える権限は得られません。BIP8 は時刻の境界の代わりにブロック高を使います。lockinontimeout が true で、まだ lock-in に達していない場合、最後の期間はシグナルを必須とする MUST_SIGNAL に移ることがあります。BIP148 は参加ノードに対し、SegWit のシグナルがないブロックの拒否を求めました。一方、BIP91 はより低いマイナーのシグナルしきい値を使って移行を調整しました。ルールの適用、hashrate、経済的な受け入れが食い違うと、チェーンが分裂する可能性があります。そのため、有効化の方法を選ぶ際には、安全性に関する利点とリスクを検討する必要があります。 [11] [9] [10] [17]

P2SH (BIP16) では、後で資金を使う条件を定めたプログラム、つまりスクリプトのハッシュ宛てに資金を送れます。2012 年の導入時には、coinbase 取引内のシグナルがマイナーの準備状況を判断する材料になりました。ただし、新たな検査を適用し始める基準は、定められたブロックのタイムスタンプです。シグナルは検証の代わりではありません。Coinbase はマイナーの報酬を含む、ブロックの先頭の取引です。 その後の変更では、ブロックのバージョンとシグナルのしきい値を使いました。BIP34 は、チェーン内の位置を表すブロック高を coinbase に記録するよう求めました。BIP66 は署名の DER 形式を厳格にし、BIP65 は支出できる最も早い時刻や高さを調べる CHECKLOCKTIMEVERIFY を導入しました。バージョン番号を順に上げる方式では、独立した変更を並行して導入しにくいため、BIP9 は個別のビットを導入しました。 2016 年、高さ 419328 で BIP68、BIP112、BIP113 が同時に有効になりましたが、扱う時間条件は異なります。BIP68 は、使おうとする出力が承認されてからの相対的な待ち時間を導入します。BIP112 は、その待ち時間をスクリプト内で要求する CHECKSEQUENCEVERIFY、略して CSV を使えるようにします。一方、BIP113 が変えるのは絶対的なタイムロックの時間基準です。評価中のブロックの時刻ではなく、直前の 11 ブロックの時刻の中央値である Median Time Past を使います。同時に有効になったからといって、三つとも同じ相対ロックを導入したわけではありません。 [3] [4] [5] [6] [7] [18] [19] [20]

SegWit は 2017 年 8 月、高さ 481824 で有効になりました。署名などの witness 検証データを、取引識別子 txid の計算に使う部分から分離しました。なぜ重要なのでしょうか。以前の記録形式では、受取人も金額も変えずに署名の表し方を変え、取引識別子まで変えられる場合がありました。この性質を展性、malleability と呼びます。witness データだけを変えても txid は変わりません。ただし、この仕組みで旧形式を使い続ける入力まで修正されるわけではありません。 古いノードは witness のない取引を見て、witness v0 プログラムを anyone-can-spend として扱います。更新済みノードは witness に加え、署名するデータの指紋である署名ダイジェストも確認します。Coinbase 出力に入る witness commitment は、witness データとブロックを暗号学的に結び付け、完全な検証で変更や欠落を検出できるようにします。Weight は、ブロック容量を計算する際のデータの重みです。これにより実効容量を増やしながら、古いノードに見える基本ブロックは従来の 1 メガバイト上限内に収まります。 [8]

Key-path では出力鍵に対応する署名で資金を使い、script-path では公開するスクリプトの条件を満たして使います。Schnorr は署名方式、Tapscript はそのスクリプト言語です。BIP341 と BIP342 は、ネイティブ SegWit 出力の 32 バイトの witness v1 プログラムについて、Schnorr 署名と Tapscript を使うこれらの支出ルールを定めています。古いノードには予約済みプログラムが anyone-can-spend と見えるため、互換性は保たれますが、検証範囲は同じではありません。Mainnet の Speedy Trial では、修正した BIP9、1815/2016（90 %）のしきい値、最小有効化高 709632 を使いました。Taproot は 2021 年 11 月 14 日、その高さで有効になりました。ルールの内容と、有効にする手順は、それぞれ検討すべき別の問題です。 [12] [13] [16]