grantが使い切れた後、Ethereum 開発者ツールはどうすればいいですか？

この記事を読むのに必要な時間は 30 分

過去の問題は「誰が助成されるべきか」でした。しかし、今日の問題は「既に重要性が証明されているチームが、次回の助成金決定で生死を分かつ方法」に変わりつつあります。

原文タイトル：「grantが使い果たされた後、Ethereum 開発者ツールはどうすればよいのか？」
原文出典：ETHPanda

2月27日、Ethereum Foundation の資金調整チームメンバーであるRaul Romanutti氏が記事を発表し、タイトルは「すべてはうまくいっていた、grantが尽きるまでは」（This Is Fine (Until the Grant Runs Out)）でした。記事では、Project Odin—EFから大規模な助成金を受けた戦略的な少数チームを対象とした構造化された持続可能性サポートプラン—が紹介されました。

情報の要点だけを見ると、Odinは「EFがまた新しい公共財助成計画を発表した」と見なされやすいですが、それは一般的な助成金とは異なります：プロジェクトチームに提供されるのは新たな起動資金でもなく、一度きりの公開申請機会でもなく、既存の助成団体向けの長期的なパートナーシップメカニズムです。EFブログは目標を2年間の枠組みに置いています：これらのチームが信頼できる持続可能な経路を築くのを支援し、単一資金源への長期的な依存を低減する。駐在戦略アドバイザーによるパートナーシップと実行サイクルは約12ヶ月です。

Odinは、助成金の後の道に関心を寄せています。

0xRahul氏のツイートでも、この点が強調されています。彼は、「EFは公共財をさらに支援すべきか」という問題を取り上げたのではなく、開発者ツールチームの持続可能性に焦点を当てました：大規模で複雑かつ重度に使用されるオープンソースツールは、情熱や短期的な助成金だけでは長期的に維持できません。

過去において、中国語コミュニティが公共財について議論する際、Gitcoinの寄付、RetroPGFの配布、EFの助成リスト、あるいは特定のプロジェクトが寄付に適しているかどうかについての議論が主でした。Project Odinが指摘するステージは、公共財プロジェクトが自身の重要性を証明した後、次の助成金に振り回されないようにする方法です。

助成金は依然として重要ですが、問題は変化し始めています

まず、誤解を解消しましょう：Project Odinは、EFが公共財に対する助成を停止する合固でございません。

過去数年間の公開情報から見る限り、EFは引き続きプロトコル研究、クライアント、暗号学、ZK、開発者ツール、教育、公共財の実験に投資を継続しています。EFエコシステムサポートプログラムは、2026年Q1のアロケーション更新でリストアップされたプロジェクトにおいて、EthereumJSメンテナンス、BuidlGuidl、WalletConnectクリア署名ライブラリ、L2BEAT 2026、DISC-NG Geth、Lighthouse、Vero、形式検証などの多くのインフラストラクチャとツールに対応しています。同様の季節ごとの助成金リストは、過去数年間継続しています。

grant は消えていない、ただ全ての問題を解決できないだけです。

早期プロジェクトでは、grant が立ち上げコストを下げるのに役立ちます。研究に基づく作業では、grant が商業化が難しい探索をカバーすることができます。コミュニティ教育や公共インフラの場合、grant は依然として重要な資金源です。しかし、多くのプロジェクトが依存しているツールチームが、長期間主要な資金源しか持たない場合、リスクが集中することになります。

EF ブログによると、多くのチームは技術力に不足しておらず、技術以外の能力、つまり資金調達、外部コミュニケーション、組織設計、法的構造などに欠けています。チームはコンパイラを書いたり、研究を行ったり、ネットワークスタックをメンテナンスしたりしますが、次のような問題に答える余裕がないかもしれません：誰が私たちに最も依存していますか？どのユーザーが長期的なサポート契約にサインすることに同意しますか？企業がどのような仕事を購入する可能性がありますか？収入のどれがプロジェクトの中立性に影響を与えないでしょうか？

Odin が補完しようとしているのは、この能力の部分です。

開発者ツールがここで最も詰まる理由

0xRahul は長い推文の中で、4つの伝統的な開発者ツールのパターンを列挙しています：大企業のオープンソース、より大きな製品にバンドル、商用 SaaS、無償メンテナンス。

