# イーサリアムライトクライアントHelios：信頼不要のアクセスの新しい選択肢11月8日、新しいイーサリアムライトクライアントHeliosが登場しました。このクライアントはRust言語で開発されており、完全に信頼を必要としないイーサリアムアクセスを提供することを目的としています。ブロックチェーンの大きな利点は、信頼を必要としないことです。ブロックチェーン技術を通じて、ユーザーは自分の富とデータを自主的に管理できます。イーサリアムなどのブロックチェーンは、ほとんどの場合、この約束を実現し、ユーザーが本当に自分の資産を所有できるようにしています。しかし、便利さのために、ユーザーはしばしばいくつかの妥協をします。その一つは、中央集権型のRPC（リモートプロシージャコール）サーバーを使用することです。ユーザーは通常、中央集権型のプロバイダーを通じてイーサリアムにアクセスします。これらの会社は、クラウドサーバー上で高性能ノードを運営し、ユーザーが簡単にチェーン上のデータを取得できるようにします。ウォレットがトークンの残高を確認したり、保留中の取引がパッケージ化されたかどうかをチェックしたりする際には、ほぼ常にこれらの中央集権型プロバイダーが利用されます。現在のシステムの問題は、ユーザーがこれらのプロバイダーを信頼する必要があり、クエリ結果が正しいかどうかを検証できないことです。Heliosは、イーサリアムのライトクライアントとして、完全に信頼を必要としないイーサリアムアクセスを提供します。イーサリアムがPoSに移行した後に促進されたライトクライアントプロトコルを利用して、信頼できない中央集権型RPCプロバイダーからのデータを安全に検証可能なローカルRPCに変換します。中央集権型RPCと組み合わせることで、Heliosは完全ノードを実行することなくデータの真実性を検証できます。このクライアントは約2秒で同期を完了し、ストレージを必要とせず、ユーザーは任意のデバイス（モバイルやブラウザプラグインを含む）を通じて安全にチェーン上データにアクセスできます。しかし、中央集権的なインフラに依存することにはどのような潜在的なリスクがあるのでしょうか？この記事では、これらのリスクを整理し、Heliosの設計方案を紹介し、開発者がコードベースに貢献するためのいくつかの考えを提供します。## 中央集権的インフラの潜在的リスク理論的には、ある新しい攻撃がイーサリアムエコシステムに潜んでいる可能性があります。この攻撃は取引メモリプール（Mempool）を直接狙うものではなく、ユーザーが依存する中央集権的なインフラを模倣することで罠を仕掛けます。攻撃を受けたユーザーは何も悪いことをしていません：彼らはいつも通りDEXにアクセスし、妥当なスリッページを設定してトークンを取引しているだけです。しかし、彼らはイーサリアムエコシステムの入口に巧妙に配置された新しいタイプのサンドイッチ攻撃に直面する可能性があります。これはRPCプロバイダーによるものです。この攻撃を理解するためには、まずDEXが取引をどのように処理するかを知る必要があります。ユーザーがトークンを交換する際、スマートコントラクトにいくつかのパラメータを提供します：交換するトークン、交換額、そして最も重要なことに、ユーザーが受け入れる最小トークン数量です。この最後のパラメータは取引の「最小出力」を設定しており、この数値に達しない場合、取引はキャンセルされます。これは通常「スリッページ」と呼ばれ、取引が送信されてからパッケージ化されるまでの間に発生する可能性のある最大価格変動を効果的に制限します。スリッページの設定が低すぎると、ユーザーは少量のトークンしか得られない可能性があります。この状況はサンドイッチ攻撃を引き起こす可能性もあり、攻撃者はユーザーの取引を2つの悪意のある取引の間に挟み込みます。これらの取引は現物価格を押し上げ、ユーザーに不利な価格での取引を強いることになります。その後、攻撃者はすぐにトークンを売却し、小額の利益を得ます。最小出力パラメータが合理的な範囲に設定されていれば、ユーザーはサンドイッチ攻撃を受けることはありません。しかし、RPCプロバイダーがDEXスマートコントラクトの正確な見積もりを提供しない場合、ユーザーは知らず知らずのうちに不利な交換取引に署名してしまう可能性があります。さらに悪いことに、ユーザーは取引を悪意のあるRPCプロバイダーに直接送信してしまうかもしれません。プロバイダーは取引を公共メモリプールにブロードキャストせず、私的に保持し、攻撃される取引パッケージを特定のサービスに直接送信して利益を得ることができます。この攻撃の根本的な原因は、他者を信頼してブロックチェーンの状態を取得することです。この問題を解決するために、経験豊富なユーザーは通常、自分のイーサリアムノードを運営することを選択します。しかし、これは大量の時間とリソースを消費し、少なくとも1台の常時オンラインのデバイス、数百GBのストレージスペース、そして初期同期を完了するために約1日の時間が必要です。一部のチームはこのプロセスを簡素化しようと努めていますが、ほとんどのユーザー、特にモバイルデバイスのユーザーにとってノードを運営することは依然として課題です。注意が必要なのは、中央集権型RPCプロバイダーへの攻撃は理論上完全に可能であるものの、現時点では実際の事例は存在しないということです。大手プロバイダーの過去の実績は信頼できるものですが、馴染みのないRPCプロバイダーをウォレットに追加する前に、十分な調査を行うことが賢明です。## Helios：信頼不要のイーサリアムアクセスソリューションイーサリアムがライトクライアントプロトコルを発表した後、高速なブロックチェーンインタラクションと最低限のハードウェア要件でRPCエンドポイントを検証する新たな可能性が開かれました。The Mergeの後の1ヶ月間に、いくつかの独立したライトクライアントプロジェクトが相次いで登場し、それぞれ異なるアプローチを採用していますが、全てが同じ目的に取り組んでいます。信頼不要の効率的なアクセスを実現し、完全なノードを使用する必要がありません。Heliosはイーサリアムのライトクライアントで、約2秒で同期を完了し、ストレージを必要とせず、完全に信頼を要しないイーサリアムアクセスを提供します。すべてのイーサリアムクライアントと同様に、Heliosは実行層とコンセンサス層で構成されています。しかし、ほとんどの他のクライアントとは異なり、Heliosはこの2つの層を緊密に結合しており、ユーザーは単一のソフトウェアをインストールして実行するだけで済みます。Heliosの動作原理は以下の通りです：コンセンサス層は既知のビーコンサインのブロックハッシュを使用し、信頼されていないRPCに接続して、検証可能な方法で現在のブロックに同期します。実行層は、これらの検証済みのビーコンサインのブロックを信頼されていない実行層RPCと組み合わせて、アカウントの残高、コントラクトのストレージ、トランザクションレシート、スマートコントラクトの呼び出し結果など、オンチェーンの状態に関するさまざまな情報を検証します。これらのコンポーネントは連携して動作し、ユーザーに完全に信頼不要なRPCを提供し、完全なノードを実行する必要がありません。## Heliosの実用化Heliosはライトクライアントとして、ユーザーがどのデバイス（携帯電話やブラウザプラグインを含む）からでも安全にチェーン上のデータにアクセスできるようにします。これにより、より多くの人々がハードウェアの制約を受けることなく、信頼なしでイーサリアムのデータを取得できるようになります。ユーザーはウォレット内でHeliosをRPCプロバイダーとして設定することで、信頼なしでさまざまなDAppにアクセスできるようになり、プロセス全体に他の変更は必要ありません。さらに、RustのWebAssemblyサポートにより、アプリケーション開発者はHeliosをJavascriptアプリケーション（ウォレットやDAppなど）に簡単に組み込むことができます。これらの統合は、イーサリアムのセキュリティを向上させ、中央集権的なインフラへの依存を減らします。コミュニティは、コードベースに貢献するだけでなく、Heliosを統合したソフトウェアを構築することで、さまざまな方法でHeliosに貢献できます。いくつかの有望な方向性には、以下が含まれます：- P2Pネットワークからライトクライアントデータを直接取得することをサポート- 欠落しているRPCメソッドを実装する- WebAssemblyにコンパイル可能なHeliosバージョンの開発- Heliosをウォレットソフトウェアに直接統合する- トークン残高を確認するためのネットワークダッシュボードを構築し、HeliosをWebAssemblyを使用したウェブサイトに組み込みます。- エンジンAPIをデプロイし、Heliosコンセンサス層を既存の実行層のフルノードに接続しますHeliosの登場はイーサリアムエコシステムに新しい可能性をもたらしました。これは、安全性を確保しながら、ユーザーがブロックチェーンデータにアクセスする便利さを向上させることが期待されています。コミュニティの継続的な貢献と改善に伴い、Heliosはイーサリアムのさらなる分散化と普及を促進する重要なツールとなる可能性があります。
Helios：イーサリアムの無信任アクセスの革新ライトクライアント
イーサリアムライトクライアントHelios：信頼不要のアクセスの新しい選択肢
11月8日、新しいイーサリアムライトクライアントHeliosが登場しました。このクライアントはRust言語で開発されており、完全に信頼を必要としないイーサリアムアクセスを提供することを目的としています。
ブロックチェーンの大きな利点は、信頼を必要としないことです。ブロックチェーン技術を通じて、ユーザーは自分の富とデータを自主的に管理できます。イーサリアムなどのブロックチェーンは、ほとんどの場合、この約束を実現し、ユーザーが本当に自分の資産を所有できるようにしています。
しかし、便利さのために、ユーザーはしばしばいくつかの妥協をします。その一つは、中央集権型のRPC（リモートプロシージャコール）サーバーを使用することです。ユーザーは通常、中央集権型のプロバイダーを通じてイーサリアムにアクセスします。これらの会社は、クラウドサーバー上で高性能ノードを運営し、ユーザーが簡単にチェーン上のデータを取得できるようにします。ウォレットがトークンの残高を確認したり、保留中の取引がパッケージ化されたかどうかをチェックしたりする際には、ほぼ常にこれらの中央集権型プロバイダーが利用されます。
現在のシステムの問題は、ユーザーがこれらのプロバイダーを信頼する必要があり、クエリ結果が正しいかどうかを検証できないことです。
Heliosは、イーサリアムのライトクライアントとして、完全に信頼を必要としないイーサリアムアクセスを提供します。イーサリアムがPoSに移行した後に促進されたライトクライアントプロトコルを利用して、信頼できない中央集権型RPCプロバイダーからのデータを安全に検証可能なローカルRPCに変換します。中央集権型RPCと組み合わせることで、Heliosは完全ノードを実行することなくデータの真実性を検証できます。
このクライアントは約2秒で同期を完了し、ストレージを必要とせず、ユーザーは任意のデバイス（モバイルやブラウザプラグインを含む）を通じて安全にチェーン上データにアクセスできます。しかし、中央集権的なインフラに依存することにはどのような潜在的なリスクがあるのでしょうか？この記事では、これらのリスクを整理し、Heliosの設計方案を紹介し、開発者がコードベースに貢献するためのいくつかの考えを提供します。
中央集権的インフラの潜在的リスク
理論的には、ある新しい攻撃がイーサリアムエコシステムに潜んでいる可能性があります。この攻撃は取引メモリプール（Mempool）を直接狙うものではなく、ユーザーが依存する中央集権的なインフラを模倣することで罠を仕掛けます。攻撃を受けたユーザーは何も悪いことをしていません：彼らはいつも通りDEXにアクセスし、妥当なスリッページを設定してトークンを取引しているだけです。しかし、彼らはイーサリアムエコシステムの入口に巧妙に配置された新しいタイプのサンドイッチ攻撃に直面する可能性があります。これはRPCプロバイダーによるものです。
この攻撃を理解するためには、まずDEXが取引をどのように処理するかを知る必要があります。ユーザーがトークンを交換する際、スマートコントラクトにいくつかのパラメータを提供します：交換するトークン、交換額、そして最も重要なことに、ユーザーが受け入れる最小トークン数量です。この最後のパラメータは取引の「最小出力」を設定しており、この数値に達しない場合、取引はキャンセルされます。これは通常「スリッページ」と呼ばれ、取引が送信されてからパッケージ化されるまでの間に発生する可能性のある最大価格変動を効果的に制限します。
スリッページの設定が低すぎると、ユーザーは少量のトークンしか得られない可能性があります。この状況はサンドイッチ攻撃を引き起こす可能性もあり、攻撃者はユーザーの取引を2つの悪意のある取引の間に挟み込みます。これらの取引は現物価格を押し上げ、ユーザーに不利な価格での取引を強いることになります。その後、攻撃者はすぐにトークンを売却し、小額の利益を得ます。
最小出力パラメータが合理的な範囲に設定されていれば、ユーザーはサンドイッチ攻撃を受けることはありません。しかし、RPCプロバイダーがDEXスマートコントラクトの正確な見積もりを提供しない場合、ユーザーは知らず知らずのうちに不利な交換取引に署名してしまう可能性があります。さらに悪いことに、ユーザーは取引を悪意のあるRPCプロバイダーに直接送信してしまうかもしれません。プロバイダーは取引を公共メモリプールにブロードキャストせず、私的に保持し、攻撃される取引パッケージを特定のサービスに直接送信して利益を得ることができます。
この攻撃の根本的な原因は、他者を信頼してブロックチェーンの状態を取得することです。この問題を解決するために、経験豊富なユーザーは通常、自分のイーサリアムノードを運営することを選択します。しかし、これは大量の時間とリソースを消費し、少なくとも1台の常時オンラインのデバイス、数百GBのストレージスペース、そして初期同期を完了するために約1日の時間が必要です。一部のチームはこのプロセスを簡素化しようと努めていますが、ほとんどのユーザー、特にモバイルデバイスのユーザーにとってノードを運営することは依然として課題です。
注意が必要なのは、中央集権型RPCプロバイダーへの攻撃は理論上完全に可能であるものの、現時点では実際の事例は存在しないということです。大手プロバイダーの過去の実績は信頼できるものですが、馴染みのないRPCプロバイダーをウォレットに追加する前に、十分な調査を行うことが賢明です。
Helios：信頼不要のイーサリアムアクセスソリューション
イーサリアムがライトクライアントプロトコルを発表した後、高速なブロックチェーンインタラクションと最低限のハードウェア要件でRPCエンドポイントを検証する新たな可能性が開かれました。The Mergeの後の1ヶ月間に、いくつかの独立したライトクライアントプロジェクトが相次いで登場し、それぞれ異なるアプローチを採用していますが、全てが同じ目的に取り組んでいます。信頼不要の効率的なアクセスを実現し、完全なノードを使用する必要がありません。
Heliosはイーサリアムのライトクライアントで、約2秒で同期を完了し、ストレージを必要とせず、完全に信頼を要しないイーサリアムアクセスを提供します。すべてのイーサリアムクライアントと同様に、Heliosは実行層とコンセンサス層で構成されています。しかし、ほとんどの他のクライアントとは異なり、Heliosはこの2つの層を緊密に結合しており、ユーザーは単一のソフトウェアをインストールして実行するだけで済みます。
Heliosの動作原理は以下の通りです：コンセンサス層は既知のビーコンサインのブロックハッシュを使用し、信頼されていないRPCに接続して、検証可能な方法で現在のブロックに同期します。実行層は、これらの検証済みのビーコンサインのブロックを信頼されていない実行層RPCと組み合わせて、アカウントの残高、コントラクトのストレージ、トランザクションレシート、スマートコントラクトの呼び出し結果など、オンチェーンの状態に関するさまざまな情報を検証します。これらのコンポーネントは連携して動作し、ユーザーに完全に信頼不要なRPCを提供し、完全なノードを実行する必要がありません。
Heliosの実用化
Heliosはライトクライアントとして、ユーザーがどのデバイス（携帯電話やブラウザプラグインを含む）からでも安全にチェーン上のデータにアクセスできるようにします。これにより、より多くの人々がハードウェアの制約を受けることなく、信頼なしでイーサリアムのデータを取得できるようになります。ユーザーはウォレット内でHeliosをRPCプロバイダーとして設定することで、信頼なしでさまざまなDAppにアクセスできるようになり、プロセス全体に他の変更は必要ありません。
さらに、RustのWebAssemblyサポートにより、アプリケーション開発者はHeliosをJavascriptアプリケーション（ウォレットやDAppなど）に簡単に組み込むことができます。これらの統合は、イーサリアムのセキュリティを向上させ、中央集権的なインフラへの依存を減らします。
コミュニティは、コードベースに貢献するだけでなく、Heliosを統合したソフトウェアを構築することで、さまざまな方法でHeliosに貢献できます。いくつかの有望な方向性には、以下が含まれます：
Heliosの登場はイーサリアムエコシステムに新しい可能性をもたらしました。これは、安全性を確保しながら、ユーザーがブロックチェーンデータにアクセスする便利さを向上させることが期待されています。コミュニティの継続的な貢献と改善に伴い、Heliosはイーサリアムのさらなる分散化と普及を促進する重要なツールとなる可能性があります。