كيف يتعامل Omniston مع عمليات التبادل من EVM إلى EVM على STON.fi
غالبًا ما يُقدَّم التداول عبر السلاسل كأنه نقل أصل من بلوكتشين إلى أخرى يجب أن يكون بسيطًا مثل المبادلة بين رمزين على بورصة لامركزية.
في الواقع، قد تكون العملية الأساسية أكثر تعقيدًا بكثير.
تحدث عملية تبادل DEX تقليدية عادةً داخل سلسلة بلوكتشين واحدة. توجد السيولة على تلك الشبكة، ويتم تنفيذ المعاملات بواسطة عقود على نفس دفتر الأستاذ، وتتبع الصفقة بأكملها بيئة التنفيذ لسلسلة واحدة.
يُدخل التداول عبر EVM إلى EVM عبر Ethereum وBNB Chain وBase وPolygon وشبكات أخرى مشكلة مختلفة: الأصول التي يتم تبادلها موجودة على سلاسل بلوكشين منفصلة ولا تشترك في سجل معاملة واحد.
هنا يتبنى STON.fi’s Omniston نهجًا مختلفًا.
بدلًا من إجبار الصفقة عبر تسلسل جسر-ثم-تبديل تقليدي، يعامل Omniston التفاعل كطلب عبر سلاسل. يجمع النظام بين نموذج RFQ (Request for Quote) وسيولة المُحلِّلين المتنافسة وHTLCs (Hashed Timelock Contracts) المزدوجة لتنسيق التسوية عبر شبكات EVM مستقلة.
تكون النتيجة تجربة للمستخدم تبدو وكأنها تبديل واحد، بينما يتم تنفيذ التسوية فعليًا عبر آليات منسّقة على عدة سلاسل.
ماذا يفعل Omniston بشكل مختلف؟
في جوهره، تم تصميم Omniston لإخفاء قدر كبير من التعقيد المرتبط بالتنفيذ عبر السلاسل.
بدلًا من مطالبة المستخدم بإكمال عدة إجراءات يدويًا عبر شبكات مختلفة، تعرض الواجهة نية واحدة عبر السلاسل: الأصل الذي يريد المستخدم بيعه، والأصل الذي يريد استلامه، والشبكات المعنية.
خلف هذا الطلب، يتنافس المُحلِّلون لتوفير السيولة من جهة الوجهة وتنفيذ المعاملة وفق الشروط المنقولة.
وهذا يخلق تمييزًا مهمًا.
لا يحتاج Omniston إلى جعل TON محطة وسيطة لكل مسار عبر السلاسل. في سيناريو EVM إلى EVM، يمكن للأصل في جهة المصدر والأصل في جهة الوجهة أن يبقيا على شبكتيهما التابعتين من نوع EVM بينما يقوم البروتوكول بتنسيق التسوية بينهما.
يتضمن دعم المرحلة 1 شبكات رئيسية مثل Ethereum وBNB Chain وBase وPolygon، ما يضع أساسًا لتبادل أصول عبر عدة شبكات دون مطالبة المستخدم ببناء مسار جسر يدويًا.
نموذج RFQ: السيولة تتنافس على الطلب
أحد أهم مكونات بنية Omniston هو نموذج RFQ.
يمثل RFQ طلب عرض سعر (Request for Quote).
بدلًا من الاعتماد حصريًا على مجمّع سيولة واحد لتحديد سعر التنفيذ، يتيح النظام للمُحلِّلين التنافس عبر تقديم عروض لطلب عبر السلاسل.
يبدو التدفق المبسّط مثل هذا:
يحدد المتداول الأصل الذي يريد بيعه والأصل الذي يريد استلامه.
يبث Omniston الطلب إلى المُحلِّلين المؤهلين.
يقيم المُحلِّلون الطلب وسيولة الوجهة وتكاليف التنفيذ وظروف الشبكة وعوامل أخرى.
تقوم بإرجاع عروض تصف ما يمكنها تقديمه.
يمكن للنظام بعدها اختيار مسار تنفيذ مناسب استنادًا إلى العروض المتاحة.
تعد هذه البنية مهمة بشكل خاص لتداول عبر السلاسل لأن السيولة قد تكون متشرذمة عبر الشبكات.
يمكن للمُحلِّل أن يوفر فعليًا سيولة حيث يحتاج إليها المستخدم على سلسلة الوجهة، مع تنسيق معاملة جهة المصدر بشكل منفصل.
بالنسبة للمتداول، يقلل ذلك الحاجة لفهم البنية التحتية خلف المسار.
لماذا تهم HTLCs المزدوجة؟
المكوّن الرئيسي الثاني هو استخدام Hashed Timelock Contracts، والتي يشار إليها عادةً باسم HTLCs.
التحدي في معاملة عبر السلاسل مفهوم بشكل مباشر:
كيف يمكن لطرفين تبادل أصول موجودة على سلاسل بلوكشين مختلفة دون الاعتماد على معاملة مشتركة واحدة؟
الإجابة هي إنشاء شروط تشفير متطابقة على الشبكتين.
في مثال مبسط، يقوم المتداول بحبس أصل داخل HTLC من جهة المصدر.
يتضمن هذا العقد:
hashlock، والتي تحدد السر المطلوب للمطالبة بالأموال.
timelock، والتي تحدد ما يحدث إذا لم يتم إكمال التبادل ضمن الفترة المسموح بها.
في المقابل، يقوم المُحلِّل بحبس أصل الوجهة المقابل باستخدام شرط HTLC متوافق.
وبالتالي يرتبط الجانبان بنفس السر التشفيري الأساسي.
السر ينسق التسوية
العنصر المهم في العملية هو السر المستخدم بواسطة hashlock.
لا يمكن ببساطة المطالبة بالأصول بشكل تعسفي. تحدد الشروط المضمنة في العقود كيف يمكن أن تحدث التسوية.
عندما يتم الكشف عن السر الصحيح للمطالبة بأحد جانبي التبادل، يمكن استخدام هذا السر لاستيفاء الشرط المطابق على الجانب الآخر.
وهذا يخلق آلية تسوية متزامنة بين سلاسل بلوكشين مستقلة.
الفكرة الأساسية ليست أن Ethereum وBase قد تشاركت فجأة دفتر حسابات مشترك.
لا.
بدلًا من ذلك، تفرض العقود على الشبكات المنفصلة قواعد متوافقة تسمح بإتمام التبادل وفق الشرط التشفيري نفسه.
وهذا ما يمنح الآلية خصائص التسوية الذرّية.
ماذا يحدث إذا فشلت الصفقة؟
يجب أيضًا أن تراعي البنية التحتية عبر السلاسل الفشل.
قد تصبح الشبكات مزدحمة. يمكن تأخير المعاملات. قد يفشل المُحلِّل في إكمال التنفيذ. قد لا يُستوفى شرط التسوية ضمن الفترة المطلوبة.
وهنا يصبح الـ timelock أمرًا حاسمًا.
إذا لم تُستوفَ الشروط المطلوبة للتسوية قبل وقت المهلة ذي الصلة، تتيح آلية HTLC للطرف المناسب استرداد الأصول المحبوسة وفق قواعد العقد.
لذلك فإن النظام غير معتمد على نجاح كل معاملة بشكل مثالي.
بدلًا من ذلك، تم تصميمه حول نتيجتين محتملتين:
تسوية ناجحة: يتم استيفاء الشرط التشفيري ويمكن المطالبة بالأصول.
المهلة: لا تكتمل التسوية ضمن النافذة المطلوبة وتصبح آلية الاسترداد متاحة.
وهذا يجعل الطلب عبر السلاسل أكثر مرونة من عملية يجب فيها على المستخدمين تنسيق عدة معاملات مستقلة يدويًا.
لماذا هذا مختلف عن DEX التقليدي
يعد تبديل DEX العادي بسيطًا نسبيًا لأن كلا الأصلين عادةً ما يكونان متاحين على السلسلة نفسها.
على سبيل المثال، يمكن لتاجر يقوم بتبديل توكن واحد مقابل توكن آخر على شبكة Ethereum أن يتفاعل مع مجمّع سيولة أو نظام توجيه يعمل بالكامل داخل بيئة التنفيذ الخاصة بـ Ethereum.
توفر البلوكشين حالةً مشتركة بالفعل اللازمة لتنفيذ الصفقة.
تبديلات EVM إلى EVM مختلفة.
على سبيل المثال، تحافظ Ethereum وPolygon على حالات مستقلة. لا تُنفّذ معاملة مُؤكدة على إحداهما تلقائيًا معاملة مكافئة على الأخرى.
لذا لا يمكن لـ Omniston اعتبار تبديل متعدد السلاسل معاملة واحدة حرفيًا على سلسلة بلوكشين واحدة.
بدلًا من ذلك، ينشئ نية تداول واحدة مدعومة بعدة خطوات تنفيذ منسقة.
قد تبدو الواجهة موحدة، لكن التسوية الأساسية تحدث بشكل منفصل على كل شبكة.
هذا التمييز مهم.
تأتي الذرية من قواعد البروتوكول والشروط التشفيرية وآليات المهلة، لا من معاملة واحدة سحرية تمتد عبر عدة بلوكشين.
لا يلزم وسيط TON
ومن جانب آخر مهم في تصميم Omniston من نوع EVM إلى EVM أن TON لا يتعين عليه الجلوس في منتصف المعاملة.
في مسار EVM إلى EVM، لا يحتاج المتداول بالضرورة إلى تحويل أصل المصدر إلى TON، ثم الانتقال عبر منظومة TON ثم تحويله مرة أخرى إلى أصل الوجهة المطلوب.
بدلًا من ذلك، يمكن لـ Omniston تنسيق سلسلتي المصدر والوجهة مباشرةً عبر بنية التنفيذ عبر السلاسل الخاصة بها.
يمكن أن يقلل ذلك من الخطوات غير الضرورية من منظور المستخدم، ويجعل التداول عبر عدة شبكات أقرب بكثير إلى تبديل عادي.
إذن يلخص ذلك التجريد المهم في:
طلب واحد، عدة شبكات، تسوية منسقة.
تعبئات جزئية للطلبات الأكبر
يواجه التداول عبر السلاسل أيضًا مشكلة سيولة تظهر بشكل أوضح كلما زاد حجم الطلب.
قد لا يتم دائمًا تعبئة طلب كبير بكفاءة من مصدر واحد أو مُحلِّل واحد.
يمكن لـ Omniston دعم عمليات تعبئة جزئية، ما يتيح التعامل مع الطلبات الأكبر عبر فرص تنفيذ متعددة بدل الاعتماد بالكامل على مصدر سيولة واحد.
قد يكون ذلك مفيدًا لأن سيولة عبر السلاسل نادرًا ما توزع بالتساوي.
قد يقدم مُحلِّل واحد تنفيذًا جذابًا لجزء من الطلب، بينما قد يكون آخر في وضع أفضل لجزء مختلف.
لذلك يمكن لنظام قادر على التعامل مع تنفيذ جزئي أن يكون أكثر مرونة عند التعامل مع سيولة متشرذمة.
تجربة المستخدم مقابل البنية التحتية
واحدة من أقوى أفكار Omniston هي الفصل بين ما يراه المستخدم وبين ما يتعين على البروتوكول فعله فعليًا.
ومن منظور المتداول، يمكن أن يبقى التدفق بسيطًا نسبيًا:
اختر الأصل الذي تريد بيعه.
اختر الأصل المراد استلامه.
راجع العرض المتاح.
وافق على المعاملة.
اترك عملية التنفيذ عبر السلاسل تكتمل.
لكن خلف هذه الواجهة البسيطة قد يحدث عدة أمور.
يتنافس المُحلِّلون على الطلب.
يتم تقييم السيولة.
يُؤخذ في الاعتبار تكلفة الغاز.
يتم تجهيز عقود المصدر والوجهة.
يتم إنشاء شروط HTLC.
يتم إرسال المعاملات بشكل مستقل إلى الشبكات المعنية.
يتم تنسيق التسوية عبر الشروط التشفيرية.
هذا التجريد مهم لأن المستخدمين عمومًا لا يريدون أن يصبحوا خبراء في تنسيق المعاملات عبر السلاسل فقط لنقل أصل بين شبكتين من نوع EVM.
ما الذي يظل مهمًا: العروض، والغاز، والسيولة
لا يلغي Omniston كل التحديات المرتبطة بتداول عبر السلاسل.
ما يزال تنفيذ الجودة يعتمد على عدة عوامل عملية.
جودة العرض مهمة. لا تكون مسارات عبر السلاسل مفيدة إلا إذا كان مقدار المستلم منافسًا.
تكاليف الغاز مهمة. يمكن لكل شبكة مشاركة إدخال رسوم معاملة تؤثر على التكلفة الإجمالية للتنفيذ.
الأهمية للسيولة. يحتاج المُحلِّل إلى سيولة كافية من جهة الوجهة كي يفي بالطلب بكفاءة.
شروط الشبكة مهمة. يمكن للازدحام وأوقات التأكيد وموثوقية المعاملات أن تؤثر في التنفيذ.
لذا بينما قد تبسط الواجهة العملية، لا تختفي الاقتصادات الأساسية للتداول.
يجعل التجريد عبر السلاسل التجربة أسهل؛ لكنه لا يجعل السيولة أو الرسوم أو ظروف الشبكة غير ذات صلة.
الأمان عبر التنسيق، لا عبر المركزية
طريقة أخرى مفيدة لفهم البنية هي أن Omniston لا يتطلب خزانة عبر سلاسل مشتركة واحدة يتم التحكم بها بواسطة وسيط واحد لعملية التبادل نفسها.
بدلًا من ذلك، تحافظ سلسلة المصدر وسلسلة الوجهة على عقودها الخاصة وتفرض شروطها الخاصة.
يحدث هذا التنسيق عبر منطق التنفيذ في البروتوكول والضمانات التشفيرية.
هذا الهيكل ذو معنى لأنه يقلل الفجوة المفاهيمية بين نية المستخدم وآلية التسوية الفعلية.
لا يثق المستخدم ببساطة بأن الوسيط سينقل الأصول في النهاية.
يتم تنظيم الصفقة بحيث تحدد العقود على الشبكات المعنية كيفية حدوث التبادل وما يحدث إذا لم تُستوفَ تلك الشروط.
الصورة الأكبر لتداول عبر السلاسل
توضح طريقة Omniston من نوع EVM إلى EVM تحولًا أوسع في التداول اللامركزي.
قد لا يعتمد مستقبل تجربة المستخدم عبر السلاسل على تعلم المستخدمين كيفية عمل كل بلوكشين على حدة.
بدلًا من ذلك، يمكن للبنية التحتية التعامل مع التوجيه واكتشاف السيولة وتنسيق التسوية تحت تجربة تداول موحدة.
ومن هذه الزاوية، تصبح مشكلة عبر السلاسل أقل ارتباطًا بنقل الأصول يدويًا بين السلاسل وأكثر ارتباطًا بصياغة نية:
“أريد بيع هذا الأصل هنا واستلام ذلك الأصل هناك.”
يتنافس المُحلِّلون بعد ذلك على تحقيق نية التنفيذ، بينما تضمن آليات التسوية التشفيرية أن يتبع التنفيذ القواعد المحددة.
هذا مختلف جوهريًا عن مجرد إضافة واجهة جسر أخرى.
يركز الجسر في المقام الأول على نقل الأصول أو تمثيلات الأصول بين الشبكات.
يركز النظام المعتمد على الطلب على إتمام الصفقة عبر الشبكات.
قد يصبح هذا التمييز أكثر أهمية مع استمرار نمو عدد النظم البيئية للبلوكشين والأصول ومواقع السيولة.
الخلاصة
تستند طريقة Omniston لتبديلات EVM إلى EVM إلى فكرة بسيطة مع بنية تحتية متقدمة تحت السطح.
بدلًا من التعامل مع تداول عبر السلاسل كسلسلة من معاملات جسور وDEX غير مرتبطة، فإنه يعامل العملية كطلب واحد عبر السلاسل.
يتنافس المُحلِّلون عبر نموذج RFQ.
يتم توفير سيولة الوجهة حيث يحتاج إليها المتداول.
تُنشئ HTLCs المزدوجة شروطًا تشفيرية عبر الشبكات المشاركة.
تنسّق Hashlocks المطالبات الناجحة.
توفر Timelocks مسارًا لاسترداد الأموال عند عدم اكتمال التسوية.
يمكن أن تساعد التعبئات الجزئية في معالجة الطلبات الأكبر.
والأهم من ذلك أن الصفقة لا تتطلب من TON أن يعمل كأصل وسيط أو شبكة لِمسار EVM إلى EVM.
النتيجة هي نظام يتفاعل فيه المتداول مع تدفق تبديل واحد موحد بينما تقوم عدة سلاسل بلوكشين مستقلة بالتنسيق تحته.
هذه هي القيمة الحقيقية للبنية التحتية عبر السلاسل: ليس جعل سلاسل البلوكشين متطابقة، بل جعل اختلافاتها أقل وضوحًا للمستخدم.
ومع تزايد تشرذم سيولة متعددة السلاسل، قد تلعب أنظمة مثل Omniston دورًا مهمًا في تحويل هذا التشرذم إلى تجربة تداول أبسط—حيث يركز المستخدم على الأصل الذي يريد تداوله والأصل الذي يريد استلامه، بينما تتولى البنية التحتية التعامل مع تعقيد تسوية الصفقة.
الخلاصة الأساسية: يجمع Omniston بين منافسة السيولة القائمة على RFQ والتسوية عبر السلاسل القائمة على HTLC، مما يحول تبديل EVM إلى EVM من عملية معقدة متعددة الخطوات إلى طلب منسّق مصمم للتنفيذ أو فك الارتباط بأمان وفق قواعد محددة مسبقًا.
اكتشف المزيد على STON.FI لتبديل EVM إلى EVM: https://app.ston.fi/swap?mode=cross-chain&in=bnb%3AUSDT&out=ethereum%3AUSDT
هل ستثق بمعمارية RFQ + HTLC للتبديلات الكبيرة عبر السلاسل، أم ما زلت تفضّل المسارات التقليدية المبنية على جسور؟