A16z: ブロックチェーンのパフォーマンスを測定するのはなぜ難しいのですか?

原文: https://a16zcrypto.com/why-blockchain-performance-is-hard-to-measure/

ジョゼフ・ボノー著

パフォーマンスとスケーラビリティは、暗号通貨分野でよく議論される課題であり、レイヤー 1 プロジェクト (スタンドアロン ブロックチェーン) と、ロールアップやオフチェーン チャネルなどのレイヤー 2 ソリューションの両方に関連します。ただし、標準化された指標やベンチマークはありません。数値は一貫性がなく不完全に報告されることが多く、プロジェクトの正確な比較が困難になり、実際に何が最も重要であるかが曖昧になることがよくあります。

パフォーマンスの測定と比較には、より詳細で徹底的なアプローチ、つまりパフォーマンスをコンポーネントに分割し、それらを複数の軸に沿ったトレードオフで比較するアプローチが必要です。この投稿では、基本的な用語を定義し、課題の概要を説明し、ブロックチェーンのパフォーマンスを評価する際に留意すべきガイドラインと重要な原則を提供します。

スケーラビリティとパフォーマンス

まず、スケーラビリティとパフォーマンスという 2 つの用語を定義しましょう。これらは標準的なコンピュータ サイエンスの意味を持ち、ブロックチェーンのコンテキストで誤用されることがよくあります。パフォーマンスは、システムが現在達成できることを測定します。以下で説明するように、パフォーマンス メトリクスには、1 秒あたりのトランザクション数やトランザクション確認時間の中央値が含まれる場合があります。一方、スケーラビリティは、リソースを追加してパフォーマンスを向上させるシステムの能力を測定します。

この区別は重要です。明確に定義されている場合、パフォーマンスを向上させる多くの方法はスケーラビリティをまったく向上させません。簡単な例としては、Schnorr 署名や ECDSA 署名の約半分のサイズである BLS 署名など、より効率的なデジタル署名スキームを使用することが挙げられます。ビットコインが ECDSA から BLS に切り替わった場合、ブロックあたりのトランザクション数は 20 ～ 30% 増加し、一夜にしてパフォーマンスが向上する可能性があります。しかし、これを実行できるのは 1 回だけです。これ以上、スペース効率の高い署名スキームを切り替えることはできません (スペースを節約するために BLS 署名を集約することもできますが、これは 1 回限りのトリックです)。

ブロックチェーンでは、他の多くの単発トリック (Segregated Witness など) が可能ですが、継続的なパフォーマンス向上を達成するには、リソースを追加することで時間の経過とともにパフォーマンスが向上する、スケーラブルなアーキテクチャが必要です。これは、Web サーバーの構築など、他の多くのコンピューター システムでも常識です。いくつかの一般的なテクニックを使えば、非常に高速なサーバーを構築できますが、最終的には、増大する需要に対応するためにサーバーを追加し続けるマルチサーバー アーキテクチャが必要になります。

この違いを理解すると、「ブロックチェーン X は拡張性が高く、1 秒あたり Y 個のトランザクションを処理できます!」などのステートメントに見られる一般的なクラス エラーを回避するのにも役立ちます。 2 番目のステートメントは印象的かもしれませんが、これはパフォーマンスの指標であり、スケーラビリティの指標ではありません。リソースを追加することでパフォーマンスを向上させる機能は考慮されていません。

スケーラビリティには本質的に並列処理の活用が必要です。ブロックチェーン空間では、レイヤー 1 のスケーリングにはシャーディング、またはシャーディングに似たものが必要なようです。シャーディングの基本概念 (状態をチャンクに分割して、さまざまなバリデーターが個別に処理できるようにする) は、スケーラビリティの定義によく適合します。レイヤ 2 には、オフチェーン チャネル、ロールアップ サーバー、サイドチェーンなど、並列処理の追加を可能にするオプションがさらにあります。

レイテンシとスループットの比較

従来、ブロックチェーン システムのパフォーマンスは、レイテンシとスループットの 2 つの側面に沿って評価されます。レイテンシは個々のトランザクションがどれだけ早く確認できるかを測定し、スループットは時間の経過に伴うトランザクションの合計速度を測定します。これらの軸は、Tier 1 および Tier 2 システムだけでなく、データベース クエリ エンジンや Web サーバーなどの他の多くのタイプのコンピュータ システムにも適用されます。

残念ながら、レイテンシーとスループットの両方を測定して比較するのは困難です。また、個々のユーザーはスループットをあまり気にしません (これはシステム全体の尺度です)。彼らが本当に気にしているのは、待ち時間と取引手数料です。具体的には、取引ができるだけ早く、できるだけ安く確認されることです。他の多くのコンピュータ システムもコスト/パフォーマンスに基づいて評価されますが、トランザクション手数料は、従来のコンピュータ システムには存在しないブロックチェーン システムの新しいパフォーマンス軸を表します。

