Cardano の改善提案 (CIP) のリポジトリで、次の世代のスマートコントラクト実行環境 Plutus V4 が台帳の情報を受け取るときのデータの形を定めた CIP-0195 が、10 月 13 日 (UTC) に統合されました。Cardano 公式 X は日本時間 10 月 19 日未明、CIP の編集を担う Robert Phair 氏の今週のまとめを紹介し、CIP-0195 を「完了 (Completed)」の欄に挙げています。
コントラクトが取引の中身を読むときの形が文書で固まったことで、Haskell 以外の言語でコントラクトを書く道具の作り手も、同じ仕様から実装を始められるようになりました。CIP-0195 が何を決め、まだ何が残っているのかを整理します。
「完了」は統合のこと、状態は Proposed
CIP-0195 は、IOG の Ziyang Liu 氏が 8 月 3 日に提出したプルリクエスト #1238 から始まりました。2 か月あまりの議論を経て、10 月 13 日に Phair 氏が CIP のリポジトリへ統合しています。
ただし、統合されたいまの CIP-0195 の状態は「Proposed (提案)」です。本文の「Active への道」の節には、Plutus の台帳 API のライブラリ (plutus-ledger-api) にこの符号化の規則と改めた型を実装すること、Plutus V4 用の新しい Data の型を用意することが受け入れの条件として並び、Plutus チーム、UPLC を出力する他の言語の作り手、関連する道具の 3 者による実装が計画として書かれています。統合の時点では、これらの項目はまだ完了の印が付いていません。今週のまとめの「完了」は、編集の手続きとしての審査が終わったという意味です。
配列ではなくリストを選んだ理由
CIP-0195 がまず答えているのは、データを「配列 (Array)」と「リスト (List)」のどちらで表すかという問いです。オンチェーンで実行されるコードの形式 UPLC には、位置を指定して一定の手間で要素を取り出せる配列が組み込みの型として加わりました。一見すると配列が有利に見えますが、CIP は V4 の型をリストで表すと結論づけています。
理由のひとつは、リストの先頭から要素を読み飛ばす新しい組み込み関数 dropList の登場です。この関数は手間の見積もりが小さく、構造の 20 番目の項目を読む場合でもリストのほうが速いと CIP は説明しています。V4 の型で項目が最も多いのは取引の情報をまとめた TxInfo の 20 項目なので、配列の強みが出る長さには届きません。
もうひとつは影響の範囲です。配列で表すなら、Plutus の Data の型に新しい形を 2 つ、組み込み関数を 4 つ足す必要があり、Plutus 本体だけでなく他の言語やコンパイラー、台帳の側にも大きな作業が及びます。リストを選べば Data の型は変えずに済みます。配列が必要な場面では変換の手間がかかりますが、CIP の試算では 1,000 要素のリストを配列に直しても、1 取引あたりの計算の上限の 1% にはるかに届かない手間です。
「Constr 0」をやめ、仕様を文書にする
V1 から V3 までは、項目を束ねただけの型 (直積型) も「Constr 0」という目印つきで表していました。直積型は形が 1 つしかないので、この目印は情報を運びません。V4 では直積型を目印なしの List で表し、取り出しのたびに目印を外す手間をなくします。
規則は 4 つにまとめられています。組み込みの型はそのまま対応する形で表すこと (V4 では Value も組み込みの型になり、Data の新しい形で表します)、newtype は中身と同じに表すこと、直積型は List で表すこと、選択肢を持つ型 (直和型) は 0 から数えた選択肢の番号つきの Constr で表すことです。
CIP はこの文書化そのものにも意味があると述べています。V1 から V3 では Data での表し方に正式な仕様がなく、plutus のリポジトリで実装を生成する Template Haskell のコードが事実上の仕様でした。別のコンパイラーや道具の作り手は、そのコードから表し方を読み解く必要があったわけです。V4 からは、型の定義と 4 つの規則から機械的に表し方を導けます。
型の中に見える次の世代の取引
CIP-0195 に載った V4 の型の定義からは、次の世代で取引の形がどう変わるかも読み取れます。取引の情報 TxInfo には、取引の中の「サブ取引」の番号 (txInfoSubTxIx) や、取引を守る条件の一覧 (txInfoGuards)、口座の残高の範囲 (AccountBalanceIntervals) といった項目が加わりました。取引全体を見る TopTxInfo は、すべてのサブ取引の TxInfo を一覧で持ちます。
V3 までの時間の範囲の型 Interval は、始まりと終わりをそれぞれ「指定なし」も取れる形で持つ POSIXTimeRange に置き換わり、アドレスに付く StakingCredential もなくなって AccountId に変わりました。Plutus のリポジトリで V4 のスクリプトコンテキストを追う issue #7342 は、取り込む CIP として CIP-112 (スクリプトの種類を観測する) と CIP-118 (入れ子の取引) を挙げています。
Plutus V4 は次の時代 Dijkstra に向けた版で、Plutus 本体は 1.71.0.0 で V4 のスクリプトコンテキストを追加し (10 月 9 日の記事)、Go 言語のノード Dingo も評価に対応し始めています (既報: Dingo、Plutus V4 の評価と1コマンドの DevNet に対応)。実装が先に進むなかで、そのデータの形を説明する仕様の側が追いついた、というのが今回の統合の位置づけです。
同じまとめに並んだ 2 件
Phair 氏のまとめには、ほかに 2 つの動きが並びました。審査中の欄には CIP-0113 (プログラム可能なトークン) の改訂の論点があります。10 月 9 日に立てられた issue #1294 は、USDA や USDM のような既存のネイティブトークンが、ポリシー ID や名前を変えずにプログラム可能な管理の仕組みに入れるよう、発行と保管を分ける形を求めています。
新しい提案の欄には、ブロックを作ったノードのソフトウェアの情報を記録する Block Producer Payloads (プルリクエスト #1282) が入りました。ノードの識別子を登録する候補 CIP-0203 の拡張とするか、独立した CIP にするかを含めて議論が始まっています。
次に見るもの
確認できる次の一点は、Plutus のリポジトリの issue #7342 と plutus-ledger-api のリリースノートに、CIP-0195 の符号化の規則の実装が載るかどうかです。それが入れば、CIP-0195 の「Active への道」の最初の項目に印が付き、状態を Active へ進める条件がひとつ満たされます。
コントラクトを書く側にとっては、V4 に移るときに Data の読み書きの形が V3 と変わる、ということが今回で確定しました。Haskell 以外の言語でコントラクトを書いている開発者は、自分の使うコンパイラーが CIP-0195 の 4 つの規則に追随するかを、Dijkstra の準備の進み具合と並べて確かめておくとよさそうです。
ことば
- CIP — Cardano Improvement Proposal (Cardano 改善提案)。仕様や規格を文書として提案し、エディターの審査を経てリポジトリに統合されます。統合後も実装が進むまでは Proposed の状態にとどまります。
- Data — Plutus のコントラクトがオンチェーンの情報を受け渡すときに使う汎用のデータ型。取引の中身を Data でどう表すかが決まっていないと、言語ごとに読み方がずれてしまいます。
- UPLC — Untyped Plutus Core。Cardano のノードが実際に実行するコントラクトのコードの形式です。Haskell 以外の言語も UPLC を出力することで Cardano のコントラクトを書けるため、共通の仕様が重みを持ちます。
一次ソース / 関連リンク
- Cardano 公式 X: CIP の今週のまとめ（2026年10月18日 UTC）
https://x.com/Cardano/status/2111861648298246520 - Cardano 公式 X: 完了の欄（CIP-0195）
https://x.com/Cardano/status/2111861666673545636
