
Multicoin Capital:成功したDePINプロジェクトが考慮すべき要因とは?
TechFlow厳選深潮セレクト

Multicoin Capital:成功したDePINプロジェクトが考慮すべき要因とは?
本稿では、新しいDePINネットワークを探求する際に創業者と議論される最も一般的な問題や検討事項について考察する。
執筆: SHAYON SENGUPTA 、TUSHAR JAIN
翻訳:TechFlow
2022年4月、我々は「物理的作業証明(PoPW)ネットワーク」に関する論文を発表した(現在ではより一般的に「分散型物理インフラネットワーク(DePIN)」と呼ばれている)。その記事の中で、次のように述べた。
PoPWネットワークは、人々が検証可能な作業を行い、現実世界のインフラを構築することをインセンティブ付ける。従来の資本形成手段と比較して、これらの許可不要かつ信頼中立なプロトコルは:
-
インフラ建設をはるかに迅速に行える――多くの場合、10〜100倍も速い;
-
ネイティブな市場需要により密接に対応できる;
-
コスト効率も優れている可能性がある。
我々はこの主張に対して最初に大規模に投資した機関であり、それ以来、エネルギー、物流、マッピング、通信など多岐にわたる分野でDePINネットワークが爆発的に登場しているのを目の当たりにしてきた。最近ではさらに特定用途のリソースネットワーク、特に計算、ストレージ、帯域幅、消費者データ集約といったデジタル商品に特化したカテゴリも出現している。各ネットワークの背後には、暗号資産ネイティブな資本形成によって初めて可能になる、構造的なコストまたはパフォーマンスのアービトラージが存在する。
DePINネットワークにおける設計パターンやベストプラクティスには大きな共通点がある。創設者やコミュニティはネットワーク設計を考える際に、いくつかの重要な問いを検討しなければならない。ハードウェアはエンドユーザー向けにするべきか、それとも専門設置者によるネットワークを誘導すべきか? 初めての有料顧客を獲得するために必要なノード数はどれくらいか? 10個か? 1,000個か? ネットワークは完全に分散化すべきか、それとも信頼できる仲介者を通じて管理すべきか?
これらの決定はネットワーク設計の初期段階で下さなければならず、正しく行う必要がある。ハブとなる問題はしばしばDePINネットワークの成功か失敗かを左右する。ハードウェアレベル、トークンレベル、分配レベル、あるいは需要活性化層におけるわずかな変更が、ネットワークの成否に大きな影響を与えることがある。
Multicoinでは、今なおDePINに対して楽観的であり、今後数年のうちに新たなカテゴリーのネットワークが多数登場すると予想している。本稿では、DePINの創設者やコミュニティが最も頻繁に考慮するトレードオフについて考察し、次世代のDePIN創設者やコミュニティがネットワークをより成功裏に設計する手助けとなればと思う。我々はDePIN構築における3つの必須要素を提示する:ハードウェア、閾値規模、需要生成。それぞれの側面について主要な問題点を検討し、それがいかにキーデザイン決定に影響するか、およびトークン設計に及ぼす広範な含意について概説する。
ハードウェアに関する検討
ほとんどのDePINネットワークは物理インフラ――つまり実際のハードウェア――を調整する。しかし、常にそうとは限らない。計算、ストレージ、帯域幅などの仮想リソースを管理するネットワークもある(これらは「分散型仮想インフラネットワーク(DeVIN)」と呼ばれることもある)。ただし、本セクションの議論上、ネットワークが実際のハードウェアを持つものと仮定し、以下のような重要なネットワーク設計上の問題に答える必要がある。
誰がハードウェアを製造するのか?
自社でハードウェアを製造・配布するDePINネットワークは、ネットワーク供給サイドに対してより高いコントロールを維持できる。また、貢献者との直接的な関係を築くことができ(時としてより強固なコミュニティにつながる)。しかし、時間の経過とともに、製造・流通プロセスにおいてボトルネックや単一障害点となるリスクがあり、これがネットワークの拡張性を制限する可能性がある。
自社でハードウェアを製造・配布する代替案として、ハードウェア仕様をオープンソース化し、コミュニティにそれを基にハードウェアを構築してもらう方法がある。これにより、サプライチェーンリスクを分散しつつ、供給サイドの拡張が可能になる。当然ながら、この手法の課題は、第三者メーカーに対して新しい市場向けのハードウェア製造をインセンティブ付けることが困難かつ高コストである点だ。また、ハードウェアの品質とサポートについても検討が必要である。仮に強力なハードウェアメーカーのエコシステムを構築できたとしても、デバイスおよびサポートの品質を維持する必要がある。
Heliumは興味深いケーススタディである。彼らはまず自社でホットスポットを構築してネットワーク立ち上げを支援し、その後すぐにハードウェア仕様をオープンソース化し、第三者がそれらを製造する強力なエコシステムをインセンティブ付けた。しかし、多数の第三者メーカーを抱えつつも、Heliumはネットワークの成長期において深刻なサプライチェーンのボトルネックに見舞われ、一部のメーカーは不十分なサポートを提供した。
一方、Hivemapper(スマートフォンを使用して屋内空間の分散型マッピングを行う)は、自社でハードウェアカメラを製造・配布する方針を選んだ。これによりハードウェア生産を完全にコントロールでき、ファームウェアの迅速なイテレーションや受動的ビデオアップロードの早期実現が可能となり、地図カバレッジとデータの商業的価値を加速させることができた。代償として、一社によるハードウェア生産のコントロールはサプライチェーンの集中化を招き、より脆弱になる可能性がある。
まとめ――我々はハードウェア仕様がオープンソース化され、無許可で展開されるとき、DePINネットワークははるかに迅速に拡張することを観察している。ネットワークが十分に成熟した時点で、ハードウェア開発を開放して分散化・拡張するのは理にかなっている。しかし、初期段階では品質とサポートを確保するためにハードウェアをコントロールすることは賢明である。

