a16z:ブロックチェーンのパフォーマンスを評価する基本原則
執筆:Joseph Bonneau、a16z crypto research メンバー
編纂:Amber、Foresight News
性能とスケーラビリティに関する議論は、暗号世界全体で最も古くからある論題の一つです。
レイヤー1とレイヤー2のソリューションの優劣や有効性についての議論は続いていますが、標準化された指標や評価基準が欠如しているため、議論の中で各側が提示するデータはしばしば一貫性を欠き、明らかに意見の相違をさらに悪化させています。
簡単に言えば、私たちは性能を比較するために、より詳細で徹底的なアプローチが必要です。たとえば、性能をいくつかの次元に分けて比較し、包括的なトレードオフ基準を見つける必要があります。本稿では、基本的な用語から始め、現在の市場が直面している課題を概説し、ブロックチェーンの性能を評価する際に留意すべき基本原則について展開します。
スケーラビリティ & 性能
まず、スケーラビリティと性能という2つの用語を定義しましょう。この2つの言葉は標準的な計算機科学の意味を持っていますが、ブロックチェーン環境ではしばしば誤用されています。性能は一般的に、システムが達成できる目標の効率を測るために使用され、性能指標には、1秒あたりに処理できるプロセスの数や特定の要求に対する所要時間が含まれることがあります。一方、スケーラビリティは、システムが一定のリソースを追加することで性能を向上させる能力を測るために使用されます。
なぜ最初に明確に定義する必要があるのかというと、実際には多くの性能向上の方法がスケーラビリティを向上させないからです。簡単な例として、より効率的なデジタル署名スキーム、たとえばBLS署名を使用することが挙げられます。BLS署名のサイズはSchnorrやECDSA署名の約半分です。もしビットコインがECDSAからBLSに切り替われば、各ブロックの取引数は20-30%増加し、一夜にして性能が向上する可能性があります。しかし、これは一度だけ行うことができます——これ以上の空間を節約する署名スキームに切り替えることはできません(BLS署名もさらに空間を節約するために集約できますが、これもまた一時的なテクニックに過ぎません)。
実際、ブロックチェーンネットワークには多くの一時的な性能向上のテクニックがあります(たとえばSegWitなど)が、私たちが本当に必要としているのは、持続的な性能向上を実現するためのスケーラブルなアーキテクチャです。そうすることで、リソースを継続的に追加することで性能を持続的に向上させることができます。実際、Web2時代には、これは一般的な手法でした。サーバーを構築する例を挙げると、十分に速いサーバーを直接構築することもできますが、最終的には通常、マルチサーバーアーキテクチャにアップグレードする必要があり、その間に新しいサーバーを追加し続けて、増大するデータストレージ/処理の要求に応える必要があります。
この違いを理解することで、「あるブロックチェーンは高いスケーラビリティを持ち、1秒あたりにどれだけの取引を処理できるか!」といった発言における常識的な誤りを避けるのに役立ちます。このような言い回しは煽動的であるかもしれませんが、実際には処理できる取引の数は性能指標であり、スケーラビリティ指標ではありません。
スケーラビリティは本質的に並列性を利用する必要があります。ブロックチェーンの分野では、レイヤー1の拡張はしばしばシャーディングやシャーディングのように見えるものを必要とします。シャーディングの基本的な概念は、状態をいくつかの部分に分割し、異なる検証者がその一部を独立して処理できるようにすることです。これはスケーラビリティの定義と非常に一致しています。もちろん、レイヤー2には、オフチェーンチャネル、ロールアップ、サイドチェーンなど、並列処理を追加するためのさらに多くのオプションがあります。
遅延とスループット
過去には、遅延とスループットの2つの次元を用いてブロックチェーンの性能を評価することが一般的でした。遅延は単一の取引がどれだけ早く確認されるかを測るために使用され、スループットは特定の時間内に確認できる取引の総量を測るために使用されます。この測定方法は、レイヤー1とレイヤー2のネットワークに適用でき、さらにはブロックチェーン以外の他のタイプのコンピュータシステムにも完全に適用可能です。
残念ながら、遅延とスループットのこの2つの次元は、実際には測定や比較が非常に難しいのです。そして、もう一つ重要な点は、個々のユーザーは実際にはスループットを気にしておらず、彼らが本当に気にしているのは遅延と取引手数料だけです。取引手数料はブロックチェーンシステムにおける重要な次元であり、これは従来のコンピュータ分野には存在しません。
遅延の測定の課題
遅延の測定は一見簡単に思えます:取引が確認されるまでにどれくらいの時間がかかるのか?しかし、実際の操作では問題が明らかになります。まず、異なる時間点で測定した遅延はしばしば異なります。私たちはユーザーのローカルで「送信」ボタンをクリックした瞬間から計算を始めるべきでしょうか?それとも、タスクがメモリプールに到達した瞬間から計算を始めるべきでしょうか?また、ブロックが確認されたときにすぐに計時を停止すべきでしょうか?異なる操作の詳細が異なる結果をもたらします。
最も一般的な方法は、検証者の視点から測定することです。顧客が取引を最初に放送してから、取引が合理的に確認されるまでの時間(ある意味では、現実世界の商人は支払いを受け取って商品を発送することを考慮します)。もちろん、異なる商人は異なる受け入れ基準を採用する可能性があり、単一の商人も取引金額の大きさに応じて異なる基準を採用することがあります。
検証者中心のアプローチは、実践において重要なことをいくつか無視しています。まず、ピアツーピアネットワーク上の遅延(クライアントが取引を放送してから大多数のノードがそれを聞くまでにどれくらいの時間がかかるか?)やクライアント遅延(取引を準備するのにどれくらいの時間がかかるか?クライアントのローカルマシンでどれくらいの時間がかかるか?)を無視しています。イーサリアムの支払いなどの単純な取引において、クライアント遅延は非常に小さく予測可能であるかもしれませんが、より複雑な状況(たとえば、プライベート取引が正しいことを証明する場合)では異なります。
遅延の測定時間ウィンドウを標準化しても、最終的な答えは状況に応じて異なります。暗号通貨システムが一定の取引遅延を保証することはありません。覚えておくべき基本的な経験則は、遅延は数字ではなく分布であるということです。
ネットワーク研究コミュニティはこのことを早くから認識しており、ロングテールが重要であると指摘しています。0.1%のプロセスが遅延するだけでも、最終的なユーザー体験に深刻な影響を与える可能性があります。
ブロックチェーンにおいて、確認遅延はさまざまな理由で異なる可能性があります:
バッチ処理:ほとんどのシステムは何らかの形でトランザクションをバッチ処理しており、これにより可変遅延が生じます。なぜなら、特定のトランザクションはバッチ処理キューが満たされるまで処理されないからです。ネットワーク参加者は、そのバッチの最後の列車に乗ることができるかもしれません。これらの取引はすぐに確認され、追加の遅延は発生しませんが、早くキューに入った人々は確認を待つのに長い時間を費やさなければなりません。
不確実な混雑:ほとんどのシステムは混雑の状況を経験しており、これは発表された取引がシステムが即座に処理できる数を超えることを意味します。取引が予測できない時間(通常はポアソン過程として抽象化される)に放送されたり、新しい取引の速度が1日または1週間の間に変化したり、外部イベントに応じて混雑の程度が異なる可能性があります。
コンセンサス層の違い:レイヤー1で取引を確認するには、通常、分散ノードのセットがブロックに関して合意に達する必要があり、これにより可変遅延が増加する可能性があります。プルーフ・オブ・ワークシステムは予測できない時間にブロックを発見します。プルーフ・オブ・ステークシステムもさまざまな遅延を増加させる可能性があります。
これらの理由から、良い指針は、遅延に関する声明は確認時間の分布として提示されるべきであり、平均値や中央値のような単一の数字ではないということです。
平均値、中央値、またはパーセンタイルなどの集約統計は部分的な規則性を示すことができますが、システムを正確に評価するには全体の分布を考慮する必要があります。特定のアプリケーションでは、遅延分布が比較的単純であれば、平均遅延が良い洞察を提供することがあります。しかし、暗号通貨ではこの理想的な状況はあまり見られません。通常、確認時間は非常に長くなります。
支払いチャネルネットワーク(たとえば、ライトニングネットワーク)は良い例です。クラシックなL2拡張ソリューションとして、これらのネットワークはほとんどの場合、非常に迅速な支払い確認サービスを提供しますが、時にはチャネルのリセットが必要であり、これが遅延を数桁増加させる可能性があります。
正確な遅延分布に関する良好な統計データがあっても、それらはシステムやシステムの要求の変化に伴い時間とともに変化する可能性があります。競合システム間の遅延分布を比較する方法も非常に曖昧です。たとえば、取引の均一分布遅延が1分から2分の間(平均と中央値が90秒)で確認されるシステムを考えてみましょう。もし競合システムが1分以内に95%の取引を正確に確認し、11分以内に残りの5%を確認した場合(平均90秒、中央値60秒)、どちらのシステムが優れているのでしょうか?答えは、異なるカテゴリのアプリケーションが選択する基準が一致しない可能性があるということです。
最後に注意すべき点は、ほとんどのシステムにおいてすべての取引の優先度が同じではないということです。ユーザーはより高い優先度を得るためにより多くの手数料を支払うことができるため、上記のすべての要素に加えて、遅延は支払った取引手数料にも依存します。要するに、遅延は複雑です。前提条件の詳細が多ければ多いほど良いです。理想的には、異なる混雑条件下で完全な遅延分布を測定するべきです。遅延を異なる要素(ローカル、ネットワーク、バッチ処理、コンセンサス遅延)に分解することも役立ちます。
スループットの測定の課題
スループットは一見簡単に思えます:システムは1秒あたりにどれだけの取引を処理できるのでしょうか?しかし、実際には問題も水面下に隠れています。難しさは主に2つの側面にあります。第一に、何が取引と見なされるのか、私たちはシステムが今日何をしたのかを測定しているのでしょうか?それとも、彼が何をできるかを測定しているのでしょうか?
1秒あたりの取引数(またはTPS)は、ブロックチェーンの性能を測る一般的な基準ですが、取引を測定単位とすることには問題があります。汎用プログラミング(スマートコントラクト)を提供するシステムや、ビットコインのマルチトランザクションやマルチシグネチャ検証オプションなどの限定機能を持つシステムにおいて、最も基本的な問題は、すべての取引が平等ではないということです。
イーサリアムネットワークでは、取引は任意のコードや任意の状態を含むことができます。イーサリアムにおけるガスの概念は、取引が実行される総作業量を定量化(および課金)するために使用されますが、これはEVM実行環境に高度に限定されています。EVMトランザクションの完了に必要な作業量をBPF環境の一連のSolanaトランザクションと直接比較する簡単な方法はありません。これらのいずれかをビットコインの取引のセットと直接比較することも合理的ではありません。
取引層をコンセンサス層と実行層に分けるブロックチェーンは、これをより明確にします。(純粋な)コンセンサス層では、スループットは単位時間あたりにチェーンに追加されるバイト数で測定できます。一方、実行層ははるかに複雑です。
よりシンプルな実行層、たとえば支払い取引のみをサポートするロールアップサーバーは、計算の定量化の困難を回避します。しかし、その場合でも、支払いの入力と出力の数は異なる場合があります。支払いチャネル取引に必要な可変パラメータの数は異なる可能性があり、これがスループットに影響を与えます。ロールアップサーバーのスループットは、一連のトランザクションがどの程度「要約」されて小さなデータパケットのセットになるかに依存する可能性があります。
スループットのもう一つの課題は、今日の性能を経験的に測定することを超えて理論的な容量を評価することです。これにより、潜在的な容量を評価するためのさまざまなモデリングの問題が生じます。まず、実行層の実際のトランザクション作業負荷を特定する必要があります。次に、実際のシステムは理論的な容量にほとんど達することはありません。特にブロックチェーンシステムでは、堅牢性の理由から、ノードの実装が実際には異種で多様であることを望みます(すべてのクライアントが同じソフトウェア実装を実行するわけではありません)。これにより、ブロックチェーンのスループットの正確なシミュレーションがさらに難しくなります。
全体として、スループットのトレードオフには、取引の作業量と検証者の数を慎重に解釈する必要があります。明確な基準がない場合、イーサリアムのような比較的普及したネットワークの過去の負荷を基準として比較することしかできません。
遅延とスループットの総合的な考慮
遅延とスループットをそれぞれ統計的に評価した後、両者の間で総合的なトレードオフを行う必要があります。Lefteris Kokoris-Kogiasが述べたように、このトレードオフは通常スムーズではなく、システムの負荷が最大スループットに近づくと、遅延が急激に上昇します。
ZKロールアップシステムは、スループット/遅延のトレードオフの自然な例を提供します。大量の取引は証明時間を増加させ、遅延を増加させます。しかし、証明のサイズと検証コストの観点から、オンチェーンの計算能力はより大規模な取引クラスターに傾くため、スループットが向上します。
取引手数料
理解できることに、最終ユーザーは遅延と費用のトレードオフに関心があり、遅延とスループットにはあまり関心がありません。ユーザーはスループットを気にする必要はなく、彼らはできるだけ低い費用で迅速に取引を確認したいだけです(一部のユーザーは費用を重視し、他のユーザーは遅延を重視します)。全体的に、費用はさまざまな要因に影響されます:
市場の需要はどれくらいですか?
システムが実現できる総スループットはどれくらいですか?
このシステムは検証者やマイナーにどれくらいの収入を提供していますか?
この収入の中で、どれくらいが取引手数料とインフレ報酬に基づいていますか?
簡単に言えば、他の条件が同じであれば、より高いスループットはより低い費用をもたらすはずです。しかし、上記の第3点と第4点はブロックチェーンシステム設計の基本的な問題です。ブロックチェーンのコンセンサスプロトコルに関する多くの経済分析が行われていますが、検証者が必要とする収入については、まだ合意されたモデルがありません。今日のほとんどのシステムは、検証者が誠実に行動するのに十分な収入を提供しつつ、ネットワークがユーザーにとって魅力的であり続けるために必要な収入を提供するという根拠のある推測に基づいています。単純化されたモデルでは、51%攻撃を発動するコストを検証者の報酬に比例させることができます。
攻撃コストを引き上げることは良いことですが、私たちは「十分な」安全性がどれくらいかを知りません。想像してみてください、あなたは2つの遊園地を考えています。そのうちの1つは、乗り物のメンテナンスにかかる費用がもう1つの半分だと主張しています。この公園に行くのは良い考えでしょうか?おそらく、彼らはより効率的で、同じ安全性をより少ない費用で得られるかもしれません。あるいは、別の公園は安全を保つために必要な費用を超えているかもしれませんが、何の利益もありません。しかし、最初の公園は危険かもしれません。ブロックチェーンシステムも同様です。スループットを考慮に入れると、費用が低いブロックチェーンは、報酬が少ないために費用が低くなります。私たちは、これが実行可能かどうか、またはそれがシステムを攻撃に対して脆弱にするかどうかを評価するための良いツールを持っていません。全体的に、システム間の費用を比較することは、ある程度の誤解を招く可能性があります。取引手数料はユーザーにとって重要ですが、システム設計自体を除いて、多くの要因に影響されます。スループットは、システム全体を分析するためのより良い指標です。
結論
公平かつ正確に性能を評価することは非常に困難です。ブロックチェーンを測定することは、車が買う価値があるかどうかを測定することと同じくらい複雑であり、人々は異なることに関心を持っています。自動車の場合、一部のユーザーは最高速度や0-100km/h加速タイムを気にし、他の人は燃費を気にし、また別の人はその車がどれだけの貨物を運べるかを気にします。このため、米国環境保護庁は自動車評価基準のガイドラインを直接策定しました。
しかし、ブロックチェーンの分野では、標準化された基準を策定する時期にはまだ達していません。時には、標準的な作業負荷を見つけて、ブロックチェーンネットワークのスループットと遅延分布の「標準的なグラフ」を描くことができるかもしれませんが、現在の研究者や構築者にとって最良の方法は、できるだけ多くのデータを収集し、意見を発表する前にテスト環境をできるだけ詳細に描写することです。そうすることで、相対的に客観的な比較結果を得ることができます。