レッスン2 — Hot upgrade と協調 chain アップグレード

問い

メインネット hardfork 当日。新バイナリがコンセンサスルールを書き換える。何万もの validator が散らばって稼働、マスタースイッチなし、メンテナンス窓なし、chain は止められない。それでも 14:13 UTC に canonical chain に残る全 validator が一斉に新ルールでブロック生成 — どうやって？

注: 以下のコード断片は運用フロー理解のための概念スニペットです（... は省略箇所）。そのまま実行する用途ではありません。

原理（最小モデル）

• 協調メカニズムは「全員同時アップグレード」ではない. バイナリそのものが切り替えタイミングを知っている = height-gate ルール。
• Activation 4 方式. Block height（決定論的、PoW/PoS 両対応）+ Timestamp（壁時計、精度低い）+ Difficulty（PoW 歴史的）+ Total difficulty（Ethereum Merge 1 回限り）。
• Activation 前にアップグレード済めば OK. Activation 後、アップグレード済 validator は新ルール適用、未アップグレードは古ルールで stale fork → ネットワークから脱落。
• アップグレード 5 ステップ. アナウンス受領 → 新バイナリ DL + 検証 → activation 前デプロイ → デプロイ検証 → activation 待ち。
• アップグレードされているのは chain spec. activation_block_number テーブルがバイナリに同梱。
• Pre-fork dry run. Testnet で 2-3 週間先に同 fork → 問題発見で mainnet 遅延。Pectra は 2 回遅延。
• Hot fork ≠ Hot software 更新. Hot fork = コンセンサスルール / Hot software 更新 = 再起動なし。短い再起動は許容（slashing-protection DB が再起動越え）。
• 緊急対応 4 段階. Stale ブロック（自己回復）/ 不正 state（協調 rollback）/ 資金窃取（緊急 hardfork）/ コンセンサス halt（協調リセット、稀）。
• BFT chain は halt-and-recover. >1/3 オフライン → halt → オペレータ復旧 → 再開。halt は許容（fork せず safety 維持）。

具体例

Height-gate ルールの動作:

Block 999: 全 validator (旧コード + 新コード) がこのブロックを受け入れる
Block 1000: Activation 地点
Block 1001: 旧コードの validator はこれを reject する (新ルールに従っていない)
           新コードの validator は受け入れる

Activation 以降、chain は新ルール。旧コードは 明示的に invalid。

4 方式:

現代 PoS = 人間可読のため timestamp、精度のため block height。Casper FFG = epoch 境界。

5 ステップ:

1. アップグレードアナウンス受領（Github issue、Discord）
2. 新バイナリ DL + 検証
3. activation 前に全 validator ノードデプロイ
4. デプロイ正常か検証
5. Activation block 待ち（新ルール自動適用）

ステップ 3 を逃すと activation 瞬間に chain から脱落。アップグレード + sync で再合流。

Reth ベース chain spec パターン（Course 1 Consensus Engineering Lesson 5 より）:

pub enum CustomHardfork {
    Bedrock,
    Canyon,
    Ecotone,
    // ...
}

impl CustomHardfork {
    pub fn activation_block_number(&self, chain: &CustomChain) -> Option<u64> {
        match (self, chain) {
            (Self::Bedrock, CustomChain::Mainnet) => Some(105_235_063),
            (Self::Canyon, CustomChain::Mainnet) => Some(125_000_000),
            // ...
        }
    }
}

新バイナリバージョンに更新済 chain spec 同梱 → 新 activation テーブル → activation block で新ルール発動。

「アップグレードされているのは chain spec」。

Pre-fork dry run:

• Mainnet activation の 2-3 週間前
• 同 fork を testnet で走らせる
• 全動作検証
• 問題発見で mainnet 遅延
• Pectra は 2 回遅延

Hot fork ≠ Hot software 更新:

緊急対応:

歴史例:

• 2016 DAO: 盗まれた資金取り戻す協調 hardfork
• 2024 Polkadot: validator 不正動作で協調 rollback
• 応答サイクル: 24 時間程度

BFT chain の halt-and-recover:

• 1/3 超オフラインで chain halt（>2/3 quorum 要件直接帰結）
• オペレータが validator オンライン復帰
• Chain 再開

halt は許容（chain fork せず、safety 失わず、ただ止まる）。Ethereum の inactivity leak とは異なる回復モデル。

失敗例（誤解）

「全 validator が正確に同瞬間にアップグレード必要」— 間違い。バイナリそのものが切り替えタイミングを知っている。Activation block 前にアップグレード済めば OK、validator 間の協調は不要。アップグレード時刻はずれてもよい、activation block の瞬間に同時 fork。

