Partnered With:

Avail：Polygonが導入した拡張可能なデータ利用性レイヤ

DeFi之道

この記事を読むのに必要な時間は 22 分

Availは、データ利用可能性を重視した汎用性の高いスケーラブルなブロックチェーンであり、スタンドアロンチェーン、サイドチェーン、およびオフチェーン拡張ソリューションに適しています。

原文タイトル：《Polygon の新製品 Avail を理解する：拡張可能なデータ可用性レイヤー》

原著者：Polygon

原文出典：DeFi之道

Avail — 未来のブロックチェーンの動作方法における新しい重要な要素。Avail は、汎用性が高く、拡張可能で、データ可用性を中心に据えたブロックチェーンであり、スタンドアロンチェーン、サイドチェーン、およびオフチェーン拡張ソリューションに適しています。

Avail は、非常に安全な数学的原理を使用して、データ可用性レイヤーを提供しています — データ可用性チェックにはデータ保全性を持つエリュアーションコードを使用し、私たちは Kate 多項式コミットメントを使用して、不正証明を回避し、誠実な大多数の仮定を必要とせず、誠実なフルノードにデータが利用可能であるという信頼を置かずに二次元のデータ可用性アプローチを作成しています。

Avail は汎用のデータ可用性レイヤーを提供し、異なる実行環境で利用できます。これには、スタンドアロンチェーン、サイドチェーン、およびオフチェーン拡張ソリューションが含まれます。長期的には、Avail は、実行環境および最終実装に関するさまざまな実験をサポートし、チームやプロジェクトが独自のセキュリティ措置を立ち上げる必要がないようにします。Polygon SDK、Cosmos SDK、または Substrate を使用して作成されたチェーンは、この目的のために Avail を使用することで恩恵を受けることができます。

Avail は取引の実行と有効性をコンセンサスレイヤーから分離するため、コンセンサスは取引の並べ替えを行い、そのデータの利用可能性を保証することにのみ責任を負います。

主な目標

· 独立したチェーンやサイドチェーンなど、任意の実行環境を有効にし、トランザクションデータの可用性を保証することで、バリデータのセキュリティを導くためのバリデータセットの作成と管理が不要であること

· Avail をオフチェーンデータの可用性レイヤーとして使用することで、Validiums などの第2層ソリューションはより高いスケーラビリティとスループットを提供します

2020 年末から、Avail について機密に研究を行ってきましたが、現在は Devnet 階段にあり、テストネットが開発中です。問題、アーキテクチャ、およびソリューションに関する詳細情報や、コードリファレンスについては、ドキュメントを参照してください。

背景

現在のEthereumなどのエコシステムでは、主に3種類のノードがあります：

・バリデータノード

・フルノード

・ライトクライアント

ブロックは、バリデータノードによってブロックチェーンに追加され、このノードはトランザクションをメモリプールから収集し、それらを実行し、ブロックを生成してネットワークを介して伝播する前に、それらを含めます。このブロックには、ブロックに含まれるトランザクションに関連する要約とメタデータが含まれた小さなブロックヘッダーが含まれます。ネットワーク全体のフルノードはそのブロックを受け取り、そのブロックに含まれるトランザクションを再実行してその正当性を検証します。ライトクライアントは、隣接するフルノードから必要に応じてブロックヘッダーとトランザクションの詳細を取得します。ブロックヘッダーのメタデータにより、ライトクライアントは受信したトランザクションの詳細の正当性を検証できます。

このアーキテクチャは非常に安全で広く採用されていますが、いくつかの重要な実際の制約があります。ライトクライアントは全体のブロックをダウンロードしないため、ライトクライアントは底層のデータが利用できないブロックを受け入れる可能性があります。ブロック生産者は、悪意のあるトランザクションをブロックに含めるかもしれず、ネットワークにその全容を公開しない可能性があります。これはデータ可用性の問題と呼ばれ、ライトクライアントに深刻な脅威をもたらします。さらに悪いことに、データの利用不可能性は帰属不能な障害であり、我々は欺瞞証拠構造を追加することができず、この構造によりフルノードが信頼できる方法でライトクライアントにデータの欠落を通知できるようになります。

