ブロックチェーン ネットワークでは、ノードはどのようにして新しく提案されたブロックのすべてのデータが利用可能であることを確認するのでしょうか?何でこれが大切ですか？
この記事では、データ可用性の問題と、それがイーサリアムのスケーラビリティにどのような影響を与えるかについて詳しく説明します。
データ可用性の問題は何ですか?
データ可用性 (DA) 問題: ブロックチェーン ネットワーク内のノードは、新しく提案されたブロック内のすべてのデータが実際に利用可能であることをどのように確認するのでしょうか?データが利用できない場合、ブロックには、ブロック作成者によって隠蔽された悪意のあるトランザクションが含まれている可能性があります。ブロックに悪意のないトランザクションが含まれている場合でも、それらを非表示にするとシステムのセキュリティが脅かされる可能性があります。
たとえば、Alice が ZK-Rollup オペレーターであると仮定します。彼女はイーサリアム上で ZK-Proof を提出し、検証されました。彼女がイーサリアム上のすべての取引データを提出しない場合、ロールアップのユーザーは依然として現在の口座残高について分からないままになる可能性がありますが、彼女の証拠はロールアップで行われたすべての状態遷移が有効であることを確認しています。ゼロ知識の性質のため、提出された証明では現在の状態に関する情報を明らかにすることはできません。
オプティミスティック ロールアップ シナリオにも同様の例があり、アリスはイーサリアムでアサーションを送信しましたが、トランザクション データが利用できなかったため、OPR 参加者はアサーションを再計算したり異議を申し立てることができませんでした。
上記の状況に対処するために、OPR と ZKR の両方の設計では、オペレーターがすべてのトランザクションの詳細を「calldata」としてイーサリアムに送信する必要があります。これにより、短期的には DA の問題を回避できますが、ロールアップ内のトランザクション数が増加するにつれて、コミットする必要があるデータの量も増加し、これらのロールアップが提供できるスケーリングの量が制限されます。
さらに悪いことに、データが利用できないことは、一意に原因を特定できないエラーです。これは、参加者がデータの特定のブロックが欠落していることを他のノードに証明できないことを意味します。これは、ボブは、アリスによって送信されたブロックにはデータが欠落していることをブロードキャストできるが、チャーリーがアリスにクエリを実行すると、アリスにデータを提供する可能性があるためです。
データの可用性の問題は現在のブロックチェーンにどのような影響を及ぼしますか?
この質問に答えるために、まずイーサリアムのようなブロックチェーンの一般的なブロック構造と、ブロックチェーン ネットワーク上に存在するクライアントの種類を確認してみましょう。
ブロックは 2 つの主要な部分に分割できます。
ブロック ヘッダー: 小さなブロック ヘッダーには、ブロックに含まれるトランザクションに関連する概要とメタデータが含まれています。
ブロック本体: すべてのトランザクション データが含まれており、ブロックの主要部分を構成します。
従来のブロックチェーン プロトコルでは、すべてのノードがフル ノードとみなされ、ブロック全体が同期され、すべての状態遷移が検証されます。トランザクションの有効性をチェックしてブロックを保存するには、大量のリソースが必要です。利点は、これらのノードが無効なトランザクションを受け入れないことです。
すべてのトランザクションを検証するためのリソースを持たない (または費やしたくない) ノードの別のカテゴリが存在する可能性があります。代わりに、彼らはブロックチェーンの現在の状態と、ブロックチェーンに関連するトランザクションがチェーンに含まれているかどうかを理解することに主に興味を持っています。理想的には、これらのライト クライアントは、無効なトランザクションを含むチェーンによるなりすましからも保護される必要があります。これは実際には、いわゆる不正行為の証明を使用して実現できます。これらの簡潔なメッセージは、特定のブロック本体に無効なトランザクションが含まれていることを示します。どのフルノードでもそのような不正証拠を生成できるため、ライトクライアントは正直に言って特定のフルノードを信頼する必要はありません。必要なのは、ブロック ヘッダーの不正行為の証拠が利用可能であれば、確実にそれを受信できるようにするゴシップ ネットワークに適切に接続していることを確認することだけです。
ただし、このシステムには問題があります。ブロックプロデューサーがブロックの背後にある完全なデータを明らかにしない場合はどうなるでしょうか?この場合、フル ノードは明らかにそのブロックを拒否します。フル ノードの観点からは、ブロックにブロック本体が付属していなければ、それはブロックですらないからです。ただし、軽量クライアントにはブロック ヘッダー チェーンが表示され、データの欠落に気付かない可能性があります。同時に、フルノードは不正証明を作成するために必要なデータが不足しているため、不正証明を作成できません。
この問題に対処するには、ライト クライアントがデータの可用性を確認するためのメカニズムが必要です。これにより、データを隠しているブロックプロデューサーがライトクライアントを説得して回避することができなくなります。これにより、ブロックプロデューサーは部分的なデータを公開する必要が生じ、ネットワーク全体が協力してブロックのデータ全体にアクセスできるようになります。
例を挙げてこの問題をさらに深く理解してみましょう。ブロックプロデューサーのアリスがトランザクション tx 1、tx 2、...、txn を含むブロック B を構築するとします。 tx 1 が悪意のあるトランザクションであると仮定します。 tx 1 がブロードキャストされると、フル ノードはそれが悪意のあるものであることを検証し、この情報を詐欺の証拠としてライト クライアントに送信することができ、ライト クライアントはブロックが受け入れられないことをすぐに認識します。ただし、アリスが tx 1 を非表示にしたい場合は、ヘッダーと tx 1 を除くすべてのトランザクション データのみを公開します。フルノードでは tx 1 の正確性を検証できません。
簡単な解決策は、すべてのライト クライアントにトランザクションをランダムにサンプリングさせ、サンプルが利用可能であることがわかったら、ブロックが利用可能であると確信できるようにすることであると考える人もいるかもしれません。しかし、ライト ノードがランダムにトランザクションをクエリする場合、ライト クライアントが tx 1 をクエリする確率は 1/n です。したがって、アリスはほとんどの場合、ライトクライアントをだまして悪意のあるトランザクションを受け入れることができます。言い換えれば、ほとんどのライトクライアントはなりすましを受けることになります。帰属不可能な性質のため、フル ノードは tx 1 が利用できないことをいかなる方法でも証明できません。残念ながら、サンプルサイズを増やしても状況は改善されません。
では、この問題をどのように解決すればよいでしょうか?
この問題の解決策は、ブロックに冗長性を導入することにあります。コーディング理論、特にイレイジャーコーディングに関する文献は豊富にあり、この問題に対処するのに役立ちます。
つまり、イレイジャーコーディングを使用すると、任意の n データ ブロックを 2n データ ブロックに拡張できるため、2n の任意の n で元のデータを再構築できます (パラメーターは調整可能ですが、ここでは単純にしてこの状況を考慮します)。
ブロックプロデューサーにトランザクション tx 1、tx 2、...、txn の消去コードを強制する場合、トランザクション全体を構築するには任意の n データ ブロックで十分であるため、単一のトランザクションを非表示にするには、n+1 データ ブロックを非表示にする必要があります。セット。この場合、少数のクエリにより、基礎となるデータが実際に利用可能であるという高い信頼性をライト クライアントに与えることができます。
Woah,それだけですか？
いいえ。この単純なトリックによりデータの隠蔽は困難になりますが、ブロック作成者が意図的に間違った方法で消去コーディングを行った可能性は依然としてあります。ただし、フル ノードは、このイレイジャー コーディングが正しく行われていることを検証でき、正しく行われていない場合は、これをライト クライアントに証明できます。これも、上記の悪質な取引と同様に、別の種類の詐欺の証拠です。興味深いことに、必要なのは、ブロックが悪意のある場合に不正の証拠を受け取ることを保証するために、ライト クライアントの近隣として 1 つの正直なフル ノードだけであることです。これにより、ライト クライアントは非常に高い確率で悪意のあるトランザクションのないチェーンにアクセスできるようになります。
しかし、問題があります。単純すぎると、一部の不正行為の証明がブロック自体のサイズと同じくらい大きくなる可能性があります。ライトクライアントに関するリソースの想定により、そのような設計を使用することはできません。コミットメントのサイズを増やす代わりに、不正行為の証明のサイズを縮小する多次元消去コーディング技術の使用によって改善が行われています。簡潔にするために、ここではこれらについて詳しく説明しませんが、この記事では紙これを詳細に分析しました。
不正証明に基づくソリューションの問題は、ライト クライアントがまだ不正証明を受け取っていないブロックについて完全に確信できないことです。同時に、彼らは完全なノードが正直であると信頼し続けます。正直なノードには、ブロックを継続的にレビューするよう奨励する必要もあります。
ここで私たちが焦点を当てているのは、ブロックエンコーディングが無効な場合に、フルノードがそれを検出し、ライトクライアントに不正行為を納得させる証拠を提供できることを保証するシステムです。ただし、次のセクションでは、有効なエンコーディングのみがチェーンに送信されることを保証するブロック エンコーディングに焦点を当てます。これにより、コーディングエラーを証明する不正行為の証明が不要になります。有効性証明に基づくソリューションにより、アプリケーションは、ノード全体が不正の証明を提供するまで待つことなくシステムを使用できるようになります。
では、これらのソリューションはどのように機能するのでしょうか?
最近、多項式コミットメントがブロックチェーン空間への新たな関心を生み出しています。これらの多項式コミットメント、特に多項式に対する一定サイズの KZG/Kate コミットメントを使用すると、不正証明を必要としないきちんとしたデータ可用性 (DA) スキームを設計できます。つまり、KZG コミットメントにより、単一の楕円曲線グループ要素を使用して多項式にコミットすることができます。さらに、このスキームにより、一定サイズの証人を使用して、ある点 i で多項式 φ が値 φ(i) を持つことを証明することができます。このコミットメントスキームは計算上の拘束力があり、準同型であるため、不正行為の証明をきちんと回避できます。
ブロックプロデューサーに、生のトランザクションデータをサイズ nxm の 2 次元行列に配置するよう強制します。多項式補間を使用して、サイズ n の各列をサイズ 2 n の列に拡張します。この展開行列の各行は多項式コミットメントを生成し、これらのコミットメントはブロック ヘッダーの一部として送信されます。ブロックの概略図を以下に示します。
ライト クライアントは、この拡張行列の任意のセルに証明を問い合わせます。これにより、ブロック ヘッダーに対して即座に検証できます。メンバーシップの一定サイズの証明により、サンプリングが非常に効率的になります。コミットメントの準同型の性質により、ブロックが正しく構築された場合にのみ証明を検証できることが保証されますが、多項式補間により、成功したサンプルの数が一定であることは、データの可用性の確率が非常に高いことを意味します。
ブロックの概略図
このスキームの詳細、およびさらなる最適化とコストの見積もりについては、この記事の範囲を超えています。ただし、ここでは 2 次元スキームについて説明していますが、ブロック ヘッダー サイズが小さい 1 次元スキームでも同様の保証を提供できることを指摘しておきますが、並列処理と軽量化が犠牲になります。クライアントのサンプリング効率。これについては、次の記事でさらに詳しく説明します。
他の代替手段は何ですか?次は何が起こる？
高次元イレイジャーコーディングと KZG コミットメントだけがデータ可用性の問題の解決策ではありません。ここでは、コード化マークル ツリー、コード化インターリーブ ツリー、FRI、STARK ベースの方法など、他のいくつかの方法を省略しましたが、それぞれの方法には長所と短所があります。
Avail では、KZG コミットメントを使用してデータ可用性ソリューションを開発してきました。今後の記事では、実装の詳細、その使用方法、およびデータ可用性の問題スペースをどのように変更する計画について説明します。 Avail についてさらに詳しく知りたい場合は、Twitter でフォローして、Discord サーバーに参加してください。
Twitter：https://twitter.com/AvailProject
Discord：https://discord.com/invite/jTkvDrZ54r
Modular 101 の Twitter アカウント @Modular 101 もフォローしてください。
