ブログ > 2021 > September > 並行性とそのすべて:CardanoスマートコントラクトとEUTXOモデル

並行性とそのすべて:CardanoスマートコントラクトとEUTXOモデル

CardanoのEUTXOモデルが、複数の操作をシステム障害なしに処理できるセキュアな多目的環境を提供

2021年 9月 10日 Olga Hryniuk 10 分で読めます

並行性とそのすべて:CardanoスマートコントラクトとEUTXOモデル

CardanoはUTXOベースのブロックチェーンであり、分散型アプリケーション(DApp)に、イーサリアムなどのアカウントベースのブロックチェーンとは異なるプログラミングパラダイムを活用します。Cardanoが使用する具体的なフレーバーは、Alonzoによって導入される拡張未使用トランザクションアウトプット(EUTXO)モデルです。EUTXOはより優れたセキュリティ、不快な驚きのないスマートコントラクトの実行コストの予測可能性、そしてその結果として、並列性への異なるアプローチを提供します。

EUTXOはUTXO(ビットコイン)モデルのブランチ(枝)設計を継承しています。ここでブランチは、定義上、一連の検証を必要とする一連のトランザクションです。異なるブランチにロジックを分割してより多くの並列処理を実行するためには、複数のUTXOを使用してDAppやその他のソリューションを構築することが不可欠です。これは、ビットコインのサービス開発が1つのウォレットをサブウォレットに分割することを前提としているように、スケーリングの点でメリットを提供します。

Cardanoに構築されたDAppはブロックにつき1トランザクションに限定されていません。実際、ブロックバジェット(保持できるトランザクション最大数)で、数百の単純なトランザクションと複数の複雑なスクリプトの実行が可能です。しかし、EUTXOモデルでは、トランザクションアウトプットを使用できるのは1回のみとなります。同じUTXOにアクセスしようとすると競合に直面する可能性があることから、多くの異なるUTXO使用することが重要です。このような設計がクライアントの厳密な序列の恩恵を受けられない限り、重要であることに注意してください。UTXOのセットは、セマフォを含む設計パターンを実装するために使用できます。さらに、異なるユーザーが、並行性を損なうことなく、1つのスマートコントラクトとやり取りできます。これは、スマートコントラクトが、現在のステータスを構成するさまざまな数多くのUTXOと、これらのUTXOを解釈することを可能にするオフチェーンメタデータを処理することができるためです。

並列で処理する

ブロックチェーンはトランザクション処理の普遍性と透明性をさまざまな方法で実現しています。どのようなブロックチェーンシステムでも、安全で迅速な操作処理への高まるニーズに対応する以下のプロパティを備えています。

  • スループット - 一定期間にシステムが実行できる操作数。たとえば、1秒間に処理するトランザクションやスマートコントラクトの数などに関係する
  • パフォーマンス - システムが動作する速さ。トランザクションやスマートコントラクトを実行する時間で測定する
  • スケーラビリティ - システムが複数の操作をネットワークの過負荷やパフォーマンスプロパティへの影響なしに実行する能力

並列性を強化することは、最終的に各操作のパフォーマンスを据え置きながら、システムのスループットを改善することに繋がります。しかし、この種のスケーラビリティは常に競合の度合いによって制限されます。

スケーラビリティは、さらに並行性並列性競合に区別されます。並行性は複数のアクターが互いに干渉することなく、特定のタスクを進めるために欠かせません。並列性はこのような進行を、いかなる干渉もなく、同時に行うことを可能にします。競合は、これら複数のアクターが、並行または並列で作業している際に、相互干渉した場合に発生します。

並行性の理解

並行性はシステムのパフォーマンス、スループット、反応性を向上させる場合もさせない場合もあります。並行性の程度により、同時に実行できる操作の最大数が制限されます。

UTXOベースのブロックチェーンで実際にパフォーマンスを向上させるためには、処理者や他のアクターは複数のアクションを同時に実行できなければなりません。並行性レベルが上がれば上がるほど、可能な並列性の最大値は高まります。このようなアプローチは、次にパフォーマンスの改良やスループットへと変換されます。また、アカウントベースシステム(イーサリアムなど)に対して大幅な利点も提供します。

UTXO台帳へのDAppデプロイは異なる