「Hot software 更新 = Hot fork」— 間違い。Hot software 更新 = 再起動なし運用変更（slashing-protection DB が再起動越えるので安全）/ Hot fork = コンセンサスルール変更（chain spec の activation テーブル更新）。別物。

「Stale fork（アップグレードしなかった 1%）は slashing リスク」— 間違い。Stale fork は canonical chain 上で double-sign したわけではない（別 fork 上にいただけ）→ slashing なし。負担は inactivity ペナルティのみ。アップグレード + sync で復帰可能。

🛑 予測。 Ethereum は主要 outage なしで 10 以上の hardfork 実行。これを成立させているプロトコル機構は？「全員同瞬間アップグレード」ではない。（答え: Height-gate ルール + chain spec activation テーブル。バイナリそのものが「block N で新ルール」と知っている → validator は activation block 前にアップグレード済めばよい（協調は不要、アップグレード時刻はずれてもよい）→ activation block で全アップグレード済 validator が一斉に新ルール適用 → 未アップグレード validator は stale fork で脱落（slashing なし、復帰可能）。chain spec が「いつ」を所有、validator が「どう」を実行。Pectra など 10+ fork が outage なしで成立した理由。）

ステップで組み立てる

Step 1: 協調の本質を理解

「全員同時アップグレード」ではなく height-gate + chain spec。

Step 2: 4 activation 方式

Block height / Timestamp / Difficulty / Total difficulty。現代 PoS = timestamp or epoch 境界。

Step 3: 5 アップグレードステップ

アナウンス → DL+検証 → デプロイ → 検証 → activation 待ち。

Step 4: chain spec の役割

activation_block_number テーブルがバイナリに同梱 → 新バージョンで新ルール起点。

Step 5: Pre-fork dry run

Testnet で 2-3 週間先 → 問題発見で mainnet 遅延 → Pectra は 2 回遅延。

Step 6: Hot fork ≠ Hot software 更新

ルール変更 vs 再起動運用。slashing-protection DB が再起動越えなので software 更新は安全。

Step 7: 緊急対応 4 段階

Stale（自己回復）/ 不正 state（rollback）/ 窃取（緊急 hardfork）/ halt（リセット）。

Step 8: BFT chain の halt-and-recover

halt 許容（fork せず）vs Ethereum inactivity leak で削減。BFT は outage を設計選択にできる。

答え合わせ

• 協調メカニズムの本質: 「全員同時アップグレード」は協調できない（人間の同期不可能）→ バイナリそのものが切り替えタイミングを知っている = height-gate ルール + chain spec の activation テーブル。validator は activation block 前にアップグレード済めばよい、アップグレード時刻はずれてよい → activation block で全アップグレード済が一斉新ルール適用。chain spec が「いつ」を所有、validator が「どう」を実行。
• 1% 未アップグレードの結末と回復: 1% は旧ルールで stale fork 生成、99% は新ルール canonical chain。99% 側から見ると 1% はオフラインに見える（生成ブロック reject）。回復 = ① 「自分が rejected ブロック生成」気づく → ② バイナリアップグレード → ③ canonical chain に sync → ④ canonical 上で署名再開。slashing リスクなし（別 fork 上にいただけ、canonical で double-sign したわけではない）、負担は inactivity ペナルティのみ。
• BFT chain が halt-and-recover を許容する理由: 1/3 超オフラインで chain halt（>2/3 quorum 要件直接帰結）→ オペレータ復帰 → 再開。halt = chain fork せず、safety 失わず、ただ止まる = 大規模 incident で fork するくらいなら halt が望ましい設計選択。Ethereum の inactivity leak（chain 動き続けるが非参加 stake 削る）とは別モデル、BFT は単純 halt を選べる。

合格基準

• 協調メカニズムが「全員同時」ではなく「height-gate + chain spec」と理解している。
• 4 activation 方式と現代 PoS の選択を即答できる。
• 5 アップグレードステップを順に言える。
• chain spec の activation_block_number テーブルを書ける。
• Hot fork と Hot software 更新の違いを言える。
• 緊急対応 4 段階を重大度順に言える。

まとめ（3行）

• 協調 hardfork の本質 = height-gate ルール + chain spec の activation テーブル（バイナリが「いつ」を所有）、validator は activation block 前にアップグレード済めば OK、時刻ずれてよい。
• 4 activation 方式（height / timestamp / difficulty / total difficulty）、5 ステップ、pre-fork dry run（Pectra は 2 回遅延）、Hot fork ≠ Hot software 更新。
• 緊急対応 4 段階（自己回復 → rollback → 緊急 hardfork → halt）、BFT chain は halt-and-recover を許容（fork せず、safety 維持）= 設計選択肢。