Midnight のデプロイ申請リポジトリで日本時間 9 月 23 日 12 時 20 分、Shadow Labz が出した 3 本のコントラクトのメインネット展開申請が、Midnight 側のレビュアーに承認されてマージされました。プライバシーを保ったまま投票・意見収集・DAO 運営を行うための一式で、いずれもネイティブトークンを一切受け取らず、持たず、送らない設計です。
資金を扱う回路を外したビルドを先に出し、資金を預かる部分は別の申請へ切り離す。この分け方は、プライバシー技術を実際のサービスに載せるときの順番として読む価値があります。申請書に書かれた仕様と自己評価、そしてこのリポジトリが定めている審査の枠組みから、何が承認されたのかを見ていきます。
■ 投票・意見・DAO の 3 本
申請の対象は 3 本のコントラクトで、それぞれ一度だけ展開して多数のインスタンスに使い回す形をとります。
- Shadow Polls（
shadow_polls.compactの 1 問版とshadowpollv1.compactの複数問版）— 参加資格を、資格者名簿を一つの値に畳み込んだマークル木の根に対して証明したうえで投票します。秘密から作られる使い捨ての印であるヌリファイアによって「1 人 1 票」が強制され、公開されるのは選択肢ごとの集計値だけです。誰がどれを選んだかの結びつきはチェーンに載りません - Shadow Feedback（
shadowfeedback.compact）— 匿名の意見収集です。投稿者は資格を証明し、トピックごとに一度だけ使えるヌリファイアを消費します。意見の中身はトピック管理者の鍵で端から端まで暗号化され、チェーン上には 2,048 バイト固定の暗号文としてのみ置かれます - ShadowDAO v1（
shadowdaov1.compact）— 提案作成を権限者に限り、投票はコミット・リビール方式で行います。開票までどれを選んだかは伏せられたままです
3 本とも、申請書の自己評価は「プライバシー 1・価値 1・状態量 2」で揃っています。数字の意味は後で触れます。
申請書が自分から弱点を書いている箇所もあります。Shadow Polls について、集計値がその場で更新されるため、参加者がごく少ない投票では、取引のタイミングを突き合わせた観測者が選択を推測できる余地がある、と明記されています。そのうえで、開票まで集計を伏せる HIDDEN_UNTIL_CLOSE を今後の対応として記録し、そのための resultVisibility という項目はすでに保存しているとしています。
■ 国庫の回路を抜いて出す
今回の申請でいちばん目を引くのは、ShadowDAO v1 の出し方です。
申請書によれば、展開されるビルドからは国庫関連の 2 つの回路（fund_treasury と execute_approved_spend）が除かれています。結果として、展開されるコントラクトにはネイティブトークンを扱う API が存在せず、資金を受け取ることも保持することも送ることもできません。DAO のガバナンス機能だけを先に動かす、という切り分けです。
資金を預かる部分は escrow.compact という別のコントラクトにまとめられ、今回の申請からは外されています。理由も書かれています。ローンチパッドのエスクローはプロジェクトごとに資金を預かる存在で、目標額に達するか返金されるまで資金が積み上がるため、価値リスクの審査と TVL（預かり資産総額）の上限をどう置くかの議論を単独で受けるべきだ、というものです。その議論が固まったあとに別途提出する、と申請書は述べています。
順序として見ると、危険度の低い部分から先に本番へ出し、資金を扱う部分は審査の場を分けて後に回す形になります。プライバシー機能そのものよりも、資金をどこで預かるかのほうが審査の重心になっている、という現在のメインネットの姿がここに出ています。
■ 「この審査は監査ではありません」
数字の意味と、この承認が何を保証しないかに触れておきます。同じリポジトリに置かれた審査基準の文書は、冒頭にこう書いています。
「コントラクトのデプロイ申請レビューは監査ではありません」
評価は 3 つの観点で 1 から 3 の段階を付けます。プライバシー（証明系の不具合で秘密が漏れたとき、利用者は何を失うか）、価値（悪用されたとき、利用者はいくら失いうるか・それは取り戻せるか）、状態量（台帳に恒久的な状態をどれだけ積むか・その増加を攻撃に使えるか）の 3 つです。基準文書は「点数が表すのは、何かが起きたときに実際に何が懸かっているかであって、それが起こりやすいかどうかではない」と明記しています。
価値の「1」は、コントラクトに資金が一切ロックされない設計を指します。悪用されても利用者の元本が直接失われることはなく、リスクはガス代や動作の停止に限られる段階です。状態量の「2」は、利用に応じて状態が増えるものの、参加者ごと・投票ごとに上限があることを指します。Shadow Labz の 3 本では、1 人 1 票のヌリファイアと、固定の深さを持つマークル木が、その上限の役割を果たします。
そして、どれか一つでも「3」と判定されると展開は止まります。基準文書はこれを永久的な却下ではなく設計を考え直す合図だとし、Discord の開発者向けチャンネルや開発者フォーラムで構成を共有するよう促しています。申請書の末尾にも、審査でいずれかが 3 と判断された場合は、本番で動かす前にそれらの場で設計を議論する、という一文が置かれています。
■ 承認までの 2 日間と、次に出てくる申請
承認までの経緯も公開されています。申請は 9 月 21 日 10 時 49 分（JST）にプルリクエスト #320 として開かれました。翌 22 日 9 時 35 分（JST）、Midnight 側のレビュアーが変更要求を出します。内容は、マージを検討する前に貢献者ライセンス同意（CLA）への署名が必要だというものでした。署名が確認されたのち、9 月 23 日 12 時 20 分（JST）に承認され、同じ分にマージされています。
この deployments ディレクトリには、Shadow Labz のほかにも ascend-dex、zkart、nightforce-directory といった申請ファイルが並んでいます。誰がどういう設計で何を出したか、どの観点をどう自己評価したかが、まとめて読める場所になっているということです。メインネットで動くものが増えるほど、この一覧は「Midnight の上で今なにが動こうとしているか」の目録に近づきます。
そのうえで残る問いは、資金のほうです。今回の 3 本は、資金を持たないという理由で価値リスク 1 を得ました。しかし Shadow Labz が作ろうとしているのは、募った資金を DAO が使うところまでを含む仕組みで、escrow.compact はそのために存在します。資金を持たない側だけを先に通すやり方は、審査を進めるうえでは合理的です。では、資金を持つ側が同じリポジトリに出てきたとき、価値リスクと TVL 上限はどこに置かれるのか。次に確認できるのは、この deployments ディレクトリに escrow.compact のファイルが追加されるときです。そこに書かれる自己評価の点数と、上限の数字が、Midnight のメインネットが資金を扱うアプリをどこまで受け入れるかの最初の目盛りになります。
■ ことば
- ヌリファイア — 一度きりの使用を強制するための使い捨ての印。秘密から作られるため誰のものかは分からず、同じ印が二度出れば重複と判定できます。Shadow Labz では「1 人 1 票」と「1 トピックに 1 投稿」の両方をこれで担保しています。
- コミット・リビール — まず選択を伏せた形（コミット）で提出し、締切後にその中身を明かす（リビール）二段階の投票方式。投票中に他人の選択が見えないため、途中経過に引きずられた投票や、集計の途中から選択を推測されることを防げます。ShadowDAO v1 が採る方式です。
- マークル木の根 — 参加資格のある人の一覧を一つの短い値に畳み込んだもの。この値だけを公開すれば、自分がその一覧に入っていることを、一覧そのものや自分の位置を明かさずに証明できます。Shadow Polls の資格確認がこの形です。
一次ソース / 関連リンク
- Midnight Improvement Proposals：Shadow Labz のデプロイ申請書
https://github.com/midnightntwrk/midnight-improvement-proposals/blob/main/deployments/shadow-labz.md - 同：プルリクエスト #320（申請から承認・マージまでの経緯）
https://github.com/midnightntwrk/midnight-improvement-proposals/pull/320 - 同：コントラクト展開の審査基準（スコアの定義・3 の扱い・申請手順）
https://github.com/midnightntwrk/midnight-improvement-proposals/blob/main/deployments/contract-deployment-rubric.md