ステートレスクライアント:イーサリアムの分散化への道

初級編Dec 25, 2023
この記事では、イーサリアムの分散型ソリューションであるステートレスクライアントを詳細に紹介し、ステートとは何か、その背景、原則、ソリューションについても説明します。
ステートレスクライアント:イーサリアムの分散化への道

イーサリアムの使用量が増えると、フルノードの実行はリソースと帯域幅を大量に消費するようになります。 これにより、フルノードを実行できる人が少なくなり、ネットワークの分散化が軽減されます。 さらに、イーサリアムは取引需要の増加に伴うスケーリングに苦労しており、ネットワークの混雑やガス料金の高騰につながっています。

2017年にヴィタリックが提案したステートレスクライアントは、イーサリアムが直面している分散化の課題の両方に対する潜在的な解決策を提供します。 ステートレスクライアントの背後にある重要な考え方は、フルノードを実行するためのストレージと帯域幅の要件を減らし、より多くの人々がネットワークに参加して分散化できるようにすることです。 このエッセイでは、ステートレスクライアントがどのように機能するか、そしてその潜在的な利点と欠点について詳しく説明します。

イーサリアムの状態とは?

ステートレスクライアントを理解するには、まずイーサリアムの「状態」の概念を理解する必要があります。 イーサリアムの状態とは、イーサリアムの世界におけるすべてのアカウント、コントラクト、残高、ナンス、ストレージの現在の状態を指します。 これは、特定の時点でのイーサリアムネットワークに関するすべての関連情報を保存するデータベースと考えることができます。

この状態は、基本的にキーと値のペアを格納する変更されたマークルツリーであるマークル パトリシア トライで永続化されます。 このトライのルートハッシュは、状態全体を要約します。 新しいブロックごとに、そのブロック内のトランザクションに基づいて状態が更新されます。 新しい状態ルート ハッシュは、ブロック ヘッダーに含まれます。

時間の経過とともにアカウント、コントラクト、トランザクションが追加されるにつれて、イーサリアムの状態はどんどん大きくなっていきます。 現在、州の規模は 1 TB を超え、年間数十ギガバイトずつ増加しています。 この成長状態は、地方分権の問題の根底にあります。

国家の成長が問題を引き起こす理由

イーサリアムの状態サイズの増加は、いくつかの重要な問題を引き起こします。

  • 新しいノードの同期時間が長くなる - すべての履歴状態変更を処理することで、新しいノードが同期されるまでに非常に長い時間がかかります。 これにより、新しいフルノードの実行が困難になり、分散化が妨げられます。 現在、ジェネシスから新しいノードを同期するには、コンシューマー ハードウェアで数日、最大で数週間かかります。 これは、新しいノードを効率的にスピンアップし、より多くの参加者がネットワークに参加できるようにするための大きな障壁となっています。
  • ハードウェア要件の増加 - 状態が大きくなると、格納、アクセス、更新のために、より多くのストレージ、メモリ、処理能力が必要になります。 これにより、リソースが十分にないユーザーがノードを実行できなくなります。 完全に同期されたイーサリアムノードを実行するには、少なくとも1〜2TBの容量を持つSSDが必要になりました。 これは、多くの潜在的なノードオペレーターにとって手の届かないものです。
  • より多くの帯域幅使用量 - 新しいブロックのブロードキャストには、更新された状態も含まれる必要があり、より多くの帯域幅が必要になります。 これにより、ノードオペレーターのコストが増加します。 現在、州はほとんどのブロックブロードキャストを支配しているため、ブロックサイズは増加し続けています。 帯域幅が広くなると、ノードオペレーターのコストが高くなります。
  • ブロック検証が遅くなる - 大きな状態を読み取って更新すると、ブロック検証が遅くなり、トランザクションのスループットが制限されます。 各トランザクションには、残高、ナンス、コントラクト状態などを更新するために、複数のストレージの読み取りと書き込みが必要です。 状態が大きいほど、ブロックあたりの読み取り/書き込みが多くなり、1 秒あたりに処理できるトランザクションの数が減少します。
  • 恒久的なストレージ コスト - データが状態に追加されると、永久に保存する必要があります。 これにより、状態が無制限に成長します。 現在、古い未使用の状態データをアクティブに削除するメカニズムはありません。 そのため、イーサリアムが運用され続ける限り、状態維持コストは無期限に増加します。

ステートレス クライアントの説明

