Midnight の改善提案リポジトリに、9 月 9 日付で MPS-0039「Calling a Contract Requires Its Full Compiled Artifacts（契約を呼ぶには、そのコンパイル済み成果物一式が必要である）」が merge されました。書いたのは Hector Bulgarini 氏と Nicolas Di Prima 氏で、状態は Proposed、分類は Libraries and Tooling です。文書が示す数字は、Midnight の設計思想がそのまま配布の重さになっていることを、はっきりした形で見せてくれます。試験用の小さな契約 10 本で、コンパイル済み成果物は合計 384MB。一方でチェーン側が持つのは数 KB です。
SIPO がこの種の文書を追いかけているのは、「仕様が書かれたか」ではなく「配れる道具になったか」で技術の実装段階を測っているからです。その観点から見ると、これは前進の報せではありません。むしろ、いま何が詰まっているのかを、当事者が自分で数えて公開した文書です。以下では、何が merge されたのか、なぜ呼ぶ側だけが重くなるのか、そして「MPS」という文書の種類が何を意味するのかを順に見ていきます。
■ 何が merge されたのか
merge されたのは 1 本の Markdown 文書です。mps/mps-0039-lightweight-contract-interaction.md という名前で、作成日は 2026 年 9 月 9 日と記載されています。参照している他の提案はなく（Requires: none）、置き換える提案もありません（Replaces: none）。対応する MIP もまだ紐づいていません。
内容は、Midnight で「デプロイ済みの契約を呼ぶ」という、ごく当たり前の操作に必要なものを列挙したものです。文書は Midnight の実行モデルをこう説明しています。契約呼び出しのトランザクションは「回路名と引数」を運ぶのではなく、現在の台帳状態に対して回路を実行したトランスクリプトと、その実行の証明を運ぶ、と。つまり実行するのはチェーンではなく、呼ぶ側です。
■ なぜ「呼ぶ側」だけが重くなるのか
実行するのが呼ぶ側である以上、呼ぶ側は回路そのものを持っていなければなりません。文書によれば、midnight-js の呼び出し用の入り口はすべて compiledContract を引数に要求し、インターフェースだけで済ませる経路は存在しません。デプロイ済みの契約を見つけるだけでも、全回路の検証鍵をローカルに持っている必要がある、と書かれています。
回路 1 本につき必要なファイルは 3 種類です。証明鍵（prover key）、検証鍵（verifier key）、そして ZKIR。このうち重いのは証明鍵で、しかも標準の証明サーバー用クライアントは、証明を依頼するたびにこの証明鍵をアップロードします。
複数の契約をまたぐ呼び出しでは、必要な成果物がさらに増えます。合成されたトランザクションを証明するには、関係する複数のコンパイル済み契約の成果物が要る、と文書は述べています。足りなければ ZKArtifactNotFoundError で止まります。
■ 2KB と 73MB、約 35,000 倍という距離
文書は midnight-js の試験用データから、実際のファイルサイズを表にしています。
counter/increment：証明鍵 14KB / 検証鍵 約 1.3KBunshielded/mintUnshieldedToUserTest：証明鍵 2.7MB / 検証鍵 約 2KBshielded/mintAndSendShielded：証明鍵 9.5MB / 検証鍵 約 2KBevents/emitMisc：証明鍵 64.3MB / 検証鍵 約 2KBfee-mint/mintWithShieldedFee：証明鍵 72.9MB / 検証鍵 2.1KB
チェーンが保存するのは検証鍵だけで、単位は KB です。呼ぶ側が持たなければならないのは証明鍵で、大きいものでは数十 MB になります。文書はこの差を「最大のものでおよそ 35,000 倍の比率」と表現しています。そして小さな試験用契約 10 本を合計すると 384MB になる、と。
この数字が効いてくるのは、配布の場面です。複数の dApp に対応するウォレット SDK を作ろうとすると、対応する契約の数だけ成果物が積み上がります。ブラウザの拡張機能やモバイルアプリに 384MB を同梱することはできません。EVM でいえば ABI にあたる「軽い呼び出し規格」が、Midnight にはまだ無い、というのが文書の指摘です。
■ MPS は答えではなく、問いです
ここは読み違えやすいところなので、丁寧に確認しておきます。このリポジトリには 2 種類の文書があります。MPS（Midnight Problem Statements）は「エコシステムの摩擦・欠落・機会を、解決策に依存しない形で記述したもの」で、何を解くべきかを定義します。対して MIP（Midnight Improvement Proposals）は「Midnight エコシステムを変更するための、具体的で技術的に厳密な提案」であり、どう解くかを示します。
MPS-0039 は前者です。状態は Proposed で、この先 Review → Accepted → Implemented と進む段階の、いちばん手前にあります。今日起きたのは「解決策が採用された」ではなく、「解くべき問題として登録された」です。
とはいえ、文書には望ましい姿も列挙されています。KB 単位のコンパクトなインターフェース成果物、契約数に依存しない有界なクライアント側の容量、オンチェーンの検証鍵ハッシュに紐づけた成果物解決の検証可能性、プライバシー境界を広げずに重い処理を委譲できること、呼び出し木に比例した成果物取得、そしてバージョン確認。実現すれば、ウォレット SDK やエージェント CLI、各種サービスが「新しい dApp への対応を、ほぼゼロの追加容量で」行えるようになる、と文書は見通しを述べています。
■ 次に見る場所
見るべきは 2 つです。ひとつは、この MPS に対応する MIP が同じリポジトリに現れるかどうか。MPS が問いである以上、答えは MIP の形で来ます。もうひとつは、MPS-0039 の状態が Proposed から Review へ動くかどうかです。どちらも同じリポジトリで追えます。
プライバシーを保ったまま検証させる設計は、証明を作る側に仕事を寄せることで成り立っています。その設計が正しく機能しているからこそ、呼ぶ側が重くなる。今回の文書は、その代償を初めて数字で見せたものだと言えます。数字が出たということは、次に何を軽くすればいいかが決まったということでもあります。
一次ソース / 関連リンク
- MPS-0039: Calling a Contract Requires Its Full Compiled Artifacts（文書本文）
https://github.com/midnightntwrk/midnight-improvement-proposals/blob/main/mps/mps-0039-lightweight-contract-interaction.md - 当該文書を merge した commit（2026 年 9 月 9 日）
https://github.com/midnightntwrk/midnight-improvement-proposals/commit/04f061eda73fa03b576d8865ec697d8e758d2b31 - midnight-improvement-proposals リポジトリ（MPS と MIP の定義・進行段階）
https://github.com/midnightntwrk/midnight-improvement-proposals