Proof of Validator:イーサリアムのDHTのためのシンプルな匿名クレデンシャルスキーム

紹介

イーサリアムのロードマップには、 Data Availability Sampling(DAS)6と呼ばれるスケーリング技術が組み込まれています。 DAS は新しい <a href="https://notes.ethereum.org/@djrtwo/das-requirements">requirements を導入しました 4 イーサリアムのネットワークスタックに、 特殊なネットワークプロトコル の実装が必要 7.1つの顕著な<a href="https://notes.ethereum.org/ @dankrad /S-Kademlia-DAS">プロトコル提案4は、 Kademlia 2 に基づく分散ハッシュテーブル(DHT)を使用して、データのサンプルを保存および取得します。

ただし、 DHT 4 はシビル攻撃の影響を受けやすく、多数の DHT ノードを制御する攻撃者は、DAS サンプルを使用不能にすることができます。 この脅威に対抗するために、ビーコンチェーンバリデーターのみで構成される高信頼ネットワーク層を確立できます。 このようなセキュリティ対策は、DHTを攻撃するために自分のETHを賭けなければならないため、攻撃者にとっての障壁を大幅に引き上げます。

この記事では、DHTの参加者がゼロ知識でイーサリアムのバリデーターであることを証明できるプルーフ・オブ・バリデーター・プロトコルを紹介します。

動機:DASに対する「サンプル隠蔽」攻撃

このセクションでは、データ可用性サンプリングに対するシビル攻撃を説明することで、バリデータプロトコルの証明をさらに動機付けます。

DASプロトコルは、ブロックビルダーを中心に展開し、クライアントがブロックデータを取得できるようにブロックデータを利用できるようにします。 現在のアプローチでは、データをサンプルに分割し、ネットワーク参加者は自分の関心に関連するサンプルのみを取得します。

)

Sybil 攻撃者が、ネットワーク参加者が被害者ノードからサンプルを取得するのを阻止したいシナリオを考えてみましょう。 上の図に示されているように、攻撃者は被害者のノードIDに近い多くのノードIDを生成します。 攻撃者は、被害者のノードを自分のノードで囲むことで、悪質なノードが被害者の存在に関する情報を意図的に差し控えるため、クライアントが被害者のノードを発見するのを妨げます。

このような Sybil 攻撃の詳細については、DHT Eclipse 攻撃に関する 最近の研究論文 2 を参照してください。 さらに、<a href="https://notes.ethereum.org/@dankrad/S-Kademlia-DAS#SKademlia-modifications">Dankradの DASネットワークプロトコルの提案8は、S/Kademlia DHTプロトコルがこのような攻撃にどのように苦しむかを説明し、バリデータプロトコルの証明の必要性を示しています。

プルーフ・オブ・バリデーター

上記の攻撃は、バリデータプロトコルの証明の必要性を動機付けています:バリデーターだけがDHTに参加できるのであれば、シビル攻撃を仕掛けたい攻撃者は、大量のETHも賭けなければなりません。

プルーフ・オブ・バリデーター・プロトコルを使用して、ビーコンチェーン・バリデーターのみがDHTに参加でき、各バリデーターが一意のDHT IDを取得することを保証します。

さらに、バリデーターのDoSレジリエンスのために、ネットワークレイヤーでバリデータの身元を隠すことも目指しています。 つまり、攻撃者がどのDHTノードがどのバリデーターに対応しているかを知られないようにしたいのです。

これらの目的を達成するためには、プルーフ・オブ・バリデーター・プロトコルが以下の要件を満たさなければなりません。

• 一意性:各ビーコンチェーンバリデーターは、単一の一意のキーペアを導出できなければなりません。 このプロパティは、Sybil攻撃者が生成できるノードの数を制限するだけでなく、ネットワーク参加者が派生キーペアをブロックリストに登録することで、動作に問題のあるノードをローカルで罰することを可能にします
• プライバシー: 敵対者は、どのバリデータが特定の派生公開鍵に対応するかを知ることができなければなりません
• 検証時間:プロトコルの検証プロセスは、ノードあたり200ミリ秒未満で、各ノードが毎秒少なくとも5つの新しいノードを学習できるように、効率的でなければなりません

このようなバリデータープロトコルの証明は、DHTレイヤーでの接続確立中にボブによって使用され、アリスがバリデーターと話していることを知ることができます。

Proof of Validator プロトコル

私たちのプルーフ・オブ・バリデーター・プロトコルは、事実上、単純な匿名のクレデンシャルスキームです。 その目的は、アリスがバリデーターである場合にのみ、Dと表記される一意の派生キーを生成できるようにすることです。 その後、Alice は、この派生キー D をネットワーク層内で使用します。

このプロトコルの設計における私たちの目標は、実装と分析が簡単で、概説された要件を効率的な方法で満たすことを保証するソリューションを作成することでした。

プロトコルの概要

このプロトコルはメンバーシップ証明サブプロトコルを採用しており、アリスはZKプルーフを使用して秘密のハッシュプリイメージの知識を示すことで、自分がバリデーターであることを証明します。 次に、Alice は、そのシークレット ハッシュ プリイメージから派生した一意のキーペアを構築します。

