Hard Fork は、新しい有効集合が旧集合の部分集合ではないコンセンサス変更である。典型例は範囲の拡大であり、V(new) が V(old) の外側の状態、例えば旧ノードの許容サイズを超えるブロックや旧ソフトウェアが無効とする構造を認める。新ルールの有効化は旧ノードに移行を強制しない。旧ノードは自分のルールを実行し続けるため、チェーンの継続性は自発的な協調に依存する。
旧ルールで受理する全ブロックを V(old) とする。新ソフトウェアがその集合の外にあるブロックを一つでも受理するなら、その変更は Hard Fork である。有効な範囲の拡大である場合が多いが、決め手は互換性だ。新ノードでは有効なブロックが旧ノードでは無効になり得るなら、旧検証者はルールを変えずに新チェーンを追えない。 [Bitcoin Developer Guide — Consensus rule changes]
旧フルノードは新ルールを知らず、承認もしていない。更新済みマイナーが旧上限を超えるブロックや新たに許可された構造を使うブロックを生成すると、旧ノードは自分にとって最後の有効ブロックにとどまり、その後の枝を拒否する。多数決で負けたのではなく、別のコンセンサスプログラムを決定論的に実行している。 [Bitcoin Developer Guide — Consensus rule changes]
所定の日付、ブロック高、マイナーのシグナルは更新を受け入れた参加者を調整できるが、受け入れていないノードのソフトウェアは変えられない。両方のルールに経済的に重要な参加者が残れば、両チェーンが続く可能性がある。したがって Hard Fork の有効化計画は、分裂リスクを伴う移行計画である。 [Bitcoin Developer Guide — Consensus rule changes]
分岐点では両枝が同じ分岐前の UTXO 履歴を継承する。その後は異なる取引を承認し、異なる上限を採用し、異なる chainwork を蓄積できる。両方が存続すれば、保有者は通常それぞれのチェーンに対応するコインを持つが、後のルール、replay 保護、ウォレットの対応に左右される。もはや一つの台帳上の単一記録ではない。 [BCHN Technical Bulletin — shared history and 2017 split]
Proof of Work は、ノードがブロックを有効と認めてから枝を比較する。旧ルールで無効なブロックを含む枝の chainwork を、旧ノードが自分の有効チェーンと比較することはない。まずその候補を除外するからだ。「hashrate が最大のチェーンが勝つ」という説明は、検証ルールを明示しなければ不完全である。 [Bitcoin Developer Guide — Consensus rule changes]
共通の署名形式と取引形式により、同じ署名済み取引が分岐後の両ネットワークで有効になることがある。これが replay リスクである。フォーク側で保護機構、別の sighash ルール、異なるアドレス形式を導入できるが、それぞれ独立した措置だ。利用者はネットワーク、残高、導出したアドレス、取引所の入金反映と出金の方針を区別する必要がある。 [Bitcoin Cash upgrade specification — 2017 hard fork]
Bitcoin Cash は 2017 年 8 月 1 日、ブロック高 478559 で Bitcoin から分岐した。当時の Bitcoin ノードが受理するより大きなブロックを許すルールを採用し、独自の継続チェーンを作った。Bitcoin ノードは BCH のルールだけで有効なブロックを拒否し、BCH ノードは自分たちの有効な履歴を追った。これは同じネットワーク内で Bitcoin を置き換える更新ではなく、独立したネットワークを作った Hard Fork の例である。 [Bitcoin Cash upgrade specification — 2017 hard fork] [BCHN Technical Bulletin — shared history and 2017 split]
互換性のない分岐がすべて意図的な新通貨の計画とは限らない。バグが実装間の一時的な不一致を起こし、緊急リリースが共通ルールへの復帰を調整することもある。2013 年 3 月の Bitcoin 分裂は、データベースとその制約を巡るバージョン間の挙動差に起因した。マイナーが旧バージョン 0.7 のノードが受理する枝へ協調して戻ることで解決しており、BCH を独立ネットワークとして長期維持するケースとは異なる。 [BIP 50 — March 2013 chain fork post-mortem]
Soft Fork は V(new) が V(old) の内側にとどまるよう有効集合を狭める。旧ノードは追加制約を検証しないものの、互換ブロックを追える。Hard Fork にはこの一方向の互換性がない。新しく有効になったブロックが旧ノードでは無効になり得る。Soft Fork も協調に失敗すれば分裂し得るが、Hard Fork は定義上、新ルールへの移行を要する。 [Bitcoin Developer Guide — Consensus rule changes]
開発者はコードを公開し、マイナーは hashrate の投入先を変え、企業は取引記号と入金方針を選び、利用者はソフトウェアを選べる。いずれも他者のコンセンサスを自動で書き換えない。十分な独立参加者が両方のルールを自発的に維持して価値を認めれば分裂は続き得るが、非互換な変更が必ず二つの長期稼働ネットワークを作るわけではない。一方の枝を「更新」と呼ぶことは社会的な呼称であり、コンセンサスルールではない。 [Bitcoin Developer Guide — Consensus rule changes]
運用者はネットワーク識別子、具体的なソフトウェアリリース、コンセンサスパラメータ、ピア、チェーン先端、分岐点のブロックハッシュ、対応するリリースノートやチェックポイントを確認する。多額の資金を扱う場合は、分岐したコインを使う前にウォレットと作業手順を分けるのが望ましい。ブロックエクスプローラーや取引記号は参考になるが、自分で検証するノードの代わりにはならない。 [Bitcoin Core v29.0: getblockchaininfo]
理解を深めるには、この項目とあわせて次もお読みください Soft Fork, コンセンサス規則, Full Node, Reorg, ブロックサイズ戦争, UTXO. 次の項目からも参照されています Soft Fork, BIP (Bitcoin Improvement Proposal), Reorg, ブロックサイズ戦争.