以下はIOGブログに掲載された記事「Increasing the transaction throughput of Cardano」を翻訳したものです。
カルダノのトランザクションスループットを向上させる
by Matthias Fitzi 2022年3月21日
今夏に予定されている拡散パイプライン化により、ブロックの伝搬と検証時間の予算が増え、より大きなブロックと取引スループットの向上が可能になります。ここでは、技術研究の観点からご紹介します。(さらに高性能な兄弟機であるAVの紹介も合わせて…)
カルダノのトランザクションスループットを向上させる
最近、カルダノでスマートコントラクトが可能になったことで、ユーザーのアクティビティが大幅に増加しました。同時に、コードを運ぶスクリプト取引により、平均取引サイズも大きくなりました。現在、最初の分散型金融（DeFi）アプリケーションがカルダノエコシステム上に展開されており、今後も展開される予定であることから、この傾向は継続すると思われます。このような需要の高まりに対応するためには、システムの現在のトランザクション処理能力を向上させる必要があります。
トランザクションのスループットを向上させるための明らかなアプローチは、ブロックあたりのトランザクション数を増やすためにブロックサイズの上限を増やすことです。ブロックサイズは今年すでに64kBから現在の80kBへと25％増やされており、今後もさらに増えることが予想されます。しかし、ブロック生成率を現状のまま維持しようとすると、台帳-合意プロトコルによって安全に維持できるブロックの大きさには限度があります。システムの安全性を損なわずに高いスループットを実現するためには、さらなる対策が必要です。その理由を理解するために、一般的に台帳コンセンサスがどのように機能するかを詳しく見てみる必要があります。
元帳コンセンサスプロトコルは、2つの時間パラメータによって特徴付けられます。
- Δp：新しいブロックがネットワークの95%に到達するまでの最大ネットワーク遅延時間と
- Δb:：2つの新しいブロックが生成されるまでの（予想）時間
一般的なプロトコルでは、コンセンサスの一貫性を主張するために、少なくともほとんどの場合、次のブロックが生成される前に前のブロックの伝搬が終了している必要があります。したがって、ΔbはΔpよりもいくらか大きくなるように選択される。カルダノでは、Δp=5s（秒）、Δb=20sである。
さて、この条件で1ブロックが輸送できるデータ量はどの程度だろうか。これを見るには、Δpの中で具体的に何を実現しなければならないかをより詳細に調べる必要がある。
上の図1は、ネットワーク上でブロックが伝播していく様子を簡略化して描いたものです。ブロックの生成者は新しいブロックのヘッダーをピア1（白いhボックス）に送信し、白いhボックスで示された時間内に両方のノードのネットワークリンクを占有します。ピア1は次にヘッダーを検証します（灰色のhvボックスで示された時間内にローカル計算が行われます）。ヘッダーが有効であれば、つまり、ヘッダーが適格なブロックリーダーシップなどを証明すれば、ブロック本体はピア1（白のbボックス）によってダウンロードされ、再び両ノードのネットワークリンクを占有することになります。最後に、ピア1はブロックボディを検証し(灰色のbv-box)、ブロックボディも有効である場合にのみ、ピア1は先ほど説明した方法で他のピアにブロックを伝搬する準備ができます。
この動作モードの残念な副作用は、1つのノードのCPUとネットワークリンクがΔp=5sのごく一部しか使用されず、残りの（予想される）Δb=20sの間は（ほとんど）アイドル状態のままであることです。
具体的には、1ブロックに収められるデータ量は、ブロックのピアツーピアネットワーク遅延と必要な検証時間によって決定されます。両者はブロックのサイズにほぼ線形に増加し、全ノードの95%に到達するために必要な最大ホップ数の倍となる。計測の結果、Δp=5s以内のネットワーク伝搬を保証するためには、ブロックサイズは2MBを超えないようにする必要があることがわかった。計算量の多いスクリプトを考慮すると、検証時間はさらに低い制限を課すことができる。
良いニュースは、これらの制約の中で、peer-to-peerネットワークやコンセンサス層に変更を加えることで、トランザクションのスループットを超えることができることです。以下、これらの技術について説明します。
拡散パイプライン
図1を再考すると、すべてのノードのアクションは厳密な順序で実行されるため、Δpは1つのノードの所要時間にピアツーピア経路のホップ数を掛けたものに適合する必要があることがわかります。これはネットワーク伝送には必要であるが、ブロック検証には必要ないことがわかる。
図2を考えてみましょう。完全な検証が行われる前にブロックが伝搬されるようにすることで、伝搬経路から（繰り返される）本体検証を除外することができます。ピア1がブロック本体（b-box）を受信したらすぐに、ブロック本体の検証などと同時にブロックの伝搬を開始することができるのです。
図1の方式とは対照的に、Δpバジェットは現在、ボディ検証を一度だけ考慮する必要があります。この結果、ピアツーピアネットワーク伝送および/またはボディ検証のための時間バジェットが高くなり、より高いトランザクションスループットが可能になる（図1との比較を容易にするため、この利益はより大きなボディ検証（「bv」）バジェットによって説明されている）。
以下に説明する理由により、以下の2つの検証チェックが伝搬経路で完全に複製されたままであることが重要である。
- ヘッダーの正確さ、すなわちブロックがその前任者を正しく参照すること、および正しいブロックのリーダーシップ（VRF（Verifiable-Random-Function）およびブロックシグネチャの妥当性確認）。
- ブロックの完全性、すなわち、受信した（しかしまだ検証されていない）ボディが、ヘッダーのボディハッシュによって実際に参照されていること。
拡散パイプラインはコンセンサス層とネットワーク層のセキュリティにどのような影響を与えるのでしょうか？
まず、コンセンサス層はこの変更に影響されないことに注意してください。
- ブロックリーダーは新しいブロックに付加されるチェーンと新しいブロック自身を完全に検証するので、正直なブロックは常に有効である。
- 不完全なブロックは伝搬されない（上記ポイント2による）。
- 無効な（完全な）ブロックは、ネットワークを通じて伝搬される可能性はあるが、本体検証後に正直なノードによって常に破棄される。
第二に、ネットワーク層へのDoS（Denial-of-Service）攻撃について、敵は無効なブロックを拡散することでシステムを輻輳させようとすることができることに注意する必要があります。しかし、正しいブロック・リーダーシップは（ポイント1により）まだ検証されており、そのようなブロックは、敵がそうするように予定されている場合にのみ伝播される、すなわち、このブロック・リーダーが正直だった場合よりも負荷が発生しない（システムのスループットに貢献しないブロックは除く）ことを意味しています。さらに、無効なブロックを生成するステークプールオペレーター（SPO）を簡単に特定し、罰することができます。実際、まさにこの機能を実行する違反管理システムが現在開発中です。
結論として、拡散パイプラインは、コンセンサスルールを変更しないまま、Δp制限内のブロック伝搬と検証時間の予算を増やし、より大きなブロック、ひいては取引のスループットを向上させることが可能です。これは、システムへの侵襲を最小限に抑えながらスループットを大幅に向上させることが可能であり、短期的な実装の候補として優れています。しかし、パイプライン化の効果は限定的であり、私たちの野望はここにとどまりません。
次に、さらに高いトランザクションスループットを達成できる、より強力な技術の概要を述べますが、これにはより劇的なプロトコルの変更が必要です。
非同期検証
拡散パイプラインの背後にあるアイデア、すなわち本体検証の遅延は、極端に言えば、新しいブロックがΔp以内に到着することは必要ですが、その本体検証がΔp以内に完了することは要求されません。これを非同期検証(Asynchronous Validation: AV)と呼ぶ。
図3を見てほしい。ボディ検証は（ブロック送信とヘッダー検証以外の）残りの（予想） Δbバジェットを実質的に消費することが許されているため、ノードのCPUは 実質的に永久的な負荷にさらされることになる。しかし、ネットワークリンクとCPUは他のタスク(mempoolの同期など)にも割り当てられていることに注意。つまり、残りのΔbをすべてボディ検証に使うのではなく、数秒を他のタスクに割り当てたままにしておきたいのである。
これには注目すべき副次的効果がある。拡散パイプラインとは対照的に、元帳の検証は一般的にチェーンの先頭から遅れます。特に、現在では誠実なブロックリーダーでさえ、新しいブロックに至るまでの取引履歴の検証を終えていない可能性があるため、（部分的に）無効なブロックを作成する可能性があります。
この副作用に対処するため、元帳のルールを変更する必要がある。正直なブロックが常にコンセンサスの安全性に貢献することを保証するため、無効な取引を含むブロックは依然として有効なチェーン拡張と見なされる必要があるのだ。無効な取引は元帳の検証時に単純に破棄することができる。
拡散パイプライン方式よりも大幅に改善されているが、AVはさらに改善することが可能である。その理由は、一般にΔpの間に十分なデータを拡散できず、残りのΔbの期間にCPUをフル稼働させるのに十分な検証作業ができないからです。AVの利点を十分に活用するために、我々はAVと入力支持者のメカニズムを組み合わせる。
インパクト
パイプラインとAVは、スループットにどのような影響を与えるのでしょうか？この質問に対する正確な答えを見つけることは、私たちのネットワークと研究チームによってまだ進行中の作業です。なぜなら、悪意のある敵対者（プロトコルを最大限に混乱させようとする）の場合に厳密な分析を行うことは、かなり複雑だからです。それでも、最初の推定値を提供するために、我々は、すべてのSPOが正直に行動する楽観的な場合のスループット分析を以下に与える-悪意のある場合の結果が大幅に逸脱しないことを期待して（違反管理システムの存在も考慮して）。ただし、システムの実際のスループットは、与えられた推定値とは異なる可能性があることに注意してください。
表 1 では、これらのスループット推定値を示しています (単位は 1 秒あたりのトランザクション数、TPS)。スループットはトランザクションのサイズと検証時間の両方に依存することを思い出してください。サイズと検証時間の組の選択について、すべてのトランザクションが同じ特性を持つと仮定し、それぞれのスループット数値を示す。4つの異なるプロトコルを比較する。
- Praos。Cardanoが現在展開しているプロトコル（ブロックサイズ80kB）。
- Praos Max：（上記の仮定のもと）安全に維持できる最大限のブロックサイズを持つPraos
- 拡散パイプライン
- AV（Δbバジェットの20％を割り引き、異なるタスクに割り当てる）
ここでは、サイズと検証に要する時間が異なる4種類のトランザクションを考える。単純な支払取引は 0.5kB / 0.5ms のカテゴリーに近いですが、スクリプト取引は他のタイプのいずれかに該当し、より大きなサイズと検証のためのより多くの労力の両方を必要とします。最後の列（2kB / 32ms）では、検証時間がネットワーク遅延と比較して大きくなっていることにも注目してください。ブロックサイズを大きくしても（PraosからPraos Maxへ）、検証時間がすでに最大になっているため、スループットの改善にはつながりません。その結果、パイプラインとAVは、検証時間のバジェットを増加させるので、まさにこのような場合に強い相対的な利益をもたらします。
カルダノの展望
パーミッションレス・ブロックチェーンのスループットを向上させることは、システムにより多くの負荷を与えることでDoS攻撃の機会をもたらす可能性があるため、セキュリティ上非常に重要です。そのため、このような変更は、システムへの影響を注意深く観察しながら、小さなステップを順番に実行することが望ましいとされています。
このような最初のステップは、昨年12月と今年2月にブロックサイズの制限（およびPlutusスクリプトのメモリユニット）を64kBから80kBに引き上げることで行われました（John Woodsによる最近のブログもご覧ください）。
今後数ヶ月間、ネットワークの需要や容量の制約に基づいて、これらのパラメータを注意深く監視し、調整し続ける予定です。拡散パイプラインの実装により、さらなる改善が期待されます。インプットエンドーザーを含むその他のコンセンサスの最適化については、まだ開発中であり、これらの実行方法の詳細については、いずれ発表される予定です。
カルダノ Basho時代の最適化の試みは、ネットワークとコンセンサス層にとどまらず、Plutusスクリプトの強化やオフチェーン処理も含まれていることに注意してください（Tim Harrisonによるこの最近のブログを参照ください）。特に、現在開発中のレイヤー2プロトコルスイートであるHydraは、オフチェーンでの取引実行を可能にすることで、取引全体のスループットを劇的に向上させる別の道筋を提供します。
謝辞 Duncan Coutts, Sandro Coretti-Drayton, Neil Davies, Alexander Esgen, Nicolas Frisby, Peter Gaži, Philipp Kant, Aggelos Kiayias, Karl Knutsson, Tim Harrison, Giorgos Panagiotakos, Alexander Russell, Fernando Sanchez, Marcin Szamotulski, Peter Thomas, Spyros VoulgarisそしてJohn Woodsに感謝したい。
