# イーサリアムライトクライアントHelios：信頼不要のブロックチェーンアクセスを実現11月8日、新しいイーサリアムライトクライアントHeliosが正式にリリースされました。このクライアントはRust言語を基に開発されており、完全に信頼不要のイーサリアムアクセスを提供することを目的としています。ブロックチェーンの主な目的の一つは、信頼不要を実現することです。ブロックチェーンを通じて、私たちは自分の財産やデータを自主的に管理することができます。多くの場合、イーサリアムなどのブロックチェーンはこの約束を実現しています: 私たちの資産は本当に私たち自身のものです。しかし、便利さを追求するために、いくつかの妥協をしました。その一つは、中央集権的なRPC(リモートコール)サーバーを使用することです。ユーザーは通常、中央集権的なプロバイダーを通じてイーサリアムにアクセスします。これらの企業はクラウドサーバー上で高性能ノードを運営し、誰もが簡単にチェーン上のデータを取得できるように支援しています。ウォレットがトークン残高を照会したり、取引状況を確認したりする際には、ほぼ常にこれらの中央集権的なプロバイダーが利用されます。現在のシステムの問題は、ユーザーがこれらのプロバイダーを信頼する必要があり、クエリ結果が正しいかどうかを検証できないことです。HeliosはRustに基づくイーサリアムのライトクライアントで、完全に信頼不要なイーサリアムアクセスを提供します。イーサリアムがPoSに移行した後に実現されたライトクライアントプロトコルを利用し、信頼できない中央集権型RPCプロバイダからのデータを安全に検証可能なローカルRPCに変換します。中央集権型RPCと組み合わせることで、Heliosはフルノードを運用することなくデータの真実性を検証できます。このクライアントは約2秒で同期を完了し、ストレージを必要とせず、ユーザーはどのデバイス(を通じて安全にオンチェーンデータにアクセスできます。携帯電話やブラウザプラグイン)を含みます。しかし、中央集権的なインフラに依存することにはどのような潜在的なリスクがあるのでしょうか？次に、これらのリスクを分析し、Heliosの設計案を紹介し、コードベースを向上させるためのいくつかのアイデアを提供します。## 中央集権的インフラの潜在的リスク理論的な攻撃手法がイーサリアムの「ダークフォレスト」に潜んでいます。それは取引メモリプール内でターゲットを探すのではなく、私たちが依存している中央集権的インフラを模倣することによって罠を設定します。ユーザーは間違いを犯さなくても罠にかかる可能性があります: 彼らはただ通常通りDEXで取引を行い、合理的なスリッページを設定しただけですが......それでもRPCプロバイダーで巧妙に設定された新型のサンドイッチ攻撃に遭遇する可能性があります。分散型取引所で取引を処理する際、ユーザーはスマートコントラクトにいくつかのパラメーターを提供する必要があります: 交換するトークン、交換金額、そして最も重要な、ユーザーが受け入れる最小トークン数量。最後のパラメーターは、交換が達成すべき「最小出力」を示しており、そうでなければ取引はキャンセルされます。これは通常「スリッページ」と呼ばれ、取引送信から取引がブロックチェーンに追加されるまでの間に発生する可能性のある最大価格差を効果的に設定します。スリッページの設定が低すぎると、ユーザーは少ないトークンしか得られず、サンドイッチ攻撃を受ける可能性もあります。最小出力パラメータが合理的な範囲内に設定されていれば、サンドイッチ攻撃の影響を受けることはありません。しかし、RPCプロバイダーがDEXスマートコントラクトの正確な見積もりを提供しない場合はどうでしょうか？これにより、ユーザーが誤解され、低い最小出力パラメータで交換取引に署名する可能性があります。さらに悪いことに、ユーザーは悪意のあるRPCプロバイダーに直接取引を送信することもあります。プロバイダーは取引を公共メモリプールにブロードキャストせず、私的に保持し、攻撃される取引パッケージを特定の機関に直接送信して利益を得ることができます。この攻撃の根本原因は、他者を信頼してブロックチェーンの状態を取得することです。この問題を解決するために、経験豊富なユーザーは通常、自分のイーサリアムノードを運営しますが、これは大量の時間とリソースを必要とし、少なくとも常にオンラインのデバイス、数百GBのストレージスペース、そして最初から同期するのに約1日を必要とします。現在、ノードを運営するためのハードルは低くなっていますが、特にモバイルデバイスを使用しているユーザーにとっては、依然として困難です。注意が必要なのは、中央集権的なRPCプロバイダーに対する攻撃は完全に発生する可能性がありますが、通常は単純なフィッシング攻撃であり、私たちが説明したような攻撃はまだ発生していません。主流のプロバイダーの過去の記録は信頼できますが、馴染みのないRPCプロバイダーを使用する前に、もう少し調査を行うことは賢明な選択です。## Helios:信頼不要のエーテルアクセスを実現イーサリアムはライトクライアントプロトコルを導入し、高速なブロックチェーンインタラクションと最低限のハードウェア要件でRPCエンドポイントを検証する新たな可能性を切り開きました。The Mergeの1ヶ月後には、複数の独立したライトクライアントが相次いで登場し、それぞれ異なるアプローチを採用していますが、目標は一致しています: 完全なノードを運用せずに効率的な無信頼アクセスを実現することです。Heliosは、約2秒で同期を完了し、ストレージを必要とせず、完全に信頼を必要としないイーサリアムアクセスを提供するイーサリアムのライトクライアントです。すべてのイーサリアムクライアントと同様に、Heliosは実行層とコンセンサス層を含んでいます。しかし、ほとんどのクライアントとは異なり、Heliosはこの2つの層を密接に結合しており、ユーザーは単一のソフトウェアをインストールして実行するだけで済みます。Heliosの動作原理は以下の通りです: コンセンサス層は既知の信号チェーンのブロックハッシュを使用し、不信頼のRPCに接続して、検証可能な方法で現在のブロックに同期します。実行層はこれらの検証された信号チェーンのブロックを不信頼の実行層RPCと組み合わせて、アカウント残高、コントラクトストレージ、取引レシート、スマートコントラクトの呼び出し結果など、チェーン上の状態に関するさまざまな情報を検証します。これらのコンポーネントは協力して動作し、ユーザーに完全に信頼不要なRPCを提供し、完全なノードを運用する必要はありません。### コンセンサス層コンセンサス層ライトクライアントは、ビーコンサインのライトクライアント仕様に従い、ビーコンサインの同期委員会を利用しています。同期委員会はランダムに選ばれた512人のバリデーターで構成されるサブセットで、サービス周期は約27時間です。検証者が同期委員会に参加した後、見えるすべてのビーコンサインブロックヘッダーに署名します。委員会メンバーの2/3以上がブロックヘッダーに署名した場合、そのブロックは規範ビーコントレインに存在する可能性が非常に高いです。Heliosが現在の同期委員会の構成を理解している場合、最近の同期委員会の署名を照会することで、チェーンヘッドを信頼性高く追跡できます。BLS署名の集約のおかげで、新しいブロックヘッダーの検証を1回のクエリで完了できます。署名が有効であり、2/3以上の委員会メンバーが署名を完了すれば、ブロックがチェーンに含まれていることが保証されます。もちろん、ブロックの最終性を追跡することで、より強い保証が提供されます。この戦略では、現在の同期委員会を見つける方法についても解決する必要があります。まず、弱い主観性チェックポイントと呼ばれる信頼のルートを取得する必要があります。これは、過去のある時点でチェーンに取り込まれた古いブロックハッシュを保証できることを示します。チェックポイントの存在時間については、理論的な分析では最悪の場合約2週間、実際の推定では数ヶ月に達する可能性があります。チェックポイントが古すぎる場合、理論的にはノードを誤ったチェーンに従わせる攻撃が存在します。この時、弱い主観性チェックポイントを取得することはプロトコルの能力の範囲を超えています。Heliosの解決策は、初期チェックポイントを提供し、それをコードベースにハードコーディングすることです(は簡単に上書きされます)、ローカルに最新の最終ブロックハッシュを保存し、ノードが同期する際にチェックポイントとして使用できるようにします。ハッシュ操作を通じて、信号チェーンのブロックは簡単にユニークな信号ブロックハッシュを生成できます。これにより、完全な信号ブロックを簡単に照会し、ハッシュ比較を通じてブロック内容の有効性を証明できます。Heliosはこの特性を利用して、弱い主観性チェックポイントブロック内の重要なフィールド、現在の同期委員会および次の同期委員会を取得および検証します。最も重要なのは、ライトクライアントがこのメカニズムを利用してブロックチェーンの履歴を迅速に確認できることです。弱い主観性チェックポイントがあれば、現在および次の同期委員会を取得して検証できます。現在のチェーンヘッドとチェックポイントが同じ同期委員会サイクル内にある場合、署名された同期委員会ヘッダーを使用して新しいブロックを即座に検証できます。チェックポイントがいくつかの同期委員会の後にある場合、次のことができます: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をウォレットソフトウェアに直接統合する- ネットワークダッシュボードを構築してトークン残高を確認し、HeliosをWebAssemblyを使用したウェブサイトに組み込んでデータを取得する- エンジンAPIを展開し、Heliosコンセンサス層を既存の実行層のフルノードに接続します。
Heliosライトクライアント: 実現全無信任のイーサリアムオンチェーンデータアクセス
イーサリアムライトクライアントHelios：信頼不要のブロックチェーンアクセスを実現
11月8日、新しいイーサリアムライトクライアントHeliosが正式にリリースされました。このクライアントはRust言語を基に開発されており、完全に信頼不要のイーサリアムアクセスを提供することを目的としています。
ブロックチェーンの主な目的の一つは、信頼不要を実現することです。ブロックチェーンを通じて、私たちは自分の財産やデータを自主的に管理することができます。多くの場合、イーサリアムなどのブロックチェーンはこの約束を実現しています: 私たちの資産は本当に私たち自身のものです。
しかし、便利さを追求するために、いくつかの妥協をしました。その一つは、中央集権的なRPC(リモートコール)サーバーを使用することです。ユーザーは通常、中央集権的なプロバイダーを通じてイーサリアムにアクセスします。これらの企業はクラウドサーバー上で高性能ノードを運営し、誰もが簡単にチェーン上のデータを取得できるように支援しています。ウォレットがトークン残高を照会したり、取引状況を確認したりする際には、ほぼ常にこれらの中央集権的なプロバイダーが利用されます。
現在のシステムの問題は、ユーザーがこれらのプロバイダーを信頼する必要があり、クエリ結果が正しいかどうかを検証できないことです。
HeliosはRustに基づくイーサリアムのライトクライアントで、完全に信頼不要なイーサリアムアクセスを提供します。イーサリアムがPoSに移行した後に実現されたライトクライアントプロトコルを利用し、信頼できない中央集権型RPCプロバイダからのデータを安全に検証可能なローカルRPCに変換します。中央集権型RPCと組み合わせることで、Heliosはフルノードを運用することなくデータの真実性を検証できます。
このクライアントは約2秒で同期を完了し、ストレージを必要とせず、ユーザーはどのデバイス(を通じて安全にオンチェーンデータにアクセスできます。携帯電話やブラウザプラグイン)を含みます。しかし、中央集権的なインフラに依存することにはどのような潜在的なリスクがあるのでしょうか？次に、これらのリスクを分析し、Heliosの設計案を紹介し、コードベースを向上させるためのいくつかのアイデアを提供します。
中央集権的インフラの潜在的リスク
理論的な攻撃手法がイーサリアムの「ダークフォレスト」に潜んでいます。それは取引メモリプール内でターゲットを探すのではなく、私たちが依存している中央集権的インフラを模倣することによって罠を設定します。ユーザーは間違いを犯さなくても罠にかかる可能性があります: 彼らはただ通常通りDEXで取引を行い、合理的なスリッページを設定しただけですが......それでもRPCプロバイダーで巧妙に設定された新型のサンドイッチ攻撃に遭遇する可能性があります。
分散型取引所で取引を処理する際、ユーザーはスマートコントラクトにいくつかのパラメーターを提供する必要があります: 交換するトークン、交換金額、そして最も重要な、ユーザーが受け入れる最小トークン数量。最後のパラメーターは、交換が達成すべき「最小出力」を示しており、そうでなければ取引はキャンセルされます。これは通常「スリッページ」と呼ばれ、取引送信から取引がブロックチェーンに追加されるまでの間に発生する可能性のある最大価格差を効果的に設定します。スリッページの設定が低すぎると、ユーザーは少ないトークンしか得られず、サンドイッチ攻撃を受ける可能性もあります。
最小出力パラメータが合理的な範囲内に設定されていれば、サンドイッチ攻撃の影響を受けることはありません。しかし、RPCプロバイダーがDEXスマートコントラクトの正確な見積もりを提供しない場合はどうでしょうか？これにより、ユーザーが誤解され、低い最小出力パラメータで交換取引に署名する可能性があります。さらに悪いことに、ユーザーは悪意のあるRPCプロバイダーに直接取引を送信することもあります。プロバイダーは取引を公共メモリプールにブロードキャストせず、私的に保持し、攻撃される取引パッケージを特定の機関に直接送信して利益を得ることができます。
この攻撃の根本原因は、他者を信頼してブロックチェーンの状態を取得することです。この問題を解決するために、経験豊富なユーザーは通常、自分のイーサリアムノードを運営しますが、これは大量の時間とリソースを必要とし、少なくとも常にオンラインのデバイス、数百GBのストレージスペース、そして最初から同期するのに約1日を必要とします。現在、ノードを運営するためのハードルは低くなっていますが、特にモバイルデバイスを使用しているユーザーにとっては、依然として困難です。
注意が必要なのは、中央集権的なRPCプロバイダーに対する攻撃は完全に発生する可能性がありますが、通常は単純なフィッシング攻撃であり、私たちが説明したような攻撃はまだ発生していません。主流のプロバイダーの過去の記録は信頼できますが、馴染みのないRPCプロバイダーを使用する前に、もう少し調査を行うことは賢明な選択です。
Helios:信頼不要のエーテルアクセスを実現
イーサリアムはライトクライアントプロトコルを導入し、高速なブロックチェーンインタラクションと最低限のハードウェア要件でRPCエンドポイントを検証する新たな可能性を切り開きました。The Mergeの1ヶ月後には、複数の独立したライトクライアントが相次いで登場し、それぞれ異なるアプローチを採用していますが、目標は一致しています: 完全なノードを運用せずに効率的な無信頼アクセスを実現することです。
Heliosは、約2秒で同期を完了し、ストレージを必要とせず、完全に信頼を必要としないイーサリアムアクセスを提供するイーサリアムのライトクライアントです。すべてのイーサリアムクライアントと同様に、Heliosは実行層とコンセンサス層を含んでいます。しかし、ほとんどのクライアントとは異なり、Heliosはこの2つの層を密接に結合しており、ユーザーは単一のソフトウェアをインストールして実行するだけで済みます。
Heliosの動作原理は以下の通りです: コンセンサス層は既知の信号チェーンのブロックハッシュを使用し、不信頼のRPCに接続して、検証可能な方法で現在のブロックに同期します。実行層はこれらの検証された信号チェーンのブロックを不信頼の実行層RPCと組み合わせて、アカウント残高、コントラクトストレージ、取引レシート、スマートコントラクトの呼び出し結果など、チェーン上の状態に関するさまざまな情報を検証します。これらのコンポーネントは協力して動作し、ユーザーに完全に信頼不要なRPCを提供し、完全なノードを運用する必要はありません。
コンセンサス層
コンセンサス層ライトクライアントは、ビーコンサインのライトクライアント仕様に従い、ビーコンサインの同期委員会を利用しています。同期委員会はランダムに選ばれた512人のバリデーターで構成されるサブセットで、サービス周期は約27時間です。
検証者が同期委員会に参加した後、見えるすべてのビーコンサインブロックヘッダーに署名します。委員会メンバーの2/3以上がブロックヘッダーに署名した場合、そのブロックは規範ビーコントレインに存在する可能性が非常に高いです。Heliosが現在の同期委員会の構成を理解している場合、最近の同期委員会の署名を照会することで、チェーンヘッドを信頼性高く追跡できます。
BLS署名の集約のおかげで、新しいブロックヘッダーの検証を1回のクエリで完了できます。署名が有効であり、2/3以上の委員会メンバーが署名を完了すれば、ブロックがチェーンに含まれていることが保証されます。もちろん、ブロックの最終性を追跡することで、より強い保証が提供されます。
この戦略では、現在の同期委員会を見つける方法についても解決する必要があります。まず、弱い主観性チェックポイントと呼ばれる信頼のルートを取得する必要があります。これは、過去のある時点でチェーンに取り込まれた古いブロックハッシュを保証できることを示します。チェックポイントの存在時間については、理論的な分析では最悪の場合約2週間、実際の推定では数ヶ月に達する可能性があります。
チェックポイントが古すぎる場合、理論的にはノードを誤ったチェーンに従わせる攻撃が存在します。この時、弱い主観性チェックポイントを取得することはプロトコルの能力の範囲を超えています。Heliosの解決策は、初期チェックポイントを提供し、それをコードベースにハードコーディングすることです(は簡単に上書きされます)、ローカルに最新の最終ブロックハッシュを保存し、ノードが同期する際にチェックポイントとして使用できるようにします。
ハッシュ操作を通じて、信号チェーンのブロックは簡単にユニークな信号ブロックハッシュを生成できます。これにより、完全な信号ブロックを簡単に照会し、ハッシュ比較を通じてブロック内容の有効性を証明できます。Heliosはこの特性を利用して、弱い主観性チェックポイントブロック内の重要なフィールド、現在の同期委員会および次の同期委員会を取得および検証します。最も重要なのは、ライトクライアントがこのメカニズムを利用してブロックチェーンの履歴を迅速に確認できることです。
弱い主観性チェックポイントがあれば、現在および次の同期委員会を取得して検証できます。現在のチェーンヘッドとチェックポイントが同じ同期委員会サイクル内にある場合、署名された同期委員会ヘッダーを使用して新しいブロックを即座に検証できます。チェックポイントがいくつかの同期委員会の後にある場合、次のことができます:
チェックポイントの後の次の同期委員会を使用して、将来生成される同期委員会のブロックを取得し、検証します。
この新しいブロックを使用して次の同期委員会を取得します。
チェックポイントがまだ後ろにある場合は、ステップ1に戻ります。
上記のプロセスを通じて、私たちは27時間単位でこのブロックチェーンの履歴を迅速にレビューすることができ、過去の任意のブロックハッシュから現在のブロックハッシュまで同期できます。
実行レイヤー
実行層ライトクライアントの目標は、コンセンサス層で検証された信号ブロックヘッダーと信頼されていない実行層RPCを組み合わせて、検証された実行層データを提供することです。このデータは、Heliosを介してローカルホストされたRPCサーバーにアクセスすることができます。
以下はアカウント残高を取得するための簡単な例であり、まずイーサリアムがどのように状態を保存するかを簡単に紹介します。各アカウントには、契約コードのハッシュ、ランダム数、ストレージのハッシュ、および残高など、いくつかのフィールドが含まれています。これらのアカウントは、状態ツリーと呼ばれる調整された大規模なメルクル・パトリシャツリーに格納されています。状態ツリーのルートを知っている限り、メルクル証明を検証してツリー内に任意のアカウントが存在するかどうかを証明することができます。この証明は偽造できません。
Heliosはコンセンサス層から検証済みのステートルートを取得します。信頼できない実行層RPCにこのステートルートとマークル証明リクエストを適用することにより、Heliosはローカルでイーサリアムに保存されているすべてのデータを検証できます。
私たちは、実行レイヤーで使用されるさまざまなデータを検証するために異なる技術を使用し、信頼できないRPCからのすべてのデータを検証できるようにします。信頼できないRPCはデータアクセスを提供することを拒否できますが、誤った結果を提供することはできません。
Heliosのアプリケーションの展望
利便性と非中央集権性を両立させることが難しいというのは一般的な悩みです。軽量なHeliosを通じて、ユーザーはスマートフォンやブラウザプラグイン(を含む任意のデバイス)から安全なチェーン上のデータにアクセスできます。これにより、どのようなハードウェアを使用しても、より多くの人々が信頼なしにイーサリアムのデータにアクセスできるようになります。ユーザーはウォレットの中でHeliosをRPCプロバイダーとして使用し、信頼なしにさまざまなDAppにアクセスできるようにします。このプロセスには、他の変更は一切必要ありません。
さらに、RustのWebAssemblyサポートにより、アプリケーション開発者はHeliosをJavascriptアプリケーション(、例えばウォレットやDApp)に簡単に組み込むことができます。これらの統合は、イーサリアムのセキュリティを向上させ、中央集権的なインフラストラクチャへの信頼ニーズを減少させます。
コミュニティは、Heliosに貢献するためのさまざまな方法を持っており、コードベースを改善するだけでなく、Heliosの利点を活用するソフトウェアを構築することもできます。以下は、いくつかの潜在的な開発方向です: