メインコンテンツへスキップ
Change page

ライト・クライアント

フル・ノードを実行することは、イーサリアムとやり取りするための、最もトラストレスでプライベート、かつ分散型で検閲耐性のある方法です。フル・ノードを使用すると、即座にクエリを実行できるブロックチェーンの独自のコピーを保持し、イーサリアムのピア・ツー・ピア・ネットワークに直接アクセスできます。しかし、フル・ノードを実行するには、大量のメモリ、ストレージ、およびCPUが必要です。つまり、誰もが独自のノードを実行できるわけではありません。イーサリアムのロードマップには、ステートレス性など、これに対するいくつかの解決策がありますが、実装されるまでには数年かかります。短期的な答えは、フル・ノードを実行する利点の一部を妥協する代わりに、非常に低いハードウェア要件でノードを実行できるようにする大幅なパフォーマンス向上を得ることです。この妥協を行うノードは、ライト・ノードと呼ばれます。

ライト・クライアントとは

ライト・ノードとは、ライト・クライアント・ソフトウェアを実行しているノードのことです。ブロックチェーン・データのローカルコピーを保持し、すべての変更を独立して検証する代わりに、必要なデータをプロバイダーに要求します。プロバイダーは、フル・ノードへの直接接続である場合もあれば、中央集権型のRPCサーバーを経由する場合もあります。その後、データはライト・ノードによって検証され、チェーンの先頭に追従できるようになります。ライト・ノードはブロック・ヘッダーのみを処理し、実際のブロックの内容をダウンロードするのは時々だけです。ノードの軽量さは、実行するライト・クライアントとフル・クライアント・ソフトウェアの組み合わせによって異なります。たとえば、最も軽量な構成は、ライト実行クライアントとライト・コンセンサス・クライアントを実行することです。また、多くのノードが、フル実行クライアントとライト・コンセンサス・クライアントを組み合わせて実行したり、その逆を選択したりする可能性もあります。

ライト・クライアントはどのように機能するのか？

イーサリアムがプルーフ・オブ・ステーク (PoS) ベースのコンセンサス・メカニズムを使用し始めたとき、ライト・クライアントをサポートするために特化した新しいインフラストラクチャが導入されました。その仕組みは、1.1日ごとに512人のバリデータのサブセットをランダムに選択し、シンク・コミッティとして機能させるというものです。シンク・コミッティは、最近のブロックのヘッダーに署名します。各ブロック・ヘッダーには、シンク・コミッティ内のバリデータの集約署名と、どのバリデータが署名し、どのバリデータが署名しなかったかを示す「ビットフィールド」が含まれています。各ヘッダーには、次のブロックの署名に参加することが期待されるバリデータのリストも含まれています。これにより、ライト・クライアントは、受信したデータにシンク・コミッティが署名したことをすばやく確認できます。また、受信したシンク・コミッティと、前のブロックで期待されていたシンク・コミッティを比較することで、それが本物であるかどうかも確認できます。このようにして、ライト・クライアントは、ブロック自体を実際にダウンロードすることなく、要約情報を含むヘッダーのみを使用して、最新のイーサリアム・ブロックに関する知識を更新し続けることができます。

実行レイヤーには、ライト実行クライアントの単一の仕様はありません。ライト実行クライアントの範囲は、フル・ノードのすべてのEVMおよびネットワーク機能を備えつつ、関連データをダウンロードせずにブロック・ヘッダーのみを検証するフル実行クライアントの「ライト・モード」から、イーサリアムとやり取りするためにRPCプロバイダーへのリクエスト転送に大きく依存する、より機能が削ぎ落とされたクライアントまでさまざまです。

なぜライト・クライアントが重要なのか？

ライト・クライアントが重要なのは、フル・ノードのほんのわずかな計算リソースを使用するだけで、データ・プロバイダーが正確で誠実であると盲目的に信頼するのではなく、ユーザーが受信データを検証できるからです。ライト・クライアントが受信したデータは、512人のランダムなイーサリアム・バリデータのセットのうち少なくとも3分の2によって署名されたことがわかっているブロック・ヘッダーと照合できます。これは、データが正しいことを示す非常に強力な証拠です。

ライト・クライアントは、ごくわずかな計算能力、メモリ、ストレージしか使用しないため、携帯電話で実行したり、アプリに組み込んだり、ブラウザの一部として実行したりできます。ライト・クライアントは、イーサリアムへのトラスト最小化されたアクセスを、サードパーティのプロバイダーを信頼するのと同じくらいスムーズにする方法です。

