イーサリアムライトクライアントHelios：信頼不要のオンチェーンデータアクセス

11月8日、著名なベンチャーキャピタルがイーサリアムライトクライアントHeliosを発表しました。このRust言語で書かれたクライアントは、完全に信頼不要なイーサリアムアクセスを提供することを目的としています。

ブロックチェーン技術の大きな利点は、第三者を信頼する必要がないことです。ブロックチェーンを通じて、ユーザーは自分の財産とデータを自律的に管理できます。イーサリアムなどのブロックチェーンは、ほとんどの場合、この約束を実現しています：私たちの資産は本当に私たち自身のものです。

しかし、便利さを追求するために、いくつかの妥協もしています。その一つが、中央集権的なRPC（リモートプロシージャコール）サーバーを使用することです。ユーザーは通常、中央集権的なプロバイダーを通じてイーサリアムにアクセスします。これらの会社はクラウドサーバー上で高性能ノードを運営し、ユーザーがオンチェーンデータを簡単に取得できるように支援しています。ウォレットがトークンの残高を照会したり、未処理の取引がパッケージ化されているかどうかを確認したりする際には、ほぼ常にこれらの中央集権的なプロバイダーのサービスを利用しています。

現在のシステムの問題は、ユーザーがこれらのプロバイダーを信頼する必要があり、クエリ結果の正確性を検証できないことです。

HeliosはRustに基づくイーサリアムライトクライアントで、完全に信頼不要なイーサリアムアクセスを提供します。これはイーサリアムがPoSに移行した後に実現されたライトクライアントプロトコルを利用しており、信頼できない中央集権のRPCプロバイダーからのデータを安全に検証可能なローカルRPCに変換することができます。中央集権のRPCと組み合わせることで、Heliosは完全なノードを実行せずにデータの真実性を検証できます。

利便性と非中央集権を両立させることが難しいというのは、一般的に存在する痛点です。この新型クライアント（一般公開されて開発を続けることが可能）は、約2秒で同期を完了し、ストレージスペースも必要ありません。ユーザーは、任意のデバイス（スマートフォンやブラウザプラグインを含む）を通じて安全にオンチェーンデータにアクセスできます。では、中央集権的インフラに依存することには、どのような潜在的リスクがあるのでしょうか？この記事では、これらのリスクを詳しく探り、Heliosの設計案を紹介し、開発者がコードベースに貢献するためのいくつかの提案を提供します。

中心化基盤の潜在的リスク：イーサリアムエコシステムにおける理論的脅威

イーサリアムエコシステムには理論上の脅威が潜んでいます。それは取引メモリプール（Mempool）内でターゲットを探すのではなく、私たちが依存している中央集権的インフラを模倣することで罠を仕掛けます。この罠に陥ったユーザーは何も悪いことをしていません：彼らはいつも通りに馴染みのあるDEXにアクセスし、合理的なスリッページを設定し、トークン取引を行っただけです......彼らの操作には何の問題もないのに、新しいタイプのサンドイッチ攻撃に遭遇する可能性があります。これはイーサリアムエコシステムの入り口——RPCプロバイダー——に巧妙に仕掛けられた罠です。

詳細な説明の前に、DEXがどのように取引を処理するかを見てみましょう。ユーザーがトークンを交換する際、スマートコントラクトにいくつかのパラメータを提供します：交換するトークン、交換額、そして最も重要な、ユーザーが受け入れることができる最小トークン数量です。最後のパラメータは、交換が達成しなければならない「最小出力」を決定します。そうでなければ、取引は取り消されます。これは通常「スリッページ」と呼ばれ、取引がメモリプールに送信されてからブロックにパッケージ化されるまでの間に発生する可能性のある最大価格変動を実質的に制限します。スリッページの設定が低すぎると、ユーザーは少ないトークンしか得られない可能性があります。この状況はサンドイッチ攻撃を引き起こすこともあり、攻撃者はユーザーの取引を2つの悪意のある取引の間に挟むことがあります。これらの取引は現物価格を押し上げ、ユーザーが不利な価格で取引を行わざるを得なくさせます。その後、攻撃者はすぐにトークンを売却し、小さな利益を得ます。

最小出力パラメータが適切な範囲内に設定されていれば、ユーザーはサンドイッチ攻撃の影響を受けることはありません。しかし、RPCプロバイダーがDEXスマートコントラクトの正確な見積もりを提供しない場合はどうでしょうか？この場合、ユーザーは誤って低い最小出力パラメータで交換取引を署名する可能性があります。さらに悪いことに、ユーザーは取引を悪意のあるRPCプロバイダーに直接送信してしまう可能性があります。プロバイダーはこの取引を公共メモリプールにブロードキャストせず（そこには多くのボットがサンドイッチ攻撃を競い合っています）、代わりにプライベートに保持し、攻撃される取引パケットを特定のプラットフォームに直接送信して利益を得ることができます。

