Polygon の新バージョンの Avail Testnet が公開されました

Polygon Avail テストネットが公開されました。ユーザーがチェーン設計に Avail を組み込み始めると、「Avail はいくつのトランザクションを処理できるか?」という質問がよく出てきます。

これは、Polygon Avail の現在のパフォーマンスと、短期的および長期的なスケーリング能力について取り上げる一連の記事の最初の記事です。 Avail が技術的にどのように実装されているかを概説した記事を既に公開しています。まず、両方のチェーンの現在のアーキテクチャを考慮して、イーサリアムとアベイルのスループットを比較します。

ポリゴン アベイル vs イーサリアム

Ethereum ブロックは最大 1.875 MB を保持でき、ブロック時間は ~13 秒です。ただし、通常、イーサリアム ブロックは満たされていません。実行と決済の両方にガスがかかるため、ほぼすべてのブロックがデータ制限に達する前にガス制限に達します。その結果、ブロックごとに保存されるデータの量は可変です。

実行、決済、およびデータの可用性を同じブロックに組み合わせる必要性は、モノリシック ブロックチェーン アーキテクチャの中心的な問題です。レイヤー 2 (L2) ロールアップは、実行専用のブロックを使用して、別のチェーンで実行を処理できるようにすることで、モジュラー ブロックチェーンの動きを開始しました。 Polygon Avail は、データの可用性を分離し、データの可用性専用のブロックを使用したチェーンを可能にすることで、モジュール設計をさらに一歩進めます。

現在、Avail のブロック時間は 20 秒で、各ブロックは約 2 MB のデータを保持できます。平均トランザクション サイズが 250 バイトであると仮定すると、各 Polygon Avail ブロックは現在、約 8,400 トランザクション (1 秒あたり 420 トランザクション) を保持できます。

さらに重要なことに、Avail は一貫してストレージ制限までブロックを埋め、必要に応じてサイズを増やすことができます。必要に応じて、ブロックあたり 500,000 トランザクション (1 秒あたり 25,000 トランザクション) を超える数を取得するために、プルできるレバーが多数あります。その多くは非常に迅速です。

スループットを向上させることはできますか?

スループット (具体的には、1 秒あたりのトランザクション数) を増やすには、チェーン アーキテクトはブロック サイズを増やすか、ブロック時間を減らす必要があります。

チェーンに追加するには、各ブロックがコミットメントを生成し、証明を構築し、それらを伝播し、他のすべてのノードに証明を検証させる必要があります。これらの手順には常に時間がかかり、ブロック時間に制限があります。

その結果、ブロック時間を 1 秒程度に短縮することはできません。コミットメントを生成し、証明を生成し、これらの断片をネットワーク全体のすべての参加者に伝達するのに十分な時間はありません。理論上のブロック タイムが 1 秒の場合、すべてのネットワーク参加者がコミットメントとプルーフを瞬時に生成できる最も強力なマシンを実行していたとしても、ボトルネックはデータの伝播です。ネットワークは、インターネット速度の制約により、すべてのフルノードに十分な速度でブロックを通信できません。したがって、コンセンサスに達した後、ネットワーク全体にデータを配布できるように、ブロック時間を十分に長くする必要があります。

代わりに、スループットの向上は、ブロック サイズの増加、つまり各ブロックに含めることができるデータ量の増加によってもたらされます。

現在のアーキテクチャ: チェーンへのブロックの追加

まず、チェーンにブロックを追加するために必要なものを見てみましょう。各ブロックをチェーンに追加するには、主に 3 つの手順が必要です。ブロックを生成し、そのブロックを伝播し、そのブロックを検証するのにかかる時間。

1.ブロック生産

このステップには、Avail トランザクションの収集と注文、コミットメントの構築、およびデータ マトリックスの拡張 (消去コード) にかかる時間が含まれます。

ブロック生成は、常に少なくともある程度の時間がかかるため、ブロックの生成に必要な時間を測定します。その結果、最良の場合の時間だけでなく、さまざまなマシンの平均時間と最悪の場合の時間を考慮する必要があります。

新しいブロックの生成に参加できる最も弱いマシンは、平均ケース時間で容量が最大になるマシンです。低速のマシンはすべて、高速のマシンに追いつくことができないため、必然的に遅れをとることになります。

2. 伝搬遅延

伝播遅延は、プロデューサからバリデータおよびピアツーピア ネットワークにブロックを伝播するのにかかる時間の尺度です。

現在、Avail には 2 MB のブロックがあります。このサイズのブロックは、現在の 20 秒のブロック時間の制約内で伝播できます。ブロック サイズが大きいほど、伝播が難しくなります。

たとえば、Polygon Avail を増やして 128 MB ブロックをサポートする場合、計算はスケーリングできる可能性があります (約 7 秒)。ただし、ボトルネックは、ネットワークを介してこれらのブロックを送信およびダウンロードするのにかかる時間になります。

ピアツーピア ネットワークを介して 128 MB のブロックを 5 秒で世界中に送信することが、現時点で達成できる限界である可能性があります。

128 MB の制限は、データの可用性やコミットメント スキームとは関係なく、むしろ通信帯域幅の制約の問題です。

この伝播遅延を考慮する必要があるため、Polygon Avail の現在の理論上のブロック サイズ制限が得られます。

3.ブロック検証

伝播されると、参加するバリデータは、ブロック提案者から提供されたブロックを単純に信頼するだけではなく、生成されたブロックが実際にデータ プロデューサーの言うことを持っていることを検証する必要があります。

これらの 3 つのステップは、互いに緊張感を与えます。すべてのバリデーターを、同じデータセンター内の優れたネットワークによって緊密に接続された強力なマシンにすることができました。これにより、生産と検証の時間が短縮され、より多くのデータを伝播できるようになります。しかし、さまざまな種類の参加者を持つ分散型の多様なネットワークも必要であるため、これは望ましいアプローチではありません。

代わりに、ブロックをアベイル チェーンに追加するために必要な手順と、最適化できる手順を理解することで、スループットが向上します。

現在、Polygon Avail を使用するバリデーターはブロック全体を取得し、ブロックを検証するために提案者によって生成されたすべてのコミットメントを再現します。これは、上の図のすべてのステップを実行するブロック プロデューサーとすべてのバリデーターの両方に変換されます。

各バリデーターによるこのブロック全体の再作成は、モノリシック ブロックチェーンのデフォルトです。ただし、トランザクションが実行されない Avail のようなチェーンでは必要ありません。結果として、Avail を最適化する方法の 1 つは、バリデーターがブロックの再作成ではなく、サンプリングによってデータの可用性を独自に保証できるようにすることです。これにより、すべてのコミットメントを再現するように求められた場合よりも、バリデーターに必要なリソースが少なくなります。