前回の続きです。

全体のブロックチェーン業界は、スケーラビリティの進化の歴史です。コスト削減とスピード向上のためにさまざまなルートが試みられていますが、それぞれに限界があります。そんな中、AOという伝統的なブロックチェーンとは異なるパラダイムが登場しました。巧妙な設計により、AO上のブロックスペースは固定供給の希少品ではなく、必要に応じて無限に創出できるリソースとなり、AOに無限のスケーラビリティを与えました！

これにより、エージェント向けの金融モデルであるAgentFiが可能になりました。従来のDeFiと比較して、AgentFiはより広範な応用シーンを持っています。

従来のDeFiプロトコルはイーサリアムに起源を持ち、さまざまなL2や高性能の新しいブロックチェーンが誕生しましたが、人々のDeFi構築のパラダイムに対する想像力は常にイーサリアムに限られていました。今、性能制限のないプラットフォームに足を踏み入れ、インターネットが読み取り専用から書き込み可能、アルゴリズム、自主的な発展へと進化した一連の過程を思い出し、ブロックチェーン上の金融がどのようなものであるべきかを再想像してみましょう。全てのユーザーが金融エージェントを作成でき、あらゆる計算ユニットが「金融機関」となり、カスタマイズされた金融サービスを提供する金融の平等な景観が思い浮かぶのではないでしょうか？

なぜエージェントの標準プロトコルが必要なのか？

AOコンピュータ上では、プロセス間でメッセージを通じて通信が行われ、メッセージの送信は一定の規範に従います。実際、金融シーンでも同様です。

カスタマイズは多様性の出発点です。異なる種類の金融エージェントが独自に発展すると、異なるプロトコル規範が生じ、エージェント間の相互作用が大きな課題となります。エージェント同士が相互に通信し、相互にマッチングできるようにするにはどうすればよいのでしょうか？

統一された規範の欠如による相互運用性の欠如を避けるために、FusionFi Protocol（FFP）が誕生しました。

FusionFi Protocolはエージェント間の相互作用プロトコルとして、エージェント間の相互作用ルールを定義し、エージェントに基づいて作成されたさまざまな金融業務が相互に通信できるようにし、一体化します。AgentFiが始まったばかりの時点で、このようなプロトコルは非常に先見の明があると言えます。

FFP（FusionFi Protocol）

FusionFi Protocolは、EverVisionの創設者outprogが2024年のArweave Asia大会で発表したプロトコルです。

FusionFi Protocolの重要な概念はNote（ノート）です。これは約束の抽象的な表現モデルであり、その形式はトークン、債券、証明書、契約権利などです。Noteモデルを媒介として利用することで、FusionFi Protocolは取引、貸付、担保などの豊富な金融シーンをサポートできます。

FusionFi Protocolは単なるプロトコル規範を提供するだけでなく、開発者にAgentFiの開発ツール（FFP SDK）を提供し、開発者がより効率的かつ簡単にAgentFiを作成できるようにします。

現在、FusionFi ProtocolにはAMMエージェントとオーダーブックエージェントの2つのインスタンスがあります。

AMMエージェント

AMMエージェントを例に見てみましょう。各AMMエージェントは「個人主権」の流動性プールと理解できます。この流動性プールのマーケットメイキングルールは自由に設定できます。つまり、ユーザーは統一されたマーケットメイキングアルゴリズムを採用した外部プラットフォームに依存せずに、独自にスワップ機能を実現し、全ネットワークで任意の適切な対戦相手を探すことができます。言い換えれば、ユーザーがエージェントを作成する際、実際には個人の分散型取引所を作成しているのです。そして、FusionFi Protocolは多くのこのような「個人取引所」をピアツーピアネットワークとして構成し、より効率的で柔軟なマッチングを実現します。

以下はAMMエージェントの核心プロセスです：