Existing Blockchains vs Polygon Avail

これに対して、Availはこの問題を解決するために異なるアプローチを取っています。Availはアプリケーションの状態を検証するのではなく、公開されたトランザクションデータの可用性とトランザクションの順序に焦点を当てています。共有されたブロックは、そのブロックの背後のデータが利用可能な場合のみ有効と見なされます。これは、ブロック生産者がブロックヘッダーをリリースするが、ブロックヘッダーの背後にあるデータを開示しない場合に、クライアントが必要なトランザクションを読み取るのを防ぐためです。

Availはデータの利用可能性検証にブロック検証の問題を単純化し、この作業をコスト効率的に行うためにデータの利用可能性チェックを使用できます。データの利用可能性チェックは冗長設計のデータ冗長性で広く使用されるエンコード検証に依存しています。

データの利用可能性チェックでは、各ライトクライアントがチェーン内の各ブロックから極めて少量のランダムブロックをサンプリングする必要があります。ライトクライアントグループはこのようにして全体のブロックチェーンを集合的にサンプリングすることができます。良いモデルは、Torrentなどのp2pファイル共有システムのようなシステムであり、異なるノードが通常、ファイルの一部を保存しているようなものです。

これらの技術は、Ethereum 2.0 や Celestia（以前の名前は LazyLedger）などのシステムで大々的に使用される予定です。

これは興味深い結果ももたらしました：ネットワーク内の非コンセンサスノードが多いほど、安全に保持できるブロックのサイズ（およびスループット）が大きくなります。これは有用な特性であり、非コンセンサスノードもネットワークのスループットとセキュリティに貢献できることを意味します。

KZG コミットメントベースのスキーム

Avail で使用されている KZG コミットメントベースのスキームには、主に次の3つの特徴があります：

・データ冗長性により、ブロッカーがブロックの任意の部分を隠すことが難しくなります。

・フレーデントレス保証の正しいリカバリコード

・ベクターコミットメントにより、全ノードが簡潔な証明を使用して軽いノードにトランザクションを含めることができます。

要するに、1つのブロック内のすべてのデータは2次元行列に配置されます。元の列のサイズを倍にするために、行列の各列にイレイジャコーディングが適用され、データ冗長性が導入されます。Kate コミットメントは各行を提出するために使用され、コミットメントはブロックヘッダーに含まれます。このスキームはデータの隠蔽試行を簡単に捉えることができます。ブロッカーがブロックの大部分を隠そうとした場合でも、ブロックヘッダーにアクセスできる軽クライアントは行列のランダムなセルをクエリし、ブロックヘッダーに基づいて検証できる短い証明を取得できます（Kate コミットメントのおかげ）。データの冗長性により、ブロック生産者はブロックの大部分を隠すように強制されます。単一のトランザクションを隠そうとしていた場合でも、ランダムサンプリングで簡単に捉えられます。フレーデントレス証明の必要性を回避しました。Kate コミットメントの制約性により、ブロック生産者が間違ったコミットメントを構築しても、計算的に取締まられることは非常に困難です。さらに、KZG コミットメントスキームの同型性特性を使用して、拡大行のコミットメントを計算できます。

KZG コミットメントスキーム

ここで Avail 構築の主な機能に言及しましたが、部分的データ取得や協力的可用性保証などの他の機能もあります。この記事では詳細を省略し、後続の記事で再度取り上げます。

今、実際のユースケースを例示し、演習する良いタイミングかもしれません。新しいアプリケーションが特定のアプリケーション固有の独自チェーンをホストしたいとします。Polygon SDK または他の類似のフレームワーク（Cosmos SDK または Substrate など）を使用して新しい PoS チェーンを立ち上げ、ビジネスロジックを組み込みます。しかし、十分なセキュリティを保証するためには、バリデータのステーキングを通じてブートストラップ問題があります。

