قد لا تتمحور المرحلة التالية من التداول اللامركزي حول بناء بورصة أخرى. ربما تتمحور حول بناء بنية تحتية تربط بين البورصات ومصادر السيولة والتطبيقات.
مقدمة
لسنوات طويلة، كانت البورصات اللامركزية في قلب التمويل اللامركزي.
كان على المستخدم توصيل محفظته، واختيار رمزين، وتأكيد معاملة، ثم استلام الأصل الذي كان يرغب فيه. كانت الفكرة بسيطة: كان الـDEX هو السوق.
لكن التمويل اللامركزي غيّر كل شيء.
اليوم، يمكن أن توجد السيولة عبر عدة DEXs، وصنّاع الأسواق الآليين، ومزوّدي السيولة المعتمدين على RFQ، وبشكل متزايد، عبر أنظمة بيئية مختلفة لسلاسل الكتل. ومع نمو عدد مصادر السيولة، لم يعد تشغيل DEX هو التحدي الوحيد.
سؤال جديد يزداد أهمية:
كيف يمكن للتطبيقات الوصول إلى المشهد الأوسع للسيولة دون بناء كل هذه البنية التحتية بأنفسها؟
وهنا تصبح فكرة طبقة التنفيذ مثيرة للاهتمام.
كان الـ DEX مجرد البداية
لدى AMM التقليدي دور واضح نسبيًا.
يحافظ على مجمعات السيولة ويتيح للمستخدمين التداول معها وفق آلية التسعير الخاصة بها.
يبقى هذا النموذج أساسياً في DeFi.
لكن تخيل تطبيقًا يريد تزويد المستخدمين بأفضل تنفيذ متاح.
قد يبني تكاملات مع كل DEX على حدة.
يمكنه الحفاظ على نظام التوجيه الخاص به.
يمكنه مراقبة السيولة باستمرار.
يمكنه التعامل مع تنسيقات عروض مختلفة وآليات تنفيذ مختلفة.
أو يمكنه الاتصال ببنية تحتية تقوم بالفعل بتجميع تلك المصادر.
المقاربة الأخيرة هي المكان الذي تزداد فيه أهمية تجميع السيولة.
تغيّر التجميع البنية
إن مجمّع السيولة لا يستبدل بالضرورة البورصات الأساسية.
بدلًا من ذلك، يمكنه أن يعمل كطبقة تنسيق بين التطبيقات ومصادر السيولة.
وفقًا لوثائق STON.fi الحالية، صُمم Omniston كبروتوكول لا مركزي لتجميع السيولة لـ TON، لربط التطبيقات بعدة DEXs ومحلّلات RFQ. يصف التدفق الموثق أن التطبيق يرسل طلب swap إلى Omniston، والذي بدوره يحصل على عروض أسعار (quotes) من مصادر السيولة قبل اختيار مسار التنفيذ.
وهذا يخلق بنية مختلفة:
المستخدم → التطبيق → طبقة التجميع → مصادر السيولة → التنفيذ
بدلًا من ذلك:
المستخدم → DEX واحد
قد تصبح هذه الفروق أكثر أهمية مع تزايد ترابط أنظمة التمويل اللامركزي (DeFi).
لماذا يهتم المطورون بهذه الأمور
بالنسبة لتطبيق DeFi، لا تكون السيولة مفيدة إلا إذا تمكن المستخدمون من الوصول إليها.
لذلك يتعين على المطورين التفكير في مشكلتين منفصلتين:
السيولة
من أين يمكن للتطبيق الحصول على عروض أسعار تنافسية؟
التنفيذ
كيف يمكن تحويل هذه العروض فعليًا إلى عملية Swap مكتملة؟
إن حل الأمرين بشكل مستقل قد يخلق تعقيدًا تقنيًا كبيرًا.
تحاول بنية التجميع إخفاء جزء من هذا التعقيد بعيدًا عن المستخدم.
تصف STON.fi Omniston بأنه يوفر نقطة تكامل واحدة للتطبيقات التي تسعى للوصول إلى مصادر سيولة متعددة.
تطور Omniston يستحق المتابعة
هنا تصبح قصة STON مثيرة للاهتمام بشكل خاص.
ركز Omniston في البداية على تجميع السيولة داخل TON. لكن المواد الحالية من STON.fi تصف اتجاهًا أوسع، مع تطوير قدرات عبر السلاسل، كما يتم وضع Omniston بشكل متزايد كـ بنية تحتية للتنفيذ وليس مجرد أداة توجيه.
ذكرت STON.fi أيضًا أن Omniston أصبح نظام التوجيه الافتراضي داخل dApp الخاص بها، حيث يوفر سيولة من عدة DEXs.
يعكس هذا التطور نمطًا أوسع عبر DeFi:
DEX → مجمّع → بنية تحتية للتنفيذ
تحاول كل مرحلة إخفاء المزيد من التعقيد عن المستخدم والمطور.
أهمية سيولة نمط RFQ
من الأجزاء المثيرة للاهتمام في بنية Omniston استخدام مُحلّلي طلب-من-أجل-عرض (RFQ) إلى جانب سيولة DEX.
تتعلق المسألة بهذا: لا يتعين أن تأتي السيولة اللامركزية حصريًا من مسابح AMM التقليدية.
يمكن لنموذج RFQ أن يسمح لمزوّد سيولة أو مُحلِّل (resolver) بالرد على طلب تجارة محدد بعرض سعر.
تسمح البنية المعمارية الموثقة لـ Omniston بأن تأتي العروض من كلٍّ من DEXs والمحُحلّين قبل اختيار مسار تنفيذ.
وهذا يخلق سوقًا أوسع للسيولة بدلًا من حصر التنفيذ في نوع واحد من مصادر السيولة.
وماذا عن الأمان؟
يخلق التجميع سؤالًا مهمًا آخر:
ماذا يحدث إذا ساءت الأمور أثناء التنفيذ؟
تصف وثائق STON.fi عمليات تبادل Omniston بأنها تعمل بنمط «ثقة معدومة»، مع تضمين خاصية الذرّية وقابلية الاسترداد (refundability) في تصميم البروتوكول. كما تصف الوثائق عقود الحبس زمنية التجزئة (HTLCs) في بنية التبادل ذات الصلة.
تلك الآليات مهمة لأن التنفيذ عبر أطراف متعددة يتطلب أن يكون لدى المشاركين شروط واضحة يتحدد بموجبها ما إذا كانت الصفقة ستكتمل أو تنحل (unwind).
ومع ذلك، مثل أي بروتوكول لا مركزي، فإن البنية لا تلغي كل المخاطر.
ما زالت العقود الذكية ومزوّدو السيولة والمحلّلون وظروف الشبكة وتفاصيل التنفيذ مهمة.
تكون هذه الفروقات مهمة عند تقييم أي بنية تحتية لـ DeFi.
أطروحة البنية التحتية غير المرئية
قد تكون أكثر أجزاء هذا التطور إثارة للاهتمام هي أن المستخدمين لا يحتاجون بالضرورة إلى معرفة أن ذلك موجود أصلًا.
قد يكتفي المستخدم بفتح تطبيق والنقر على "Swap".
وراء هذا الإجراء البسيط قد يكون:
مصادر سيولة متعددة
طلبات العروض (quotes)
اختيار المسار
منطق التسوية
العقود الذكية
معاملات الشبكة
كلما تحسنت البنية التحتية، قلَّ هذا التعقيد الذي يتعين على المستخدم رؤيته.
غالبًا ما يعمل هذا مع التكنولوجيا الناضجة.
لا يختفي التعقيد.
ينتقل تحت واجهة الاستخدام.
ما الذي يأتي بعد ذلك؟
إذا واصلت DeFi التحرك نحو بيئة متعددة السلاسل، فقد تزداد أهمية بنية تنفيذية.
قد لا ترغب التطبيقات في الحفاظ على عشرات التكاملات الفردية.
قد يرغب مزوّدو السيولة في الوصول إلى مزيد من التطبيقات.
قد يرغب المستخدمون في تنفيذ تنافسي دون الحاجة إلى مقارنة الأسواق يدويًا.
وقد تتنافس البروتوكولات بشكل متزايد على جودة البنية التحتية التي تربط هذه المجموعات الثلاثة.
لذلك تستحق تطورات أنظمة مثل Omniston الاهتمام—ليس فقط لأن بروتوكولًا واحدًا بعينه، بل لأنه يوضح إلى أين قد تتجه البنية التحتية للتداول اللامركزي.
أفكار أخيرة
كانت البورصة اللامركزية من بين الابتكارات الأساسية الأولى في DeFi.
لكن قد تبدو الجيل التالي مختلفًا.
بدلًا من أن يتفاعل كل تطبيق بشكل مستقل مع كل مصدر سيولة، يمكن لطبقات تنفيذ متخصصة أن تعمل كنوع من البنية التحتية الرابطة فيما بينها.
يُعد Omniston من STON.fi مثالًا واحدًا على هذا النموذج، حيث يجمع بين تجميع السيولة ومصادر سيولة من DEX وRFQ، ويتجه نحو قدرات تنفيذ أوسع.
ليس السؤال المهم ما إذا كانت المجمّعات ستستبدل DEXs أم لا.
على الأرجح لن يحدث ذلك.
الاحتمال الأكثر إثارة للاهتمام هو أن تصبح DEXs مصادر سيولة ضمن منظومة تنفيذ أوسع بكثير.
وإذا حدث ذلك، فقد تصبح أهم بنية تحتية في DeFi هي الجزء الذي لا يراه المستخدمون على الإطلاق.