Update Plutus Cost Models
- Governance Action Type: Parameter Change（パラメータ変更・Treasury 引き出しなし）
- 提出: 2026年5月26日（Epoch 633）
- 失効: 2026年6月29日頃（Epoch 640）
- 提案者: Intersect Parameter Committee（Technical Steering Committee 確認済）
- Governance Action ID:
gov_action1eqhnsdyf3exhp5mqt7sdjtl7xy69wqg8tvg854psns2jt72cra3qqrcnr8r - Legacy Governance Action ID (CIP-105):
c82f3834898e4d70d3605fa0d92ffe31345701075b107a54309c1525f9581f62#0 - gov.tools: 該当ガバナンスアクションを開く
- SIPO DRep スタンス: 賛成（Yes）
Update Plutus Cost Models をどう見るか ― SIPO DRep としての分析とスタンス
提案の概要
本提案は、Treasury からの資金引き出しを伴わないパラメータ変更です。Plutus（Cardano のスマートコントラクト実行環境）の cost model ― 各演算プリミティブの CPU・メモリ消費に対する課金単価表 ― を Plutus V1・V2・V3 にわたって更新します。Intersect の Parameter Committee が公開議事録のある会議（2026年3月5日・3月19日）で勧告し、Technical Steering Committee が確認した、パラメータ変更の正規の制度ルートを経た提案です。
何が変わるのか ― 3 つの内容
第一に、van Rossem ハードフォーク（Protocol Version 11）後に使える新プリミティブの単価設定です。単価が設定されていなければ、ハードフォークが来ても新機能は使えません。対象には、べき剰余（CIP-0109・RSA 検証や暗号計算の基礎）、BLS12-381 上の multi-scalar multiplication（CIP-0133・ZK rollup や証明集約の中核演算）、dropList（CIP-0132）、Array 組込型（CIP-0138）、MaryEraValue（CIP-0153）が含まれます。第二に、これまで Plutus V3 限定だったプリミティブを V1・V2 でも利用可能にします。第三に、既存プリミティブの単価をベンチマーク実測に基づいて調整します（この部分は可決と同時に発効します）。
検証可能性 ― すべてが公開されている
ベンチマークは GitHub の公開ワークフローで実行され、計測データ・手法の解説文書・現行と変更後のパラメータ diff（IPFS）まで、すべて公開されています。どの DRep も独立に検証できる形です。これは過去のプロトコルアップグレード（Chang 以降の各 HF）のたびに同じ手法で実施されてきた標準プロセスであり、事故歴はありません。
リスク評価
cost model 更新の本質的リスクは「単価の設定ミス」です。安すぎる場合はスクリプトが課金以上の実リソースを消費し、ノード負荷（理論上は DoS ベクトル）になり得ます ― これが唯一の実質リスクで、公開ベンチマークプロセスが緩和策です。高すぎる場合はプリミティブが実用にならないだけで、後続のパラメータ更新で修正可能です。また、既存プリミティブの即時再価格化は実測準拠の定常的な再調整であり、過去の更新で問題化した事例はありません。
タイミングの面では、新プリミティブの単価は Protocol Version 11 ハードフォーク後にのみ有効化されます。本アクションが先に発効してもハードフォークが遅延すれば無害（設定が眠っているだけ）である一方、否決されたままハードフォークが来ると新機能が使えない ― 順序の論理は承認を支持します。
なぜ「賛成（Yes）」なのか
SIPO が賛成する理由は 4 つです。(1) 正規の制度ルート（Parameter Committee 勧告 + TSC 確認 + 完全公開のエビデンス）を経ていること。(2) SIPO が支持してきた能力群の有効化スイッチであること ― ポスト量子・ゼロ知識関連のプリミティブは、SIPO が今期支持した研究・プラットフォーム群（ZK スケーリング研究・スマートコントラクト基盤・Plutus V4 対応）の下にある技術的基盤です。(3) リスクが許容範囲でよく緩和されていること。(4) 否決の方が実害があること。Treasury 資金の要求はなく、利益相反も SIPO 側の recusal 事由もありません。
期待事項として、Parameter Committee が今後の cost model 変更でも同水準のベンチマークデータと diff の公開を継続すること、発効後の挙動を監視し異常があれば速やかに修正アクションを講じること、の 2 点を記しています。
SIPO DRep としての結論・スタンス
以上から、SIPO は本提案に 賛成（Yes） を投じました。これは、van Rossem ハードフォークで届く次世代機能 ― とりわけ ZK・ポスト量子時代の暗号演算 ― の電源を入れる、検証可能で制度的に整った技術整備です。
How SIPO Views Update Plutus Cost Models — A DRep Perspective —
Overview
This is a parameter-change action with no treasury withdrawal. Proposed by Intersect’s Parameter Committee (publicly minuted meetings, March 5 and 19, 2026) and confirmed by the Technical Steering Committee, it updates the Plutus cost models across V1, V2, and V3: setting parameters for the new primitives arriving with the van Rossem hard fork to Protocol Version 11 — including modular exponentiation (CIP-0109) and multi-scalar multiplication over BLS12-381 (CIP-0133, core to ZK rollups and proof aggregation), plus dropList (CIP-0132), the Array type (CIP-0138), and MaryEraValue (CIP-0153); making previously V3-only primitives available in V1 and V2; and recalibrating some existing primitives based on published benchmarking, effective on enactment.
Verifiability and Risk
Benchmarking workflows, measurement data, methodology documentation, and a full parameter diff are all public — any DRep can verify them. The principal risk of a cost model, underpricing that lets scripts consume more resources than they pay for, is mitigated by this published benchmarking process; overpricing is correctable by a later update. The immediate repricing of existing primitives is routine, benchmark-driven recalibration of the kind performed at every recent upgrade without incident. Sequencing favours approval: enacting before the mainnet hard fork is harmless if the fork is delayed, while rejection would leave the new primitives unusable when it arrives.
Why SIPO Votes Yes
Four reasons: the proper institutional route; the enabling switch for capabilities SIPO has consistently supported — the post-quantum- and zero-knowledge-relevant primitives are the technical substrate beneath the research and platform work SIPO has backed this cycle; an acceptable, well-mitigated risk profile; and a sequencing logic in which rejection causes more harm than approval. No treasury funds, no conflict of interest, no recusal grounds. SIPO expects the Parameter Committee to maintain this standard of published benchmarking and diffs for future changes, and post-enactment monitoring with prompt corrective action if anomalies emerge.
Final Position
SIPO votes Yes — a verifiable, institutionally grounded piece of technical groundwork that switches on the next generation of cryptographic capability arriving with the van Rossem hard fork.
