以下は、ライトクライアント愛好家のPhil Ngo氏、Gajinder Singh氏(Lodestar)、Guillaume Ballet氏(Geth)、Matt Garnett氏(EF)による最近の Twitterスペースに基づいています。

Lodestarでは、フルノードに接続してブロックチェーンと対話するソフトウェアであるライトクライアントを長年支持してきました。独自のフルノードを実行する代わりに、リソースに優しくトラストレスな代替手段として、ライトクライアントはサードパーティを信頼する必要性を減らします。 ブロックを確認するものではありませんが、トラストレスなブロックチェーンデータに直接アクセスするという点では価値があります。

しかし、理論上の価値はあるものの、ライトクライアントをイーサリアムとのやり取りの標準的な部分にするための作業はまだあります。 以下では、ユーザーエクスペリエンスを損なうことなくトラストレスネスの重要性を強調しながら、いくつかの既存の課題(および進捗状況)を掘り下げます。

ライトクライアントとは

イーサリアムと関わる最も分散化されたトラストレスな方法は、フルノードを実行することです。 しかし、これは簡単な作業ではなく、ブロックチェーンの独立したコピーを維持し、イーサリアムのピアツーピアネットワークに即座に直接アクセスする必要があるため、大量のメモリ、ストレージ、CPUが必要であり、多くのユーザーにとって実現不可能です。 言うまでもなく、多くの場合、チェーン全体を検証する必要はありません。

無国籍化などのこの問題の解決策は、現実のものになるのに何年も先のことです。今のところ、最小限のハードウェア要件で機能するためにフルノードを実行することの利点をいくつか犠牲にすることは、私たちが楽観的に考えている有望なソリューションです。

実際、私たちは昨年、ライトクライアントに関する記事を公開し、いくつかの問題の解決策として ライトクライアントを擁護しました。

この目的のために、ライトクライアントはブロックチェーンシステムにおいて極めて重要な役割を果たし、フルノードを実行したくないユーザーに、ネットワーク全体を同期させることなくイーサリアムへの安全なアクセスを提供します。

ライトクライアントは、ローカルのブロックチェーンデータを保存して変更を自律的に検証する代わりに、プロバイダーから必要なデータを取得し、プロバイダーはフルノードに直接接続できます。 このデータはライトノードによって処理され、それが正規チェーンの一部であることを確認し、最新の状態を維持することができます。

イーサリアムは、ライトクライアントで積極的に活動している唯一のエコシステムではありません。

ライトクライアントの課題

ご存知のように、フルノードの実行には、リソースを大量に消費するタスクと、デバイスの機能と計算要件に関する制限が伴います。 ライトクライアントは単純な代替手段のように思えるかもしれませんが、歴史的に見ると、実装が困難でした。

しかし、このマージは、イーサリアムのライトクライアントであることの意味を、どのように機能し、何を提供するかという点で根本的に変えました。 Altairのハードフォークでは、同期委員会、つまりチェーンの先頭が何であるかについて軽いコンセンサスを得るための便利な方法が導入されました。 要するに、これはライトクライアントのプロトコルへのよりネイティブな統合です。

プルーフ・オブ・ステークにより、基本的にチェーンの任意の部分を選択し、プルーフを構築し、深く掘り下げることができるライトクライアントプロトコルができました。 これは以前は利用できなかったことで、スペース全体がより面白くなり、より多くの人がライトクライアントを中心に構築することを奨励しました。

ロードスタープローバー
Lodestarチームが取り組んでいることの1つがプルーバーです。 つまり、ライトクライアント同期を使用して実行側からデータを検証するため、プロバイダー(Infuraなど)から取得している情報を検証することは正しいです。

このようなことが、プロトコルにセキュリティの別のレイヤーを追加し、もう少し分散化することが期待されています。 これも最初の一歩に過ぎません。 この可能性で何が構築できるのか、もっと具体的な例が必要です。

現在、ライトクライアントの使用を妨げているものは何ですか?

