ハードフォークが発生したとき、ノード運用者はどう行動すればよいのか？

ビットコインの素晴らしいところの１つに、「ルール変更を強制されない（フォークする自由がある・フォークについていかない自由がある）」という点があります。しかし、実際にフォークが発生したとき、どのように自分が利用するチェーンを選べばよいのでしょうか？

読者様から以下の匿名質問をいただきました：

ビットコインはハードフォークができることによって単一障害点を排していると理解しています。
しかし、実際にハードフォークが起きたときにノード運営者として取りうる具体的なプロセスを理解できていません。
Bitcoin Coreなどでコマンドライン経由か何かで検証するブロックを選択するのでしょうか。

まず先に、ノード運用者でなければ参照する先のノードやサービスに依存することになるため、自身で選択することはできません。

今日はご質問の通り、ノード運用者の立場でハードフォークが発生した際に取れる行動を考えてみます。

・ハードフォークの発生条件

・ノードの視点からみたハードフォーク

・ノード運用者やユーザーが取るべき行動

ハードフォークの発生条件

まず、用語の整理をしましょう。

ハードフォークとはソフトウェアの改変によって「コンセンサスルールに含まれる制約が取り払われる」ことによって「以前のバージョンから見たら無効なブロックが正常なものと見做されるようになる」ことです。

例えばビットコインの今のブロックサイズは4MWU (1MvB)という大きさに制限されていますが、仮にこの制限を超える10MWUのブロックまで認めるバージョンアップ（またはバグ）があったとします。新しいソフトウェアは10MWUのブロックを正式なものと認めますが、古いバージョンのソフトウェアはこれを無効なものとして無視します。

この結果としてチェーンが分岐することがありますが、必ずしもそうではありません。バグと見做された場合など古いソフトウェアが圧倒的にユーザーに支持されていればそちらのチェーンが長くなり、新しいソフトウェアもそちらのチェーンにつなごうとします。（旧来のルールのチェーンにつないでいても、新しいソフトウェアは4MWUを超えるブロックを採掘するたびにいわゆるオーファンブロックを生成してしまいます）

チェーンの分岐が発生し恒常化する、つまり1本のチェーンに収束しないような変更が加えられると事実上２つの通貨が誕生したことになります。これは「ハードフォークした側」のハッシュレートが圧倒的な場合のほか、コンセンサスルールの制約を取り払うと同時に、これまでのコンセンサスルールが不正となるような変更がセットで加えられたような場合に起きやすいです。（例えば従来のトランザクションフォーマットが不正と見做されるようになったなど）

またビットコインノードは不正なブロックを配信してきたピアとの接続を切断するので、ノード間のネットワーク自体も分裂する可能性があります。逆に言えば同じ陣営のノードが互いに十分に繋がっていなければそのネットワーク自体も不完全なものとなるでしょう。

おそらく質問者さんはブロックチェーンの分岐が恒常化しそうで、ネットワークも分裂しているかもしれない状況を想定しているのではないかと感じます。（ちなみにソフトウェアを意図的にアップデートしない限り、新ルールのチェーン側に入ってしまうことはバグ以外では基本的にありえません）

ノードの視点からみたハードフォーク

さて、ノードの視点から見たらハードフォークはどう見えるのでしょう？

各ノードはコンセンサスルールやブロックを受け取ったタイミングによって自身が正当と考えるチェーン観を持っています。そのチェーン観では、「正当なブロックのみで構成されるチェーンの中でProof of Workが最多のもの」を保存し、さいActive Chain Tipとみなしています。

「最長のチェーン」ではなく「Proof of Workが最多のチェーン」という判断基準は、下方向の難易度調整によって「最長のチェーン」をより少ないハッシュレートで作成できてしまうおそれがあるため採用されています。

また、Bitcoin Coreでは受信したブロックとそのProof of Workが正当であればいわゆるStale Block（その後に最多PoWのチェーンが続かないブロック）も異なるChain Tipsとして永久に保存します。多大なコストを支払って生成されたものの可能性が高く、DoS攻撃のリスクがないためです。（初回やオフラインからの復帰後にブロックチェーンを同期する際にはピアからダウンロードしないため、受信はリアルタイムで行われなければなりません）

一方、DoS攻撃対策の観点から、不正とみなしたブロックは保存せず、それを配信してきたピアをブロックしてしまうため、「ハードフォークしていない側」から見たときに分岐相手のチェーンは手元にありません。分岐相手のチェーンも手元で成長し続けるのは「ハードフォークした側」のノードにおいてのみです。ただし、ノード運用の負担になるほか、長大なReorgのリスクやリプレイ攻撃（同じトランザクションが両方のネットワークに配信されて分岐の両方のコインを送金した扱いになる）のリスクもあるため意図的な分岐であれば緩和前のブロックを不正とみなす変更も加えることが一般的です。（こうすると「ハードフォークした側」のノードからみても分岐相手のチェーンは手元に残りません。）

