Cardanoの最適化

プルーフオブステークブロックチェーンとして、Cardanoは安全性とネットワーク障害耐性が高まるよう設計されています。Ouroboros（ウロボロス）コンセンサスアルゴリズム、形式手法を使用したHaskellのビルトイン、査読を受けた学術研究によって推進されるCardanoは、分散化された非常にスケーラブルな方法で何百万ものトランザクションをグローバルに処理する、堅牢な環境を提供するために設計されています。

以前のブログ記事で、トランザクションを処理、検証し、これに署名する際に、システムが全体としてどう作動するかというネットワークパフォーマンスについて論じました。長期にわたって維持できるシステムを構築する場合、ごく初期の段階で、適切な設計にすることが重要です。ネットワークキャパシティは貴重なリソースであるため、最も効率的なパフォーマンスメトリクスを実現するためには、計算、メモリー、ストレージ、ネットワークリソースを効果的に消費することが重要です。

Cardanoは柔軟性を意識して構築されています。スループットの最大化だけでなく、需要の増加に対応できるよう設計されています。ネットワークが成長するにつれ、価格変動に対応したり、スケーラビリティやスループットプロパティを拡大するために、プロトコルパラメーターを調整します。ここでは、ネットワークパフォーマンスを長期的に最適化する方法について詳しく見ていきます。

渋滞の定義

ネットワークから道路まで、効率的なシステムは渋滞を最小化するよう、そして、これが生じたときには効果的に管理できるよう構築されています。ブロックチェーンに関して言えば、渋滞はネットワークが過飽和となり、大量のトランザクションを処理し、関連するブロックに署名することが困難になっている状態を指します。Cardanoブロックは所与のエポックで平均25%が活用されています。つまり一般的に、ネットワークは混雑しておらず、大量のトランザクションですら処理できるほどの十分なゆとりが設けられています。

Cardanoは、過飽和状態であっても、公正姓と高い回復性を保つよう設計されています。では、現在のパラメーター設定を振り返り、今後の最適化プランについてみてみましょう。現在のパフォーマンスメトリクスは、以下の測定値に依拠しています。

• スループット - 転送されるデータ量。現在のブロックサイズは64KBに設定されています。単一のPlutusスクリプトトランザクションは現在最大16KBに設定されており、単純なトランザクションは通常300バイトほどを使用します。こうした基準は、良好なネットワーク使用率とトランザクションを確保しつつ、待ち時間を最小化するためのバランスを考慮したものです。一度に急激に増加すると、ブロックの適応時間に遅延が生じることになります。これは、スループットと適時性が互いに緊張関係にあるためで、スループットの最大化はネットワークパフォーマンスの向上を意味しますが、システムが過飽和状態にあるときは遅延が増加するというリスクが生じます。
• 適時性 - ブロックの適用時間。ブロック適応のための総「タイムバジェット」は、ブロックがネットワーク全体（ステークの95%）に伝播する時間として5秒に設定されており、Plutusスクリプトに利用できるバジェットはおよそ５０ミリ秒です。これは、ブロックがスクリプトと単純なトランザクションの両方を、偏りなく含められるよう設計されています。

最近、大規模なNFTドロップにより、トランザクション処理の待ち時間に記録的な増加が生じました。この過飽和は、大量のNFTが同時にリリースされ、以下を引き起こしたために生じたものです。

• 大量の同時NFTトランザクション
• 複数のユーザーが同じNFTを購入しようとしたことによる、トランザクション処理の同時発生
• NFTを購入できなかったユーザーへの返金トランザクションの同時発生

このシナリオでは、NFTの販売にネットワーク容量が追いつかなかったため、供給の43,000%に相当する膨大なサービス需要を引き起こしました。「渋滞」時間が１時間以内であったことも特筆に値します。

これは成長途上にある市場であり、NFTクリエイターたちはすでにユーザーエクスペリエンスへのこのようなドロップの影響を最小限に抑えるために、プロセスのイテレーションを始めています。 これはいまだ初期段階で、私たちは迅速に学習しています。NFTのミント（発行）プロセスは完全に並列処理できるため、このプロセスに制限はありません。いったんミントされると、取引に必要とされるプログラム可能なスワップコードと資産が格納されたNFTは、市場とやり取りする準備が整います。

ただし少なくとも短、中期的には、道幅を広げるよりもトラフィックシステムの効率を上げることが課題となります。中には、特にNFTドロップを対象に、コスト、そして短期的なネットワーク負荷を削減するようなシステムを生み出している開発者もいます。

分散型取引所（DEX）

Cardanoに構築された初期のDAppの多くはDEXです。 また、一部のアプリケーションでは、ユーザーは注文時に競合を経験する傾向があります。全ステータスが1つのUTXO内に格納される（複数のUTXOに拡散されずに）というDApp設計の前提条件により、将来のトランザクションは前回のトランザクションからの出力に依存するようになります。これは、並行性「問題」として広く参照されています。しかし、自動車に例えるなら、これは、英国や日本で左側走行が「問題」となる程度のことです。習得する必要はあるものの、所詮は物事のやり方が違うだけの話です。開発者が習得しようとしなければ、もちろん問題に直面することになるでしょう。また、本質的に複雑というわけでもありません。単に異なるアプローチが必要なだけです。

CardanoのEUTXOモデルは、アカウントベースモデルとは異なります。Cardanoに構築されたDAppはシングルスレッドのステートマシンスタイルから離れ、抽象レベルを直接EUTXOに下げ、EUTXOグラフの同時エッジを含むソリューションを構築する必要があります。様々なUTXOセットを使用することは重要です。これによって、システムのスループットを改善しながら、個別操作のパフォーマンスを変えずに保つ並列性が強化されます。確かに、イーサリアムのアプローチに慣れている開発者にとっては、意識をシフトすることが求められます。しかし、UTXOベースモデルはアカウントベースモデルよりも安全です。これは、単一のアカウントにすべてのステータスを維持すると、攻撃に対して脆弱さが増すためです。並列手法を適切に使用することで、ユーザーは、スループットとスケーラビリティに関して向上された結果を享受できますが、オフチェーンソリューションはUTXO台帳により適しています。詳細は、並行性に関するブログ記事 と、スケーラブルなPlutus DAppの構築方法をお読みください。これに関してはそのうちに、追加のコンテンツを公開してモデルを最大限に活用するためのガイダンスを提供します。

最適化のロードマップ

初期公開時の焦点は常に、最適化の前にまずコア機能と正確性にあてられています。これは常に、私たちが表明している目標です。私たちは、パフォーマンスの監視とベンチマークの調整を続けています。ネットワークが成長し、Cardanoがより大容量で機能するようになると、ネットワークの需要に対応するためにパラメタリゼーションを調整します。これらは段階的なアップグレードであり、変更がネットワーク要件を満たし、さまざまなプロパティで妥協しないようにするために、今後数か月にわたって徐々に実装されます。

すでに広範な分析を実施し、データ拡散時間を正確に測定するノードメトリクスの実装を開始しました。データ拡散とは、ブロックチェーンを検証するノード間でトランザクションとブロックを分散するプロセスです。コンセンサスアルゴリズムが決定を下せるように、ノードに必要な情報を提供することが不可欠です。

トランザクションの送信からトランザクションの適用までの平均待機時間を実装する可能性があります。それに加えて、次のような短期的および長期的にネットワークパフォーマンスを繰り返し向上させるシナリオを調査および分析しています。

• ブロックサイズの拡大 — ブロックサイズを拡大すると、ブロックにより多くのトランザクションを含めることができます。この利点は、ネットワークが飽和状態のときに、トランザクションがブロックに適用されるまでの待機時間が短くなります。しかしこれには欠点もあります。ブロックが大きいと、ネットワークへの伝播に時間がかかるのです。また、トランザクションの検証にノードが必要とする時間も長くなります。ブロックサイズの拡大はネットワークパフォーマンスを高めるオプションの1つではありますが、実行する際には注意が必要です。拡大してもブロックの適用時間に影響を与えないようにするために、私たちはパラメーターを段階的に変更し、飽和期間に結果を査定します。これは一度にできる更新ではなく、イテレーションアプローチによって明確な結果を取得しながら、もっとも効率的な調整を行っていきます。
• メモリープールサイズ — 現在、メモリープールのサイズは128KBに設定されています。これはブロックサイズのほぼ2倍です。メモリープールはネットワークのバッファとして機能し、ブロックにトランザクションを適用する際にやや遅延を生じさせる可能性があります。しかし、メモリープールサイズの拡大によって、ネットワークのスループットが改善されることはありません。トランザクションキューは変わりません。メモリープールは、くじアルゴリズムによって選択された生成ノードに基づいてランダムに入力される新しいトランザクションが、公正に適用されることを可能にします。
• スクリプトの圧縮 — 現在トランザクションサイズが16KBに設定されている中で、プロトコルが透明性を保ちながらコードを「zip」できるように、圧縮に取り組んでいます。これでサイズが削減されると、より多くのスクリプトトランザクションが1つのブロックに格納できるようになり、開発者はより多くの洗練されたコードを16KB以下に圧縮して送信することができ、他のトランザクションにもより多くのスペースが残されることになります。

