LIVE ADA-- MCAP-- TVL-- STAKE-- EPOCH-- Cardano & Midnight 総合情報ポータル
SIPO
𝕏 🔍
速報 Midnight公式が「AIが決定した」をセキュリティモデルとすべきではないと指摘 1日前 速報一覧 →
HOME › Signal › 契約を呼ぶ側が、384MB を持ち歩くことになる——Midnight の重さが MPS-0039 として文書になりました
Signal

契約を呼ぶ側が、384MB を持ち歩くことになる——Midnight の重さが MPS-0039 として文書になりました

2026-09-10SIPO

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.3KB
  • unshielded/mintUnshieldedToUserTest：証明鍵 2.7MB / 検証鍵 約 2KB
  • shielded/mintAndSendShielded：証明鍵 9.5MB / 検証鍵 約 2KB
  • events/emitMisc：証明鍵 64.3MB / 検証鍵 約 2KB
  • fee-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 へ動くかどうかです。どちらも同じリポジトリで追えます。

プライバシーを保ったまま検証させる設計は、証明を作る側に仕事を寄せることで成り立っています。その設計が正しく機能しているからこそ、呼ぶ側が重くなる。今回の文書は、その代償を初めて数字で見せたものだと言えます。数字が出たということは、次に何を軽くすればいいかが決まったということでもあります。

一次ソース / 関連リンク

関連記事

Signal
Mesh の SDK が、Bitcoin も話せるようになりました——Catalyst Fund 14 の 5 マイルストーン、全納品
Signal
x402 に Cardano の決済経路が実装として入りました——仕様書の中の話ではなくなります
Signal
監査済みの契約ライブラリに 1,178 万 ADA——OpenZeppelin の資金要求が投票にかかりました