出典:PermaDAO
前回に続きます。ブロックチェーン業界全体は拡張の進化史であり、高速化とコスト削減のために、さまざまなルートが試されていますが、すべてには限界があります。AOが登場するまで、伝統的なブロックチェーンとは異なるパラダイムが存在しませんでした。巧妙な設計により、AO上のブロックスペースは、もはや固定供給の希少品ではなく、必要に応じて無限に生成できるリソースになり、AOに無制限の拡張能力を与えました！
これにより、エージェント向け金融モデルであるAgentFiが可能となり、従来の分散型金融に比べて、AgentFiはより広範なアプリケーションシーンを持っています。
伝統的な分散型金融プロトコルは、ETHエーテルから生まれましたが、さまざまなL2および高性能な新しいパブリックチェーンが登場しても、分散型金融の構築パラダイムに対する人々の想像力は常にETHエーテルに制約されていました。今、私たちはパフォーマンス制限のないプラットフォームに入って、インターネットの進化のように、読み取り専用から読み書き、アルゴリズム、自治の一連の発展のように、オンチェーン金融の新しい景色を想像することができるでしょうか？すべてのユーザーが金融エージェントを作成し、すべての計算ユニットが「金融機関」となり、カスタム金融サービスを提供する金融平等な景観です！
AOコンピュータ上では、プロセス間の通信はメッセージを介して行われ、メッセージの送受信は一定の規約に従います。実際、金融シーンでも同様です。
カスタマイズは多様性の出発点です。異なる種類の金融エージェントが個別に発展する場合、異なるプロトコル仕様が生じることになります。このような場合、エージェント間の相互作用は大きな問題となります。エージェント同士がどのように相互に通信し、さらには相互にマッチングすることができるのでしょうか？
統一された規格の欠如から生じる相互運用性の欠如を防ぐために、FusionFi Protocol（FFP）が生まれました。
FusionFi Protocol はエージェント間の相互プロトコルとして、エージェント間の相互ルールを定義し、エージェントによって作成されたさまざまな金融取引が相互に連携し、さらに一体となります。AgentFi がまだ始まったばかりの時点で、このようなプロトコルはかなり先見性があります。
FFP(FusionFiプロトコル)
FusionFi Protocolは、EverVisionの創設者であるoutprogがArweave Asia 2024カンファレンスで発表したプロトコルです。
FusionFi ProtocolのキープコンセプトはNote（ノート）です。これは約束の抽象的な表現モデルであり、トークン、債券、証明書、契約権などの形式を取ることができます。Noteモデルを媒体として使用することで、FusionFi Protocolは取引、融資、ステークなど、さまざまな金融シナリオをサポートできます。
FusionFi Protocol は、プロトコル規格だけでなく、開発者が AgentFi の開発ツール（FFP SDK）を作成する際にも役立ち、開発をより効率的かつ簡単に行うのを支援します。
現在、FusionFiプロトコルには、AMMエージェントとオーダーブックエージェントの2つのインスタンスがあります。
AMMエージェント
AMMエージェントの例を見てみましょう。各AMMエージェントは、「個人の主権」の流動性プールと考えることができます。この流動性プールのメイキングルールは自由に設定できます。つまり、統一されたメイキングアルゴリズムを採用したファンドプールなどの外部プラットフォームに依存する必要はありません。ユーザーは自律的にスワップ機能を実現し、ネットワーク全体で適切な相手を見つけることができます。つまり、ユーザーがエージェントを作成すると、実際には「個人の分散型取引所」を作成していることになります。そして、FusionFiプロトコルは、多くのこのような「個人取引所」がピアツーピアのネットワークを形成し、より効率的かつ柔軟なマッチングを実現します。
以下はAMMエージェントの中核プロセスです:
見た目はとても簡単ですが、LPにとっては、作成、預金、追加、交換、引き出しのプロセスのように見えますが、異なるのはエージェントがユーザー自身によって制御されることです。LPにとっては、資産は自分の手にあります。これは実際にはAgentFi自体の能力であり、FusionFiはこの罠の能力に対応して、比較的統一的なエントリーポイント（およびデータ構造）を構築しています。
LPとして、あなたが行う必要があるのは、預入と引き出し操作だけで、統一されたエントリ関数を呼び出すことです。関数自体は、複数のディセントラル化金融プロジェクトとリンクすることができますが、その後の相互作用や機能については気にする必要はありません。これがプロトコル標準の価値です。これは、ERC20などの標準が存在することで、アプリケーションレイヤーがユーザーに適応するのと同様です。
以下は流動性を追加する具体的なコードの例です。
見ることができますが、わずか数行のコアコードを使用して、この機能を迅速に実装できます。
const minLiquidity = await agent.getMinLiquidityByX(helloAmount, ammSlippageOfPercent) // 金額とスリッページを設定 const addLiquidityMessageId = await agent.addLiquidity(minLiquidity) // Initiating a message to add liquidity const addLiquidityResult = await getProcessResult(addLiquidityMessageId, ammProcess)//結果を取得する
ソースコードの使用例：
ノートライフサイクル
ここでは、Noteの視点に切り替えて、ユーザーとAMMエージェントの取引プロセスをもう一度見てみましょう。
ユーザーがお問合せリクエストを発行すると、対応する流動性を持つすべてのAMMエージェントが自動的に見積もりを作成します。この見積もりはノートと呼ばれ、その有効期間は非常に短く、迅速に取引が成立しない場合、ノートは無効になります。AMMエージェントはメーカーの役割を果たします。
すべてのNoteはシステムのNote Poolに集中的に保存され、Note Poolはシステム内で共有ストレージスペースとして機能し、他のエンティティがアクセスしやすくなっています。
ユーザーはフロントエンドのウェブページからNote Poolから最適な見積もりのノートを選び、決済センターに提出します。決済センターは具体的な決済操作、例えばここでのスワップを実行する責任があります。
ノートは「決済済み」としてマークされ、Swapが正常に実行されました。
ここでは、Settlement CenterはFusionFiプロトコルの重要なコンポーネントであり、システム内のさまざまなNote決済操作を処理する責任があります。
実際、Orderbook Agentについても同様であり、Orderbook Agentの中の指値注文自体がノートであり、その決済プロセスはAMM Agentが作成した見積もり注文エージェントとまったく同じです。これは、FusionFi Protocolが実際にAMMとオーダーブックから流動性を統合できることを意味します。
このような統合は多くの利点をもたらします。スワップシナリオでは、流動性はユーザーの注文とメイカーノードの両方から提供されます。ユーザーはルーティングプロトコルを利用して全体のノートプールから流動性を探し、最適な取引価格を実現することができます。AMMは市場に基本的な流動性を提供しますが、価格インパクトが大きく変動損失の問題があります。一方、オーダーブックはユーザーが自己メイカーとしての役割を果たすことができ、大口取引や特定の価格要件を持つユーザーに適しています。統合後、AMMは持続的な流動性を提供し、オーダーブックは価格インパクトを減らしデプスを増やすことで、大量注文の取引をより効率的にします。このモデルは異なるタイプのユーザーのニーズを満たし、個人投資家から機関投資家まで、適切な取引方法を見つけることができます。これにより資金利用率が向上し、市場の成熟を促進します。
マルチノートアトミックセトルメント
上記の例は、1回の決済で1つのNoteのみを対象としていますが、実際には、FusionFiプロトコルは1度に複数のNoteの決済をサポートし、このような決済はアトミックです。1回の決済で全てのNoteが決済されるまで、Noteの状態は変更されません。それ以外の場合、全てのNoteの状態は変更されません。
これにはいくつかの便利な機能がもたらされました：
源：
Permaswapは、FusionFi Protocol上に構築された最初のAgentFi DEXであり、AOエコシステムで最も成熟したDEXでもあります。 興味のある方は、Permaswap(aopsn.com)で上記の機能を体験することができます。
決済センター
明らかに、FusionFi Protocolでは、Settlement Centerは重要なコンポーネントです。それはすべてのノートを時間順に処理し、AOのSUシステムが正常であればその時間順を取得できます。誰でもノートプールからノートを取り出し、Settle Centerに提出して決済することができます。
noteの処理リクエスト量が増加すると、Settlement Centerは分散方式で簡単にスケーリングすることができ、複数の決済プロセスによって決済タスクを分散処理することもできます。どれだけのプレッシャーがあるかは、noteのIDに基づいて異なる決済プロセスにタスクを分散処理することによって決定されます。
Noteの多様なアプリ
FusionFiプロトコルで定義されたNoteの構造化形式は、実際には様々な金融取引に非常に汎用的です。そのため、Noteの適用方法は多岐にわたります。現物取引の見積もり、先物取引、先物取引、借り入れなどのシーンに使用できます。そのため、FusionFiが統合できるのは流動性だけでなく、様々な金融形態も含まれます。
筆者によれば、このインターネットの世界の本質は、マルチポイント取引であり、したがって、複数のグループ間の高頻度取引を解決することは非常に価値があります。AgentFiのモデルはほぼすべてのDeFiシーンをカバーでき、FusionFiプロトコルはエージェント間のピアツーピアのマッチングをより効率的に行うことができます。また、このようなマッチングはプロトコルを越えて行われます。DeFi領域では、流動性の獲得を主要な競合戦略とし、利益の獲得方法として流動性の独占が行われていますが、FusionFiプロトコルによる変化は画期的です！
もちろん、FusionFi Protocolは新しいプロトコルの標準であり、ビジネスの要件に応じて継続的に調整と最適化が必要かもしれません。これは、BIP（Bitcoin Improvement Proposal）ビットコイン改善提案とEIP（Ethereum Improvement Proposals）イーサリアム改善提案のモデルを参考にし、共創によってアイデアを取り入れることができます。
26.71K 人気度
52.54K 人気度
17.16K 人気度
11.97K 人気度
39.49K 人気度
FusionFi Protocol：すべての金融エージェントを接続する
出典:PermaDAO
前回に続きます。ブロックチェーン業界全体は拡張の進化史であり、高速化とコスト削減のために、さまざまなルートが試されていますが、すべてには限界があります。AOが登場するまで、伝統的なブロックチェーンとは異なるパラダイムが存在しませんでした。巧妙な設計により、AO上のブロックスペースは、もはや固定供給の希少品ではなく、必要に応じて無限に生成できるリソースになり、AOに無制限の拡張能力を与えました！
これにより、エージェント向け金融モデルであるAgentFiが可能となり、従来の分散型金融に比べて、AgentFiはより広範なアプリケーションシーンを持っています。
伝統的な分散型金融プロトコルは、ETHエーテルから生まれましたが、さまざまなL2および高性能な新しいパブリックチェーンが登場しても、分散型金融の構築パラダイムに対する人々の想像力は常にETHエーテルに制約されていました。今、私たちはパフォーマンス制限のないプラットフォームに入って、インターネットの進化のように、読み取り専用から読み書き、アルゴリズム、自治の一連の発展のように、オンチェーン金融の新しい景色を想像することができるでしょうか？すべてのユーザーが金融エージェントを作成し、すべての計算ユニットが「金融機関」となり、カスタム金融サービスを提供する金融平等な景観です！
なぜエージェントの標準プロトコルが必要なのですか？
AOコンピュータ上では、プロセス間の通信はメッセージを介して行われ、メッセージの送受信は一定の規約に従います。実際、金融シーンでも同様です。
カスタマイズは多様性の出発点です。異なる種類の金融エージェントが個別に発展する場合、異なるプロトコル仕様が生じることになります。このような場合、エージェント間の相互作用は大きな問題となります。エージェント同士がどのように相互に通信し、さらには相互にマッチングすることができるのでしょうか？
統一された規格の欠如から生じる相互運用性の欠如を防ぐために、FusionFi Protocol（FFP）が生まれました。
FusionFi Protocol はエージェント間の相互プロトコルとして、エージェント間の相互ルールを定義し、エージェントによって作成されたさまざまな金融取引が相互に連携し、さらに一体となります。AgentFi がまだ始まったばかりの時点で、このようなプロトコルはかなり先見性があります。
FFP(FusionFiプロトコル)
FusionFi Protocolは、EverVisionの創設者であるoutprogがArweave Asia 2024カンファレンスで発表したプロトコルです。
FusionFi ProtocolのキープコンセプトはNote（ノート）です。これは約束の抽象的な表現モデルであり、トークン、債券、証明書、契約権などの形式を取ることができます。Noteモデルを媒体として使用することで、FusionFi Protocolは取引、融資、ステークなど、さまざまな金融シナリオをサポートできます。
FusionFi Protocol は、プロトコル規格だけでなく、開発者が AgentFi の開発ツール（FFP SDK）を作成する際にも役立ち、開発をより効率的かつ簡単に行うのを支援します。
現在、FusionFiプロトコルには、AMMエージェントとオーダーブックエージェントの2つのインスタンスがあります。
AMMエージェント
AMMエージェントの例を見てみましょう。各AMMエージェントは、「個人の主権」の流動性プールと考えることができます。この流動性プールのメイキングルールは自由に設定できます。つまり、統一されたメイキングアルゴリズムを採用したファンドプールなどの外部プラットフォームに依存する必要はありません。ユーザーは自律的にスワップ機能を実現し、ネットワーク全体で適切な相手を見つけることができます。つまり、ユーザーがエージェントを作成すると、実際には「個人の分散型取引所」を作成していることになります。そして、FusionFiプロトコルは、多くのこのような「個人取引所」がピアツーピアのネットワークを形成し、より効率的かつ柔軟なマッチングを実現します。
以下はAMMエージェントの中核プロセスです:
見た目はとても簡単ですが、LPにとっては、作成、預金、追加、交換、引き出しのプロセスのように見えますが、異なるのはエージェントがユーザー自身によって制御されることです。LPにとっては、資産は自分の手にあります。これは実際にはAgentFi自体の能力であり、FusionFiはこの罠の能力に対応して、比較的統一的なエントリーポイント（およびデータ構造）を構築しています。
LPとして、あなたが行う必要があるのは、預入と引き出し操作だけで、統一されたエントリ関数を呼び出すことです。関数自体は、複数のディセントラル化金融プロジェクトとリンクすることができますが、その後の相互作用や機能については気にする必要はありません。これがプロトコル標準の価値です。これは、ERC20などの標準が存在することで、アプリケーションレイヤーがユーザーに適応するのと同様です。
以下は流動性を追加する具体的なコードの例です。
見ることができますが、わずか数行のコアコードを使用して、この機能を迅速に実装できます。
const minLiquidity = await agent.getMinLiquidityByX(helloAmount, ammSlippageOfPercent) // 金額とスリッページを設定 const addLiquidityMessageId = await agent.addLiquidity(minLiquidity) // Initiating a message to add liquidity const addLiquidityResult = await getProcessResult(addLiquidityMessageId, ammProcess)//結果を取得する
ソースコードの使用例：
ノートライフサイクル
ここでは、Noteの視点に切り替えて、ユーザーとAMMエージェントの取引プロセスをもう一度見てみましょう。
ユーザーがお問合せリクエストを発行すると、対応する流動性を持つすべてのAMMエージェントが自動的に見積もりを作成します。この見積もりはノートと呼ばれ、その有効期間は非常に短く、迅速に取引が成立しない場合、ノートは無効になります。AMMエージェントはメーカーの役割を果たします。
すべてのNoteはシステムのNote Poolに集中的に保存され、Note Poolはシステム内で共有ストレージスペースとして機能し、他のエンティティがアクセスしやすくなっています。
ユーザーはフロントエンドのウェブページからNote Poolから最適な見積もりのノートを選び、決済センターに提出します。決済センターは具体的な決済操作、例えばここでのスワップを実行する責任があります。
ノートは「決済済み」としてマークされ、Swapが正常に実行されました。
ここでは、Settlement CenterはFusionFiプロトコルの重要なコンポーネントであり、システム内のさまざまなNote決済操作を処理する責任があります。
実際、Orderbook Agentについても同様であり、Orderbook Agentの中の指値注文自体がノートであり、その決済プロセスはAMM Agentが作成した見積もり注文エージェントとまったく同じです。これは、FusionFi Protocolが実際にAMMとオーダーブックから流動性を統合できることを意味します。
このような統合は多くの利点をもたらします。スワップシナリオでは、流動性はユーザーの注文とメイカーノードの両方から提供されます。ユーザーはルーティングプロトコルを利用して全体のノートプールから流動性を探し、最適な取引価格を実現することができます。AMMは市場に基本的な流動性を提供しますが、価格インパクトが大きく変動損失の問題があります。一方、オーダーブックはユーザーが自己メイカーとしての役割を果たすことができ、大口取引や特定の価格要件を持つユーザーに適しています。統合後、AMMは持続的な流動性を提供し、オーダーブックは価格インパクトを減らしデプスを増やすことで、大量注文の取引をより効率的にします。このモデルは異なるタイプのユーザーのニーズを満たし、個人投資家から機関投資家まで、適切な取引方法を見つけることができます。これにより資金利用率が向上し、市場の成熟を促進します。
マルチノートアトミックセトルメント
上記の例は、1回の決済で1つのNoteのみを対象としていますが、実際には、FusionFiプロトコルは1度に複数のNoteの決済をサポートし、このような決済はアトミックです。1回の決済で全てのNoteが決済されるまで、Noteの状態は変更されません。それ以外の場合、全てのNoteの状態は変更されません。
これにはいくつかの便利な機能がもたらされました：
源：
Permaswapは、FusionFi Protocol上に構築された最初のAgentFi DEXであり、AOエコシステムで最も成熟したDEXでもあります。 興味のある方は、Permaswap(aopsn.com)で上記の機能を体験することができます。
決済センター
明らかに、FusionFi Protocolでは、Settlement Centerは重要なコンポーネントです。それはすべてのノートを時間順に処理し、AOのSUシステムが正常であればその時間順を取得できます。誰でもノートプールからノートを取り出し、Settle Centerに提出して決済することができます。
noteの処理リクエスト量が増加すると、Settlement Centerは分散方式で簡単にスケーリングすることができ、複数の決済プロセスによって決済タスクを分散処理することもできます。どれだけのプレッシャーがあるかは、noteのIDに基づいて異なる決済プロセスにタスクを分散処理することによって決定されます。
Noteの多様なアプリ
FusionFiプロトコルで定義されたNoteの構造化形式は、実際には様々な金融取引に非常に汎用的です。そのため、Noteの適用方法は多岐にわたります。現物取引の見積もり、先物取引、先物取引、借り入れなどのシーンに使用できます。そのため、FusionFiが統合できるのは流動性だけでなく、様々な金融形態も含まれます。
見通し
筆者によれば、このインターネットの世界の本質は、マルチポイント取引であり、したがって、複数のグループ間の高頻度取引を解決することは非常に価値があります。AgentFiのモデルはほぼすべてのDeFiシーンをカバーでき、FusionFiプロトコルはエージェント間のピアツーピアのマッチングをより効率的に行うことができます。また、このようなマッチングはプロトコルを越えて行われます。DeFi領域では、流動性の獲得を主要な競合戦略とし、利益の獲得方法として流動性の独占が行われていますが、FusionFiプロトコルによる変化は画期的です！
もちろん、FusionFi Protocolは新しいプロトコルの標準であり、ビジネスの要件に応じて継続的に調整と最適化が必要かもしれません。これは、BIP（Bitcoin Improvement Proposal）ビットコイン改善提案とEIP（Ethereum Improvement Proposals）イーサリアム改善提案のモデルを参考にし、共創によってアイデアを取り入れることができます。