Midnightの中央集権性を巡る主張、必要なのは拡散ではなく証拠

Midnightの中央集権性を巡る論点は現実のもの。最も深刻な主張にはなお証拠が必要

Midnightのバリデーター構造、トークン管理、管理者キー、本番ソフトウェアを巡る主張は、正当なガバナンス上の疑問を提起している。ただし、ここで検討した証拠に照らす限り、これらはプロジェクトが不正であることや、バリデーターが非開示のクローズドソースコードベースへ秘密裏に切り替えたことを立証するものではない。

この区別は重要である。ネットワークは中央集権的な管理を伴ってローンチし、その後に分散化することがある。プロジェクトはソフトウェアの一部を公開しつつ、非公開の構成要素を保持することもある。いずれも自動的に不正行為となるわけではない。しかし、その両方をユーザー、開発者、投資家に明確に開示すべきである。

Justun Bonsに帰属される主張については、同氏がそれを行った元の投稿、インタビュー、文書にリンクすべきである。本記事で検討した資料は、同氏に帰属されるすべての引用や具体的な主張を独自に検証したものではない。

Midnightが構築するもの

Midnightは、Charles Hoskinsonが創業した企業Input Outputと関係する、プライバシー重視のblockchainプロジェクトである。その設計は、アプリケーションが選択した情報を非公開に保ちながら、必要に応じてユーザーやアプリケーションが特定の事実を開示できるようにすることを意図している。

プライバシーの問題は、単にデータが隠されているかどうかではない。誰に対して非公開なのか、すなわち他のユーザー、バリデーター、アプリケーション運営者、一般公開の対象者、あるいはそのすべてに対してなのかが問われる。Midnightのモデルは、すべての取引がすべての参加者から見えないという前提ではなく、選択的開示を中心に構築されている。

システムは主に2種類の資産を用いる。

• NIGHTはネットワークの譲渡可能なトークンであり、経済的インセンティブ、ガバナンス、その他のネットワーク機能を支えることが想定されている。
• DUSTは取引および計算コストに用いるリソースである。NIGHTの直接的な支出から手数料消費を分離し、アプリケーションのコストをより予測可能にするよう設計されている。

DUSTを、留保なく通常の第2通貨と表現すべきではない。その役割はネットワークリソースへの支払いであり、NIGHTはプロジェクトの経済モデルで用いられる譲渡可能な資産である。

Midnightの初期配布はCardanoと密接に結び付いていた。これはNIGHTがADAと同じ資産であることを意味せず、MidnightがCardanoのメインチェーンであることも意味しない。Midnight独自のネットワークインフラが発展する間、初期配布とユーザー体験の一部がCardanoベースの資産、ポリシー、契約に依存していることを意味する。

ここには重要な区別がある。トークン保有はネットワーク利用と同義ではない。プロジェクトは大量のトークンを配布していても、取引活動が限定的で、アプリケーションが少なく、独立した運営者の数も少ない可能性がある。

従って有用な指標は、配布されたNIGHTトークン数だけではない。アクティブユーザー、取引数、デプロイされたアプリケーション、独立バリデーター、少数の管理グループに依存せずにCardanoとMidnightの間で資産を移動できる能力も含まれる。

バリデーターを巡る問題

Bonsに帰属される主張では、Midnightの初期ネットワークは許可型であり、オープンなプルーフ・オブ・ステーク方式よりもプルーフ・オブ・オーソリティに近いとされる。この主張は、関連するMidnightの技術文書とネットワーク状況の情報に結び付ける必要がある。

根本的な問題は単純である。ネットワークは制限されたバリデーターセットで始まる可能性がある。運営者は、オープンなstakingプロセスを通じて参加するのではなく、財団、管理者、統治グループによって承認される場合がある。この方式は、テスト、統制されたデプロイ、インシデント対応に役立ち得る。しかし、公表されたルールの下で幅広く参加可能なオープンなバリデーターネットワークと同じものではない。

「バリデーター」という言葉も、複数の異なる区分を覆い隠し得る。

• 登録済みまたは承認済みの運営者。
• インフラを運用しているがブロックを生成していない運営者。
• 稼働中のブロック生成者。
• 将来参加する予定の運営者。
• ガバナンスまたは管理上の署名者。

Midnightの文書がある数を示す一方で、実際に稼働している運営者がより少数であるなら、プロジェクトは用語を定義し、現在のセットを公表すべきである。承認済み事業体の数は、現時点でチェーンを保護している独立事業体の数と同じではない。

