← 観測ノート一覧

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つの受賞プロジェクト

プロジェクト主領域非公開にする情報公開・証明するもの評価
NightPoolOTC / DeFi注文価格、数量、取引情報資金保有、注文の有効性★★★★★
HermesSNS / Identity身元、資格情報年齢条件、評判、権限★★★★★
LatchAI Agent予算、購入ルール、支出額AIがルールに従ったこと★★★★★
ProveNowPOS / Payment金額、請求書、取引相手支払いが成立したこと★★★★★
MatchLockMatching相手情報、共有秘密双方向マッチ成立★★★★☆
MoonrayGame解答、途中スコア正当にプレイしたこと★★★★☆
AmongUs MidnightGame役割、投票内容役割配布・投票の正当性★★★★☆

7作品を貫く共通原理は単純な「秘匿」ではない。

Privacy → Verification

すなわち、

秘密そのものを明かさず、その秘密について必要な条件が満たされていることだけを証明する

という方向である。


3. Midnightの本質は「Private State × Public Proof」

従来型の公開ブロックチェーンでは、信頼不要性を得る代わりに、多くの場合オンチェーン状態が公開される。

Public Data
+
Public Logic
=
Trustless Verification

Midnightが狙うモデルは異なる。

Private Data
+
Public Verification
=
Trustless + Privacy

Midnightの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
        ↓
     Match

Jubjub曲線を用いて共通秘密を生成し、双方のデータが同一スロットに到達した場合にマッチが成立する。

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 BetaMainnet上の限定利用
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が特に注目する順序は、

  1. Latch
  2. NightPool
  3. ProveNow
  4. 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需要は緩やか
S2Hackathon・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 consumptionNIGHT utilityへの直接接続
Preprod → Mainnet移行率Developer UX成熟度
商用企業導入数B2B適合性
Sponsored transactionsBlockchain 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

  1. Midnight公式ブログ

*Celebrating seven winners from MLH x Midnight July hack* Published: 2026-08-20 ※添付のMidnight Japan日本語訳記事を主要ソースとして使用。

  1. Midnight Japan

*MLH × Midnight July ハッカソンから選ばれた7つのチームを称える* Published: 2026-08-21

  1. Midnight TGE Ltd.

*Midnight Tokenomics and Incentives Whitepaper* Version 1.0, June 2025. NIGHT、DUST、DUST generation、Capacity Marketplace、Sponsored Transaction等の確認に使用。

  1. Midnight TGE Ltd.

*NIGHT MiCA WHITE PAPER* MidnightのKachina、Compact、public/private state、NIGHT/DUST機能、ネットワーク構造の確認に使用。

  1. 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への経済的波及はトークノミクス設計から導ける構造的仮説であり、現時点の価格上昇を保証するものではない。