| STEP | 説明 | |---------------|------------------------------------------------------------------------| | 1. AMMエージェントの作成 | createAMMAgentメソッドを呼び出してエージェントを作成します。エージェントはAOプロセスとして存在し、スマートコントラクトとは異なり、ユーザーの制御下にあります。 | | 2. 資産の預け入れ | ユーザーはトークンをAMMエージェントに預け入れ、流動性を提供する準備をします。 | | 3. 流動性の追加 | agent.addLiquidityメソッドを呼び出して、一定量の資産を流動性プールに追加します。 | | 4. 自動交換 | AMMエージェントはアルゴリズム（例えば、一定の積の公式）を使用して自動的に交換価格を計算し、マーケットメイキングルールを自由に設定できます。 | | 5. 流動性の削除 | ユーザーが資金を引き出す必要がある場合、agent.removeLiquidityメソッドを使用して流動性を削除できます。 |

見た目は簡単ですが、LPにとっては、標準的な作成、預け入れ、追加、交換、引き出しのプロセスのように見えます。ただし、エージェントはユーザー自身の制御下にあるため、LPにとっては資産が自分の手元にあります。これは実際にAgentFi自体の能力であり、FusionFiはこの能力に対して、比較的一元的な入口（およびデータ構造）を構築しています。

LPとして理解できるのは、あなたが完了すべきことは預け入れと引き出しの操作だけであり、統一された入口関数を呼び出すだけです。そして、その関数自体は複数のDeFiプロジェクトとリンクすることができます。以降、彼らがどのように相互作用し、どのように機能するかは気にする必要がありません。これがプロトコル標準の価値です。ERC20などの標準ができた後、アプリケーション層がユーザーに適応するのと同じように。

以下は流動性を追加するための具体的なコード例です。

数行のコアコードでこの機能を迅速に実現できることがわかります。 >

`const minLiquidity = await agent.getMinLiquidityByX(helloAmount, ammSlippageOfPercent)//数量とスリッページを設定
const addLiquidityMessageId = await agent.addLiquidity(minLiquidity)//流動性追加のメッセージを発信
const addLiquidityResult = await getProcessResult(addLiquidityMessageId, ammProcess)//結果を取得
`

コード例の出典：https://github.com/permadao/ffp-demo

Noteのライフサイクル

ここではNoteの視点に切り替え、ユーザーとAMMエージェントの取引プロセスを見てみましょう。

1. ユーザーが価格照会リクエストを発信すると、すべての相応の流動性を持つAMMエージェントが自動的に見積もりを作成します。この見積もりはNoteであり、その有効期限は非常に短いです。迅速に成立しなければ、Noteは無効になります。AMMエージェントはまさにメイカーです。
2. すべてのNoteはシステムのNoteプールに集中して保存され、Noteプールはシステム内で共有ストレージスペースの役割を果たし、他のエンティティがアクセスしやすくなります。
3. ユーザーはフロントエンドのウェブページからNoteプールの中で最も適切な見積もりNoteを選択し、Settlement Centerに提出して決済を行います。Settlement Centerは具体的な決済操作を実行する責任があります。例えば、ここでのスワップです。
4. Noteは「決済済み」とマークされ、スワップが成功裏に実行されます。

ここで、Settlement CenterはFusionFi Protocolの重要なコンポーネントであり、システム内のさまざまなNoteの決済操作を処理する責任があります。

実際、Orderbookエージェントについても同様です。Orderbookエージェントの指値注文自体がNoteであり、その決済プロセスはAMMエージェントが作成した見積もりエージェントと完全に一致します。つまり、FusionFi Protocolは実際にAMMとオーダーブックからの流動性を統合することができます。

このような統合は大きな利点をもたらします。スワップシーンでは、流動性はユーザーの見積もりからも、マーケットメイキングノードからも得られます。ユーザーはルーティングプロトコルを利用してNoteプール全体から流動性を探し、最適な取引価格を実現できます。AMMは市場に基礎的な流動性を提供しますが、価格への影響が大きく、無常損失の問題があります。一方、オーダーブックはユーザーが自主的に注文を出すことを許可し、大口取引や特定の価格要求のあるユーザーに適しています。統合後、AMMは持続的な流動性を提供し、オーダーブックは価格への影響を減少させ、深さを増し、大口取引をより効率的にします。このモデルは、個人投資家から機関投資家まで、さまざまなタイプのユーザーのニーズを満たし、資金の利用率を向上させ、市場のさらなる成熟を促進します。

