LIVE ADA-- MCAP-- TVL-- STAKE-- EPOCH-- Cardano & Midnight 総合情報ポータル
SIPO
速報 Intersect、8月26日にDRep向けコミュニティコールを開催 5時間前 速報一覧 →
HOMESignal › Midnight が「注文を探す場所」だけを Celestia に置きました——プライバシーと発見可能性を別の層に分ける設計
Signal

Midnight が「注文を探す場所」だけを Celestia に置きました——プライバシーと発見可能性を別の層に分ける設計

2026-08-26SIPO

Midnight が日本時間の 8 月 25 日 3:37、Celestia との連携を 3 本の連続投稿で告知しました。Zswap の注文を Celestia の共有名前空間へ投稿し、その名前空間を読むウォレットやアプリが同じ注文を見つけられるようにする、という内容です。プライバシー技術の議論は「何を隠すか」に集中しがちですが、取引が成立するには、まず相手が見つからなければなりません。隠すことと、見つけてもらうこと。この二つは、同じ層で解こうとすると必ずぶつかります。今回の設計が面白いのは、その二つを別の層に分けた点です。何がどちらに置かれたのかを順に見ていきます。

■ 告知に書かれていること

投稿は 3 本に分かれています。1 本目は問題の提示です。

Private markets have a discovery problem: how do you make an offer discoverable while keeping the parties involved and unrelated balance information private?

Zswap enables privacy-preserving atomic swaps, while Celestia provides the shared layer for offer discovery.

プライベートな市場には「発見」の問題がある——当事者と、無関係な残高の情報を伏せたまま、どうやって注文を見つけてもらうのか。Zswap がプライバシーを保つアトミックスワップを担い、Celestia が注文発見のための共有層を提供する、という整理です。

2 本目で、具体的な置き方が書かれます。

The unlock is shared discovery.

Zswap offers are posted to a shared Celestia namespace, where wallets and applications that index it can discover the same offers.

The trade itself is visible for matching, while Zswap’s confidentiality properties keep the parties involved and unrelated balance information private.

Zswap の注文は共有された Celestia の名前空間に投稿され、それを索引するウォレットやアプリケーションが同じ注文を発見できる。取引そのものはマッチングのために見える状態に置かれる一方、当事者と無関係な残高の情報は Zswap の秘匿性によって伏せられたままになる——ここが今回の設計の核心です。

■ 「見える」と書かれているのは、どこまでか

ここは読み違えやすいところなので、Midnight 自身の技術文書と突き合わせておきます。

Zswap は公式ドキュメントで「a transaction scheme for data-protecting atomic asset swaps」、つまりデータを保護したままアトミックに資産を交換するための取引方式と説明されています。アトミックであるとは、交換が全部成立するか、まったく成立しないかのどちらかだということです。ドキュメントは「Either all parts of the exchange complete or none do, avoiding partial execution」と書いています。片側だけ渡して終わる状態が原理的に生じません。

そのうえで、何が伏せられるのか。ドキュメントは「Sender, receiver, and amount details do not need to be publicly exposed」——送り手・受け手・金額の詳細は公開される必要がない、としています。公開される側については「The protocol reveals only limited imbalance information per asset class and avoids exposing exact transfer relationships」、資産クラスごとの限定的な不均衡の情報だけが明かされ、正確な移転の関係は露出しない、と書かれています。

つまり今回「マッチングのために見える」とされているのは、取引の当事者や残高そのものではなく、交換を成立させるために必要な差分の情報です。共有名前空間に置かれるのは注文であって、誰がいくら持っているかの一覧ではありません。

■ 発見だけを外に出す、という分け方

プライバシーを保つ取引方式には、実装とは別のところに固有の難しさがあります。注文を誰にも見せなければ、相手も見つかりません。かといって注文を広く配れば、配った先から当事者が推測される余地が生まれます。

Zswap の設計自体は、この点でもともと柔軟です。注文はローカルで証明を作り、直列化して、どこにでも投稿できる形になっています。理屈のうえでは、Discord のチャンネルでも、Telegram のグループでも成立します。ただしそのやり方だと、注文はそれを見た人の範囲にしか届きません。

今回置かれたのは、その「どこに投稿するか」の共通の置き場です。ウォレット A が投稿した注文を、ウォレット B もマーケットプレイス C も、同じ名前空間を読むことで拾える。秘匿の仕組みは Zswap 側に残したまま、発見の経路だけを外の共有層に出しました。

■ 作る側から見ると、何が減るのか

3 本目は、開発者にとっての意味に寄せて書かれています。

For builders, this means less infrastructure to build and maintain.

Instead of building and optimising a gossip layer for offer dissemination, teams can focus on the parts of their protocol that actually differentiate them.

Privacy-preserving by design. Discoverable by design. Shared across the ecosystem.

注文を配るためのゴシップ層を自前で作り、最適化する作業が要らなくなる、という主張です。ここは開発コストの話に見えて、実際にはもう少し構造的な話でもあります。

取引の場を新しく立ち上げるとき、いちばん重くのしかかるのは、たいてい機能ではなく流動性です。板に注文が並んでいない場所には、誰も注文を置きに来ません。注文の置き場がエコシステムで共有されていれば、新しいウォレットや取引の場は、その最初の空白をゼロから埋め直さずに済みます。読みに行けば、すでにそこに注文があるからです。

Input Output もこの点を補強しています。同社は同日、この構成を「A strong example of modular design in practice」——実践におけるモジュール設計の好例だと述べ、ウォレットやアプリが「separate markets from scratch」を作らずに流動性を共有できる点を挙げました。チャールズ・ホスキンソン氏も同じ時間帯に、Celestia との協業について短く肯定的な投稿を出しています。

■ 次に確認したいこと

告知の時点で、まだ書かれていないことがあります。三点あげておきます。

ひとつは、この経路がいつから、どのウォレットで使えるのかです。告知は設計の説明であって、利用可能な機能としての案内ではありません。

ふたつめは、名前空間を読む側の負担です。共有された置き場に注文が集まるほど、それを索引する側が処理する量は増えます。軽量なクライアントがどこまで自前で読むのか、あるいは索引する役割が別に立つのかは、実装が出てからでないと分かりません。

みっつめは、可用性の前提が一段増えることです。注文の発見を外部の層に預けるということは、その層が読める状態にあることを前提にするということでもあります。Zswap の秘匿性そのものは Midnight 側に残るとしても、注文が見つかるかどうかは共有層の側に依存します。取引の成立に必要な条件が、どこに、いくつ置かれているのか——プライバシーの設計を読むときは、隠せる範囲と同じくらい、この依存の形を見ておきたいところです。


一次ソース / 関連リンク