! [DAのスケーラビリティ:アベイルズの現在の状態] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-d4e2f4e2b4-dd1a6f-cd5cc0)ユーザーが Avail をチェーン設計に統合し始めると、「Avail はいくつのトランザクションを処理できるのか」という疑問がしばしば生じます。 この投稿では、イーサリアムとアベイルのスループットを、2つのチェーンの現在のアーキテクチャに基づいて比較します。これは、Availのスケーラビリティに関するシリーズの第1弾であり、Availの現在のパフォーマンスと、短期的および長期的な拡張能力について説明します。## アベイル vs イーサリアムイーサリアムのブロックは最大1.875MBのデータを保持でき、ブロック時間は約13秒です。 しかし、イーサリアムのブロックは通常、埋まっていません。 ほとんどすべてのブロックは、実行と決済の両方がガスを消費するため、ガス制限に達するため、データの上限に達しません。 その結果、各ブロックに格納されるデータの量は変動します。実行、決済、データの可用性を同じブロックに統合する必要性は、単一のブロックチェーンアーキテクチャの中心的な問題です。 L2ロールアップは、実行操作を単一のチェーンで処理できるようにし、チェーンのブロックが実行専用になるモジュラーブロックチェーンの動きを開始しました。 Availは、データの可用性を切り離すモジュール設計を採用することでさらに一歩進んでおり、チェーンのブロックをデータの可用性専用にすることができます。! [DAのスケーラビリティ:アベイルズの現在の状態] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-60a64e927d-dd1a6f-cd5cc0)現在、アベイルズのブロックタイムは20秒で、各ブロックは約2MBのデータを保持できます。 平均トランザクション サイズを 250 バイトと仮定すると、各 Avail ブロックは、現在約 8, 400 トランザクション (毎秒 420 トランザクション) を保持できます。さらに、Availはいつでもストレージ制限までブロックを埋め、必要に応じてサイズを増やすことができます。 必要に応じて、ブロックあたりのトランザクション数を500、000(毎秒25、000トランザクション)以上に増やすために迅速に調整できるレバーがいくつかあります。## スループットを上げることはできるか?スループット(特に1秒あたりのトランザクション数)を向上させるためには、チェーンのアーキテクトはブロックサイズを増やすか、ブロック時間を短くする必要があります。チェーンに追加するには、各ブロックがコミットメントを生成し、証明を構築し、それらを伝播し、他のすべてのノードにそれらの証明を検証させる必要があります。 これらの手順には常に時間がかかるため、ブロックの生成と確認にかかる時間に自然な上限が設定されます。したがって、ブロック時間を単純に1秒に短縮することはできません。 これでは、コミットメントを生成し、証明を生成し、それらの部分をネットワーク全体のすべての参加者に伝播するのに十分な時間がありません。 理論上の1秒のブロック時間では、各ネットワーク参加者がコミットメントとプルーフを瞬時に生成できる最も強力なマシンを実行したとしても、ボトルネックはデータの伝播にあります。 インターネットの速度制限により、ネットワークはすべてのフルノードに十分な速さでブロックを通知することができません。 そのため、コンセンサスに達した後にデータをネットワークに配信できるように、ブロック時間が十分に長いことを確認する必要があります。逆に、ブロックサイズを大きくすること、つまり各ブロックに含めることができるデータ量を増やすことで、スループットを向上させることもできます。## 現在のアーキテクチャ: チェーンにブロックを追加するまず、チェーンにブロックを追加するために必要な手順を見てみましょう。 各ブロックをチェーンに追加するには、主に3つのステップが必要です。 これには、ブロックの生成、伝播、検証にかかる時間が含まれます。! [DAのスケーラビリティ:アベイルズの現在の状態] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-8d735187bc-dd1a6f-cd5cc0)### 1. ブロック生成このステップには、Avail トランザクションの収集とソート、コミットメントの構築、およびデータ マトリックスのスケーリング (イレイジャー コーディング) にかかる時間が含まれます。ブロック生成は、ブロックの生成にかかる時間を測定します。 したがって、最良の場合の時間だけでなく、さまざまなマシンでの平均状況と最悪の場合の時間も考慮に入れる必要があります。新しいブロックの生成に参加できる最も弱いマシンは、平均してパフォーマンスの限界に達するマシンです。 遅いマシンは、速いマシンに追いつくことができないため、最終的には遅れをとってしまいます。### 2. 伝搬遅延伝播遅延は、プロデューサからバリデーター、ピアツーピアネットワークにブロックを伝播するのにかかる時間の尺度です。現在、アベイルズのブロックサイズは2MBです。 現在の 20 秒のブロック時間制限内で、このようなブロック サイズを伝搬できます。 ブロックサイズが大きいほど、伝搬が難しくなります。たとえば、128 MB のブロックをサポートするように Avail を増やすと、計算をスケーリングできる可能性があります (約 7 秒)。 ただし、ボトルネックは、ネットワーク上でこれらのブロックを送信およびダウンロードするのにかかる時間になります。128 MB のブロックを 5 秒でピアツーピア ネットワーク経由で地球に送信するのは、現在達成可能なことの限界かもしれません。128 MB の制限は、データの可用性やコミットメント シナリオとは関係なく、通信帯域幅の制限の問題です。伝播のレイテンシーを考慮する必要があるため、Availの現在の理論上のブロックサイズ制限が生じます。### 3. ブロック検証一旦伝播されると、参加するバリデータは、ブロック提案者から提供されたブロックを単に信頼するだけでなく、生成されたブロックにプロデューサーが主張するデータが実際に含まれていることを確認する必要があります。この3つのステップの間には、ある種の緊張感があります。 すべてのバリデーターを強力なマシンにし、同じデータセンター内の優れたネットワークで緊密に接続することで、生産と検証の時間を短縮し、より多くのデータを広めることができます。 しかし、さまざまなタイプの参加者が集まる分散型の多様なネットワークも必要であるため、これは理想的なアプローチではありません。代わりに、スループットの向上は、アベイルズチェーンにブロックを追加するために必要な手順と、最適化できる手順を理解することで達成されます。! [DAのスケーラビリティ:アベイルズの現在の状態] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-1d534dd1ad-dd1a6f-cd5cc0)現在、アベイルズを使用するバリデーターは、ブロック全体を取得し、提案者が生成したすべてのコミットメントをコピーしてブロックを検証します。 つまり、ブロックプロデューサーとすべてのバリデーターは、上のチャートの各ステップを実行する必要があります。単一のブロックチェーンでは、各バリデーターがブロック全体を再構築するのがデフォルトの方法です。 ただし、トランザクションが実行されないAvailのようなチェーンでは、この再構築は必要ありません。 したがって、Avail を最適化する方法の 1 つは、バリデーターがブロックを再構築するのではなく、サンプリングを通じてデータの可用性を独自に保証できるようにすることです。 これは、バリデーターがすべてのコミットメントを複製することを要求するよりも、バリデーターにとってリソースを消費しません。 これについては、今後の記事で詳しく説明します。## 探索的データ可用性サンプリングのしくみAvailでは、ライトクライアントは、サンプル、コミットメント、配達確認の3つのコアツールを使用してデータの可用性を確認します。* 現在、ライト クライアントは、特定のセルの値とそれに関連する有効性の証明を Avail ネットワークに要求するサンプル操作を実行します。 サンプル数が多いほど、すべてのデータが入手可能であるという確信が高まります。* コミットメントはブロック提案者によって生成され、Avail ブロック内のデータの行全体を要約します。 (ヒント: これは、このシリーズの後半で最適化するステップです。 ）* ネットワーク内の各セルは証明を生成します。 ライトクライアントは、構成証明と promise を使用して、提供されたセルの値が正しいことを確認します。これらのツールを使用して、ライトクライアントは 3 つの手順を実行します。* 決定事項: 必要な可用性の信頼度によって、ライト クライアント実行のサンプル数が決まります。 99.95%以上の可用性を保証するために、多くのサンプル(8〜30サンプル)は必要ありません。* ダウンロード:ライトクライアントは、これらのサンプルとそれに関連するプルーフを要求し、ネットワーク(フルノードまたは他のライトクライアント)からダウンロードします。* 検証: ブロックヘッダーの promise (ライトクライアントから常にアクセス可能) を見て、各セルの証明を promise に照らして検証します。これだけで、ライトクライアントは、ブロックの内容のほとんどをダウンロードすることなく、ブロック内のすべてのデータの可用性を確認できます。 ライトクライアントが実行するその他の手順もアベイルのセキュリティに貢献しますが、ここには記載されていません。 たとえば、ライトクライアントは、必要に応じて、ダウンロードしたサンプルと配達確認を他のライトクライアントと共有できます。 しかし、これはライトクライアントがデータの可用性を確認するための手順です。このシリーズの第 2 部では、短期的に Avail のスループットを向上させる方法を探ります。 アベイルが来年、あらゆるネットワークのニーズを満たすことができると信じている理由と、今後数年間の課題に対応するためにネットワークをどのように改善できるかを説明します。
DAのスケーラビリティ:アベイルズの現在の状態
! [DAのスケーラビリティ:アベイルズの現在の状態] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d4e2f4e2b4-dd1a6f-cd5cc0.webp)
ユーザーが Avail をチェーン設計に統合し始めると、「Avail はいくつのトランザクションを処理できるのか」という疑問がしばしば生じます。 この投稿では、イーサリアムとアベイルのスループットを、2つのチェーンの現在のアーキテクチャに基づいて比較します。
これは、Availのスケーラビリティに関するシリーズの第1弾であり、Availの現在のパフォーマンスと、短期的および長期的な拡張能力について説明します。
アベイル vs イーサリアム
イーサリアムのブロックは最大1.875MBのデータを保持でき、ブロック時間は約13秒です。 しかし、イーサリアムのブロックは通常、埋まっていません。 ほとんどすべてのブロックは、実行と決済の両方がガスを消費するため、ガス制限に達するため、データの上限に達しません。 その結果、各ブロックに格納されるデータの量は変動します。
実行、決済、データの可用性を同じブロックに統合する必要性は、単一のブロックチェーンアーキテクチャの中心的な問題です。 L2ロールアップは、実行操作を単一のチェーンで処理できるようにし、チェーンのブロックが実行専用になるモジュラーブロックチェーンの動きを開始しました。 Availは、データの可用性を切り離すモジュール設計を採用することでさらに一歩進んでおり、チェーンのブロックをデータの可用性専用にすることができます。
! [DAのスケーラビリティ:アベイルズの現在の状態] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-60a64e927d-dd1a6f-cd5cc0.webp)
現在、アベイルズのブロックタイムは20秒で、各ブロックは約2MBのデータを保持できます。 平均トランザクション サイズを 250 バイトと仮定すると、各 Avail ブロックは、現在約 8, 400 トランザクション (毎秒 420 トランザクション) を保持できます。
さらに、Availはいつでもストレージ制限までブロックを埋め、必要に応じてサイズを増やすことができます。 必要に応じて、ブロックあたりのトランザクション数を500、000(毎秒25、000トランザクション)以上に増やすために迅速に調整できるレバーがいくつかあります。
スループットを上げることはできるか?
スループット(特に1秒あたりのトランザクション数)を向上させるためには、チェーンのアーキテクトはブロックサイズを増やすか、ブロック時間を短くする必要があります。
チェーンに追加するには、各ブロックがコミットメントを生成し、証明を構築し、それらを伝播し、他のすべてのノードにそれらの証明を検証させる必要があります。 これらの手順には常に時間がかかるため、ブロックの生成と確認にかかる時間に自然な上限が設定されます。
したがって、ブロック時間を単純に1秒に短縮することはできません。 これでは、コミットメントを生成し、証明を生成し、それらの部分をネットワーク全体のすべての参加者に伝播するのに十分な時間がありません。 理論上の1秒のブロック時間では、各ネットワーク参加者がコミットメントとプルーフを瞬時に生成できる最も強力なマシンを実行したとしても、ボトルネックはデータの伝播にあります。 インターネットの速度制限により、ネットワークはすべてのフルノードに十分な速さでブロックを通知することができません。 そのため、コンセンサスに達した後にデータをネットワークに配信できるように、ブロック時間が十分に長いことを確認する必要があります。
逆に、ブロックサイズを大きくすること、つまり各ブロックに含めることができるデータ量を増やすことで、スループットを向上させることもできます。
現在のアーキテクチャ: チェーンにブロックを追加する
まず、チェーンにブロックを追加するために必要な手順を見てみましょう。 各ブロックをチェーンに追加するには、主に3つのステップが必要です。 これには、ブロックの生成、伝播、検証にかかる時間が含まれます。
! [DAのスケーラビリティ:アベイルズの現在の状態] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-8d735187bc-dd1a6f-cd5cc0.webp)
1. ブロック生成
このステップには、Avail トランザクションの収集とソート、コミットメントの構築、およびデータ マトリックスのスケーリング (イレイジャー コーディング) にかかる時間が含まれます。
ブロック生成は、ブロックの生成にかかる時間を測定します。 したがって、最良の場合の時間だけでなく、さまざまなマシンでの平均状況と最悪の場合の時間も考慮に入れる必要があります。
新しいブロックの生成に参加できる最も弱いマシンは、平均してパフォーマンスの限界に達するマシンです。 遅いマシンは、速いマシンに追いつくことができないため、最終的には遅れをとってしまいます。
2. 伝搬遅延
伝播遅延は、プロデューサからバリデーター、ピアツーピアネットワークにブロックを伝播するのにかかる時間の尺度です。
現在、アベイルズのブロックサイズは2MBです。 現在の 20 秒のブロック時間制限内で、このようなブロック サイズを伝搬できます。 ブロックサイズが大きいほど、伝搬が難しくなります。
たとえば、128 MB のブロックをサポートするように Avail を増やすと、計算をスケーリングできる可能性があります (約 7 秒)。 ただし、ボトルネックは、ネットワーク上でこれらのブロックを送信およびダウンロードするのにかかる時間になります。
128 MB のブロックを 5 秒でピアツーピア ネットワーク経由で地球に送信するのは、現在達成可能なことの限界かもしれません。
128 MB の制限は、データの可用性やコミットメント シナリオとは関係なく、通信帯域幅の制限の問題です。
伝播のレイテンシーを考慮する必要があるため、Availの現在の理論上のブロックサイズ制限が生じます。
3. ブロック検証
一旦伝播されると、参加するバリデータは、ブロック提案者から提供されたブロックを単に信頼するだけでなく、生成されたブロックにプロデューサーが主張するデータが実際に含まれていることを確認する必要があります。
この3つのステップの間には、ある種の緊張感があります。 すべてのバリデーターを強力なマシンにし、同じデータセンター内の優れたネットワークで緊密に接続することで、生産と検証の時間を短縮し、より多くのデータを広めることができます。 しかし、さまざまなタイプの参加者が集まる分散型の多様なネットワークも必要であるため、これは理想的なアプローチではありません。
代わりに、スループットの向上は、アベイルズチェーンにブロックを追加するために必要な手順と、最適化できる手順を理解することで達成されます。
! [DAのスケーラビリティ:アベイルズの現在の状態] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-1d534dd1ad-dd1a6f-cd5cc0.webp)
現在、アベイルズを使用するバリデーターは、ブロック全体を取得し、提案者が生成したすべてのコミットメントをコピーしてブロックを検証します。 つまり、ブロックプロデューサーとすべてのバリデーターは、上のチャートの各ステップを実行する必要があります。
単一のブロックチェーンでは、各バリデーターがブロック全体を再構築するのがデフォルトの方法です。 ただし、トランザクションが実行されないAvailのようなチェーンでは、この再構築は必要ありません。 したがって、Avail を最適化する方法の 1 つは、バリデーターがブロックを再構築するのではなく、サンプリングを通じてデータの可用性を独自に保証できるようにすることです。 これは、バリデーターがすべてのコミットメントを複製することを要求するよりも、バリデーターにとってリソースを消費しません。 これについては、今後の記事で詳しく説明します。
探索的データ可用性サンプリングのしくみ
Availでは、ライトクライアントは、サンプル、コミットメント、配達確認の3つのコアツールを使用してデータの可用性を確認します。
これらのツールを使用して、ライトクライアントは 3 つの手順を実行します。
これだけで、ライトクライアントは、ブロックの内容のほとんどをダウンロードすることなく、ブロック内のすべてのデータの可用性を確認できます。 ライトクライアントが実行するその他の手順もアベイルのセキュリティに貢献しますが、ここには記載されていません。 たとえば、ライトクライアントは、必要に応じて、ダウンロードしたサンプルと配達確認を他のライトクライアントと共有できます。 しかし、これはライトクライアントがデータの可用性を確認するための手順です。
このシリーズの第 2 部では、短期的に Avail のスループットを向上させる方法を探ります。 アベイルが来年、あらゆるネットワークのニーズを満たすことができると信じている理由と、今後数年間の課題に対応するためにネットワークをどのように改善できるかを説明します。