المصدر: PermaDAO
كما هو مذكور في الجزء السابق، فإن صناعة البلوكتشين ككل هي تاريخ تطوري للتوسع، حيث تجري محاولات لتسريع العمليات وتخفيض التكاليف عبر مجموعة متنوعة من الطرق، ولكن كلها تواجه حدودًا معينة. حتى ظهور AO، الذي يعتبر نمطًا مختلفًا تمامًا عن البلوكتشين التقليدي. من خلال تصميم ماهر، أصبحت مساحة الكتلة في AO ليست بعدم الكمية الثابتة النادرة، بل هي مورد يمكن إنشاؤه بلا حدود وفقًا للحاجة، مما يمنح AO القدرة على التوسع بلا حدود!
هذا أيضًا يجعل وضعية التمويل الموجهة نحو الوكلاء - AgentFi - ممكنة، وعند مقارنتها بالتمويل اللامركزي التقليدي، يحظى AgentFi بمجالات تطبيق أكثر انتشارًا.
التمويل اللامركزي التقليدي ينشأ من بروتوكول إثيريوم، على الرغم من ظهور مجموعة متنوعة من L2 وسلاسل الكتل الجديدة عالية الأداء، إلا أن خيال الناس بشأن بناء نموذج التمويل اللامركزي لا يزال مقتصرًا على إثيريوم. الآن، دعونا ندخل منصة بدون حدود في الأداء تمامًا، تمامًا مثل مسار تطور الإنترنت من القراءة فقط إلى القراءة والكتابة والخوارزمية والاستقلالية، ونتخيل مرة أخرى كيف يبدو النظام المالي داخل السلسلة، هل تخطر في ذهننا رؤية جديدة تمامًا؟ رؤية حيث يمكن لجميع المستخدمين إنشاء وكلاء ماليين وحدات حسابية يمكن أن تصبح “المؤسسات المالية” وتقدم خدمات مالية مخصصة لتحقيق المساواة المالية!
لماذا نحتاج إلى بروتوكول معياري للوكلاء؟
في حاسوب AO ، يتم التواصل بين العمليات عن طريق الرسائل ، ويتم اتباع معايير معينة في نقل الرسائل. في الواقع ، يحدث نفس الشيء في سياق المشهد المالي.
التخصيص هو نقطة انطلاق متعددة الأوجه، إذا تم تطوير وكلاء ماليين من أنواع مختلفة بشكل مستقل، فسوف ينتج بالضرورة بروتوكولات مختلفة، وبالتالي يصبح تفاعل الوكلاء بينهما تحديًا كبيرًا، فكيف يمكن جعل الوكلاء يتواصلون مع بعضهم البعض ويتعاونون؟
لتجنب فقدان التوافق الذي ينتج عن عدم وجود معايير موحدة، تم إطلاق بروتوكول FusionFi (FFP).
البروتوكول القاطع بشكل أساسي للتفاعل بين الوكلاء ، ويحدد قواعد التفاعل بين الوكلاء ، مما يتيح التواصل بين مختلف الأعمال المالية التي تم إنشاؤها بناءً على الوكيل ، وبالتالي تدمجها في واحدة. في نقطة البداية لـ AgentFi ، يمكن القول أن مثل هذا البروتوكول هو رؤية مستقبلية.
FFP (بروتوكول FusionFi)
بروتوكول FusionFi هو بروتوكول تم إطلاقه بواسطة مؤسس EverVision outprog في مؤتمر Arweave Asia لعام 2024.
في بروتوكول FusionFi، المفهوم الرئيسي هو ملاحظة (Note). إنه نموذج تمثيل مجرد للالتزامات، ويمكن أن يكون بشكل عملة، سند، إيصال، حقوق عقدية وغيرها. باستخدام نموذج الملاحظة كوسيلة، يمكن لبروتوكول FusionFi دعم مجموعة متنوعة من السيناريوهات المالية مثل التداول، الاقتراض، والتراكم.
يوفر بروتوكول FusionFi للمطورين أدوات تطوير AgentFi (FFP SDK) وهو ليس مجرد مواصفة بروتوكول ولكنه يساعد المطورين على إنشاء AgentFi بشكل أكثر كفاءة وسهولة.
حاليًا ، يحتوي بروتوكول FusionFi على نوعين من العناصر: AMM Agent و Orderbook Agent.
وكيل AMM
على سبيل المثال، يمكن أن يفهم كل وكيل AMM وككيل لسوق السيولة ‘سيادة فردية’، ويمكن تعيين قواعد السوق لهذا السوق بشكل مستقل. وهذا يعني أيضًا أن المستخدمين لا يحتاجون إلى الاعتماد على منصة خارجية مثل بركة أموال تستخدم خوارزمية سوق موحدة، ويمكنهم تنفيذ وظيفة swap بشكل مستقل، والبحث في الشبكة بحثًا عن أي طرف مناسب. وهذا يعني أنه عند إنشاء الوكيل، فإنه في الواقع يقوم بإنشاء ‘تبادل’ الخاص بالفرد. ثم يمكن لبروتوكول FusionFi أن يجعل العديد من هذه ‘التبادلات’ الفردية تشكل شبكة نقطية إلى نقطية، لتحقيق توفيق أكثر كفاءة ومرونة.
وفيما يلي العمليات الأساسية لوكيل AMM:
![]()
تبدو بسيطة ، ولكن بالنسبة لـ LP ، يبدو أنها عملية قياسية لإنشاء الإيداع وإضافته مرة أخرى وعملية التحويل والسحب ، لكن الفرق هو أن الوكيل تحت سيطرة المستخدم نفسه ، وبالنسبة لـ LP ، الأصول في أيديهم. هذه هي بالفعل قدرة AgentFi ، بينما FusionFi تستهدف هذه القدرة وتضع مدخلًا موحدًا نسبيًا (وهيكل البيانات) لذلك.
يمكنك أن تفهم، بأنه بصفتك LP، عليك إكمال عمليات الإيداع والسحب فقط، من خلال استدعاء وظيفة الدخول الموحدة. ويمكن للوظيفة نفسها أن تكون مرتبطة بعدة مشاريع التمويل اللامركزي ، وبالنسبة لكيفية تفاعلها فيما بعد، وكيفية تأثيرها، يمكن تجاهلها، وهذا هو القيمة لطبقة معيار البروتوكول. تشبه الأمر الحصول على معايير مثل ERC20، حيث يأتي طبقة التطبيق لتكييف المستخدم.
هناك أدناه مثال على رمز الإضافة الخاص بالسيولة.
يمكن رؤيتها، مع بضعة أسطر من الشفرة الأساسية يمكن تحقيق هذه الوظيفة بسرعة.
const minLiquidity = انتظر agent.getMinLiquidityByX (helloAmount ، ammSlippageOfPercent) // تعيين المبلغ والانزلاق const addLiquidityMessageId = انتظر agent.addLiquidity (minLiquidity) // بدء رسالة لإضافة السيولة const addLiquidityResult = انتظر getProcessResult(addLiquidityMessageId, ammProcess)//الحصول على النتيجة
مصدر الحالة البرمجية: 01928374656574839201
ملاحظة دورة حياة
هنا يمكننا التبديل إلى وجهة نظر ملاحظة ، ثم نلقي نظرة على عملية التداول بين المستخدم ووكيل AMM.
-
عندما يقوم المستخدم بتقديم طلب استفسار ، سيقوم جميع وكلاء السيولة المتاحة تلقائيًا بإنشاء عرض أسعار وهذا العرض هو ملاحظة ولكن فترة صلاحية هذه الملاحظة قصيرة جدًا، إذا لم يتم الاتفاق بسرعة، ستصبح الملاحظة غير صالحة. يعمل وكلاء السيولة بمثابة الصانعين.
-
سيتم تخزين جميع الملاحظات في بركة الملاحظات في النظام، وتلعب بركة الملاحظات دور مساحة تخزين مشتركة في النظام لتسهيل وصول الكيانات الأخرى.
-
يختار المستخدمون عروض الأسعار الأكثر مناسبة من بركة الملاحظات عبر صفحة الويب الأمامية ويقدمون الملاحظة المختارة إلى مركز التسوية للتسوية. يقوم مركز التسوية بتنفيذ عمليات التسوية الفعلية ، مثل الاستبدال هنا.
-
ملاحظة تم وضع علامة على “تمت التسوية”، تم تنفيذ السواب بنجاح.
هنا، مركز التسوية هو أحد العناصر الرئيسية في بروتوكول FusionFi، ويجب أن يتولى معالجة جميع عمليات التسوية المختلفة داخل النظام.
في الواقع ، بالنسبة لـ Orderbook Agent ، هو نفس الشيء ، إن الطلبات المحدودة في Orderbook Agent هي في حد ذاتها ملاحظة ، وعملية التسوية لهذه الطلبات المحدودة هي مطابقة تمامًا للعملية التي يقوم بها AMM Agent لإنشاء وكيل العروض. وهذا يعني أن بروتوكول FusionFi في الواقع يمكنه دمج السيولة من AMM وسجل الطلبات.
هذا التكامل يجلب فوائد كبيرة. في سيناريو السواب، يمكن أن تكون السيولة من عروض المستخدمين أو من صانعي السوق. يمكن للمستخدمين استخدام بروتوكول التوجيه للبحث عن السيولة في حوض العقود بأكمله وتحقيق أفضل سعر تنفيذ. يوفر AMM السيولة الأساسية للسوق، ولكنه يعاني من مشكلات تأثير السعر الكبير والخسارة المؤقتة. بينما يسمح سجل الأوامر للمستخدمين بالتداول بشكل مستقل، وهو مناسب للمعاملات الكبيرة ومستخدمين لديهم متطلبات سعر محددة. بعد التكامل، يوفر AMM السيولة المستمرة، بينما يقلل سجل الأوامر من تأثير السعر ويزيد من العمق، مما يجعل التداول بالطلبات الضخمة أكثر كفاءة. يلبي هذا النمط احتياجات مستخدمين مختلفين، من المستثمرين التجزئة إلى المؤسسات، ويعزز استخدام رأس المال ويعزز نضج السوق بشكل أكبر.
ملاحظة متعددة تسوية الذرية
الأمثلة أعلاه محدودة بتسوية ملاحظة واحدة فقط، ومع ذلك، فإن بروتوكول FusionFi يدعم أيضًا تسوية مجموعة من الملاحظات في عملية واحدة وهذه التسوية ذات طابع ذري. يجب استكمال تسوية جميع الملاحظات في عملية التسوية الفردية قبل تغيير حالة الملاحظة. وإلا فلن يتم تغيير حالة أي من الملاحظات.
هذا يجلب بعض الميزات المفيدة جدًا:
- تقسيم الصفقات الكبيرة: من الصعب أن تُشترى طلبات كبيرة من طرف واحد، يدعم FFP تقسيم الطلبات الكبيرة والاستفادة الكاملة من السيولة المتناثرة.
- عمليات تداول متعددة يمكن دمجها في طلب واحد: يمكن دمج عمليات التداول المتعددة في طلب واحد ذي طابع ذري. يمكن أن يؤدي ذلك إلى تحسين سرعة التداول بشكل معتبر، وهذا يعد أمرًا حاسمًا بالنسبة للمتداولين التردديين وسيناريوهات التداول المعقدة.
- التداول المتعدد القفزات: التداول المتعدد القفزات هو تمديد لوظيفة الدمج. يفترض أنه في سيناريو سواب ، يجب إجراء استبدال A→C ، ولكن لا يوجد مسار مباشر من A→C ، ولكن هناك مسار A→B→C ، يمكن لـ FFP دمج A→B و B→C. بالإضافة إلى ذلك ، هذا التداول المتعدد القفزات هو ذو طبيعة ذرية ، ولا يوجد حالة حيث ينجح A→B ويفشل B→C.
- المراجحة بدون رأس المال: وهي ما يسمى بـ “الذئب الأبيض الخالي اليدين”. والحقيقة هي أن المحكم يأخذ نوتين لديهما فارق في الفائدة ويسويهما في نفس الوقت. يمكنكم الاطلاع على الصورة أدناه.
![]()
مصدر الصورة:
Permaswap هو أول DEX لعميل Fi الذي يعتمد على بروتوكول FusionFi ، وهو أيضًا أكثر DEX نضجًا في AO البيئية حاليًا. يمكن للجميع تجربة هذه الميزات على Permaswap (aopsn.com).
مركز التسوية
من الواضح أن مركز التسوية هو مكون رئيسي في بروتوكول FusionFi. سيقوم بمعالجة جميع الملاحظات بناءً على ترتيب الوقت في حال كانت نظام الـ SU لـ AO على ما يرام، فيمكن الحصول على ترتيب الوقت هذا. يمكن لأي شخص سحب الملاحظات من بركة الملاحظات وتقديمها إلى مركز التسوية للتسوية.
عند توسيع حجم طلب معالجة الـ note ، يمكن لمركز التسوية أيضًا توسيع القدرة بسهولة عن طريق الطريقة الموزعة ، حيث يتم توجيه مهام التسوية إلى عدة عمليات التسوية لتخفيف الضغط. يتم توجيه الضغط بناءً على هوية الـ note ، حيث يتم توجيهها إلى عمليات التسوية المختلفة للتعامل معها. 01928374656574839201
![]()
تطبيقات متعددة لـ Note
تنسيق بنية ملاحظة المحددة بواسطة بروتوكول FusionFi، لديها تطبيق عام قوي لمختلف الأعمال المالية. لذلك، هناك العديد من طرق استخدام الملاحظة. يمكن استخدامها لتمثيل أوراق العرض للصفقات الفورية، وكذلك لصفقات العقود الآجلة وتداول العقود والاقتراض وما إلى ذلك. بالتالي، يمكن أن يدمج FusionFi ليس فقط السيولة ولكن أيضًا مجموعة متنوعة من أشكال التمويل.
رؤية
في رأي الكاتب، فإن جوهر عالم الإنترنت هذا هو التداول متعدد النقاط، لذا حل مشكلة التداول المتكرر بين عدة مجموعات يحمل قيمة عالية، بينما يمكن لنموذج AgentFi أن يغطي تقريبًا جميع سيناريوهات التمويل اللامركزي، بينما يمكن لبروتوكول FusionFi أن يجعل التطابق بين الوكلاء أكثر كفاءة بشكل كبير، وهذا التطابق هو عابر للبروتوكول. في مواجهة المنافسة في مجال التمويل اللامركزي بالتنافس على السيولة كوسيلة رئيسية للتنافس، ونمط الاحتكار للسيولة كوسيلة ربحية، يمكن أن يحمل تغييرات التي يمكن تقديمها بروتوكول FusionFi تغييرًا جذريًا!
بالطبع، FusionFi Protocol هو معيار بروتوكول جديد تمامًا، وقد يتطلب التعديل والتحسين المستمر وفقًا لاحتياجات الأعمال. يمكن الاستفادة من نموذج BIP (Bitcoin Improvement Proposal) اقتراح تحسين البيتكوين لتكييف مع الإبداع في عملية الشراكة.
إخلاء المسؤولية: قد تكون المعلومات الواردة في هذه الصفحة من مصادر خارجية ولا تمثل آراء أو مواقف Gate. المحتوى المعروض في هذه الصفحة هو لأغراض مرجعية فقط ولا يشكّل أي نصيحة مالية أو استثمارية أو قانونية. لا تضمن Gate دقة أو اكتمال المعلومات، ولا تتحمّل أي مسؤولية عن أي خسائر ناتجة عن استخدام هذه المعلومات. تنطوي الاستثمارات في الأصول الافتراضية على مخاطر عالية وتخضع لتقلبات سعرية كبيرة. قد تخسر كامل رأس المال المستثمر. يرجى فهم المخاطر ذات الصلة فهمًا كاملًا واتخاذ قرارات مدروسة بناءً على وضعك المالي وقدرتك على تحمّل المخاطر. للتفاصيل، يرجى الرجوع إلى
إخلاء المسؤولية.