このような状況を避けるために、それは Avail を使用してトランザクションのオーダリングとデータの利用性を行います。アプリケーションのユーザーは Polygon SDK チェーンにトランザクションをサブミットし、これらのトランザクションは自動的に Avail に転送され、そこで順次処理されます。整理されたトランザクションは、1つまたは複数のオペレータによってピックアップされ、ビジネスロジックに従って最終的なアプリケーションの状態が構築されます。アプリケーションのユーザーは、順次データが利用可能であることを安心し、アプリケーションの状態をいつでも再構築することができます。Avail によって提供される堅牢なセキュリティ保証を活用して、彼らはチェーンを利用できます。

上記の例は、Avail を使用して安全性を確保する新しい独自チェーンを利用する場合を議論していますが、このプラットフォームは汎用的であり、既存のどのチェーンでもデータ利用性を確保するために使用できます。次のセクションでは、Avail がどのようにして既存の Ethereum の集約拡張を支援するかについて簡単に触れます。

イーサリアムチェーンの拡張解決策のデータ利用性に関する説明

さまざまな Ethereum Layer 2 解決策が提案されており、Optimistic Rollup、ZK Rollup、Validium などが含まれます。これらの解決策は、実行をチェーンの外に移し、同時にアプリケーションの検証とデータのチェーン上の利用性を確保します。チェーンの外で実行するアーキテクチャはスループットを向上させますが、依然として Ethereum のようなメインチェーンが処理できるデータ量の制限を受けます。これは、実行がチェーンの外で行われるとしても、検証や紛争解決が厳密にチェーン上で行われるためです。トランザクションデータは Ethereum 上に calldata として提出され、将来の再構築のためにデータが利用可能であることを保証します。これは極めて重要です。

Optimistic Rollup の場合、オペレーターは無効なトランザクションをサブミットし、次に全体のブロックを一部抑制するかもしれません。そのような場合、システム内の他のフルノードは、サブミットされたアサーションが正しいかどうかを検証できません。データの不足のため、彼らはそのアサーションが実際に無効であることを証明する不正の証拠/チャレンジを生成することができません。

ゼロ知識を活用した Rollup の場合、ZKP の強固性は受け入れられたトランザクションが有効であることを保証します。しかし、このような保証があっても、トランザクションをサポートするデータを公開しない場合には深刻な副作用が発生します。

これにより、他の検証者がシステムの現在の状態を計算できなくなる可能性があり、ユーザーはシステムから排除され、彼らの残高が凍結される可能性があります。それは、その残高にアクセスするために必要な情報（ウィットネス）にアクセスできないためです。

私たちは、より高いスループットを実現するために、実行をオフチェーンに配置するだけでなく、データの可用性を保証するスケーラブルなデータ保管レイヤーが必要であることに気付いています。

このようなブロックチェーンの設計には、次の部分を解決する必要があります：

・データ保管とソーティング：この部分はトランザクションデータを受け取り、ソートし、実行は必要ありません。その後、データを保存し、分散された方法で完全なデータ可用性を確保します。これが Avail の鍵です。

・実行：実行コンポーネントは Avail から順序付けられたトランザクションを取得し、それらを実行する必要があります。それはチェックポイント/アサーション/プルーフを作成し、それをデータ検証レイヤーに提出する必要があります。これを実行レイヤーと呼びます。

・検証/紛争解決：この部分はシステムのアンカーとなるメインチェーンを代表します。設計のセキュリティは、この部分の強固性とセキュリティ属性に依存します。実行レイヤーが提出したチェックポイント/アサーション/プルーフは、このレイヤーによって処理され、データの可用性が確保された場合にのみ有効な状態遷移がシステムで受け入れられるようにします。これをデータ検証レイヤーと呼びます。