これら4つのパターンを Ethereum に当てはめると、明確な制約があることがわかります。

大企業によるオープンソースのツールはしばしば強力ですが、長期的には企業の戦略に依存します。企業が投資する時、エコシステムが恩恵を受けますが、企業の方向性が変わると、メンテナンスの優先順位も変わります。信頼性が中立性を重視する Ethereum のような生態系にとって、重要なツールを単一の企業の長期的な興味に預けることは安定していません。

大規模な製品にバンドルされたツールも同様です。特定の製品ラインやプラットフォームのユーザーにサービスを提供できますが、完全にオープンであることを維持することが難しいです。Ethereum の開発者ツールは、ウォレット間、クライアント間、L2 間、プロトコル間で使用される必要があります。クローズドガーデンはその公共性を弱めます。

商用 SaaS は一部の問題を解決できますが、全ての問題を解決できるわけではありません。多くの暗号通貨チームはまだ早い段階にあり、研究開発予算が限られています。さらに重要なのは、コンパイラ、言語、基本ライブラリ、ネットワークスタック、透明性プラットフォームなどのツールの多くは、その価値がエコシステム全体の安全性や効率性に反映されるため、単一のユーザーに直接料金を請求することは難しいということです。

最後に無償メンテナンスです。小規模なライブラリや個人ツールは興味によって短期間推進されることがありますが、大規模なインフラストラクチャはそうではありません。コンパイラには長期間のテストとセキュリティ対応が必要であり、言語にはロードマップとコミュニティガバナンスが必要です。P2P ネットワークスタックにはプロジェクト間の調整が必要であり、リスク監視プラットフォームには継続的なデータの維持が必要です。これらはどれも一時的な作業ではありません。

開発者ツールはしばしば微妙な立ち位置にあります：それらはあまりにも基盤にあるため、誰も失いたくありませんが、同時にあまりにも一般的なため、収入を自然に得ることが困難です。

Project Odin は「アクセラレーター」ではないことをしている

EF ブログは Odin を構造化サポートプログラムと表現していますが、それはスタートアップアクセラレーターとは異なります。

アクセラレーターは通常、成長企業にサービスを提供し、目標はプロダクト、マーケット、資金調達、およびスケーリングです。Odin は公共財チームがベンチャースケールのストーリーを語ることを求めておらず、その代わりに関心を寄せているのは、これらのチームが多ラウンドの資金調達サイクルで持続的に成果を上げ、徐々により安定した機関になっていくかどうかです。

Odin の基本的な仕組みは、各チームが駐在戦略コンサルタントを持つことです。このコンサルタントはトレーニングを行うためだけでなく、長期的にチームの持続可能性計画と実行に参加します。プロセス全体は大まかに次の三つの段階からなります：

· 第一段階は現実の選択肢を整理すること。チームは現在何に生きているのか？過去にどのような資金調達手法を試みたのか？エコシステム内で誰がそれを受け取るのか？利用可能な資金調達チャネルは何か？それぞれのチャネルのコストは何か？

· 第二段階はパスを検証すること。たとえば、潜在的な資金提供者、パートナー、企業ユーザー、DAO デリゲート、またはプロトコルチームとの対話を展開し、表面上のプランではない方向性を判断します。

· 第三段階は実行です。資金調達や協力のための資料の準備、協力パイプラインの構築、必要に応じてサポート契約、サービス契約、またはその他の繰り返し可能な収入形式の設計が含まれます。

このプロセスは「公共財」の物語ほど魅力的ではありませんが、これはプロジェクトの非常に現実的な部分に対処しています：チームは必ずしもランウェイが切れる直前に次の資金調達を探すわけではありません。

Vyper が選ばれた理由

Vyper は Project Odin の最初のパイロット参加者です。

この選択は驚くべきことではありません。Vyper は EVM 向けの Pythonic スマートコントラクト言語であり、安全性、明快さ、可読性を重視しています。EF ブログによれば、Vyper は歴史的には 270 億ドルを超えるオンチェーン価値を保護してきました。今日でも、Vyper は数千のコントラクトと数十億ドルの TVL を支えています。