ステートレスクライアントは、イーサリアムの完全な状態にアクセスすることなく、新しいブロックを検証する方法を提供します。 これらは、「証人」と呼ばれる暗号証明を利用して、基礎となる状態データを持たずに、ブロック内の状態変化の有効性を証明します。

ステートレス クライアントの概要は次のとおりです。

  • クライアントは、ブロック ヘッダーと状態ルートのみを格納し、完全な状態データは格納しません。 ブロックヘッダーには、そのブロックが処理された後の状態トライのルートハッシュなどのメタデータが含まれています。
  • 新しいブロックを検証するとき、クライアントはブロックとともに「witness」を受け取ります。 この証人は、トランザクションからの特定の状態更新が有効であることを示す一連のマークル証明です。
  • 証人には、トランザクションの処理に必要な特定の状態値のマークル証明が含まれています。 たとえば、口座残高や契約ストレージの更新などです。
  • クライアントはミラーリング監視サーバーを使用して、トランザクションが最後の既知の状態ルートに対して有効であることを確認します。 証明は、状態の変化が前のルートと一致することを認証します。
  • 有効な場合、クライアントはブロック ヘッダーで指定された新しい状態ルートに更新されます。 この新しい状態ルートは、次のブロックを検証するために使用されます。

完全な状態をローカルに格納する代わりに、ミラーリング監視サーバーを使用して状態を検証することで、ステートレス クライアントにはいくつかの利点があります。

  • 同期時間が非常に速く、状態変更の履歴を再生する必要はありません。 ステートレス クライアントは、ブロック ヘッダーのみでほぼ瞬時に同期できます。
  • ストレージ要件が低い - 状態ルートはわずか 32 バイトです。 数百GBの状態の代わりに、ブロックヘッダーのみが必要です。
  • 帯域幅が少ない - ブロック ヘッダーとミラーリング監視のみが転送され、完全な状態は転送されません。 帯域幅の使用量が最小限に抑えられます。
  • 迅速な検証 - 証人には、関連する状態の小さなサブセットのみが含まれます。 タッチされた更新されたアカウント/ストレージのみが証明されます。
  • 簡単なライトクライアントのサポート - ライトクライアントは簡単に校正を検証できます。 ライトクライアントモデルは、ステートレス検証と非常に互換性があります。

ステートレスクライアントの課題

ステートレス クライアントにはいくつかの大きなメリットがありますが、克服すべき重大な技術的課題もあります。

  • 監視サイズ - 監視が大きすぎて効率的に送信できない可能性があります。 完全なマークルプルーフを使用すると、ブロックサイズの制限を超える可能性があります。
  • 証人の作成 - 最適な証人の生成は、ブロック提案者にとって複雑です。 提案者は、各トランザクションを検証するために、適切な証明フラグメントを組み立てる必要があります。
  • 証人のインセンティブなし - 証人を提供しても、直接的な報酬は得られません。 マイニングとは異なり、証人作成のためのインセンティブ構造は組み込まれていません。
  • 一時データ - 目撃者は、ある時点での状態を証明し、再生が必要です。 証人は、状態が進行するにつれて再利用することはできません。
  • 状態ストレージ - 証人を生成するために、誰かが完全な状態を維持する必要があります。 ステートレス検証は、ステートフルな監視生成に依存します。
  • 複雑なアプリケーション - 一部の契約は、大規模な状態のサブセットに依存し、証人を肥大化させる場合があります。 たとえば、トランザクションごとに多くのストレージ スロットを更新するコントラクトなどです。

考えられる解決策

研究者は、これらの課題に対処するためにさまざまなソリューションを提案しています。

  • Verkle ツリー - witness サイズを縮小するための特別なデータ構造。 Verkle ツリーは、簡潔な暗号化コミットメントを使用して、証明サイズを最小化します。
  • 証人キャッシュ - 提案者は、再利用するために最近の証人を保持できます。 関連性がある可能性が高い証人を再びキャッシュすると、作成コストが償却されます。
  • プロトコルインセンティブ - 有用な証人を提供するための報酬メカニズム。 新しいインセンティブ構造は、証人の作成を補うことができます。
  • 中間状態のルート - 時間の経過とともにルートを追跡して、証明の再生成を回避します。 部分的なルートを維持すると、目撃者のフラグメントが再利用される可能性があります。
  • 州の家賃 - 未使用の状態を剪定し、状態を長期的に維持するために支払いが必要です。 Rent は、プルーフ・サイズを制限するために、古いストレージのクリーンアップを強制します。
  • 分割された監視モデル - 提案者と検証者の間で状態処理を分割します。 いくつかの専用プロポーザーノードにwitnessを生成させます。

