下記の記事はIOGブログの記事「Plutus: what you need to know」を翻訳したものです。
Plutus：知っておくべきこと
開発者は現在、PlutusとAlonzoプロトコルのアップグレードによって可能になる、Cardanoスマートコントラクトの登場に向けて準備を進めています。
By Lars Brünjes 2021年4月13日 9 mins read
Plutus: 知っておくべきこと
前回のブログ記事では、Alonzoについて説明しました。Alonzoとは、Cardanoにスマートコントラクトのサポートを導入するためのプロトコルアップグレードの名称です。Alonzoは、Plutusを使った機能的なスマートコントラクト開発のためのインフラを確立し、ツールを追加します。
Plutusプラットフォームは、Cardanoブロックチェーンのためのネイティブなスマートコントラクト言語を提供します。Plutusを理解し、使いこなすためには、3つのコンセプトを理解する必要があります。
- Extended UTXOモデル（EUTXO）
- Plutus Core – Plutusの「オンチェーン」部分
- Plutusアプリケーションフレームワーク（PAF） – Plutusの「オフチェーン」部分で、スマートコントラクトとのやりとりを可能にします。
Plutusのコントラクトは、ブロックチェーン上で実行される部分（オンチェーンコード）と、ユーザーのマシン上で実行される部分（オフチェーンまたはクライアントコード）で構成されています。オンチェーンコードもオフチェーンコードもHaskellで書かれており、Plutusのスマートコントラクトは実質的にHaskellのプログラムです。オフチェーンのコードはPAFを使って書くことができ、このコードはGHC（Glasgow Haskell Compiler）によってコンパイルされますが、オンチェーンのコード（Plutus Coreを使って書かれたもの）はPlutusのコンパイラによってコンパイルされます。
これらのPlutusの概念とネイティブトークンの機能との関係を理解し、それらの相互作用によって後者がより便利で強力な機能に変わることを確認することが重要です。
拡張UTXOモデル
Cardanoは（Bitcoinのように）、アンスペント（U）トランザクション（TX）アウトプット（O）会計モデルを使用しています。UTXOモデルでは、取引には入力と出力があり、入力は以前の取引からの未使用の出力である。出力がトランザクションの入力として使用された時点で、その出力は使用済みとなり、二度と使用することができない。出力は、アドレス（公開鍵または公開鍵ハッシュ）と値（ADA金額とオプションで追加されるネイティブ・トークンの金額で構成される）で指定されます。出力のアドレスは、その出力を「アンロック」して入力として使用することを許可するトランザクションを決定します。トランザクションは、そのアドレスに対応する秘密鍵の所有者によって署名されなければなりません。アドレスは、正しい「鍵」（正しい署名）によってのみ「解錠」できる「錠」と考えてください。
EUTXOモデルは、このモデルを2つの方向に拡張したものである。
- EUTXOモデルはこのモデルを2つの方向に拡張している。EUTXOモデルにおけるアドレスは、鍵を公開鍵に、鍵を署名に限定するのではなく、スクリプトの形で任意のロジックを含むことができる。例えば、あるノードがトランザクションを検証する際、ノードはそのトランザクションがある出力を入力として使用することを許可されているかどうかを判断します。トランザクションは、出力のアドレスで提供されるスクリプトを調べ、トランザクションが出力を入力として使用できる場合には、そのスクリプトを実行する。
- UTXOとEUTXOの2つ目の違いは、出力がアドレスと値に加えて（ほぼ）任意のデータを運ぶことができることです。こ れに よ り 、 ス ク リ プ ト は状態を伝え る こ と がで き 、 よ り 強力にな り ます。
アドレスを検証する際、スクリプトは、出力によって運ばれるデータ、検証されるトランザクション、およびトランザクションがすべての入力に対して提供するリダイマーと呼ばれるいくつかの追加データにアクセスします。ス ク リ プ ト は こ れ ら すべての情報を検索す る こ と で、 非常に複雑な状況やユースケースで も 「はい」 または 「いいえ」 の回答を与え る こ と がで き ます。
要約すると、EUTXOはUTXOモデルを拡張し、出力アドレスに、どのトランザクションがロックを解除できるかを決定するための複雑なロジックを含めることを可能にし、またすべての出力にカスタムデータを追加します。
EUTXOモデルには、他の会計モデルにはない独自の利点がある。トランザクションの検証の成否は、ブロックチェーン上の他の何にも依存せず、トランザクション自体とその入力にのみ依存します。その結果、トランザクションの有効性は、トランザクションがブロックチェーンに送信される前に、オフチェーンで確認することができます。トランザクションが期待している入力を他のトランザクションが同時に消費した場合、トランザクションは失敗する可能性がありますが、すべての入力が残っている場合、トランザクションは成功することが保証されます。
イーサリアムで採用されているアカウントベースのモデルでは、スクリプトの実行途中でトランザクションが失敗する可能性があるのとは対照的である。EUTXOではこのようなことは起こりえない。また、トランザクションの実行コストは、送信前にチェーン外で決定することができますが、これもEthereumでは不可能な機能です。
最後に、トランザクションの検証は「ローカル」な性質を持つため、高度な並列処理が可能です。ノードは、トランザクションが同じ入力を消費しようとしなければ、原理的にトランザクションを並行して検証することができます。これは、効率性と推論の両面で優れており、起こりうる結果の分析を単純化し、「悪いことは何も起こらない」ことを証明します。EUTXOモデルについては、以前のブログ記事で詳しく紹介しています。
Plutusコア
EUTXOモデルを実装するためには、スクリプトとデータという用語を明確に定義する必要がある。スクリプトには、明確に規定されたスクリプト言語が必要であり、また、出力に添付され、リダイムとして使用されるデータの種類を定義することも重要である。
ここでPlutus Coreの出番です。Plutus Coreは、Cardanoが使用するスクリプト言語です。Haskellに似たシンプルな関数型言語で、Haskellの大部分のサブセットはPlutus Coreのスクリプトを書くのに使用できます。コントラクトオーサーとして、あなたはPlutus Coreを一切書きません。すべてのPlutus Coreプログラムは、Haskellコンパイラプラグインによって生成されます。
これらのスクリプトは、チェーン上でのトランザクション検証の「ライブ」中にノードによって実行されます。これらのスクリプトは、バリデータ・スクリプトの形でUTXOをロックするか、ネイティブ・トークンの鋳造と燃焼を制御する鋳造ポリシーの形で実行されます（以下を参照）。
Redeemerのデータは、Haskellで簡単に定義できるシンプルな（代数的な）データ型であり、これもPlutus Coreのスクリプトを書くのにHaskellが適している理由のひとつです。実際には、スマートコントラクトの開発者はHaskellでバリデータのスクリプトを書き、それが自動的にPlutus Coreにコンパイルされます。
適切なHaskellライブラリは、検証時にトランザクションを検査するためのコアデータ型を提供したり、多くのヘルパー関数や高レベルの抽象化を提供したりすることで、そのような検証ロジックの記述を簡素化し、コントラクト作成者がビジネスロジックに集中できるようにします。
Plutusアプリケーションフレームワーク(PAF)
バリデータスクリプトのオンチェーン状態は、スクリプトを消費して出力するトランザクションによってのみ変更できます。Plutusアプリケーションを書くときには、アプリケーションのオンチェーン部分（Plutus Coreスクリプト）だけでなく、トランザクションを構築して送信するオフチェーン部分も考慮する必要があります。
オフチェーンのコードは、オンチェーンのコードと同じようにHaskellで書かれています。これにより、ビジネスロジックは一度だけ書けばよいことになります。そして、バリデータ・スクリプトと、バリデータ・スクリプトを実行するトランザクションを構築するコードで使用することができます。
多くのアプリケーションは、特定のアドレスに変化がないかUTXOセットを監視する必要があります。コントラクトをステートマシンとして記述する場合、マシンの現在の状態を表す未使用の出力を追跡し、オンチェーンの状態が変化したときにローカルの状態を更新する必要があります。同様に、多くのアプリは、取引に使用している暗号通貨にアクセスするために、ウォレットのバックエンドと通信する必要があります。
PAFは、Plutusアプリケーションがよく使用するサービスに簡単にアクセスできます。フレームワークのライブラリを使用してデプロイされたアプリケーションは、Plutusアプリケーションバックエンド上で実行することができます。このバックエンドは、ブロックチェーンへのアクセスや、永続性、ロギング、モニタリングなどの他の懸念事項に対するランタイムサポートを提供します。PAFの上に書かれたアプリケーションは、HTTPとWebSocketのインターフェイスを自動的に提供し、Webブラウザからのアプリケーションとの対話に使用できます。
ネイティブトークン
ネイティブトークンは、2月のメリーハードフォークでカルダノで利用できるようになりました。ユーザーは誰でも自分のトークンを作ることができ、トークンの送受信はADAのように自由に行うことができます。それぞれのネイティブトークンには、トークンを鋳造したり焼いたりする条件を決める、独自の鋳造ポリシーがあります。
現時点では、このミティングポリシーは、署名とタイムロックを指定する単純なルールの組み合わせで構成されています。例えば、あるポリシーでは、可能な5つの署名のうち2つの署名があるトランザクションのみ、トークンの鋳造や焼失を許可することができます。また、特定の時間帯の前後にのみトークンの鋳造を許可するというポリシーもあります。
これらの基本的な構成要素は強力ですが、考えられるすべての用途をカバーしているわけではありません。例えば、このようなシンプルなポリシーを用いて、NFT（non-fungible token）をモデル化することは可能ですが、困難です。これは、NFTを鋳造するためにタイムロックを使用し、鋳造作業を特定の時点に限定することで可能となります。その時点に到達する前に1つのトークンだけが鋳造された場合、そのトークンは技術的には（1つしかないので）鋳造できません。しかし、これを確認するためには、単にミント化の方針を確認するだけでは不十分です。トークンの鋳造履歴を見て、本当に一度しか鋳造されていないことを確認する必要があるのです。
Plutusが導入されると、ユーザーはPlutus coreを使ってミント・ポリシーを書くことができるようになります。ミンティングやバーニングの際には、Plutus Coreのポリシースクリプトがミンティングやバーニングのトランザクションのコンテキストで実行され、スクリプトはその行為を承認または禁止しなければなりません。これにより、はるかに複雑な鋳造ポリシーの作成が可能になり、トラストレスな方法でNFTの作成ができるようになることで、カルダノにおけるNFTの成長がさらに加速されます。
Alonzoは、いくつかのテストネットを経由してメインネットに徐々に展開されているため、パートナー企業やPlutusのパイオニア企業は、コード凍結に先立ち、5月から6月にかけて、カルダノ上でアプリケーションを書いてPlutus Coreをテストすることができます。また、この期間は、Alonzoメインネットのアップグレード時にプラットフォームが完全に準備されていることを確認するために、取引所による品質保証とユーザー受け入れテストの期間にもなります。開発者の方で、Plutusについてもっと知りたいという方は、将来のパイオニアコホートへの参加をご検討ください。また、PlutusのGitHubリポジトリをご覧になったり、Cardano ForumでPlutusに関する議論に参加することもできます。
Jann Müller氏には、このブログ記事への追加のインプットと貢献を感謝したいと思います。
