前回のまとめ:
AgentFi - AOを活用したDeFiの新しいコンセプト
前回に引き続き。ブロックチェーン業界全体は、拡張の進化の歴史です。高速化と費用削減のため、さまざまなルートが試されていますが、それぞれに限界があります。それがAOです。伝統的なブロックチェーンとは異なるパラダイムで、AOが登場しました。巧妙な設計により、AO上のブロックスペースはもはや固定供給の希少品ではなく、必要に応じて無限に生成できるリソースとなり、AOに無限の拡張能力を与えました!
これにより、エージェント向けの金融モデルであるAgentFiが可能になりました。従来の分散型金融と比較して、AgentFiはより幅広い利用シーンを持っています。
従来の分散型金融プロトコルはETH坊から発展してきましたが、さまざまなL2および高性能な新しいパブリックチェーンが登場しているにもかかわらず、分散型金融の構築パラダイムに関する人々の想像力は常にETH坊に制限されていました。今、私たちはパフォーマンス制限のないプラットフォームに足を踏み入れてみましょう。それはまるでインターネットが読み取り専用から読み書き可能、そしてアルゴリズム、自律性へと進化していった一連の発展のようです。オンチェーン金融の姿を新たに想像してみると、どのような新たな光景が思い浮かぶでしょうか?ユーザー全員が金融エージェントを作成し、どんな計算ユニットも「金融機関」となり、カスタム金融サービスを提供する金融の力が均等に広がる光景です!
なぜエージェントの標準プロトコルが必要なのですか?
AOコンピュータ上では、プロセス間の通信はメッセージを介して行われ、メッセージの送受信は一定の規則に従います。実際、金融の場面でも同様です。
カスタマイズは多様化の出発点であり、異なる種類の金融エージェントが独自に発展しなければならない場合、異なるプロトコル規格が生じる可能性があるため、エージェント間の相互作用が大きな問題となります。どのようにしてエージェント同士が相互通信し、相互にマッチングすることができるようにするか、ということです。01928374656574839201
統一された規範の欠如による相互運用性の欠如を防ぐために、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)を提供し、開発者がより効率的かつ簡単に AgentFi を作成できるよう支援しています。
現在、FusionFi Protocol には AMM エージェント、Orderbook エージェントの2種類のインスタンスがあります。
AMM エージェント
AMMエージェントを例に取ると、各AMMエージェントは「個人主権」の流動性プールと見なすことができ、この流動性プールのメイキングルールは自己設定できます。これは、ユーザーが統一メイキングアルゴリズムを採用した資金プールのような外部プラットフォームに依存する必要がないため、自律的にswap機能を実現し、任意の適切な対抗者をネット全体で探すことができることを意味します。つまり、ユーザーがエージェントを作成するとき、実際には個人の分散型取引所を作成していることになります。FusionFiプロトコルは、多数のこのような「個人取引所」をピアツーピアネットワークとして組み合わせ、より効率的かつ柔軟なマッチングを実現することができます。
以下は、AMM エージェントのコア プロセスです。
見た目は簡単ですが、LPにとっては、作成して入金し、追加して交換して引き出すという一般的な手順です。ただし、Agentはユーザー自身によって制御されるため、LPにとっては資産が自分の手元にあるという違いがあります。これはAgentFi自体の能力であり、FusionFiはこの機能に対応するために、比較的統一されたエントリーポイント(およびデータ構造)を提供します。
あなたは、LPとして、預入と引き出しの操作のみを行う必要があり、統一されたエントリ関数を呼び出すだけです。関数自体は、複数の分散型金融プロジェクトにリンクすることができますが、その後の相互作用や役割については気にする必要はありません。これがプロトコルレイヤの価値です。 ERC20などの標準が存在することで、アプリケーションレイヤがユーザーに適応するのと同様です。
以下は流動性を追加するための具体的なコード例です。
見ることができます、わずか数行のコアコードで機能を迅速に実現できます。
const minLiquidity = await agent.getMinLiquidityByX(helloAmount, ammSlippageOfPercent) // 金額とスリッページを設定します
const addLiquidityMessageId = await agent.addLiquidity(minLiquidity)//流動性を追加するメッセージを開始します
const addLiquidityResult = await getProcessResult(addLiquidityMessageId, ammProcess)//結果を取得する
ソースコードの例:
ノートのライフサイクル
ここでは、Noteの視点に切り替えて、ユーザーとAMMエージェントの取引プロセスを確認できます。
ユーザーがお問合せリクエストを発行すると、対応する流動性を持つすべてのAMMエージェントが自動的に見積もりを作成します。この見積もりはノートであり、その有効期間は非常に短く、迅速に取引が成立しない場合、ノートは無効になります。AMMエージェントはメーカーに相当します。
すべてのNoteは、システムのNote Poolに集中的に保存され、Note Poolは共有ストレージスペースを担い、他のエンティティがアクセスするのに便利です。
ユーザーはフロントエンドウェブページからNote Poolから最適な見積もりNoteを選択し、決済センターに提出します。決済センターは具体的な決済操作、例えばここでのスワップを実行する責任があります。
注意事項:「已決済」にマークされた場合、スワップは正常に実行されました。
ここでは、Settlement CenterはFusionFi Protocolの重要なコンポーネントであり、システム内のさまざまなNote決済操作を処理する責任があります。
実際には、注文薄エージェントについても同じです。注文薄エージェントの指値注文自体がノートであり、その決済プロセスはAMMエージェントが作成する価格提供エージェントと完全に一致しています。これは、FusionFiプロトコルが実際にはAMMと注文薄からの流動性を融合できることを意味します。
このような統合により、スワップシナリオでは、流動性はユーザーの引用からもノード作成からも得ることができます。そしてユーザーは、ルーティングプロトコルを利用して全体のノードプールで流動性を探し、最適な取引価格を実現することができます。AMMは市場に基本的な流動性を提供しますが、価格インパクトが大きく、変動損失の問題があります。一方、オーダーブックはユーザーが自己のメーカーとなり、大口取引や特定の価格要求を持つユーザーに適しています。統合後、AMMは持続的な流動性を提供し、オーダーブックは価格インパクトを減少させ、デプスを増加させ、大量注文取引をより効率的にします。このモデルは異なるタイプのユーザーのニーズを満たし、個人投資家から機関投資家まで、適切な取引方法を見つけることができ、資金利用率を向上させ、市場をさらに成熟させることができます。
マルチノートアトミック決済
上記の例は、1つのノートのみを決済する場合に限定されていますが、実際には、FusionFi Protocolは複数のノートを一度に決済することもサポートしており、この決済はアトミックです。すべてのノートが一度の決済で完了するまで、ノートの状態を変更することはできません。それ以外の場合、すべてのノートの状態は変更されません。
これにはいくつかの便利な機能が付属しています:
大口取引の分割:大口の注文は単一の対戦相手による一括注文が難しいため、FFPは大口注文を分割することをサポートし、分散した流動性を最大限に活用することができます。
複数の取引を1つの合成注文に統合することができます。これは取引速度を向上させる一定の効果があり、高頻度取引者や複雑な取引シーンにとって、このような効率向上は非常に重要です。
マルチホップトランザクション:マルチホップトランザクションは、合成機能の拡張です。例えば、スワップシナリオでA→Cの交換を完了する必要がありますが、直接のA→Cのパスは存在せず、A→B→Cのパスが存在する場合、FFPはA→B、B→Cのトランザクションの合成を実現できます。また、このようなマルチホップトランザクションはアトミックであり、A→Bが成功し、B→Cが失敗するという状況はありません。
ゼロ資金アービトラージ:つまり、いわゆる空手套白狼です。実質的には、アービトラージャーが利差を持つ2つのノートを同時に決済することです。以下の図をご覧ください。
源:
Permaswapは、FusionFi Protocolに基づいて構築されたAgentFi DEXであり、AOエコシステムで現在最も成熟しているDEXでもあります。興味がある方は、Permaswap(aopsn.com)で上記の特性を体験することができます。
決済センター
明らかに、FusionFi Protocolでは、決済センターは重要なコンポーネントです。それはすべてのノートを時間の順序で処理し、AOのSUシステムが正常である限り、その時間の順序を取得することができます。誰でもノートプールからノートを取り出して、決済センターに提出することができます。
noteの処理リクエスト量が増加すると、決済センターは分散型の方法で簡単に拡張することができます。複数の決済プロセスによって決済タスクが分散処理されます。ノートのIDに基づいて、どれだけの負荷があるかに応じて、異なる決済プロセスに分散して処理されます。
Noteの多様なアプリケーション
FusionFi Protocol で定義された Note の構造化形式は、実際にはさまざまな金融取引に非常に普遍的に適用されます。そのため、Note の応用方法はさまざまです。現物取引の見積もりだけでなく、先物取引、先物取引、融資などのシーンにも使用できます。したがって、FusionFi が統合できるのは流動性だけでなく、さまざまな金融形態もあります。
見通し
筆者にとって、このインターネットの世界の本質は、マルチポイント取引であると言えます。したがって、複数のグループ間の高頻度取引を解決することは非常に価値があります。AgentFiのモデルは、ほぼすべてのDeFiシーンをカバーできます。一方、FusionFiプロトコルは、エージェント間のピアツーピアのマッチングをより効率的に行うことができ、しかもそのマッチングはプロトコルをまたいで行われます。DeFi領域では、流動性を獲得することが主要な競争手段としており、流動性の独占を利益の手段とするモデルに対し、FusionFiプロトコルがもたらす変革は画期的です!
当然、FusionFi Protocol は新しい標準プロトコルであり、ビジネス要件に応じて継続的に調整および最適化が必要かもしれません。これは、BIP(ビットコイン改善提案)およびEIP(Ethereum Improvement Proposals)のモデルを参考にし、共同で創造的なアイデアを取り入れることができます。
参照:
スマートファイナンス:AgentFiからFusionFiへ
FusionFiプロトコル:AgentFiの相互運用性を実現するためのコアエレメント
FusionFiプロトコルドキュメント
プロトコル紹介.md
この記事はPermaDAOで最初に発表されました。
原文リンク: