今日、イーサリアム研究フォーラムで新しいコンセプトが静かに誕生しました: Proof of Validator。

このプロトコル メカニズムにより、ネットワーク ノードは、特定の身元を明らかにすることなく、イーサリアムのバリデーターであることを証明できます。

これは私たちと何の関係があるのでしょうか？

通常の状況では、市場はイーサリアム上の特定の技術革新によってもたらされる表面的な物語に注目する可能性が高く、事前に技術自体を深く調査することはほとんどありません。たとえば、上海のアップグレード、合併、PoW から PoS への移行、およびイーサリアムの拡大など、市場は LSD、LSDFi、および再プレッジの物語だけを覚えています。

ただし、イーサリアムにとってパフォーマンスとセキュリティが最優先事項であることを忘れないでください。前者は上限を決定し、後者は収益を決定します。

イーサリアムがパフォーマンスを向上させるためにさまざまな拡張ソリューションを積極的に推進している一方で、拡張の途上では内部スキルの練習に加えて、外部からの攻撃に対する防御も必要であることがはっきりとわかります。攻撃します。

たとえば、検証ノードが攻撃され、データが利用できなくなった場合、イーサリアムの誓約ロジックに基づくすべての物語や拡張計画が全体に影響を受ける可能性があります。ただ、影響とリスクは背後に隠れており、エンドユーザーや投機家は発見するのが難しく、場合によっては気にも留めないこともあります。

この記事で説明する Proof of Validator は、イーサリアムの拡張における重要なセキュリティ パズルになる可能性があります。

生産能力の拡大は不可欠であるため、生産能力の拡大のプロセスに含まれる可能性のあるリスクをどのように軽減するかは避けられないセキュリティ問題であり、これは私たち全員と密接に関係しています。

したがって、新たに提案される Proof of Validator の全体像を明らかにする必要がある。しかし、技術フォーラムの全文は断片的かつ硬派であり、多くの拡張スキームや概念が含まれているため、神潮研究所は元の投稿を統合し、必要な関連情報を整理し、背景、必要性の分析を実施しています。 Proof of Validator の影響の可能性について説明します。読書について学びましょう。

データ可用性サンプリング: 容量拡張のブレークスルー

心配しないでください。Proof of Validator を正式に導入する前に、イーサリアムの現在の拡大のロジックとそれに伴う可能性のあるリスクを理解する必要があります。

イーサリアム コミュニティは、いくつかの拡張計画を積極的に推進しています。その中でも、Data Availability Sampling (略称 DAS) は最も重要なテクノロジーと考えられています。

原理は、完全なブロック データをいくつかの「サンプル」に分割することです。ネットワーク内のノードは、完全なブロックを検証するために、自分自身に関連するいくつかのサンプルを取得するだけで済みます。

これにより、ノードごとのストレージと計算量が大幅に削減されます。わかりやすい例で言えば、これは標本調査と似ており、さまざまな人にインタビューすることで、母集団全体の全体的な状況をまとめることができます。

これにより、ノードごとのストレージと計算量が大幅に削減されます。わかりやすい例で言えば、これは標本調査と似ており、さまざまな人にインタビューすることで、母集団全体の全体的な状況をまとめることができます。

具体的には、DAS の実装について次のように簡単に説明します。

このサンプリングを通じて、各ノードが少量のデータしか処理しない場合でも、ブロックチェーン全体のデータ可用性を一緒に完全に検証できます。これにより、ブロック サイズが大幅に増加し、急速な拡張が可能になります。

ただし、このサンプリング スキームには重要な問題があります: 大量のサンプルはどこに保存されるのでしょうか? これには、サポートする分散ネットワークのセット全体が必要です。

分散ハッシュ テーブル: サンプルのホーム

これにより、分散ハッシュ テーブル (DHT) にその才能を発揮する機会が与えられます。

DHT は、ハッシュ関数を使用してデータをアドレス空間にマッピングする巨大な分散データベースとみなすことができ、異なるノードが異なるアドレス セグメント内のデータへのアクセスを担当します。これを使用すると、大規模なノード内のサンプルを迅速に検索して保存できます。

具体的には、DAS がブロック データを複数のサンプルに分割した後、これらのサンプルをネットワーク内のさまざまなノードに分散して保存する必要があります。 DHT は、これらのサンプルを保存および取得するための分散型メソッドを提供できます。基本的な考え方は次のとおりです。

たとえば、特定のルールに従って、各サンプルをアドレスにハッシュすることができ、ノード A は 0 ～ 1000 のアドレスを担当し、ノード B は 1001 ～ 2000 のアドレスを担当します。

次に、アドレス 599 のサンプルがノード A に保存されます。このサンプルが必要な場合は、同じハッシュでアドレス 599 を検索し、次にネットワーク内でそのアドレスを担当するノード A を検索し、そこからサンプルを取得します。

この方法は、集中ストレージの制限を打ち破り、耐障害性とスケーラビリティを大幅に向上させます。これはまさに DAS サンプル ストレージに必要なネットワーク インフラストラクチャです。

集中型のストレージと取得と比較して、DHT はフォールト トレランスを向上させ、単一障害点を回避し、ネットワークのスケーラビリティを強化できます。さらに、DHT は、DAS で言及されている「サンプル隠蔽」などの攻撃に対する防御にも役立ちます。

集中型のストレージと取得と比較して、DHT はフォールト トレランスを向上させ、単一障害点を回避し、ネットワークのスケーラビリティを強化できます。さらに、DHT は、DAS で言及されている「サンプル隠蔽」などの攻撃に対する防御にも役立ちます。

DHT の問題点: シビル攻撃

ただし、DHT にはシビル攻撃の脅威であるアキレス腱もあります。攻撃者はネットワーク内に多数の偽のノードを作成することができ、周囲の実際のノードはこれらの偽のノードによって「圧倒」されます。

たとえて言えば、誠実な行商人の周囲には、何列にもわたる偽造品があり、ユーザーが正規品を見つけるのは困難です。このようにして、攻撃者は DHT ネットワークを制御し、サンプルを利用できなくすることができます。

たとえば、アドレス 1000 のサンプルを取得するには、このアドレスを担当するノードを見つける必要があります。しかし、攻撃者が作成した数万の偽ノードに囲まれると、リクエストは継続的に偽ノードに送信され、実際にアドレスを担当するノードに到達できなくなります。その結果、サンプルを取得できず、保管も検証も失敗します。

この問題を解決するには、検証ノードのみが参加する高信頼ネットワーク層を DHT 上に構築する必要があります。ただし、DHT ネットワーク自体は、ノードがバリデーターであるかどうかを識別できません。

これは、DAS とイーサリアムの拡大を著しく妨げます。この脅威に対抗し、ネットワークの信頼性を確保する方法はあるのでしょうか?

Proof of Validator: 拡張のセキュリティを守る ZK ソリューション

さて、この記事の要点である Proof of Validator に戻りましょう。

本日、イーサリアムテクノロジーフォーラムで、George Kadianakis、Mary Maller、Andrija Novakovic、Suphanat Chunhapanya が共同でこの提案を提案しました。

その一般的な考え方は、前のセクションの DHT 拡張計画で誠実な検証者のみが DHT に参加できるようにする方法を見つけられれば、Sybil 攻撃を開始したい悪意のある人物も大量の ETH をプレッジする必要があるということです。 . 悪を行うコストが経済的に大幅に増加します。

言い換えれば、この考えは私たちにとってより馴染み深いものです。私は、あなたが良い人であり、あなたの身元を知らなくても悪い人を見分けることができることを知りたいのです。

情報が限られたこの種の証明シナリオでは、ゼロ知識証明が明らかに役に立ちます。

したがって、Proof of Validator (以下、PoV と呼びます) を使用して、誠実な検証ノードのみで構成された信頼性の高い DHT ネットワークを確立し、Sybil 攻撃に効果的に対抗できます。

基本的な考え方は、各検証ノードに公開鍵をブロックチェーンに登録させ、ゼロ知識証明技術を使用して公開鍵に対応する秘密鍵を知っていることを証明するというものです。これは、自分が検証ノードであることを証明するために自分の ID 証明書を取り出すことと同じです。

さらに、PoV は、検証ノードに対する DoS (サービス拒否) 攻撃に対して、ネットワーク層でバリデーターの ID を隠すように設計されています。つまり、このプロトコルは、攻撃者がどの DHT ノードがどのバリデータに対応するかを知ることができることを期待していません。

さらに、PoV は、検証ノードに対する DoS (サービス拒否) 攻撃に対して、ネットワーク層でバリデーターの ID を隠すように設計されています。つまり、このプロトコルは、攻撃者がどの DHT ノードがどのバリデータに対応するかを知ることができることを期待していません。

では、どうすればよいのでしょうか？元の投稿では多くの数式と導出が使用されているため、ここでは詳しく説明しません。簡略化したバージョンを示します。

具体的な実装としては、マークルツリーやルックアップテーブルが使用されます。例えば、マークルツリーを用いて、公開鍵リストのマークルツリーに登録用公開鍵が存在することを証明し、この公開鍵から導出されるネットワーク通信用公開鍵が一致することを証明する。すべてのプロセスはゼロ知識証明によって実現され、実際の身元は明らかにされません。

これらの技術的な詳細は省略しますが、PoV の最終的な効果は次のとおりです。

ID 検証に合格したノードのみが DHT ネットワークに参加でき、セキュリティが大幅に強化されるため、Sybil 攻撃に効果的に抵抗し、サンプルが意図的に隠蔽されたり変更されたりするのを防ぐことができます。 PoV は、DAS に信頼性の高い基本ネットワークを提供し、イーサリアムの急速な拡張を間接的に支援します。

ただし、現在のPoVはまだ理論研究の段階にあり、実現できるかどうかはまだ不確実だ。

しかし、この投稿の数人の研究者は小規模な実験を行っており、その結果は、ZK 証明を提案する際の PoV の効率と、証明を受け取る際の検証者の効率は悪くないことを示しています。特筆すべきは、彼らの実験装置は 5 年前に Intel i7 プロセッサを搭載しただけの単なるノートブックであるということです。

最後に、現在のPoVはまだ理論研究の段階にあり、実装できるかどうかはまだ不確実です。いずれにせよ、これはブロックチェーンのスケーラビリティの向上に向けた重要な一歩を表しています。イーサリアム拡張ロードマップの重要なコンポーネントとして、これは業界全体の継続的な注目に値します。