これに対する答えは、技術的な側面よりも、PoCとインフラストラクチャ(Prover Libraryなど)の採用に関係しています。

トランザクションとレシートに関する証明機能を追加する必要があるため、トランザクションのSSZエンコーディングに移行する必要がありますが、それを除けば、プロトコル的にはそこにあります。

この技術は、今すぐにでも使えるのです。 ただし、UXの観点では、ライトクライアントがバックグラウンドで実行されているだけで、ユーザーの邪魔をしたり、追加の手順を要求したりしない場所に到達する必要があります。

もちろん、分散型空間で何かを強制的に採用するのは難しいですが、これを促進するためにインセンティブをどのように使用するか、MetaMaskやRainbowなどにも検討してもらう方法を考える必要があります。

マークルからヴェルクルの木への移行

効率を高めるためのデータ構造の変更 — Merkle Patricia ツリー設定から新しい Verkle ツリーへの移行は、大規模なプルーフ サイズに苦労していたライト クライアントにとって画期的なことです。

Verkle ツリーの導入は、新しいデータ構造によってこの懸念に対処します。 多項式ベースの手法を革新的に使用することで、Verkle treesは検証に必要な証明のサイズを大幅に削減し、ライトクライアントにとってプロセスをより管理しやすく合理化します。

「Verkleのおかげで、小さな証拠が手に入るという考え方です。 そのため、ステートレスクライアントと呼ぶ軽量クライアントに、与えられたものをすべて検証する方法を提供し、信頼度を下げることができます。」

このアップデートは、ライトクライアントがイーサリアムのデータと対話する方法を根本的に変えることを意味し、セキュリティや信頼性を損なうことなくブロックチェーンの状態を効率的に検証する能力を強化します。

これは、現在のライトクライアントに利益をもたらすだけでなく、将来のイノベーションの舞台を整え、ユーザーがイーサリアムをよりスムーズに、安全に、そして効率的に扱うことができる空間を作り出します。

ライト クライアントは L1 と L2 で標準化する必要がありますか?

これはやや物議を醸すトピックであり、現在議論の的となっています。 Guillaume氏によると、「L2は実験段階にあり、動きが速くて壊れる人であり、L1はより慎重で少し保守的であるため、データ構造をまだ調和させるべきではないと思います」。

本当は、標準化を検討するにはもっと時間が必要でしょう。 タイミングに関して何が理にかなっているかは未解決の問題ですが、コミュニティが調和プロセスについて考えるには、おそらく5年から10年かかるでしょう。

この遅れは、イーサリアムのレイヤーの複雑な性質と、すでに導入されている技術や設計による変更の実装の難しさによって正当化されることは間違いありません。 肝心なのは、より成熟した安定したイーサリアムインフラを可能にするために、潜在的な標準化の取り組みにもっと適した時期を待つ必要があるということです。

ライトクライアントサミット@ DevConnect 🇹🇷

来週、世界中のイーサリアムビルダーがトルコのイスタンブールに集結し、Devconnectを開催します - ライトクライアント開発の方向性に関するプレゼンテーションとディスカッションを特徴とする第3回 ライトクライアントサミットにご参加ください!

間に合わない? Twitterでご期待いただくか、Telegramで会話に参加するか、Discordの #light クライアントでアクションに参加してください。

ロードスター

Lodestarは、TypeScriptで構築され、ChainSafeによって管理されている最新のイーサリアムコンセンサスクライアントです。 当社のオープンソースのクライアントとライブラリは、世界最大の開発者グループがイーサリアムでの開発にアクセスできるようにします。 Lodestarは、ライトクライアントに焦点を当て、あらゆるタイプのデバイスとそのユーザーにとって検証可能なブロックチェーンデータの使いやすさを向上させることを目指しています。

クライアントの多様性に貢献します。 クイックスタートガイドでLodestarを実行してください。ご不明な点がございましたら、 Discord👋にお立ち寄りください

免責事項：

1. この記事は[chainsafe]からの転載です。 すべての著作権は原作者[コリンA]に帰属します。 この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。