FusionFiプロトコル:AgentFi相互運用性の核心的な橋梁を構築する
概要
Permaswap は最近、AO 上で FusionFi Protocol(FFP) に基づく AgentFi のデモケースを発表し、自動マーケットメイキングエージェント(AMM Agent)を作成し、アービトラージ操作を行うケースを追加しました。FFP を使用することで、開発者は数行のコードで AMM エージェントプールを作成し、資産の交換を実現できます。FFP は AO ネットワーク上の標準プロトコルとして、さまざまなタイプのエージェントに相互運用性のサポートを提供します。
この記事では、まず AgentFi、主権金融などの核心概念を整理し、次に Orderbook Agent と AMM Agent の二つの典型的なエージェントの例を紹介し、FFP プロトコルがどのように二つの異なる取引プロセスを統合するかを示し、最後に FFP が未来の金融エコシステムにおいて果たすことができる重要な役割を明らかにします。
基本概念
AgentFi は DeFi の基盤の上に「エージェント」概念を導入し、ユーザーが自分のスマートコントラクトエージェント(Agent)を展開し、プロトコルとのインタラクションを自動的に管理できるようにします。エージェントを通じて、ユーザーは資産管理、戦略実行などのさまざまな金融操作を自主的かつ自動的に実行できます。
従来の DeFi プロトコルはスマートコントラクトを使用して資産の交換、貸し出しなどの操作を実現していますが、これらの資産は通常、単一のスマートコントラクトに集中してロックされており、ユーザーは資金をコントラクトに預ける必要がある一方で、関連機能やパラメータをカスタマイズする柔軟性を失っています。AgentFi はこの制限を打破し、各ユーザーが金融機能を備えた独立したエージェント(Agent)を持ち、これを通じて個別の金融業務を展開できるようにします。つまり、AgentFi はユーザーのエージェントを独立した金融主体にし、個人が資産の交換、貸し出し契約、資産発行ルールなどの金融ルールを制定できるようにし、個別の金融管理を実現し、従来の集中化の制限を突破します。
これが主権金融です!
従来の中央銀行が金融ルールを制御する集中体系とは異なり、主権金融はユーザー自身が金融ルールを制定し、掌握することを可能にし、開発者が提供する単一のコントラクトや中央機関に依存しなくなります。
AgentFi の基盤:性能と柔軟性
従来の DeFi プロトコルが資金を集中管理する理由の一つは、イーサリアムの性能の制限です:それは各ユーザーに独立したエージェント計算能力を提供できません。そのため、Compound や Uniswap のようなプラットフォームは、ブロックチェーンの制約に適応するためにコードを最適化しました。さらに、従来のブロックチェーンスマートコントラクトは柔軟性が低く、修正や再展開が難しいため、エージェントの計算の柔軟性が制限されます。
AO は分散型のグローバルスーパー並列コンピュータとして、独立した計算ユニット(プロセスと呼ばれる)を提供し、各プロセスは独立した計算リソースを持ち、性能のボトルネックを解決します。同時に、プロセス内で実行されるコントラクトコードはプロセスの所有者によって制御され、柔軟に更新およびアップグレードでき、AgentFi の柔軟性に対する堅実な基盤を提供します。
FusionFi Protocol
AO の分散型ネットワーク内で、AgentFi は広く採用され、いくつかの独立した金融主体を生成することができます。たとえば、ゲーム内の NPC はゲームサービスを提供するだけでなく、金融サービスも提供できます。たとえば、質屋の NPC はプレイヤーの NFT を担保として受け入れ、貸付サービスを提供することができ、この NPC は独立したエージェント、すなわち主権金融の個体です。AO 上のすべてのユーザーとプロセスは、この方法で金融エージェントを作成でき、任意の計算ユニットが「金融機関」となり、カスタマイズされた金融サービスを提供できます。
異なる種類の金融エージェントが独自に発展すると、異なるプロトコル規範が生じ、エージェント間の相互作用が大きな課題となります。業務の違いによる相互運用性の問題を解決するために、FusionFi Protocol(FFP)が登場しました。
FusionFi Protocol は、異なる金融エージェントを接続し、情報の橋を構築し、相互運用性を実現し、多様な金融業務を統合することを目的としたプロトコル規範と開発ツールです。FFP に対応するエージェントは相互に接続可能です。
金融の詳細に深入りする時間がないユーザーも、FFP SDK を使用して自分のエージェントを特定の金融属性を持つエージェントに変換できます。AgentFi の実装の難易度を下げることで、FFP は主権金融を手の届くものにします。
実践と相互運用性
Order Book(オーダーブック)と AMM(自動マーケットメイカー)は二つの異なる取引メカニズムであり、それぞれの取引プロセスには顕著な違いがあります。Order Book はオーダーブックを通じてすべての売買意向を記録し、取引は売買双方の価格が一致するのを待つ必要があるため、対抗者の参加に依存します。一方、AMM は対抗者に依存しません。流動性プールとアルゴリズムを通じて、ユーザーはプール内の資産と直接取引を行います。流動性提供者は資金をプールに預け、AMM はアルゴリズム(例えば、恒常積公式)を使用して自動的に価格を調整し、ユーザーがペアリングを待つことなく取引を完了できるようにします。
FFP は統一された方法とプロセスで Orderbook と AMM の取引を処理し、両者の流動性を融合させることができます。
以下のデモコードを参照してください:https://github.com/permadao/ffp-demo
オーダーブックエージェント(Orderbook Agent)
FFP のオーダーブックデモでは、開発者はオーダーブックエージェント(Orderbook Agent)を作成し、資産取引を行うことができます:
- オーダーブックエージェントの作成:
createOrderbookProcess
関数を使用してオーダーブックエージェントプロセスを作成します。この時、AO プロセスが展開され、オーダーブックに関連するビジネスロジックがロードされ、独立した金融実体としての役割を果たします。 - 資産の預け入れ:
deposit.js
スクリプトを使用してトークンをオーダーブックエージェントに預け、取引資金を提供します。 - 注文の作成:
agent.makeOrder
メソッドを使用してオーダーブックに買い注文または売り注文を作成します。すべての注文は特定の FFP Schema 形式で AO ネットワークに送信され、その後、注文は特定の形式でブロックチェーンネットワークに透明に表示され、一致を待ちます。 - 注文の取引:
agent.takeOrder
メソッドを使用して注文を受け取り、システムは自動的に取引を完了し、資産を更新します。
自動マーケットメイカーエージェント(AMM Agent)
AMM Agent のデモでは、ユーザーが作成したエージェントは個人主権の流動性プールに相当します。AgentFi を通じて、ユーザーは集中プラットフォームや従来の取引所に依存することなく、自主的に資産交換機能を提供できます。以下は AMM Agent の核心プロセスです:
- AMM Agent の作成:
createAMMProcess
関数を使用して AMM Agent プロセスを作成し、ユーザーが制御する AO プロセスとして展開し、流動性管理機能を備えた個人金融実体となります。 - 資産の預け入れ:ユーザーはトークンを AMM Agent に預け、流動性プールに資金を注入し、取引ニーズをサポートします。
- 流動性の追加:
agent.addLiquidity
メソッドを呼び出し、預け入れた資産を流動性プールに追加します。ユーザーはスマートコントラクトを通じてプール内資産の価格設定と交換比率を設定できます。 - 自動交換:AMM Agent はアルゴリズム(例えば、恒常積公式)を使用して交換価格を自動計算し、価格結果を特定の FFP Schema 形式で取引を要求したユーザーに返します。
- 流動性の削除:ユーザーが資金を引き出したい場合、
agent.removeLiquidity
メソッドを使用してプール内の流動性を削除し、資産を引き出すことができます。
AMM Agent を作成することで、ユーザーは完全に自主的な流動性管理権を持ち、対抗者なしで資産交換サービスを提供できるため、個別の分散型取引環境を構築します。
ユーザーがエージェントを作成する際(AMM Agent でも Orderbook Agent でも)、実際には個人主権の分散型取引所を作成していると考えることができます。 AgentFi は従来の取引所の概念を根本的に打破し、ユーザーが特定のプラットフォームに依存せずに取引を行えるようにします。特定の機能を持つエージェントとスマートコントラクトルールを設定することで、ユーザーは交換の「場」を自主的に提供し、個別の金融サービスを実現できます。エージェントの作成プロセスは、実際には一行のコードだけで済みます。
相互運用性
FFP Schema は FusionFi Protocol(FFP) において取引および決済データを標準化するための構造化フォーマットです。これは、異なる取引プロセス(Orderbook と AMM など)におけるデータフォーマットと通信プロトコルを定義し、異なるタイプの金融エージェント(Agents)間でスムーズに相互運用可能であることを保証します。この統一されたデータフォーマットにより、取引プロセスにおける価格、注文状態、資産情報などの重要データがさまざまなエージェント間で共有および解析可能になります。
Orderbook Agent と AMM Agent の第四ステップでは、Orderbook の注文と AMM のリクエストは統一された FFP Schema フォーマットを採用し、一貫した決済データ構造を実現します。FFP Schema はエージェント間の相互運用性を標準化します:
- アービトラージャーは、チェーン上で Orderbook の注文を直接照会し、FFP Schema を通じて Orderbook と AMM の価格を比較し、価格差を発見できます。
- アービトラージャーは、フォーマットが統一された取引データを FFP 決済プロセスに提出するだけで、エージェント間の原子性取引を実現できます。FFP 規範は、複数のヘッジ注文がすべて完了するか、すべて失敗することを保証し、取引の不一致リスクを回避します。
FFP のケースでは、Orderbook と AMM の異なる取引プロセスが相互接続され、FFP は二つのビジネスの境界を打破し、相互協力と統合を実現しました。
特性
FFP は複数の取引の原子決済をサポートし、FFP に基づいて構築された DEX に以下の高度な特性を提供します:
- 大口取引の分割:トレーダーは大口注文を複数の小口注文に分割できます。たとえば、トレーダーが 100 万ドルの取引を完了する必要がある場合、単一のエージェントが最適な価格を提供するのが難しいことがあります。FFP は大口注文を複数の小口注文に分割し、異なるエージェント間で実行することを可能にし、ネットワーク内で最適な価格を取得します。
- 複数取引の統合:市場の散発的な注文を一つの原子注文に統合し、Orderbook と AMM の相互運用性を強化し、取引をより柔軟にします。
- マルチホップ取引:マルチホップ取引は統合機能の延長応用です。たとえば、トレーダーが資産 A を C に交換したいが、市場に A-C の取引ペアがない場合、A-B と B-C の取引ペアが存在する場合、FFP は A-B と B-C の二つの取引を一つの注文に統合し、取引目的を達成します。
- ゼロ資金アービトラージ:アービトラージャーは、市場内の二つのヘッジ注文の価格差を利用して利益を得ることができます。従来のアービトラージ手法とは異なり、FFP のゼロ資金アービトラージは自己資金を必要とせず、アービトラージャーは二つの注文を決済プロセスに提出するだけで、システムが自動的に資産交換を完了し、利ざや収益をアービトラージャーに配布します。
FFP がもたらすこれらの革新特性は、ユーザーの取引体験を簡素化し、最適な価格を保証し、アービトラージャーの資本効率を向上させ、価値の効率的な流通を保障します。
展望
要するに、FFP は金融エージェント(Agents)に統一されたフレームワークを提供し、異なる金融シーン間の壁を打破します。 Orderbook と AMM にとどまらず、FFP を通じて、将来的には貸付、先物、合成資産などのさまざまな金融業務のシームレスな統合が実現され、アプリケーション間、シーン間の分散型金融エコシステムが構築されるでしょう。
統一データ構造(FFP Schema)を通じて、FFP はエージェント間のコミュニケーションと決済を簡素化し、取引の柔軟性と効率を向上させます。より多くのタイプの金融エージェントが登場するにつれて、FFP は AO 上の AgentFi エコシステムのコアプロトコルとなり、真の主権金融と個別の金融サービスの普及を促進することが期待されます。