イーサリアムライトクライアントHelios:信頼不要のブロックチェーンアクセスを実現

11月8日、新しいイーサリアムライトクライアントHeliosが登場しました。このRust言語で開発されたクライアントは、完全に信頼を必要としないイーサリアムアクセスを提供することを目的としています。

私たちがブロックチェーンを使用する主な理由の一つは、信頼が不要であることです。ブロックチェーンを通じて、私たちは自分の財産とデータを自主的に管理できます。ほとんどの場合、イーサリアムなどのブロックチェーンはこの約束を実現しています:私たちの資産は本当に私たち自身のものです。

しかし、便利さを追求するために、私たちはいくつかの妥協をしました。その一つが、中央集権型のRPC(リモートコール)サーバーを使用することです。ユーザーは通常、中央集権型プロバイダーを通じてイーサリアムにアクセスします。これらの企業はクラウドサーバー上で高性能ノードを運営し、ユーザーがチェーン上のデータに簡単にアクセスできるように支援します。ウォレットがトークンの残高を照会したり、保留中の取引がブロックに含まれているかどうかを確認したりする際には、ほぼ常にこれらの中央集権型プロバイダーが利用されます。

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

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

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

中心化基盤のリスク: イーサリアム"ダークフォレスト"の理論的産物

理論的な産物が暗い森に潜んでいる。それはイーサリアムの取引メモリプールで獲物を探すのではなく、私たちが依存している中央集権的なインフラを模倣して罠を仕掛ける。罠に落ちたユーザーは何も間違ったことをしていない: 彼らはただよく行く分散型取引所にアクセスし、合理的なスリッページを設定し、いつものようにトークンを売買しただけだ...彼らは何も間違っていなかったが、それでも新しいタイプのサンドイッチ攻撃に遭遇した。これはイーサリアムの暗い森の入口であるRPCプロバイダーに巧妙に仕掛けられた罠だ。

詳細な説明の前に、まず分散型取引所がどのように取引を処理するかを見てみましょう。ユーザーが交換取引を実行する際、スマートコントラクトにいくつかのパラメータを提供します: 交換するトークン、交換額、そして最も重要な、ユーザーが取引を進めるために受け取る必要がある最小トークン数量。この最後のパラメータは、交換が達成すべき「最小出力」を示しており、そうでなければ取引はキャンセルされます。これは通常「スリッページ」と呼ばれ、取引が送信されてメモリプールに入るまでの間に発生する可能性のある最大の価格差を実質的に設定します。スリッページの設定が低すぎると、ユーザーは少ないトークンしか受け取れない可能性があります。この状況はサンドイッチ攻撃を引き起こす可能性もあり、攻撃者はユーザーの入札を二つの悪意のある取引の間に挟むことができます。これらの取引は現物価格を押し上げ、ユーザーにあまり良くない価格で取引を強いることになります。そして、攻撃者はすぐにトークンを売却し、小額の利益を得ます。

この最小出力量パラメータが公正な値付近に設定されていれば、サンドイッチ攻撃を受けることはありません。しかし、あなたのRPCプロバイダーが分散型取引所のスマートコントラクトの正確な価格を提供していない場合はどうなりますか？そうなると、ユーザーは惑わされ、低い最小出力量パラメータで交換取引に署名してしまう可能性があります。さらに悪いことに、ユーザーは悪意のあるRPCプロバイダーに直接取引を送信する可能性もあります。プロバイダーは、この取引を公共メモリプール(にブロードキャストせず、数十のボットがサンドイッチ攻撃)を競い合う中、秘密裏に取引パッケージを保持し、直接あるMEVプラットフォームに送信して利益を得ることができます。

この攻撃の根本的な原因は、他人を信頼してブロックチェーンの状態を取得することです。この問題を解決するために、経験豊富なユーザーは通常、自分のイーサリアムノードを運営します。この作業には大量の時間とリソースが必要で、少なくとも常時オンラインのデバイス、数百GBのストレージスペース、そしてゼロから同期するために約1日の時間が必要です。このプロセスは明らかに過去よりも簡素化されました。一部の団体は、低コストのハードウェアを使ってノードを運営する手助けをするために絶え間ない努力を続けています。たとえば、外部ハードドライブを搭載したラズベリーパイのマイクロコンピュータ(などです。しかし、大幅なコスト削減が求められても、ノードを運営することは多くのユーザーにとって依然として困難であり、特にモバイルデバイスを使用しているユーザーにとってはそうです。

注意すべきは、中央集権的RPCプロバイダーへの攻撃は完全に可能ですが、通常は単純なフィッシング攻撃に過ぎず、私たちが言及しているような攻撃はまだ発生していないということです。大手プロバイダーの過去の実績から彼らを疑う理由はありませんが、馴染みのないRPCプロバイダーをウォレットに追加する前に、もう少し調査を行う価値があります。

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

イーサリアムはライトクライアントプロトコルを導入し、迅速なブロックチェーンインタラクションと最低限のハードウェア要件でRPCエンドポイントを検証するためのエキサイティングな可能性を開きました。The Mergeの後の1ヶ月間に、独立した一連のライトクライアントが次々と現れ、それぞれが異なるアプローチで同じ目標に向かっています: 信頼なしの効率的なアクセスを提供し、フルノードを使用する必要がありません。

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

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

) コンセンサス層

コンセンサス層ライトクライアントは、ビーコンクレインライトクライアントの仕様に準拠しており、Altairハードフォークのマージ前にビーコンクレインの同期委員会###を利用しています(。同期委員会はランダムに選ばれた512人のバリデーターで構成されるサブセットで、サービス期間は約27時間です。

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

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

しかし、この戦略には明らかに欠けている要素があります: 現在の同期委員会をどのように見つけるかです。まず、弱主観性チェックポイント(weak subjectivity checkpoint)と呼ばれる信頼の根を取得する必要があります。名前に驚かないでください、それは単に過去のある時点でチェーンに組み込まれた古いブロックハッシュを保証できることを示しています。チェックポイントの正確な存在時間については、いくつかの興味深い数学的計算があります: 最悪のシナリオ分析では約2週間、より実際的な見積もりでは数ヶ月が示されています。

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

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

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

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

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

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

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

( 実行レイヤー

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

以下にアカウントの残高を取得する簡単な例を示しますが、まずエーテルがどのように状態を保存しているかを簡単に紹介します。各アカウントは、契約コードのハッシュ、ランダム数、ストレージのハッシュ、残高などのいくつかのフィールドを含んでいます。これらのアカウントは、調整された大規模なマークル-パトリシアツリーに保存されており、状態ツリーと呼ばれます。状態ツリーの根を知っていれば、マークル証明を検証してツリーにアカウントが存在するかどうかを証明できます。この証明は偽造できません。

Heliosは、コンセンサス層からの検証済みの状態根)state root###を持っています。信頼できない実行層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コンセンサス層を既存の実行層の全ノードに接続する