--- title: "ハードフォークとソフトフォーク：ルールの互換性、アクティベーション、チェーン分岐" description: "ハードフォークとソフトフォークは、新旧コンセンサスルール間の異なる互換関係を表す。有効ブロック集合、アクティベーション、ノードの強制、マイナーまたはバリデーターの行動、アプリケーションの準備、リプレイリスク、実際のチェーン分岐を分けて分析する。" image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # ハードフォークとソフトフォーク：ルールの互換性、アクティベーション、チェーン分岐 > プロトコルを学ぶための分析であり、投資助言ではありません。提案中または有効化されたフォークは、検証、入出金、カストディ、コントラクト、価格、流動性、税務処理、運用上の安全性を混乱させる可能性があり、持続的な第二の資産が生まれる保証もありません。 ## 要点 ハードフォークとソフトフォークは、アップグレード済みノードと未更新ノードがブロックをどう判定するかによって、コンセンサスルールの変更を分類する。旧ルールが受け入れるブロック集合を `V_old`、新ルールが受け入れる集合を `V_new` とする。ソフトフォークは有効性を制限し、`V_new subset V_old` となる。つまり新ルールで有効な全ブロックは旧ルールでも有効だが、旧ノードは追加制約を強制しない。ハードフォークでは、旧ノードが拒否する新ルール有効ブロックが少なくとも一つ存在する：`exists b: b in V_new and b not in V_old`。ハードフォークのルール集合は拡張の場合も、互いに包含しない場合もあり、「ハード」は単にブロックが大きい、または機能が大胆という意味ではない。 互換性は非対称である。ソフトフォークが成功すると、未更新ノードは更新済みのマイナーやバリデーターが作るブロックを受け入れるため、同じチェーンに残れる。しかし更新済みノードが拒否するものを有効と判断し、保証が弱くなる場合がある。ハードフォークでは、更新済みのブロック生成者が旧有効集合の外にあるブロックを生成した時点で、旧ノードは追従できない。経済的に重要な参加者が両方のルール集合を維持すれば二つの永続的ネットワークになり得るが、一方に実効的な支持がなければ二つの資産が残るとは限らない。 これらの名称が表すのはルールであって、ガバナンスの正当性、安全性、経済的支持、アクティベーション方式ではない。提案は有効化前からハードフォークと呼べる一方、有効化された変更が永続的分岐を生まないこともある。意図しない実装の不整合が、ガバナンス投票なしにチェーンを分裂させる場合もある。マイナーやバリデーターのシグナルは準備状況の調整には使えるが、自身のルールで無効と判定するブロックをフルノードに受け入れさせることはできない。 コンセンサスフォークを、同じルール下の一時的分岐、チェーン再編、ソフトウェアリポジトリのフォーク、アプリケーション更新と混同してはならない。運用上の問いは、各ノード、ウォレット、取引所、カストディアン、オラクル、コントラクトが、どのネットワーク、ルール集合、アクティベーション条件、チェーン履歴を認識するかである。 ## プロトコルフォークの分析手順 1. **識別情報と範囲を固定する。** `chain`、`network`、`client version`、アクティベーション提案、ジェネシスまたはファイナライズ済みチェックポイント、現在のブロックハッシュ、対象レイヤーを記録する。同じ名称でも、テストネット、メインネット、実行層、コンセンサス層、アプリケーションではルールが異なり得る。 2. **コンセンサス上の有効性を差分比較する。** 変更されたブロック、取引、署名、状態遷移、Gas、タイムスタンプ、ファイナリティ、フォーク選択の各ルールを列挙する。代表的な対象を両バージョンで `valid`、`invalid`、`unknown` に分類し、リリースノートだけで互換性を推測しない。 3. **集合関係を証明する。** 新ルールで有効な全対象が旧ルールでも有効かを検証する。すべて有効ならソフトフォーク互換になり得る。一つでも新ルール有効・旧ルール無効のブロックがあれば、そのノードにはハードフォーク移行が必要となる。旧ルール有効・新ルール無効の対象も確認する。 4. **アクティベーションを再現する。** 実装済み仕様とコードから、高さ、エポック、中央値時刻、シグナル閾値、ロックイン遅延、総難易度条件、ガバナンストリガーを確認する。シグナル、ロックイン、アクティベーション、強制は別の状態である。 5. **参加者の行動を対応付ける。** 更新済みのブロック生成ウェイトを測り、各側のフルノード、リレー、ウォレット、取引所、カストディアン、ブリッジ、ステーブルコイン発行者、オラクル、コントラクトを特定する。ハッシュレートやステークだけでは経済的受容を決められない。 6. **分岐と取引処理を追跡する。** 両ルール集合で親ハッシュと有効性をたどる。承認方針、メンプール分岐、リプレイ保護、アドレス形式、チェーン識別子、署名ドメイン、出金経路、両ブランチで取引が実行される可能性を確認する。 7. **運用管理を設定する。** 祖先関係が曖昧なら決済を停止または延長し、計画的に更新とバックアップを行う。ブランチ別に残高と負債を照合し、署名と復旧をオフラインで試験し、明示したチェーン、ノード、相手方、ファイナリティ基準を満たしてから再開する。 この方法は「フォーク」という一語にまとめられがちな四つの事象、すなわちルール提案、アクティベーション条件、観測されたチェーン分岐、その後の一つ以上のブランチの経済的存続を分離する。どの段階も次の段階を自動的に証明しない。 ## 具体例 ### 1. 有効集合の互換性 旧ルールが `100` 種類の候補ブロック形式を受け入れ、新ルールはそのうち `80` 種類だけを受け入れるとする。その `80` 種類がすべて旧集合内にあれば、変更はソフトフォークの関係を持ち、残る `20` 種類の旧ルール有効形式は更新済みノードに拒否される。この数は集合の説明であり、確率や投票閾値ではない。 次に、新ルールが全旧ノードの拒否するブロック形式を受け入れるとする。他の大半のブロックが両ルールで有効でも、この一つの反例だけで後方受容性は崩れ、移行はハードフォーク非互換になる。実際にネットワークが分裂し続けるかは、そのブロック出現後の生成者、利用者、経済インフラに左右される。 ### 2. BIP 34 のアクティベーションは定義ではない `BIP 34` はコインベース取引へのブロック高の記録を必須とし、ローリング準備方式を採用した。直前 1,000 ブロックのうち `750 of 1,000` がバージョン 2 以上になると無効なバージョン 2 ブロックを拒否し、`950 of 1,000` に達するとバージョン 1 ブロックを拒否した。同 BIP はブロック `227,835` を最後のバージョン 1 ブロックとして記録している。 この閾値は展開を調整したのであって、変更をソフトフォークにした定義ではない。互換性は、更新済みノードが受容範囲を狭める一方、旧クライアントも新ルール準拠ブロックを受け入れられたことに由来する。後の `BIP 9` は展開状態とバージョンビットを分けて定め、ルール関係とアクティベーション機構が別問題であることを示した。 ### 3. Segregated Witness のソフトフォーク設計 `BIP 141` は `witness` データを導入し、そのツリーをコインベース取引経由で既存のブロックコミットメント構造に組み込んだ。この設計により、旧ノードは新しい witness ルールを理解・検証しなくても準拠ブロックを受け入れ、更新済みノードは新ルールを強制できた。 これは後方受容性であり、検証能力が同等という意味ではない。新ルールに支配される出力を旧ノードは更新済みノードより緩く見なす可能性があるため、新たな安全特性に依存する利用者には更新済みの検証が必要となる。「旧ソフトウェアが動き続ける」だけではリスク分析として不十分である。 ### 4. Ethereum の DAO Fork EIP-779 はメインネットのブロック `1,920,000` における DAO Fork を記録している。これは指定口座リスト `L` から `WithdrawDAO` コントラクトへ残高を移す変則的な状態変更で、EVM オペコード、取引形式、ブロック構造は変更しなかった。 この状態遷移を適用するノードと拒否するノードは、境界後に異なる状態を計算した。この例から、ハードフォークはブロック拡大やオペコード追加を必要とせず、一度限りの状態遷移ルールでも非互換性を生み、両方の履歴への支持が続けば別ネットワークが存続し得ると分かる。 ## リスクとレビュー上の誤り ### 分類と仕様の誤り - 全ノードが同じルールを使い通常のフォーク選択で解消する一時的な競合先端までハードフォークと呼ぶ。 - 実際の有効ブロック集合を検証せず、すべてのルール緩和をハードフォーク、すべての制限をソフトフォークと定義する。 - 後方受容性を完全な後方安全性とみなす。旧ノードは新しいソフトフォーク制約を強制しない。 - 実装済みコードとチェーンパラメータではなく、ブランド名、ロードマップ、リリースノート、リポジトリ分岐からコンセンサス動作を推測する。 - メインネット、テストネット、実行層、コンセンサス層、ブリッジ、ロールアップ、アプリケーション層の更新を混同する。 - 提案、クライアント公開、シグナル閾値、ロックイン、アクティベーションを同じ事象と考える。 - マイナーやバリデーターのシグナルを、利用者、取引所、カストディアン、フルノードを拘束する投票とみなす。 ### 分岐と取引のリスク - アクティベーションが必ず分裂を生む、または分裂が流動性と持続性のある二資産を必ず生むと考える。 - 同じ高さに異なるブロックがあり得るのに高さだけを使い、ハッシュと祖先関係を確認しない。 - リプレイ保護、チェーン識別子、署名ドメイン、ブランチ固有の取引構築を確認せず、分裂中に送金する。 - 一方のブランチで入金を計上し、他方で負債や出金を決済する。 - 異なるルールを選ぶ、または移行に遅れる可能性があるのに、一つのエクスプローラー、RPC、カストディ表示だけに依存する。 - 再編、ファイナリティ停止、ピア分断、少数マイニング、バリデーターの二重投票、データ利用不能を無視する。 - トークン記号、コントラクトアドレス、ステーブルコイン残高、オラクル価格、ブリッジ債権が両ブランチで同じ発行者保証を持つと仮定する。 ### ガバナンスと運用のリスク - プロトコル互換性を、その変更が正当、分散的、安全、または経済的に支持されている証拠と説明する。 - 再現可能なバイナリ、バックアップ、ロールバック限界、DB 移行試験、独立したハッシュ確認なしに本番ノードを更新する。 - 新しい状態データ、ウォレット形式、スラッシング条件の導入後もダウングレードが常に安全だと考える。 - 秘密を漏らしたり署名をリプレイしたりする未検証ソフトウェアで秘密鍵を移動し、「フォークコインを請求」する。 - 満期、ロック、コントラクト状態、カストディ方針を確認せず、スナップショット残高を直ちに使用可能とみなす。 - ブランチの所有、支配、流動性、現地ルールが確定する前に税務、会計、評価の結論を出す。 ## よくある誤解 - **ハードフォークは必ず新しいコインを作る。** 第二の資産の存続には、継続的なブロック生成、利用者、インフラ、市場が必要で、多くの更新は一つの履歴に収束する。 - **旧ノードが動くのでソフトフォークは無リスクである。** 旧ノードはチェーンを追えても追加ルールを強制せず、検証保証は弱くなり得る。 - **過半数のハッシュレートやステークだけで任意のルールを変更できる。** フルノードは自身のルールで無効なブロックを拒否し、生成ウェイトは受け入れたブロック間でのみ作用する。 - **ハードは論争的、ソフトは全員一致を意味する。** この用語が分類するのは互換性であり、社会的合意、ガバナンス品質、論争の有無ではない。 - **エクスプローラーに見える全フォークがプロトコル更新である。** 同じルールによる競合ブロックや再編は、コンセンサスルール変更なしでも起きる。 ## 関連トピック - [コンセンサスメカニズム](/ja/crypto/consensus-mechanism/) - [フルノード](/ja/crypto/full-node/) - [フォーク選択ルール](/ja/crypto/fork-choice-rule/) - [チェーン再編](/ja/crypto/chain-reorg/) - [Bitcoin](/ja/crypto/bitcoin/) ## 出典 - [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST（参照日：2026-08-19） - [Bitcoin Developer Guide: Block Chain](https://developer.bitcoin.org/devguide/block_chain.html) - Bitcoin Project（参照日：2026-08-19） - [BIP 34: Block v2, Height in Coinbase](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki) - Bitcoin BIPs（参照日：2026-08-19） - [BIP 66: Strict DER signatures](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki) - Bitcoin BIPs（参照日：2026-08-19） - [BIP 9: Version bits with timeout and delay](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki) - Bitcoin BIPs（参照日：2026-08-19） - [BIP 141: Segregated Witness (Consensus layer)](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) - Bitcoin BIPs（参照日：2026-08-19） - [BIP 50: March 2013 Chain Fork Post-Mortem](https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki) - Bitcoin BIPs（参照日：2026-08-19） - [EIP-779: Hardfork Meta: DAO Fork](https://eips.ethereum.org/EIPS/eip-779) - Ethereum Improvement Proposals（参照日：2026-08-19） Source: https://wiki.fcontext.com/ja/crypto/hard-fork-soft-fork/index.mdx