CardanoのPlutus提案がスクリプト実行のオーバーヘッド低減を目指す

CardanoのPlutus開発パイプラインは、スマートコントラクトがレジャーデータを処理する方法に焦点を当てた2件の提案を追加した。CIP-0194はUPLC向けの組み込みパターンマッチングを導入し、CIP-0195はScriptContextやTxInfoなどのPlutus V4の型をDataとしてどのようにエンコードすべきかを定義する。いずれも審査中の段階にある。

CIP-0194にはすでに動作する実装プロトタイプがあり、初期のローカルベンチマークでは複数のデータアクセスパターンでCEKの実行時間が大幅に短縮されることが示された。これらの測定値はオンチェーンの実行ユニットに較正されたものではなく、本番のコストパラメータもまだ確定していない。

CIP-0194がPlutus Coreにパターンマッチングを追加

Cardanoのスマートコントラクトは、ScriptContext内のトランザクション情報を含む構造化されたDataを頻繁に検査する。既存のUPLCプログラムは、unConstrData、chooseData、リスト操作などの関数を通じてこれらの構造を分解できるが、その各段階がCEK評価器内での処理を積み重ねる。

CIP-0194は、新しいMatch演算を提案しており、入れ子になった値を直接検査し、スクリプトに必要なフィールドだけを取り出せる。対象は整数、バイト列、リスト、ペア、構造化されたDataに及び、簡易な操作のための既存のCase機構も引き続き利用可能だ。

この変更は、より複雑なDeFiやトレーディング、レンディングのロジックを含め、トランザクションコンテキストを反復的に検査するバリデータを主な対象としている。

Plutusのコードベースにはすでに動作するプロトタイプが存在する。本番利用には、適合性テスト、較正済みのコストパラメータ、レジャー対応、そしてCardanoノードのリリースがなお必要となる。

初期ベンチマークでCEK実行時間の短縮を確認

このCIPには、Dataの分解に関する既存手法とMatchを比較したローカルベンチマークが含まれている。

深く入れ子になった単一の値を取り出す場合、試験シナリオでは測定されたCEK実行が6.38倍から13.74倍高速だった。64層の入れ子Dataを扱ったテストでは、既存手法の31.068マイクロ秒に対し、Matchでは2.297マイクロ秒を記録した。

スクリプトが複数の値を取得する場合には性能差は縮小し、構造やベースライン手法に応じておおよそ1.67倍から6.10倍の改善となった。

これらの数値は、最終的なCardanoの実行ユニットではなく、ローカル環境でのCEKの実時間性能を測定したものだ。コストモデルは依然として未較正である。提案における暫定的なCPUおよびメモリの予算は、ワークロードによって10%から90%の改善を示し、典型的なスクリプトコンテキストのシナリオでは初期パラメータの下で概ね40%から60%の改善が見られた。

この提案では、MatchをPlutus Coreの言語バージョン1.2.0に割り当てており、メインネットでスクリプトが利用できるようになるには、レジャー対応とCardanoのハードフォークのプロセスによる有効化が必要となる。

CIP-0195がPlutus V4のDataモデルを定義

CIP-0195は、Plutusスタックのもう一方の側面に対処し、Plutus V4のレジャーAPIの型をDataとしてどのように表現すべきかを規定する。

この提案は、拡張されたTxInfoを含むV4のScriptContextと関連する構造を対象とする。これは、専用の仕様ではなく実装コードからエンコードの挙動を読み解かなければならないことが多かった従来のPlutusのより非公式な手法に代わるものだ。

提案されたV4の設計では、データ型のエンコードにリストの使用を継続する。CIP-0195は、より新しいUPLCの操作によりリストへのアクセスが効率的になり、より広範な配列ベースのモデルが必要とする追加のコンストラクタやレジャー統合を回避できると主張している。

CIP-0194とCIP-0195はそれぞれ独立して進行可能だが、合わせて次世代のPlutusがレジャーデータをどのように構造化しアクセスするかに取り組むものだ。採用された場合、CIP-0195はPlutus V4がそのデータをどのように公開するかを標準化し、CIP-0194はバリデータにそれを低オーバーヘッドで検査する方法を提供する。いずれもCardanoメインネットに到達する前に、仕様の承認、較正済みのコストモデル、レジャー統合を必要とする。