軽量クライアントプロトコル

軽量クライアントが解く問題

ブロックチェーンを完全に検証するフルノードは、全ブロック・全状態を保持し、あらゆる取引を独立に再計算します。安全性は最大ですが、ビットコインで数百GB、Ethereumのアーカイブノードで数TBに達し、スマートフォンやブラウザ拡張、オンチェーンのブリッジには重すぎます。そこで登場するのが軽量クライアント（light client）です。台帳の大半を持たずに、それでも「サーバーの言うことを鵜呑みにはしない」水準の検証を目指す設計です。

鍵になるのは、検証を2つに分けて考えることです。ひとつはどのブロックが正典（canonical chain）かを決めるコンセンサスの追跡。もうひとつはある状態や取引がそのブロックに含まれるかの包含検証です。軽量クライアントは前者を「ヘッダや委員会署名の連鎖」に、後者を「マークル証明」に切り詰めることで成立します。

ヘッダ同期とマークル証明（PoW / SPV）

Nakamoto合意のチェーンで軽量クライアントの原型は、ビットコイン原論文の SPV（Simplified Payment Verification）です。SPVクライアントは取引本体を捨て、各ブロックのヘッダだけを連鎖として保持します。ヘッダは80バイト程度で、前ブロックのハッシュ・マークルルート・難易度目標を含みます。

ヘッダ鎖だけで何が言えるのか。前ブロックハッシュが鎖を繋ぎ、各ヘッダが自身の Proof-of-Work（難易度目標を満たすハッシュ）を内包するため、クライアントは累積仕事量が最大の枝を最重鎖ルールで選べます。つまり全取引を持たずとも「このヘッダ鎖が最も work を積んだ枝である」ことは検証可能です。

その上にマークル証明を重ねます。「取引 Tx がブロック N に含まれる」ことは、Tx から根へ登る経路上の兄弟ハッシュ列（約 log2(件数) 個）で示せます。手順は次のとおりです。

1. クライアントはフルノードへ「Tx の包含証明が欲しい」と要求
2. フルノードは Tx を含むブロックのマークル経路（兄弟ハッシュ列）を返す
3. クライアントは手元の Tx から proof を畳み込み、ルートを再計算
4. 再計算ルートが、自分の持つヘッダ N のマークルルートと一致するか照合
5. 一致し、かつヘッダ N が最重鎖上にあれば包含を承認

証明サイズが件数の対数で済む数理はマークル木の包含証明に譲りますが、この対数性こそが軽量クライアントを成立させる土台です。ブロックに10万件入っていても、証明は20個弱のハッシュで足ります。

同期委員会（sync committee）（PoS / Ethereum）

PoSへ移行したEthereumでは、ヘッダに Proof-of-Work が無いため、クライアントは「このヘッダを本当に多数のバリデータが承認したのか」をハッシュ計算では確かめられません。そこで導入されたのが同期委員会（sync committee）です。

同期委員会は、全バリデータ集合から擬似乱数で選ばれる512人の部分集合で、約27時間（256エポック）ごとに交代します。委員会のメンバーは各スロットで最新のビーコンブロックヘッダに署名し、その署名を集約したものをヘッダに添えて公開します。軽量クライアントはこの署名を検証することで、フルノードを持たずに「ネットワークが今このヘッダを正典と見なしている」ことを確認します。

この512署名を扱えるのはBLS署名の集約のおかげです。BLSは多数の署名を1つに畳み込め、対応する公開鍵も集約鍵として1つにまとめられます。クライアントは「委員会512人のうち、実際に署名した部分集合の集約公開鍵」を自分で再構成し、集約署名1つを1回のペアリング検証で確かめます。署名アルゴリズムの基礎は署名・鍵管理で扱うECDSAと系譜が異なりますが、「本人だけが作れ誰もが検証できる」性質を集約可能な形で持つ点が要点です。

信頼最小化の限界

軽量クライアントは強力ですが、フルノードと同等ではありません。設計上の限界を切り分けて理解することが、実務での安全な使い方に直結します。

第一に、証明できるのは包含であって正しさではありません。マークル証明は「その値がこのルートの木に入っている」ことしか示しません。そのブロック自体が無効な状態遷移を含んでいても、軽量クライアントは全状態を再計算しないため気づけません。SPVが二重支払いを自力で完全排除できないのと同根で、最終的にはコンセンサスの多数派が正直という仮定に寄りかかっています。この多数派仮定の中身はコンセンサスと確率的ファイナリティそのものです。

第二に、不在証明が難しいことです。「この取引は存在しない」「このアカウントは残高ゼロだ」を素朴なマークル木では証明できません。フルノードが証明の対象を隠して返さなければ、クライアントは不在なのか秘匿されたのか区別できない。Ethereumはキーでソートしたマークル・パトリシア木を用いるため不在証明が可能ですが、これは構造の選択に依存する能力です。

第三に、接続先への依存です。軽量クライアントは状態値を外部のフルノードから取り寄せるため、接続先が特定の取引を返さない（検閲する）と、証明の要求自体が届きません。改竄は証明照合で弾けても、沈黙による検閲は原理的に防げない。対策は複数の独立したピアへ問い合わせることですが、これはP2P層の冗長性の問題であり、単一のRPCへの接続では担保できません。

まとめ

• 軽量クライアントはブロック本体を持たず、コンセンサス追跡（ヘッダ鎖／委員会署名）と包含検証（マークル証明）に検証を切り詰めることで、モバイルやブラウザでも信頼最小化の検証を成立させる。
• PoWのSPVは各ヘッダの Proof-of-Work から最重鎖を選び、マークル証明を既知のルートに畳み込んで取引の包含を確かめる。証明は件数の対数サイズで済む。
• Ethereumの同期委員会は512人の部分集合が最新ヘッダに署名し、BLS集約署名で1回のペアリング検証に畳み込む。委員会は約27時間ごとに交代し、クライアントは鍵集合の更新署名だけを追う。
• 信頼最小化には限界がある。証明できるのは包含であって状態の正しさではなく、多数派仮定に依存する。不在証明・データ可用性・接続先の検閲には原理的に弱く、同期委員会の閾値はBFTの確定的ファイナリティより緩い。