بروتوكول FusionFi: يربط بين جميع وسطاء المالية

مراجعة الجزء السابق:

《AgentFi - مفهوم جديد يقوده AO في التمويل اللامركزي 》

متابعة الجزء السابق. صناعة البلوكتشين بأكملها هي تاريخ توسعي، حيث يحاول جميع الطرق تسريع السرعة وتقليل التكلفة، لكن كلها تواجه حدودها الخاصة. حتى ظهرت AO، وهي نمط مختلف تمامًا عن البلوكتشين التقليدي. من خلال تصميمها الماهر، أصبحت مساحة الكتل في AO ليست بعد الآن سلعة نادرة ذات إمدادات ثابتة، بل هي مورد يمكن إنشاؤه بلا حدود حسب الحاجة، مما يمنح AO قدرة توسع لا محدودة!

هذا يجعل نمط التمويل الموجه نحو الوكيل - AgentFi ممكنًا ، وبالمقارنة مع التمويل اللامركزي التقليدي ، يتمتع AgentFi بمجموعة أوسع من سيناريوهات التطبيق.

التمويل اللامركزي التقليدي ينشأ من بروتوكول إيثيريوم، على الرغم من ظهور مجموعة متنوعة من السلاسل الجديدة L2 وعالية الأداء، إلا أن خيال الناس بشأن البنية التحتية للتمويل اللامركزي ما زال مقتصرًا دائمًا على إيثيريوم. الآن، دعونا ندخل إلى منصة لا تقيّد الأداء على الإطلاق، تمامًا كما في تطور الإنترنت من القراءة فقط إلى القراءة والكتابة، والخوارزمية، وحتى الاستقلالية، دعونا نتصوّر من جديد كيف يجب أن تبدو الخدمات المالية داخل السلسلة، هل سيظهر صورة جديدة تمامًا في عقولنا؟ صورة حيث يمكن لجميع المستخدمين إنشاء وكلاء ماليين، وحيث يمكن لأي وحدة حساب أن تصبح “المؤسسة المالية” وتقدم مشهدًا متساويًا للخدمات المالية المخصصة!

لماذا نحتاج إلى بروتوكول معياري للوكلاء؟

في الحاسوب AO ، يتم التواصل بين العمليات من خلال الرسائل ، ويتبع توصيل الرسائل معايير معينة. في الواقع ، هذا هو الحال أيضًا في السياق المالي.

التخصيص هو نقطة الانطلاق المتعددة ، إذا كانت وكلاء الأموال من أنواع مختلفة تتطور بشكل مستقل ، فسوف تنتج معايير بروتوكول مختلفة. وبالتالي ، يصبح تفاعل الوكلاء مشكلة كبيرة. كيف يمكن للوكلاء التواصل مع بعضهم البعض ومن ثم التوسط بينهم؟

ولتجنب فقدان التوافق الوظيفي الذي ينشأ عن عدم وجود معايير موحدة، تم إطلاق بروتوكول FusionFi (FFP).

بروتوكول FusionFi كبروتوكول تفاعلي بين الوكلاء ، يحدد قواعد التفاعل بين الوكلاء ، مما يتيح التواصل بين مختلف الأعمال المالية التي تم إنشاؤها على أساس الوكلاء وتدمجها في جميع الأعمال المالية. في وقت بدء AgentFi ، يمكن القول إن هذا البروتوكول لديه رؤية واعدة.

بروتوكول FusionFi (FFP)

بروتوكول FusionFi هو بروتوكول تم إطلاقه من قبل مؤسس EverVision outprog في مؤتمر Arweave Asia لعام 2024.

بروتوكول FusionFi يعتمد على مفهوم مهم وهو ملاحظة (Note). إنه تمثيل مجرد للتعهدات، ويمكن أن يكون بشكل عملة، سند ديني، إيصال، أو حقوق عقدية وغيرها. باستخدام نموذج الملاحظة كوسيلة، يمكن لبروتوكول FusionFi دعم سيناريوهات مالية متنوعة مثل التداول، الاقتراض، والتكديس.

بروتوكول FusionFi لا يوفر فقط مواصفات بروتوكول واحدة، بل يوفر أيضًا أدوات تطوير AgentFi (FFP SDK) للمطورين، مما يساعد المطورين على إنشاء AgentFi بشكل أكثر كفاءة وبساطة.

حالياً، لدى بروتوكول FusionFi بالفعل نوعان من الوكلاء: وكيل AMM ووكيل Orderbook.

وكيل AMM

على سبيل المثال ، يمكن فهم وكيل AMM كبركة سيولة ذات سيادة فردية ، حيث يمكن تعيين قواعد صنع السوق لهذه البركة. هذا يعني أيضًا أن المستخدم لا يحتاج إلى الاعتماد على منصة خارجية مثل بركة أموال تستخدم خوارزمية صنع السوق الموحدة ، بل يمكنه تنفيذ وظيفة السواب بشكل مستقل ، والبحث في الشبكة العالمية عن أي طرف مناسب. بمعنى آخر ، عند إنشاء وكيل ، فإنه في الواقع يتم إنشاء تبادل اللامركزية الخاص بالفرد. ثم يمكن لبروتوكول FusionFi أن يجعل العديد من مثل هذه الوكلاء الفردية تشكل شبكة نقطية لتحقيق التوافق الأكثر كفاءة ومرونة.

