a16z: チェーンのパフォーマンスを測定するのはなぜ難しいのですか?
この記事の由来は a16zこの記事の由来は
、原著者：ジョゼフ・ボノー、Odaily翻訳者のケイティ・クーによって編集されました。
パフォーマンスの測定と比較には、パフォーマンスをコンポーネントに分割し、複数のデータ軸にわたるトレードオフを比較する、より微妙で徹底的なアプローチが必要です。このペーパーでは、ブロックチェーンのパフォーマンスの意味を定義し、その課題を概説し、ブロックチェーンのパフォーマンスを評価する際に留意すべきガイドラインと重要な原則を提供します。
副題
スケーラビリティとパフォーマンスの比較
まず、スケーラビリティとパフォーマンスには標準的なコンピュータ サイエンスの意味があり、ブロックチェーンでは誤って適用されることがよくあります。パフォーマンスは、システムが現在達成できることを測定します。以下で説明するように、パフォーマンス メトリクスには、1 秒あたりのトランザクション数やトランザクション確認時間の中央値が含まれる場合があります。一方、スケーラビリティは、リソースを追加してパフォーマンスを向上させるシステムの能力を測定します。
この区別は重要です。正しく定義されていれば、パフォーマンスを向上させる多くの方法はスケーラビリティをまったく向上させません。簡単な例としては、Schnorr 署名や ECDSA 署名の約半分のサイズである BLS 署名など、より効率的なデジタル署名スキームを使用することが挙げられます。ビットコインが ECDSA から BLS に切り替わった場合、ブロックあたりのトランザクション数は 20 ～ 30% 増加し、一夜にしてパフォーマンスが向上する可能性があります。しかし、これを実行できるのは 1 回だけです。これ以上、スペース効率の高い署名スキームを切り替えることはできません (スペースを節約するために BLS 署名を集約することもできますが、これも 1 回限りのトリックです)。
他のいくつかのワンショット トリック (SegWit など) もブロックチェーンで使用できますが、リソースを追加すると時間の経過とともにパフォーマンスが向上する、継続的なパフォーマンス向上のためにはスケーラブルなアーキテクチャが必要です。これは、Web サーバーの構築など、他の多くのコンピューター システムにおける従来の考え方でもあります。いくつかの一般的なトリックを使えば、高速に動作するサーバーを構築できます。しかし、最終的には、サーバーを継続的に追加して増大する需要に対応するには、マルチサーバー アーキテクチャが必要になります。
スケーラビリティには本質的に並列処理の活用が必要です。ブロックチェーン空間では、L1 スケーリングにはフォークまたはフォークに類似したものが必要なようです。フォークの基本概念は、状態を複数のチャンクに分割して、さまざまなバリデーターが独立して処理できるようにすることであり、これはスケーラビリティの定義とよく一致します。 L2 には、オフチェーン チャネル、ロールアップ サーバー、サイドチェーンなど、並列処理の追加を可能にするオプションがさらにあります。
副題
レイテンシとスループットの比較
ただし、レイテンシとスループットの測定と比較は複雑です。また、個々のユーザーはスループットをあまり気にしません (これはシステム全体のメトリックです)。彼らが本当に気にしているのは、レイテンシーとトランザクション手数料です。より具体的に言えば、取引は可能な限り迅速かつ安価に確認されます。他の多くのコンピューター システムもコスト/パフォーマンスに基づいて評価されますが、トランザクション手数料は、従来のコンピューター システムには実際には存在しない、ブロックチェーン システムの新しいパフォーマンス軸です。
副題
レイテンシ測定の課題
レイテンシーは最初は単純なように思えますが、トランザクションが確認されるまでにどのくらい時間がかかるのでしょうか?しかし、この質問に答えるにはいくつかの異なる方法があります。
まず、異なる時点間の遅延を測定すると、異なる結果が得られます。たとえば、レイテンシの測定を開始するのは、ユーザーがローカルで「送信」ボタンを押したときでしょうか、それともトランザクションがメモリプールに到達したときでしょうか?トランザクションが提案されたブロック内にあるとき、またはブロックが 1 つまたは 6 つの後続ブロックによって確認されたときに、時間のカウントを停止するのでしょうか?
最も一般的なアプローチは、ユーザーが最初にトランザクションをブロードキャストしてから、バリデーターの観点から合理的に「確認」されるまでの時間を測定することです。もちろん、販売業者が異なれば、異なる受け入れ基準を採用することもあり、単一の販売業者であっても、取引金額に応じて異なる基準を採用することもある。
バリデータ中心のアプローチでは、実際にはいくつかの重要な点が無視されます。まず、ピアツーピア ネットワーク上の遅延 (クライアントがトランザクションをブロードキャストしてから大多数のノードがそれを受信するまでにどのくらい時間がかかりますか?) とクライアント側の遅延 (トランザクションの準備にどのくらい時間がかかりますか) を無視します。クライアント側の遅延は、イーサリアム支払いへの署名などの単純なトランザクションではほとんど発生せず、予測可能ですが、シールドされた Zcash トランザクションが正しいことを証明するなど、より複雑なケースでは重大になる可能性があります。
レイテンシーを測定しようとしている時間枠を正規化したとしても、答えは異なります。現在まで、固定トランザクション遅延を提供する暗号通貨システムはありません。基本的な経験則は次のとおりです。
レイテンシは数値ではなく分布です。
ネットワーク研究コミュニティは以前からこのことを理解していました。トランザクション (または Web サーバー クエリ) の 0.1% でさえ遅延が大きいと、エンド ユーザーに深刻な影響を与える可能性があるため、ディストリビューションの「ロング テール」に特に重点が置かれます。
ブロックチェーンでは、確認のレイテンシーはさまざまな理由で異なります。バッチ処理：
ほとんどのシステムは、何らかの方法でトランザクションをバッチ処理します。たとえば、ほとんどの L1 システムでは、トランザクションをブロックにバッチ処理します。これにより、一部のトランザクションはバッチがいっぱいになるまで待機する必要があるため、遅延が変動します。幸運にも最後に参加できる人もいるでしょう。これらのトランザクションは即座に確認され、追加の遅延は発生しません。変動する混雑:
ほとんどのシステムでは輻輳が発生します。これは、システムがすぐに処理できるよりも多くのトランザクションが発行されることを意味します。トランザクションが予測不可能な時間にブロードキャストされる場合、または新しいトランザクションのレートが 1 日または 1 週間にわたって変化する場合、または人気のある NFT の発売などの外部イベントに応じて、混雑のレベルが変化する可能性があります。コンセンサス層の違い:
通常、L1 でトランザクションを確認するには、ブロックに関する合意に達するために分散されたノードのセットが必要ですが、これにより、輻輳に関係なく、変動する遅延が追加される可能性があります。 Proof-of-Work システムは、予測できないタイミングでブロックを検出します。 PoS システムは、さまざまな遅延を追加する可能性もあります (たとえば、ラウンドで委員会を形成するのに十分なオンラインのノードがない場合、またはリーダーの崩壊に応じて意見の変更が必要な場合)。
これらの理由から、優れた指針は次のとおりである必要があります。
待ち時間に関する主張は、平均や中央値のような単一の数値ではなく、確認時間の分布を示す必要があります。
平均、中央値、パーセンタイルなどの概要統計は全体像の一部を提供しますが、システムを正確に評価するには、分布全体を考慮する必要があります。一部のアプリケーションでは、待ち時間の分布が比較的単純な場合、平均待ち時間から優れた洞察が得られます。しかし、暗号通貨では、このようなことはほとんど起こりません。通常、確認時間は非常に長くなります。
ライトニング ネットワークなどの支払いチャネルのネットワークが良い例です。これは古典的な L2 スケーリング ソリューションであり、これらのネットワークはほとんどの場合、非常に高速な支払い確認を提供しますが、場合によってはチャネルのリセットが必要となり、遅延が桁違いに増加する可能性があります。
正確なレイテンシー分布に関する優れた統計情報がある場合でも、システムやシステム要件の変化に応じて統計が変わる可能性があります。また、競合するシステム間で遅延プロファイルを比較する方法が必ずしも明確であるとは限りません。たとえば、システムでトランザクションの遅延が 1 ～ 2 分 (平均および中央値 90 秒) に均等に分布していることが確認されたとします。競合システムがトランザクションの 95% を 1 分以内に正しく確認し、残りの 5% を 11 分以内 (平均 90 秒、中央値 60 秒) に確認した場合、どちらのシステムが優れていますか?答えは、前者を好むアプリもあれば、後者を好むアプリもあるということかもしれません。
レイテンシーは複雑です。報告されるデータが多ければ多いほど良いのです。理想的には、完全な遅延プロファイルをさまざまな輻輳条件下で測定する必要があります。レイテンシをさまざまなコンポーネント (ローカル、ネットワーク、バッチ、コンセンサス レイテンシ) に分類することも役立ちます。
副題
スループット測定の課題
スループットも表面的には単純に見えます。システムは 1 秒あたり何件のトランザクションを処理できるでしょうか。しかし、主な問題が 2 つあります。1 つは「トランザクション」とは正確に何なのか、もう 1 つはシステムが現在実行していることを測定しているのか、あるいは実行する可能性があることを測定しているのかということです。
「1 秒あたりのトランザクション数」（tps）はブロックチェーンのパフォーマンスの事実上の尺度ですが、測定単位としてのトランザクションには問題があります。一般的なプログラム可能性 (スマート コントラクト)、またはビットコインの多方向トランザクションやマルチ署名検証オプションなどの限定された機能を提供するシステムの場合、基本的な質問は次のとおりです。
すべての取引が同じように作成されるわけではありません。
これは、トランザクションに任意のコードを含めたり、状態を任意に変更したりできるイーサリアムでは明らかに当てはまります。イーサリアムのガスの概念は、トランザクションが実行する作業の全体量を定量化 (および課金) するために使用されますが、これは EVM 実行環境に非常に関連しています。 BPF 環境を使用して、EVM トランザクションのセットと Solana トランザクションのセットによって実行された作業の合計量を比較する簡単な方法はありません。この 2 つを一連のビットコイン取引と比較することも同様に懸念事項です。
トランザクション層をコンセンサス層と実行層に分割するブロックチェーンにより、これをより明確にすることができます。 (純粋な) コンセンサス層では、スループットは単位時間あたりにチェーンに追加されるバイト数で測定できます。実行層はより複雑です。
支払いトランザクションのみをサポートするロールアップ サーバーなどのより単純な実行レイヤーにより、定量的な計算の困難が回避されます。この場合でも、投入量と産出量に応じて支払額は変動する。支払いチャネルのトランザクションでは必要な「ホップ」の数が異なる場合があり、スループットに影響します。ロールアップ サーバーのスループットは、トランザクションのバッチがより小さな集約された変更セットにどの程度うまく「ネットワーク化」されるかによって決まります。
スループットに関するもう 1 つの課題は、今日のパフォーマンスを経験的に測定するだけでなく、理論上の能力を評価することです。これにより、潜在的な機能を評価するためのさまざまなモデリング問題が導入されます。まず、実行層の現実的なトランザクション ワークロードを特定する必要があります。第二に、実際のシステム、特にブロックチェーンシステムは理論上の能力にほとんど到達しません。堅牢性の理由から、実際には (すべてのクライアントが単一のソフトウェア実装を実行するのではなく) ノード実装が異種混合で多様であることが望まれます。これにより、ブロックチェーンのスループットを正確にシミュレートすることがより困難になります。
スループットの要求には、トランザクションのワークロードとバリデーターの数 (バリデーターの数、実装、およびネットワーク接続) を慎重に解釈する必要があります。明確な標準がない場合は、イーサリアムのような人気のあるネットワークの過去のワークロードで十分です。
副題
レイテンシーとスループットのトレードオフ
副題
取引手数料
取引手数料
当然のことながら、エンド ユーザーは遅延とスループットの間のトレードオフよりも、遅延とコストの間のトレードオフを重視します。ユーザーにはスループットを気にする直接の理由はまったくなく、トランザクションを迅速かつ可能な限り低い手数料で確認できることだけを気にしています (手数料をより気にするユーザーもいれば、レイテンシーをより気にするユーザーもいます)。高額な手数料は、次のようなさまざまな要因によって影響されます。
取引に対する市場の需要はどれくらいありますか?
システムによって達成される全体的なスループットはどれくらいですか?
システムがバリデーターまたはマイナーに提供する総収益はいくらですか?
この収益のうち、取引手数料またはインフレ報酬に基づくものはどれくらいですか?
最初の 2 つの要素は、大まかに言って、市場清算価格につながる需要と供給の曲線です (ただし、連盟などのマイナーがこの点を超えて手数料を設定していると主張する人もいます)。他のすべてが同じであれば、スループットが高くなると料金は安くなるはずですが、対処すべき要因はさらにあります。
特に、上記のポイント 3 と 4 はブロックチェーンのシステム設計における基本的な問題ですが、両方とも適切な原則が不足しています。私たちは、マイナーに取引手数料に比べてインフレ的な報酬を与えることの長所と短所をある程度理解しています。しかし、ブロックチェーンコンセンサスプロトコルについては多くの経済分析が行われているにもかかわらず、検証者にどれだけの収益をもたらす必要があるかについて広く受け入れられたモデルはまだありません。今日のほとんどのシステムは、実際のシステムの使用を妨げることなくバリデーターが誠実に作業するのに十分な収益がどれだけあるのかという知識に基づいた推測に基づいて構築されています。単純化されたモデルでは、51% 攻撃をインストールするコストがバリデーターの報酬に直接比例していることがわかります。
副題
結論は
結論は
パフォーマンスを公平かつ正確に評価することは困難です。車の性能を測定する場合も同様です。ブロックチェーンと同じように、人によって関心のあることは異なります。車に関しては、最高速度や加速を気にするユーザーもいれば、燃料消費量を気にするユーザーも、牽引能力を気にするユーザーもいます。これらすべての正確な値を取得するのは簡単ではありません。たとえば米国では、環境保護庁が燃費の評価方法と、販売店でのユーザーへの表示方法について詳細なガイドラインを定めています。
IOS
Android