Avail テストネットが稼働中です。ユーザーが Avail をチェーン設計に統合し始めると、よく生じる質問は次のとおりです:「Avail はどれくらいのトランザクションを処理できますか?」これはスケーラビリティに関するシリーズの最後の記事であり、Avail の現在のパフォーマンスとその短期的なパフォーマンスについて説明します。そして長期的な拡張性。パート 1 はここで、パート 2 はここで読むことができます。
以下のモデルは、ブロックの提案と構築 (ブロックにどのトランザクション/データ ブロックが含まれるかを決定する) というアクションが分離され、異なるアクターによって実行されるアーキテクチャを説明します。
この新しいブロック ビルダー エンティティを作成することにより、行コミットメントの生成とセル プルーフの生成に必要な計算作業を、さまざまな参加者間で共有できます。
Avail の中心的な機能は、データを受信し、注文されたデータを出力することです。 API のようなものだと考えてください。 Avail を使用すると、誰でもデータの可用性をサンプリングできます。
改善できる点を強調する前に、まず、現在の状態でのブロック プロポーザーとバリデーター/フル ノードに対する Avail の要件を詳しく説明します。
1. ブロックプロデューサーはブロック本体を作成します
トランザクションの収集（データ提出）
これらのトランザクションを Avail データ マトリックスに並べ替えます。これがブロック本体になります。
2. ブロックプロデューサーがブロックヘッダーを作成する
行列の各行に対して Promise を生成する
多項式補間を使用してこれらのコミットメントを拡張します (生成および拡張されたコミットメントはブロック ヘッダーになります)
3. ブロックプロデューサーはブロック (ボディ + ヘッダー) を伝播します。
4. バリデーターとフルノードがブロックを受け取る
5. バリデーターとフルノードはブロックをデコード、再構築、検証します
データマトリクスを再構築する
約束を再構築する
延長されたコミットメント
受信したすべてのデータが生成した約束と一致することを確認する
5 番目のステップは、ノード全体でブロック ヘッダーを再生成する必要がありますが、Avail のようなシステムでは不要です。
Avail は従来のブロックチェーンのアーキテクチャを継承しており、実行操作が正しく完了したことを確認するためにバリデーターが必要なため、現在フルノードでこれが行われています。 Avail は実行操作を処理しません。ブロック プロポーザー、バリデーター、およびライト クライアントは、データの可用性のみを考慮します。これは、Avail ネットワークのすべての参加者が、データ可用性サンプリングを使用してトラストレスにデータの可用性を確認できることを意味します。
バリデーターとフルノードはサンプリングを通じてデータの可用性をチェックできるため、ネットワークのセキュリティを確保するためにブロック全体を再構築する必要はありません。
検証者は、すべてが正しいかどうかを確認するためにプロデューサーが行ったことをすべてやり直す必要はありません。代わりに、少量をサンプリングすることで確認できます。ライトクライアントの場合と同様に、データ可用性の統計的保証に達すると (8 ～ 30 サンプル後)、バリデーターはブロックをチェーンに追加できます。 Avail はデータの実行を処理しないため、この操作は安全に実行できます。
データ サンプリングは、バリデーターに、面倒な 1:1 検証プロセスに代わるはるかに高速な代替手段を提供します。 Avail の魅力は、ブロック ヘッダーのみを使用することで、誰でも (この場合はバリデーター) が正しいチェーンに従っているというコンセンサスに達できることです。
これができれば、ブロックヘッダー再構成ステップ全体をいくつかのサンプルに置き換えることができます。
この記事では、バリデーターの要件の変化とその他の改善点について説明します。ここでは、ブロック提案者が (依然として) ブロックを作成して伝播しますが、他のすべてのネットワーク参加者がデータ可用性サンプリングを通じてネットワークと対話する、改良されたシステムについて説明します。次に、2 つの異なるネットワーク参加者によって操作される、ブロック構築とブロック提案を分離するさらなるシステムを導入します。
これらの変更は比較的進んでおり、現在も活発な研究が行われていることに注意することが重要です。
Avail の場合、より効率的なモデルは、単一ノードがコミットメントを構築してネットワークに伝達することです。他のすべての参加者は証明を生成して検証します。
ライトクライアントだけでなく、チェーンのどの部分でもこれを実行できるようにするのはこれが初めてです。バリデーターがライトクライアントと同じ方法でサンプリングできるようにします。
このモデルでは、単一のバリデーターがブロックを提案し、データ行列のすべての行のコミットメントを作成してから、ブロック ヘッダーのみを提案します。
ステップ 1: プロポーザーはブロック ヘッダー情報のみを伝播します。
ステップ 2: バリデーターはヘッダー情報のみを受信するため、ブロックをデコードしたり再構築したりすることはできません。ただし、データの可用性をサンプリングできるため、その必要はありません。
この場合、他のバリデーターはライトクライアントのように動作します。
これらの他のバリデータは、データの可用性サンプリングに Promise を使用し、可用性の保証が満たされた場合にのみブロックを受け入れます。
この世界では、すべてのノードがライト クライアントのように動作します。バリデーターは、ブロック本体を使用してコミットメントを再生成することを回避し、ブロック提案者による正しい計算を保証できます。
検証者が単に証明の検証に依存できる場合、証明計算のコミットメントを生成する必要はありません。
フルノードにはブロックの有効な実行を検証する必要がないため (Avail は実行を実行しません!)、フルノードはヘッダー情報のみに基づいて正しいチェーンに従っていることを確認できます。必要なのは可用性の証明だけであり、ヘッダー情報 (少数のランダムなサンプルと組み合わせた) がこれを提供します。これにより、バリデーターになるために必要な計算量を減らすことができます。
これには、通信時間を短縮できる可能性があるという追加の利点もあります。
複雑
このモデルを短期間で完成させるには、Substrate の基本構造から脱却する必要があるため、躊躇しました。外部ルートを削除する必要があるため、Substrate ツールへのアクセスがすべて遮断されますが、これは私たちが積極的に検討している改善点です。
別のモデルは、EIP-4844 のシャード BLOB モデルから借用しています。https://eips.ethereum.org/EIPS/eip-4844?ref=blog.availproject.org
このシステムを想像してください:
1. ブロック データ マトリックスの各行は、異なるビルダーによって構築され、行の関連する多項式コミットメントが含まれます。
ビルダーは自分の行を p2p ネットワークと共有し、提案者に約束を渡します。
2. ヘッダーの作成: 単一のブロック プロポーザーがこれらのコミットメントを収集します。
提案者は、エンコードされたコミットメントを消去する前に、特定のコミットメントが有効なオープンプルーフを生成できることを確認するために、ビルダー (および p2p ネットワーク) からサンプリングします。この元の Promise + 拡張された Promise の組み合わせがヘッダーになります。
3. プロポーザーは、このヘッダーをバリデーターと共有します。
4. 提案者と検証者は、p2p ネットワーク (またはビルダー) からランダムなユニットをサンプリングし、データが有効なオープンプルーフを生成することを確認することによって、データ可用性サンプリングを実行します。
5. バリデーターが可用性の統計的保証に達すると、ブロック ヘッダーがチェーンに追加されます。
コミットメントは多くの参加者によって生成されるため、ブロック提案者は多くの作業を行う必要はありません。
遅延プロポーザー モデルには、ブロックに対して 1 つのプロポーザーがあります。その後、参加者は、上記の提案者と構築者の分離と同じ方法で分割できます。
複数のビルダーがブロックの小さな部分を作成する場合があります。これらはすべて、これらのブロックをエンティティ (提案者) に送信し、エンティティは各部分をランダムにサンプリングして、提案するヘッダーを構築します。
ブロック本体は論理構造を使用して構築されます。
一例
遅延プロポーザー モデルが異なるのは、ブロック ビルダーとブロック プロポーザーが別個のエンティティであることです。
4 つのブロック ビルダーがあり、それぞれにデータ行列の行があるとします。各ビルダーは、この行を使用して Promise を作成します。
次に、各ビルダーは行と構築されたコミットメントを指定されたプロポーザーに送信し、プロポーザーはブロック本体からデータをサンプリングして指定されたコミットメントを確認します。次に、提案者はコミットメントを多項式に補間して、最初に構築されたコミットメントが 4 つだけでなく 8 つになるようにします。データ マトリックスは消去エンコードされ、拡張されました。
これら 8 行と 8 つの約束は、同じ提案者によって検証されています。
マトリックス全体を見ると、行の半分が提案者によって構築され (消去によってエンコードされ)、残りの半分が提案者に提供されていることがわかります。
次に、プロデューサーがブロック ヘッダーを提案し、全員がそれを受け入れます。この結果、ブロックはより効率的に構築されていますが、Avail テストネットによって現在生成されているブロックと同じように見えます。
Avail の遅延プロポーザー モデルはより効率的ですが、非常に複雑でもあります。システム全体を最適化する簡単な機会は他にもありますが、Avail チームはこのモデルの実装を検討することに興奮しています。
従来のブロックチェーントランザクションと遅延プロポーザーモデルの比較
遅延プロポーザー モデルは、今日の Avail 以外のブロックチェーンで個々のブロックチェーン トランザクションが処理される方法とそれほど変わりません。
現在、ほぼすべてのチェーンでトランザクションを実行すると、このトランザクションの通知がすべてのノードに送信されます。間もなく、各ノードのメモリプールにこのトランザクションが含まれるようになります。
では、ブロックプロデューサーは何をするのでしょうか?
ブロックプロデューサーはメモリプールからトランザクションを取得し、それらを集約してブロックを生成します。これはブロックプロデューサーの典型的な役割です。
Avail では、データ ブロックとそのコミットメントは個別のトランザクションと同様に扱われます。これらのデータ ブロックとコミットメントの組み合わせは、個々のトランザクションが従来のチェーンで送信されるのと同じように、システム上に伝播されます。
間もなく、誰もがこれらのデータの塊にコミットするようになるでしょう。これらの取り組みを実施すると、提案者はデータの可用性を確保するためにランダムなサンプリングを開始できます。十分なサンプリングの信頼性があれば、ノードはこれらのコミットメントを拡張し、本文内のデータを受け入れ、ブロック ヘッダーを構築して、次のブロックを作成します。
結論
Avail 向けに提案されたこれらのアーキテクチャ提案は、データ可用性レイヤーをブロックチェーンの他のコア機能から切り離すことの重要性を示すことを目的としています。
データの可用性が個別に処理される場合、データの可用性を独立したレイヤーとして扱うように最適化を行うことができ、データの可用性が実行などの他のブロックチェーン機能に関連付けられている場合よりも大幅な改善につながる可能性があります。
それらがレイヤー 3 ソリューション、モジュラー ブロックチェーン、またはオフチェーン スケーリング ソリューションと呼ばれているかどうかに関係なく、この専用のデータ可用性レイヤーを活用してチームが思い付く斬新なアイデアを見るのを楽しみにしています。チームは、Avail がその上に構築されたチェーンやアプリケーションを直接拡張できるため、安心できます。私たちは、数百のバリデーター、数千のライトクライアント、そして今後登場する多くの新しいチェーンを備えたモジュラーブロックチェーンネットワークを構築しているため、需要を満たすために問題が発生することはないと予想しています。