あなたのハードウェアは能動的か受動的か?
一部のDePINネットワークは一度設定すれば完了だが、他のネットワークは継続的なユーザー参加を必要とする。
例えば、Heliumの場合、ホットスポットを開封して設定するまで約10分かかる。その後、デバイスは静かに置かれたまま、ユーザーがほとんど追加作業を行わなくてもネットワークに受動的なカバレッジを提供する。一方、Geobyte(スマートフォンを使って屋内空間の分散型マッピングを行う)のようなネットワークでは、価値を生み出すためにユーザーが積極的に行動する必要がある(スマホのセンサーを使って屋内の映像を撮影する)。供給サイドの貢献者にとって、能動的ネットワークへの時間的投資は、他の収益活動や日常生活に費やす時間を明示的に犠牲にするものである。そのため、能動的ネットワークの貢献者は、(多くの場合)時間的・機会費用を正当化するために、トークンやネットワーク設計を通じてより多くを得なければならない。これはまた、能動的ネットワークが(設計上)受動的ネットワークよりも閾値規模(後述)に達する速度が遅くなることも意味している。
一方で、能動的DePINネットワークは一定程度の継続的参加を必要とするため、通常、ネットワークに対してより関与し、知識豊富な貢献者を抱えることになる。逆に言えば、能動的ネットワークは貢献したい、あるいは貢献できる人の数に制限されることでもある。
まとめ――貢献者が初期に一時的なコスト(時間または金銭)を支払うだけで済み、継続的なコストが不要であれば、DePINネットワークの拡張は容易になる。受動的ネットワークは設定が簡単なため、拡張も容易である。
能動的ネットワークであること自体が死刑宣告ではない。創造的な思考とインセンティブ設計が必要なのだ。例えば、Geobyte、Dronebase、FrodoBots、Verisといった能動的ネットワークは、伝統的なインフラネットワークというよりむしろ「永久ゲーム」に近い。

ハードウェアの設置はどれほど難しいか?
DePINネットワークによって、ハードウェア設置の難易度は大きく異なる。壁のコンセントに差し込むだけの簡単なものから、専門設置者が必要なものまでさまざまである。
簡単な例としては、ゲームプレイヤーがRender Networkという分散型計算ネットワークにGPUを接続する際、bashスクリプトを実行するだけでよい。これは理想的である。なぜなら、データセンターの負荷分散を適切に実行するには、地理的に分散した数万のGPUが必要だからだ。
中程度の難易度の例として、Hivemapperカメラの設置には15〜30分かかる。強力なリアルタイム地図を構築するには、特定地域に数百台の車両が必要となるため、初期の時間投資は簡単で、その後の操作も容易でなければならない。
対照的に、困難な例として、XNETはキャリアグレードのCBRSワイヤレスネットワークを構築している。そのネットワークラジオは、現地ISPの専門家が設置する必要があり、商業用不動産所有者の同意も必要である。しかし、それでもネットワークは拡大している。都市地域のカバーには少数のこうした配置で十分であり、キャリアの負荷分散やデータローミング用途にサービスを提供できるからだ。
まとめ――ネットワークの拡張速度は、ハードウェア設置の難易度に直接影響される。世界各地に何千ものデバイスが必要なネットワークでは、ハードウェア設置を可能な限り簡素化する必要がある。一方、少数のノードで急速に拡張できるネットワークであれば、個人貢献者ではなく専門貢献者に焦点を当てることも選択肢となる。一般に、設置の複雑さが十分に低く、普通の人が簡単に貢献者になれるとき、DePINネットワークは最も速く拡張する。

