---
title: "ライトクライアント"
description: "フォークを認識するコンセンサス・ライトクライアントのブートストラップ、同期委員会、弱主観性チェックポイント、楽観的／ファイナライズ済みヘッダー、実行状態証明、RPCプロバイダー、データ可用性、プライバシーを解説します。"
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.
# ライトクライアント
> 教育目的の情報であり、セキュリティまたは取引の助言ではありません。ライトクライアントが検証するのは、設定されたプロトコルと証明が対象とするオブジェクトだけです。対象チェーン、フォーク、チェックポイント、ヘッダー状態、プロバイダー、未検証のデータ領域を確認してください。
## 端的な答え
ライトクライアントは、フルノードより少ないローカル実行、状態、履歴でブロックチェーンを追跡する検証ソフトウェアです。ライトノードは、そのソフトウェアを実行する機器またはプロセスです。Proof of Stake型Ethereumのコンセンサス・ライトクライアントは、信頼できる最近のファイナライズ済みチェックポイントから起動し、フォークを認識した同期委員会更新を検証して、楽観的ヘッダーとファイナライズ済みヘッダーを維持します。すべてのEVMトランザクションを再実行するわけではありません。
検証済みのコンセンサスビューは、最初の信頼アンカーにすぎません。アカウントまたはコントラクトのストレージ値を検証するには、認証済みBeaconヘッダーを実行ペイロードヘッダーに結び付け、その `stateRoot` を選び、そのルートに対してアカウント証明またはストレージ証明を検証する必要があります。必要な証明を伴わない通常のRPC応答は、依然としてプロバイダーの主張です。コンセンサス署名は、トランザクション履歴、レシート、トレース、データ可用性、アプリケーションの挙動、長期的な検索可能性を自動的に証明しません。
## 仕組み
1. ネットワークと信頼ルートを固定します。チェーン識別情報、ジェネシスのバリデータールートと時刻、フォークスケジュールとプリセット、現在時刻、クライアント版、信頼できる最近のファイナライズ済み弱主観性チェックポイントを記録します。独立した認証済み情報源でチェックポイントを相互確認します。悪意ある起点ルートは、ピア間の合意では修復できません。
2. 信頼済みブロックルートに対応する `LightClientBootstrap` を取得します。ブートストラップヘッダー、現在の同期委員会とそのMerkleブランチを検証し、`LightClientStore` を初期化します。設定したフォークと一致しないチェーン、フォークダイジェスト、一般化インデックス、シリアライズ形式は拒否します。
3. 同期委員会期間ごとに `LightClientUpdate` を処理します。委員会を交代する前に、スロット、参加ビット、BLS集約署名とドメイン、現在および次期委員会ブランチ、ファイナリティブランチ、単調性を検証します。フォーク更新によりオブジェクトのフィールドや一般化インデックスが変わるため、Altairの定数は永続的な共通値ではありません。
4. `optimistic_header` と `finalized_header` の方針を分けて維持します。楽観的更新は新しい情報を提供できますが、再編成やデータ秘匿へのエクスポージャーが大きくなります。ファイナライズ済み更新はコンセンサス状態が強い一方、遅れる場合があります。アプリケーションは用途に合うヘッダーを明示的に選び、最新応答を最終確定済みと読み替えてはいけません。
5. 実行データをアンカーします。認証済みライトクライアントヘッダーが含む実行ペイロードヘッダーとブランチを検証し、各アカウントまたはストレージ照会を、その実行 `stateRoot`、ブロックハッシュ、ファイナリティ状態に結び付けます。Ethereumでは `eth_getProof` がアカウント証明と指定したストレージ証明を返せます。ノード、パス、値、不存在性をローカルで検証します。
6. 未検証の領域をすべて棚卸しします。残高証明は、トランザクションレシート、ログ照会、トレース、callシミュレーション、mempool、トークンラベル、オラクル、blob、履歴範囲、プロバイダーが結果を省略していないという主張を認証しません。必要な各オブジェクトについて、証明、独立再構築、フルノードへのフォールバック、または明示的な信頼前提を定めます。
7. 検証失敗時は閉じる運用にします。チェックポイント、フォーク、楽観的／ファイナライズ済みルート、実行ブロックと状態ルート、証明ノード、プロバイダー、タイムスタンプを記録します。最大許容鮮度を強制し、プロバイダーとネットワーク経路を分散し、照会プライバシーを保護し、Eclipse攻撃と停止からの復旧を試験します。証明対象が不足する場合は、フルノードまたは別の検証システムを使います。
## 計算例
- **同期委員会の整数境界。** `512` 人の委員会では、仕様上の超多数判定は `participants * 3 >= 512 * 2` です。参加者が `341` 人なら、`341 / 512 = 66.6015625%` かつ `1,023 < 1,024` なので不合格です。`342` 人なら、`342 / 512 = 66.796875%` かつ `1,026 >= 1,024` なので合格です。これは設定された更新規則の検証であり、全委員または全実装の誠実性を証明するものではありません。
- **ヘッダーの時計。** 教材上のチェックポイントをスロット `10,000`、認証対象ヘッダーを `10,064`、そのファイナライズ済みヘッダーを `10,032` とします。`12 seconds/slot` なら、認証対象ヘッダーはチェックポイントより `64 * 12 = 768 seconds = 12 minutes 48 seconds` 後で、ファイナライズ済みヘッダーは認証対象より `32 * 12 = 384 seconds = 6 minutes 24 seconds` 遅れます。スロット時刻は、ネットワーク配信や一定の実時間内でのファイナリティを保証しません。
- **小さなブランチ、限定された主張。** `2^20` 個の葉を持つ理想的な平衡木では、単一葉のブランチに `20` 個の兄弟ハッシュがあります。`32 bytes/hash` なら `640 bytes` です。`8 MiB = 8,388,608 bytes` のオブジェクトと比べると、ブランチは `0.00762939453125%` で、`99.99237060546875%` の削減です。このブランチが証明するのは葉からルートへの関係だけで、他のバイトの可用性ではありません。
- **証明と証明なしRPC。** ファイナライズ済み実行 `stateRoot` に対する検証済みアカウント証明が `3.25 ETH` を示し、証明なしRPC応答が `3.30 ETH` を示したとします。差は `0.05 ETH` で、証明なし応答は `0.05 / 3.30 = 1.5151515152%` 高くなっています。選択したルートの下で証明された値を採用しますが、その証明から後時点の残高、レシート、履歴結果、トークン同一性を推定してはいけません。
## リスク
- 誤ったチェーン、ジェネシスのバリデータールート、ジェネシス時刻、プリセットを設定する。
- 悪意ある、古い、または未確定のチェックポイントから起動する。
- 未認証のチェックポイント情報源を一つだけ使う、または長距離フォークを受け入れる。
- ローカル時刻のずれにより、スロット、期間、ドメイン、鮮度判定を誤る。
- 古いフォークスケジュール、オブジェクト形式、一般化インデックスを使う。
- 同期委員会の参加度、BLS署名、ドメインを検証しない。
- 委員会交代を見落とす、または無効な現・次期委員会を受け入れる。
- 楽観的ヘッダーをファイナライズ済みヘッダーとして扱う。
- 誤ったBeaconヘッダー、実行ペイロード、実行ブロックハッシュを結び付ける。
- 誤った `stateRoot` に対してアカウントまたはストレージ証明を検証する。
- 不正形式のtrieノード、パス、エンコード、不存在証明を受け入れる。
- 未対応または証明なしのRPCメソッドを検証済みとみなす。
- 古い、検閲済み、不完全、または捏造されたプロバイダー応答を受け取る。
- 見かけ上別のプロバイダーが共通支配される、またはEclipse／Sybil攻撃を受ける。
- 証明を提供するフルノードのプルーニングや停止でライブネスを失う。
- コンセンサス妥当性を、実行の再現またはアプリケーションの正しさと混同する。
- 有効な証明を、データ可用性または永続的な検索可能性と混同する。
- アプリケーションに必要なレシート、ログ、トレース、ブロック本体、履歴がない。
- クライアント実装、依存関係、バイナリ、フォーク更新が失敗する。
- 照会内容、IP、アカウント、トランザクションのプライバシーが漏れる。
## よくある誤解
- ライトクライアントは、小型フルノードまたはリモートRPCの別名にすぎない。
- 同期委員会ヘッダーを検証すれば、すべてのRPC応答を信頼できる。
- 最新の楽観的ヘッダーは、ファイナライズ済みヘッダーと同じである。
- Merkle証明またはコンセンサス署名は、データ可用性と完全な履歴を証明する。
- ライトクライアントを使えば、フルノード同等のプライバシー、ライブネス、検閲耐性を自動的に得られる。
## 関連トピック
- [フルノード](/ja/crypto/full-node/)
- [弱主観性](/ja/crypto/weak-subjectivity/)
- [状態ルート](/ja/crypto/state-root/)
## 出典
- [Light clients](https://ethereum.org/developers/docs/nodes-and-clients/light-clients/) - Ethereum.org（参照日: 2026-08-13）
- [Altair Light Client -- Sync Protocol](https://ethereum.github.io/consensus-specs/specs/altair/light-client/sync-protocol/) - Ethereum Consensus Specs（参照日: 2026-08-13）
- [Altair Light Client -- Light Client](https://ethereum.github.io/consensus-specs/altair/light-client/light-client/) - Ethereum Consensus Specs（参照日: 2026-08-13）
- [Electra Light Client -- Sync Protocol](https://ethereum.github.io/consensus-specs/electra/light-client/sync-protocol/) - Ethereum Consensus Specs（参照日: 2026-08-13）
- [Weak subjectivity](https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) - Ethereum.org（参照日: 2026-08-13）
- [eth_getProof](https://ethereum.github.io/execution-apis/api/methods/eth_getProof/) - Ethereum Execution APIs（参照日: 2026-08-13）
- [Merkle Patricia Trie](https://ethereum.org/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) - Ethereum.org（参照日: 2026-08-13）
- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org（参照日: 2026-08-13）
Source: https://wiki.fcontext.com/ja/crypto/light-client/index.mdx