المصدر: PermaDAO
يستمر الكتاب من الفصل السابق. إن صناعة البلوكتشين بأكملها عبارة عن تاريخ تطوري من التوسع، حيث يتم تجربة طرق مختلفة من أجل زيادة السرعة وخفض الرسوم، ولكن لكل منها حدودها الخاصة. حتى ظهور AO، ظهر نموذج مختلف عن blockchain التقليدي. من خلال التصميم الذكي، لم تعد مساحة الكتلة في AO مصدرًا ثابتًا للندرة، ولكنها مورد يمكن إنشاؤه بلا حدود حسب الحاجة، مما يمنح AO القدرة على التوسع بلا حدود!
وهذا أيضًا يجعل AgentFi ممكنًا، وهو نموذج مالي موجه للوكيل. وبالمقارنة مع DeFi التقليدي، فإن AgentFi لديه نطاق أوسع من سيناريوهات التطبيق.
نشأ بروتوكول DeFi التقليدي من Ethereum على الرغم من ظهور العديد من السلاسل العامة الجديدة عالية الأداء وL2، إلا أن خيال الناس لنموذج بناء DeFi كان دائمًا يقتصر على Ethereum. الآن، دعونا نسير في منصة بدون قيود على الأداء، تمامًا مثل تذكر عملية تطوير الإنترنت من القراءة فقط، إلى القراءة والكتابة، إلى الخوارزمية، إلى الاستقلالية، وإعادة تصور الشكل الذي يجب أن يبدو عليه التمويل عبر السلسلة هل ستظهر صورة جديدة في ذهنك؟ رؤية للمساواة المالية حيث يمكن لجميع المستخدمين إنشاء وكلاء ماليين، ويمكن لأي وحدة حاسوبية أن تصبح "مؤسسة مالية" وتقدم خدمات مالية مخصصة!
لماذا هناك حاجة إلى بروتوكول قياسي للوكيل؟
على كمبيوتر AO، تتواصل العمليات من خلال الرسائل، ويتبع تمرير الرسائل مواصفات معينة. وفي الواقع، ينطبق الأمر نفسه على المشهد المالي.
يعد التخصيص نقطة البداية للتنويع إذا تطورت أنواع مختلفة من الوكلاء الماليين من تلقاء أنفسهم، فسوف تنشأ حتماً مواصفات بروتوكول مختلفة. وبهذه الطريقة، سيصبح التفاعل بين الوكلاء مشكلة رئيسية. المشكلة هي كيفية تمكين الوكلاء من التواصل مع بعضهم البعض ثم مطابقة بعضهم البعض؟
من أجل تجنب نقص قابلية التشغيل البيني الناجم عن عدم وجود مواصفات موحدة، ظهر بروتوكول FusionFi (FFP).
يحدد بروتوكول FusionFi، باعتباره بروتوكول تفاعل بين الوكلاء، قواعد التفاعل بين الوكلاء، مما يسمح لمختلف الخدمات المالية التي تم إنشاؤها بناءً على الوكلاء بالتواصل مع بعضهم البعض ثم التكامل. في الوقت الذي كانت فيه AgentFi قد بدأت للتو، يمكن القول أن مثل هذه الاتفاقية كانت تطلعية تمامًا.
FFP (بروتوكول FusionFi)
بروتوكول FusionFi هو بروتوكول أطلقه مؤسس EverVision outprog في مؤتمر Arweave Asia لعام 2024.
المفهوم الأساسي في بروتوكول FusionFi هو الملاحظة. إنه نموذج تمثيل مجرد للالتزام، والذي يمكن أن يكون في شكل رموز، أو سندات، أو شهادات، أو حقوق تعاقدية، وما إلى ذلك. باستخدام نموذج Note كوسيط، يمكن أن يدعم FusionFi Protocol مجموعة متنوعة من السيناريوهات المالية، مثل التداول والإقراض والرهن وما إلى ذلك.
لا يوفر بروتوكول FusionFi مواصفات البروتوكول فحسب، بل يوفر أيضًا للمطورين مجموعة من أدوات تطوير AgentFi (FFP SDK) لمساعدة المطورين على إنشاء AgentFi بشكل أكثر كفاءة وبساطة.
في الوقت الحالي، يحتوي بروتوكول FusionFi بالفعل على مثيلين: وكيل AMM ووكيل Orderbook.
وكيل AMM
بأخذ وكيل AMM كمثال، يمكن فهم كل وكيل AMM على أنه مجمع سيولة "للسيادة الشخصية". يمكن ضبط قواعد تجمع الجنس بنفسك. وهذا يعني أيضًا أن المستخدمين لا يحتاجون إلى الاعتماد على منصات خارجية مثل مجمع رأس المال باستخدام خوارزمية صنع السوق الموحدة، ولكن يمكنهم تنفيذ وظيفة المبادلة بشكل مستقل والعثور على أي طرف مقابل مناسب في الشبكة بأكملها. بمعنى آخر، عندما يقوم المستخدم بإنشاء وكيل، فهو في الواقع يقوم بإنشاء تبادل لامركزي شخصي. ثم يمكن أن يسمح بروتوكول FusionFi للعديد من "التبادلات الشخصية" بتكوين شبكة نظير إلى نظير لتحقيق مطابقة أكثر كفاءة ومرونة.
ما يلي هو العملية الأساسية لعامل AMM:
انظر، يبدو الأمر بسيطًا للغاية، في الواقع، بالنسبة لـ LP، يبدو أنها عملية قياسية للإنشاء والإيداع والإضافة والتبادل والسحب الأصول في أيديهم. هذه في الواقع هي قدرة AgentFi نفسها، ويقوم FusionFi بإنشاء مدخل موحد نسبيًا (وبنية بيانات) لهذه المجموعة من الإمكانات.
يمكنك أن تفهم أنه باعتبارك LP، كل ما تحتاج إلى إكماله هو عمليات الإيداع والسحب، ويمكنك الاتصال بوظيفة الإدخال الموحد. يمكن ربط الوظيفة نفسها بمشاريع DeFi متعددة، ويمكنك تجاهل كيفية تفاعلها وعملها في المستقبل. هذه هي قيمة طبقة البروتوكول القياسية. تمامًا كما هو الحال مع ظهور معايير مثل ERC20، تتكيف طبقة التطبيق مع المستخدمين.
ما يلي هو مثال رمزي محدد لإضافة السيولة.
كما ترون، يمكن تنفيذ هذه الوظيفة بسرعة باستخدام بضعة أسطر فقط من التعليمات البرمجية الأساسية.
const minLiquidity = await agent.getMinLiquidityByX(helloAmount, ammSlippage OfPercent)// تعيين الكمية والانزلاق const addLiquidityMessageId = await agent.addLiquidity(minLiquidity)// بدء رسالة لإضافة السيولة const addLiquidityResult = await getProcessResult(addLiquidityMessageId, ammProcess)//الحصول على النتائج
مصدر حالة استخدام الكود:
https://github.com/permadao/ffp-demo ص>
ملاحظة دورة الحياة
هنا يمكننا التبديل إلى منظور Note وإلقاء نظرة على عملية المعاملة بين المستخدم ووكيل AMM.
1. عندما يبدأ المستخدم طلب استعلام، سيقوم جميع وكلاء AMM الذين لديهم سيولة مقابلة بإنشاء عرض أسعار تلقائيًا. فترة صلاحية هذه الملاحظة قصيرة جدًا إذا لم يكن من الممكن تنفيذها بسرعة بمجرد اكتمال المعاملة، ستصبح الملاحظة غير صالحة. وكلاء AMM يعادلون الصناع.
2. سيتم تخزين كافة الملاحظات مركزيًا في مجموعة ملاحظات النظام. تعمل مجموعة الملاحظات كمساحة تخزين مشتركة في النظام لتسهيل الوصول إليها من قبل الكيانات الأخرى.
3. يقوم المستخدم باختيار مذكرة الاقتباس الأكثر ملائمة من مجموعة الملاحظات من خلال صفحة الويب الأمامية وإرسالها إلى مركز التسوية للتسوية. مركز التسوية مسؤول عن تنفيذ عمليات تسوية محددة، مثل المبادلة هنا.
4. تم وضع علامة "تمت التسوية" على الملاحظة وتم تنفيذ المبادلة بنجاح.
هنا، يعد مركز التسوية مكونًا رئيسيًا في بروتوكول FusionFi وهو مسؤول عن التعامل مع عمليات تسوية الملاحظات المختلفة في النظام.
في الواقع، ينطبق الأمر نفسه على وكيل Orderbook. إن الأمر المحدد في وكيل Orderbook نفسه عبارة عن مذكرة، وعملية التسوية الخاصة به هي تمامًا نفس وكيل عرض الأسعار الذي أنشأه وكيل AMM. وهذا يعني أن بروتوكول FusionFi يمكنه بالفعل دمج السيولة من AMMs ودفاتر الطلبات.
يجلب هذا التكامل فوائد عظيمة في سيناريو المبادلة، يمكن أن تأتي السيولة من عروض أسعار المستخدم أو عقد صنع السوق. يمكن للمستخدمين استخدام بروتوكول التوجيه للعثور على السيولة في مجموعة الملاحظات بأكملها وتحقيق أفضل سعر للمعاملة. توفر AMM السيولة الأساسية للسوق، ولكنها تواجه مشكلة التأثير الكبير على الأسعار والخسائر غير الدائمة، بينما يسمح دفتر الطلبات للمستخدمين بتقديم الطلبات بشكل مستقل، وهو مناسب للمعاملات الكبيرة والمستخدمين ذوي الاحتياجات السعرية المحددة. عند دمجها، توفر AMM سيولة مستمرة بينما يقلل دفتر الطلبات من تأثير السعر ويزيد من العمق، مما يجعل التداولات الكبيرة أكثر كفاءة. يلبي هذا النموذج احتياجات أنواع مختلفة من المستخدمين، بدءًا من مستثمري التجزئة وحتى المؤسسات، الذين يمكنهم العثور على طرق تداول مناسبة، وبالتالي تحسين استخدام الأموال وتعزيز المزيد من نضج السوق.
التسوية الذرية لنوتة متعددة
تقتصر الحالة المذكورة أعلاه على تسوية ملاحظة واحدة في كل مرة، ولكن في الواقع، يمكن لبروتوكول FusionFi أيضًا دعم تسوية النوتة الواحدة. ملاحظات متعددة في وقت واحد، وهذه التسوية ذرية. لا يمكن تغيير حالة الملاحظة حتى تتم تسوية جميع الملاحظات في تسوية واحدة. وإلا فلن يتم تغيير حالة كافة الملاحظات.
يجلب هذا بعض الميزات المفيدة جدًا:
تقسيم المعاملات الكبيرة: تكون الطلبات الكبيرة صعبة إذا تم أخذ الطلبات بواسطة طرف مقابل واحد، يدعم FFP تقسيم الطلبات الكبيرة لتحقيق الاستفادة الكاملة من السيولة المشتتة.
يمكن دمج المعاملات المتعددة في ترتيب ذري واحد. يمكن أن يؤدي ذلك إلى تحسين سرعة المعاملات إلى حد ما بالنسبة للمتداولين ذوي التردد العالي وسيناريوهات التداول المعقدة، يعد تحسين الكفاءة أمرًا بالغ الأهمية.
التداول متعدد القفزات: التداول متعدد القفزات هو امتداد لوظيفة تجميع الأوامر. افترض أنه في سيناريو المبادلة، يجب إكمال استبدال A→C، ولكن لا يوجد مسار مباشر من A→C، ولكن هناك مسار من A→B→C FFP يمكنه تحقيق مجموعة A→B و ب → ج. علاوة على ذلك، فإن هذه المعاملة متعددة القفزات ذرية، ولن يكون هناك موقف ينجح فيه A → B ويفشل B → C.
المراجحة ذات رأس المال الصفري: هذا ما يسمى بالذئب خالي الوفاض. الجوهر هو أن المراجح يقوم بتسوية ورقتين بأسعار فائدة في نفس الوقت. يمكنك رؤية الصورة أدناه.
مصدر الصورة: https://x.com/Permaswap/status/1854212032511512992
Permaswap هو أول AgentFi DEX مبني على بروتوكول FusionFi، وهو أيضًا الأكثر نضجًا النظام البيئي AO حاليًا. يمكن لأي شخص مهتم تجربة الميزات المذكورة أعلاه على Permaswap (aopsn.com).
مركز التسوية
من الواضح أن مركز التسوية هو مكون رئيسي في بروتوكول FusionFi. سيقوم بمعالجة جميع الملاحظات بناءً على الترتيب الزمني وطالما أن نظام SU الخاص بـ AO طبيعي، فيمكن الحصول على الترتيب الزمني. يمكن لأي شخص استخراج الملاحظات من مجموعة الملاحظات وإرسالها إلى مركز التسوية للتسوية.
عندما يزيد حجم طلبات معالجة الملاحظات، يمكن أيضًا توسيع مركز التسوية بسهولة بطريقة موزعة، باستخدام عمليات تسوية متعددة لتفريغ مهام التسوية. يتم حساب مقدار الضغط الموجود بناءً على معرف الملاحظة ويتم تقسيمه إلى عمليات تسوية مختلفة للمعالجة.
تطبيقات متنوعة للملاحظة
< p>يتمتع التنسيق المنظم للملاحظة التي يحددها بروتوكول FusionFi بقابلية تطبيق عالمية قوية جدًا على العديد من الشركات المالية. ولذلك، يمكن استخدام الملاحظة بطرق مختلفة. لا يمكن استخدامه فقط للتعبير عن عروض الأسعار للمعاملات الفورية، ولكن يمكن استخدامه أيضًا في تداول العقود الآجلة وتداول العقود والإقراض والسيناريوهات الأخرى. لذلك، لا يمكن لـ FusionFi دمج السيولة فحسب، بل أيضًا الأشكال المالية المختلفة.
التوقعات
يرى المؤلف أن عالم الإنترنت هو في الأساس معاملة متعددة النقاط، لذا فإن حل المعاملات عالية التردد بين مجموعات متعددة هو أمر له ذات قيمة عالية، ويمكن استخدام نموذج AgentFi في جميع سيناريوهات DeFi تقريبًا، ويمكن أن يسمح بروتوكول FusionFi للوكلاء بإجراء مطابقة من نقطة إلى نقطة بشكل أكثر كفاءة، وهذه المطابقة عبارة عن بروتوكول مشترك. في مواجهة نموذج تكون فيه المنافسة على السيولة هي الطريقة الرئيسية للمنافسة في مجال التمويل اللامركزي واحتكار السيولة هو طريقة الربح، فإن التغييرات التي يمكن أن يجلبها بروتوكول FusionFi مدمرة!
بالطبع، يعد FusionFi Protocol معيارًا جديدًا للبروتوكول وقد يحتاج إلى تعديله وتحسينه باستمرار بناءً على احتياجات العمل. يمكن أن يشير هذا إلى نماذج BIP (اقتراح تحسين البيتكوين) وEIP (اقتراح تحسين الإيثريوم) لاستيعاب الإبداع في الإنشاء المشترك.