هذه هي العمليات الأساسية لوكيل AMM:

تبدو بسيطة ، ولكن بالنسبة ل LP ، يبدو أن العملية القياسية هي إنشاء إيداع ثم إضافة وصرف السحب ، لكن الفارق هو أن الوكيل يتم التحكم فيه بواسطة المستخدم نفسه ، بالنسبة ل LP ، فإن الأصول في يديه. هذه في الواقع قدرة AgentFi نفسها ، بينما FusionFi تستهدف هذه القدرة من أجل إنشاء مدخل موحد نسبيًا (وهيكل بيانات).

يمكن أن تفهم أنك ، بصفتك LP ، تحتاج فقط إلى إجراء عمليات الإيداع والسحب ، واستدعاء وظيفة الوصول الموحدة. يمكن أن يكون الدالة نفسها مرتبطة بعدة مشاريع تمويل لامركزي ، ولا يهم كيف يتفاعلون فيما بعد أو كيف يعملون ، وهذا هو قيمة الطبقة القياسية للبروتوكول. على سبيل المثال ، بمجرد وجود معايير مثل ERC20 ، يتم تكييف التطبيق للمستخدم.

هنا هو مثال على الكود المحدد لإضافة السيولة.

يمكن رؤيته، فقط بضعة أسطر من الشفرة الأساسية يمكن أن تحقق هذه الوظيفة بسرعة.

const minLiquidity = انتظر agent.getMinLiquidityByX (helloAmount ، ammSlippageOfPercent) // قم بتعيين المبلغ والانزلاق السعري

const addLiquidityMessageId = انتظر agent.addLiquidity(minLiquidity)//بدء رسالة لإضافة السيولة

const addLiquidityResult = await getProcessResult(addLiquidityMessageId, ammProcess)//Get the result

مصدر الحالة الاختبارية للشيفرة:

مذكرة دورة حياة

هنا يمكننا التبديل إلى منظور الملاحظة وإلقاء نظرة على عملية تنفيذ المستخدم ووكيل AMM.

1. عندما يقوم المستخدم بطلب استفسار، سيقوم جميع وكلاء السيولة المتاحة تلقائيًا بإنشاء عرض سعر واحد، وهذا العرض هو ملاحظة واحدة فقط، ومدة صلاحية هذه الملاحظة قصيرة للغاية، إذا لم يتم التداول بسرعة، فإن الملاحظة ستصبح غير صالحة. وكلاء السيولة يعتبرون صانعي السوق.

2. سيتم تخزين جميع الملاحظات في حوض الملاحظات الخاص بالنظام ، ويعمل حوض الملاحظات كمساحة تخزين مشتركة في النظام لتسهيل وصول الكيانات الأخرى.

3. يقوم المستخدم بتحديد عرض السعر الأنسب من مجموعة الحواضن وتقديمه إلى مركز التسوية للتسوية. يقوم مركز التسوية بتنفيذ عمليات التسوية الفعلية مثل هذا التبادل.

4. تم تنفيذ Swap بنجاح بعلامة ‘تم تسوية’.

هنا، مركز التسوية هو مكون رئيسي في بروتوكول FusionFi ويتحمل مسؤولية معالجة جميع عمليات التسوية في النظام.

في الواقع ، ينطبق الأمر نفسه على وكيل كتاب الطلبات ، حيث يعد الأمر المحدود في وكيل كتاب الطلبات نفسه ملاحظة ، ويكون عملية تسوية هذه الملاحظة متطابقة تمامًا مع وكيل العرض الذي أنشأه وكيل AMM. هذا يعني أن بروتوكول FusionFi يمكنه فعلا دمج السيولة من AMM وكتاب الطلبات.

جلب هذا التكامل فوائد كبيرة. في سيناريو تبادل السيولة، يمكن أن تكون السيولة من عروض المستخدمين أو من عقد السوق. يمكن للمستخدمين استخدام بروتوكول التوجيه للبحث عن السيولة في جميع حوض العروض وتحقيق أفضل سعر تنفيذ. يوفر AMM السيولة الأساسية للسوق، ولكنه يعاني من مشاكل تأثير السعر الكبير والخسارة المؤقتة. يسمح دفتر الطلبات للمستخدمين بأن يكونوا مستقلين ومناسبين للمعاملات الكبيرة وللمستخدمين الذين لديهم متطلبات سعر محددة. بعد التكامل، يوفر AMM سيولة مستمرة، بينما يقلل دفتر الطلبات من تأثير السعر ويزيد من العمق، مما يجعل تداول الطلبات الكبيرة أكثر كفاءة. هذا النمط يلبي احتياجات مستخدمين مختلفين، بدءاً من مستثمر التجزئة إلى المؤسسات، ويعزز استخدام رأس المال ويعزز نضج السوق بشكل أكبر.

التسوية المذكورة في ملاحظة متعددة