ハードウェアに関するトークン設計への影響
ネットワーク構築を検討する際、初期の供給サイド貢献者は最も重要なステークホルダーの一つである。ハードウェアに関する意思決定によって、供給サイドの貢献者は一般人、専門家、あるいはその中間の「準専門家」のいずれかに偏ることがある。
我々は、専門的貢献者はネットワーク初期の即時ドル換算収益を重視しやすく、早期にトークンを現金化する傾向があることを観察している。一方、初期の個人貢献者は長期的な成果に注目しやすく、短期的な価格変動を気にせず、できるだけ多くのトークンを蓄積しようとする傾向がある。

専門的貢献者が多数いるネットワークでは、従来の現物トークン報酬に加えて、ロックされたトークンやドル換算収益シェア契約などの代替手段を試みることもできる。
どのような供給サイド貢献者であれ、成熟期にはネットワークの供給サイドが資本投資と運用コストをドル建てで賄えるようになっていなければならない。早期採用者へのインセンティブと、後期の成熟段階での貢献者報酬のバランスを取ることは、厄介だが極めて重要な課題である。
閾値規模に関する検討
「閾値規模」という用語は、ネットワークの供給サイドが需要サイドに対して商業的に実行可能になる時点を指す。DePINネットワークは本質的に破壊的である。なぜなら、トークンを使って早期貢献者がインフラを展開し、閾値規模に到達するよう報酬を与えられるからだ。
一部のネットワークは初日から1つまたは数個のノードで需要にサービスを提供できる(例:ストレージ・計算市場)が、他には一定規模に達しないと需要に応えられないものもある(例:無線ネットワーク、物流・配送ネットワーク)。需要が数量的に拡大するにつれ、その増分需要を満たすために必要な最小ノード集合も拡大していく。
位置は重要か?
一部のDePINネットワークは物理的な分散から大きな利益を得ないが、他のネットワークはそれを不可欠とする。ほとんどの場合、ネットワークが物理リソースを調整する必要があるなら、位置に敏感である。したがって、需要生成のタイミングを決める際、「最小実現可能カバレッジ」についての推論が重要な要因となる。
位置に非常に敏感なネットワークもあれば、位置に依存しないネットワークもある。例えば、エネルギーマーケット(Anodeなど)やマッピングネットワーク(Hivemapperなど)は位置に非常に敏感である。一方、Helium IoTのような無線ネットワークはホットスポットの範囲が広いため、位置に対する感度は低い。Filecoin Saturn、Fleek、Wyndなどの帯域幅市場はさらに位置に鈍感であり、特定の場所のノードではなく、一般的な地理的カバレッジだけでよい。
一方、Render Networkのような計算市場やFilecoinのようなストレージ市場といったDeVINは位置に鈍感である。これらのネットワークでは、エントランスが地理的に制限されないため、供給サイド貢献者を閾値規模まで引きつけるのが容易になる。
まとめ――位置に敏感なネットワークは、目標エリアへの供給サイド貢献をインセンティブ付け、閾値規模に達してサービス可能な市場を解放すべきである。達成後は「土地拡張」戦略を採用し、他の領域で同じ戦略を繰り返すべきである。
ネットワーク密度は重要か?
前述の「最小実現可能カバレッジ」に基づき、一部のDePINネットワークには「ネットワーク密度」という概念がある。これは通常、ハードウェアユニット(またはノード)の数、あるいは特定地域内の特定リソースの総合計単位で定義される。
Helium Mobileはweb3モバイルキャリアであり、そのネットワークカバレッジを「コミュニティあたりのモバイルホットスポット数」として定義している。Helium Mobileにとってネットワーク密度は極めて重要であり、継続的なカバレッジを提供するには大量のモバイルホットスポット密度が必要だからだ。
Teleportは無許可のライドシェアプロトコルであり、密度を「都市のホットスポットから5〜10マイル半径内のアクティブドライバー数」と定義している。Teleportにとって密度は重要である。誰も10分以上待つタクシーは望まないからだ。しかし、Helium Mobileとは異なり、Teleportのドライバーは乗り出して乗客を迎えに行くことができるため、Helium Mobileほどの高い原生密度は必要ない。
Hivemapperは「特定都市内のマッパー数」をネットワーク密度として定義している。都市に十分な数のマッパーがいなければ、更新されたマッピングデータを提供できないからだ。しかし、HivemapperはTeleportほどの密度を必要としない。地図の更新は、タクシーの呼び出しよりも長い遅延を許容できるためである。
閾値規模の文脈で密度を検討するシンプルな方法は、「ある地理的領域で、最初の販売または最初の需要サイド顧客を獲得するために必要な貢献者の閾値は何か?」ということを考えることだ。10人目では? 100人目では?
例えば、XNETは分散型の準許可モバイルキャリアであり、都市地域をカバーするためにわずか100個の大規模で専門設置された無線機で十分かもしれない。一方、Helium Mobileの無線機は小さく、同じ都市地域をカバーするにはより多くの無線機が必要となる――数万の小さな基地局を持つHelium Mobileネットワークは価値が高く、数百の基地局では価値が低い。ハードウェア設計の意思決定により、Helium Mobileの閾値規模はXNETよりも高い。
まとめ――より高い密度を必要とするネットワークは、閾値規模に達するためにより多くの貢献者を必要とする。逆に、密度が低いネットワークは、より複雑なハードウェアや/および専門的貢献者を利用できる。
トークン設計への影響
我々は、位置の感度やネットワーク密度の要件の組み合わせにより、閾値規模が高いネットワークほど、供給サイドの構築に多くのトークン報酬が必要になると観察している。対照的に、相対的に閾値規模が低いネットワークは、トークン報酬をより慎重に設定でき、後期の閾値規模マイルストーンで分配を行う柔軟性を持つ。
一般的に、トークン分配には2つの一般的な戦略がある:時間ベースの戦略と利用ベースの戦略。閾値規模が高いネットワークには時間ベースの戦略が最も効果的であり、閾値規模が比較的低いネットワークには利用ベースの戦略が最も効果的である。Heliumは時間ベースのトークン発行スケジュールを採用しており、Hivemapperはネットワーク利用ベースの発行スケジュールを採用している。
時間ベースの戦略は、一定期間内にネットワークへの貢献度に応じて固定量のトークンを比例的に分配するものである。インフラ構築の上市時期が重要であり、競合に先んじて閾値規模に到達することが求められる場合、このような戦略が適している。ネットワークが「勝者全取り」市場で最初に行動するわけではない場合、時間ベースの戦略を検討すべきである。(注意:この手法は通常、弾力的なサプライチェーンを通じてハードウェアを明確に分配できる能力をネットワークに要求する。)

