LIVE ADA-- MCAP-- TVL-- STAKE-- EPOCH-- Cardano & Midnight 総合情報ポータル
SIPO
速報 Intersect MBO がアップデート #131 を公開、CIP編集者採用やCAP-12など報告 1日前 速報一覧 →
HOME › Signal › Midnight の MIP-0027、ブロック処理を4割短縮する案
Signal

Midnight の MIP-0027、ブロック処理を4割短縮する案

2026-10-05SIPO #Midnight

日本時間10月5日の早朝、Midnight の改善提案を管理する GitHub リポジトリに、MIP-0025・MIP-0026・MIP-0027 の3本と、課題を定義する文書 MPS-0044 が番号付きで取り込まれました。このうち MIP-0027 は、ゼロ知識証明(ZK 証明)の検証結果を使い回す仕組みで、性能試験用のネットワークでブロックの作成時間を42.4%、取り込み時間を41.1%縮めたと報告しています。

3本の MIP は、どれも「ネットワークをどう軽く、どう安全に回すか」に向いています。10月2日にメインネットで誰でもコントラクトを置けるようになり(10月2日の Signal)、使われるほど重くなる部分に先回りで手を入れる段階に入りました。ただし番号が付いたことは採択を意味しません。それぞれの中身と、ここから先の手順を整理します。

MPS-0044 が示した「1秒あたり約42件」の上限

MPS は「何が問題か」を定義する文書で、MIP はその解き方を示す提案です。MPS-0044 は、Midnight が目標とする毎秒1,000件以上の取引に対し、今の仕組みでは届かない理由を数字で示しました。

Midnight の取引には ZK 証明が付き、ブロックを作る1台のノードがそれを順番に検証します。1件の検証には約6ミリ秒かかり、6秒のスロットのうち利用者の取引の処理に使えるのは1,500ミリ秒です。そこに収まる証明は1ブロック約250件で、毎秒にすると約42件。毎秒1,000件には、1ブロック6,000件、36,000ミリ秒分の検証が必要になり、今の枠の24倍にあたります。

MPS-0044 はこの壁を「1台のリーダーに検証が集中する構造の問題」と位置づけ、検証をバリデーター全体に分散させる DAG 型の合意方式(Narwhal/Bullshark など)の検討を推奨しています。ノードのハードウェア要件がどう変わるかなど、未解決の問いも多く並んでいます。

MIP-0027: 同じ証明を約7回確かめていた

MIP-0027 が見つけたのは、検証の「やり直し」です。ノードは取引をメモリプールに受け入れるときに証明を検証し、台帳の状態が変わるたび、つまりブロックを作るときと取り込むときにもう一度検証します。3ノードの試験ネットワークでは、1件の取引の証明がネットワーク全体で約7回確かめられていました。

証明の検証が読む台帳の情報は検証鍵だけなので、鍵が変わらない限り答えは変わりません。そこで MIP-0027 は、一度通った検証結果を保存し、状態が変わったときは「コインがまだ使われていないか」など状態に依存する確認だけをやり直す設計を提案しています。二重支払いはこの確認で弾かれます。

8台のバリデーターを使った比較では、取引を含むブロックの作成時間が1,015ミリ秒から585ミリ秒に、取り込み時間が1,027ミリ秒から605ミリ秒に縮み、取引1件あたり約22ミリ秒の削減になりました。ただし今回の負荷ではブロックの重さの上限が先に効くため、ネットワーク全体の処理件数は変わっていません。提案自身も、これは処理件数の増加ではなく余力の増加で、上限が引き上げられたときに処理件数に変わると書いています。キャッシュが使うメモリ(推定100〜400MB)は実測されておらず、契約の更新で検証鍵が変わる場合の扱いも未検証です。

MIP-0026: 誰も読まない途中の台帳状態を手放す

ノードはブロック内の取引を1件ずつ適用し、そのたびに新しい台帳の状態を作ります。ブロックが終われば必要なのは最後の状態だけですが、今のノードは途中の状態もすべて保存し続け、消すことがありません。MIP-0026 は、この途中の状態を手放すようノードを変える提案です。

8台のバリデーターで約20時間動かした比較では、同じ11,750ブロックの間に台帳の保存領域が、変更なしのノードで4.9GB、変更ありのノードで2.9GB増えました。増え方の約42%を減らせた計算で、処理時間も数%速くなっています。

ノードを運用する側にとって大事なのは、すでにディスクにあるデータは小さくならない点です。効果が出るのはこれからの増え方で、保存量そのものを小さくしたい場合は、ジェネシスからの同期かスナップショットからの復元が必要になると提案は書いています。MIP-0026 と MIP-0027 は、どちらもハードフォークを必要としない、ノード側だけの変更とされています。

MIP-0025: コントラクトごとの私的な状態を「カプセル」に

MIP-0025 は性能ではなく、プライバシーの土台に関わる提案です。Midnight では、利用者の私的なデータは手元の端末から出さずに、ZK 証明で公開の台帳の更新が正しいことだけを示します。ところが今の Compact(Midnight のコントラクト言語)では、手元の私的な状態の作り方や守り方をすべて呼び出し側のアプリが担っていて、あるコントラクトの私的なデータを別のコントラクトから切り離す手段が基盤側にありません。

提案は例として、年齢や居住地の証明書を持つ利用者が、まだ信頼しきれない新しい取引アプリを試す場面を挙げています。そのアプリに証明書の中身を見せずに済むよう、各コントラクトの私的な状態を「カプセル」という境界の中で扱い、専用の実行環境(カプセルランタイム)で動かす設計です。コンパイラ、ウォレット、Midnight.js など多くの部品に変更が及び、文書の状態はまだ Draft で、採択までの道筋も「未起草」と書かれています。

番号が付いたあとの手順

Midnight の改善提案の手順を定めた MIP-0001 は、番号の付与について「MIP そのものの採択とは同じではない」と明記しています。MIP-0026 と MIP-0027、MPS-0044 の文書の状態欄は Proposed で、手順上はこのあと通常2週間以上のコミュニティの意見期間を経て、編集者の投票で採否が決まります。採択されてから実装、さらにネットワークのアップグレードでの展開へと進みます。

確認できる次の一点は、リポジトリの番号一覧(NUMBERS_INDEX)と各提案の状態欄です。MIP-0027 の欄が Accepted に変われば、ノードの実装計画(本番向けのキャッシュの実装、メモリ使用量の計測、テストネットでの負荷試験)が動き出します。Midnight のノードを運用する SPO にとっては、MIP-0026 の採否が、今後のディスク容量の見積もりに直接響きます。

ことば

  • MIP / MPS — Midnight の改善の仕組み。MPS(Midnight Problem Statement)が課題を定義し、MIP(Midnight Improvement Proposal)が解き方を提案します。Cardano の CPS と CIP に近い関係で、今回は課題1本と解き方3本が同時に番号を得ました。
  • ZK 証明(ゼロ知識証明) — 中身を明かさずに「条件を満たしている」ことだけを示す暗号の技術。Midnight の取引はこれを使うため、検証の計算がノードの処理時間の大きな部分を占めます。
  • 検証鍵 — ZK 証明を確かめるときに使う公開の鍵。プロトコルのアップグレードやコントラクトの更新で変わります。変わらない限り同じ証明の検証結果も変わらないことが、MIP-0027 の使い回しの前提です。

一次ソース / 関連リンク

タグ: #Midnight