重要なポイント
モジュール型ブロックチェーンと統合型ブロックチェーンの議論で最も頻繁に議論されるトピックの 1 つは流動性です。モジュラーブロックチェーンは、多くの場合、さまざまなロールアップにわたって流動性を分散させますが、統合チェーンの支持者は、アプリケーションが単一のシャード上で動作するため、流動性は本質的に統合されていると主張しています。
しかし、統一された流動性があると主張する統合チェーンであっても、実際には流動性の断片化に直面しています。アプリケーションが同じシャード上で実行されている場合でも、流動性が特定のアプリ内でサイロ化されている場合、他のアプリからはアクセスできなくなります。その意味では、統合チェーンは統合流動性を持っているという主張は、いくぶん誇張されていると言えるでしょう。
この問題に対処するために、Injective Research は「流動性アクセシビリティ」という概念を導入し、それを最適化する方法を検討しました。流動性へのアクセスを最大化するには多大な労力と時間が必要になりますが、それを達成することでオンチェーン金融の新たなパラダイムが生まれる可能性があります。
業界でモジュール型ブロックチェーンと統合型ブロックチェーンのどちらが優れているかという議論があるときは、必ず話題に上がるのが「アプリケーション/ネットワークが流動性を共有できるかどうか」というトピックです。
個別のネットワークを持つモジュラー ブロックチェーンの場合、各ロールアップにわたって流動性が断片化されるため、コストが高くなります (ネットワークごとに新しい流動性を構築する必要があります)。一方、統合ブロックチェーンでは、すべての流動性が単一のシャードに統合されるため、コストが比較的低くなります。 Suiの流動性レイヤーであるDeepbookについて書いたときに、この利点を強調しました。
しかし、統合されたチェーンであっても、流動性は完全に統合されているわけではありません。例えば、前述の Deepbook の場合、集中流動性はオーダーブックベースのアプリケーションにのみ提供されます。これは、流動性が貸付やスワップなどの他の DeFi アプリケーションと共有されないことを意味します。これらの制限は、Solana によって導入された Serum でも明らかでした。
ある意味、これらのプラットフォームは統合ブロックチェーンの利点の半分しか活用していません。統合ブロックチェーンで単一のシャードを使用することによるメリットを真に最大化するには、そのブロックチェーン上のすべてのアプリケーションが統合された流動性を活用して流動性効率を達成する必要があります。
ネットワークに提供される流動性を、注文書ベースの取引所だけでなく、貸付、保険、ステーキング、トークンブリッジ、スワップなど、さまざまなアプリケーションで必要に応じて自由に利用できるネットワークレベルのソリューションがあったらどうでしょうか?興味深いことに、そのようなソリューションを準備しているブロックチェーンが存在します。Injective です。
Injective では、このソリューションを説明するために「流動性の可用性」という概念を導入しています。この記事では、まず流動性の可用性とは何かを検討し、従来の金融事例と比較して理解した上で、Injective が提案するさまざまな流動性の可用性の最適化メカニズムを見ていきます。最後に、これらの最適化の取り組みが Injective とより広範なブロックチェーン エコシステムの両方にとって何を意味するのかを検討します。
1. 流動性の可用性とは何ですか?
Injective Research が発表した研究論文によると、流動性可用性とは、特定の制約の下で、いつでもあらゆる種類の取引を正常に実行するために必要な流動性を満たす能力を指します。つまり、これらの流動性要件を満たすことができない場合は「流動性可用性が低い」と言え、逆に、これらの要件を十分に満たすことができる場合は「流動性可用性が高い」と言えます。
したがって、流動性の可用性自体は流動性の問題に対する答えではなく、むしろ各ネットワークまたはアプリケーションがどの程度流動性を備えているかを測定するのに役立つ指標です。たとえば、この概念をアプリケーション レベルで適用する場合、流動性の可用性は、アプリケーション内で分離された流動性のみを指します。これは、各アプリケーションが通常、取引を実行するために必要な流動性を独自の流動性プールからのみ調達するためです。
問題は、ほとんどのアプリケーションに十分な流動性がないことです。一部の主要な DeFi プロトコルは独自の流動性が豊富にあり、流動性の可用性が確保されていますが、ほとんどのアプリケーションはそれ自体の流動性が不十分なだけでなく、ネットワーク レベルで見ると、その限られた流動性さえも個々のアプリケーション内で分離されています。流動性が分散されずに一箇所に留まるという問題は、長い間、業界における慢性的な課題と考えられてきました。
そして、この「流動性分離問題」は、典型的には 2 つの形で現れます。次に、各フォームが具体的にどのように動作し、どのような問題を引き起こすのかを見ていきます。
1.1 流動性分離の2つのタイプ: ネットワークレベルとアプリケーションレベル
流動性分離の 2 つのタイプは、ネットワーク レベルの分離とアプリケーション内制約に分けられます。前者は、流動性が特定のアプリケーションにのみ存在し、同じネットワーク内の他のアプリケーションでは利用できない分離を指します。後者は、個々のアプリケーション内でも流動性が特定のプールに結び付けられ、アプリケーション自体内で流動性が他の目的に使用されることを防ぐ状態を指します。
それぞれの分離タイプについてさらに詳しく説明しましょう。現在、ブロックチェーン上に構築されているほとんどの金融アプリケーションは、流動性プロバイダー (LP) から資産を受け取り、特定のトランザクションのみを処理する指定のプールに預け入れます。たとえば、分散型取引所 (DEX) は資産スワップのプールに流動性を引き付けますが、貸付プロトコルはローン専用の貸付プールに流動性を引き付けます。ただし、これら 2 つは、互いのプールに預けられた流動性を直接使用することはできません。この場合、流動性はネットワークレベルで分離されていると言えます。
もう 1 つの問題は、単一のアプリケーション内で流動性を自由に利用できないことです。 DEX 内の特定のプールに多くの流動性があるからといって、この流動性を他のプールに恣意的に移動できないため、このアプリケーションに豊富な流動性があることを意味するわけではありません。この場合、流動性はアプリケーション内で分離されていると言えます。
したがって、ブロックチェーンに預けられた流動性を調べるときに最も一般的に観察される指標である Total Value Locked (TVL) の概念は、かなり曖昧であると考えられます。これは、TVL ではネットワーク レベルで利用可能な流動性の量を説明していないためです (たとえば、チェーン A の 1 つの DEX がチェーン A の TVL の 90% を保持し、この流動性が他の DeFi プロトコルで使用できない場合、本当にチェーン A の流動性を表していると言えるのでしょうか)。
つまり、これら 2 つの問題を解決するには、単一のアプリケーションの流動性の可用性 (これも重要だと考えられる) だけでなく、ネットワーク レベルでの流動性の可用性も高める必要があります。では、この流動性の可用性を高めるにはどうすればいいのでしょうか?最も簡単な方法は、既存の業界の類似の例を調べてベンチマークすることだと思います。これは、従来の金融では流動性の利用可能性が最大化されているケースがあるためです。
2. TradFiから学んだ教訓
ブロックチェーンや分散型金融の支持者は、その性質上、従来の金融を軽視する傾向がありますが、従来の金融がこれほど長い間世界を支配してきたのには明確な理由があります。彼らのシステムは想像以上に複雑かつ効率的に動作します。従来の金融には確かに欠点があり、多くの Web3 開発者が代替手段を作ろうとしているのはそのためですが、その遺産には観察して学ばなければならない側面が数多くあります。ある意味では、伝統的な金融における流動性の可用性は、これらの側面の 1 つと考えることができます。従来の金融が流動性を確保するためにどのようなメカニズムを使用しているかを見てみましょう。
2.1 信用 - 必要なときに資金を調達する手段
伝統的な金融における流動性について議論する場合、信用が最も重要な要素となります。信用は現代の金融システムを支える基盤であり、インフラストラクチャです。信用は、将来の返済を条件に資金または資産を借り入れる能力を提供し、必要に応じて即座に流動性ニーズを満たします。たとえば、クレジットカードは消費者や企業に継続的に流動性を供給するツールです (給料日は決まっていますが、口座にすぐにお金がなくてもクレジットカードを通じて「消費」することができます)。現在の消費を将来まで延期する。
では、そのようなクレジットは Web3 で適切に実装されているのでしょうか? （融資プロトコルを通じて）「ある程度」の実装は行われていますが、資本効率の点では、依然として従来の金融の信用システムに追いついていません。
2.2 保険 - 将来の不確実性に対する財政的保護
保険の仕組みは、平常時に資金を集めて将来の潜在的な損失に対する財政的保護を提供することで、流動性の可用性を強化します。これにより、個人だけでなく企業も経済変動に効果的に対応し、困難な市場状況でも流動性を維持できるようになります（たとえば、無保険者は病気になったときに一時金を支払わなければなりませんが、保険に加入している人は病気でないときも継続的に保険料を支払っているため、病気になったときに保険で入院費用を賄うことができます）。
2.3 借り換え -状況に応じてより良い金融環境を提供
ローンを組んだことがある人なら、借り換えという概念をよくご存知でしょう。借り換えにより、借り手は既存の信用契約を再調整または置き換えることができるため、有利な金融環境を活用し、流動性管理能力を向上させることができます。特に、借り換えにより、債権者は金利を引き下げたり、返済期間を延長したりすることができ、流動性の確保が可能になります。
2.4 クリアリングハウス - 金融商品取引の効率化
クリアリングハウスとは、金融商品の買い手と売り手の間の仲介役を務める組織を指します。取引を決済するだけでなく、リスクを軽減しながら金融商品の取引が効率的に行われるように証拠金を徴収します。代表的な例は、米国内で証券取引を処理し、安全で信頼性の高い流動性を提供する米国証券保管振替機構です。
2.5 銀行間貸出市場 - 銀行間の流動性配分の最適化
銀行間融資は文字通り、銀行システム内の流動性配分を合理化します。 SOFR（担保付翌日物融資金利）などのベンチマーク金利は、金融システム全体の借入および貸出コストに影響を与え、必要な場所に流動性を効率的に配分できるようにします。米国のフェデラルファンド金利市場は、銀行間貸出市場のもう一つの例です。
2.6 エスクロー - 取引当事者の資産の保護
エスクロー サービスは、契約上の義務が履行されるまで取引当事者に代わって資産または資金を保管し、取引が円滑に進むまで資産を保管することで契約上の義務の履行を促進します。
（実際、現在多くのブロックチェーン/暗号関連製品はエスクローベースのモデルを使用しているため、分散型金融はすでに伝統的な金融からメカニズムを借用していると言えます。）
2.7 ディーラーとマーケットメーカー - 金融商品の流動性の確保
大手投資銀行などのディーラーやマーケット メーカーは、特定の金融商品について継続的にビッド/アスク相場を提供し、誰かが商品を取引したいときに常に取引相手（購入時には売り手、販売時には買い手）が利用できるようにしています。
ご覧のとおり、従来の金融システムが流動性の可用性を確保する方法は、単一のメカニズムによって駆動されるのではなく、さまざまなメカニズムが連携して市場に流動性を供給し、必要に応じて流動性が「保証」されるようにインフラストラクチャを最適化することによって実現されます。ブロックチェーンも同様です。 Injective がネットワーク レベルで流動性の可用性を保証するには、革新的なメカニズムが 1 つだけではなく、必要に応じて流動性を適切に分配するために連携して機能するさまざまなメカニズムが必要です。もちろん、伝統的な金融の仕組みをそのまますべて取り入れることはできないかもしれませんが、そこから得られるヒントは確かにあるはずです。では、Injective は流動性の可用性を最適化するためにどのようなメカニズムを検討しているのでしょうか?
3. ブロックチェーンにおける流動性の最適化
「ネットワーク内の流動性をdApp間で適切に移動する」というのは単純に思えるかもしれませんが、実際にはそれほど単純ではありません。ブロックチェーンでは、流動性はユーザーから引き出され、ユーザーは流動性に対して 100% の権限を持ちます (ブロックチェーンは自己管理を可能にするため)。また、アプリケーション間の利害関係も考慮する必要があります。たとえば、流動性プロバイダーが dApp に預けられた流動性を引き出したいが、その資本が他の場所で使用されている場合はどうなるでしょうか?あるいは、アプリケーションがインセンティブを提供することで流動性を引き付けたとしても、その流動性が潜在的に競合相手となる可能性のある別のアプリケーションによって無料で使用される場合、どのアプリケーションも個別に流動性を引き付けるインセンティブを持たないことになります。したがって、ネットワーク内の流動性をタイムリーに活用することは、思ったほど簡単ではありません。
この問題を解決するために、Injective Research では約 4 つのメカニズムを導入しています。
3.1 経済的インセンティブの提供とリスクの最小化
まず第一に、インセンティブが重要です。流動性を提供する人々とアプリケーションの両方が、ネットワーク レベルの流動性の可用性の向上に「自発的に」参加しないよりも、ネットワーク レベルの流動性の可用性の向上に貢献するインセンティブを強く持たなければなりません。たとえば、ネットワーク レベルの流動性の可用性を高めるために協力するアプリケーションは、より多くの流動性を確保できるため、ユーザー エクスペリエンスが向上し、トランザクション量が増加し、より多くのユーザーを引き付け、より多くの手数料を獲得し、フライホイール構造が形成されます。
同時に、流動性プロバイダーのリスクを最小限に抑えることも必要です。流動性が自由に利用される一方で、資金を回収したいときにいつでも引き出しリクエストがスムーズに処理され、取り付け騒ぎを防ぐためのメカニズムが必要です。たとえば、緊急の引き出しに備えて流動性を確保するためにネットワーク レベルで準備金を用意することも 1 つの方法です。もちろん、こうした準備金をどれだけ、どのように積み立て、運用するかについては、さらなる議論が必要です（私の意見では、商業銀行の準備金要件を参考にしつつ、取り付け騒ぎの可能性を阻止するために、より保守的な計算を行うのが良い戦略でしょう）。
3.2 ジャストインタイム（JIT）アクション
ジャストインタイム アクションとは、事前に定義されたトリガー条件が満たされたときに、チェーン状態の変化に応じてトランザクションを実行することを指します。 JIT アクションは、次のようにいくつかのサブ機能に分けられます。
3.2.1 トリガーメカニズム
JIT アクションについて説明したように、このメカニズムは特定のトリガーが発生したときに開始されます。トリガーは、突然のリソース需要の急増、ユーザー アクティビティの変化、ネットワーク状態の変化など、チェーン状態の変化に応じて発生します。
3.2.2 統合のための非同期インターフェース
非同期インターフェースにより、dApp は条件付きで JIT メカニズムと対話できます (この条件はさまざまに設定できます。たとえば、DEX A に未使用のアイドル流動性がある場合、A の流動性を流動性可用性システムに供給したり、逆に流動性可用性システムから流動性を取得したりできます)。これにより、dApp は流動性を他の場所に提供したり、特定の条件下で流動性を取り出したりすることができ、ネットワーク レベルの流動性を最適化できます。
3.2.3 指導
トリガー機構を通じてトリガーが発生すると、命令シーケンスが実行されます。ここで実行される命令は、順次実行することもできます。
3.2.4 スマートコントラクトの自動化
これらのプロセスはリアルタイムで管理および調整する必要があるため、スマート コントラクトを自動化して、命令トリガーを継続的に監視し、リソース割り当てを自動的に調整する必要があります。
3.2.5 複数リソースの割り当て
JIT メカニズムは流動性だけでなく、他のリソース (コンピューティング能力やストレージなど) にも適用できます。最終的に、ブロックチェーンがネットワーク レベルで流動性を統合できれば、他の要素も統合できるようになります。つまり、流動性の可用性を向上させることは、流動性の問題を解決するだけでなく、さまざまな分野で柔軟性を高めるための出発点にもなり得ます。
3.3 流動性証明
ジャストインタイムのメカニズムと同じくらい重要なのは流動性の証明です。即時実行には流動性が必要であり、流動性の確認がなければ実行できないためです。流動性の証明を容易にするためには、1) dApp は保有する流動性がジャストインタイムメカニズムの実行に十分であるという検証可能な証拠をネットワークに提供できなければなりません。2) ネットワークは dApp が流動性共有に自発的に参加するための十分なインセンティブを提供しなければなりません。3) 安心して流動性を提供できるセーフティネットも必要です。
3.4 ソルバーとルーティング層
ジャストインタイムのメカニズムによって流動性がリアルタイムで供給され、流動性証明によってその流動性が保証される場合、残る課題は、その流動性をどこにどのように割り当て、その経路を指定するかを決定することです。このためには、ソルバーとルーティング レイヤーが必要です。このレイヤーは、流動性可用性フレームワーク内の「意思決定エンジン」として機能し、リアルタイムのネットワーク状況に応じて流動性を最適に割り当て、さまざまなアプリケーションやチェーンにルーティングします。
ソルバーは、取引コスト、流動性移動速度、資本効率、ネットワーク状態などのさまざまな要素を総合的に考慮して最適化し、最も効率的な流動性パスを継続的に探索します。さらに、安全性を損なうことなく流動性が効率的に分配されるように、ネットワーク全体のさまざまな制約を識別します。このプロセス全体は、リアルタイムの状況変化に応じて動的に動作し、ネットワーク需要が発生するとすぐに流動性を再分配して全体のバランスを維持します。
要約すると、ソルバーとルーティング層は、ジャストインタイム システムとユーザー (dApps) 間の重要なリンクであり、流動性が必要になる時期と場所を識別し、ジャストインタイム システムをトリガーできるようにします (上図を参照)。この構造は、既存のブロックチェーンで試みられているクロスチェーン流動性ルーティングソリューションとは異なります。現在のルーティング ソリューションは、複数のネットワークに分散されたアプリケーション固有の流動性 (アプリ独自の流動性) を集約しますが、Injective によって導入されたソルバーとルーティング レイヤーは、「アプリケーションごとに分離された流動性」という概念を完全に排除し、アプリケーション間で分散された流動性を必要なときに必要な場所に供給することで差別化を図っています。
3.5 期待される効果
これらの仕組みがうまく活用され、ネットワークが成熟すれば、dAppsは自ら流動性を集めるために多くのコストを支払う必要がなくなります（現在、多くのDeFiプロトコルが流動性を集めるために意味のない「ガバナンス」トークンやそのようなトークンを意味するポイントを作成し、報酬として配布したり、レイヤー1ネットワークが一時的な流動性を集めるためにdAppsにガバナンストークンを配布したりしています。また、流動性プロバイダーは、資産を安全に保ちながら、預けられた流動性のリターンの最大化を目指すことができます（提供した流動性は遊休流動性にならず、実際の金融活動に使用されるため、その手数料を受け取ることができ、流動性プロバイダーは利益の最大化を目指すことができます）。
最終的には、流動性の可用性がネットワーク レベルで最適化されると、ユーザーは最大の利益を得ることができます。ユーザーは、いつ、どこで、何を取引するかに関係なく、最適な価格で迅速かつ安全に資産を取引することができ、どのアプリケーションの流動性が高いかを探すことなく、さまざまな金融取引を行うことができます。したがって、流動性の可用性を最大化するためのInjectiveの動きは、特定の当事者のための取り組みではなく、ネットワークのすべての参加者にとってこれまで存在していた流動性の非効率性を削減し、最小限のコストで最大限の効率を達成することを目的としています。
4. 著者の意見
4.1 TVLはもう不要
ブロックチェーン業界の研究者として、私はTVLを含むさまざまな指標に基づいてネットワークの成功を判断してきました。しかし、TVLのような指標がいかに不正確であるかを知りながらも、ネットワークレベルでの流動性をTVLほど直感的に表す指標がなかったため、私はTVLについて言及し、活用し続けてきました。そんな中、Injectiveが導入したLiquidity Availabilityは、新たな指標を提案するだけでなく、ネットワーク全体のレベルで流動性の可用性を向上させるための研究も行っている点で、非常に心強いです。
特に、多くのブロックチェーンプロジェクトは競争的に TVL の数字を膨らませたり歪めたりする傾向があると批判する人もいます。たとえば、同じ資金がさまざまなプロトコルで複数回カウントされたり、貸付預金構造を通じて TVL が人為的に膨らんだりすることがよくありました。このため、TVLは分散型金融（DeFi）エコシステムで最も使用されている指標であるにもかかわらず、「この指標が実際の流動性を適切に反映しているかどうか」という疑問が引き続き提起されてきました。この文脈では、流動性の可用性は、単にロックされた資金の量ではなく、あらゆる種類の取引に実際にどれだけの流動性が利用可能か、そしてその流動性がどのような状況でもどれだけ迅速かつ安定して利用できるかに焦点が当てられています。
Injective が提案する流動性可用性の概念も、ネットワーク全体が持つ流動性の質的レベルを把握しようとする試みです。たとえば、すべての資金を単一のアプリケーションに集中させるのではなく、流動性がネットワーク レベルに存在する場合 (つまり、ユーザーがどのアプリケーションを使用していても、適切なタイミングと場所で必要な流動性を受け取ることができる場合)、その機能を測定すると、どのブロックチェーンがより安定した流動性とより大きな実用的可能性を実際に提供しているかが明らかになります。この点において特に注目すべきは、「流動性の可用性」です。これは、資金の分配、アクセス可能性、ネットワーク レベルでのリアルタイムの交換可能性などの要素を考慮して、ネットワークの実際の流動性容量を評価するものです。
4.2 流動性はdApp間の競争ではなく共生関係を形成する
流動性の可用性を個々のアプリケーションではなくネットワーク全体の共通タスクとして捉える視点は、DeFi の将来の方向性に非常に重要な意味合いをもたらします。これは、特定のプロトコルが示す「TVL競争」やマーケティング効果のみに焦点を当てるのではなく、エコシステムの共生と共同繁栄の追求に向けてさらに一歩前進する転換点です。
このようなマクロ的な視点から流動性の問題に取り組むことで、プロジェクト間の資金移動や相互運用性をより柔軟かつ安定的に構築することができます。これにより、「限られた資金を先に取るための競争」ではなく、相互の協力と相乗効果を最大化する構造が生まれます。その結果、プロトコル同士が資金を共有・拡大し、危機的状況においては迅速に資金を再分配することで、エコシステム全体の競争力と安定性を同時に高める好循環が可能になります。
最終的に、ネットワーク レベルで流動性の可用性を確立することで、次の 3 つの主要な効果が期待できます。
継続的な成長と技術開発
流動性のボトルネックが解消されると、プロジェクトは新たな金融商品やサービスを試す能力が大幅に拡大します。これにより、さらなるイノベーションが促進され、プロトコルの互換性とコラボレーションが加速され、DeFi エコシステム全体が成長の機会に対応できるようになります。
より公平でダイナミックな金融エコシステムの構築
誰でも簡単に資金を活用できる基盤が整い、市場のショックで簡単に崩壊する心配もなく、小規模なプロジェクトでも成長することができます。柔軟な資金の流れが保証される環境下では、さまざまな実験や新しいプロジェクトが次々と生まれ、エコシステム全体がより活性化します。
リスク管理の合理化
分散型資金運用とリアルタイム流動化が可能になると、特定のプロジェクトや資産にのみ資金が集中する現象が緩和されます。これにより、予期しない状況での危機転送が削減され、ネットワーク全体の安定性が向上します。
結局、流動性可用性という概念を中心に、ネットワーク全体が協力と相互補完性を追求し始めれば、既存のTVL競争の時代が止まった地点を超えて、長期的かつ持続可能な金融イノベーションの地平が開ける可能性がある。これは単なる指標の改善を超えた意味を持ち、最終的にはオンチェーン金融の真の可能性を引き出す中核的な原動力になる可能性があります。
4.3 流動性の可用性が統合ブロックチェーンの構成可能性を完成させる
統合ブロックチェーンの最大の利点の 1 つは、スマート コントラクト間で「アトミックな構成可能性」が実現できることです。つまり、単一のトランザクション内で複数のプロトコルを呼び出す場合でも、全体をまとめて実行またはキャンセルできるため、プロトコル間の論理的なやり取りがスムーズになります。しかし、このアトミックな構成可能性は、多くの場合、論理次元に限定されてきました。つまり、実際の資金、つまり流動性が複数のプロトコル間で「同時に移動」し、スムーズに「共有」されるシナリオは限られているということです。
しかし、統合ブロックチェーンに流動性の可用性の概念を導入することで、この問題をさらに一歩前進させる道が開かれます。単一のシャード構造の下にあるすべてのアプリケーションが相互に流動性をアトミックに移動して利用できる場合、流動性は基本的に「1つの巨大なプール」に結び付けられ、DeFi エコシステム全体ですぐに再利用できます。これは、複数のDeFiを一度に呼び出すレベルではなく、プロトコル間の流動性自体が完全に接続された状態で、すべてのアプリケーションが最適化された資金効率と取引の利便性を享受できるという点で革新的です。
たとえば、オーダーブックベースのアプリケーションで一時的に使用される流動性が、貸付またはスワップ プロトコルによってすぐに受け取られ、利用され、プロセス全体が単一のトランザクション内でアトミックに処理されるシナリオを想像してください。これは、システム全体が単一のシャードを通じて密接に接続されているという統合ブロックチェーンの利点を最大限に活用する方法であり、その結果、すべてのアプリケーションが統合された流動性をアトミックに共有することで、真のコンポーザビリティを実現できます。
最終的には、流動性の可用性を通じて資金をアトミックに移動させることで、統合ブロックチェーンが謳うコンポーザビリティの可能性を 100% 活用できるようになります。これは、ロールアップが分離されているモジュラー チェーン環境では実装が難しい利点でもあり、最終的にはチェーン エコシステム全体がより低いコストと高い流動性効率で運用されることにつながります。つまり、流動性を原子的に共有することで、統合チェーンは真の意味での「統合金融インフラ」を完成させます。
4.4 しかし課題もある
もちろん、ここで紹介したアイデアは単なる出発点にすぎません。現在提示されている概念と戦略は、追加の研究と実験を通じて改良する必要があり、実際のプロトコルと市場環境に適用する際に生じる多数の要素を綿密に特定する必要があります。これには、参加者の行動パターンとインセンティブ構造の包括的な理解と、内部ネットワーク データの分析が必要です。
上で述べたように、従来の金融システムから得られる洞察は非常に有用な参照点となります。中央銀行モデルやバーゼル規制などの従来のリスク管理手法を再解釈し、オンチェーン金融に適用する余地が明らかにあります。しかし同時に、伝統的な金融に内在する中央集権化と閉鎖性の限界を克服するという課題もあります。つまり、既存のシステムで使われている概念をそのまま採用するのではなく、前述した「ブロックチェーン特有の仕組み」を開発・応用することで、新たなパラダイムを切り拓く必要があるのです。
このように、「新たな金融エコシステムにおけるリスク管理と流動性設計」という視点は決して簡単な作業ではありません。新しいプロトコルや市場参加者が絶えず出現し、ブロックチェーン技術全体の開発が急速に進んでいることは、不確実性を高める要因であると同時に、爆発的なチャンスの場も提供しています。したがって、今回提示した「流動性可用性」に関するアイデアを体系的に研究し、検証し、実際の市場に適用する努力が積み重なれば、オンチェーン経済全体を飛躍的に向上させる貴重な原動力となるでしょう。
結局のところ、今後の課題はこの可能性を具体化することです。 dApp が互いの流動性をネットワークに分配するように、ネットワーク レベルで経済的インセンティブをどのように設計するのでしょうか?流動性を提供するプロセスにはどのような技術的および経済的リスクが存在し、ネットワークはこれらのリスクをどのように軽減しますか? dApp は保有する流動性をどのように検証するのでしょうか?ソルバーは流動性パスをどのように最適化するのでしょうか?等々。多くの課題が残っています。しかし、問題を解決する第一歩は、問題を認識し、それを解決するためにさまざまなアイデアを出すことだと私は思います。そういった意味では、今回Injective Researchが書いた流動性の可用性は、今後多くのスマートコントラクトプラットフォームが検討すべき問題だと考えています。
