ユーザーが Avail をチェーン設計に統合し始めると、よく疑問が生じます:「Avail はどれくらいのトランザクションを処理できますか?」 この記事では、2 つのチェーンの現在のアーキテクチャに基づいて Ethereum と Avail を比較します。
これは、Avail のスケーラビリティに関する一連の記事の最初の記事であり、Avail の現在のパフォーマンスと、短期的および長期的に拡張する能力について説明します。
Avail vs Ethereum
イーサリアムのブロックは最大 1.875 MB のデータを保持でき、ブロック時間は約 13 秒です。ただし、イーサリアムのブロックは通常は埋められません。実行・決済ともにガスを消費するため、ほぼすべてのブロックがガス制限に達してデータの上限に達することはありません。したがって、各ブロックに格納されるデータの量は変化します。
実行、決済、データの可用性を同じブロック内で組み合わせる必要性は、単一のブロックチェーン アーキテクチャの中核的な問題です。 L2 ロールアップはモジュラー ブロックチェーンへの動きを開始し、実行専用のチェーンのブロックを備えた別のチェーンで実行操作を処理できるようになりました。 Avail はさらに、データの可用性を分離するモジュラー設計を採用しており、チェーンのブロックをデータの可用性専用にできるようにしています。
現在、Avail のブロック時間は 20 秒で、各ブロックは約 2 MB のデータを保持できます。平均トランザクション サイズを 250 バイトと仮定すると、現在、各 Avail ブロックは約 8,400 トランザクション (1 秒あたり 420 トランザクション) に対応できます。
さらに、Avail は常にストレージ制限までブロックを埋め、必要に応じてサイズを増やすことができます。必要に応じて、ブロックあたりのトランザクション数を 500,000 (1 秒あたり 25,000 トランザクション) 以上に増やすためにすぐに調整できるレバーを多数用意しています。
スループットを向上させることはできますか?
スループット (特に 1 秒あたりのトランザクション) を増やすには、チェーンの設計者はブロック サイズを増やすか、ブロック時間を短縮する必要があります。
チェーンに追加するには、各ブロックがコミットメントを生成し、証明を構築し、伝播し、これらの証明を他のすべてのノードで検証する必要があります。これらの手順には常に時間がかかるため、ブロックの生成と確認にかかる時間には自然な上限が生じます。
したがって、ブロック時間を単純にたとえば 1 秒に短縮することはできません。これでは、コミットメントを生成し、証明を生成し、これらの部分をネットワーク全体のすべての参加者に伝播するのに十分な時間が取れません。理論上の 1 秒のブロック時間では、すべてのネットワーク参加者がコミットメントとプルーフを瞬時に生成できる最も強力なマシンを実行している場合でも、ボトルネックはデータの伝播です。インターネット速度の制限により、ネットワークはすべての完全なノードに十分な速度でブロックを通知できません。したがって、合意に達した後にデータをネットワークに配信できるように、ブロック時間が十分に長いことを確認する必要があります。
逆に、ブロック サイズを増やすことによって、つまりブロックごとに含めることができるデータ量を増やすことによって、スループットを向上させることもできます。
現在のアーキテクチャ: チェーンへのブロックの追加
まず、チェーンにブロックを追加するために必要な手順を見てみましょう。各ブロックをチェーンに追加するには、主に 3 つの手順が必要です。これには、ブロックの生成、ブロックの伝播、およびブロックの検証にかかる時間が含まれます。
1. ブロック生成
このステップには、Avail トランザクションの収集と並べ替え、コミットメントの構築、およびデータ マトリックスの拡張 (コードの消去) に必要な時間が含まれます。
ブロックの生成には、常に少なくともある程度の時間がかかるため、ブロックの生成にかかる時間を測定します。したがって、さまざまなマシンでの最良の場合の時間だけでなく、平均的な場合と最悪の場合の時間も考慮する必要があります。
新しいブロックの生成に参加できる最も弱いマシンは、平均的な状況下でパフォーマンスの限界に達するマシンです。遅いマシンはすべて、より速いマシンに追いつくことができないため、最終的には後れを取ることになります。
2. 伝播遅延
伝播レイテンシーは、プロデューサーからバリデーターおよびピアツーピア ネットワークにブロックを伝播するのにかかる時間の尺度です。
現在、Avail のブロック サイズは 2 MB です。現在のブロック時間制限である 20 秒内では、このようなブロック サイズを伝播できます。ブロック サイズが大きくなると、伝播が難しくなります。
たとえば、128 MB ブロックをサポートするように Avail を増やすと、計算が拡張される可能性があります (約 7 秒)。ただし、これらのブロックをネットワーク上で送信およびダウンロードするのに必要な時間がボトルネックになります。
128 MB のブロックをピアツーピア ネットワーク経由で 5 秒以内に世界中に送信するのが、おそらく現在達成可能な限界です。
128 MB の制限は、データの可用性やコミットメント プランとは関係ありませんが、通信帯域幅の制限の問題です。
この伝播遅延を考慮する必要があるため、Avail の現在の理論上のブロック サイズ制限が決まります。
3. ブロック検証
伝播されると、参加するバリデーターは、ブロック提案者によって提供されたブロックを単に信頼するだけではなく、生成されたブロックにプロデューサーが要求したデータが実際に含まれていることを検証する必要があります。
これら 3 つのステップの間には一定の緊張感があります。すべてのバリデーターを強力なマシンにし、同じデータセンター内の優れたネットワークで緊密に接続することができます。これにより、生産と検証の時間が短縮され、より大量のデータを拡散できるようになります。ただし、さまざまなタイプの参加者が参加する分散型で多様なネットワークも必要としているため、これは理想的なアプローチではありません。
代わりに、Avail チェーンにブロックを追加するために必要な手順と、どの手順を最適化できるかを理解することで、スループットの向上が実現されます。
現在、Avail を使用するバリデーターはブロック全体を取得し、プロポーザーによって生成されたすべてのコミットメントをコピーしてブロックを検証します。これは、ブロックプロデューサーとすべてのバリデーターが上の図の各ステップを実行する必要があることを意味します。
単一のブロックチェーンでは、各バリデーターがブロック全体を再構築するのがデフォルトの方法です。ただし、トランザクションが実行されない Avail のようなチェーンでは、この再構築は必要ありません。したがって、Avail を最適化する 1 つの方法は、バリデーターがブロックを再構築するのではなく、サンプリングを通じてデータの可用性を独自に保証できるようにすることです。これは、バリデーターにすべてのコミットメントを複製することを要求するよりも、バリデーターに要求するリソースが少なくなります。関連コンテンツは今後の記事で紹介していきます。
Discovery Data Availability Sampling はどのように機能しますか?
Avail では、ライト クライアントは、サンプル、コミットメント、証明書という 3 つのコア ツールを使用してデータの可用性を確認します。
現在、ライト クライアントはサンプル操作を実行し、特定のセルの値とそれに関連付けられた有効性証明書を Avail ネットワークに要求します。収集するサンプルが多ければ多いほど、すべてのデータが利用可能であるという確信が高まります。
コミットメントはブロック提案者によって生成され、Avail ブロック内のデータ行全体を要約します。 (ヒント: これは、このシリーズの後半で最適化するステップです。)
ネットワーク内のすべてのセルが証明を生成します。ライト クライアントは、証明と約束を使用して、提供されたセルの値が正しいことを検証します。
これらのツールを使用して、ライト クライアントは 3 つのステップを実行します。
決定: 必要な可用性の信頼度により、ライト クライアントによって実行されるサンプルの数が決まります。 99.95% 以上の可用性保証を達成するために、多くのサンプル (8 ～ 30 サンプル) は必要ありません。
ダウンロード: ライト クライアントは、これらのサンプルとそれに関連するプルーフを要求し、ネットワーク (フル ノードまたは他のライト クライアント) からダウンロードします。
検証: ブロック ヘッダー (ライト クライアントは常にアクセス可能) 内のコミットメントを確認し、コミットメントに対する各セルの証明を検証します。
これだけで、ライト クライアントは、ブロックのコンテンツの大部分をダウンロードすることなく、ブロック内のすべてのデータの可用性を確認できます。ライト クライアントによって実行される追加の手順も Avail のセキュリティに貢献しますが、ここには記載されていません。たとえば、ライト クライアントは、必要に応じて、ダウンロードしたサンプルやプルーフを他のライト クライアントと共有できます。しかし、これはライト クライアントがデータの可用性を確認する方法です。
このシリーズの第 2 部では、Avail のスループットを短期的に向上させる方法を見ていきます。アベイルが今後 1 年間あらゆるネットワークのニーズに対応できると考える理由と、今後数年間の課題に対処するためにネットワークをどのように改善できるかについて説明します。