したがって、ノードの視点では：

意図的なHF→自分の視点でみた正当な分岐後のチェーンしか保存していない

バグ等によるHF→自分の視点でみた正当な分岐後のチェーンしか保存していない可能性も、分岐相手のチェーンが保存されている可能性もある（ハードフォークした側か、していない側か、そして分岐相手を無効と見なす改変の有無による）

という２パターンに分けられるでしょう。

ノード運用者やユーザーが取るべき行動

さて、本題のノード運用者が取れる行動ですが、それぞれのパターンに分けて考えてみましょう。

事前から告知されていた、意図的なハードフォークの場合

ネットワーク自体の分岐などに対応する必要性から、意図的なハードフォークであれば事前にある程度の期間を告知されている可能性が高く、大義名分もビットコインユーザーにとって関心のあるものとなるでしょう。

逆に告知があまりされておらず、大義名分もないフォークはそもそも支持をあまり得られないでしょう。

したがってこのような場合は発案者が用意したソフトウェアを、できればハードフォークを実行するブロック高までに行うのが正解です。ノードのソフトウェア内でできる設定等はありません。

バグなどによる、意図的でないハードフォークの場合

この場合も、SNSなどから情報収集してバグ発生やソフトウェアアップデートの情報を収集し、必要に応じてソフトウェアアップデートなどで対処することが好ましいです。告知期間は非常に短く、問題があったことに数日から数週間気付かない可能性もあるでしょう。

例えば2010年にソフトウェアのバグを突いて1844億BTCが発行されてしまった際には、発覚から数時間以内に修正版のノードソフトウェアがリリースされ、アップデートしていないノードはBTCが乱発行されたほうのブロックチェーンでマイニングを続けてしまいましたが、攻撃から53ブロック後に修正版のチェーンが最多PoWとなり、修正前のノードもそちらを参照するようになりました。（ちなみにこれはハードフォークではなく制限強化のソフトフォークに分類されます）

意図的でないフォークが発生すると、先ほど述べたようにハードフォークしてしまった側からみて元のチェーンも正当であるような可能性があります。自身のノードが誤って「ハードフォークした側」のチェーンを参照していて、「正常なチェーン」のほうに切り替えたい時は以下のコマンドが役立ちます：

bitcoin-cli getchaintips：自身のノードが正当とみなしているChain Tipsの一覧です。もしなぜかハードフォークしてしまった側にいて、かつハードフォークしていないノードが生成したブロックも認めている場合はこの中にハードフォークしていないノードがつむぐチェーンのTipも存在します。

bitcoin-cli invalidateblock：上記の場合、ハードフォークした側のみが認めるチェーンの１ブロック目をこのコマンドで無効と見なすことで強制的に別の最良Tipを探します（ハードフォークしていないノードが認めるものなど）。ただし、ハッシュレートの分布によってはまた別のハードフォーク側Chain Tipを参照しはじめる可能性があり、繰り返し実行する必要があるため一時的な解決にしかなりません。

誤って発生したハードフォークの場合、おそらく最善なのはパッチを待つことで、不安で特にノードを急ぎで使用したいわけでなければ修正がリリースされるまでノードの電源を落とすことも選択肢に入ります。（あくまで自分のためのノードであれば、後から同期すれば良いため）

ライトニングノードを実行している場合の注意点

チャネルの開設・閉鎖がスムーズに実行できない可能性が高いので、これらの行動は避ける。通常のライトニング払いには影響はおそらくない。（ただし、Phoenixのようにオンチェーントランザクションに依存するライトニング系ウォレットの挙動によって様々な影響が出る可能性はあるため、第三者の送金をルーティングする際のリスクは高まる。）

また、チェーン分岐が長期化しそうな場合、チャネル閉鎖などに関連して問題が複雑化しやすいのでその状況に応じて追加の対応が必要となる可能性がある。

まとめ

・意図的なハードフォークは大抵の場合、支持を集めるために告知されてある程度の期間が経過してからアクティベーションされる。もしハードフォークする側を支持したいならその段階でソフトウェアをアップデートすべし

・ハードフォーク発生時、「ハードフォークした側」はノードがもう１つのチェーンを正当なものと認識している場合があるが、「ハードフォークしていない側」は相手を不正とみなして全く感知しないことになる

・バグによるものを除けば、ソフトウェアをアップデートしなければ自身のノードがなぜか「ハードフォークした側」のチェーンを参照することはない

・仮にハードフォークをした側のチェーンに（意図に反して）いる場合、最善の対処はバグ修正を待ってソフトウェアをアップデートすることだが、bitcoin-cli invalidateblockで分岐直後のブロックを不正とみなして都度除外していく方法もある。ただし後者はハッシュレートの分布によっては複数回実行する必要があるかもしれない

・ライトニングノードを実行している場合、チャネルの開設や閉鎖は解決するまで避けるべき。また、長期化する場合は別途注意事項があるかもしれない。