أصبح تعبير "غير احتجازي" واحدًا من تلك الكلمات التي تظهر في كل مكان داخل التمويل اللامركزي (DeFi).
المحفظة غير احتجازية.
الـ DEX غير احتجازي.
مبادلة عبر سلاسل الكتل غير احتجازية.
لكن هناك سؤال مهم غالبًا ما يتم تجاهله:
ماذا يحدث لأصولك بين لحظة أن تضغط "تبديل" ولحظة أن تتلقى الأصل الآخر؟
يصبح هذا السؤال أكثر إثارة للاهتمام عندما تدخل عدة سلاسل بلوكشين في الصورة.
المشكلة في الاكتفاء بالقول "غير احتجازية"
على سلسلة بلوكشين واحدة، يكون فهم الفكرة أسهل نسبيًا.
أنت تتحكم في محفظتك وتوقّع على معاملة، ثم ينفّذ عقد ذكي وفقًا لقواعد محددة مسبقًا.
المعاملات عبر السلاسل مختلفة.
لا توجد حالة واحدة مشتركة لسلسلة كتل يفهمها كلتا الشبكتين تلقائيًا. لكل سلسلة آليات توافق مختلفة وافتراضات نهائية وبيئات معاملات مختلفة.
لذا يجب أن توجد آلية ما لتنسيق عملية التبادل.
وبشكل تاريخي، كان ذلك غالبًا يعني الجسور، أو الأصول المرمّزة، أو المُوَسِّطين/المدققين، أو الاحتياطيات لدى جهة حافظة.
وهنا يمكن أن يصبح تعريف «غير حافظ» أقل وضوحًا.
نموذج الجسر التقليدي
يعمل تصميم جسر شائع تقريبًا بهذا الشكل:
تُودع أصلًا على السلسلة (A).
يقوم الجسر بإقفال ذلك الأصل.
ثم يتم إتاحة تمثيلٍ مطابق على السلسلة (B).
من منظور واجهة المستخدم، قد يبدو الأمر مطابقًا تقريبًا لتحريك الأصل الأصلي.
لكن من الناحية البنيوية، أنت الآن تعتمد على النظام في الاحتفاظ بالأموال الأساسية أو التحكم بها.
وهذا يطرح مجموعة أخرى من الأسئلة:
من يتحكم في الأصول المُقفلة؟
من يمكنه تفويض عمليات السحب؟
كيف يتم دعم الأصل المرمّز؟
ماذا يحدث إذا تم اختراق بنية الجسر التحتية؟
المشكلة ليست أن كل جسر غير آمن بطبيعته.
الأهم هو أن أمن معاملة عبر السلاسل الخاصة بك يصبح مرتبطًا بأمن نظام آخر.
هناك طريقة أخرى للتفكير في مبادلات عبر السلاسل
بدلًا من السؤال:
«كيف ننقل هذا الأصل من سلسلة إلى أخرى؟»
يمكنك أن تسأل:
«كيف نتبادل أصلًا على سلسلة واحدة مقابل أصل أصلي على سلسلة أخرى؟»
هذا فرق دقيق.
عادةً ما ينقل الجسر تمثيلًا لقيمة بين الشبكات.
يُنسّق تبادل ذري عبر السلاسل تبادلًا بين طرفين.
ليس من الضروري أن يستلم المستخدم نسخة مرمّزة من الأصل الأصلي.
يمكنهم استلام الأصل الأصلي الموجود بالفعل على سلسلة الوجهة.
وهذا هو النموذج وراء Omniston، طبقة التنفيذ عبر السلاسل من STON.fi.
أين تدخل resolvers في الصورة
توجد مشكلة كبيرة واحدة في المبادلات الذرّية من نظير إلى نظير عبر سلاسل بشكل تقليدي:
السيولة.
حتى لو كانت التقنية تسمح لطرفين بالتبادل دون ثقة، فأنت ما زلت تحتاج إلى شخص على الجانب الآخر من الصفقة.
إيجاد طرف مقابل يدويًا ليس عمليًا بالنسبة للمستخدمين العاديين.
تتعامل Omniston مع ذلك عبر شبكة من الـ resolvers.
عندما يرغب المستخدم في تنفيذ مبادلة عبر سلاسل، يمكن إرسال الطلب إلى عدة مزودي سيولة مستقلين عبر عملية RFQ.
يتنافس الـ resolvers لتقديم عرض سعر للتنفيذ.
ليس من الضروري أن يبحث المستخدم عن طرف مقابل بنفسه.
وهذا يحوّل عمليًا سيولة عبر السلاسل إلى سوق بدلًا من الاعتماد على بركة واحدة ضخمة من الأصول.
الجزء الذي يجعل النموذج مثيرًا للاهتمام: HTLCs
سوق السيولة يحل مشكلة الطرف المقابل.
لكن لا يزال هناك من يجب أن يتأكد من تسوية جانبي المعاملة بشكل صحيح بالفعل.
هنا يأتي دور عقود الـ Hashed Timelock Contracts (HTLCs).
الفكرة الأساسية بسيطة بشكل مدهش.
يرتبط جانبا المبادلة عبر سر تشفيري.
إذا تم كشف السر المطلوب ضمن نافذة الوقت المحددة، يمكن للمعاملات المقابلة أن تُسوّى.
إذا لم تتحقق الحالة، فإن مؤقت الـ timelock يسمح بإعادة الأموال إلى صاحبها.
لذا صُمّم النظام حول نتيجة واحدة إما تنجح بالكامل أو تفشل بالكامل
إما أن تكتمل المبادلة، أو تنعكس المعاملة/تنفك.
تصف وثائق STON.fi نموذج Omniston عبر السلاسل بناءً على HTLCs مزدوجة، مع وجود نفس الشرط المشفر الذي يربط بين جانبي المصدر والوجهة.
هذا يغيّر نموذج الثقة بشكل كبير.
بدلًا من الاعتماد على وسيط يقرر يدويًا ما إذا كان يجب تحرير أموالك، يتم فرض شروط التسوية بواسطة العقود.
Resolver + HTLC: لماذا تهم هذه التركيبة
لا يحل أي من المكوّنين المشكلة بالكامل لوحده.
توفّر HTLCs آلية التسوية.
توفر الـ resolvers السيولة والتنفيذ.
معًا، يخلقان شيئًا أكثر عملية.
طلب المستخدم → عروض أسعار متنافسة → تنفيذ resolver → تسوية تشفيرية
وهذا ما يجعل المبادلات الذرّية المعتمدة على resolvers مختلفة عن الفكرة القديمة المتمثلة فقط في إيجاد شخص آخر مستعد للتداول معك.
تحصل على خصائص الأمان الخاصة بالتسوية الذرّية، مع وجود سوق لمقدمي سيولة محترفين يتنافسون لملء الأوامر.
وبالأهمية، لا يُفترض أن تتحول الـ resolvers إلى جهات حافظة لأموال المستخدمين.
تتمثل مهمته في توفير السيولة وتنفيذ الشروط التي يحددها البروتوكول.
ماذا يستلم المستخدم فعليًا؟
هذه تفاصيل أخرى غالبًا ما يتم تجاهلها.
في الجسر التقليدي، قد تكون الأصول في الوجهة تمثيلًا مرمّزًا.
مع مبادلة عبر سلاسل ذرّية، يمكن بدلًا من ذلك أن يكون الهدف تسليم أصل الوجهة الأصلي.
على سبيل المثال، يمكن لمستخدم ينقل قيمة من TON باتجاه نظام بيئي مبني على EVM أن يستلم أصل السلسلة الوجهة بدلًا من تمثيل الجسر المُصدر للرمز الأصلي. توصف STON.fi حاليًا Omniston كمسار خالٍ من الجسور للمبادلات الذرّية عبر السلاسل للأصول الأصلية.
وهذا يجعل الفرق أكثر من مجرد تفصيل تقني.
أنت لا تقوم فقط بنقل تمثيل رمز.
أنت تُجري تبادلًا بين أصول موجودة بشكل أصلي على شبكات مختلفة.
هل يلغي ذلك كل المخاطر؟
لا.
وهذا هو المكان الذي أعتقد فيه أن النقاشات حول البنية التحتية غير الحافظة يجب أن تظل صادقة.
ما زال النظام المعتمد على resolver يعتمد على أشياء مثل:
صحة العقود الذكية
سيولة نشطة من resolvers
تغطية السلاسل المدعومة
عروض أسعار تنافسية
توافر السلسلة والنهائية
التنفيذ الصحيح لمنطق التسوية
غير حافظة لا يعني خالية من المخاطر.
يعني أن النظام صُمّم لتقليل الاعتماد على طرف ثالث يأخذ تحكمًا تقديريًا على أموالك إلى أدنى حد.
هذا فرق مهم.
قائمة تحقق أفضل لتقييم مبادلات عبر السلاسل
بدلًا من السؤال فقط ما إذا كانت المنصة تقول «غير حافظة»، أعتقد أن على المستخدمين طرح عدة أسئلة أكثر تحديدًا:
1. من يستطيع نقل الأموال؟
هل توجد جهة مركزية أو مجموعة مدققين أو جهة حافظة لديها تحكم أحادي؟
2. ماذا يحدث إذا فشلت المبادلة؟
هل تحتاج إلى التواصل مع الدعم، أم أن آلية الاسترداد تُطبَّق تلقائيًا؟
3. ما الأصل الذي تستلمه؟
هل هو أصل الوجهة الأصلي أم تمثيل مرمّز؟
4. من أين تأتي السيولة؟
احتياطي واحد؟ تجمع جسر؟ عدة مزودين سيولة متنافسين؟
5. ما الذي يفرض التسوية فعليًا؟
مشغل موثوق، أم شروط تشفيرية مفروضة على السلسلة؟
تخبرك هذه الأسئلة كثيرًا أكثر مما يمكن لوسم «غير حافظة» أن يفعله على الإطلاق.
لماذا أعتقد أن هذا مهم بالنسبة لـ DeFi
تزداد أهمية البنية التحتية عبر السلاسل مع توقف المستخدمين عن النظر إلى سلاسل الكتل باعتبارها أنظمة معزولة.
لكن نقل القيمة عبر السلاسل لا ينبغي أن يتطلب من المستخدمين قبولًا أعمى لافتراضات أي جسر قد يكون هو الذي يربطهم.
الاتجاه الأكثر إثارة هو بنية تحتية يمكن فيها أن تكون السيولة والتنفيذ تنافسيين، بينما تظل التسوية مفروضة تشفيريًا.
وهذا هو تصور البنية المعتمدة على resolver + HTLC التي تستخدمها Omniston.
ولا يحاول جعل نشاط عبر السلاسل يبدو معقدًا بالنسبة للمستخدم.
بالطبع، يرى المستخدم فقط:
اختر الأصل → اختر الوجهة → احصل على عرض سعر → نفّذ المبادلة.
التعقيد موجود تحت مستوى الواجهة.
ومن المحتمل أن هذا هو الشكل الذي ينبغي أن تعمل به بنية تحتية جيدة.
الأهم ليس ما إذا كان البروتوكول يسمي نفسه غير حافظ للأموال.
الأهم هو ما إذا كانت بنية النظام تمنح هذا الادعاء معنى فعليًا.
هذا هو السؤال الذي سأطرحه قبل أن أثق بأي نظام عبر سلاسل بأصولي.
#STONfi #Omniston #DeFi #TON #CrossChain #Crypto #Web3 $TON