الأمثلة أعلاه محدودة فقط بتسوية ملاحظة واحدة في كل مرة، ولكن في الواقع، بروتوكول FusionFi يدعم تسوية ملاحظات متعددة في نفس الوقت، وهذه التسوية هي ذات طابع ذري. يجب أن يتم تسوية جميع الملاحظات في العملية الواحدة حتى يمكن تغيير حالة الملاحظة. وإلا فلن يتم تغيير حالة أي ملاحظة.

جلب هذا بعض الميزات المفيدة جدًا:

تجزئة الصفقات الكبيرة: تصعب تنفيذ الطلبات الكبيرة من قبل طرف واحد فقط، يدعم FFP تجزئة الطلبات الكبيرة والاستفادة الكاملة من السيولة المتنوعة.

تجميع عدة صفقات في طلب واحد: يمكن دمج عدة صفقات في طلب واحد ذو صفقة واحدة. يمكن أن يعزز هذا إلى حد ما سرعة التداول ، وهو أمر حاسم للمتداولين عالي التردد والسيناريوهات التداول المعقدة.

التداول العديد من القفزات: التداول العديد من القفزات هو تمديد لوظيفة الدمج. على سبيل المثال، في سيناريو السواب، إذا كان يتعين تنفيذ تبديل A→C، ولكن لا يوجد مسار مباشر من A→C، ولكن هناك مسار A→B→C، يمكن لـ FFP تحقيق دمج A→B و B→C. والأهم أن هذا التبادل المتعدد القفزات يكون ذو طابع ذري، ولا يوجد حالة حيث ينجح A→B ويفشل B→C.

المراجحة: هي ما يسمى بالذئب الأبيض الخالية من المال. في الواقع ، يقوم المحكم بأخذ مذكرتين مع اختلاف في الفائدة لتسوية الأمرين في نفس الوقت. يمكنك الاطلاع على الصورة أدناه.

مصدر الصورة:

Permaswap هو أول DEX مبني على بروتوكول FusionFi ، وهو أيضًا أكثر DEX نضجًا في البيئة البيولوجية AO حاليًا. يمكن للجميع تجربة هذه الميزات على Permaswap (aopsn.com).

مركز التسوية

من الواضح أن مركز التسوية هو مكون رئيسي في بروتوكول FusionFi. سيتم معالجة جميع الملاحظات بناءً على ترتيب الوقت، بشرط أن يكون نظام SU AO سليمًا، يمكن الوصول إلى هذا الترتيب الزمني. يمكن لأي شخص سحب ملاحظة من حوض الملاحظات وتقديمها إلى مركز التسوية للتسوية.

عندما يتم توسيع كمية طلبات المعالجة مع ملاحظة، يمكن أيضًا لمركز التسوية بسهولة زيادة القدرة بشكل موزع من خلال عدة عمليات تسوية لتوجيه مهام التسوية إلى قدر الضغط، وذلك بناءً على تحليل معرف الملاحظة.

تطبيقات متعددة لملاحظة

تنسيق محدد لـ Note المحدد بواسطة بروتوكول FusionFi ، والذي في الواقع لديه تطبيق عام قوي لمختلف الأعمال المالية. لذلك ، هناك العديد من طرق استخدام Note. يمكن استخدامها لتمثيل عروض أسعار التداول الفوري ، بالإضافة إلى تداول العقود الآجلة والعقود والإقراض ومشاهد أخرى. لذلك ، يمكن أن يدمج FusionFi ليس فقط السيولة ولكن أيضًا أشكال مالية متنوعة.

رؤية

في رأي الكاتب، فإن العالم عبر الإنترنت في جوهره متعدد النقاط، لذلك حل المعاملات المتكررة بين مجموعات متعددة لديه قيمة كبيرة، ويمكن أن يقوم نمط AgentFi بتغطية تقريبًا جميع سيناريوهات التمويل اللامركزي، بينما يمكن لـ FusionFi Protocol تمكين Agents من إجراء عمليات التوافق بين النقاط بشكل أكثر كفاءة وهذا التوافق هو عبر البروتوكول. في مواجهة المنافسة الرئيسية للتمويل اللامركزي في مجال السيولة ونمط الاحتكار كنمط للربح، فإن التغيير الذي يمكن أن يجلبه بروتوكول FusionFi هو مدمر!

بالطبع ، FusionFi Protocol هو معيار بروتوكول جديد تمامًا ، ومن المحتمل أن يتطلب التعديل والتحسين المستمر وفقًا لاحتياجات العمل. يمكن الاستشهاد بنمط BIP (اقتراح تحسين بيتكوين) ونمط EIP (اقتراحات تحسين ايثيريوم) للاستيعاب الإبداعي في عملية الشراكة.

مراجعة المواد:

1. التمويل الذكي: من AgentFi إلى FusionFi

2. بروتوكول FusionFi: العنصر الأساسي لتحقيق توافق AgentFi

3. بروتوكول FusionFi الوثائق

بروتوكول介绍.md

تم نشر هذا المقال لأول مرة في PermaDAO

رابط المقالة: