Cardanoはグローバルに分散化された方法で、何百万ものユーザーに提供されるよう設計されています。これは、他の分散型ブロックチェーンと同様に、新たなブロックを予測可能的かつ継続的に供給する必要があることを意味します。新ブロックはチェーンを集合的に拡大し、ユーザー間のトランザクションを記録して透明化します。新ブロックをネットワーク全体に効率的かつ安全な方法で伝播させるためには、システムは計算、メモリー、ストレージ、ネットワークといったリソースを効率よく消費することが重要です。
フレキシビリティは要です。したがって、Cardanoプロトコルの重要な機能は、真のスケーラビリティを念頭に置いて構築されています。これは単に、グローバルな完全分散型オペレーティングシステムに長期的なインフラを提供する機能性に限られません。そのパラメーター型アプローチもまた、価格変動やネットワークの飽和状態、需要の増加などに柔軟に対応し、調整できるよう設計されたものです。多くのプロトコルパラメーターは、ハードフォークを必要とせずにシステム動作を調整できるよう提供されています。それでも、より重要なアップグレードが必要な場合には、ハードフォークコンビネーター技術(HFC)を使用して手際よく管理します。これはともにCardanoを差異化している重要な要素であり、現在の堅牢性および信頼性を提供するとともに、ネットワークの成長や使用の進化に伴うアップグレードを極めてアジャイルなものにしています。
Cardanoのロードマップも、最終目標に向けて一歩一歩進む段階的アプローチで考案されました。Byronは、連合型ネットワークによる基本的なトランザクション機能を提供する開発期でした。ここでは、次段階に取り組みながら、コミュニティやパートナーシップの構築を始めることができました。Byronリブートで新たな機能を構築する堅固な基盤が提供される一方、Shelleyではステークプールが導入され、コミュニティがさらに拡大し、ブロック生成の100%分散化が達成されました。
今年も、数多くの待ち望まれていた新機能が導入されています。2021年初頭のMary期の開始以来、Cardano台帳ではマルチ資産とNFT作成がサポートされています。低コスト、スマートコントラクト不要という条件の下、このエキサイティングな分野では活発な活動が行われています。9月のAlonzoアップグレードでは、幅広い分散型アプリケーション(DApp)の開発を可能にするPlutusスマートコントラクトのサポートが導入されました。スマートコントラクトに関してはまだ初期段階ではありますが、数多くのプロジェクトがDAppに取り組んでおり、少なからぬ数がデプロイ段階に近づいています。まもなくこの動きは加速し始めるでしょう。こうした新機能は、台帳が新しいスクリプトやトランザクションを処理する方法に影響を与え、利用可能なリソースに対する新たな需要をもたらします。アクティビティの拡大に伴い、このアーキテクチャーは必要に応じて柔軟に対応するアジリティを提供します。
ネットワークキャパシティ
ネットワークは全Cardano運営の中心にあります。Cardanoネットワークは、ブロックチェーンを生成し検証するグローバルに分散したノード全体に、トランザクションとブロックを分散させています。これはデータ拡散(data diffusion)と呼ばれ、コンセンサスアルゴリズムの意思決定に向けてノードに必要な情報を提供するために欠かせないものです。こうした決定によりチェーンは拡大します。ノード間のコンセンサスは、すべてのトランザクションが検証され、認証され、それゆえに透明性をもって新しいブロックに含まれることを保証します。
Cardanoは分散型のOuroboros Praosコンセンサスプロトコルを基盤としています。Cardanoは、以前の連合型Ouroboros Classicプロトコルから、プロトコルパラメーターdの段階的変更を経て、Praosにスムーズに移行しました。Ouroboros Praosはセキュリティ強化を確立し、トップレベルのサイバーセキュリティ関連および暗号学の学術会議や雑誌で査読を受けた論文とともに配信されました。
ネットワークパフォーマンスはシステム全体の動作スピードに影響します。これには以下の基準が含まれます。
- スループット(転送されるデータ量)
- 適時性(ブロックの適用時間)
これら2つの要件は互いに緊張関係にあります。スループットは、生成されたブロックが最も効率的に使用されたときに最大化できます。これはすなわち、待ち時間を隠すのに十分なバッファリングを意味し、グローバルな分散型システムの影響を軽減します。
バッファリングの増加は通常ブロック(およびネットワーク)の効率的使用を意味しますが、システムが飽和状態になると遅延(チェーンに適用する時間)を増加させることにもつながります。
ブロックバジェット
トランザクションやスクリプトがCardanoでどれくらいの速度で実行されるかを理解するためには、まずブロックバジェットの概念を定義する必要があります。現在、ブロック全体のサイズは最大64KBに制限されています。これは、ネットワークの効率的な使用とトランザクション待ち時間の最小化のバランスを表しています。1つのブロックにはさまざまなトランザクションを含むことができます。これには、Plutusスクリプト(スマートコントラクト)付きのもの、ネイティブトークン、メタデータ、そしてもちろんシンプルなADAトランザクション(支払い)などが含まれます。同様に、1つのトランザクションサイズは現在最大16KBに制限されています。これは、1つのブロックが常に複数のトランザクション(最小4、通常はそれよりも多い)を含むことを保証しており、全体的なトランザクションスループットを向上させています。
ブロックタイムバジェットはまた別のプロパティで、1つのブロックに含まれるすべてのトランザクションを処理するために使用できる一定の時間です。これは、Plutusスクリプトの実行に使える時間と、その他のトランザクション実行用の時間に分けられています。このプロパティにより、Plutusスクリプトを使ったトランザクションが利用可能なタイムバジェットを独占することなく、Plutusスクリプトを含むブロックと同じブロックにある単純な送金をシステムで必ず処理できるようになっています。各ブロック(ネットワークコストを含む)を生成するタイムバジェットの合計は1秒に設定されており、Plutusスクリプトの実行に使用できるのはおよそ50ミリ秒です。実際には、これでかなり余裕があります。ベンチマークでは、参照システムで実際の多くのスクリプトは1ミリ秒以下で実行できることが示されています。
ブロックタイムバジェットは現在1秒に設定されています。セキュリティ上の理由から、Praosコンセンサスプロトコルは、チェーンに追加される可能性のあるブロックのごく一部(20分の1)のみを選択します。したがって現在のプロトコルパラメーターでは、最大トランザクションスループット(単純なトランザクション)は毎秒およそ11トランザクション(TPS)です。当然、各トランザクションはサイズもばらばらで、有効ペイロードも異なります。たとえば、1つのトランザクションでCatalystの投票ラウンド全体を完了したり、数百万ドル相当の送金を行うこともできます。
前述したように、各ブロックは、エンドユーザーによってウォレットやコマンドラインインターフェイス(CLI)から送信された多数のトランザクションを含んでいます。これらのトランザクションは、処理され、ブロックに含まれる準備が整うまで、一時的にメモリー内の格納領域(メモリープール)で保持されます。保留中のトランザクションは、ブロックがミントされるとメモリープールから取り出され、次に新たなトランザクションがメモリープールに追加されます。私たちは固定サイズのメモリープールを使用することにより、受容の高い期間にノードがオーバーロードする可能性を回避していますが、これはウォレットやアプリケーションがトランザクションを再送信する必要が生じる場合もあることを意味しています。メモリープールサイズは現在128KB、現在のブロックサイズの2倍に設定されています。これは、キューイングモデルを基に選択されました。
ネットワークの拡大
Ouroborosは大量のデータ、さまざまな複雑性やサイズを持つトランザクションやスクリプトを処理できるよう設計されています。現時点で、現行のパラメーターにより、Cardanoネットワークは平均して容量の25%程度しか使用していません。もちろん、最も効率的なシナリオはCardanoが容量の100%かそれ近く(ネットワーク飽和状態)で稼働することです。多くのネットワークソリューションがこのような条件では苦戦を強いられますが、OuroborosとCardanoネットワークスタックはともに過度な飽和状態でも公平で高い回復性を持つよう設計されています。ベンチマーク分析によると、200%飽和状態でも、全体的なパフォーマンスは高い回復力を誇り、ネットワーク障害は生じていません。44xストレステストでも、利用可能なネットワークキャパシティの総量は障害を示していません(ただし、一部のトランザクションにわずかの遅延が出る場合もあります)。ネットワークは、バックプレッシャーを使用してシステム全体の負荷を管理し、このように動作するよう設計されています。たとえば、大規模なNFTドロップに参加する一部の個人ユーザーのトランザクション待機時間が長めになったり、大きなバッチから不定期にトランザクションを再送信する必要が生じる(または長めの時間をかけてドロップを分散させる)場合もありますが、これはネットワークが「苦戦している」わけではありません。実際、ネットワークは意図したとおりに実行されています。これは「グレースフルデグラデーション」と呼ばれます。
ウォレット
ウォレットは、エンドユーザーに代わって、支払いやその他のトランザクションをブロックチェーンに送信し、ブロックチェーンステータスを追跡します。ウォレットが提供する主要なサービスの1つは、ユーザーに代わってトランザクションを送信し、それがブロックチェーンに受け入れられたかを確認し、送信が失敗した場合には再送信を試みることです。すなわち、ウォレットはネットワークが飽和した際のバックプレッシャーや、その他のネットワークの影響(一時的切断、潜在的チェーンフォークなど)を考慮できなければなりません。ウォレットは次のいずれかになります。
- フルノードウォレット(Daedalusなど):ローカルの計算およびネットワークリソースを使用して、Cardanoネットワークに直接接続されるノードを実行する。
- ライトウォレット:対照的に、計算およびネットワークリソースを共有して多くのエンドユーザーにサービスを提供する。
需要が高い期間(NFT販売時など)には、両タイプともトランザクションの再送信が必要となる場合があります。ライトウォレットはリソースを多くのユーザーで共有しているため、需要に確実に応えられるように一時的に使用可能な計算およびネットワークリソース(エンドポイントの複製を含む)をスケールアップする必要が生じる可能性もあります。この需要対応型スケーリングは企業が人気新製品をリリースするときなどに必要となるものと似ています。対照的に、フルノードウォレットは本質的に影響を受けません。トランザクションがわずかに遅延することはあるかもしれませんが、各ウォレットには、ネットワーク接続を含み、再送信に必要な専用リソースが備わっています。同様の原理がDAppプロバイダーにも当てはまります。特定のネットワークエンドポイントが提供されているため、システムリソースは需要に合わせてスケーリングできます。
プロセスの最適化
私たちは、現在NFTコミュニティで見られるようなイノベーション(や対話)をもちろん歓迎しています。ユーザーエクスペリエンスを向上させるためには、たとえばNFT作成プロセスがシステム飽和状態でも機能するようになど、開発プロセスの最適化が必要です。たとえば多くのNFTクリエーターが、効率を上げるためにバッチミントを使用しています。
クリエーターには、ネットワーク渋滞を最小限に抑えるために、どうすれば自分たちの労力を最適化し続けられるかを考えて欲しいと思います。また、全員に、クリエーターコミュニティの一員としてDiscordでの議論に参加することを奨励しています。特定のケースに最適なソリューションを見つけられるよう、エンジニアがサポートできるようにします。
パラメーターの調整により実現される(必要に応じて1エポック内で可能)柔軟性に加えて、中長期的にはさらにオプションが登場します。Hydraは複数の操作を並行して実行することを可能にし、スケーラビリティを強化します。そのステートチャネルソリューションによりシステムスループットが増加し、オンチェーンでの実行の需要を軽減します。Hydraはマルチスケーラビリティのユースケースに役立ちますが、NFT作成の効率化に具体的に対処するわけではありません。Cardanoの成熟、拡大に伴い、ネットワークを最適化し、ネットワークキャパシティを管理する方法を引き続き検討していきます。10月の月半ば更新情報で紹介したように、ネットワークがより高いキャパシティで実行され始めたら、必要に応じてCardanoパラメーターを調節することが可能です。たとえば、ブロックタイムバジェットを削減したり、Plutusスクリプトのサイズや実行時間を最適化したり、実行コストを下げてスループットを改善するなどです。
Discordコミュニティに今すぐ参加して詳細情報を学び、専門のコミュニティでCardanoについてさまざまな議論を行ってください。
本稿の執筆にはNeil DaviesおよびOlga Hryniuk両氏にご協力いただきました。
最新の記事
Input | Output chief scientist receives prestigious Lovelace computing award 筆者: Fergie Miller
3 December 2024
Delivering change in Ethiopia: lessons and reflections 筆者: Staff Writer
28 November 2024
Applying formal methods at Input | Output: real-world examples 筆者: James Chapman
26 November 2024