簡単な例を挙げてみましょう。アカウントの残高を確認したいとします。これを行うには、イーサリアム・ノードにリクエストを送信する必要があります。そのノードは、イーサリアムの状態のローカルコピーであなたの残高を確認し、それを返します。ノードに直接アクセスできない場合は、このデータをサービスとして提供する中央集権型のオペレーターが存在します。彼らにリクエストを送信すると、彼らは自身のノードを確認し、結果を返してくれます。これの問題点は、プロバイダーが正しい情報を提供していると信頼しなければならないことです。自分で検証できなければ、その情報が本当に正しいかどうかを知ることはできません。

ライト・クライアントは、この問題に対処します。依然として外部プロバイダーにデータを要求しますが、データを受信すると、ライト・ノードがブロック・ヘッダーで受信した情報と照合できる証明が付属しています。つまり、信頼できるオペレーターの代わりに、イーサリアムがデータの正確性を検証していることになります。

ライト・クライアントはどのようなイノベーションを可能にするのか？

ライト・クライアントの主な利点は、無視できるほどのハードウェア要件とサードパーティへの最小限の依存で、より多くの人々が独立してイーサリアムにアクセスできるようにすることです。これは、ユーザーが自身のデータを検証できるためユーザーにとって有益であり、チェーンを検証するノードの数と多様性が増加するためネットワークにとっても有益です。

非常に少ないストレージ、メモリ、処理能力のデバイスでイーサリアム・ノードを実行できる機能は、ライト・クライアントによって解き放たれたイノベーションの主要な分野の1つです。現在のイーサリアム・ノードは多くの計算リソースを必要としますが、ライト・クライアントはブラウザに組み込んだり、携帯電話で実行したり、おそらくスマートウォッチなどのさらに小さなデバイスでも実行できるようになります。つまり、クライアントが組み込まれたイーサリアム・ウォレットを携帯電話で実行できるようになります。これにより、モバイル・ウォレットはデータについて中央集権型のデータ・プロバイダーを信頼する必要がなくなるため、はるかに分散型になる可能性があります。

これの延長線上にあるのが、モノのインターネット (IoT) デバイスの有効化です。ライト・クライアントを使用すると、シンク・コミッティによって提供されるすべてのセキュリティ保証を伴って、トークン残高やNFTの所有権をすばやく証明し、IoTネットワーク上で何らかのアクションをトリガーできます。組み込みのライト・クライアントを備えたアプリを使用して、レンタルサービスのNFTを所有していることをすばやく検証し、所有している場合は自転車のロックを解除して乗れるようにする自転車レンタルサービス (opens in a new tab)を想像してみてください！

イーサリアムのロールアップも、ライト・クライアントの恩恵を受けるでしょう。ロールアップの大きな問題の1つは、イーサリアム・メインネットからロールアップへの資金の送金を可能にするブリッジを標的としたハッキングでした。脆弱性の1つは、ユーザーがブリッジに預け入れを行ったことを検出するためにロールアップが使用するオラクルです。オラクルが不正なデータを提供した場合、ブリッジへの預け入れがあったとロールアップを騙し、誤って資金を解放させる可能性があります。ロールアップに組み込まれたライト・クライアントは、トークンを解放する前にロールアップによって検証できる証明をブリッジへの預け入れに付随させることができるため、破損したオラクルから保護するために使用できます。同じ概念は、他のインターチェーン・ブリッジにも適用できます。

ライト・クライアントは、イーサリアム・ウォレットのアップグレードにも使用できます。RPCプロバイダーから提供されたデータを信頼する代わりに、ウォレットは組み込みのライト・クライアントを使用して、提示されたデータを直接検証できます。これにより、ウォレットのセキュリティが向上します。RPCプロバイダーが不誠実で不正確なデータを提供した場合、組み込みのライト・クライアントがそれを教えてくれます！

ライト・クライアント開発の現状は？

実行、コンセンサス、および実行/コンセンサスを組み合わせたライト・クライアントなど、いくつかのライト・クライアントが開発中です。このページを執筆している時点で私たちが把握しているライト・クライアントの実装は以下の通りです。

私たちの知る限り、これらの中でまだ本番環境の準備が整っていると見なされているものはありません。

ライト・クライアントがイーサリアムのデータにアクセスする方法を改善するための多くの作業も行われています。現在、ライト・クライアントはクライアント/サーバー・モデルを使用してフル・ノードへのRPCリクエストに依存していますが、将来的には、ピア・ツー・ピアのゴシップ・プロトコルを使用してライト・クライアントにデータを提供できるポータル・ネットワーク (opens in a new tab)などの専用ネットワークを使用して、より分散化された方法でデータを要求できるようになる可能性があります。

ヴァークル・ツリーやステートレス性などの他のロードマップの項目は、最終的にライト・クライアントのセキュリティ保証をフル・クライアントと同等にするでしょう。

参考文献