複数Noteの原子決済

上記のケースは一度に1つのNoteのみを決済するものでしたが、実際にはFusionFi Protocolは一度に複数のNoteを決済することをサポートし、その決済は原子性を持っています。単一の決済内のすべてのNoteが決済を完了しなければ、Noteの状態を変更することはできません。そうでなければ、すべてのNoteの状態は変更されません。

これにより、いくつかの非常に有用な特性がもたらされます：

• 大口取引の分割：大口注文は単一の対戦相手に処理されることが難しいため、FFPは大口注文を分割し、分散された流動性を最大限に活用することをサポートします。
• 複数取引の統合：複数の取引を1つの原子注文に統合できます。これにより、取引速度が向上し、高頻度取引者や複雑な取引シーンにとって、この効率の向上は非常に重要です。
• 複数ホップ取引：複数ホップ取引は統合機能の拡張です。スワップシーンでA→Cの置換を完了する必要があるとしますが、A→Cの直接的な経路は存在しないが、A→B→Cの経路が存在する場合、FFPはA→B、B→Cの統合を実現できます。このような複数ホップ取引は原子性を持ち、A→Bが成功し、B→Cが失敗するという状況は発生しません。
• ゼロ資金アービトラージ：いわゆる「空手で白狼を捕まえる」ことです。実質的には、アービトラージャーが利差のある2つのNoteを同時に決済に持っていくことです。以下の図を見てください。

図の出典：https://x.com/Permaswap/status/1854212032511512992

PermaswapはFusionFi Protocolに基づいて構築された最初のAgentFi DEXであり、AOエコシステムで最も成熟したDEXです。興味がある方は、Permaswap（aopsn.com）で上記の特性を体験できます。

Settlement Center

明らかに、FusionFi Protocolにおいて、Settlement Centerは重要なコンポーネントです。これは時間順にすべてのNoteを処理し、AOのSUシステムが正常であれば、その時間順を取得できます。誰でもNoteプールからNoteを抽出し、Settlement Centerに提出して決済を行うことができます。

Noteの処理リクエストが増加すると、Settlement Centerは分散型の方法で容易にスケールアップでき、複数の決済プロセスが決済タスクを分流して処理します。どれだけの負荷がかかるかは、NoteのIDに基づいて計算し、異なる決済プロセスに分流して処理します。

Noteの多様な応用

FusionFi Protocolが定義するNoteの構造化フォーマットは、実際にはさまざまな金融業務に非常に強い普遍的適用性を持っています。したがって、Noteの応用方法は多岐にわたります。現物取引の見積もりを表すだけでなく、先物取引、契約取引、貸付などのシーンでも使用できます。したがって、FusionFiが統合できるのは流動性だけでなく、さまざまな金融形態でもあります。

展望

筆者の見解では、このインターネットの世界は本質的に多点取引であり、複数のグループ間の高頻度取引を解決することには非常に高い価値があります。AgentFiのモデルはほぼすべてのDeFiシーンを実現でき、FusionFi Protocolはエージェント間のより効率的なピアツーピアマッチングを可能にし、さらにこのマッチングはプロトコルを超えています。流動性を主要な競争手段とし、流動性を独占することで利益を上げるモデルに直面して、FusionFi Protocolがもたらす変化は破壊的です！

もちろん、FusionFi Protocolは全く新しいプロトコル標準であり、ビジネスニーズに応じて継続的に調整と最適化が必要です。これはBIP（Bitcoin Improvement Proposal）やEIP（Ethereum Improvement Proposals）のモデルを参考にし、共創の中でアイデアを取り入れることができます。

参考資料：

スマート金融：AgentFiからFusionFiへ

https://x.com/perma_daoCN/status/1801474305597050906

FusionFi Protocol: AgentFiの相互運用性を実現するためのコア要素

https://x.com/Permaswap/status/1854212032511512992

FusionFi Protocol ドキュメント

https://github.com/zyjblockchain/ffp-doc/blob/main/doc/FusionFiプロトコル紹介.md