レイテンシ測定の課題

遅延は最初は単純なように思えます。トランザクションが確認されるまでにどのくらい時間がかかりますか?しかし、この質問に答えるには常にいくつかの異なる方法があります。

まず、異なる時点間の遅延を測定すると、異なる結果が得られます。たとえば、レイテンシの測定を開始するのは、ユーザーがローカルの「送信」ボタンを押したときでしょうか、それともトランザクションがメモリプールに到達したときでしょうか?トランザクションが提案されたブロック内にあるとき、またはブロックが 1 つまたは 6 つの後続ブロックによって確認されたときにクロックを停止するのでしょうか?

これを測定する最も一般的な方法は、バリデーターの観点から、クライアントが最初にトランザクションをブロードキャストしてから、それが合理的に「確認」されるまで (現実世界の販売者が支払いの受け取りと商品の発送を検討するという意味で) という観点から行うものです。もちろん、マーチャントが異なれば受け入れ基準も異なる場合があり、単一のマーチャントであっても取引金額に基づいて異なる基準を持つ場合もあります。

バリデータ中心のアプローチでは、実際には重要なことがいくつか無視されます。まず、ピアツーピア ネットワーク上の遅延 (クライアントがトランザクションをブロードキャストしてから大部分のノードがそれを受信するまでにどのくらい時間がかかりますか?) とクライアント側の遅延 (トランザクションがブロードキャストされるまでにどのくらいの時間がかかりますか?) を無視します。クライアントのローカル マシン上で準備する必要がありますか?)。イーサリアム支払いの署名などの単純なトランザクションの場合、クライアント側の遅延は非常に小さく予測可能ですが、シールドされた Zcash トランザクションが正しいことを証明するなど、より複雑な場合には重大な問題になる可能性があります。

レイテンシで測定しようとしている時間枠を正規化したとしても、答えはほとんどの場合それに依存します。固定トランザクション遅延を提供する暗号通貨システムはこれまで存在しませんでした。覚えておくべき基本的な経験則は次のとおりです。

レイテンシは数値ではなく分布です。

ネットワーク研究コミュニティは以前からこのことを理解していました。トランザクション (または Web サーバー クエリ) の 0.1% でさえ遅延が大きいと、エンド ユーザーに深刻な影響を与える可能性があるため、ディストリビューションの「ロング テール」に特に重点が置かれます。

ブロックチェーンでは、確認の遅延はさまざまな理由で変化する可能性があります。

バッチ処理: ほとんどのシステムは、ほとんどのレイヤー 1 システムのブロックなど、何らかの方法でトランザクションをバッチ処理します。これにより、一部のトランザクションはバッチがいっぱいになるまで待機する必要があるため、遅延が変動します。幸運に恵まれて最後にバッチに参加する人もいるかもしれません。これらのトランザクションは追加の遅延なく即座に確認されます。

変動する輻輳: ほとんどのシステムは輻輳に悩まされています。これは、システムが一度に処理できるよりも多くのトランザクションを処理する必要があることを意味します。トランザクションが予測不可能な時間にブロードキャストされる場合（多くの場合、ポアソンプロセスとして抽象化されます）、新しいトランザクションのレートが1日または1週間にわたって変化する場合、または人気のNFT発行などの外部イベントに応じて、混雑レベルが増加する可能性があります。 。

コンセンサス層の違い: 層 1 でトランザクションを確認するには、通常、ブロックに関する合意に達するために分散されたノードのセットが必要ですが、これにより、輻輳の影響を受けることなく、変動するレイテンシが追加される可能性があります。プルーフ・オブ・ワーク・システムは、予測できないタイミングでブロックを発見します (ポアソン・プロセスとしても抽象化されます)。プルーフ・オブ・ステーク システムでは、さまざまな遅延が追加される可能性もあります (たとえば、ラウンドで委員会を形成するのに十分なオンライン ノードがない場合、またはリーダーのクラッシュに応じてビューを変更する必要がある場合など)。

これらの理由から、適切なガイドラインは次のとおりです。

待ち時間に関する記述では、平均や中央値のような単一の数値ではなく、確認時間の分布 (またはヒストグラム) を提示する必要があります。

平均値、中央値、パーセンタイルなどの概要統計は全体像の一部を提供しますが、システムを正確に評価するには、分布全体を考慮する必要があります。一部のアプリケーションでは、レイテンシの分布が比較的単純 (ガウス分布など) であれば、平均レイテンシから優れた洞察が得られます。しかし、暗号通貨では、このようなことはほとんどありません。通常、確認時間は非常に長くなります。

ライトニング ネットワークなどの支払いチャネル ネットワークがその良い例です。古典的な L2 スケーリング ソリューションとして、これらのネットワークはほとんどの場合、非常に高速な支払い確認を提供しますが、場合によってはチャネルのリセットが必要となり、遅延が桁違いに増加する可能性があります。

正確なレイテンシー分布に関する適切な統計があったとしても、システムやシステム要件の変化に応じて時間の経過とともに変化する可能性があります。また、競合するシステム間のレイテンシの分布を比較する方法も必ずしも明確ではありません。たとえば、1 ～ 2 分 (平均および中央値 90 秒) の均一に分散された待ち時間でトランザクションを確認するシステムを考えてみましょう。競合システムがトランザクションの 95% を 1 分以内に正確に確認し、残りの 5% を 11 分以内に正確に確認する場合 (平均 90 秒、中央値 60 秒)、どちらのシステムが優れていますか?答えは、前者を好むアプリもあれば、後者を好むアプリもあるということかもしれません。

最後に、ほとんどのシステムでは、すべてのトランザクションが同じ優先順位を持っているわけではないことに注意することが重要です。ユーザーはより高い優先順位を得るためにより多くの料金を支払うことができるため、上記のすべてに加えて、レイテンシは支払った取引手数料によって決まります。要するに：

レイテンシーは複雑です。報告されるデータが多ければ多いほど良いのです。理想的には、完全な遅延プロファイルをさまざまな輻輳条件下で測定する必要があります。レイテンシをさまざまなコンポーネント (ローカル、ネットワーク、バッチ、コンセンサス レイテンシ) に分類することも役立ちます。

スループット測定の課題

スループットも一見単純そうに見えますが、システムは 1 秒あたり何件のトランザクションを処理できるでしょうか。 2 つの主な問題が発生します。「トランザクション」とは正確に何なのか、そしてシステムが現在何を行っているのか、あるいは何ができるかを測定しているのかということです。

「1 秒あたりのトランザクション数」（tps）はブロックチェーンのパフォーマンスの事実上の尺度ですが、測定単位としてのトランザクションには問題があります。一般的なプログラム可能性 (「スマート コントラクト」)、またはビットコインのマルチトランザクションやマルチ署名検証オプションなどの限定された機能を提供するシステムの場合、基本的な問題は次のとおりです。

すべての取引が同じように作成されるわけではありません。

これは、トランザクションに任意のコードを含めたり、状態を任意に変更したりできるイーサリアムでは明らかに当てはまります。イーサリアムのガスの概念は、トランザクションの総作業量を定量化する (および料金を請求する) ために使用されますが、これは EVM 実行環境に非常に関連しています。 BPF 環境を使用して、EVM トランザクションのセットと Solana トランザクションのセットによって実行された作業の合計量を比較する簡単な方法はありません。これらのいずれかを一連のビットコイントランザクションと比較することも同様に懸念事項です。

トランザクション層をコンセンサス層と実行層に分離するブロックチェーンにより、これがより明確になります。 (純粋な) コンセンサス層では、スループットは単位時間あたりにチェーンに追加されるバイト数で測定できます。実行層は常により複雑です。

支払いトランザクションのみをサポートするロールアップ サーバーなどのより単純な実行レイヤーにより、定量的な計算の困難が回避されます。ただし、この場合でも、支払われるインプットとアウトプットの量は異なります。支払いチャネルのトランザクションに必要な「ホップ」の数は変動する可能性があり、スループットに影響します。ロールアップ サーバーのスループットは、トランザクションのバッチを、集約された変更のより小さなセットにどこまで「分割」できるかによって決まります。

スループットに関するもう 1 つの課題は、今日のパフォーマンスを経験的に測定するだけでなく、理論上の容量を評価することです。これにより、潜在的な容量を評価するためのさまざまなモデリング問題が発生します。まず、実行層での実際のトランザクション ワークロードを決定する必要があります。第二に、実際のシステム、特にブロックチェーン システムでは、理論上の容量に到達することはほとんどありません。堅牢性の理由から、実際にはノードの実装が異種混合で多様であることが望まれます (すべてのクライアントが単一のソフトウェア実装を実行するのではなく)。これにより、ブロックチェーンのスループットの正確なシミュレーションがより困難になります。

全体：

スループットの主張には、トランザクションのワークロードとバリデーターの数 (バリデーターの数、実装、ネットワーク接続) について慎重に説明する必要があります。明確な標準がない場合は、イーサリアムのような人気のあるネットワークの過去のワークロードで十分です。

レイテンシーとスループットのトレードオフ

レイテンシとスループットは多くの場合トレードオフになります。 Lefteris Kokoris-Kogias 氏が指摘したように、このトレードオフは多くの場合スムーズではなく、システム負荷が最大スループットに近づくと遅延が大幅に増加します。

ゼロ知識ロールアップ システムは、スループットと遅延のトレードオフの自然な例を提供します。トランザクションのバッチが大きいと、証明時間が長くなり、待ち時間が長くなります。ただし、プルーフサイズと検証コストの観点からは、オンチェーンのフットプリントは、より大きなバッチを伴うより多くのトランザクションにわたって償却され、スループットが向上します。

取引手数料

エンドユーザーは当然のことながら、レイテンシとスループットよりもレイテンシとコストのトレードオフを重視します。ユーザーがスループットを気にする直接的な理由はまったくなく、可能な限り低い手数料でトランザクションを迅速に確認できるというだけです (手数料を重視するユーザーもいれば、レイテンシを重視するユーザーもいます)。全体として、コストは次のようなさまざまな要因によって影響されます。

• 取引に対する市場の需要はどれくらいありますか?
• システムによって達成される合計スループットはどれくらいですか?
• システムがバリデーターまたはマイナーに提供する総収益はどれくらいですか?
• この収益のうち、取引手数料とインフレ報酬に基づくものはどれくらいですか?

最初の 2 つの要素は、大まかに言って、市場清算価格に至る需要と供給の曲線です (ただし、マイナーがカルテルとして機能してこの点を超えて手数料を引き上げているという主張もあります)。他のすべてが同じであれば、スループットが高ければ料金は安くなるはずですが、それだけではありません。

特に上記の 3 点目と 4 点目はブロックチェーンのシステム設計の基本的な問題ですが、これらに対する適切な原則が不足しています。私たちは、マイナーに取引手数料ではなく、インフレ報酬による収入を与えることの長所と短所をある程度理解しています。しかし、ブロックチェーンコンセンサスプロトコルの多くの経済分析にもかかわらず、バリデーターにどれだけの収益を流す必要があるかを決定するための広く受け入れられたモデルはまだありません。今日のほとんどのシステムは、バリデーターがシステムの実際の使用を妨げることなく正直に行動するのに十分な収益がいくらあるのかという知識に基づいた推測に基づいて構築されています。単純化されたモデルでは、51% 攻撃を開始するコストがバリデーターへの報酬に比例することが示されます。

攻撃コストを上げるのは良いことですが、どの程度のセキュリティが「十分」なのかもわかりません。 2 つの遊園地に行くことを検討していると想像してください。そのうちの 1 社は、もう 1 社よりも乗り物のメンテナンスにかかる費用が 50% 少ないと主張しています。この公園に行くのは良い考えですか?より効率的で、より少ない費用で同じセキュリティが得られる可能性があります。もしかしたら、相手は何の利益もなく乗り物を安全に保つために必要以上にお金を費やしているのかもしれません。しかし、最初の公園が危険である可能性もあります。ブロックチェーンシステムも同様です。スループットを考慮に入れると、手数料が低いブロックチェーンは、より少ないバリデーターに報酬を与える (つまりインセンティブを与える) ため、手数料も低くなります。現在、これが可能かどうか、またはシステムが脆弱なままになるかどうかを評価するための優れたツールがありません。全体：

異なるシステム間の料金を比較すると誤解を招く可能性があります。取引手数料はユーザーにとって重要ですが、システム設計自体以外の多くの要因の影響を受けます。スループットは、システム全体を分析するためのより良い指標です。

結論は

パフォーマンスを公平かつ正確に評価することは困難です。車の性能を測定する場合も同様です。ブロックチェーンと同じように、人によって関心のあることは異なります。車の場合、最高速度や加速を気にするユーザーもいれば、燃料消費量を気にするユーザーも、牽引能力を気にするユーザーもいます。これらすべてを評価するのは簡単ではありません。たとえば米国では、環境保護庁が燃費の評価方法と、販売店でユーザーに燃費をどのように提示するかについて詳細なガイドラインを提供しています。

ブロックチェーン分野は、このレベルの標準化にはまだ遠いです。一部の領域では、将来的には、正規化されたワークロードまたはレイテンシー分布を示す正規化されたグラフを通じてシステムのスループットを測定する可能性があります。現時点では、評価者と構築者にとって最善の行動は、できるだけ多くのデータを収集して公開し、評価方法を詳細に記述して、他のシステムと複製して比較できるようにすることです。