開発者はPlutusとAlonzoプロトコルアップグレードで可能となったCardanoスマートコントラクトの到来に備えています
2021年4月13日 Lars Brünjes 読了時間9分
前回のブログでは、Cardanoにスマートコントラクトサポートを導入するプロトコルアップグレード、Alonzoを紹介しました。AlonzoはPlutusを使用した機能的なスマートコントラクトを開発するためのインフラを整え、ツールを追加します。
PlutusプラットフォームはCardanoブロックチェーンにネイティブなスマートコントラクト言語を提供します。Plutusを理解し十分に使いこなすためには、3つのコンセプトを理解することが必要です。
- 拡張UTXOモデル（EUTXO）
- Plutus Core（プルータスコア） - Plutusのオンチェーン部分
- Plutus Application Framework（プルータスアプリケーションフレームワーク：PAF） ‒ スマートコントラクトのやり取りを可能にするPlutusのオフチェーン部分
Plutusはブロックチェーンで実行される部分（オンチェーンコード）とユーザーのコンピューターで実行される部分（オフチェーンコードまたはクライアントコード）からなります。オンチェーンコードもオフチェーンコードもHaskellで書かれており、Plutusスマートコントラクトは実質的にHaskellプログラムです。オフチェーンコードはPAFで作成することができ、作成したコードはGHC（Glasgow Haskell Compiler）でコンパイルされます。一方、オンチェーンコード（Plutus Coreで作成）はPlutusコンパイラーでコンパイルされます。
これらPlutusのコンセプトとネイティブトークンの機能との関係を理解することは、これらのやり取りによってどのように後者がより有益かつパワフルな機能となるかを理解するために重要です。
拡張UTXOモデル
Cardanoはビットコインと同様に、未使用トランザクションアウトプット（UTXO）アカウントモデルを使用しています。UTXOモデルでは、トランザクションにはインプットとアウトプットがあり、インプットは以前のトランザクションで生じた未使用のアウトプットとなります。アウトプットがトランザクションでインプットとして使用されると、「使用済み」となり、2度と使用することはできなくなります。アウトプットはアドレス（公開鍵または公開鍵ハッシュ）と値（ADAの額とオプションで追加可能なネイティブトークンの額）で特定されます。アウトプットのアドレスは、どのトランザクションがそのアウトプットを「開錠」してインプットとして使用できるかを決定します。トランザクションはそのアドレスに対応する秘密鍵の所有者の署名を必要とします。アドレスは、「正しい鍵（正しい署名）」によってのみ「開錠」できる「鍵」だと考えてください。
EUTXOモデルは、このモデルを2方向に拡張しています。
- 「アドレス」のコンセプトを「錠と鍵」のアナロジーを使用して一般化します。EUTXOモデルでは、錠を公開鍵と署名鍵に限定する代わりに、スクリプト形式で任意のロジックを含めることができます。たとえば、ノードがトランザクションを認証するとき、ノードはそのトランザクションが特定のアウトプットをインプットとして使用することを許可するか否かを決定します。トランザクションはアウトプットのアドレスが提供するスクリプトを参照し、トランザクションがアウトプットをインプットとして使用できる場合にはスクリプトを実行します。
- UTXOとEUTXOの違いの2点目は、アウトプットがアドレスと値に加えて（ほぼ）任意のデータを運ぶことができる点です。これにより、ステート（状態）を含むことができるようになるため、スクリプトはさらに強化されます。
アドレスを検証する際、スクリプトはアウトプットによって運ばれるデータ、検証対象のトランザクション、その他の追加的なデータ（リディーマー：トランザクションが全インプットに提供）にアクセスします。スクリプトはこの情報を参照することにより、極めて複雑な状況やユースケースで「是」か「否」かを判断するために十分なコンテクストが得られます。
まとめると、EUTXOはUTXOを拡張し、アウトプットを開錠できるトランザクションを判断するための複雑なロジックをアウトプットアドレスに含み、すべてのアウトプットにカスタムデータを追加できるようにしたものです。
EUTXOモデルは、他のアカウントモデルにはない利点を提供します。トランザクション認証の成否はトランザクション自体およびそのインプットにのみ依存し、ブロックチェーンの他の要素は無関係となります。結果として、トランザクションの有効性は、トランザクションがブロックチェーンに送信される前に、オフチェーンで確認することができます。他のトランザクションが、使用を想定しているインプットを同時に消費した場合にはトランザクションが失敗する場合もあり得ますが、すべてのインプットが存在すれば、トランザクションは成功することが保証されます。
これは、スクリプトの実行中にトランザクションが失敗する恐れのあるアカウントベースモデル（イーサリアムが使用）とは対照的です。EUTXOでは、このようなことは絶対に起こりません。また、トランザクションを実行するための費用は送信前にオフチェーンで決定されます。これも、イーサリアムでは不可能です。
さらに、トランザクション検証の「ローカル」性のため、高度な並列処理が可能となります。原則的に、トランザクションが同じインプットを消費しようとしない限り、ノードは並行してトランザクションを検証できます。これは、効率と論拠の双方において優れており、可能な結果の分析を簡素化し、「悪いことは何も起こらない」ことを証明します。EUTXOモデルの詳細は、こちらのブログ記事をご覧ください。
Plutus Core
EUTXOモデルを実装するためには、「スクリプト」と「データ」という用語を明確に定義する必要があります。スクリプトには、明確に指定されたスクリプト言語が必要です。また、アウトプットに添付され、リディーマーとして使用されるデータの型を定義することも重要です。
ここはPlutus Coreの出番です。Plutus CoreはCardanoで使用されるスクリプト言語です。これはHaskellに似た単純な関数型言語であり、Haskellの大きなサブセットを使用してPlutus Coreスクリプトを作成できます。コントラクトの作成者として、あなたがPlutus Coreを書くことはありません。Plutus CoreプログラムはHaskellコンパイラープラグインによって生成されます。
これらのスクリプトはトランザクションがチェーンで検証されているあいだに、ノードによって実行されます。これは、「バリデータースクリプト」の形式でUTXOをロックするか、「ミントポリシー」としてネイティブトークンのミント（鋳造）やバーン（廃棄）を管理します（後述）。
リディーマーデータは単純な（代数）データ型で、Haskellで容易に定義できます。この点も、HaskellがPlutus Coreスクリプトのオプションとして優れている理由の1つです。実際には、スマートコントラクト開発者がHaskellでバリデータースクリプトを作成すると、自動的にPlutus Coreにコンパイルされます。
適切なHaskellライブラリーは、検証中のトランザクションを調査するコアデータ型、さらに多くのヘルパー関数やより高いレベルの抽象化を提供することでこのような認証ロジックの作成を単純化し、コントラクト作成者があまりにも多い低レベルのディテールに煩わされることなくビジネスロジックに集中できるようにします。
Plutus Application Framework（PAF）
バリデータースクリプトのオンチェーンステートは、スクリプトアウトプットを使用、生成するトランザクションによってのみ変更することができます。Plutusアプリケーションを作成するときは、アプリケーションのオンチェーン部分（Plutus Coreスクリプト）だけでなく、トランザクションを構築、送信するオフチェーン部分についても考慮する必要があります。
オフチェーンコードは、オンチェーンコードと同様にHaskellで作成されます。こうすることで、ビジネスロジックの作成は一度で済みます。次にこれをバリデータースクリプトおよびバリデータースクリプトを実行するトランザクションを構築するコードの両方に使用することができます。
多くのアプリケーションでは、特定のアドレスへの変更のためのUTXOセットを監視する必要があるため、コントラクトをステートマシンとして作成すると、マシンの現在のステートを代表する未使用アウトプットを追跡し、オンチェーンステートが変更されたときにローカルマシンを更新する必要が生じます。また、トランザクションに使用する暗号通貨にアクセスするために、ウォレットバックエンドと通信する必要があります。
PAFではPlutusアプリケーションで一般に使用されるサービスへ簡単にアクセスできます。PAFのライブラリーを使用してデプロイされたアプリケーションは、Plutusアプリケーションバックエンドで実行することができ、ブロックチェーンへのアクセスをはじめ、持続性、ロギング、監視といった問題に対し、ランタイムサポートを提供します。PAFの上に作成されたアプリケーションには、ウェブブラウザーからアプリケーションとやり取りするために使用できるHTTPおよびWebSocketインターフェイスが自動的に提供されます。
ネイティブトークン
ネイティブトークンは、2月のMaryハードフォークにより、Cardanoで使用可能となりました。あらゆるユーザーが自分のトークンを作成することができ、トークンはADAのように自由に送受信することができます。各ネイティブトークンは独自のミントポリシーを持ちます。これは、トークンをミントあるいはバーンする条件を定めたものです。
現在、ミントポリシーは署名とタイムロックを特定する単純なルールの組み合わせで成り立っています。たとえば、ポリシーは5つの可能な署名のうち2つによって署名されたトランザクションのみがミントまたはバーンを許可されると規定することができます。別のポリシーは特定のタイムスロットの前または後にのみミントを許可することができます。
これらの基本的な構成要素は強力ですが、考えられるすべての用途を網羅しているわけではありません。たとえば、こうした単純なポリシーを使ってNFT（代替不可能トークン）をモデル化することは、可能ではありますが厄介です。NFTをミントするためにタイムロックを使用して、ミント作業を特定の時点に制限すれば可能です。その時点に達する前に1つのトークンのみがミントされている場合、トークンは技術的には代替不可能（1つしかないため）となります。しかし、これを確認するためには、ミントポリシーを確認するだけでは不十分です。実際に一度しかミントされていないことを確かめるためには、ミント履歴を参照する必要があります。
Plutusのデプロイとともに、ユーザーはPlutus Coreを使用してミントポリシーを作成することができるようになります。ミント中やバーン中、Plutus Coreのポリシースクリプトはミントまたはバーントランザクションのコンテキストで実行され、スクリプトはアクションを承認または禁止する必要があります。これにより、はるかに複雑なミントポリシーの作成を可能にし、トラストレスにNFTが作成できるようになるため、CardanoにおけるNFTの成長がさらに加速されます。
Alonzoは複数のテストネット経由で段階的にメインネットへデプロイされています。したがって、パートナーやPlutusパイオニアたちはコード凍結前の5月から6月にかけて、Cardanoでアプリケーションを作成することによりPlutus Coreをテストすることができます。これはまた、QAおよび取引所によるUAT期間でもあり、Alonzoのメインネットアップグレード時に確実にプラットフォームの準備が完全に整っていることになります。開発者の方でPlutusについて詳細を知りたい場合には、今後のパイオニアグループに参加することをご一考ください。また、Plutus GitHubリポジトリを参照したり、CardanoフォーラムでPlutusについての議論に参加してください。
本稿の執筆にはJann Müller氏にご協力いただきました。