LIVE ADA-- MCAP-- TVL-- STAKE-- EPOCH-- Cardano & Midnight 総合情報ポータル
SIPO
速報 Cardano、Treasury資金配分改革を主題とした円卓会談39を開催予定 13時間前 速報一覧 →
HOMESignal › Midnight MIP-0018、トークン名をコントラクト自身が宣言
Signal

Midnight MIP-0018、トークン名をコントラクト自身が宣言

2026-09-22SIPO

Midnight の改善提案を管理する GitHub リポジトリに、日本時間 9 月 22 日 11 時 27 分、トークンの名前や記号をコントラクト自身がオンチェーンのイベントとして発行するための提案 MIP-0018 が取り込まれました。ウォレットやエクスプローラが、見知らぬトークンを 64 文字の 16 進文字列ではなく名前で表示できるようにするための土台で、ステータスは最初の段階である Proposed です。

同じ朝には、秘匿したデータを選んだ相手にだけ開示する仕組みが足りない、という問題提起 MPS-0043 も取り込まれています。2 つとも、Midnight でアプリやトークンを作る側がこれから踏む段差を先に言葉にした文書です。何が提案され、何がまだ決まっていないのかを、提案書の本文から整理します。

■ トークンが「色」でしか見えない、という問題

Midnight のネイティブトークンは、発行したコントラクトのアドレスと、ドメインセパレータと呼ばれる値から導かれる「色」(トークン種別の識別子)で区別されます。どのコントラクトがどの色をいくつ発行したかは取引から誰でも数えられますが、その色が何のトークンなのかを示す標準の方法がありません。

MIP-0018 はその結果を具体的に挙げています。ウォレットは 64 文字の 16 進文字列を表示し、エクスプローラはトークンにラベルを付けられず、アプリはトークンの一覧を自前で書き込んでいる。そして、名乗られた名前と、それが指すトークンを結びつけるものが何もない、という指摘です。

既存のトークン標準(MIP-0011 と MIP-0014)には、名前・記号・小数点以下の桁数を返す関数があります。ただ、それを読むにはそのコントラクトのコンパイル済みの成果物が必要で、初めて見るトークンの成果物をウォレットは持っていません。提案書はさらに、成果物やソースを持っていても、それがチェーン上に置かれたコントラクトと同じものだと確かめる手段がチェーン側にない、とも書いています。

■ MIP-0018 の仕組み: 名乗るのはコントラクト自身

提案の中身は、コントラクトが公開イベントでメタデータを発行する取り決めです。先行する MIP-0002 のイベント機構のうち、汎用の Misc イベントを使い、1 件あたり 256 バイト固定のペイロードに「キーと値」の組を載せます。イベント名は mip-0018:token-metadata[v1] で、値を更新したいときは新しいイベントを出し、受け取る側は実行順に適用します。設計は Ethereum の EIP-7496(NFT の動的な属性)にならったと明記されています。

要点は、宣言を出す主体がトークンを発行したコントラクトそのものだということです。イベントを出したコントラクトのアドレスは取引によって確かめられ、ネイティブトークンの色はそのアドレスから導かれるので、他人のトークンの色について宣言することはできません。オフチェーンの登録簿では、書き込んだのが本当に発行者かを証明するために署名や審査の仕組みを別に用意する必要がありますが、イベントならコントラクトを実行したこと自体がその証明になる、というのが提案書の立場です。

提案書は、トークンごとに外部のメタデータサーバーへ問い合わせる方式の弱点も挙げています。ウォレットが自分の持っている色を 1 つずつ問い合わせると、サーバーはその利用者がどのトークンに関心があるかを推測できます。秘匿を前提にした Midnight らしい論点で、保有と無関係にまとめて同期できるイベントの流れは、この問い合わせを減らせるとしています。

■ 決めていないこと、できないこと

MIP-0018 は、あくまで運び方の標準です。提案書は「メタデータのスキーマではなく、転送の方式を定める」と書いており、name・symbol・decimals といったキーは付録の例にとどまります。各キーの意味や必須項目は、今後の別の MIP で決めるとしています。

もうひとつ、なりすましは防げません。どのコントラクトでも名前に「USDC」と書いたイベントは出せます。提案書は、検証済みの宣言が示すのは「そのコントラクトが何を発行したか」であって資産が正当かどうかではないと明言し、ウォレットは許可リストや登録簿の証明、利用者の確認といったキュレーションの手がかりと組み合わせるべきだとしています。オフチェーンの登録簿の下に敷く土台、という位置づけです。

時期の条件もあります。コントラクトのイベントが使えるのは Midnight 2.x(台帳 v9)からで、提案書によれば、いまメインネットで動いているトークンのコントラクトはすべてイベントなしでコンパイルされています。既存のコントラクトは、保守権限を持つ委員会が新しい回路を追加する更新をすれば、作り直さずに宣言を出せるようになります。保守権限が空のコントラクトは誰も更新できず、その場合はオフチェーンの登録簿が唯一の道として残ります。参照実装は、テスト用のネットワークである Stagenet に 11 のコントラクトとして置かれています。

■ MPS-0043: 見せたい相手にだけ見せる

MPS は、解き方を決めずに「何を解くべきか」を書く問題提起の文書です。MPS-0043「Selective Disclosure to a Chosen Party」は、秘匿したデータを特定の相手にだけ開示する手段が Midnight には実質 1 つしかない、と指摘しています。

その 1 つが、秘匿ウォレットの閲覧鍵です。文書によると、この鍵はウォレット全体を開くもので、特定の支払い・相手・期間に絞ることができず、一度渡すと取り消せず、受け取った支払いしか見えないので残高の証明にも使えません。コントラクトの側にも、特定の相手にだけ値を開いて見せる標準の方法がない、としています。

想定される場面として最初に挙がっているのは監査です。ある会計年度の秘匿された受取だけを見せたいのに、いま渡せるのは、過去と将来のすべての受取が見える鍵しかない。Zcash や Penumbra、Aleo がたどった経緯にもふれ、1 件ごとの開示や期限つきの許可へ進んだ他の設計と比べています。

■ 次に確かめる場所

確認先は、GitHub の midnight-improvement-proposals リポジトリです。MIP の段階は Proposed、Review、Accepted、Implemented の順に進むので、MIP-0018 の冒頭にあるステータス欄が Review へ動くかどうかが最初の目安になります。

あわせて、提案書が次の作業として挙げている 2 つ、代替可能なトークン向けのスキーマを定める MIP と、NFT の中身を記述する MIP が同じリポジトリに出てくるかも見ておきたい点です。イベント機構そのものは Midnight 2.x で有効になるので、SIPO が 9 月 19 日の記事で取り上げた midnight-node の 2.1.x 系列が、リリース候補から正式版へ移る時期とも重なってきます。

■ ことば

  • MIP — Midnight Improvement Proposal の略で、Midnight の仕様や標準を変えるための提案書です。MIP-0018 のように番号が振られ、Proposed から Implemented まで段階を踏んで進みます。
  • 色(トークン種別)— Midnight のネイティブトークンを区別する識別子で、発行したコントラクトのアドレスとドメインセパレータから導かれます。見た目は長い 16 進文字列で、MIP-0018 はここに名前を結びつけようとしています。
  • 閲覧鍵 — 秘匿ウォレットが受け取った支払いを復号して見られる鍵です。MPS-0043 は、この鍵がウォレット全体を開き、取り消せないことを、選んだ相手への開示には粗すぎる点として挙げています。

一次ソース / 関連リンク