Cardanoトランザクションスループットの増加

最近Cardanoでスマートコントラクトが導入されたことにより、ユーザーアクティビティが大幅に増加した。同時に、コードを運搬するスクリプトトランザクションのために、平均トランザクションサイズも拡大している。Cardanoエコシステムに最初の分散型金融（DeFi）アプリケーションが展開され、さらに多くが期待される中で、この傾向は続くものと思われる。この拡大する需要に対応するためには、システムの現トランザクションスループットを増加させる必要がある。

トランザクションスループット増加への明白なアプローチは、ブロックごとにより多くのトランザクションを含められるよう、ブロックサイズの上限を増やすことだ。ブロックサイズは、今年すでに64kBから80kBへと25%増加させており、さらなる増加を予定している。しかし、ブロック生成率を現状レベルで維持しながら、台帳コンセンサスプロトコルで安全に維持できるブロックサイズには限りがある。システムの安全性を脅かすことなく高スループットを達成するには、別の方法が必要となる。この理由を理解するために、一般的な台帳コンセンサスの仕組みを説明する。

台帳コンセンサスプロトコルは2つのタイムパラメーターで特徴づけられる。

• Δp：新ブロックがネットワークの（たとえば）95%に達するためのネットワークの最大遅延
• Δb：2つの新しいブロックを生成する間の（予想される）時間

通常のプロトコルでは、コンセンサスの整合性を示す場合、少なくともほとんどの場合において、次のブロックが生成される前に前ブロックの伝播が終了している必要がある。したがって、ΔbはΔpよりもいくらか大きくなるように選択される。Cardanoでは、Δp=5s（秒）、Δb=20sである。

では、こうした条件下でどれだけのデータが1つのブロックで転送できるだろうか。これを知るためには、Δp内で達成すべきことを詳しく見る必要がある。

図1：Δp=5sバジェット内におけるブロックのネットワーク伝播と検証

上記図1は、ネットワーク内のブロック伝播の仕組みを簡単に表している。ブロック生成者は新しいブロックのヘッダーをピア1（白のhボックス）に送る。このとき白のhボックスが示す期間、両ノードのネットワークリンクはふさがれている。次にピア1はヘッダーを検証（グレーのhvボックスに示される期間ローカルの計算機能を使用）。ヘッダーが有効の場合、すなわちブロックリーダーシップその他が適切であることがヘッダーに証明されると、ピア1（白のbボックス）はブロックボディをダウンロードする。この際、再び両ノードのネットワークリンクはふさがれる。最後に、ピア1がブロックボディ（グレーのbvボックス）を検証し、ブロックボディも有効である場合に限り、ピア1は今説明した通りに他のピアにブロックを伝播する準備が整う。

この操作モードの残念な副産物は、単一ノードのCPUとネットワークリンクがΔp=5sというほんの短い時間だけ活用され、残りのΔb=20s（と予想される）時間（ほぼ）アイドル状態にあることだ。

具体的にはブロックに納められるデータ量は、ピアツーピアネットワークのブロックの遅延と検証に必要とされる時間によって決定される。両者とも、ブロックサイズに、前ノードの95%に達するために必要な最大ホップ数を積算した、ほぼ直線的に増大する。測定では、Δp=5s以内のネットワーク伝播を保証するためには、ブロックサイズは2MB以下であるべきことが示されている。計算量の多いスクリプトを考慮すると、検証時間によってさらに低い制限が課される可能性がある。

幸い、この制限内に置いて、ピアツーピアネットワークやコンセンサス層に変更を加えることによって、トランザクションスループットを増やすことができる。この手法を以下に説明する。

拡散パイプライン

再び図1に目を向けると、すべてのノードのアクションは厳密なシークエンスで実行されている。したがって、Δpは単一ノードに必要な時間にピアツーピアのパスにおけるホップ数をかけたものに適合させる必要がある。これは、ネットワーク送信には必要だが、ブロック検証には必要ないと考える。

図2：拡散パイプライン

図2を見ると、ブロックをフルに検証する前にブロックの伝播を可能にすることにより、（繰り返しとなる）ボディ検証を伝播パスから削除することができる。ピア1はブロックボディ（bボックス）を受け取るとすぐに、ブロックボディの検証などと並行してブロックの伝播を開始することができる。

図1と対照的に、Δpバジェットはボディ検証を1回だけ考慮する必要がある。この結果、ピアツーピアネットワーク送信やボディ検証のタイムバジェットが増加し、より高いトランザクションスループットが可能となる。図1との比較を容易にするために、この増加分はボディ検証（bv）バジェットの大きさで示されている)。

以下に説明するように、次の2つの検証チェックが伝播パスで完全に複製されたままになっていることが重要だ。

1. ヘッダーの正確性。ブロックはその前のブロックとブロックリーダーシップ（検証可能なランダム関数VRFおよびブロック署名検証）を正しく参照している。
2. ブロックの完全性。受け取った（検証前の）ボディはヘッダーのボディハッシュで参照されている。

