ライトクライアント

イーサリアムとやり取りする最もトラストレスで、プライバシーが保護され、分散化され、検閲耐性のある方法は、フルノードを実行することです。フルノードを持っていると、ブロックチェーンのコピーを自分自身で保持するため、即座にクエリを投げられます。また、イーサリアムのピアツーピアネットワークにも直接アクセスすることができます。しかし、フルノードの実行には、大容量のメモリとストレージ、そしてCPUが必要です。そのため、すべての人が自分のノードを実行できるわけではありません。イーサリアムのロードマップには、これを解決するためのステートレスなどの解決策がありますが、実装には数年かかる見通しです。短期的な解決策としては、フルノードの利点を一部犠牲にして、ハードウェア要件を大幅に低下させ、パフォーマンスを向上させるライトクライアントがあります。

ライトクライアントとは

ライトノードとは、ライトクライアントのソフトウェアを実行しているノードです。ブロックチェーンデータのコピーを保存して、すべての変更を自分で検証するかわりに、ライトクライアントは、必要なデータをいくつかのプロバイダーにリクエストをします。プロバイダーは、フルノードに直接接続するか、中央集権型のRPCサーバーを通して接続する場合があります。このデータは、ライトノードによって検証され、チェーンの先頭に追いつくことができます。ライトノードは、ブロックヘッダーのみを処理し、必要に応じて実際のブロックのコンテンツをダウンロードします。ノードがどの程度軽量になるかは、実行するライトクライアントソフトウェアとフルクライアントソフトウェアの組み合わせによって決まります。例えば、最も軽量なノードは、ライト実行クライアントとライトコンセンサスクライアントを実行します。また、多くのノードは、フル実行クライアントとライトコンセンサスクライアントを組み合わせて実行したり、その逆を選択したりするかもしれません。

ライトクライアントが動作する仕組み

イーサリアムがプルーフ・オブ・ステークに基づいたコンセンサスメカニズムを使い始めた当時、ライトクライアントを特別にサポートするための新しいインフラストラクチャが導入されました。この仕組みは、同期委員会として機能する512台あるバリデータのサブセットを1.1日ごとにランダムに選ぶことで機能します。同期委員会は、最新のブロックのヘッダーに署名します。すべてのブロックヘッダーには、同期委員会のバリデータによる集約された署名と、どのバリデータが署名し、どのバリデーターが署名しなかったかを示す「ビットフィールド」があります。また、各ヘッダーには、次のブロックの署名に参加することになっているバリデータのリストもあります。つまり、ライトクライアントでは、受信したデータの署名が同期委員会のものであることがすぐに確認できます。また、前のブロックから予想したデータと受信したデータを比較することで、同期委員会が本物であることも確認できます。この方法で、ライトクライアントは、実際にブロック自体をダウンロードせずに、要約された情報を含むヘッダーだけで、最新のイーサリアムのブロックが持つ情報を更新し続けることができます。

実行レイヤーでは、ライト実行クライアントの仕様が統一されていません。ライト実行クライアントの範囲は、フル実行クライアントの「ライトモード」とは異なる場合があります。「ライトモード」では、フルノードと同じEVMとネットワーク機能をすべて備えています。しかし、関連するデータをダウンロードせずにブロックヘッダーのみを検証するか、イーサリアムとのやり取りにおいてリクエストをRPCプロバイダーへ転送することに依存した、よりシンプルなクライアントになるかもしれません。

ライトクライアントが重要である理由

ライトクライアントが重要な理由は、ユーザーがデータプロバイダーを妄信せず、受信したデータを自分で検証できるようになるからです。また、ライトクライアントはフルノードに比べて、計算リソースを大幅に節約できます。ライトクライアントが受信するデータは、ランダムに選ばれたイーサリアムのバリデータ512台のうち、少なくとも3分の2の署名が付いたブロックヘッダーで確認できます。このブロックヘッダーは、データが正しいことの非常に強力な証明です。

ライトクライアントは、コンピューティングパワー、メモリ、ストレージをそれほど必要としないため、携帯電話で実行したり、アプリに埋め込んだり、ブラウザの一部として実行したりできます。サードパーティプロバイダーに依存するのと変わらないほどスムーズに、信頼を最小限に抑えてイーサリアムへアクセスできるのがライトクライアントです。

ここで簡単な例を上げてみましょう。例えば、自分のアカウントの残高を確認したい場合を考えてみましょう。確認するには、イーサリアムノードにリクエストを送信する必要があります。リクエストされたノードは、イーサリアムが持つ状態のローカルコピーをチェックして残高を確認し、結果を返します。ノードに直接アクセスできない場合は、中央集権化されたオペレーターが提供するデータを使用することになります。中央集権化されたオペレーターへリクエストを送信すると、彼らはノードを確認し、その結果を返します。ここで問題となるのは、このプロバイダーが正しい情報を提供していると信頼しなければならないことです。自分自身で検証できなければ、その情報が正しいかどうかは決してわかりません。