メンバーシップ証明サブプロトコルは、さまざまな方法でインスタンス化できます。 この記事では、マークルツリーを使用したプロトコルと、ルックアップを使用した2番目のプロトコルを紹介します。

どちらのアプローチも許容できる効率を示していますが、明確なトレードオフがあります。 マークルツリーは、ポセイドン(実験的と見なされる可能性があります)のようなSNARKフレンドリーなハッシュ関数に依存しています。 一方、効率的なルックアッププロトコルは、バリデーターセットのサイズ(現在700kのバリデーターですが、増加中)に等しいサイズのタウのべき乗の信頼できるセットアップに依存しています。

それでは、プロトコルについて詳しく見ていきましょう。

アプローチ#1:マークルツリー

マークルツリーは、会員証として広く使用されています(例: セマフォ 3 を参照)。マークルツリーを使用してメンバーシップ証明を設計する際のトレードオフスペースは次のとおりです。

• 肯定的:信頼できるセットアップの必要がない
• 肯定的:理解しやすい
• ネガティブ: PoseidonのようなSNARKフレンドリーなハッシュ関数に依存しています
• ネガティブ:プルーフの作成が遅い

以下では、マークルツリーに基づくバリデータプロトコルの証明について説明します。

マークルツリーを用いたプルーフ・オブ・バリデーター・プロトコル

)

プロトコルの最後に、Alice は DHT で D を使用してメッセージに署名し、一意の DHT ノード ID を導き出すことができます。

次に、ルックアップを使用した、少し複雑ですが、はるかに効率的なソリューションを見てみましょう。

アプローチ #2: ルックアップ

Caulk 2 のような ルックアップ 2 プロトコルを使用する場合のトレードオフ スペースを次に示します。

• 肯定的:非常に効率的な証明作成(前処理フェーズを使用)
• 肯定的: プロトコルは、ポセイドンの代わりに通常のハッシュ関数を使用するように適合させることができます
• ネガティブ: 大きなサイズ (理想的にはバリデーターのサイズと等しい) の信頼できるセットアップが必要です

以下では、バリデータプロトコルの具体的な証明について説明します。

ルックアップを使用したバリデータプロトコルの証明

マークルのアプローチとまったく同じように、すべてのバリデーターiは、ブロックチェーン上に新しい値piを登録します。

効率

メンバーシップ証明プロトコル(リンク6 から ベンチマークコード5)のランタイムを、証明の作成と検証の観点からベンチマークしました。 メンバーシップ証明はバリデータープロトコルの証明の一部にすぎませんが、全体的な実行時間の大部分を占めると予想されます。

以下に、多項式コミットメントスキームとしてIPAを使用したHalo2プルーフシステムを使用したマークルツリーメンバーシッププルーフのベンチマーク結果を示します。 IPAはKZGよりも低速なスキームですが、信頼できるセットアップを必要とせず、マークルツリーアプローチの利点を最大限に生かします。

プローバーとベリファイアの両方の時間が、当社の効率要件とよく一致していることがわかります。 このため、コーキングベースのアプローチは、すべてのカテゴリ(特にプルーバー時間とプルーフサイズ)で性能が大幅に向上すると予想されるため、ベンチマークは行わないことにしました。

ベンチマークは、Intel i7-8550U(5年前のCPU)で動作するラップトップで収集されました。

議論

ID のローテーション

proof of validator プロトコルの一意性プロパティにより、各ネットワーク参加者が個別の派生キーペアを持つことが保証されます。 しかし、特定のネットワークプロトコルでは、バリデーターが定期的に、おそらく毎日、派生した鍵が変わるローテーションIDを持つことを許可すると有利な場合があります。

このようなシナリオでは、イブが特定の日に不正行為を行った場合、アリスはその日のブロックリストに登録できます。 ただし、翌日、Eve はブロックリストに登録されていない新しい派生キーを生成できます。 ローテーションIDに基づいてバリデータを恒久的にブロックリストに登録したい場合は、 SNARKBlock 1のようなより高度な匿名認証スキームが必要になります。

ID BLS12-381 公開キーを使用してみませんか?

別の(おそらくより単純な)アプローチは、すべてのバリデーターIDのBLS12-381キーからコミットメントを構築し、そのコミットメントでメンバーシップ証明を行うことです。

ただし、このアプローチでは、バリデーターがID秘密鍵をZKプルーフシステムに挿入して、有効なメンバーシッププルーフを作成し、一意の派生キーを計算する必要があります。

このアプローチは、機密性の高いIDキーを複雑な暗号化プロトコルに挿入することは良い習慣ではなく、バリデーターがメインのIDキーをオフラインに保つのが難しくなるため、採用しないことに決めました。

今後の研究の方向性

• SNARK回路を完全に回避し、純粋に代数的な方法でメンバーシップ証明と鍵導出を実行できますか?
• 関連:信頼できるセットアップやSNARKフレンドリーなハッシュ関数に頼らずに、効率的なメンバーシッププロトコルの証明を得ることはできますか?

確認

Enrico Bottazzi氏、Cedoor氏、Vivian Plasencia氏、Wanseob氏には、メンバーシップ証明コードベースのウェブをナビゲートしていただき、ありがとうございます。

免責事項：

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