データの可用性の問題は何ですか?

! [データの可用性の問題は何ですか? (https://piccdn.0daily.com/202310/25080444/tnfnxd82p4sv8fpe.jpg!webp)

ブロックチェーンネットワークでは、ノードは新しく提案されたブロックのすべてのデータが利用可能であることをどのように保証するのでしょうか?

この記事では、データの可用性の問題と、それがイーサリアムのスケーラビリティにどのように影響するかについて深く掘り下げます。

データの可用性の問題とは?

データ可用性(DA)の問題:ブロックチェーンネットワーク内のノードは、新しく提案されたブロック内のすべてのデータが実際に利用可能であることをどのように保証し、データが利用できない場合、ブロックにはブロックプロデューサーによって隠された悪意のあるトランザクションが含まれている可能性があります。 ブロックに悪意のないトランザクションが含まれていても、それらを隠すとシステムのセキュリティが脅かされる可能性があります。

たとえば、AliceがZK-Rollupの演算子であるとします。 彼女はイーサリアムでZK-Proofを提出し、検証されました。 彼女がイーサリアム上のすべての取引データを提出していなかった場合、ロールアップで行われたすべての状態遷移が有効であることを証明したにもかかわらず、ロールアップのユーザーは現在の口座残高についてまだ知らない可能性があります。 ゼロ知識の性質上、提出された証明は現在の状態に関する情報を明らかにすることはできません。

オプティミスティックロールアップの場合、アリスがイーサリアムでアサーションを送信したが、トランザクションデータが利用できないため、OPRの参加者がクレームを再計算したり、異議を唱えたりできないという同様の例があります。

上記に対応して、OPRとZKRはどちらも、オペレーターがすべてのトランザクションの詳細を「コールデータ」としてイーサリアムに送信する必要があるように設計されています。 これにより、短期的には DA の問題を回避できますが、ロールアップ内のトランザクションの数が増えると、送信する必要があるデータの量も増加し、これらのロールアップが提供できるスケーリングの量が制限されます。

さらに悪いことに、データ利用不可は一意に帰属することができないエラーです。 これは、参加者が特定のデータブロックが欠落していることを他のノードに証明できないことを意味します。 これは、Bob は Alice が送信したブロックにデータが不足していることをブロードキャストできますが、Charlie は Alice にクエリを実行するときにデータを提供する可能性があるためです。

データ可用性の問題は、現在のブロックチェーンにどのような影響を与えるのか?

この疑問に答えるために、まずイーサリアムのようなブロックチェーンの一般的なブロック構造と、ブロックチェーンネットワーク上に存在するクライアントの種類を確認しましょう。

ブロックは2つの主要な部分に分けることができます。

• ブロックヘッダー: 小さなブロックヘッダーには、ブロックに含まれるトランザクションに関連する概要とメタデータが含まれています。 *ブロック本体:すべてのトランザクションデータを含み、ブロックの主要部分を形成します。

従来のブロックチェーンプロトコルでは、すべてのノードがフルノードと見なされ、ブロック全体を同期し、すべての状態遷移を検証します。 トランザクションの有効性をチェックし、ブロックを保存するために多くのリソースを必要とします。 利点は、これらのノードが無効なトランザクションを受け入れないことです。

すべてのトランザクションを検証するためのリソースを持たない(または使用したくない)別のタイプのノードが存在する可能性があります。 むしろ、ブロックチェーンの現状と、それに関連するトランザクションがチェーンに含まれているかどうかを理解することに主眼が置かれています。 理想的には、これらのライトクライアントは、無効なトランザクションを含むチェーンによってなりすましから保護されるべきです。 これは、実際には、不正防止と呼ばれるものを使用して実現できます。 これらの簡潔なメッセージは、特定のブロックに無効なトランザクションが含まれていることを示しています。 どのフルノードでもこのような不正防止を実現できるため、ライトクライアントは正直に言うと特定のフルノードを信頼する必要はありません。 彼らは、ブロックヘッダーの不正の証拠が利用可能な場合、それを確実に受け取ることができるゴシップネットワークにうまく接続されていることを確認する必要があります。

しかし、このシステムには問題があります:ブロックプロデューサーがブロックの背後にあるデータ全体を明らかにしない場合はどうなるでしょうか? この場合、フルノードは、ブロックにブロック本体が付属していなければ、ブロックでさえないため、明らかにブロックを拒否します。 ただし、ライト クライアントはブロック ヘッダーに公開され、データが欠落していることに気付かない可能性があります。 同時に、フルノードは、不正の証拠を作成するために必要なデータが不足しているため、詐欺の証拠を作成できません。

これに対処するには、ライトクライアントがデータの可用性を検証するためのメカニズムが必要です。 これにより、データを隠すブロックプロデューサーがライトクライアントを説得することで回避できなくなります。 これにより、ブロックプロデューサーはデータの一部を開示することを余儀なくされ、ネットワーク全体がブロック全体のデータに共同でアクセスできるようになります。

例を挙げて、この問題を詳しく見てみましょう。 ブロックプロデューサーの Alice が、トランザクション tx 1、tx 2、、...、 txn を含むブロック B を構築したとします。 tx 1 が悪意のあるトランザクションであるとします。 tx 1 がブロードキャストされた場合、どのフルノードでも悪意があることを検証し、この情報を不正の証拠としてライトクライアントに送信でき、ライトクライアントはブロックが受け入れられないことを即座に認識します。 ただし、Alice が tx 1 を非表示にする場合は、ヘッダーと tx 1 を除くすべてのトランザクション データのみを表示します。 フル ノードは tx 1 の正確性を検証できません。

簡単な解決策は、すべてのライトクライアントにトランザクションをランダムにサンプリングさせ、サンプルが利用可能であることがわかった場合、ブロックが利用可能であることを確信できるようにすることだと考える人もいるかもしれません。 ただし、ライトノードがトランザクションをランダムにクエリするように求められた場合、ライトクライアントが tx 1 をクエリする確率は 1/n です。 その結果、Aliceはほとんどの場合、ライトクライアントを騙して悪意のあるトランザクションを受け入れることができます。 つまり、ほとんどのライト クライアントはスプーフィングされています。 帰属しない性質のため、フルノードはtx 1が使用できないことをいかなる方法でも証明できません。 残念ながら、サンプルサイズを大きくしても状況は改善されません。

では、どうすればこの問題を解決できるのでしょうか?

この問題の解決策は、ブロックに冗長性を導入することにあります。 コーディング理論、特にイレイジャーコーディングに関して、この問題を解決するのに役立つ豊富な文献があります。

要するに、イレイジャーコーディングでは、任意のnブロックのデータを2つのnブロックに拡張できるため、2つのnのうちnつで元のデータを再構築できます(パラメータは調整可能ですが、ここでは単純化のためにこのケースを検討します)。

ブロックプロデューサーにトランザクションtx 1、tx 2、、...、txnを消去させ、単一のトランザクションを非表示にするには、n個のチャンクでトランザクションのセット全体を構築するのに十分であるため、n+ 1個のチャンクを非表示にする必要があります。 この場合、少数のクエリで、基になるデータが実際に使用可能であるという高い信頼度をライト クライアントに与えることができます。

うわー、それでおしまい?

いいえ。 この単純なトリックにより、データを隠すことがより困難になりますが、ブロックプロデューサーが意図的に間違った方法でコーディングを消去した可能性はまだあります。 ただし、フルノードは、このイレイジャーコーディングが正しく行われていることを検証でき、そうでない場合は、ライトクライアントに証明できます。 これは、上記の悪意のある取引と同様に、別のタイプの詐欺の証拠です。 興味深いことに、ライトクライアントのネイバーとして機能するのは誠実なフルノードだけで、ブロックが悪意のあるものである場合、不正の証拠を受け取ることができます。 これにより、ライトクライアントは、悪意のあるトランザクションがない可能性が非常に高いチェーンにアクセスできるようになります。

しかし、落とし穴があります。 あまりにも単純に行うと、一部の不正の証拠はブロック自体のサイズと同じ大きさになる可能性があります。 ライトクライアント向けのリソースの仮定により、このような設計を使用することは禁止されています。 多次元消去符号化技術の使用により、不正証明のサイズが小さくなりましたが、その代償として約束のサイズが大きくなりました。 簡潔にするために、ここではこれらについて詳しく説明しませんが、このホワイトペーパーではそれらを詳細に分析します。

不正証明ソリューションの問題は、ライトクライアントが不正の証拠をまだ受け取っていないブロックを完全に確信できないことです。 同時に、彼らはフルノードが正直であることを信頼し続けています。 また、誠実なノードには、ブロックを一貫してレビューするようにインセンティブを与える必要があります。

ここで見ているのは、ブロックエンコーディングが無効な場合、フルノードがライトクライアントを検出して証拠を提供し、不正行為を納得させることができることを保証するシステムです。 ただし、次のセクションでは、有効なコードのみをチェーンに送信できることを保証するブロックコードに焦点を当てます。 これにより、コーディングエラーを証明する必要がある不正証明が不要になります。 プルーフ・オブ・バリゼーション・ソリューションにより、アプリケーションは、フルノードがこの種の不正防止を提供するのを待たずにシステムを使用できます。

では、これらのソリューションはどのように機能するのでしょうか?

最近、多項式の約束は、ブロックチェーン空間への新たな関心を呼び起こしています。 これらの多項式コミットメント、特に多項式に対する一定サイズのKZG/Kateコミットメントは、不正証明を必要としないクリーンなデータ可用性(DA)スキームを設計するために使用できます。 一言で言えば、KZGの約束は、単一の楕円曲線群要素を使用して多項式にコミットすることを可能にします。 さらに、このスキームにより、特定の点 i で多項式φの値が φ(i) であることを、一定サイズの証人を使用して証明できます。 このコミットメントスキームは、計算的に拘束力があり、準同型であるため、不正の証明を巧みに回避することができます。

ブロックプロデューサーは、生のトランザクションデータをサイズn x mの2次元行列に配置するように強制します。 多項式補間を使用して、各列のサイズ n をサイズ 2 n の列に拡張します。 この拡張行列の各行は、多項式コミットメントを生成し、それらのコミットメントをブロックヘッダーの一部として送信します。 ブロックの概略図を以下に示します。

ライトクライアントは、この拡張行列の任意のセルに証明を照会し、ブロックヘッダーに対して即座に検証できるようにします。 一定サイズのメンバー識別により、サンプリングが非常に効率的になります。 コミットされた準同型は、ブロックが正しく構築された場合にのみ証明を検証できることを保証し、多項式補間は一定の数の成功したサンプルを保証し、データが利用可能になる可能性が非常に高いことを意味します。

! [データの可用性の問題は何ですか? (https://piccdn.0daily.com/202311/17064433/5gjxe19ptk6oa203.png!webp)

ブロックの概略図

このシナリオのより詳細な部分、およびさらなる最適化とコストの見積もりは、この記事の範囲を超えています。 ただし、ここでは2Dスキームについて話していますが、ブロックヘッダーサイズが小さい1Dスキームでも同様の保証を提供できますが、並列処理と軽いクライアントサンプリング効率が低下します。 これについては、次の記事で詳しく説明します。

他にどのような選択肢がありますか? 次に何が起こるか?

高次元のイレイジャーコーディングとKZGのコミットメントは、データ可用性の問題を解決する唯一の方法ではありません。 ここでは、マークルツリーのコーディング、インターリーブツリーのコーディング、FRI、STARKベースの方法など、他のいくつかのアプローチを省略しましたが、それぞれに長所と短所があります。

アベイルでは、KZGのコミットメントを利用して、データ可用性ソリューションを開発してきました。 今後の記事では、実装の詳細、使用方法、およびデータ可用性の問題領域をどのように変更する予定かについて説明します。 アベイルズの詳細については、Twitterでフォローしてください

Twitterは、アメリカ発祥のソーシャル・ネットワーキング・サービス・プラットフォームです。 2022年10月27日、マスク氏はTwitterの買収を完了し、新たに設立された「X」社に統合しました。 マスク氏の以前のTwitterメッセージによると、彼は包括的なアプリを作成する予定であり、Twitterを買収することでこの欲求を加速させることができると述べました。

をクリックし、Discordサーバーに参加してください。

囀る：

不和：

Modular 101 の Twitter アカウントは @Modular 101 です。