パフォーマンスとスケーラビリティは、レイヤー 1 プロジェクト (独立したブロックチェーン) とレイヤー 2 ソリューション (ロールアップやオフチェーン チャネルなど) の両方に関連する暗号空間でよく議論される課題です。 しかし、標準化された指標やベンチマークはありません。 多くの場合、数値は一貫性のない不完全な方法で報告されるため、プロジェクトを正確に比較することが難しくなり、実際に最も重要なことを曖昧にすることがよくあります。
パフォーマンスの測定と比較には、より繊細で徹底的なアプローチが必要です。つまり、パフォーマンスを複数のコンポーネントに分解し、複数の軸にわたってトレードオフを比較するアプローチです。 この投稿では、基本的な用語を定義し、課題の概要を説明し、ブロックチェーンのパフォーマンスを評価する際に留意すべきガイドラインと主要な原則を示します。
スケーラビリティとパフォーマンス
まず、スケーラビリティとパフォーマンスという XNUMX つの用語を定義しましょう。これらは、ブロックチェーンのコンテキストで誤用されることが多い標準的なコンピューター サイエンスの意味を持ちます。 性能 システムとは何かを測定する 現在達成可能な. 以下で説明するように、パフォーマンス メトリックには、XNUMX 秒あたりのトランザクション数またはトランザクション確認時間の中央値が含まれる場合があります。 スケーラビリティ、一方、 リソースを追加することによってパフォーマンスを向上させるシステムの能力.
この違いは重要です。パフォーマンスを改善するための多くのアプローチは、適切に定義された場合、スケーラビリティをまったく改善しません。 簡単な例として、Schnorr または ECDSA 署名の約半分のサイズである BLS 署名など、より効率的なデジタル署名方式を使用しています。 ビットコインが ECDSA から BLS に切り替わると、ブロックあたりのトランザクション数が 20 ～ 30% 増加し、一晩でパフォーマンスが向上する可能性があります。 しかし、これを行うことができるのは XNUMX 回だけです — これ以上スペース効率の良い署名スキームに切り替えることはできません (BLS 署名を集約してスペースを節約することもできますが、これは別の XNUMX 回限りのトリックです)。
ブロックチェーンでは、他にも多くの XNUMX 回限りのトリック (SegWit など) が可能ですが、継続的なパフォーマンスの向上を実現するには、スケーラブルなアーキテクチャが必要です。リソースを追加すると、時間の経過とともにパフォーマンスが向上します。 これは、Web サーバーの構築など、他の多くのコンピューター システムでも一般的な通念です。 いくつかの一般的なトリックを使用して、XNUMX つの非常に高速なサーバーを構築できます。 しかし最終的には、サーバーを継続的に追加することで、増え続ける需要に対応できるマルチサーバー アーキテクチャが必要になります。
区別を理解することは、「ブロックチェーン X は非常にスケーラブルで、XNUMX 秒あたり Y トランザクションを処理できる!」などのステートメントに見られる一般的なカテゴリ エラーを回避するのにも役立ちます。 XNUMX 番目の主張は印象的かもしれませんが、 パフォーマンス スケーラビリティ メトリックではありません。 リソースを追加することでパフォーマンスを向上させる能力については言及していません。
スケーラビリティには、本質的に並列処理の活用が必要です。 ブロックチェーン空間では、レイヤー 1 スケーリングにはシャーディングまたはシャーディングに似たものが必要なようです。 シャーディングの基本概念 — 異なるバリデーターが独立して処理できるように状態を分割する — は、スケーラビリティの定義とほぼ一致します。 レイヤー 2 には、オフチェーン チャネル、ロールアップ サーバー、サイドチェーンなど、並列処理を追加できるオプションがさらにあります。
レイテンシとスループット
従来、ブロックチェーン システムのパフォーマンスは、レイテンシとスループットの 1 つの次元で評価されます。レイテンシは、個々のトランザクションを確認できる速さを測定し、スループットは、経時的なトランザクションの総レートを測定します。 これらの軸は、レイヤー 2 システムとレイヤー XNUMX システムの両方に適用されます。また、他の多くの種類のコンピューター システム (データベース クエリ エンジンや Web サーバーなど) にも適用されます。
残念ながら、レイテンシとスループットはどちらも測定と比較が複雑です。 さらに、個々のユーザーは実際にはスループット (システム全体の測定値) を気にしません。 彼らが本当に気にかけているのは、待ち時間と取引手数料です。より具体的には、取引ができるだけ迅速かつ安価に確認されることです。 他の多くのコンピューター システムもコスト/パフォーマンス ベースで評価されますが、トランザクション手数料は、従来のコンピューター システムには実際には存在しない、ブロックチェーン システムのパフォーマンスのやや新しい軸です。
レイテンシの測定における課題
レイテンシーは最初は単純に思えます: トランザクションが承認されるまでにどれくらいの時間がかかりますか? しかし、この質問に答えるには常にいくつかの異なる方法があります。
まず、異なる時点間のレイテンシを測定し、異なる結果を得ることができます。 たとえば、ユーザーがローカルで「送信」ボタンを押したとき、またはトランザクションが mempool にヒットしたときに、レイテンシの測定を開始しますか? そして、トランザクションが提案されたブロックにある場合、またはブロックがXNUMXつまたはXNUMXつのフォローアップブロックで確認された場合、クロックを停止しますか?
最も一般的なアプローチは、バリデーターの観点から、クライアントが最初にトランザクションをブロードキャストした時点から、トランザクションが合理的に「確認」された時点までを測定します (実際の商人が支払いを受け取ったと見なし、商品をリリースするという意味で)。 . もちろん、マーチャントごとに異なる承認基準を適用する場合があり、単一のマーチャントでも取引金額に応じて異なる基準を使用する場合があります。
バリデーター中心のアプローチでは、実際に重要なことがいくつか見落とされています。 まず、ピア ツー ピア ネットワークのレイテンシ (クライアントがトランザクションをブロードキャストしてから、ほとんどのノードがトランザクションを受信するまでにかかる時間) とクライアント側のレイテンシ (トランザクションの準備にかかる時間) を無視します。クライアントのローカルマシン上?) クライアント側のレイテンシーは非常に小さく、Ethereum 支払いの署名などの単純なトランザクションでは予測可能ですが、シールドされた Zcash トランザクションが正しいことを証明するなどのより複雑なケースでは重要になる可能性があります。
レイテンシで測定しようとしている時間枠を標準化したとしても、答えはほとんどの場合 それは場合による. これまでに構築された暗号通貨システムは、固定のトランザクション レイテンシを提供しませんでした。 覚えておくべき基本的な経験則は次のとおりです。
レイテンシは分布であり、単一の数値ではありません。
ネットワーク研究コミュニティは、これを長い間理解してきました (たとえば、この ギル・テネによる優れた講演）。 ディストリビューションの「ロング テール」に特に重点が置かれています。トランザクション (または Web サーバー クエリ) の 0.1% でさえも非常に高いレイテンシーが深刻な影響を与えるためです。 影響 利用者。
ブロックチェーンでは、確認の待ち時間はさまざまな理由で異なります。
バッチ処理: ほとんどのシステムは、たとえばほとんどのレイヤー 1 システムのブロックにトランザクションをバッチ処理します。 これにより、一部のトランザクションはバッチがいっぱいになるまで待機する必要があるため、変動するレイテンシが発生します。 他の人は幸運に恵まれ、最後にバッチに参加するかもしれません. これらのトランザクションはすぐに確認され、追加の遅延は発生しません。
変動する混雑: ほとんどのシステムは輻輳に悩まされています。つまり、システムがすぐに処理できるよりも多くのトランザクションがポストされます (少なくとも一部の時間)。 予測不可能な時間にトランザクションがブロードキャストされると、輻輳の程度が変化する可能性があります (多くの場合、 ポアソン過程) または、新規トランザクションのレートが XNUMX 日または XNUMX 週間を通して変化するとき、または人気のある NFT の発売などの外部イベントに応じて変化するとき。
コンセンサスレイヤーの分散: レイヤー 1 でトランザクションを確認するには、通常、ノードの分散セットがブロックのコンセンサスに達する必要があり、輻輳に関係なくさまざまな遅延が追加される可能性があります。 プルーフ・オブ・ワーク・システムは、予測不可能なタイミングでブロックを見つけます (抽象的にはポアソン過程でもあります)。 プルーフ オブ ステーク システムは、さまざまな遅延を追加することもあります (たとえば、ラウンドで委員会を形成するのに十分な数のノードがオンラインでない場合、またはリーダーのクラッシュに対応してビューの変更が必要な場合)。
これらの理由から、適切なガイドラインは次のとおりです。
待ち時間に関する主張は、平均や中央値のような単一の数値ではなく、確認時間の分布 (またはヒストグラム) を提示する必要があります。
平均、中央値、パーセンタイルなどの要約統計量は部分的な全体像を提供しますが、システムを正確に評価するには分布全体を考慮する必要があります。 一部のアプリケーションでは、レイテンシ分布が比較的単純な場合 (ガウス分布など)、平均レイテンシから適切な洞察が得られます。 しかし、暗号通貨では、このようになることはほとんどありません。通常、確認時間の長いロングテールがあります。
支払いチャネル ネットワーク (Lightning Network など) が良い例です。 古典的な L2 スケーリング ソリューションであるこれらのネットワークは、ほとんどの場合、非常に高速な支払い確認を提供しますが、場合によってはチャネルのリセットが必要になるため、レイテンシが桁違いに増加する可能性があります。
また、正確なレイテンシ分布に関する優れた統計があったとしても、システムとシステムに対する要求が変化するにつれて、それらは時間の経過とともに変化する可能性があります. また、競合するシステム間でレイテンシーの分布を比較する方法も必ずしも明確ではありません。 たとえば、1 ～ 2 分 (平均と中央値は 90 秒) の均一に分散されたレイテンシでトランザクションを確認する 95 つのシステムを考えてみましょう。 競合するシステムがトランザクションの 1% を 5 分間で正確に確認し、残りの 11% を 90 分で確認する場合 (平均 60 秒、中央値 XNUMX 秒)、どのシステムが優れていますか? 答えはおそらく、前者を好むアプリケーションもあれば、後者を好むアプリケーションもあるということです。
最後に、ほとんどのシステムでは、すべてのトランザクションが均等に優先されるわけではないことに注意することが重要です。 ユーザーは、より高い優先度の包含を取得するために、より多くの料金を支払うことができます。したがって、上記のすべてに加えて、遅延は、支払われたトランザクション料金の関数として変化します。 要約すれば：
レイテンシーは複雑です。 報告されるデータが多ければ多いほど良い。 理想的には、さまざまな輻輳条件の下で完全なレイテンシ分布を測定する必要があります。 さまざまなコンポーネント (ローカル、ネットワーク、バッチ処理、コンセンサス遅延) へのレイテンシの内訳も役立ちます。
スループット測定における課題
スループットも一見単純に見えます。システムが XNUMX 秒間に処理できるトランザクションの数は? XNUMX つの主な問題が生じます。「トランザクション」とは正確には何なのか、システムが現在何を行っているのか、それとも何ができる可能性があるのかを測定しているのか?
「XNUMX 秒あたりのトランザクション数」(または tps) は、ブロックチェーンのパフォーマンスを測定するためのデファクト スタンダードですが、トランザクションは測定単位としては問題があります。 汎用のプログラマビリティ (「スマート コントラクト」) を提供するシステム、またはビットコインのマルチプレックス トランザクションやマルチシグ検証のオプションなどの限定された機能を提供するシステムの場合、基本的な問題は次のとおりです。
すべてのトランザクションが同じというわけではありません。
これは、トランザクションが任意のコードを含み、状態を任意に変更できるイーサリアムに明らかに当てはまります。 イーサリアムのガスの概念は、トランザクションが実行する全体的な作業量を定量化 (および料金を請求) するために使用されますが、これは EVM 実行環境に非常に固有のものです。 一連の EVM トランザクションによって実行される総作業量を、たとえば BPF 環境を使用する一連の Solana トランザクションと比較する簡単な方法はありません。 いずれかを一連のビットコイン トランザクションと比較することは、同様に困難を伴います。
トランザクション層をコンセンサス層と実行層に分離するブロックチェーンは、これをより明確にすることができます。 (純粋な) コンセンサス層では、単位時間あたりにチェーンに追加されたバイト数でスループットを測定できます。 実行層は常により複雑になります。
支払いトランザクションのみをサポートするロールアップ サーバーなどのより単純な実行レイヤーは、計算の定量化の難しさを回避します。 ただし、この場合でも、支払いは入力と出力の数によって異なります。 支払いチャネル トランザクションは、スループットに影響を与える必要な「ホップ」の数が異なる場合があります。 また、ロールアップ サーバーのスループットは、トランザクションのバッチをより小さな一連のサマリー変更に「差し引く」ことができる程度に依存する可能性があります。
スループットに関するもう XNUMX つの課題は、現在のパフォーマンスを経験的に測定して理論上の容量を評価するだけではありません。 これにより、潜在的な容量を評価するためのあらゆる種類のモデリングの質問が導入されます。 まず、実行レイヤーの現実的なトランザクション ワークロードを決定する必要があります。 第二に、実際のシステム、特にブロックチェーン システムが理論上の容量を達成することはほとんどありません。 堅牢性の理由から、ノードの実装が実際には異種で多様であることを願っています (すべてのクライアントが単一のソフトウェア実装を実行するのではなく)。 これにより、ブロックチェーンのスループットを正確にシミュレーションすることがさらに困難になります。
全体：
スループットを主張するには、トランザクションのワークロードとバリデーターの数 (数量、実装、ネットワーク接続) を注意深く説明する必要があります。 明確な標準がない場合は、イーサリアムのような人気のあるネットワークからの歴史的なワークロードで十分です。
レイテンシとスループットのトレードオフ
通常、レイテンシとスループットはトレードオフの関係にあります。 として Lefteris Kokoris-Kogias の概要、このトレードオフはスムーズではないことが多く、システム負荷が最大スループットに近づくにつれてレイテンシが急激に上昇する変曲点があります。
ゼロ知識ロールアップ システムは、スループットとレイテンシのトレードオフの自然な例を示しています。 トランザクションのバッチが大きいと、証明時間が長くなり、レイテンシが増加します。 しかし、オンチェーンのフットプリントは、プルーフ サイズと検証コストの両方の点で、より大きなバッチ サイズでより多くのトランザクションに償却され、スループットが向上します。
取引手数料
当然のことながら、エンド ユーザーはレイテンシと 手数料、レイテンシーとスループットではありません。 ユーザーがスループットを気にする直接的な理由はまったくなく、可能な限り低い手数料でトランザクションを迅速に確認できるという理由だけです (手数料を重視するユーザーもいれば、レイテンシを重視するユーザーもいます)。 大まかに言うと、手数料は複数の要因の影響を受けます。
- 取引を行うための市場の需要はどれくらいありますか?
- システムによって達成される全体的なスループットは?
- システムがバリデーターまたはマイナーに提供する全体的な収益はいくらですか?
- この収益のうち、トランザクション手数料とインフレ報酬に基づいているのはどれくらいですか?
最初の XNUMX つの要因は、大まかに言うと、市場クリアリング価格につながる需要/供給曲線です (ただし、 マイナーはカルテルとして行動し、このポイントを超えて料金を引き上げます）。 他のすべてが同じであれば、スループットが高いほど料金が低くなる傾向がありますが、さらに多くのことが起こっています.
特に、上記のポイント 3 と 4 は、ブロックチェーン システム設計の基本的な問題ですが、いずれについても優れた原則がありません。 インフレ報酬と取引手数料からマイナーに収益を与えることの長所と短所については、ある程度理解しています。 しかし、ブロックチェーンコンセンサスプロトコルの多くの経済分析にもかかわらず、バリデーターにどれだけの収益が必要かについて広く受け入れられているモデルはまだありません. 今日、ほとんどのシステムは、システムの実際の使用を妨げることなく、バリデーターが正直に行動し続けるのに十分な収益がどれくらいあるかについて、経験に基づいた推測を構築しています。 単純化されたモデルでは、 51% の攻撃を仕掛けるコストは、バリデーターへの報酬に比例することが示されています。.
攻撃のコストを上げることは良いことですが、どの程度のセキュリティが「十分」かはわかりません。 50 つの遊園地に行くことを考えているとします。 そのうちの XNUMX つは、他のものよりも乗り物のメンテナンスに費やす費用が XNUMX% 少ないと主張しています。 この公園に行くのは良い考えですか。 それらはより効率的であり、より少ない費用で同等の安全性を得ている可能性があります. もう XNUMX つは、乗り物を安全に保つために必要以上の費用を費やしている可能性があります。 しかし、最初の公園が危険な場合もあります。 ブロックチェーンシステムも同様です。 スループットを考慮に入れると、手数料の低いブロックチェーンは、バリデーターへの報酬が少ない (したがってインセンティブが与えられる) ため、手数料が低くなります。 現在、これが問題ないかどうか、またはシステムが攻撃に対して脆弱になるかどうかを評価するための優れたツールはありません。 全体：
システム間で料金を比較すると、誤解を招く可能性があります。 取引手数料はユーザーにとって重要ですが、システム設計自体以外の多くの要因の影響を受けます。 スループットは、システム全体を分析するための優れた指標です。
まとめ
パフォーマンスを公正かつ正確に評価することは困難です。 これは、車のパフォーマンスを測定する場合にも当てはまります。 ブロックチェーンと同じように、人によって関心が異なります。 車の場合、最高速度や加速を気にするユーザーもいれば、燃費を気にするユーザーもいれば、けん引能力を気にするユーザーもいます。 これらのすべてを評価するのは自明ではありません。 たとえば、米国では、環境保護庁が燃費の評価方法と、ディーラーでのユーザーへの提示方法に関する詳細なガイドラインを維持しています。
ブロックチェーン空間は、このレベルの標準化からはほど遠い. 特定の領域では、システムのスループットを評価するための標準化されたワークロードや、レイテンシーの分布を示すための標準化されたグラフを使用して、将来そこに到達する可能性があります。 当面の間、評価者とビルダーにとって最善のアプローチは、評価方法論の詳細な説明とともに、できるだけ多くのデータを収集して公開することです。これにより、データを再現して他のシステムと比較できるようになります。