この攻撃の根本的な原因は、ブロックチェーンの状態を取得するために他者を信頼することにあります。この問題を解決するために、経験豊富なユーザーは通常、自分のイーサリアムノードを運営することを選択します。これには多くの時間とリソースを投入する必要があり、少なくとも継続的にオンラインのデバイス、数百GBのストレージスペース、そしてゼロから同期するために約1日の時間が必要です。以前よりもこのプロセスは大幅に簡素化されましたが、一部のチームは低コストのハードウェア（外付けハードドライブ付きのラズベリーパイなど）を使用してユーザーがノードを運営するのを支援するために努力しています。しかし、要求が大幅に低下したとしても、特にモバイルデバイスを使用しているユーザーにとって、ノードを運営することは依然として困難な作業です。

注意すべき点は、中央集権的RPCプロバイダーへの攻撃が完全に発生する可能性があるものの、現時点では理論的なリスクに過ぎず、実際にはまだ発生していないということです。主流のプロバイダーの過去の記録は信頼できますが、知らないRPCプロバイダーをウォレットに追加する前には、十分な調査を行うことをお勧めします。

Heliosの紹介：完全に信頼不要なイーサリアムアクセス

イーサリアムが導入したライトクライアントプロトコルは、高速なオンチェーンインタラクションと最低ハードウェア要件でのRPCエンドポイントの検証に対して、エキサイティングな可能性を開きました。合併後の1ヶ月以内に、いくつかの相互独立のライトクライアントが相次いで登場し、それぞれ異なるアプローチを採用していますが、どれも同じ目標を達成するためです：信頼不要の効率的なアクセスを実現し、フルノードを使用する必要がありません。

Heliosは、約2秒で同期を完了し、ストレージスペースを必要とせず、完全に信頼不要なイーサリアムアクセスを提供するイーサリアムのライトクライアントです。すべてのイーサリアムクライアントと同様に、Heliosは実行層とコンセンサス層で構成されています。しかし、他のほとんどのクライアントとは異なり、Heliosはこれらの2つの層を密接に結合しており、ユーザーは単一のソフトウェアをインストールして実行するだけで済みます。

その動作原理は次のとおりです：Heliosコンセンサス層は、既知の信号チェーンのブロックハッシュを使用し、信頼されていないRPCに接続して、検証可能な方法で現在のブロックに同期します。Helios実行層は、これらの検証された信号チェーンのブロックを信頼されていない実行層RPCと組み合わせて、オンチェーン状態に関するさまざまな情報、たとえばアカウントの残高、契約のストレージ、トランザクションレシート、およびスマートコントラクトの呼び出し結果を検証します。これらのコンポーネントは協力して機能し、ユーザーに完全に信頼不要なRPCを提供し、完全なノードを実行する必要がありません。

コンセンサス層

コンセンサス層ライトクライアントは、ビーコンクレインライトクライアントの仕様に従い、ビーコンクレインの同期委員会（合併前のアルタイルハードフォークで導入）を利用しています。同期委員会は、ランダムに選ばれた512人のバリデーターで構成されるサブセットで、サービス期間は約27時間です。

バリデーターが同期委員会に参加すると、彼らは見たすべてのビーコンサインブロックヘッダーに署名します。委員会のメンバーの三分の二以上がブロックヘッダーに署名した場合、そのブロックは規範ビーコンクリートに存在する可能性が非常に高いです。Heliosが現在の同期委員会の構成を理解している場合、信頼されていないRPCに最近の同期委員会の署名を問い合わせることで、チェーンの先頭を高い確信を持って追跡できます。

BLS署名の集約のおかげで、新しいブロックヘッダーの検証を1回のクエリで完了できます。署名が有効であり、委員会メンバーの3分の2以上が署名を完了していれば、ブロックがチェーンに含まれていることが保証されます（もちろん、それはチェーンから再構成される可能性もありますが、ブロックの最終性を追跡することで、より強力な保証が提供されます）。

しかし、この戦略には明らかに欠けている部分があります：現在の同期委員会をどのように見つけるかです。まず、弱い主観性チェックポイントと呼ばれる信頼の根を取得する必要があります。これは、過去のある時点でブロックチェーンに取り込まれた古いブロックのハッシュを保証できるものです。チェックポイントの正確な存在時間については、いくつかの興味深い数学的計算があります：最悪の場合の分析では約2週間、より現実的な推定では数ヶ月にわたることを示しています。