より重要な問題は、それらの運営者が何をできるかである。許可型でのローンチは、公表された移行計画、限定的な権限、より広範な参加への明確な道筋があれば、必ずしも問題ではない。参加承認のルールが裁量的である場合、緊急権限が期限なく続く場合、あるいはプロジェクトが制限されたシステムをすでにパーミッションレスであるかのように提示する場合、それはガバナンスリスクとなる。

管理者キーには権限マップが必要

Midnightに10本の管理者キーがあるという主張は、ここで検討した資料によって独自に確立されてはいない。この数字を用いる場合、記事は根拠となる文書を特定し、それらのキーが何を管理するのかを説明すべきである。

キーの本数だけでリスク水準は決まらない。関連する問いは以下の通りである。

• キーは口座を凍結できるか。
• 取引を検閲または取り消しできるか。
• バリデーターのメンバーシップを変更できるか。
• コンセンサスソフトウェアをアップグレードできるか。
• トークン供給量または配布ルールを変更できるか。
• 署名のしきい値は必要か。
• キー保有者は特定されているか、または独立監査を受けているか。
• 権限は自動的に失効するか。

緊急停止のみに使われるキーは、残高を書き換えたり全バリデーターを任命したりできるキーとは異なるリスクをもたらす。Midnightは、各管理上の役割、実行に必要なしきい値、介入を許容する事象、権限が失効する条件を網羅する権限マップを公表すべきである。

匿名のキー保有者は、それ自体が不正行為の証拠ではない。暗号システムでは、運用上の身元を保護することが多い。しかし、同じキーがプロトコルの挙動を変更したりユーザー資産を管理したりできる場合、匿名性は説明責任を低下させる。その状況では、独立監査、しきい値署名、公表された手順がより重要になる。

Cardano側のNIGHTポリシーにできること、できないこと

Cardano上で保有されるNIGHTが、ユーザー資金を盗める契約または管理者キーによって管理されているという主張は、複数の異なる技術的リスクを混同している。関連するCardanoの資産ポリシー、契約コード、ポリシー識別子、署名構成がなければ、事実として述べるべきではない。

Cardanoのネイティブ資産は、ミンティングポリシーによって管理される。ポリシーは、そのルールとポリシーキーの有効期間に応じ、追加ユニットを発行または焼却できるかを管理し得る。これは、ユーザーが保有するすべてのトークンを恣意的に移転できる一般的なアカウントベース機能とは異なる。

CardanoベースのNIGHT表象を凍結、移転、その他の方法で制限できるかは、正確な実装に依存する。ミンティングポリシーだけでは、その保有者に既存残高すべてを差し押さえる権限が自動的に与えられるわけではない。別個のスクリプト、ブリッジ契約、アプリケーション制御が追加権限を導入する可能性はあるが、それらは個別に検証しなければならない。

従って記事では、次を区別すべきである。

1. 新規トークンを発行する能力。
2. トークンを焼却する能力。
3. 移転を阻止する能力。
4. 契約が保有するトークンを移動する能力。
5. 管理コードをアップグレードまたは置き換える能力。

これらの能力は相互に置き換え可能なものではない。

NIGHTの供給量と配布

主張で引用された計算は正しい。

• 240億のうち84億は35％。
• 240億のうち36億6000万は約15.25％。

ただし、この計算は配分が不適切であることを立証しない。

Midnightが公表したトークン配布資料は、NIGHTの総供給量を240億とし、Glacier Dropなどを含む配布プロセスを説明している。全供給量を、Glacier Dropを通じて請求者に直接配布されたかのように表現すべきではない。配布カテゴリー、適格性ルール、請求期限、未請求トークンの扱いは、それぞれ別途記載しなければならない。

大規模な財団、トレジャリー、エコシステム向け配分はblockchainプロジェクトでは一般的である。重要な問題は、これらのトークンが拘束力のある制約に服しているかどうかである。読者が知る必要があるのは以下である。

• 各配分を法的に管理する者。
• トークンがベスティングまたはロックの対象かどうか。
• いつ譲渡可能になるか。
• 制約がコードで強制されるのか、それともポリシー上のものにすぎないのか。
• 保有者が条件を一方的に変更できるか。
• トレジャリーの移動が公表されるか。

トークンが提携、開発、エコシステム成長のために確保されているという説明は、コード化されたロックアップと同じではない。財団または関連事業体がその全配分を直ちに移動できるなら、基盤プロトコルが安全であっても、保有者は集中リスクと売却リスクに直面する。