言語とコンパイラは典型的な共通インフラストラクチャです。これらに問題が発生すると、影響が個々のアプリケーションにとどまらず、これらに依存するすべてのプロトコルと開発者に及びます。ただし、ビジネスモデルから見ると、この種のプロジェクトは扱いにくいです。コア言語はオープンであるべきですが、安全性と形式的検証能力を維持するには継続的な投資が必要であり、コミュニティによる寄付だけでは長期的なチームの維持が困難です。

Vyper チームが新たに設立した Foundation for Verified Software は、この問題に直面しています。FVS のウェブサイトによると、この機関は形式的検証の研究、オープンツール、エコシステムのサポートに焦点を当てており、現在のプロジェクトには Vyper、Vyper-HOL、Verifereum、HOL4 が含まれています。EF ブログでも、Vyper / FVS が Odin プロトコルの初のパイロット参加者として紹介されています。

これは既存のビジネスモデルの典型例ではありません。より正確には、これはまだ実験中の組織形態です。基金は長期的な研究とオープンソースツールを担当し、チームは形式検証、監査、トレーニング、契約書や企業の実証概念のサポートを中心に、安定した収益体制の構築可能性を探っています。

中国語コミュニティの文脈では、Vyper は「EF サポートを受けた言語プロジェクト」というだけでなく、DeFi、L2、機関資金が契約のセキュリティにますます高い要求をする中、このような形式的検証能力は、研究トピックから段階的に調達可能な専門サービスへと進化する可能性があります。

libp2p と L2BEAT：対照的な事例

EF ブログでは、libp2p が触れられています。これは多くの Web3 システムで使用される P2P ネットワークスタックであり、イーサリアムクライアントがノードの検出、メッセージ伝達、ブロックおよびバリデータの投票伝播に使用しています。EF ブログでは、これを最近の財務圧力事例の一つとして取り上げ、広く依存されるオープンソースインフラストラクチャがリソース不足に陥る可能性があることを示しています。

この事例は、基礎となる依存関係の資金課題を示しています。基礎となるほど多くの使用者がいるため、直接的な支払い関係はますます不明瞭になります。各プロジェクトは libp2p を安定させたいと考えていますが、どのプロジェクトが主要なメンテナンスコストを負担すべきかは非常に難しい問題です。

L2BEAT は別の視点を提供しています。

L2BEAT は、中国語コミュニティで非常によく知られている透明性ツールであり、L2、ブリッジ、DA、ZK などのリスクとデータを長期間追跡しています。これは Odin のパイロットではありませんが、資金提供源を公開し、資産ポートフォリオの事例として適しています。

L2BEAT の寄付ページによると、その資金提供源には、Partnership Fund、Ethereum Foundation grants、Optimism RPGF、Gitcoin、L2 ガバナンスフレームワークへの参加に対する報酬や補償、特別助成金、会議のスポンサーシップ、報告書やダッシュボードの探索、直接的なコミュニティ寄付などが含まれています。

このリストは非常に興味深いものです。それは、公共財チームが必ずしもグラントに完全に依存するか、SaaSに変わるかのいずれかではないことを示しています。中立的なデータと専門的判断を長期間提供するチームは、複数のエコシステムロールからサポートを受けることができます。ただし、その前提条件として、資金源を明確に説明し、外部が引き続きそのインセンティブ構造を検討できるようにする必要があります。

一つの答えに賭けるのではなく、資金メカニズムを組み合わせる

過去2年間、中国語コミュニティは、Gitcoin、Optimism Retro Funding、Protocol Guild、Dripsなどの公共財資金提供メカニズムにかなり精通してきました。これらはしばしば「資金源の多様化」と「持続可能な収入ストリーム」の文脈で議論されています。

しかし、これらのメカニズムが解決する問題は異なります: Gitcoin Grantsは、コミュニティのシグナルを集約し、早期の公共財が露出とスタートアップ資金を得るのに適しています。Optimism Retro Fundingは、すでに影響を与えた作業に報酬を与え、過去の貢献を補償するのに適しています。Protocol Guildは、Ethereum L1コアR&D貢献者を対象に、より持続的なオンチェーン資金提供メカニズムを構築しています。Dripsは依存関係の資金を重視し、資金が上流オープンソースプロジェクトに流れることを望んでいます。

