著者: YQ、AltLayer 創設者、翻訳: Golden Finance cryptonaitiveイーサリアムの使用量が増加するにつれて、フルノードを実行すると、より多くのリソースと帯域幅が要求されます。その結果、フルノードを実行できる人がますます少なくなり、ネットワークの分散化が低下します。さらに、イーサリアムはトランザクション需要の増加に伴い拡張が難しくなり、ネットワークの混雑やガス料金の高騰につながります。2017 年に Vitalik によって提案されたステートレス クライアントは、イーサリアムが直面している分散化の課題に対する潜在的な解決策を提供します。ステートレス クライアントの重要なアイデアは、フル ノードの実行に必要なストレージと帯域幅の要件を軽減し、より多くの人が参加できるようにし、ネットワークを分散化することです。この記事では、ステートレス クライアントの仕組みと、その潜在的な利点と欠点について詳しく説明します。## イーサリアムの状態とは何ですか?ステートレスクライアントを理解するには、まずイーサリアムにおける「ステート」の概念を理解する必要があります。イーサリアムの状態とは、イーサリアム世界のすべてのアカウント、契約、残高、ノンス、ストレージの現在の状態を指します。これは、特定の時点でのイーサリアム ネットワークに関するすべての関連情報を保存するデータベースと考えることができます。状態はマークル パトリシア トライの形式で保持されます。これは本質的に、キーと値のペアを格納するために使用される変更されたマークル ツリーです。トライのルート ハッシュは状態全体を要約します。新しいブロックごとに、そのブロック内のトランザクションに基づいてステータスが更新されます。新しい状態のルート ハッシュはブロック ヘッダーに含まれます。時間の経過とともに、より多くのアカウント、契約、トランザクションが追加されるにつれて、イーサリアムの状態はますます大きくなっていきました。現在、州のサイズは 1 TB を超え、毎年数十 GB が追加されています。この拡大状態が地方分権問題の根本原因である。## 状態の成長が問題を引き起こす理由イーサリアムの状態サイズの増加により、いくつかの重要な問題が発生しています。● 新しいノードの同期時間が長い - 新しいノードがすべての履歴ステータス変更を同期するには長い時間がかかります。これにより、新しいフルノードの実行が難しくなり、分散化が妨げられます。新しいノードをジェネシスブロックから最新の状態に同期するには、現在、何日も、あるいは何週間もかかります。これは、消費者向けハードウェアにとって、新しいノードを効果的に起動し、より多くの参加者がネットワークに参加できるようにするための大きな障害となっています。● ハードウェア要件の増加 – 状態が大きくなると、保存、アクセス、更新のためにより多くのストレージ、メモリ、および処理能力が必要になります。これにより、リソースが少ないユーザーはノードを実行できなくなります。完全に同期された Ethereum ノードを実行するには、少なくとも 1 ~ 2TB の容量を持つ SSD が必要になります。これは、多くの潜在的なノード オペレーターにとって手の届かないものです。● 帯域幅の使用量の増加 – 新しいブロックのブロードキャストには更新された状態も含める必要があり、より多くの帯域幅が必要になります。これにより、ノード運営者のコストが増加します。現在、ほとんどのブロック ブロードキャストは状態によって支配されているため、ブロック サイズは増大し続けています。帯域幅が増えると、ノード オペレーターのコストが高くなります。● ブロック検証の遅延 – より大きな状態の読み取りと更新により、ブロック検証が遅くなり、トランザクションのスループットが制限されます。各トランザクションでは、残高、ノンス、契約ステータスなどを更新するために、ストレージへの複数回の読み取りと書き込みが必要です。状態が大きくなると、ブロックあたりの読み取り/書き込みが増加し、1 秒あたりに処理できるトランザクションの数が減少します。● 永続的ストレージのコスト – データを状態に追加したら、永続的に保存する必要があります。これにより、無制限の状態が拡大します。現在、古い未使用の状態データを積極的に削除するメカニズムはありません。したがって、イーサリアムが運営され続ける限り、状態維持コストは無限に増加します。## ステートレス クライアントとは何ですか?ステートレス クライアントは、完全な Ethereum 状態にアクセスする必要なく、新しいブロックを検証する方法を提供します。彼らは、「証人」と呼ばれる暗号証明を利用して、特定の状態データを必要とせずにブロック内の状態変化の正当性を証明します。ステートレス クライアントは次のように動作します。1. クライアントは、完全な状態データではなく、ブロック ヘッダーと状態ルートのみを保存します。ブロック ヘッダーには、ブロックの処理後の状態トライのルート ハッシュなどのメタデータが含まれます。2. 新しいブロックを検証するとき、クライアントはブロックと一緒に「証人」を受け取ります。この証人は、トランザクション内の特定の状態更新が有効であることを証明する一連のマークル証明です。3. 証人には、トランザクションの処理に使用される特定の状態値のマークル証明が含まれています。たとえば、アカウント残高や契約ストレージの更新などです。4. クライアントは、監視を使用して、トランザクション ペアの最後の既知の状態ルートの有効性を確認します。この証明により、状態の変化が以前のルートと一致することが検証されます。5. 有効な場合、クライアントはブロック ヘッダーで指定された新しい状態ルートに更新します。この新しい状態ルートは、次のブロックを検証するために使用されます。完全な状態をローカルに保存するのではなく、監視を使用して状態を検証することにより、ステートレス クライアントにはいくつかの利点が得られます。● 非常に速い同期時間 - 履歴状態の変更を完全に同期する必要はありません。ステートレス クライアントは、ブロック ヘッダーのみを必要として、ほぼ瞬時に同期できます。● 低いストレージ要件 - ステートルートはわずか 32 バイトです。数百ギガバイトの状態の代わりに、ブロック ヘッダーのみが必要になります。● 帯域幅の使用量が少なくなります - 完全な状態ではなく、ブロック ヘッダーと監視のみが送信されます。帯域幅の使用量は最小限に抑えられます。● 迅速な検証 - 証人には関連する州の小さなサブセットのみが含まれます。更新されたアカウント/ストアのみが有用であることが証明されています。● ライト クライアントを簡単にサポート – ライト クライアントはプルーフを簡単に検証できます。ライト クライアント モデルはステートレス検証と非常に互換性があります。## ステートレス クライアントの課題ステートレス クライアントにはいくつかの大きな利点がありますが、いくつかの重大な技術的課題もあります。● 証人のサイズ - 証人が大きすぎて効率的に送信できない場合があります。完全なマークル証明が使用される場合、ブロック サイズの制限を超える可能性があります。● 証人の作成 - ブロックの提案者にとって、最適な証人の生成は複雑です。提案者は、各トランザクションを検証するために正しい証拠を組み立てる必要があります。● 証人へのインセンティブなし – 証人を提供することに対する直接的な報酬はありません。マイニングとは異なり、証人の作成に対する組み込みのインセンティブはありません。● 一時データ - 証人は特定の時点でのステータスを証明するため、再生成する必要があります。状態の発展中に証人を再利用することはできません。● 状態ストレージ – 証人を生成するには、誰かが完全な状態を維持する必要があります。ステートレス検証はステートフル監視生成に依存します。● 複雑なアプリケーション - 一部の契約は州のより大きなサブセットに依存する場合があり、証人が肥大化します。たとえば、トランザクションごとに多くのストレージ スロットを更新するコントラクトなどです。## 可能な解決策研究者は、これらの課題に対処するためにさまざまなソリューションを提案しています。● Verkle ツリー – 監視のサイズを削減するために使用される特別なデータ構造。 Verkle ツリーは、証明サイズを最小限に抑えるために、簡潔な暗号化コミットメントを使用します。● 証人キャッシュ - 提案者は、再利用できるように最近の証人を維持できます。キャッシュは、作成コストが償却できることを証明する上で再び役立つ可能性があります。● プロトコルのインセンティブ - 有用な証人に報酬メカニズムを提供します。新しいインセンティブ構造により、証人の作成を補うことができます。● 中間状態のルート – プルーフの再生成を避けるために、時間をかけてルートを追跡します。ルートの一部を維持すると、証人フラグメントの再利用が可能になります。● コンディションレント – 長期にわたってコンディションを維持し、未使用の状態を剪定するために支払いが必要です。 Rent は、プルーフ サイズを制限するために、古いストレージのクリーンアップを強制します。● 分割された監視モデル – 提案者と検証者間の分割状態処理。多数の専用プロポーザー ノードが証人を生成します。これらのアプローチの間にはトレードオフがあり、最適な実装を見つけるにはさらなる研究が必要です。幸いなことに、ゼロ知識暗号化の急速な革新により、効率的なステートレス クライアントに新たな可能性がもたらされる可能性があります。## 潜在的な影響技術的な障害を克服できれば、ステートレス クライアントはイーサリアムの成長を大幅に押し上げる可能性があります。● より高速な同期と検証により、より高いトランザクション スループットをサポートします。ステートレス検証により、ブロック処理が大幅に高速化されます。● ノードの実行に必要なリソースを削減し、分散化を改善します。ラップトップや愛好家は、現実的にフルノードを実行する可能性があります。● モバイル ウォレットなどのライト クライアントのサポートが向上しました。 Proof of State は、ライト クライアント モデルと高い互換性があります。● シャーディングをよりスムーズに導入し、シャード間のステートレス検証を実行します。クロスシャードトランザクションは、効率的な状態証明を利用できます。● 役に立たなくなった古い状態データを削除および整理する機能。状態の成長は、無制限に成長するのではなく、積極的に管理できます。● ノードオペレーターがニーズに応じてステータスをより柔軟にカスタマイズできる機能。ノードは、ユースケースに基づいて状態保持ポリシーをカスタマイズできます。● ストレージよりもコンピューティングと帯域幅が重要なモデルへの移行。よりクラウドに適したモデルに向けてアーキテクチャが変更されます。また、DDoS 攻撃に対する脆弱性の増大や、ブロックチェーン履歴を確実に保存しているノード オペレーターが少数であるという事実など、潜在的なリスクもあります。ただし、暗号証明を使用すると、これらのリスクを軽減できます。全体として、ステートレス クライアントは、イーサリアムの現在の制限を克服する最も有望な方法の 1 つです。## 結論は導入が進むにつれ、イーサリアムの国家規模が拡大し、分散化への課題が生じています。ステートレス クライアントは、ブロックチェーンの完全な状態を必要とせずにノードがトランザクションを検証できるようにすることでソリューションを提供します。これにより、最終的には携帯電話でイーサリアムノードを実行できるようになり、分散化が大幅に進む可能性があります。
ステートレス クライアント: イーサリアムの分散化への道
著者: YQ、AltLayer 創設者、翻訳: Golden Finance cryptonaitive
イーサリアムの使用量が増加するにつれて、フルノードを実行すると、より多くのリソースと帯域幅が要求されます。その結果、フルノードを実行できる人がますます少なくなり、ネットワークの分散化が低下します。さらに、イーサリアムはトランザクション需要の増加に伴い拡張が難しくなり、ネットワークの混雑やガス料金の高騰につながります。
2017 年に Vitalik によって提案されたステートレス クライアントは、イーサリアムが直面している分散化の課題に対する潜在的な解決策を提供します。ステートレス クライアントの重要なアイデアは、フル ノードの実行に必要なストレージと帯域幅の要件を軽減し、より多くの人が参加できるようにし、ネットワークを分散化することです。この記事では、ステートレス クライアントの仕組みと、その潜在的な利点と欠点について詳しく説明します。
イーサリアムの状態とは何ですか?
ステートレスクライアントを理解するには、まずイーサリアムにおける「ステート」の概念を理解する必要があります。イーサリアムの状態とは、イーサリアム世界のすべてのアカウント、契約、残高、ノンス、ストレージの現在の状態を指します。これは、特定の時点でのイーサリアム ネットワークに関するすべての関連情報を保存するデータベースと考えることができます。
状態はマークル パトリシア トライの形式で保持されます。これは本質的に、キーと値のペアを格納するために使用される変更されたマークル ツリーです。トライのルート ハッシュは状態全体を要約します。新しいブロックごとに、そのブロック内のトランザクションに基づいてステータスが更新されます。新しい状態のルート ハッシュはブロック ヘッダーに含まれます。
時間の経過とともに、より多くのアカウント、契約、トランザクションが追加されるにつれて、イーサリアムの状態はますます大きくなっていきました。現在、州のサイズは 1 TB を超え、毎年数十 GB が追加されています。この拡大状態が地方分権問題の根本原因である。
状態の成長が問題を引き起こす理由
イーサリアムの状態サイズの増加により、いくつかの重要な問題が発生しています。
● 新しいノードの同期時間が長い - 新しいノードがすべての履歴ステータス変更を同期するには長い時間がかかります。これにより、新しいフルノードの実行が難しくなり、分散化が妨げられます。新しいノードをジェネシスブロックから最新の状態に同期するには、現在、何日も、あるいは何週間もかかります。これは、消費者向けハードウェアにとって、新しいノードを効果的に起動し、より多くの参加者がネットワークに参加できるようにするための大きな障害となっています。
● ハードウェア要件の増加 – 状態が大きくなると、保存、アクセス、更新のためにより多くのストレージ、メモリ、および処理能力が必要になります。これにより、リソースが少ないユーザーはノードを実行できなくなります。完全に同期された Ethereum ノードを実行するには、少なくとも 1 ~ 2TB の容量を持つ SSD が必要になります。これは、多くの潜在的なノード オペレーターにとって手の届かないものです。
● 帯域幅の使用量の増加 – 新しいブロックのブロードキャストには更新された状態も含める必要があり、より多くの帯域幅が必要になります。これにより、ノード運営者のコストが増加します。現在、ほとんどのブロック ブロードキャストは状態によって支配されているため、ブロック サイズは増大し続けています。帯域幅が増えると、ノード オペレーターのコストが高くなります。
● ブロック検証の遅延 – より大きな状態の読み取りと更新により、ブロック検証が遅くなり、トランザクションのスループットが制限されます。各トランザクションでは、残高、ノンス、契約ステータスなどを更新するために、ストレージへの複数回の読み取りと書き込みが必要です。状態が大きくなると、ブロックあたりの読み取り/書き込みが増加し、1 秒あたりに処理できるトランザクションの数が減少します。
● 永続的ストレージのコスト – データを状態に追加したら、永続的に保存する必要があります。これにより、無制限の状態が拡大します。現在、古い未使用の状態データを積極的に削除するメカニズムはありません。したがって、イーサリアムが運営され続ける限り、状態維持コストは無限に増加します。
ステートレス クライアントとは何ですか?
ステートレス クライアントは、完全な Ethereum 状態にアクセスする必要なく、新しいブロックを検証する方法を提供します。彼らは、「証人」と呼ばれる暗号証明を利用して、特定の状態データを必要とせずにブロック内の状態変化の正当性を証明します。
ステートレス クライアントは次のように動作します。
クライアントは、完全な状態データではなく、ブロック ヘッダーと状態ルートのみを保存します。ブロック ヘッダーには、ブロックの処理後の状態トライのルート ハッシュなどのメタデータが含まれます。
新しいブロックを検証するとき、クライアントはブロックと一緒に「証人」を受け取ります。この証人は、トランザクション内の特定の状態更新が有効であることを証明する一連のマークル証明です。
証人には、トランザクションの処理に使用される特定の状態値のマークル証明が含まれています。たとえば、アカウント残高や契約ストレージの更新などです。
クライアントは、監視を使用して、トランザクション ペアの最後の既知の状態ルートの有効性を確認します。この証明により、状態の変化が以前のルートと一致することが検証されます。
有効な場合、クライアントはブロック ヘッダーで指定された新しい状態ルートに更新します。この新しい状態ルートは、次のブロックを検証するために使用されます。
完全な状態をローカルに保存するのではなく、監視を使用して状態を検証することにより、ステートレス クライアントにはいくつかの利点が得られます。
● 非常に速い同期時間 - 履歴状態の変更を完全に同期する必要はありません。ステートレス クライアントは、ブロック ヘッダーのみを必要として、ほぼ瞬時に同期できます。
● 低いストレージ要件 - ステートルートはわずか 32 バイトです。数百ギガバイトの状態の代わりに、ブロック ヘッダーのみが必要になります。
● 帯域幅の使用量が少なくなります - 完全な状態ではなく、ブロック ヘッダーと監視のみが送信されます。帯域幅の使用量は最小限に抑えられます。
● 迅速な検証 - 証人には関連する州の小さなサブセットのみが含まれます。更新されたアカウント/ストアのみが有用であることが証明されています。
● ライト クライアントを簡単にサポート – ライト クライアントはプルーフを簡単に検証できます。ライト クライアント モデルはステートレス検証と非常に互換性があります。
ステートレス クライアントの課題
ステートレス クライアントにはいくつかの大きな利点がありますが、いくつかの重大な技術的課題もあります。
● 証人のサイズ - 証人が大きすぎて効率的に送信できない場合があります。完全なマークル証明が使用される場合、ブロック サイズの制限を超える可能性があります。
● 証人の作成 - ブロックの提案者にとって、最適な証人の生成は複雑です。提案者は、各トランザクションを検証するために正しい証拠を組み立てる必要があります。
● 証人へのインセンティブなし – 証人を提供することに対する直接的な報酬はありません。マイニングとは異なり、証人の作成に対する組み込みのインセンティブはありません。
● 一時データ - 証人は特定の時点でのステータスを証明するため、再生成する必要があります。状態の発展中に証人を再利用することはできません。
● 状態ストレージ – 証人を生成するには、誰かが完全な状態を維持する必要があります。ステートレス検証はステートフル監視生成に依存します。
● 複雑なアプリケーション - 一部の契約は州のより大きなサブセットに依存する場合があり、証人が肥大化します。たとえば、トランザクションごとに多くのストレージ スロットを更新するコントラクトなどです。
## 可能な解決策
研究者は、これらの課題に対処するためにさまざまなソリューションを提案しています。
● Verkle ツリー – 監視のサイズを削減するために使用される特別なデータ構造。 Verkle ツリーは、証明サイズを最小限に抑えるために、簡潔な暗号化コミットメントを使用します。
● 証人キャッシュ - 提案者は、再利用できるように最近の証人を維持できます。キャッシュは、作成コストが償却できることを証明する上で再び役立つ可能性があります。
● プロトコルのインセンティブ - 有用な証人に報酬メカニズムを提供します。新しいインセンティブ構造により、証人の作成を補うことができます。
● 中間状態のルート – プルーフの再生成を避けるために、時間をかけてルートを追跡します。ルートの一部を維持すると、証人フラグメントの再利用が可能になります。
● コンディションレント – 長期にわたってコンディションを維持し、未使用の状態を剪定するために支払いが必要です。 Rent は、プルーフ サイズを制限するために、古いストレージのクリーンアップを強制します。
● 分割された監視モデル – 提案者と検証者間の分割状態処理。多数の専用プロポーザー ノードが証人を生成します。
これらのアプローチの間にはトレードオフがあり、最適な実装を見つけるにはさらなる研究が必要です。幸いなことに、ゼロ知識暗号化の急速な革新により、効率的なステートレス クライアントに新たな可能性がもたらされる可能性があります。
潜在的な影響
技術的な障害を克服できれば、ステートレス クライアントはイーサリアムの成長を大幅に押し上げる可能性があります。
● より高速な同期と検証により、より高いトランザクション スループットをサポートします。ステートレス検証により、ブロック処理が大幅に高速化されます。
● ノードの実行に必要なリソースを削減し、分散化を改善します。ラップトップや愛好家は、現実的にフルノードを実行する可能性があります。
● モバイル ウォレットなどのライト クライアントのサポートが向上しました。 Proof of State は、ライト クライアント モデルと高い互換性があります。
● シャーディングをよりスムーズに導入し、シャード間のステートレス検証を実行します。クロスシャードトランザクションは、効率的な状態証明を利用できます。
● 役に立たなくなった古い状態データを削除および整理する機能。状態の成長は、無制限に成長するのではなく、積極的に管理できます。
● ノードオペレーターがニーズに応じてステータスをより柔軟にカスタマイズできる機能。ノードは、ユースケースに基づいて状態保持ポリシーをカスタマイズできます。
● ストレージよりもコンピューティングと帯域幅が重要なモデルへの移行。よりクラウドに適したモデルに向けてアーキテクチャが変更されます。
また、DDoS 攻撃に対する脆弱性の増大や、ブロックチェーン履歴を確実に保存しているノード オペレーターが少数であるという事実など、潜在的なリスクもあります。ただし、暗号証明を使用すると、これらのリスクを軽減できます。全体として、ステートレス クライアントは、イーサリアムの現在の制限を克服する最も有望な方法の 1 つです。
## 結論は
導入が進むにつれ、イーサリアムの国家規模が拡大し、分散化への課題が生じています。ステートレス クライアントは、ブロックチェーンの完全な状態を必要とせずにノードがトランザクションを検証できるようにすることでソリューションを提供します。これにより、最終的には携帯電話でイーサリアムノードを実行できるようになり、分散化が大幅に進む可能性があります。