Cardanoの62M ADA維持提案がインフラを財務テストに変える

Michael Kargが語るCardanoメンテナンスが単なるバックオフィス業務でない理由

CardanoガバナンスのIO & Ensurable Systems Cardano Maintenance Initiativeに関する議論は、2026年5月12日に開催された新しいCardano Governance Hourセッションで重要な技術的コンテキストを得ました。この議論はCardano FoundationのNicolas Ceaniによって司会され、Input Output EngineeringのCardano Performance & Tracing LeadであるMichael Kargが提案の内容、62百万ADA以上を求める理由、そしてなぜメンテナンスが単なるルーチンの裏方作業として扱われるべきでないかについて説明しました。

Kargはマーケティング担当者として話していたわけではありません。彼はCardanoの最も目立たないが最も重要なインフラ層で働くチームの技術リーダーとして話していました。彼のチームはCardanoノードの観測性に取り組んでおり、ログ記録、メトリクス、観測可能なイベント、システムレベルのベンチマークを含む内容が含まれています。実際には、プロトコルの変更、ノードの変更、またはPlutus実行予算調整がステークプールオペレーターやその他のネットワーク参加者に使用される実際のリソースにどのように影響するかを測定するのを助けることを意味します。

これは、この提案がIOが大規模な財務引き出しを受け取るべきかどうかだけの問題ではないため重要です。Cardanoのコアインフラを誰が維持するか、ネットワークの安全性がどのように測定されるか、リリースがどのように準備されるか、技術的負債がどのように管理されるか、そしてCardanoが強力なノード多様性へ向けてどのように前進できるかについての問題です。

提案は62,134,630 ADAを要求しており、2026年第3四半期から2027年第1四半期の終わりまでの9か月間を対象としています。議論中、Kargはこのイニシアチブが12か月間の要求ではなく、9か月のメンテナンスサイクルであることを明確にしました。

彼の中心的なポイントは、Cardano Maintenance提案が目立つ新機能を導入する提案とは異なるということでした。彼はこれをエコシステムの「エンジンルーム」での作業として述べました。それは、すべてが正しく機能しているときにはユーザーが通常気付かない部分を指しています。これがまさにこの問題が政治的に敏感である理由です。Cardanoガバナンスは新しいウォレット、新しいDeFiアプリ、または新しいユーザー向け機能に投票しているわけではありません。それはシステムを安定した状態に維持し、その上に他のすべてが構築されるべき作業を投票しているのです。

議論の時点では、この提案はまだ承認にほど遠い状態でしたが、Kargは多くのDRepsがガバナンス行動の最終日まで投票を待つ傾向があると指摘しました。その投票パターンは早期の意図を読みづらくしますが、それはまた大規模な技術的提案が最終決定の窓が閉じる前に明確に説明する圧力を増す原因にもなっています。

Cardano Blueprintとノード多様性がメンテナンス議論を拡大

議論の最も重要な部分は、メンテナンスが減少すると運用リスクが増大するという警告だけではありませんでした。Kargは、Cardano Maintenance Initiativeがバグ修正、アーキテクチャ、DevOpsインフラ、テストネット操作、ベンチマークシステム、災害復旧プロトコル、監視ツール、リリースサポート、セキュリティプロセス、主要なCardanoツールを含む、はるかに広い技術パッケージをカバーしていることを示しました。

その範囲には、ブートストラップリレー操作、PreviewおよびPreProdのようなテスト環境の維持、Haskellコンパイラサポート、メインネット監視、グローバルメンポール監視、オープンソースサポート、Plutusインタープリター、DB Sync、Cardano CLI、Cardano API、ガードレール、憲法委員会のアイデンティティスクリプトなどのツールに関する作業が含まれています。

最も重要なトピックのひとつはCardano Blueprintでした。KargはこれをCardanoを構成する技術的な青写真として説明しました。これには、ノードが互いに通信する際に使用するプロトコル、バイトレベルの詳細、暗号化機能、コードそのものとは別に存在する仕様が含まれます。これは単なるドキュメント化のためのものではありません。Blueprintが重要なのは、他のチームにRustやTypeScriptなどの言語で独自のノード実装を構築するためのより明確な枠組みを提供するからです。

これにより、メンテナンス提案は単なる日常的な維持管理以上のものになります。Cardanoはガバナンス、ステークプール運用、意思決定を分散化することについてよく話しますが、長期的な実装の多様性もその一部です。Haskellノードは現在の基準実装ですが、健全なエコシステムは永遠に1つのコードパス、1つのエンジニアリングセンターまたは1つの組織に依存するべきではありません。

