---
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.
# フォーク選択規則：有効な分岐、重み、正規ヘッド
> プロトコルを学ぶための資料です。ノードの現在のヘッドはネットワーク、規則の版、検証済みローカルビュー、重みの証拠、チェックポイント、時刻に依存し、自動的に確定済みまたは不可逆なアプリ決済に安全とはなりません。
## 要点
フォーク選択規則は、競合するブロックとコンセンサスメッセージについてノードが検証したローカルビューを、現在の正規ヘッドへ写像するプロトコル手続きです。出力は暫定的で観測者にも依存します。受信した有効ブロック、票、時刻イベントが違えば、二つの正直なノードが一時的に異なるヘッドを選ぶことがあります。プロトコルのネットワーク前提の下で許容ビューが収束すれば、規則も収束するよう設計されます。
フォーク選択は無効ブロックを有効にしません。状態遷移、認可、証明、祖先、データ可用性の検査が、重みを比較する前に許容候補を決めます。選択ヘッドが確定済みとも限りません。フォーク選択は今延長する分岐を決め、ファイナリティ規則はより強い安全性証拠で古い祖先を保護できます。現在のヘッドの置換は通常動作でも、確定済みチェックポイントの置換は別のプロトコル境界を越えます。
「最長チェーン」は普遍的な式ではありません。Bitcoin は最も累積作業量の大きい有効チェーンを選び、単なる高さではなく期待 PoW の累積を使います。Ethereum の LMD-GHOST は正当化済みチェックポイントから始め、実行可能な分岐を絞り、最新メッセージの attesting balance が最大の子を、適用される提案者ブーストも含めて貪欲にたどります。各検証者から寄与するのは最新の適格メッセージだけです。他のプロトコルは永続的な最重分岐競争ではなく、可用性証明書、leader lock、round、明示的な commit 証明書を用いる場合があります。
結果は、チェーンとネットワーク、fork 版、信頼アンカー、現在時刻または slot、既知の有効ブロック、親リンク、作業量または投票重みスナップショット、最新メッセージ、二重投票証拠、正当化・確定済みチェックポイント、可用性状態、提案者の時刻、決定論的同点規則という正確な入力に依存します。Explorer のバッジや一つの RPC は一ノードの出力であり、規則そのものでも入力の独立証明でもありません。
## フォーク選択規則の分析方法
1. **識別子と版を固定する。** チェーン、ネットワーク、コンセンサス fork、クライアント版、genesis または信頼アンカー、現在の高さまたは slot、その位置で有効な規則を記録します。mainnet の論理を testnet、sidechain、rollup、将来案へ流用しません。
2. **許容ブロックグラフを作る。** ハッシュ、親、コンセンサス証明、状態遷移、execution payload 状態、必要なデータ可用性を検証します。未知、optimistic、無効、pruned のノードを明示し、重みで無効分岐を救済しません。
3. **祖先と制約を再構築する。** 共通祖先を探し、候補が必要な checkpoint、lock、certificate の子孫か確認します。観測した生の木と規則が実際に対象とする filtered tree を分けます。
4. **全重み入力を再現する。** PoW では target を復号し、各ブロックの proof を累積 chainwork に足します。投票型では検証者、active effective balance などの重み、message domain、target root、slot または epoch、最新メッセージ置換、二重投票処理、一時ブーストを確認します。
5. **選択と同点規則を厳密に実行する。** 各分岐で指定の再帰または comparator を適用し、丸めと決定論的順序に従います。同じ重みが最終合意だと装わず、一時的なローカル選好を許すか記録します。
6. **ヘッド変更を照合する。** 勝者が変わったら切断・接続ブロックを特定し、状態を rollback・replay し、receipt、log、mempool を照合し、共通祖先から再編深度を求めます。head、safe、justified、committed、finalized を区別します。
7. **実装をストレス試験し監視する。** 遅延・秘匿ブロック、partition、古い票、二重投票、balancing、提案時刻、クライアント不一致、弱い checkpoint、利用不能データを試験します。独立ノードを比較し、不可逆処理前に予期しないヘッド分岐、深い再編、確定状態との衝突を警告します。
現在の Bitcoin Core では候補をまず `nChainWork` で比較し、同じ作業量なら早く有効化できる sequence、さらに内部の予備規則で順序付けます。RPC の `blocks` は最も作業量が大きい完全検証済みチェーンの高さで、`bestblockhash` はその tip です。Ethereum の現行仕様では `get_head(store)` が `justified_checkpoint` から filtered tree を進み、各段で `(get_weight(store, child), child.root)` が最大の子を選びます。これらはプロトコル・版固有で、コンセンサス一般の定義ではありません。
## 計算例
### 1. Bitcoin の累積作業量による切り替え
二つの有効分岐が共通祖先 `C` を持ち、tip は `chainwork(A)=240` と `chainwork(B)=235` です。大まかな高さ表示が似ていてもノードは `A` を選びます。B に新しい有効ブロックが作業量 `10` を追加します。
`chainwork(B') = 235 + 10 = 245`
`245 > 240` なので B が最重候補になります。ノードは `C` より後の A を切断し、B から `B'` を接続して取引を照合します。ブロックごとの target が異なる場合、生の個数では足りません。同作業量は一時的な同点で、ファイナリティの証拠ではありません。
### 2. 貪欲な最重観測部分木
正当化済み checkpoint `J` を根とする簡略 LMD-GHOST tree を使います。子は `A` と `B` です。検証者の最新適格メッセージにより A 全体の subtree weight は `61`、B は `39` なので最初に `A` を選びます。A の子 `A_1` と `A_2` の subtree weight は `34` と `27` で、次は `A_1` です。
ヘッドは最重の子を繰り返し選んで得られ、分岐長を数えたり、孤立した直接票が最大の leaf を選んだりしません。実際の規則には viability filter、balance snapshot、二重投票処理、提案者時刻、同点処理もありますが、この教材の木では省略しています。
### 3. 最新メッセージの置換
最新の適格メッセージが当初 A に `55`、B に `45` の重みを与えるとします。重み `20` の検証者が後に B の子孫を支持する新しい適格メッセージを送ります。最新メッセージ会計は A から古い支持を除き、B に加えます。
`A: 55 - 20 = 35; B: 45 + 20 = 65`
重みは両分岐ではなく一度だけ数えるため、選択経路が変わり得ます。これは矛盾票の許可ではありません。有効な attester-slashing 証拠が二重投票を示せば、現行 Ethereum store はその検証者を追跡し、通常の attestation score から重みを除外します。
### 4. Checkpoint filter と提案者ブースト
ノードが、確定済み checkpoint と競合する分岐に生の最新メッセージ重み `70`、実行可能な子孫に `30` を観測したとします。競合分岐はヘッド選択前に除かれ、生の多数重みで通常の fork choice から確定 checkpoint 制約を上書きできません。
次に現在 slot の二つの実行可能な子の attestation weight を `35` と `50` とします。引用した Ethereum 設定では、timely proposer boost は総 stake の 40% ではなく、一委員会重みの `40%` です。委員会重みが `100` で 35 の子に boost が適用されると、比較 score は `35 + 40 = 75` となり、この段で `50` に勝ちます。boost は一時的かつ fork 固有で、追加の検証者票でもファイナリティでもありません。
## リスクとレビュー上の失敗
### 候補集合と証拠
- 親、状態遷移、proof、payload status、必要データを検証する前に分岐重みを比較する。
- 未知・optimistic execution、利用不能データ、header-only view を完全検証状態とみなす。
- block height、timestamp、取引数、fee、explorer 人気を指定された重みの代わりにする。
- 正しい target から per-block proof と累積 chainwork を再現せず、表示 difficulty を合計する。
- 各検証者の最新適格メッセージでなく、過去の全投票を合計する。
- message domain、root、slot、epoch、timeliness、signature、equivocation、slashing 証拠を無視する。
- checkpoint、lock、certificate、availability filter が不適格にした生の分岐を比較する。
- 将来仕様、別ネットワークの parameter、実装最適化を現行コンセンサス規則として使う。
### 選択と運用の失敗
- Bitcoin を生の「最長高さ」、Ethereum を単純な 3 分の 2 head vote と説明する。
- 貪欲な subtree 再帰を global leaf score に変え、proposer boost、丸め、root tie-break を省く。
- 受信順、clock、message view が違うノードも直ちに同じ head を報告すると考える。
- 再編時に状態、receipt、log、index、mempool を正しく切断・replay しない。
- client 間で妥当性、checkpoint viability、latest message、時刻、tie-break が異なる。
- balancing、withholding、equivocation、partition、eclipse、遅延票、proposer reorg を見落とす。
- 一つの RPC、explorer、relay、client family、cloud、validator operator を独立ビューとみなす。
### ファイナリティとアプリの不一致
- 独立した finality 証拠なしに、選択 head を確定済み、不可逆、安全と呼ぶ。
- 価値に応じた方針なしに、一時 head で入金、bridge message、不可逆 trade を解放する。
- 確定済み祖先が全ての新しい head、payload、oracle、アプリ結果の正しさと可用性を保証すると思う。
- 作業量、票、checkpoint、復旧モデルが違う chain に固定 confirmation count を使う。
- emergency checkpoint、weak-subjectivity anchor、social recovery を信頼境界のない通常入力として扱う。
## よくある誤解
- **最長の分岐が常に勝つ。** プロトコルは累積作業量、重み付き最新メッセージ、証明書などを比較でき、生の高さは普遍的規則ではありません。
- **観測した最重分岐は自動的に有効である。** 妥当性と可用性が、重みを使う前に候補を絞ります。
- **フォーク選択とファイナリティは同じ規則である。** 前者は現在延長する head を選び、後者は追加の安全性条件で祖先を保護します。
- **検証者の票は永久に総数へ残る。** 最新メッセージ規則では、新しい適格メッセージが以前の fork 支持を置き換えます。
- **一つの explorer が正規チェーンを証明する。** 一つの基盤のビューを報告するだけで、独立検証と照合は必要です。
## 関連トピック
- [チェーン再編成](/ja/crypto/chain-reorg/)
- [コンセンサスメカニズム](/ja/crypto/consensus-mechanism/)
- [難易度調整](/ja/crypto/difficulty-adjustment/)
- [ファイナリティ](/ja/crypto/finality/)
- [弱主観性](/ja/crypto/weak-subjectivity/)
## 出典
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST（参照日：2026-08-19）
- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org（参照日：2026-08-19）
- [Bitcoin Core: validation.h](https://github.com/bitcoin/bitcoin/blob/master/src/validation.h) - Bitcoin Core（参照日：2026-08-19）
- [Bitcoin Core: blockstorage.cpp](https://github.com/bitcoin/bitcoin/blob/master/src/node/blockstorage.cpp) - Bitcoin Core（参照日：2026-08-19）
- [Bitcoin Core RPC: getblockchaininfo](https://developer.bitcoin.org/reference/rpc/getblockchaininfo.html) - Bitcoin Project（参照日：2026-08-19）
- [Ethereum Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org（参照日：2026-08-19）
- [Ethereum Consensus Specifications: Fork Choice](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/fork-choice.md) - Ethereum Foundation（参照日：2026-08-19）
- [CometBFT Byzantine Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT（参照日：2026-08-19）
Source: https://wiki.fcontext.com/ja/crypto/fork-choice-rule/index.mdx