ライトクライアントは、この問題を解決します。外部のプロバイダーにデータを要求する必要はありますが、データを受信すると、証明が添付されており、ライトノードはこの証明を使って、ブロックヘッダーで受信した情報と照合することができます。これにより、信頼できるオペレーターに代わって、イーサリアムでデータの正確性を検証することができます。

ライトクライアントが可能にするイノベーション

ライトクライアントの主な利点は、ハードウェアの要件を問わず、サードパーティへの依存を最小限に抑え、より多くの人が単独でイーサリアムにアクセスできるようになることです。ユーザーにとっては、自分でデータを検証できるというメリットがあります。ネットワークにとっても、チェーンを検証するノードの数と多様性が増加するメリットがあります。

ストレージやメモリ、処理能力が小さいデバイスでも、イーサリアムノードを実行できるようになることは、ライトクライアントによって実現される重要なイノベーションひとつです。現在のイーサリアムノードは、大量のコンピューティングリソースを必要としますが、ライトクライアントはブラウザに埋め込むことができ、携帯電話、さらにはスマートウォッチなどの小型デバイスでも実行できる可能性があります。つまり、携帯電話でイーサリアムウォレットと組み込みクライアントを実行できるということです。その結果、モバイルウォレットはデータに関して中央集権的なデータプロバイダーに依存する必要がなくなり、より分散化された運用が可能になります。

この拡張により、IoT(モノのインターネット)デバイスでもライトクライアントを実行できるようになります。ライトクライアントでは、同期委員会によって提供されるセキュリティ保証を活用して、トークンの残高やNFTの所有権を即座に証明できます。これは、IoTネットワーク上でのさまざまな用途につながります。例えば、自転車のレンタルサービス(opens in a new tab)を想像してみてください。ライトクライアントが組み込まれているアプリを使用して、そのレンタルサービスのNFTを所有していることをすぐに確認し、自転車のロックを解除して、乗ることができます。

ライトクライアントは、イーサリアムのロールアップにもメリットがあります。ロールアップの大きな問題のひとつは、イーサリアムメインネットからロールアップに資金を移動するブリッジを標的としたハッキングです。脆弱性のひとつが、ユーザーがブリッジに入金したことを検出するためにロールアップが使用するオラクルです。オラクルが不正なデータを提供すると、ロールアップはブリッジに入金があったと誤解し、誤って資金をリリースしてしまう可能性があります。ロールアップに組み込まれたライトクライアントは、汚染されたオラクルを保護するのに役立ちます。なぜなら、ブリッジへの入金時に、トークンをリリースする前に、ロールアップで検証できる証明を添付できるからです。このコンセプトは、他のチェーン間ブリッジにも適用できます。

ライトクライアントは、イーサリアムウォレットのアップグレードにも使えます。 RPCプロバイダーから提供されるデータを信頼する代わりに、組み込みのライトクライアントを使用して、ウォレットに送信されたデータを直接検証できます。これでウォレットのセキュリティが高まります。 RPC プロバイダーが誤ったデータを不正に提供した場合、組み込みのライトクライアントは、それを検出できるでしょう。

ライトクライアント開発の現状

現在、さまざまなライトクライアントの開発が進められています。ライトクライアントには、実行クライアント、コンセンサスクライアント、実行およびコンセンサスクライアントを結合したものがあります。本ページの執筆時点で周知となっているライトクライアントの実装は、次の通りです。

Lodestar(opens in a new tab): TypeScriptで実装されたコンセンサスライトクライアント
Helios(opens in a new tab): Rustで実装された実行およびコンセンサスを結合したライトクライアント
Geth(opens in a new tab): Goで実装された実行クライアントのライトモード(開発中)
Nimbus(opens in a new tab): Nimで実装されたコンセンサスライトクライアント

現時点では、これらはまだ本番環境で使用できるものではありません。

また、ライトクライアントがイーサリアムのデータにアクセスする方法の改善にも、多くの作業が必要です。現状、ライトクライアントは、クライアント/サーバーモデルを使用したフルノードへのRPCリクエストが必要ですが、将来的には、ポータルネットワーク(opens in a new tab)などのピアツーピアのゴシッププロトコルを使用して、ライトクライアントに対してデータを提供できるようになります。

バークルツリーやステートレスなどのロードマップアイテムの導入により、ライトクライアントのセキュリティ保証もフルクライアントと同等になるでしょう。