تتبّع دورة حياة المعاملة، ومعالجة الإخفاقات، وآليات الاسترداد عبر شبكات Rayls.
قد يبدو التحويل بين السلاسل بسيطًا على نحو خادع.
تختار رمزًا، وتُدخل عنوان الوجهة، وتؤكد المعاملة، ثم تنتظر وصول الأموال.
لكن ماذا يحدث بعد النقر على «تأكيد»؟
يجب أن يعالج سجل المصدر المعاملة. كما يجب أن تجهّز الخدمات الداعمة الرسالة وتنقلها. وعلى الوجهة التحقّق من العملية المقابلة وتنفيذها. وإذا حدث خلل في أي مرحلة، فيجب أن يكون للنظام إجراء محدد للتعامل معه.
وهذا يثير سؤالًا أردت التحقق منه في وثائق Rayls:
إذا أخفق تحويل عابر للسلاسل بعد نجاح المعاملة المصدرية، فما الذي يحدث للرموز فعليًا؟
الإجابة أكثر إثارة للاهتمام من مجرد حالة نجاح أو إخفاق. توثّق Rayls سلوكيات مختلفة للتحويل القياسي والتحويل الذري والتحويلات بين سجل Rayls Sovereign وسلسلة Rayls العامة.
ويكشف فهم هذه الاختلافات أيضًا عن مبدأ مهم في هندسة الأنظمة العابرة للسلاسل: قد تنجح المعاملة في مرحلة ما من دون اكتمال التحويل بأكمله.
1. التحويل عبر السلاسل سلسلة من الخطوات، لا معاملة واحدة
لنبدأ بتحويل قياسي بين مؤسستين داخل شبكة Rayls خاصة.
وعلى مستوى عالٍ، يبدو المسار على النحو التالي:
سجل Sovereign المُرسِل → Relayer → Private Network Hub → Relayer المستقبِلة → سجل Sovereign الوجهة
لكل مكوّن مسؤولية محددة.
يعالج السجل المُرسِل التحويل ويحرق الرموز المصدرية. وتُصدر نقطة النهاية فيه حدث MessageDispatched.
ترصد Relayer الخاصة بالمرسِل هذا الحدث، وتُعِدّ إثبات Merkle، وتشفّر الرسالة للمؤسسة الوجهة. ثم تُرسل الرسالة إلى Private Network Hub، الذي يتحقق من صحة الإثبات ويخزن الرسالة.
على الجانب المستقبِل، ترصد Relayer الوجهة الرسالة، وتفك تشفير الحمولة، وترسل العملية المقابلة إلى سجل الوجهة. وتتحقق نقطة النهاية في الوجهة من أن الرسالة لم تُنفَّذ من قبل، ثم يتولى معالج الرموز سكّ الرموز للمستلم.
لا يقتصر الأمر على انتقال الرموز بين رصيدين، بل هو عملية منسقة تشمل التنفيذ في المصدر وإعداد الرسالة والتحقق منها وتسليمها والتنفيذ في الوجهة.
وتكتسب عملية حرق الرموز في المصدر وسكّها في الوجهة أهمية خاصة، إذ تساعد على منع بقاء الأصل نفسه قابلًا للإنفاق بشكل مستقل على جانبي التحويل.
لكنها تثير أيضًا سؤالًا عن الاسترداد: ماذا يحدث إذا نجح حرق الرموز في المصدر ولم تنجح العملية في الوجهة؟
مرجع تقني رسمي:
2. كم يستغرق التحويل العادي فعليًا؟
لفتت انتباهي معلومة في الوثائق الرسمية: المدة الإجمالية المذكورة للتحويل القياسي عبر الشبكة الخاصة تقارب 30–60 ثانية.
وهذا تذكير مفيد بأن سرعة معاملة منفردة على سلسلة الكتل لا تحدد مدة إكمال العملية العابرة للسلاسل بأكملها.
تشمل العملية الموثقة عدة مراحل:
إرسال المعاملة المصدرية وتنفيذها محليًا.
اكتشاف الحدث بواسطة Relayer.
إنشاء إثبات Merkle.
تشفير الرسالة.
إرسال الرسالة إلى Private Network Hub.
اكتشاف حدث الوجهة.
فك التشفير والتنفيذ في الوجهة.
يسهم وقت الكتلة في Hub وفترات الاستطلاع التي تستخدمها Relayers إسهامًا كبيرًا في المدة الإجمالية.
يلزم تنفيذ بعض الأعمال الإضافية لتدفقات مثل Enygma والتسليم مقابل الدفع (DvP)، التي قد تتطلب إنشاء إثباتات عديمة المعرفة.
بالنسبة إلى مطوّر التطبيقات، يغيّر هذا التمييز طريقة عرض حالة المعاملة.
يؤكد إيصال المعاملة المصدرية تنفيذ المعاملة المصدرية. لكنه لا يثبت، بحد ذاته، أن الوجهة أتمّت جانبها من التحويل.
لذلك، ينبغي للواجهة المفيدة أن تميّز بين تأكيد المصدر والمعالجة عبر السلاسل والتنفيذ في الوجهة والاسترداد.
الأوقات المحددة هي توقعات موثقة، وليست ضمانًا بأن كل معاملة ستكتمل ضمن الفترة الزمنية نفسها.
المصدر:
https://docs.rayls.com/docs/how-a-cross-chain-transaction-works
3. أربع نقاط للإخفاق — ولماذا تختلف عن بعضها
لفهم الاسترداد، قسّمت العملية إلى أربعة سيناريوهات عملية للإخفاق.
السيناريو أ: إلغاء المعاملة المصدرية
إذا أُلغيت المعاملة في سجل Sovereign المُرسِل، فلن تُرسَل الرسالة العابرة للسلاسل.
لم ينتقل التحويل إلى عملية التسليم المعتادة عبر السلاسل. ويمكن للمرسِل التحقق من سبب الإلغاء وإعادة المحاولة بعد إصلاح المشكلة.
يختلف هذا اختلافًا جوهريًا عن تحويل أُحرقت فيه الرموز المصدرية بالفعل وبدأت عملية المراسلة.
السيناريو ب: تعطل خدمة مساندة مؤقتًا
تعتمد Relayer على خدمات مساندة لإعداد الرسائل ومعالجتها.
تصف الوثائق سلوك إعادة المحاولة عند تعذر إنشاء إثبات Merkle، أو عدم توفر Cryptographic Trust Suite، أو انتهاء مهلة واجهة برمجة التطبيقات الخاصة بإنشاء الإثبات.
هذه أمثلة على حالات إخفاق يمكن التعامل معها بإعادة محاولة العملية بدلًا من التخلي عن التحويل فورًا.
مشكلة مؤقتة في خدمة ما ومعاملة غير صالحة نهائيًا ليستا الأمر نفسه.
السيناريو ج: رفض Private Network Hub لإثبات
يتحقق Private Network Hub من صحة الإثبات المصاحب للرسالة العابرة للسلاسل.
إذا فشل التحقق من صحة الإثبات، تُرفض المعاملة وتُسجّل للتحقيق فيها.
يتيح مسار الاسترداد الموثق للتحويل الذري لـ Relayer بدء معاملة إلغاء في السجل المصدر، ما يعيد الرموز إلى المرسِل.
يوضح هذا الفرق بين اكتشاف عملية غير صالحة واسترداد حالة الأصل بعد تعذر إتمام تلك العملية.
السيناريو د: إخفاق العملية في الوجهة
قد يصل التحويل إلى الجهة المستقبِلة ومع ذلك يفشل أثناء التنفيذ في الوجهة.
يعتمد سلوك الاسترداد على بروتوكول التحويل.
بالنسبة إلى التحويل القياسي، تقول الوثائق إن إخفاق التنفيذ في الوجهة يُعلَّم على أنه إخفاق ويتطلب إعادة محاولة يدويًا.
أما في التحويل الذري، فيؤدي إخفاق التنفيذ في الوجهة إلى تشغيل تدفق الإلغاء التلقائي الموثق، ما يعيد الأموال إلى المصدر.
هذا التمييز جوهري. فمن غير الدقيق الادعاء بأن كل تحويل عابر للسلاسل في Rayls يُلغى تلقائيًا بعد أي إخفاق.
يعتمد ضمان الاسترداد على المسار المستخدم.
المصدر:
https://docs.rayls.com/docs/how-a-cross-chain-transaction-works
4. قد يبدو هذان المصطلحان مترادفين، لكنهما يشيران إلى إجراءين مختلفين.
تعني إعادة المحاولة تنفيذ العملية مرة أخرى. وهي مفيدة عندما يُحتمل زوال الإخفاق المؤقت — على سبيل المثال، عند عودة خدمة مساندة إلى العمل أو إمكان تكرار محاولة إنشاء الإثبات.
أما الإلغاء، في تدفقات الاسترداد الموثقة للتحويلات العابرة للسلاسل، فيعني بدء معاملة تعويضية تعيد حالة الأصل إلى ما كانت عليه في المصدر.
لنتأمل مثالًا مبسطًا.
تبدأ مؤسسة تحويل 100 رمز. تنجح المعاملة المصدرية وتُحرق الرموز في المصدر. لكن السجل المستقبِل لا يستطيع إكمال العملية في الوجهة.
في التحويل القياسي، تُعلَّم العملية الفاشلة في الوجهة على أنها إخفاق، وتنص الوثائق على ضرورة إعادة المحاولة يدويًا.
أما في التحويل الذري، فيضيف البروتوكول التنسيق ومسارًا للإرجاع. وإذا أخفقت المعاملة ضمن التدفق الذري الموثق، فيمكن استعادة الرموز في المصدر عبر عملية الإلغاء.
لا يكمن الفرق الأساسي في طريقة الإبلاغ عن الإخفاق فحسب، بل في ما يفعله البروتوكول بالأصل بعد الإخفاق.
وهناك أيضًا قيد مهم: الإلغاء معاملة بحد ذاته. لذا يجب إرسال آلية الاسترداد ومعالجتها. ولا ينبغي الخلط بين مسار الاسترداد التلقائي الموثق والادعاء بأن كل إخفاق تشغيلي يُعالَج فورًا أو من دون مراقبة.
المصدر:
https://docs.rayls.com/docs/sending-teleports
5. التحويل القياسي مقابل التحويل الذري
هذا هو أهم تمييز في هذا التحقيق.
يشترك التحويل القياسي والتحويل الذري في البنية الأوسع للتحويل عبر السلاسل، لكنهما يختلفان في معالجة الإخفاقات.
التحويل القياسي
تُحرق الرموز المصدرية.
تُعالَج الرسالة العابرة للسلاسل.
تحاول الوجهة تنفيذ التحويل.
إذا أخفق التنفيذ في الوجهة، تُعلَّم المعاملة على أنها إخفاق ويلزم إعادة المحاولة يدويًا.
التحويل الذري
تُضاف مراحل تنسيق وقفل/إلغاء قفل.
يتبع الجانب المستقبِل عملية الإنهاء الخاصة بالبروتوكول.
إذا تحققت شروط الإخفاق الموثقة، يدخل التحويل في تدفق الإلغاء التلقائي.
يمكن استعادة الأصل في المصدر بدلًا من ترك الاسترداد معتمدًا على إعادة المحاولة يدويًا.
يوثّق عقد Teleport في Private Network Hub نافذة قفل على السلسلة مدتها 240 ثانية للتدفق الذري. ولدى Relayer أيضًا مؤقّت إلغاء عند انتهاء المهلة خارج السلسلة، لكن ضبطه يعتمد على إعدادات النشر وليس قيمة ثابتة موحدة في البروتوكول.
هذه آليات منفصلة، ولا ينبغي التعامل معها على أنها مؤقّت واحد.
الخلاصة العملية واضحة: إذا كان التطبيق يحتاج إلى سلوك إلغاء تلقائي، فعليه أن يعرف بروتوكول التحويل الذي يستخدمه بالفعل. ولا يكفي اسم الشبكة وحده لتحديد سلوك الاسترداد.
مرجع رسمي:
https://docs.rayls.com/docs/sending-teleports
6. ما الذي يتغير عندما تكون الوجهة هي سلسلة Rayls العامة؟
يختلف المسار المباشر بين Rayls Sovereign وسلسلة Rayls العامة من الناحية المعمارية عن مسار الشبكة الخاصة.
وفقًا للوثائق الرسمية، لا يمر هذا الاتصال عبر Private Network Hub. بل يستخدم مجموعة منفصلة من العقود وعملية Relayer عامة مستقلة.
وتختلف آليات الأصول أيضًا باختلاف الاتجاه.
عندما تنتقل الرموز من سجل Sovereign إلى السلسلة العامة، تُقفل الرموز المصدرية وتُسك الرموز النظيرة المقابلة على الجانب العام.
وعندما تنتقل الرموز من السلسلة العامة إلى سجل Sovereign، تُحرق الرموز العامة ويُلغى قفل الرموز المقابلة في سجل Sovereign.
تراقب Relayer العامة كلا الجانبين. ويُعِدّ التنفيذ الموثق حمولة إلغاء ويخزنها عند إنشاء المعاملة الأمامية. وإذا أخفقت معاملة الوجهة، يمكن لخدمة الإلغاء استرجاع الحمولة المخزنة وإرسال معاملة الاسترداد إلى السلسلة المصدرية.
والنتيجة الموثقة هي أن التحويل الفاشل يعيد الأصل إلى جانبه الأصلي: فالتحويل الفاشل من Sovereign إلى السلسلة العامة يفتح قفل الرموز المصدرية، بينما يعيد التحويل الفاشل من السلسلة العامة إلى Sovereign الرموز إلى الجانب العام.
هذا تنفيذ مختلف عن تدفق Private Network Hub، مع أن كلا المسارين يهدف إلى تنسيق نقل الأصول بين السجلات.
لذلك، من المهم عدم افتراض أن العقود أو Relayer أو عملية معالجة الإخفاق نفسها تنطبق على كل اتصال في Rayls.
مرجع رسمي:
https://docs.rayls.com/docs/connecting-rayls-sovereign-to-the-public-chain
7. ما معنى ذلك للمطورين والمستخدمين؟
يشير هذا التحقيق إلى ثلاثة دروس عملية.
أولًا، تتبّع التحويل كاملًا، لا إيصال المصدر وحده.
ينبغي للتطبيق تتبّع المعاملة المصدرية ومعالجة الرسالة العابرة للسلاسل والتنفيذ في الوجهة وأي معاملة استرداد. وإلا فقد يعرض التحويل على أنه مكتمل قبل أوانه، أو يعجز عن توضيح سبب تعثره للمستخدمين.
ثانيًا، اجعل سلوك الاسترداد واضحًا.
لا ينبغي عرض عملية فاشلة تتطلب إعادة محاولة يدويًا كما لو أنها تسترد عافيتها تلقائيًا. وبالمثل، ينبغي ألا يخبر التطبيق المستخدم بأن الأموال قد أُعيدت قبل تأكيد معاملة الاسترداد.
ثالثًا، افهم البروتوكول قبل تقديم الضمانات.
للتحويل القياسي والتحويل الذري والمسار المباشر إلى السلسلة العامة آليات موثقة مختلفة. وينبغي للتطبيق الالتزام بضمانات الاسترداد التي تتوافق مع مساره الفعلي، بدلًا من تقديم وعد عام يشمل جميع تحويلات Rayls.
هذه استنتاجات تصميمية مستمدة من البنية الموثقة، وليست ادعاءات بأنني اختبرت كل مسارات الإخفاق بنفسي.
8. ما الذي تحققت منه — وما الذي لم أتحقق منه
تصف الوثائق الرسمية مراحل المعاملة وسلوك إعادة المحاولة ورفض الإثبات ومعالجة إخفاق الوجهة ومسارات الإلغاء التلقائي.
استخدمت هذه الأوصاف لمقارنة السلوكيات الموثقة واستخلاص الآثار العملية لتتبّع حالة التطبيق.
لم أنشر بيئة Rayls بنفسي، ولم أُحدِث إخفاقات في تحويل مباشر، ولم أتحقق من سلوك الاسترداد عبر سجلات المعاملات. هذا تحليل تقني يستند إلى الوثائق، وليس تجربة أُعيد تنفيذها والتحقق منها بشكل مستقل.
يمكن أن تتمثل تجربة لاحقة مفيدة في تنفيذ تحويل مضبوط، والتسبب في إخفاق التنفيذ في الوجهة، وتسجيل المعاملة المصدرية وإيصال الوجهة ومعاملة الإلغاء والأرصدة النهائية. ومن شأن تكرار هذه التجربة للتحويل القياسي والتحويل الذري أن يساعد في التحقق من الفرق بين مساري الاسترداد الموثقين.
وهذا من شأنه تحويل المقارنة المعمارية إلى نتيجة يمكن إعادة إنتاجها والتحقق منها بشكل مستقل.
أفكار أخيرة
لا ينبغي تقييم البنية التحتية العابرة للسلاسل من خلال قدرتها على إتمام التحويل فحسب.
بل ينبغي أيضًا تقييمها من خلال مدى وضوح سلوك النظام عندما يتعذر إكمال التحويل.
تصف وثائق Rayls آليات منفصلة لإعادة محاولة الإخفاقات المؤقتة ورفض العمليات غير الصالحة وإعادة محاولة التحويل القياسي الفاشل يدويًا وإلغاء التحويل الذري تلقائيًا أو إلغاء التحويل الفاشل عبر المسار المباشر إلى السلسلة العامة.
أهم درس هو أن عبارة «فشلت المعاملة» لا تشرح بالكامل ما حدث للأصل.
لفهم النتيجة، عليك معرفة موضع الإخفاق وبروتوكول التحويل المستخدم وما إذا كانت عملية الاسترداد الموثقة قد اكتملت بالفعل.
هذا هو مستوى التفاصيل الذي يحتاج إليه المطورون قبل تحويل البنية التحتية العابرة للسلاسل إلى تجربة موثوقة للمستخدم.
المراجع التقنية الرسمية
آلية عمل المعاملة العابرة للسلاسل
https://docs.rayls.com/docs/how-a-cross-chain-transaction-works
التحويلات
https://docs.rayls.com/docs/sending-teleports
ربط Rayls Sovereign بسلسلة Rayls العامة
https://docs.rayls.com/docs/connecting-rayls-sovereign-to-the-public-chain
#Rayls #TheRail #Blockchain #Web3 #CrossChain #Infrastructure