ネットワーク利用ベースのトークン分配は、ネットワーク成長に応じてトークンを分配できる柔軟なメカニズムである。報酬メカニズムには、特定の場所、特定の時間、またはネットワークに特定タイプのリソースを提供することで、より多くのトークンを付与するものがある。ここで生じるトレードオフは、ネットワークが最も価値ある参加者にトークンを分配する選択権を保持できる一方で、供給サイドに収益の不確実性をもたらし、転換率の低下や離脱率の上昇を招く可能性がある点だ。
例えば、Hivemapperは発行総量の2%未満のトークンでアメリカの10%の地域をマッピングした。そのため、現在は特定エリアで閾値規模に達し、地図を拡張し、戦略的エリアでの密度を改善するために、非常に慎重にボーナスチャレンジを設計できる。
需要生成に関する検討
DePINネットワークが閾値規模に達すると、需要サイドに対して真剣に販売を開始できるようになる。ここに疑問が生じる:誰が販売を行うべきか?
DePINネットワークは、最終的に顧客がネットワークが集約したリソースに簡単にアクセスできるときのみ価値を持つ。消費者や企業は通常、許可不要なネットワークから直接購入するのではなく、伝統的な企業から購入することを好む。これにより、ネットワークリソースを顧客が理解し、購入したい製品・サービスにパッケージングするバリューアディッドディストリビューター(VAD)の機会が生まれる。
ネットワーク創設者自身がネットワークVADを運営する選択肢もある。この企業はネットワーク上で事業を行い、顧客との関係およびそれに伴うすべて(製品開発、販売、顧客獲得・維持、継続的サポート、法的契約など)を担う。ネットワークVADを構築する利点は、顧客への販売価格とネットワークが提供する基本リソースコストの間の全てのスプレッドを獲得できることにある。このアプローチによりネットワークはフルスタックになり、需要サイドからの継続的なフィードバックを得られるため、より密接な製品イテレーションが可能になる。
一方、必ずしもVADになる必要はない。需要サイドの関係をネットワークエコシステムに外部委託できる。このアプローチにより、コアプロトコル開発に集中できるが、顧客との接触点が減ることで、製品フィードバックやイテレーションが妨げられる可能性がある。
ネットワークVADになるべきか、それとも外部委託すべきか?
さまざまなDePINチームがこの問題を多くの視点から検討している。
例えば、Hivemapper Inc.は現在、Hivemapper Networkの主要なVADである。彼らはネットワークのマッピングデータの上に事業を築き、商用APIを通じて企業向けロジスティクスおよびマッピングデータを提供している。
Heliumの場合、Helium Mobile NetworkはHelium Systems Inc.から派生した単一のVADであるHelium Mobileによってサービスされている。一方、HeliumのIoTネットワークはSenetなどの一連のVADによって商業化されており、Senetは顧客がホットスポットを展開する支援、センサーとカバレッジの購入、データパケット送信の検証などを業務としている。
HivemapperやHeliumとは異なり、Render Networkは公共計算顧客にネットワークリソースの商業化を外部委託している。彼らはこれらのリソースを、レンダリングや機械学習ジョブ向けの機関やアーティストに再販売する。Render Network自体は計算整合性証明、プライバシー保証、特定プログラムパッケージやライブラリのワークロード処理のオーケストレーション層などは提供しない。これらはすべて第三者によって提供される。
まとめ――サービスや信頼保証の追加は需要を刺激できる。ネットワーク自身がこれらのサービスを提供することも可能だが、一定の臨界規模に達する前に過早に投資すると、時間、労力、資金の浪費につながる。大規模になった時点で、これらのサービスは第三者が処理するのが最適であり、サービス対象の顧客に合わせて製品をカスタマイズできる。
我々はまた、ネットワークが拡大し、ネットワークリソースの商業化を始めるにつれて、通常以下の段階を経ることを観察している。
-
第1段階:最初の閾値規模マイルストーン時または直後に、コアチームが需要サイド関係のすべてを管理する。これにより、早期顧客に可能な限り高品質な製品を提供できる。
-
第2段階:最初の閾値規模マイルストーンを超えた後、ネットワークは第三者エコシステムの構築を始め、ネットワークが集約したリソースを再販売できるようにする。リソース統合を行う第三者がネットワークに入り、需要と供給の関係を仲介できる。
-
第3段階:ある程度安定した状態では、多数の参加者がリソースをパッケージングし、広範なネットワーク参加者に販売する。この段階でネットワークは、他のサービス企業が直接顧客にサービスを提供するためのプラットフォームとなり、純粋なリソース層として機能する。
トークン設計への影響
ネットワークが需要生成を拡大するために特定の側面に依存している場合、これらのネットワーク参加者にプロトコル報酬を指定すると役立つかもしれない。第三者の需要生成活動向けのトークンは通常マイルストーンベースであり、ネットワークと第三者が共通の目標を達成したときに報酬が分配される。パートナーとのトークン発行メカニズムは常に合理的に設計し、彼らがネットワークにもたらす価値と最終的に得るトークンが一致するようにすべきである。