大規模な開発者ツールチームにとって重要なのは、これらのメカニズムから唯一の答えを見つけ出すことではなく、各資金が適用される境界を理解することです。Quick Fundingはプロジェクトが何度もロビー活動を行う必要があり、Retro Fundingの結果には不確実性が存在し、DAOグラントはガバナンスサイクルとトークンの変動に影響を受け、直接寄付は通常、安定したチームコストをカバーするのが難しいです。

Project Odinの焦点は、新しい資金メカニズムを発明することではなく、チームが既存のメカニズムと潜在的な収入を組み合わせるのを手助けすることです: グラントは研究をサポートし、Retro Fundingは影響を報酬化し、DAOまたはプロトコルは特定のサポートを提供し、企業ユーザーはサービスを購入するか契約をサポートし、パートナーはPOCを共同開発することができます。

これらはすべて一般的な運営上の問題のように聞こえますが、多くの公共財チームにとって、一般的な運営能力自体が不足しています。Odinが本当に補完しているのは、「プロジェクトが有用である」ということを、「それに依存する誰か、継続的にサポートする誰か、どの収入源がその公共属性を損なわないか」という能力に変換することです。

つまり、グラント以外には口 Slogan ではなく、より具体的な資金組み合わせ、協力関係、そして組織能力のセットです。

中文コミュニティが理解すべきこと

過去、中国語コミュニティは公共財を理解する際、通常は2つのアプローチがありました。

1つは寄付です。たとえば、Gitcoinの各ラウンド開始時には、プロジェクトの推薦、寄付の手引き、対話ガイドなどがあります。ここでは、公共財はコミュニティ参加のようなものです。

もう1つのアプローチはニュースです。たとえば、EFが四半期の助成金リストを公開したり、OptimismがRetro Fundingを開始したり、あるプロジェクトが助成金を受けたりします。ここでは、公共財はエコシステムの資金流れのようなものです。

Project Odinは第3のアプローチを提供しています：公共財チームの長期運営。

中国語コミュニティにとって、この視点は開発者やプロトコル側により密接に関連しています。プロトコルが長期間にわたり特定のオープンソースライブラリ、リスクデータプラットフォーム、コンパイラ、検証ツール、またはセキュリティインフラストラクチャに依存している場合、そのプロトコルは助成金を必要とするときだけ援助を求めるべきではありません。より合理的な手法は、これらの依存関係を自身のエコシステム予算に記載することです：どのツールが当社にとって重要な依存関係ですか？長期的なサポートを提供すべきか？サポート契約を結ぶ必要がありますか？依存関係の資金提供に参加するべきか？ガバナンス予算に公共財支出を残すべきか？

これを慈善問題と見なすのは正確ではありません；これは、サプライチェーンの問題に近いものです。公共財が重要であるのは、「寄付に値するから」ではなく、多くのチームがこれに日常的な開発、セキュリティ、データ、およびガバナンス判断で依存しているためです。このような依存が実在するのであれば、それを支援することは善意の表現だけでなく、エコシステムのリスク管理でもあります。

プロトコルが流動性、インセンティブ、成長、およびブランドに資金を提供することを好む一方で、自身が依存する基本ツールに対してお金を支払うことを好まないのであれば、それによって節約されるのは費用ではなく、コストをメンテナーとエコシステム全体に転嫁していることになります。Project Odinが注目される理由も、この問題を「誰が支援したいか」から1歩前に進めたことにあります：本当にこれらのチームに依存しているのは誰か、早期にその持続可能性設計に参加すべき人は誰かということです。

Project Odinはすべての公共財の資金調達問題を解決しないでしょう。現時点では、戦略的に助成される少数のチームに対する構造化されたサポート計画に焦点を当てています。ただし、Project Odinは長らく後回しにされていた問題を明確にしました：公共財プロジェクトは、自らの価値を助成金申請時だけでなく、日常の運営で証明しなければなりません。誰が本当に自分たちに依存しているのか、誰が自分たちを持続的にサポートすることを望んでいるのか、そして何が自身の公共属性を損なわない収入かを見つけなければなりません。

これはおそらく、イーサリアムの公共財議論が次の段階に入る合図です。過去の問題は「誰が助成されるべきか」でした；現在の問題は「すでに重要性が証明されたチームが、次の助成金決定で生き残る方法について」です。