EUTXO向けアーキテクチャー

以前の並行性に関するブログ記事で説明したように、CardanoのEUTXOモデルは、DeFiアプリケーションの設計にまつわるあらゆるレベルの問題を排除します。トランザクションを並列処理できるというEUTXOに本来備わる能力に加えて、このモデルの持つ決定性により、開発者とユーザーは不要な「ガス」を避けることができます。

すなわち、EUTXOモデルはアカウントベースモデルと同じではないということです。アカウントベースのシステムを対象としたアプリケーションアーキテクチャーをEUTXOベースのシステムに移行しても、アプリケーションの設計は最適化されません。CardanoのEUTXO用に特に設計されたアプリケーションは、最高のユーザーエクスペリエンスを提供します。

たとえば、EUTXOモデルへの注文の送信と処理を開発者が最適化する方法などについて、技術的な詳細を深く掘り下げた記事をまもなく公開します。

イテレーションと改良

進化、イテレーションを続ける中で、舞台裏では数多くの作業が進んでいます。まだ初期段階ではありますが、ネットワークパフォーマンスを継続的に査定し、それに応じてパラメーターを調節していきます。短期的には、ステーク分布と報酬分配の計算をより均等に拡散することによって、NFTドロップの渋滞を緩和することができます。これにより、次にブロックサイズを拡大して、エポック境界における一時停止や渋滞を解消し、計算スパイク（ブロック伝播の遅延につながる可能性を持つ）を排除することができます。段階的なブロックサイズの拡大によっても、ネットワークパフォーマンスにとってベストケースのシナリオを査定することができ、こうした結果はすぐにネットワークで可視化されます。

また、台帳ステータスをディスクストレージに移して、スクリプトの圧縮やオンチェーンの共有機能の実装とともに、オンチェーンの負荷を軽減するプランも立てています。完成すれば、ネットワーク調整を大いに補完することになるでしょう。

中期的には、Hydraが追加機能をもたらします。長期的には、チーフサイエンティストとチームが、価格設定フレームワークに関して他の手法やメカニズムの研究を続け、トランザクションスループットを増加させるためにOuroborosプロトコルを強化します。詳細は、今後のブログ記事にご期待ください。

2か月経過

Cardanoでスマートコントラクトの時代が幕を開けてからたった2か月しかたっていません。「公開」にあたりどのような期待や予想がなされたかにかかわらず、これは一回きりの大きな更新で済むものではありませんでした。ちょうどエコシステムで弾みがつくまでには常に時間を要するものであるように、ネットワークへの要求が高まるにつれて、設定し、それから調整するという期間が必要となりました。私たちは道の途中であり、コミュニティからにフィードバックを理解することが大切であることは変わりません。たくさんのエキサイティングな新プロジェクト#BuildingOnCardanoと話し合いながら、私たちは必要に応じてサポートできるように、そのプランや目的、そして彼らが直面している問題についての理解を深めています。私たちはコミュニティの議論も注意深くフォローしています。

今はまだ初期段階で、私たちはいまだに学習しています。それでも、Cardanoは設計上、新生の（しかしすでに活気に満ちている）エコシステムとともに自在に成長していくよう設定されています。みんなで構築を続けましょう。

ガイダンス、サポートを希望する、または、単にオープンセッションに顔を出して話がしてみたいという開発者は、Discordで成長中の技術コミュニティにぜひご参加ください。

本稿の執筆にあたり、助言、フィードバックを提供してくれたJohn Woods、Vitor Silva、Kevin Hammond、Duncan Coutts、Romain Pellerin、Michael Peyton Jones、Jean-Frederic Etienne、Olga Hryniuk諸氏のご協力に感謝します。