オープンソースを巡る主張

最も深刻な主張は、バリデーターが9月25日にクローズドソースのコードベースへ切り替え、本番ソフトウェアがいかなる公開リポジトリとも一致しないというものである。

これは検証可能な主張であるが、提示された証拠はそれを立証していない。

信頼できる技術的比較には、以下が必要となる。

• 正確な日時とタイムゾーン。
• チェーンのバージョン。
• バリデーターのバイナリまたはコンテナイメージ。
• 実行中ソフトウェアの暗号学的ハッシュ。
• 一致するはずのリポジトリコミット。
• 本番バイナリを取得した方法。
• 関係する運営者による署名または証明。
• 差異があればそれを示す再現可能な比較。

公開リポジトリは、本番ソフトウェアの再現可能性と自動的に同じものではない。プロジェクトはソースコードを公開しつつ、リリースを遅らせたり、ビルド手順を公開しなかったり、一部の構成要素を非公開にしたりする可能性がある。逆に、オープンソースのネットワークをうたうプロジェクトは、非公開のバリデーターソフトウェア、プロプライエタリなモジュール、ソース公開の遅延を説明すべきである。

Midnightの公開文書がネットワークのオープンソース実装を約束しているなら、重要な変更は開示すべきである。その影響は実務的である。独立運営者は同じコードを実行していることを検証できず、研究者は報告された挙動を再現できず、ユーザーはネットワークが自らに示されたソフトウェアによって統治されているかを評価できない。

ハッシュ、リポジトリ履歴、ビルド情報が独立して比較されるまで、秘密のクローズドソースへの切り替えに関する主張は未検証のままである。

アプリケーションと取引に対する制限

Midnightが政治献金に関わるアプリケーションを制限しているという主張についても、元の発言と該当するポリシー文書が必要である。そのような制限が存在するなら、スタックのどの層にあるかが重要となる。

以下には大きな違いがある。

• 取引を拒否するコンセンサスルール。
• アプリケーションの承認を拒む財団のポリシー。
• ウォレット提供者によるコンプライアンス判断。
• アプリケーション独自の利用規約。

これらの管理手段は、検閲と中立性に異なる意味を持つ。Midnightは、いかなる制限もどの層が課しているのか、誰が変更できるのか、すべてのユーザーに適用されるのか承認済みアプリケーションのみに適用されるのか、一時的なものかを明らかにすべきである。

ローンチ後に制限を解除するという約束は、スケジュールではない。プロジェクトはルール、その法的または技術的根拠、解除の条件を公表すべきである。

証拠が裏付けること

入手可能な資料が裏付ける結論は、最も強い主張より限定的である。

Midnightには、制限されたバリデーターセット、管理上の統制、Cardanoと結び付いたトークン配布から始める正当な理由がある可能性がある。こうした設計上の選択は、統制されたローンチを支え得る。同時に、明確に開示すべき中央集権性、カストディ、実行上のリスクも生み出す。

ここで検討した証拠は、Midnightのバリデーターが秘密裏にクローズドソースのコードベースを採用したこと、管理者キーがユーザー資金を盗めること、Bonsに帰属されるすべての発言が引用された形で実際に行われたことを立証していない。これらの主張には一次資料と技術的証拠が必要である。

Midnightは以下を公表すべきである。

• 現在のバリデーターセットと参加承認ルール。
• 承認済みバリデーターと稼働中バリデーターの違い。
• 完全な管理者キーおよびしきい値署名のマップ。
• 緊急権限と失効条件。
• Cardano上のNIGHTポリシーと関連する契約上の管理機能。
• 配分の保有者、ベスティング条件、トレジャリーの移動。
• バリデーターソフトウェアの再現可能な本番ビルド情報。

その情報が利用可能になるまで、NIGHTは中央集権性と実行面で重要なリスクを伴う初期段階のネットワークとして評価すべきである。大規模なトークン配分はネットワーク利用の証拠ではない。公開リポジトリは再現可能な本番ソフトウェアの証明ではない。分散化のロードマップは、すでに実現した分散化ではない。

Midnightは有能なプライバシーネットワークへ発展する可能性がある。今日問われるべきことは、プロジェクトが将来何になると約束しているかではなく、どの当事者がネットワークを変更できるのか、資産を移動できるのか、バリデーターの参加を認められるのか、ユーザーが実際に実行しているコードを決定できるのかである。