OBSERVATION NOTE / MDFOOB-HU
MLH × Midnight July Hackathon受賞7プロジェクト解説 ― Private State × Public Proofが示すMidnightの勝ち筋
受賞7プロジェクトから、Midnightの実用的プライバシー設計、Preprod到達、NIGHT/DUSTへの接続、商用化シナリオを整理します。
Private State × Public Proofが示すMidnightの勝ち筋
[!summary] 2026年7月17日から19日に開催された48時間の「MLH × Midnight」ハッカソンでは、84チームが参加し、プライバシーインフラとゲームの2トラックから7プロジェクトが受賞した。 重要なのは受賞数そのものではなく、Midnightのゼロ知識証明を使い、秘密情報を公開せずに必要な事実だけを検証可能にするアプリケーションが複数の分野で成立した点にある。 今回の成果は、Midnightが「匿名通貨」ではなく、Private State × Public Proofを中核とするアプリケーション基盤を目指していることを具体的に示している。
1. 添付記事の概要
2026年8月20日付のMidnight公式ブログ「Celebrating seven winners from MLH x Midnight July hack」を、Midnight Japanが2026年8月21日に日本語訳した記事によると、7月17日から19日にかけて48時間のハッカソンが開催された。
開発テーマは、ユーザー自身が個人データを主権的に管理できるアプリケーションである。参加者は初心者からブロックチェーン経験者まで幅広く、84チームが参加したと説明されている。
審査員は以下の2トラックから計7プロジェクトを選出した。
- Privacy Infrastructure
- Gaming
記事末尾ではDevpostギャラリーに「全86件」の作品があると記されている。一方、冒頭は「84チーム」とされているため、これは参加チーム数と投稿作品数など集計単位が異なる可能性がある。提示記事のみでは差異の理由は確認できない。
2. 7つの受賞プロジェクト
| プロジェクト | 主領域 | 非公開にする情報 | 公開・証明するもの | 評価 |
|---|---|---|---|---|
| NightPool | OTC / DeFi | 注文価格、数量、取引情報 | 資金保有、注文の有効性 | ★★★★★ |
| Hermes | SNS / Identity | 身元、資格情報 | 年齢条件、評判、権限 | ★★★★★ |
| Latch | AI Agent | 予算、購入ルール、支出額 | AIがルールに従ったこと | ★★★★★ |
| ProveNow | POS / Payment | 金額、請求書、取引相手 | 支払いが成立したこと | ★★★★★ |
| MatchLock | Matching | 相手情報、共有秘密 | 双方向マッチ成立 | ★★★★☆ |
| Moonray | Game | 解答、途中スコア | 正当にプレイしたこと | ★★★★☆ |
| AmongUs Midnight | Game | 役割、投票内容 | 役割配布・投票の正当性 | ★★★★☆ |
7作品を貫く共通原理は単純な「秘匿」ではない。
Privacy → Verification
すなわち、
秘密そのものを明かさず、その秘密について必要な条件が満たされていることだけを証明する
という方向である。
3. Midnightの本質は「Private State × Public Proof」
従来型の公開ブロックチェーンでは、信頼不要性を得る代わりに、多くの場合オンチェーン状態が公開される。
Public Data
+
Public Logic
=
Trustless VerificationMidnightが狙うモデルは異なる。
Private Data
+
Public Verification
=
Trustless + PrivacyMidnightのMiCA White Paperでは、Kachina由来の設計として、公開状態と秘密状態を分離し、ゼロ知識証明によって両者を接続する構造が説明されている。Compactはそのためのプライバシー保護型スマートコントラクト言語として位置付けられている。
したがってMidnightの競争相手を「プライバシーコイン」とだけ見るのは不十分である。
より正確には、
企業・金融・AI・ID・ゲームなどにおける「秘匿状態を持つ検証可能なアプリケーション」
が主要市場になる。
4. NightPool ― Private DeFiの代表例
NightPoolは、シールドオークション機能を備えたダークプール型OTC取引デスクである。
公開DEXでは、大口注文をオンチェーンに置くと、
- 注文価格
- 数量
- wallet
- 注文タイミング
- 市場参加者の意図
などが観察可能になる。
これは大口取引ではフロントランニングや情報漏洩につながり得る。
NightPoolでは注文内容を直接公開せず、コミットメントとして登録する。
注文価格・数量
↓
Commitment
↓
公開台帳取引参加者は、実際の注文情報を公開せずに、取引に必要な資金を保有していることなどを証明できる。
Commitment
概念的には次のように理解できる。
Commit(data, salt) → commitment第三者にはコミットメント値しか見えないが、後から「この値は以前にコミットしたデータに対応する」と証明できる。
ここでsaltを再利用すると、複数のコミットメントの関連性を推測される危険があるため、記事でも再利用禁止が強調されている。
5. Nullifier ― 今回の7作品を理解する重要概念
今回の記事には複数回「nullifier」が登場する。
Nullifierは簡略化すれば、
秘密を公開せずに「この権利・注文・投票・レシートは既に使われた」と証明するための識別子
である。
NightPoolの場合、
Private Order
↓
Execute
↓
Nullifier
↓
同じ注文を再利用不可となる。
これはZKアプリケーションにおいて非常に重要で、プライバシーを維持しながら二重使用を防ぐ。
今回の作品では、
- 注文の再使用防止
- 投票の重複防止
- レシートの二重換金防止
- ゲーム上の二重行為防止
などにNullifierが応用されている。
6. Hermes ― 匿名SNSではなく「属性証明」の基盤
HermesはRedditのような匿名フォーラムとして紹介されているが、本質は匿名投稿そのものではない。
重要なのは、
Identityを公開せずPredicateだけを証明する
ことである。
たとえば、
本人の氏名 → 非公開
生年月日 → 非公開
18歳以上か → 証明
Moderator権限 → 証明
Reputation > 100 → 証明という設計が可能になる。
これはSNSを超えて、
- KYC
- 年齢確認
- 医療資格
- 会員資格
- 適格投資家判定
- 社内アクセス制御
などに応用できる。
企業用途の例
氏名・職員番号・所属
↓ 非公開
「医療従事者資格を持つ」
↓ 証明必要以上の個人情報を開示せずにアクセス資格のみを確認できる。
これはMidnightが掲げるSelective DisclosureやRational Privacyの具体像に近い。
7. Latch ― AIエージェント経済との接点
今回の7作品の中で、将来性の観点から特に重要なのがLatchである。
LatchはAIアシスタントに対して、
- 1回あたりの支出上限
- 総予算
- 許可された商品カテゴリ
- 実際の支出額
を非公開にしたまま、購入がポリシーに準拠していることだけを証明する。
Private Policy
↓
AI Agent
↓
Purchase
↓
ZK Proof
↓
Policy Compliantここで重要なのは、AIに渡したポリシーそのものが公開台帳に出ないことである。
例えば、
1回 ≤ 10,000円
月間 ≤ 100,000円
医療用品のみ
特定業者は禁止というルールをAIに設定した場合でも、外部にはその詳細を見せず、
「今回の支払いは許可されたルールの範囲内である」
という事実だけを証明できる。
8. AI Agent × Privacyがなぜ重要か
AIエージェントが、
検索
↓
比較
↓
交渉
↓
注文
↓
支払いまで自律的に行うようになると、公開ブロックチェーン上ではその活動履歴から、
- 誰のAIか
- 何を買うか
- 予算
- 購買頻度
- 取引相手
- 行動パターン
- 経営戦略
などが推測される可能性がある。
AIエージェント経済では「決済できること」だけでは足りない。
秘密のルールの下で行動し、そのルールに従ったことだけを証明できる仕組み
が必要になる。
Latchはこの構造を48時間のハッカソンで具体化した点で重要である。
9. ProveNow ― Private Commerceへの入り口
ProveNowは、POSで支払いが行われたことを、
- 金額
- 請求書
- 取引相手
を公開せずに証明する。
Payment
↓
Commitment
↓
On-chain
↓
後日、支払い済みを証明さらにused-receipt setを利用し、同じレシートを再利用することを防ぐ。
このモデルは単なるPOS用途に留まらない。
応用例
保証サービス
商品を購入した → 証明
購入価格 → 非公開
購入店舗 → 非公開経費精算
支払い済み → 証明
取引条件 → 非公開B2B取引
請求書決済済み → 証明
契約条件 → 非公開企業がパブリックブロックチェーン採用をためらう理由の一つは、取引データや商流が競合から観測され得る点にある。
ProveNowはこの問題に対する非常に分かりやすい回答になっている。
10. MatchLock ― Privacy-preserving Matching
MatchLockは、互いを非公開で指名した2者が、メッセージを直接交換せずに同じ共有秘密を導き出す仕組みである。
Alice → Bob
Bob → Alice
↓
MatchJubjub曲線を用いて共通秘密を生成し、双方のデータが同一スロットに到達した場合にマッチが成立する。
Nullifierによって、同方向への二重投稿を利用した偽装も防止する。
応用可能性は広い。
- Dating
- Private recruiting
- OTC counterparties
- Whistleblower matching
- DAO coordination
- 商談相手の相互意思確認
などが考えられる。
Compactの制約から見える設計原則
記事では、Compactに回路内暗号化機能がないため、ペイロードをクライアント側で暗号化してopaque BLOBとしてコントラクトに渡したと説明される。
Client Side
↓ encrypt
Encrypted BLOB
↓
ContractこれはZKアプリの重要な設計原則を示す。
On-chainに置くもの
- Commitment
- Nullifier
- Proof
- Public State
Off-chainで処理するもの
- Heavy computation
- Encryption
- Sensitive data
- Client-side private state
すべてをオンチェーンに置く必要はない。
11. Moonray ― Commit-Revealの実用例
Moonrayは毎日のトーナメント形式パズルゲームである。
全プレイヤーが同じシードを使うため、解答を即時公開すると他者がコピーできる。
そこで解答そのものを公開せず、
Solution
↓
Commitment
↓
Blockchainとして先にコミットする。
後の公開期間に解答を明かして検証する。
Solution + Secret
↓
VerifyこのCommit-Revealモデルはゲームだけでなく、
- DAO投票
- Sealed-bid auction
- 入札
- Prediction Market
- コンテスト
- ガバナンス
- 採用選考
などにも使える。
Moonrayは「秘密情報が競争条件そのもの」である場合のZK利用を示している。
12. AmongUs Midnight ― 秘密そのものがゲームロジック
Among Us型ゲームでは、
- 誰がCrewか
- 誰がImpostorか
- 誰に投票したか
という秘密がゲーム性そのものである。
従来はゲームサーバーが秘密情報を管理し、ユーザーはサーバーを信用する必要がある。
Midnightでは、
Secret Role
↓
Private Stateとして保持しながら、
正しい役割配布
正しい投票
重複投票なしを暗号学的に証明できる。
つまり、
Trusted Game Server
から
Cryptographically Verifiable Game
への移行である。
ゲームは実験的に見えるが、実際には「秘密状態を持ちながら公平性を検証する」というZKの強みを一般ユーザーに理解させる優れたユースケースでもある。
13. Preprod到達の意味
7受賞作品のうち、
- Hermes
- Moonray
の2つがMidnight Preprodにデプロイされた。
これは今回のニュースで非常に重要な点である。
48時間の期間内に、
Idea
↓
Compact Contract
↓
Test
↓
Frontend
↓
Deploy
↓
Preprodまで到達できた。
これは第三者開発者がMidnightのツールチェーンを利用し、短期間で公開テスト環境まで進めることが可能であることを示す。
ただし、過大評価してはいけない。
確認できたこと
- Compactで第三者アプリを開発できる
- 実用的なZKユースケースが複数成立した
- 一部プロジェクトはPreprodへ到達した
- UI、Contract、Testまで完成させた作品がある
まだ確認できないこと
- 大規模ユーザー利用
- Production環境での長期安定運用
- 高負荷時のZK proving性能
- セキュリティ監査済み商用展開
- Product-Market Fit
- DUST実需
- NIGHT価格への経済的還流
したがって現在地は、
Technology Hypothesis → Prototype
を越えつつある段階であり、
Prototype → Economy
はこれからである。
14. Local Devnet / Preprod / Mainnetを混同しない
今回の記事を読む際には環境の違いを区別する必要がある。
| 段階 | 意味 |
|---|---|
| Local Devnet | 開発者ローカル環境 |
| Preprod | 公開テストネット |
| Private Mainnet Beta | Mainnet上の限定利用 |
| Public Mainnet dApp | 一般利用可能な本番サービス |
HermesとMoonrayはPreprodである。
したがって、
「7つのdAppがMidnight mainnetで稼働した」
という解釈は誤りである。
今回の成果はあくまで「第三者開発者によるZKアプリ開発が公開テスト環境まで到達した」というDeveloper Adoptionのシグナルとして評価すべきである。
15. NIGHT / DUSTトークノミクスへの接続
MidnightのTokenomics and Incentives Whitepaperでは、NIGHTはDUSTを生成する資産とされる。
DUSTはMidnightのトランザクション実行に必要なネットワークリソースであり、
- shielded
- renewable
- consumable
- non-transferable
- decaying
という性質を持つ。
一方、NIGHTは取引を行うたびに消費されるわけではない。
したがってアプリケーション需要が増えた場合の経済的な流れは、
Useful Privacy dApps
↓
Users
↓
Transactions
↓
DUST Demand
↓
DUST-generation Capacity Demand
↓
NIGHT Utility Demandとなる。
重要なのは、
NIGHTがガス代として毎回消費されることではなく、ネットワーク容量を生み出す資本資産であること
である。
16. Capacity Marketplaceまで進むと何が変わるか
Tokenomics Whitepaperでは、将来的なCapacity Marketplaceが構想されている。
NIGHT保有者は、自分のDUST生成能力を他者へ向けることができる。
またDApp事業者はユーザーのDUSTコストをスポンサーできる。
最終的にはユーザー自身が、
- NIGHTを持たない
- DUSTを意識しない
- blockchainを意識しない
状態でもMidnightアプリを使える設計が想定されている。
User
↓
DApp
↓
Sponsored Transaction
↓
DUST Provider
↓
Midnight Networkこの構造が実現すると、LatchやProveNowのようなアプリは一般消費者向けUIの裏側でMidnightを利用できる。
この意味で、ハッカソン作品が実需に発展した時に初めて、
Developer Activity → DUST Demand → NIGHT Utility
という経済経路が成立する。
17. 「一言で理解できるユースケース」が重要
今回の記事で非常に重要なのが、受賞作に共通する特徴として、
他人が一言で理解できるユースケース
が挙げられていることだ。
ZKは技術説明を始めると難しくなる。
ユーザーは、
- zkSNARK
- Jubjub
- Merkle tree
- Nullifier
- Commitment
を理解する必要はない。
必要なのは、
「金額を見せずに支払い済みを証明できる」
「予算を公開せずAIの浪費を防げる」
「身元を明かさず資格だけ証明できる」
「役割を明かさず公平なゲームができる」
という体験である。
ZK技術が一般社会に普及するには、暗号技術そのものではなく、解決される問題が一文で説明できることが重要である。
18. 7作品から見えるMidnightの有力ユースケース
CGTAは今回の成果から、Midnightの強みを次の4領域に整理する。
① AI Agent
代表:Latch
AIエージェントが秘密のポリシーに従って自律的に支出し、ポリシー準拠だけを証明する。
将来的には、
- Agent Wallet
- Corporate Agent
- Procurement Agent
- Healthcare Agent
- Autonomous Commerce
との接続が考えられる。
② Private Finance
代表:NightPool
金融取引の価格・数量・参加者情報を隠しながら決済可能性を検証する。
Institutional DeFiとの相性が良い。
③ Identity / Compliance
代表:Hermes
身元を明かさず、
- 年齢
- 権限
- 資格
- Reputation
- Compliance status
などを証明する。
④ Private Commerce
代表:ProveNow
支払いの存在を証明しながら、商取引条件を公開しない。
B2B、POS、RWA、保険、保証などへの応用余地がある。
19. CGTA評価
今回のニュースは、Midnightにとってかなり質の高いDeveloper Adoptionシグナルである。
特に重要なのは、7作品が単なる「Privacy Demo」ではなく、それぞれ現実世界の問題をZKで解決する形に落としている点だ。
CGTAが特に注目する順序は、
- Latch
- NightPool
- ProveNow
- Hermes
である。
LatchはAIエージェント経済、NightPoolはInstitutional DeFi、ProveNowは商取引、HermesはIdentity/Complianceという巨大市場につながる可能性がある。
ただし、現時点で確認できるのはあくまでPrototypeおよびPreprodレベルであり、商用成功を意味しない。
20. 5段階シナリオ分析
| Scenario | 状況 | Midnightへの意味 |
|---|---|---|
| S5 最良 | Latch/NightPool/Hermes系から複数の商用サービスが成立 | Privacy Application Platformとして定着。DUST需要が構造化 |
| S4 | 多数のHackathon作品がPreprodからMainnetへ移行 | Developer ecosystemが成長し、継続的トランザクション需要が形成 |
| S3 基準 | 開発者コミュニティは形成されるが商用化は限定的 | 技術基盤として一定成功。DUST需要は緩やか |
| S2 | Hackathon・PoC中心で停滞 | Developer activityはあるがPMFが弱い |
| S1 最悪 | Productionへの移行が進まず利用者も増えない | DUST実需が形成されず、NIGHTユーティリティも限定 |
2026-08-21時点のCGTA評価:S3からS4へ進めるかを観察する段階。
S5を評価するには、Mainnetでの継続利用、実ユーザー数、トランザクション、DUST消費量、商用サービス数などの確認が必要である。
21. 今後観測すべきKPI
Midnightの実用化を追うなら、ハッカソン参加数よりも次の指標が重要になる。
| KPI | 意味 |
|---|---|
| Mainnet dApp数 | PrototypeからProductionへの移行 |
| Active developers | 開発者エコシステムの継続性 |
| Weekly active users | 実需 |
| Transaction count | ネットワーク利用 |
| DUST consumption | NIGHT utilityへの直接接続 |
| Preprod → Mainnet移行率 | Developer UX成熟度 |
| 商用企業導入数 | B2B適合性 |
| Sponsored transactions | Blockchain abstractionの進展 |
| Capacity Marketplace利用 | NIGHT→DUST経済の成熟 |
| NIGHT保有集中度 | ネットワーク経済の健全性 |
22. 結論
今回のMLH × Midnight July Hackathonで最も重要なのは、7つの受賞作そのものではない。
重要なのは、
Midnightの「Private State × Public Proof」という設計が、金融・SNS・AI・決済・マッチング・ゲームという異なる領域で同じ原理として再利用できたこと
である。
この汎用性は大きい。
Midnightが成功する条件は、プライバシー技術が優秀であることだけではない。
最終的には、
ZK Technology
↓
Simple UX
↓
Useful dApp
↓
Users
↓
DUST Demand
↓
NIGHT Utilityという経路が成立する必要がある。
今回のハッカソンは、その最初の3段階、
ZK Technology → Simple Use Case → Working Prototype
が実際に第三者開発者によって成立し始めたことを示した。
したがって今回のニュースは、Midnightにとって「技術デモ」から「アプリケーション・エコシステム形成」へ移る過程を示す前向きなシグナルと評価できる。
一方で、Mainnet商用利用、DUST実需、NIGHTへの経済的還流はまだ十分に確認されていない。
次に見るべきなのは、これらのPrototypeがMainnet上で継続的に使われるProductへ進化するかどうかである。
Sources
- Midnight公式ブログ
*Celebrating seven winners from MLH x Midnight July hack* Published: 2026-08-20 ※添付のMidnight Japan日本語訳記事を主要ソースとして使用。
- Midnight Japan
*MLH × Midnight July ハッカソンから選ばれた7つのチームを称える* Published: 2026-08-21
- Midnight TGE Ltd.
*Midnight Tokenomics and Incentives Whitepaper* Version 1.0, June 2025. NIGHT、DUST、DUST generation、Capacity Marketplace、Sponsored Transaction等の確認に使用。
- Midnight TGE Ltd.
*NIGHT MiCA WHITE PAPER* MidnightのKachina、Compact、public/private state、NIGHT/DUST機能、ネットワーク構造の確認に使用。
- Cardano Epoch reference
Epoch 650: 2026-08-18 06:44:51 JST - 2026-08-23 06:44:51 JST.
Fact Check Notes
- 「84チーム」と「Devpost全86件」の差は、提示記事のみでは理由不明。参加チーム数と投稿数など集計単位の違いの可能性があるが、未確認。
- HermesとMoonrayがPreprodに到達したことは添付記事の記載に基づく。
- 他5作品は記事上ローカル環境に留まったとされる。
- ハッカソン受賞は商用化・Mainnet稼働・PMFを意味しない。
- NIGHT/DUSTへの経済的波及はトークノミクス設計から導ける構造的仮説であり、現時点の価格上昇を保証するものではない。