تبادل عبر السلاسل (cross-chain swap) لديه مشكلتان مختلفتان جدًا تختبئان تحت واجهة الاستخدام.
أولًا، تحتاج إلى إيجاد صفقة جيدة.
ثم تحتاج إلى التأكد من أن الصفقة تتم فعليًا بشكل صحيح.
تبدو هاتان المشكلتان مترابطتين، لكنهما تتطلبان آليات مختلفة.
إن معمارية STON.fi حول Omniston مثيرة للاهتمام لأنها تتعامل معهما بشكل منفصل.
الطبقة الأولى هي RFQ، أو Request for Quote (طلب عرض سعر).
بدلًا من ترك المستخدم يبحث يدويًا عبر مصادر سيولة مختلفة، يمكن للنظام طلب عروض الأسعار من مُحلِّلين/مُحسّنين محترفين.
هؤلاء المُحلِّلون يتنافسون لملء الصفقة، مما يخلق عملية اكتشاف للعروض بحيث يمكن مقارنة العروض المتاحة قبل التنفيذ.
هذا يعالج جانب التسعير والاتجاهات المتعلقة بالسيولة من المشكلة.
لكن العرض ما زال مجرد اتفاق.
لا بد في النهاية أن تتحرك الأصول.
وهنا يأتي دور التسوية المعتمدة على HTLC.
تستخدم عقود Hashed Timelock Contracts شروطًا تشفيرية وحدودًا زمنية للتنسيق بين طرفي تبادل عبر سلسلتين.
يستخدم Omniston HTLCs مزدوجة عبر الشبكات المشاركة.
والفكرة المهمة هنا هي الذرّية (atomicity).
يُفترض أن يحدث التبادل إما وفقًا للشروط المتفق عليها، أو يمكن للعملية التراجع عبر آلية المهلة الزمنية.
لذا لا توجد آلية واحدة تحاول حل كل شيء.
يساعد RFQ على الإجابة عن:
"من الذي يستطيع أن يزوّدني بأفضل تنفيذ متاح؟"
يساعد HTLC على الإجابة عن:
"كيف نُنجز التسوية لذلك التنفيذ دون تحويل الصفقة إلى اختبار ثقة؟"
لهذا السبب، فإن هذا المزيج هو ما يجعل المعمارية تستحق الانتباه.
ليس DeFi عبر السلاسل مجرد نقل أصل من السلسلة (A) إلى السلسلة (B).
بل يتضمن اكتشاف السيولة، والتسعير، والأطراف المقابلة، والتنفيذ، والتسوية.
عندما يتم تنسيق هذه الأجزاء بشكل صحيح، يستطيع المستخدم التفاعل مع النظام من خلال تجربة أبسط بكثير.
ما زالت التعقيدات موجودة.
فقط أنها موجودة في مكانها الصحيح.
تحت الواجهة.
#STON.fi #defi
أولًا، تحتاج إلى إيجاد صفقة جيدة.
ثم تحتاج إلى التأكد من أن الصفقة تتم فعليًا بشكل صحيح.
تبدو هاتان المشكلتان مترابطتين، لكنهما تتطلبان آليات مختلفة.
إن معمارية STON.fi حول Omniston مثيرة للاهتمام لأنها تتعامل معهما بشكل منفصل.
الطبقة الأولى هي RFQ، أو Request for Quote (طلب عرض سعر).
بدلًا من ترك المستخدم يبحث يدويًا عبر مصادر سيولة مختلفة، يمكن للنظام طلب عروض الأسعار من مُحلِّلين/مُحسّنين محترفين.
هؤلاء المُحلِّلون يتنافسون لملء الصفقة، مما يخلق عملية اكتشاف للعروض بحيث يمكن مقارنة العروض المتاحة قبل التنفيذ.
هذا يعالج جانب التسعير والاتجاهات المتعلقة بالسيولة من المشكلة.
لكن العرض ما زال مجرد اتفاق.
لا بد في النهاية أن تتحرك الأصول.
وهنا يأتي دور التسوية المعتمدة على HTLC.
تستخدم عقود Hashed Timelock Contracts شروطًا تشفيرية وحدودًا زمنية للتنسيق بين طرفي تبادل عبر سلسلتين.
يستخدم Omniston HTLCs مزدوجة عبر الشبكات المشاركة.
والفكرة المهمة هنا هي الذرّية (atomicity).
يُفترض أن يحدث التبادل إما وفقًا للشروط المتفق عليها، أو يمكن للعملية التراجع عبر آلية المهلة الزمنية.
لذا لا توجد آلية واحدة تحاول حل كل شيء.
يساعد RFQ على الإجابة عن:
"من الذي يستطيع أن يزوّدني بأفضل تنفيذ متاح؟"
يساعد HTLC على الإجابة عن:
"كيف نُنجز التسوية لذلك التنفيذ دون تحويل الصفقة إلى اختبار ثقة؟"
لهذا السبب، فإن هذا المزيج هو ما يجعل المعمارية تستحق الانتباه.
ليس DeFi عبر السلاسل مجرد نقل أصل من السلسلة (A) إلى السلسلة (B).
بل يتضمن اكتشاف السيولة، والتسعير، والأطراف المقابلة، والتنفيذ، والتسوية.
عندما يتم تنسيق هذه الأجزاء بشكل صحيح، يستطيع المستخدم التفاعل مع النظام من خلال تجربة أبسط بكثير.
ما زالت التعقيدات موجودة.
فقط أنها موجودة في مكانها الصحيح.
تحت الواجهة.
#STON.fi #defi