CardanoのDAppデプロイのアプローチは異なるため、学習と、異なるアプローチが必要になります。これは異なるプログラミング言語で作業するようなものです。ソリューションをデプロイするという目的は1つでも、この目的のために使用可能なプログラミング言語はたくさんあります。

並行性の最大化は習得が必要となるスキルです。開発者は、競合の機会を厳しく制限するようにコードを作成する必要があります(共有ステータスや偶然的依存関係の回避などによる)。システムはその後この並行性を並列性に変換します。多くの開発者はすでにこれにアプローチする方法を特定し、他の開発者はソリューションの開発を続けています。別のブロックチェーンで学んだことを単純に移植するだけでは機能しません。習得は簡単ではありませんが、結果にその価値が反映されます。

いずれにせよ、CardanoにスケーラブルなDAppをデプロイするためには、開発者は単に適用させたイーサリアムコントラクトを使用すればよいわけでなはいことを理解することが重要です。CardanoはUTXOモデルをベースにしています。これはアカウントベースではありません。そしてこれは、1つのオンチェーンステータスがCardanoの並行性プロパティにそぐわないことを意味しています。その代わりに、DAppはオンチェーンステータスを多くのUTXOに分割させる必要があります。これはアプリケーションの並行性を高め、そこから高いスループットが可能となります。

教育チームは、以前Plutusパイオニアコースで、シンプルなAMMスタイルのDEX実装を説明しました。これは教育目的には役立ちますが、このアーキテクチャーは、オーダーブックアプローチと追加的な並行性が要求される商用DEXを直接サポートするものではありません。Cardanoメインネットへのデプロイを目的とする開発者は、必要に応じてアーキテクチャーのスケーラビリティを改善する必要があります。

最近発表されたDjedステーブルコインについての論文に、解決案が提案されています。CardanoにDjedを実装するためには、注文者がステーブルコインスマートコントラクトへのミントやバーンのオーダー転送を担うオーダーブックモデルパターンが優先され、ステーブルコインやリザーブコインの売り手または買い手には追加的なインセンティブ料金が課されます。複数のセキュリティメカニズム(NFTの拡張的使用を通じた)もまた、トランザクションの一意性、送信されたオーダーの正確性を保証するため、また、最有力な攻撃を防ぐために使用されます。NFTトークンはまた、ミントやバーンオーダーの成功または失敗の報告にも使用されます。これに関する記事は、近々公開します。

スケーラビリティについての詳細は、スケーラブルなPlutusアプリケーションの設計方法や、オーダーブックパターンを使用したCardanoでのDAppの整理方法を参照してください。開発者はまた、EUTXOスマートコントラクトアーキテクチャーへの並行的決定的アプローチを発表していますが、これは、Hydra論文でマルチステップのステートマシンを実現するために紹介された並列ステートマシンステップを一般化したものと捉えることができます。数多くの他の開発者やコミュニティメンバーも、論文や動画記事、そしてTwitterで役に立つスレッドを提供しています。これは、プラットフォームの成熟とともにアプローチが標準化していくにつれ、コミュニティがどのように自分たちの革新的なソリューションを開発し続けていくかを知る素晴らしい機会となります。

今後の展望

Alonzoハードフォークイベントにより、Plutus 1.0の基本要素が導入されます。これは、エコシステム拡大の始まりです。これはまだ初期段階ですが、Alonzoテストネットは開発者がシステムプロパティを査定し、スケーラブルなDAppをあらかじめ構築して、メインネットへの配信に備えることができます。数多くのプロジェクトがローカルでPlutus環境のインスタンスを使用しています。メインのパブリックテストネットでもまもなくスマートコントラクトがサポートされ、今後数週間、数か月間でアクティビティが大幅に増加することが期待されます。今月末のCardanoサミット(9月25、26日)は、こうしたプロジェクトの多くが紹介されるとともに、スマートコントラクトのロードマップや、現在進行中であるテクノロジースタックの進化について、重要な更新情報が提供されます。開発者のイベント、ハッカソン、そしてもちろん、Project Catalystの結果も、この急成長中の開発者エコシステムに新たなツールや抽象化を提供し続けます。

開発者の方はぜひDiscordコミュニティに参加し、プロジェクトの資金調達を検討している場合はProject Catalystをチェックしてください。

本稿の執筆には、特に技術面でLars BrünjesJann MüllerManuel Chakravartyの諸氏にご協力いただきました。