チェックポイントが古すぎる場合、理論的にはノードを誤ったチェーンに従わせる攻撃が存在します。この時、弱い主観性チェックポイントを取得することはプロトコルの能力の範囲を超えています。Heliosの解決策は、初期チェックポイントを提供し、それをコードベースにハードコーディングすることです（簡単に上書き可能です）。これにより、ノードが同期する際のチェックポイントとして使用するために、ローカルに最新の最終ブロックハッシュを保存します。

ハッシュ操作を通じて、ビーコンクリプトブロックは簡単にユニークなビーコンクリプトハッシュを生成できます。これにより、ノードに完全なビーコンクリプトブロックを照会し、そのハッシュ操作を行い、既知のブロックハッシュと比較することで、ブロック内容の有効性を証明することができます。Heliosはこの特性を利用して、弱い主観的チェックポイントブロック内の特定のフィールドを取得および検証します。その中には、現在の同期委員会と次の同期委員会という2つの重要なフィールドがあります。最も重要なのは、ライトクライアントがこのメカニズムを利用して、ブロックチェーンの履歴を迅速にチェックできることです。

弱い主観性チェックポイントがあれば、現在および次の同期委員会を取得し、検証することができます。現在のチェーンヘッドとチェックポイントが同じ同期委員会周期内にある場合、署名された同期委員会ヘッドを使用して新しいブロックを検証することを直ちに開始できます。チェックポイントがいくつかの同期委員会に遅れている場合、私たちは次のことができます：

1. チェックポイントの後の次の同期委員会を使用して、将来生成される同期委員会のブロックを取得および検証します。

2. この新しいブロックを使用して次の同期委員会を取得します。

3. チェックポイントがまだ後ろにある場合は、ステップ1に戻ります。

このプロセスを通じて、私たちは27時間単位でこのブロックチェーンの履歴を迅速に確認することができ、過去の任意のブロックハッシュから始めて、現在のブロックハッシュまで同期します。

実行レイヤー

実行層ライトクライアントの目標は、合意層で検証された信号ブロックヘッダーと信頼されていない実行層RPCを組み合わせて、検証された実行層データを提供することです。これらのデータは、Heliosを介してローカルホストされたRPCサーバーにアクセスすることができます。

アカウントの残高取得を例に挙げて、イーサリアムがどのように状態を保存するかを簡単に紹介します。各アカウントは、コントラクトコードハッシュ、ランダム数、ストレージハッシュ、残高などのいくつかのフィールドを含んでいます。これらのアカウントは、状態ツリーと呼ばれる修正された大規模なマークル・パトリシアツリーに保存されています。状態ツリーのルートを知っている限り、マークル証明を検証して、ツリー内に任意のアカウントが存在するかどうかを証明することができます。この証明は偽造できません。

Heliosはコンセンサス層から検証済みの状態ルートを取得しました。この状態ルートとメルクル証明要求を信頼されていない実行層RPCに適用することで、Heliosはイーサリアム上に保存されているすべてのデータをローカルで検証できます。

私たちは、実行層で使用されるさまざまなデータを検証するために異なる技術を使用しています。この方法により、信頼されていないRPCからのすべてのデータを検証できます。信頼されていないRPCはデータアクセスの提供を拒否できますが、誤った結果を提供することはできません。

複雑な環境でHeliosを使う

利便性と非中央集権性を両立させることが難しいというのは、一般的な問題です。軽量なHeliosを通じて、ユーザーはあらゆるデバイス（スマートフォンやブラウザプラグインを含む）から安全にオンチェーンデータにアクセスできます。これにより、より多くの人々がハードウェアの制約を受けることなく、信頼なしにイーサリアムデータにアクセスできるようになります。ユーザーは特定のウォレットでHeliosをRPCプロバイダーとして設定し、信頼なしにさまざまなDAppにアクセスすることができ、そのプロセスには他の変更は一切必要ありません。

さらに、RustのWebAssemblyサポートにより、アプリケーション開発者はHeliosをJavaScriptアプリケーション（ウォレットやDAppなど）に簡単に組み込むことができます。これらの統合は、イーサリアムのセキュリティを向上させ、私たちの中央集権的インフラへの依存を減少させます。

コミュニティの反応が待ち遠しいです。Heliosに貢献する方法は多岐にわたり、コードベースに貢献するだけでなく、Heliosの利点を活用するソフトウェアを構築することもできます。以下は、いくつかのエキサイティングなアイデアです：

• P2Pネットワーク（RPCではなく）からライトクライアントデータを直接取得することをサポート
• 一部の未サポートのRPCメソッドを実装する
• WebAssemblyにコンパイル可能なHeliosバージョンの開発
• Heliosをウォレットソフトウェアに直接統合する
• トークン残高を表示するネットワークダッシュボードを構築し、データを取得するためにWebAssemblyを使用したサイトにHeliosを埋め込む
• エンジンAPIをデプロイし、Heliosコンセンサスレイヤーを既存の実行レイヤーのフルノードに接続します