これらのアプローチにはトレードオフがあり、最適な実装を見つけるにはさらなる研究が必要です。 幸いなことに、ゼロ知識暗号で起きている急速なイノベーションは、効率的なステートレスクライアントに新たな可能性を開く可能性があります。

潜在的な影響

技術的な障害を克服することができれば、ステートレスクライアントはイーサリアムを大幅に進化させることができます。

  • 同期と検証の高速化により、トランザクションのスループットが向上します。 ステートレス検証により、ブロック処理が大幅に高速化されます。
  • ノードを実行するために必要なリソースが削減され、分散化が向上します。 ラップトップや愛好家は、現実的にフルノードを実行できます。
  • モバイルウォレットなどのライトクライアントのサポートが向上しました。 状態証明は、ライトクライアントモデルと高い互換性があります。
  • シャーディングのスムーズな導入、シャード間のステートレス検証。 シャード間のトランザクションでは、効率的な状態証明を利用できます。
  • 役に立たなくなった古い状態データを削除およびプルーニングする機能。 状態の増加は、無制限ではなく、アクティブに管理できます。
  • ノードオペレーターがニーズに基づいて状態をカスタマイズするための柔軟性が向上しました。 ノードは、ユースケースに合わせて状態保持ポリシーを調整できます。
  • ストレージよりも計算と帯域幅が重要なモデルに移行します。 アーキテクチャは、よりクラウドに適したモデルに移行します。

また、DDoS攻撃に対する脆弱性が高まっていることや、ブロックチェーンの履歴が少数のノードオペレーターによってのみ確実に保存されていることなど、いくつかの潜在的なリスクもあります。 ただし、暗号証明はこれらのリスクを軽減できます。 全体として、ステートレスクライアントは、イーサリアムの現在の制限を克服するための最も有望なアプローチの1つです。

結論

イーサリアムの国家規模の拡大は、採用が進むにつれて分散化の課題を提起しています。 ステートレスクライアントは、ノードが完全なブロックチェーン状態なしでトランザクションを検証できるようにすることで、解決策を提示します。 これにより、最終的には携帯電話でイーサリアムノードを実行できるようになり、分散化が大幅に促進される可能性があります。

免責事項:

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

ステートレスクライアント:イーサリアムの分散化への道

初級編Dec 25, 2023
この記事では、イーサリアムの分散型ソリューションであるステートレスクライアントを詳細に紹介し、ステートとは何か、その背景、原則、ソリューションについても説明します。
ステートレスクライアント:イーサリアムの分散化への道

イーサリアムの使用量が増えると、フルノードの実行はリソースと帯域幅を大量に消費するようになります。 これにより、フルノードを実行できる人が少なくなり、ネットワークの分散化が軽減されます。 さらに、イーサリアムは取引需要の増加に伴うスケーリングに苦労しており、ネットワークの混雑やガス料金の高騰につながっています。

2017年にヴィタリックが提案したステートレスクライアントは、イーサリアムが直面している分散化の課題の両方に対する潜在的な解決策を提供します。 ステートレスクライアントの背後にある重要な考え方は、フルノードを実行するためのストレージと帯域幅の要件を減らし、より多くの人々がネットワークに参加して分散化できるようにすることです。 このエッセイでは、ステートレスクライアントがどのように機能するか、そしてその潜在的な利点と欠点について詳しく説明します。

イーサリアムの状態とは?

ステートレスクライアントを理解するには、まずイーサリアムの「状態」の概念を理解する必要があります。 イーサリアムの状態とは、イーサリアムの世界におけるすべてのアカウント、コントラクト、残高、ナンス、ストレージの現在の状態を指します。 これは、特定の時点でのイーサリアムネットワークに関するすべての関連情報を保存するデータベースと考えることができます。

この状態は、基本的にキーと値のペアを格納する変更されたマークルツリーであるマークル パトリシア トライで永続化されます。 このトライのルートハッシュは、状態全体を要約します。 新しいブロックごとに、そのブロック内のトランザクションに基づいて状態が更新されます。 新しい状態ルート ハッシュは、ブロック ヘッダーに含まれます。

時間の経過とともにアカウント、コントラクト、トランザクションが追加されるにつれて、イーサリアムの状態はどんどん大きくなっていきます。 現在、州の規模は 1 TB を超え、年間数十ギガバイトずつ増加しています。 この成長状態は、地方分権の問題の根底にあります。

国家の成長が問題を引き起こす理由

