إن نقل الأصول بين شبكات البلوك تشين أكثر تعقيدًا من مبادلة رمزين على الشبكة نفسها. فلكل بلوك تشين سجلها الخاص، وتنفذ معاملاتها الخاصة، وتتبع قواعدها الخاصة.
ونتيجة لذلك، لا تُتم المعاملة على إحدى الشبكات تلقائيًا معاملةً مقابلة على شبكة أخرى.
هذه هي المشكلة التي تهدف بنية التنفيذ العابرة للسلاسل إلى حلها.
تعالج STON.fi هذا التحدي من خلال Omniston، وهي طبقة تنفيذ عابرة للسلاسل مصممة لتنسيق تبادل الأصول عبر شبكات البلوك تشين المدعومة.
بدلًا من مطالبة المستخدمين بتنسيق معاملات منفصلة يدويًا، تجمع Omniston بين اكتشاف عروض الأسعار ومزودي السيولة وتنفيذ المعاملات وتسويتها ضمن عملية منسقة.
يساعد فهم كيفية عمل هذه المكونات معًا على توضيح فوائد المبادلات عبر الشبكات ومخاطرها.
1. طلب عرض سعر: العثور على مسار قابل للتنفيذ
تبدأ العملية عندما يحدد المستخدم أصل المصدر وأصل الوجهة والمبلغ المراد مبادلته.
على سبيل المثال، لنتصور مستخدمًا يريد مبادلة USDT على TON بـ USDG على Robinhood Chain.
يطلب التطبيق عرض سعر للمعاملة المقصودة.
تستخدم Omniston آلية طلب عرض سعر (RFQ) للحصول على عروض قابلة للتنفيذ من مزودي السيولة المشاركين، المعروفين باسم المُحلِّلين.
يقيّم هؤلاء المُحلِّلون المبادلة المطلوبة، وقد يقدمون عروض أسعار بناءً على السيولة المتاحة لديهم والتسعير وشروط التنفيذ.
يمكن للمستخدم بعد ذلك مراجعة العروض المتاحة عبر التطبيق.
تكتسب هذه النقطة أهميتها لأن السعر المعروض مرتبط باقتراح قابل للتنفيذ، لا بمجرد سعر سوق إرشادي.
تعتمد عروض الأسعار والمسارات المتاحة على المُحلِّلين المشاركين والأصول المدعومة وظروف السوق الحالية.
2. منافسة المُحلِّلين: توفير سيولة الوجهة
المُحلِّلون مزودو سيولة مستقلون يتنافسون على تنفيذ طلبات المبادلة المؤهلة.
يحدد كل مُحلِّل السعر والشروط التي يمكنه تقديمها بناءً على عوامل مثل مخزونه وتكاليفه التشغيلية وزوج الأصول المطلوب. وفي المعاملة عبر الشبكات، يمكن للمُحلِّل توفير أصول جهة الوجهة اللازمة لتنفيذ الطلب.
وهذا يعني أن التطبيق ليس مضطرًا بالضرورة إلى الاحتفاظ بمخزون خاص به من كل أصل مدعوم على كل سلسلة كتل.
بل يمكن للمُحلِّلين المشاركين توفير سيولة الوجهة عند توفر طلب مناسب.
قد تحسن المنافسة بين المُحلِّلين التسعير وخيارات التنفيذ، مع أن أفضل عرض متاح يعتمد على عروض الأسعار التي تُستلم فعليًا.
قد لا يتوفر المسار أيضًا إذا لم يكن هناك أي مُحلِّل مستعد أو قادر على تنفيذه وفق شروط مقبولة.
3. تنسيق التنفيذ: ربط المعاملات عبر الشبكات
العثور على عرض سعر ليس سوى جزء من العملية. إذ يجب أيضًا تنفيذ المعاملة عبر شبكتي المصدر والوجهة.
تصف STON.fi بنية Omniston للتسوية عبر الشبكات باستخدام عقود مؤقتة مقفلة ومترابطة قائمة على التجزئة (HTLCs).
آلية HTLC هي آلية عقد ذكي تجمع بين شرط تشفيري وحد زمني.
بعبارات مبسطة، تحدد العقود الشروط التي يمكن بموجبها للأطراف المطالبة بأصولهم كلٌّ على حدة.
في عملية مبادلة مدعومة عبر الشبكات، قد تتضمن العملية عقدين مترابطين:
- عقد على جهة المصدر مرتبط بأصل المستخدم.
- عقد على جهة الوجهة مرتبط بأصل المُحلِّل.
يستخدم العقدان شرط تجزئة تشفيريًا مشتركًا وحدودًا زمنية متوافقة.
يربط ذلك جانبي المبادلة من دون اشتراط مشاركة سلاسل الكتل في دفتر أستاذ واحد.
تُنفِّذ العقود شروط التسوية المحددة على الشبكات الخاصة بها.
والتمييز المهم هو أن Omniston ينسق المبادلة، بينما تفرض معاملات سلسلة الكتل الأساسية والعقود الذكية شروط التنفيذ والتسوية ذات الصلة.
4. التسوية الذرية: ماذا يحدث عند اكتمال المبادلة؟
تُعد التسوية الذرية عنصرًا محوريًا في تصميم Omniston الموصوف للتعامل عبر الشبكات.
في هذا السياق، تعني الذرية أن المبادلة منظّمة وفق شروط مترابطة، بحيث يكتمل نقل الأصل المقصود على كلا الجانبين، أو تصبح الأصول المقفلة ذات الصلة قابلة للاسترداد.
تستخدم العملية سرًا تشفيريًا تُضمَّن تجزئته في العقود المترابطة.
عند الكشف عن السر المطلوب واستيفاء الشروط التعاقدية، يصبح بالإمكان تقديم المطالبات المقابلة.
يمكن للمستخدم المطالبة بأصل الوجهة، بينما يستطيع المُحلِّل استخدام السر المُعلَن للمطالبة بأصل المصدر.
يربط الشرط التشفيري المشترك بين المطالبتين.
إذا لم يُستوفَ شرط التسوية المطلوب ضمن المهلة الزمنية المعنية، تتيح العقود مسارًا لاسترداد الأموال وفقًا لقواعدها.
يهدف هذا التصميم إلى الحد من مخاطر أن يسلّم أحد طرفي المبادلة أصولًا من دون أن يتلقى الأصل المقابل المتفق عليه.
لكن لا ينبغي تفسير التسوية الذرية على أنها ضمان ضد جميع الخسائر المحتملة. فما تزال ثغرات العقود الذكية وأخطاء التنفيذ وانقطاعات الشبكة والمخاطر التقنية الأخرى عوامل مؤثرة.
ينبغي للمستخدمين فهم التنفيذ الفعلي للبروتوكول وحالة المعاملة، بدلًا من الاعتماد على كلمة «ذرية» وحدها.
5. مثال عملي: USDT على TON مقابل USDG على Robinhood Chain
لنفترض مستخدمًا يملك USDT على TON ويريد الحصول على USDG على Robinhood Chain.
يوضح سير العمل المقصود كيفية تكامل المكونات المختلفة.
الخطوة 1: اختيار الأصول.
يختار المستخدم USDT على TON كأصل مصدر وUSDG على Robinhood Chain كأصل وجهة، بشرط أن يكون المسار المحدد متاحًا في التطبيق المباشر.
الخطوة 2: طلب عرض سعر.
يطلب التطبيق عرضًا قابلًا للتنفيذ للأصول والمبلغ المحددين.
الخطوة 3: مراجعة العرض.
يراجع المستخدم المبلغ المتوقع استلامه والرسوم المطبقة وشروط التنفيذ قبل التصريح بالمعاملة.
الخطوة 4: تنسيق التنفيذ.
إذا تابع المستخدم وقُبل المسار، تنسق عملية التنفيذ المعنية جانبي المصدر والوجهة وفق آلية التسوية الخاصة بالبروتوكول.
الخطوة 5: الإكمال أو الاسترداد.
إذا تمت تسوية المبادلة بنجاح، يتلقى المستخدم أصل الوجهة وفق الشروط المتفق عليها. وإذا لم يكتمل التنفيذ، تحدد آلية الاسترداد المعمول بها في البروتوكول كيفية استعادة الأصول المقفلة.
يعتمد سير العمل الدقيق على المسار المحدد وطريقة التنفيذ.
مثال المبادلة من USDT إلى USDG توضيحي؛ ينبغي للمستخدمين التحقق من توفر زوج الأصول المحدد حاليًا في واجهة STON.fi المباشرة قبل محاولة المبادلة.
6. أهمية هذه البنية
يفصل نهج Omniston بين عدة مسؤوليات تتولاها غالبًا أنظمة مختلفة.
يساعد اكتشاف عروض الأسعار على تحديد عروض التنفيذ المتاحة.
تُدخل منافسة المُحلِّلين مزودي السيولة في العملية.
يربط تنسيق التنفيذ بين جانبي المصدر والوجهة للمعاملة.
وتفرض تسوية العقود الذكية الشروط التي يمكن بموجبها المطالبة بالأصول أو استردادها.
يمكن أن يؤدي الجمع بين هذه الوظائف إلى تبسيط تجربة المستخدمين وتقليل حاجة التطبيقات إلى إنشاء بنية تحتية منفصلة لكل مسار مدعوم.
وقد يساعد ذلك أيضًا الجهات المدمجة على تقديم وظائف عبر الشبكات من دون الاحتفاظ بشكل مستقل بسيولة على جهة الوجهة لكل معاملة.
تعتمد الفائدة على دعم المسار فعليًا ومشاركة المُحلِّلين وموثوقية العقود الأساسية.
7. المخاطر والقيود
رغم تصميم Omniston لتنسيق التنفيذ عبر الشبكات، ينبغي للمستخدمين فهم المخاطر.
السيولة والتسعير: لا تضمن منافسة المُحلِّلين الحصول على أفضل سعر سوق ممكن في كل الحالات. وتعتمد العروض المتاحة على مزودي الخدمة المشاركين وظروف السوق الحالية.
توفر المسار: ليس بالضرورة أن يكون كل زوج من الأصول أو كل تركيبة من الشبكات مدعومًا. وقد لا يتوفر مسار عند عدم كفاية السيولة أو القدرة على التنفيذ.
مخاطر العقود الذكية: يمكن للعقود المترابطة الحد من بعض مخاطر التسوية، لكنها لا تلغي الثغرات أو إخفاقات التنفيذ.
ظروف الشبكة: قد يؤثر الازدحام والانقطاعات وتأخر المعاملات في التنفيذ والوقت اللازم لمعالجة المبادلة غير المكتملة.
شروط عرض السعر: ينبغي للمستخدمين مراجعة عرض السعر الفعلي والرسوم وشروط التنفيذ المطبقة قبل التوقيع.
شروط الاسترداد: يعتمد استرداد الأموال على قواعد العقد والمهل الزمنية وحالة المعاملة.
ينبغي للمستخدمين فهم هذه الشروط بدلًا من افتراض أن كل إخفاق يؤدي إلى استرداد فوري.
يُعد فهم هذه القيود أمرًا ضروريًا عند تقييم أي نظام للتنفيذ عبر الشبكات.
تنسق Omniston المبادلات عبر الشبكات من خلال الجمع بين اكتشاف عروض الأسعار والسيولة التي يوفرها المُحلِّلون وتنسيق التنفيذ وتسوية العقود الذكية.
تتيح آلية RFQ الخاصة بها للمُحلِّلين المشاركين تقديم عروض قابلة للتنفيذ. وتستخدم بنيتها عبر الشبكات عقود HTLC مترابطة لوضع شروط التسوية أو الاسترداد على الشبكات المشاركة. والهدف للمستخدمين واضح: مبادلة أصل على سلسلة كتل مدعومة بأصل على سلسلة أخرى من دون تنسيق كل عملية أساسية يدويًا. أما للمطورين، فتوفر هذه البنية وسيلة لدمج التنفيذ عبر الشبكات من دون بناء كل مكون من مكونات التوجيه والتسوية بشكل مستقل.
والدرس الأوسع هو أن البنية التحتية العابرة للشبكات تتطلب أكثر من مجرد نقل الرموز بين الشبكات. فهي تستلزم تنسيق السيولة والتسعير وتنفيذ المعاملات وشروط الاسترداد عبر أنظمة تعمل بشكل مستقل.
استكشف المزيد على: https://ston.fi/cross-chain-swap-from-ton-to-base
ابحث في الآلية.
تحقق من المسار.
افهم المخاطر قبل إجراء المعاملة.
المصادر الرسمية:
«نظرة عامة على التنفيذ عبر الشبكات» من Omniston (https://ston.fi/omniston)
«الوثائق التقنية لـ Omniston» من STON.fi (https://docs.ston.fi/developer-section/omniston)
«شرح التنفيذ عبر الشبكات» من STON.fi (https://blog.ston.fi/omniston-explained-how-cross-chain-swaps-on-ton-work-without-a-bridge/)