レッスン1 — Light client（gold standard の検証プリミティブ）

問い

Ethereum フルノード = ストレージ ~1TB + RAM ~200GB。Light client は同じ仕事を数 MB + スマホ CPU で行う。Block header をダウンロードし、フルノードと同じコンセンサスルールに従う。source chain の light client を destination chain の中に置いてクロスチェーンメッセージを暗号的に検証できるか？ Yes なら trust 最小化の gold standard。

原理（最小モデル）

• Light client にできる 4 つ. Block header → genesis のチェーン検証 / state inclusion proof 検証 / transaction inclusion 検証 / コンセンサス追従。
• Light client にできない 3 つ. Proof なし任意 state 参照 / 任意 tx 実行 / state proof 生成（検証のみ）。
• Sync committee + BLS が PoS Ethereum で light client を成立させた. 512 validator のローテーションサブセット、N 署名を 1 つに集約、~MB / 期間 ~27 時間。
• 3 必要要素. 初期信頼 checkpoint（out-of-band）+ sync committee 更新（期間ごと）+ header 更新（committee 署名検証）。
• Helios = a16z 製の本番 Rust Ethereum light client. ~10k 行、wallet / indexer / bridge で使用、wasm でブラウザ動作。
• Reth ベース chain の light client 設計. Naive（BFT、Ethereum 上で ~5000 gas/header）vs ZK（off-chain proof + Ethereum 上で定数 ~100k gas）。
• ZK light client が bridge の endgame. Trust = 数学、本番例 = SP1 / Espresso / Polyhedra。

具体例

Light client のできる / できない:

Ethereum light client プロトコル:

• Sync committee period ~27 時間ごとに 512 validator ランダム選出 = sync committee
• Sync committee がその期間の すべての block header に署名
• Light client が committee メンバーシップ + 署名のみダウンロード
• BLS 集約公開鍵で検証 = ~ms

Helios アーキテクチャ:

flowchart LR
    Trusted["信頼 checkpoint<br/>(slot, blockRoot)"] --> Sync["head に sync"]
    Sync --> Update["Sync committee<br/>各期間で更新"]
    Update --> Header["Header 更新<br/>現 committee 経由"]
    Header --> Verify["クレーム検証<br/>(execution payload、<br/>state proof)"]
    RPC["RPC server"] --> Verify
    Apps["Bridge / Indexer"] --> RPC

Helios 主要ファイル（a16z/helios）:

• consensus/src/consensus.rs — コンセンサスクライアント（sync committee + header 検証）
• execution/src/state.rs — execution 層からの state inclusion proof 検証
• rpc/src/lib.rs — RPC server（アプリから検証済み state クエリ可能）

Reth ベース chain での light client 2 アプローチ:

Naive light client（BFT chain）:

• Validator セット追跡（交代イベント込み）
• 2f+1 署名された header 検証
• State root に対する inclusion proof 検証
• Ethereum 上で BLS 集約込み ~5000 gas/header = 50 gwei で ~$0.50/header

ZK light client:

• BFT 検証が off-chain zkVM proof 内
• Ethereum 上で proof 検証のみ = 定数 ~100k gas
• 本番例: Succinct SP1（Ethereum light client）/ Espresso（共有 sequencer）/ Polyhedra（各種 chain）

Reth ベース chain の役割:

失敗例（誤解）

「Light client は full state を持たないから検証不可能」— 間違い。Light client は state を 生成 しないが、proof があれば 検証 できる。Bridge は light client を 検証者 として使う（relayer が proof 生成 + light client が検証）。

「Ethereum PoW 時代の light client は研究用」— 正しい。PoS が経済性を変えた（固定 validator + BLS 集約）→ 実用領域に。プロトコル選択次第で light client の実用性が決まる。

「ZK light client は遅い」— 半分間違い。on-chain 検証は定数（~ms） で爆速、off-chain proof 生成が ~分-時間で高コスト。高スループットなら ZK が漸近的に勝つ。

🛑 予測。 Light client は ~MB、フルノードは ~1TB。Light client にできないことを 3 つ挙げる（state を必要とするものを考える）（答え: ① proof なしで任意 state 参照 — full state を持たない、② 任意 tx 実行 — 実行に必要な full state を持たない、③ state proof の生成 — 検証のみ可能。Light client は state に関するクレームの 検証者 であって 生成者 ではない。Bridge では relayer が proof 生成 + light client が検証 = 役割分担。）

ステップで組み立てる

Step 1: できる / できない 4+3 を即答

できる: header 検証 + state inclusion 検証 + tx inclusion 検証 + コンセンサス追従。 できない: 任意 state 参照 + 任意 tx 実行 + state proof 生成。

Step 2: Sync committee の仕組み

512 validator ローテーション + BLS 集約 + ~MB/期間 + ~27 時間/期間。

Step 3: 3 必要要素

初期信頼 checkpoint（一度だけ out-of-band）+ sync committee 更新（期間ごと）+ header 更新（期間中）。

Step 4: Helios の構造を読む

consensus.rs（コンセンサス）/ state.rs（state proof）/ rpc/lib.rs（アプリ向け RPC）。wasm でブラウザ動作。

Step 5: Naive vs ZK light client

Naive = O(N) per-header on-chain / ZK = O(1) on-chain + O(N) off-chain。高スループットで ZK 漸近勝利。

Step 6: Reth ベース chain の役割

Source = Reth がデフォルトで light client フレンドリー / Destination = mainnet 互換で任意 Solidity light client 動作。

答え合わせ

• PoS が PoW より light client friendly な理由: PoW = chain-of-work 検証（マイナー逐次署名なし、Merkle proof のみ）→ trust 仮定が弱い + 安価検証困難。PoS = 固定 validator + BLS 集約 → 「committee が署名したか」を 1 つの BLS 検証で確認可能 → 数 MB + ~ms。経済モデルが light client を成立させた。
• ZK light client が漸近的に安くなる場面: スループットが高く on-chain ガスが律速。Naive O(N) per-header → ZK O(1) on-chain + O(N) off-chain（GPU で安く）。10000 header / 日なら naive $5000、ZK $50 + off-chain $10 = $60。100× 削減。
• Reth ベース chain の light client 設計の自由度: Source 側は Reth がデフォルトで提供（Header + Merkle + BLS）、Destination 側は mainnet 互換 EVM で任意 Solidity light client が動く。自由度を最大化したまま最小信頼を維持。Tempo の場合、Ethereum 上の Tempo light client を別途書く必要あり（こちらは validator ~30 で安価）。

合格基準

• Light client の できる 4 / できない 3 を即答できる。
• Sync committee + BLS の仕組みを 1 文で説明できる。
• 3 必要要素を順に言える。
• Helios の 3 主要ファイルを役割で言える。
• Naive vs ZK light client の漸近コスト trade を計算できる。

まとめ（3行）

• Light client = 数 MB + スマホ CPU でフルノードと同じ検証、PoS + BLS 集約が経済性を成立、Helios が a16z 製 Rust 本番実装（~10k 行）。
• 3 必要要素（初期信頼 checkpoint + sync committee 更新 + header 更新）で chain に追従、検証は ~ms。
• Bridge endgame = ZK light client（trust = 数学、on-chain O(1)、高スループットで漸近勝利、Succinct SP1 / Espresso / Polyhedra が本番例）。