イーサリアムの状態サイズの増加は、いくつかの重要な問題を引き起こします。

  • 新しいノードの同期時間が長くなる - すべての履歴状態変更を処理することで、新しいノードが同期されるまでに非常に長い時間がかかります。 これにより、新しいフルノードの実行が困難になり、分散化が妨げられます。 現在、ジェネシスから新しいノードを同期するには、コンシューマー ハードウェアで数日、最大で数週間かかります。 これは、新しいノードを効率的にスピンアップし、より多くの参加者がネットワークに参加できるようにするための大きな障壁となっています。
  • ハードウェア要件の増加 - 状態が大きくなると、格納、アクセス、更新のために、より多くのストレージ、メモリ、処理能力が必要になります。 これにより、リソースが十分にないユーザーがノードを実行できなくなります。 完全に同期されたイーサリアムノードを実行するには、少なくとも1〜2TBの容量を持つSSDが必要になりました。 これは、多くの潜在的なノードオペレーターにとって手の届かないものです。
  • より多くの帯域幅使用量 - 新しいブロックのブロードキャストには、更新された状態も含まれる必要があり、より多くの帯域幅が必要になります。 これにより、ノードオペレーターのコストが増加します。 現在、州はほとんどのブロックブロードキャストを支配しているため、ブロックサイズは増加し続けています。 帯域幅が広くなると、ノードオペレーターのコストが高くなります。
  • ブロック検証が遅くなる - 大きな状態を読み取って更新すると、ブロック検証が遅くなり、トランザクションのスループットが制限されます。 各トランザクションには、残高、ナンス、コントラクト状態などを更新するために、複数のストレージの読み取りと書き込みが必要です。 状態が大きいほど、ブロックあたりの読み取り/書き込みが多くなり、1 秒あたりに処理できるトランザクションの数が減少します。
  • 恒久的なストレージ コスト - データが状態に追加されると、永久に保存する必要があります。 これにより、状態が無制限に成長します。 現在、古い未使用の状態データをアクティブに削除するメカニズムはありません。 そのため、イーサリアムが運用され続ける限り、状態維持コストは無期限に増加します。

ステートレス クライアントの説明

ステートレスクライアントは、イーサリアムの完全な状態にアクセスすることなく、新しいブロックを検証する方法を提供します。 これらは、「証人」と呼ばれる暗号証明を利用して、基礎となる状態データを持たずに、ブロック内の状態変化の有効性を証明します。

ステートレス クライアントの概要は次のとおりです。

  • クライアントは、ブロック ヘッダーと状態ルートのみを格納し、完全な状態データは格納しません。 ブロックヘッダーには、そのブロックが処理された後の状態トライのルートハッシュなどのメタデータが含まれています。
  • 新しいブロックを検証するとき、クライアントはブロックとともに「witness」を受け取ります。 この証人は、トランザクションからの特定の状態更新が有効であることを示す一連のマークル証明です。
  • 証人には、トランザクションの処理に必要な特定の状態値のマークル証明が含まれています。 たとえば、口座残高や契約ストレージの更新などです。
  • クライアントはミラーリング監視サーバーを使用して、トランザクションが最後の既知の状態ルートに対して有効であることを確認します。 証明は、状態の変化が前のルートと一致することを認証します。
  • 有効な場合、クライアントはブロック ヘッダーで指定された新しい状態ルートに更新されます。 この新しい状態ルートは、次のブロックを検証するために使用されます。

完全な状態をローカルに格納する代わりに、ミラーリング監視サーバーを使用して状態を検証することで、ステートレス クライアントにはいくつかの利点があります。

  • 同期時間が非常に速く、状態変更の履歴を再生する必要はありません。 ステートレス クライアントは、ブロック ヘッダーのみでほぼ瞬時に同期できます。
  • ストレージ要件が低い - 状態ルートはわずか 32 バイトです。 数百GBの状態の代わりに、ブロックヘッダーのみが必要です。
  • 帯域幅が少ない - ブロック ヘッダーとミラーリング監視のみが転送され、完全な状態は転送されません。 帯域幅の使用量が最小限に抑えられます。
  • 迅速な検証 - 証人には、関連する状態の小さなサブセットのみが含まれます。 タッチされた更新されたアカウント/ストレージのみが証明されます。
  • 簡単なライトクライアントのサポート - ライトクライアントは簡単に校正を検証できます。 ライトクライアントモデルは、ステートレス検証と非常に互換性があります。

ステートレスクライアントの課題