Ensurable Systemsの追加もその文脈で説明されました。このサイクルではIOがリードしてデリバリーを行いますが、Ensurable SystemsはCardanoのドメイン知識と経験を持つデリバリーパートナーとして記載されています。その創設者が以前IOで働いていたためです。Kargはこれを管理の分散化に結び付けました。つまり、Cardanoのメンテナンスは長期的に1つの組織だけの責任であるべきではないということです。

最も技術的に興味深い詳細のひとつは、Haskellコンパイラのサポートでした。Kargは、Cardanoノードがおそらく最も複雑なHaskellアプリケーションのひとつであると述べました。そのため、IOはHaskellコンパイラチームと密接に協力しており、Cardanoのベンチマークが標準的なコンパイラベンチマークスイートがカバーしきれないコード生成問題を明らかにすることができると説明しました。理由は、Cardanoのコードベースが非常に大規模で複雑だからです。

この詳細は、メンテナンスが財務表の管理項目ではないことを示しています。Cardanoにおけるメンテナンスには、性能の規律、システム限界の理解、基本的な開発ツールの協力、およびLeios、Hydra、マルチ資産財政機能など、将来のアップグレードに備えたネットワーク準備が含まれます。

DRepsはコストだけでなく証拠で投票している

この提案にとって最大の課題は、メンテナンスが重要かどうかだけではありません。課題は信頼です。62百万ADAを超える要求は大きく、現在のCardano財務は多くの並行する引き出し提案に直面しています。そのような環境では、DRepsが予算、成果物、そして測定可能な結果との明確なつながりを要求するのは当然です。

Kargは透明性の一環として公開ベンチマークレポートとCardano Updatesに言及しました。ベンチマークレポートは以前と新しいノードリリースを比較し、リソース使用率、ブロック生成、ブロック拡散、ブロック採用を追跡し、リリースノートと関連付けられることがよくあります。SPOや技術的なDRepsにとって、それは装飾ではありません。それはメンテナンス作業が測定可能なネットワーク性能を通じて可視化される方法のひとつです。

それは提案にとって強力な論拠ですが、すべての懸念を取り除くものではありません。司会者は、9つのワークストリームに渡る作業者の数や、DRepsがチームの割り当て、FTE（フルタイム従業員）容量、そして優先順位をどのように理解すべきかについて質問を提出しました。Kargは成果物が複数のチームとエンジニアに及んでいること、IOが歴史的データを使用して努力と時間を見積もること、そして提案が成果指向であることを回答しました。つまり、IOは要求された金額内で結果に責任を持つということです。

その答えは技術的には合理的ですが、公共ガバナンスのコミュニケーションとしては完璧ではありません。簡単な予算内訳、より明確なFTEマップ、カテゴリごとのより正確なコスト構造を望むDRepsは質問を続ける可能性があります。これが提案を弱めるものではありませんが、コミュニケーションは非常に正確である必要があります。この規模の要求の場合、メンテナンスが重要だと言うだけでは十分ではありません。コミュニティは確認可能なものが何であるか、進捗がどこで見えるか、そして財務が運用出力にどのように変わるかを見る必要があります。

また優先順位の問題もあります。Cardanoがメンテナンス、Leios、その他の技術提案を同時に資金提供する場合、同じ組織やエンジニアリング人材が複数のワークストリームに関与する可能性があります。KargはIOが週次および月次評価、相互依存性、プロジェクトごとの個別予算追跡を通じて優先順位を管理していると説明しました。それは内部プロセスが存在することを示していますが、それはまたCardanoガバナンスが現在技術提案を孤立して判断できるフェーズに入っていることを確認するものです。

これが投票が単純でない理由です。大規模な財務要求を拒否することは財務的規律のように見える可能性があり、承認することは責任あるインフラ資金提供のように見える可能性があります。両者には論拠がありますが、議論の浅いバージョンでは肝心な点が見過ごされます。本当の質問はコミュニティがその金額の大きさを好むかどうかではありません。本当の質問は費用が高いように見えるものと、それが欠けて初めて重大となるインフラを区別できるかどうかです。

この提案はしたがって誇張ではなく証拠によって擁護されるべきです。IOとEnsurable SystemsがDRepの信頼を得たいのであれば、彼らの最強の論拠は問題の恐怖ではなく、要求された金額、公開成果物、ベンチマーク規律、Blueprintのドキュメント化、長期的な実装分散化との明確なリンクとなるでしょう。Cardanoガバナンスはメンテナンスに支払うかどうかを決定しているだけではありません。それはその基盤が、アプリケーション、ステークプール、未来のアップグレードの下でどれほど強力になるかを決定する技術的規律に責任を持って資金提供できるかどうかを決定しているのです。