今後の展望
本稿では、我々が新たなDePINネットワークを探求する中で創設者と議論する最も一般的な問題や検討事項について考察した。
我々は今後数年間で、新たなカテゴリーを定義するDePINネットワークが多数登場すると予想しており、トークン分配、ハードウェア、閾値規模、需要生成といったコア属性が極めて重要であり、供給サイドリソースを効果的に構築し、需要サイド顧客にサービスを提供するためには包括的に検討されるべきだと考えている。これらのネットワークは本質的に市場であり、各トレードオフは連鎖反応を引き起こし、固有のネットワーク効果を強化するか、新規参入者に競争の余地を与えるかのいずれかとなる。
最終的に、我々はDePINを、暗号ネイティブな資本形成を通じて、価値あるインフラネットワークの構築コストを削減する手段と見なしている。我々は、通信、エネルギー、データ集約、炭素排出削減、物理的ストレージ、物流・配送といった大規模市場のサブセットにおいて、明確なトレードオフを行い、サービスを提供するネットワークに広大な設計空間が存在すると信じている。
TechFlow公式コミュニティへようこそ
Telegram購読グループ:https://t.me/TechFlowDaily
Twitter公式アカウント:https://x.com/TechFlowPost
Twitter英語アカウント:https://x.com/BlockFlow_News