ステートレス クライアントにはいくつかの大きなメリットがありますが、克服すべき重大な技術的課題もあります。

  • 監視サイズ - 監視が大きすぎて効率的に送信できない可能性があります。 完全なマークルプルーフを使用すると、ブロックサイズの制限を超える可能性があります。
  • 証人の作成 - 最適な証人の生成は、ブロック提案者にとって複雑です。 提案者は、各トランザクションを検証するために、適切な証明フラグメントを組み立てる必要があります。
  • 証人のインセンティブなし - 証人を提供しても、直接的な報酬は得られません。 マイニングとは異なり、証人作成のためのインセンティブ構造は組み込まれていません。
  • 一時データ - 目撃者は、ある時点での状態を証明し、再生が必要です。 証人は、状態が進行するにつれて再利用することはできません。
  • 状態ストレージ - 証人を生成するために、誰かが完全な状態を維持する必要があります。 ステートレス検証は、ステートフルな監視生成に依存します。
  • 複雑なアプリケーション - 一部の契約は、大規模な状態のサブセットに依存し、証人を肥大化させる場合があります。 たとえば、トランザクションごとに多くのストレージ スロットを更新するコントラクトなどです。

考えられる解決策

研究者は、これらの課題に対処するためにさまざまなソリューションを提案しています。

  • Verkle ツリー - witness サイズを縮小するための特別なデータ構造。 Verkle ツリーは、簡潔な暗号化コミットメントを使用して、証明サイズを最小化します。
  • 証人キャッシュ - 提案者は、再利用するために最近の証人を保持できます。 関連性がある可能性が高い証人を再びキャッシュすると、作成コストが償却されます。
  • プロトコルインセンティブ - 有用な証人を提供するための報酬メカニズム。 新しいインセンティブ構造は、証人の作成を補うことができます。
  • 中間状態のルート - 時間の経過とともにルートを追跡して、証明の再生成を回避します。 部分的なルートを維持すると、目撃者のフラグメントが再利用される可能性があります。
  • 州の家賃 - 未使用の状態を剪定し、状態を長期的に維持するために支払いが必要です。 Rent は、プルーフ・サイズを制限するために、古いストレージのクリーンアップを強制します。
  • 分割された監視モデル - 提案者と検証者の間で状態処理を分割します。 いくつかの専用プロポーザーノードにwitnessを生成させます。

これらのアプローチにはトレードオフがあり、最適な実装を見つけるにはさらなる研究が必要です。 幸いなことに、ゼロ知識暗号で起きている急速なイノベーションは、効率的なステートレスクライアントに新たな可能性を開く可能性があります。

潜在的な影響

技術的な障害を克服することができれば、ステートレスクライアントはイーサリアムを大幅に進化させることができます。

  • 同期と検証の高速化により、トランザクションのスループットが向上します。 ステートレス検証により、ブロック処理が大幅に高速化されます。
  • ノードを実行するために必要なリソースが削減され、分散化が向上します。 ラップトップや愛好家は、現実的にフルノードを実行できます。
  • モバイルウォレットなどのライトクライアントのサポートが向上しました。 状態証明は、ライトクライアントモデルと高い互換性があります。
  • シャーディングのスムーズな導入、シャード間のステートレス検証。 シャード間のトランザクションでは、効率的な状態証明を利用できます。
  • 役に立たなくなった古い状態データを削除およびプルーニングする機能。 状態の増加は、無制限ではなく、アクティブに管理できます。
  • ノードオペレーターがニーズに基づいて状態をカスタマイズするための柔軟性が向上しました。 ノードは、ユースケースに合わせて状態保持ポリシーを調整できます。
  • ストレージよりも計算と帯域幅が重要なモデルに移行します。 アーキテクチャは、よりクラウドに適したモデルに移行します。

また、DDoS攻撃に対する脆弱性が高まっていることや、ブロックチェーンの履歴が少数のノードオペレーターによってのみ確実に保存されていることなど、いくつかの潜在的なリスクもあります。 ただし、暗号証明はこれらのリスクを軽減できます。 全体として、ステートレスクライアントは、イーサリアムの現在の制限を克服するための最も有望なアプローチの1つです。

結論

イーサリアムの国家規模の拡大は、採用が進むにつれて分散化の課題を提起しています。 ステートレスクライアントは、ノードが完全なブロックチェーン状態なしでトランザクションを検証できるようにすることで、解決策を提示します。 これにより、最終的には携帯電話でイーサリアムノードを実行できるようになり、分散化が大幅に促進される可能性があります。

免責事項:

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