前述の拡散パイプラインは、コンセンサス層とネットワーク層の安全性にどのように影響するのか。

第1に、コンセンサス層はこの変更に影響されない。

• ブロックリーダーが新しいブロックと新しいブロックが追加されるチェーンを完全に検証するため、誠実なブロックは常に有効となる。
• 不完全なブロックは伝播されない（上記2による）。
• 無効（完全）なブロックは、ネットワーク経由で伝播される可能性はあるが、誠実なノードによるボディ検証後に常に破棄される

第2に、ネットワーク層へのサービス拒否（DoS）攻撃に関して、攻撃者は無効なブロックを拡散することによってシステムを混雑させようとする可能性があることに留意したい。しかし、正しいブロックリーダーシップが検証されている（上記1による）ということは、そのようなブロックは攻撃者がリーダーにスケジュールされている場合に限り伝播される、すなわち、このブロックリーダーが誠実である場合より多い負荷は生成されない（システムのスループットに貢献しないブロックを除く）。さらに、無効なブロックを生成するステークプールオペレーター（SPO）は簡単に特定され、罰せられる。事実、まさにこの機能を実行するために、現在違反管理システムを開発中である。

まとめると、拡散パイプラインはブロックの伝播と検証のタイムバジェットをΔp制限内で増加させ、より大きなブロックを可能とし、それゆえコンセンサスルールを変更せずにトランザクションスループットを増加させることができる。これは、システムへの低侵襲な変更で達成可能ながらスループットの大幅な向上が約束されており、短期的実装の優れた候補となる。それでも、パイプライン（のみ）の影響は限られており、これで最終とするつもりはない。

次に、より強力な手法の概要を紹介する。これはさらに高いトランザクションスループットを達成しうるが、より劇的なプロトコル変更も必要とする。

非同期検証

ボディ検証を遅延させるという拡散パイプラインの構想は、極論化できる。新たなブロックはΔpの期間内に受信する必要があるが、ボディ検証は必ずしもΔp内で完了する必要はない。これを、非同期検証（Asynchronous Validation：AV）と呼ぶ。

図3：非同期検証（AV）

図3を見ると、ボディ検証は、本質的に残りの（予想される）Δbバジェット（ブロック転送とヘッダー検証を除く）を消費することを可能にするため、実質的にはノードのCPUに永続的な負荷がかかることになる。しかし、ネットワークリンクとCPUも別のタスク（メモリープールの同期など）に割り当てられることに留意したい。つまり、Δbの残りすべてをボディ検証に使用するのではなく、このような他のタスクに割り当てるために数秒を残しておきたい。

これには顕著な副作用がある。拡散パイプラインと対照的に、台帳検証は一般的にチェーンのヘッドに遅れを取っている。とくに、誠実なブロックリーダーですら、新ブロックに至るまでのトランザクション履歴の検証が完了していない場合があるため、（部分的に）無効なブロックを生成してしまう可能性がでてくる。

この副作用に対処するために、台帳ルールを適用させる必要がある。誠実なブロックが常にコンセンサスの安全性に貢献するために、無効なトランザクションを含むブロックでも、有効なチェーン拡張とみなされなければならない。無効なトランザクションは、単純に台帳の検証中に破棄すればいい。

拡散パイプラインが大幅に向上されるが、AVにはさらに改良の余地がある。その理由は、一般に、Δpの間に不十分なデータを拡散し、Δbの全残り時間中CPUを最大限使用した十分な検証作業を実行できることだ。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が、検証用タイムバジェットを増加させることから、まさにこれらのケースで強力な相対的利益を提供する。

Cardanoの展望

パーミッションレスブロックチェーンのスループットを向上させることは、システムへの負荷を増やすことでDoS攻撃の機会を増やす恐れがあるため、セキュリティ上重要事項となる。したがってこのような変更は、小さなステップのシークエンスとして、システムへの影響を慎重に観察しながら実施することが望ましい。

その最初のステップは、昨年の12月後半と今年2月に実施された、64kBから80kBへのブロックサイズ制限（およびPlutusスクリプトメモリーユニット）の増加である（詳細はJohn Woodsによる最近のブログ記事参照）。

今後数か月間、ネットワーク需要と容量の制約に基づき、これらのパラメーターの綿密な監視、調整を続ける。さらなる改良は、拡散パイプラインの実装によってもたらされる。インプットエンドーザーを含むその他のコンセンサス最適化は現在開発中であり、これをどのように実行するかの詳細はまもなく発表される。

Cardano Basho期における最適化の取り組みはネットワーク層やコンセンサス層を超え、Plutusスクリプトの強化やオフチェーン処理にまで拡大される。詳細は、Tim Harrisonによる先般のブログ記事を参照されたい。ことに、開発中のレイヤー2プロトコルスイート、Hydra（ハイドラ）は、トランザクションをオフチェーンで実行できるようにすることによって、トランザクションの総スループットを劇的に向上させるためのもう1つの経路を提供する。

謝辞：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 Thompson、Spyros Voulgaris、John Woodsの諸氏に感謝いたします。