⏳ آليات قفل المعاملات القابلة للتحقق (HTLC): الساعة التي تحمي تبادلًا عبر السلاسل
تستخدم Omniston HTLCs مترابطة: HTLC عرض (bid) ثنائي الاتجاه على سلسلة المصدر وHTLC طلب (ask) على سلسلة الوجهة. كلاهما يستخدم قفل تجزئة واحد.
🔐 سر واحد، قفلان
تُقفل أصول المستخدم في جهة المصدر بينما يقوم المحلِّل/المُحلّ (resolver) بإيداع أصوله الخاصة في جهة الوجهة. عندما يطالب المستخدم بأصل الوجهة، يصبح السرّ معلنًا للعموم، ويمكن للمحلّل استخدامه للمطالبة بأموال المصدر.
تدفق العمل هو:
- يقوم المستخدم بقفل الأصول على سلسلة المصدر.
- يقوم المحلّل بقفل الأصول على سلسلة الوجهة.
- يطالب المستخدم ويُفصح عن السر.
- يستخدمه المحلّل للمطالبة بأموال المصدر.
⏱ لا تُعد مهلة التوقيت مؤقت تبادل
مهلة التوقيت ليست الوقت المعتاد الذي يجب أن يستغرقه التبادل. يصف STONfi معظم عمليات التبادل عبر السلاسل بأنها تكتمل تقريبًا خلال 15–40 ثانية. أما مهلة التوقيت فهي تاريخ حد أمان أطول يُستخدم عند تعثر شيء ما.
قبل انتهاء المهلة، يمكن للسر فك قفل HTLC. بعد انتهاء المهلة، يستطيع المالك الأصلي استردادها. وهذا يخلق مسار فشل محدد.
🌐 لماذا يجب أن تختلف الساعتان
لا يمكن أن تكون المواعيد النهائية متطابقة ببساطة. يعمل المحلّل ثانيًا، لذلك يجب أن يبقى HTLC العرض على جهة المصدر صالحًا بعد بقاء HTLC الطلب على جهة الوجهة.
لننظر إلى حالة الفشل:
- يطالب المستخدم قرب موعد التسليم/الوجهة النهائي.
- يصبح السر مرئيًا على السلسلة.
- تؤدي ازدحامات الشبكة إلى تأخير مطالبة المحلّل في جهة المصدر.
- إذا انتهت مهلة المصدر أولًا، فقد يقوم المستخدم باسترداد الأموال الأصلية.
يوفر الفارق وقت رد فعل للمحلّل. حجمه يعتمد على نهائية المعاملة (finality) وتأخيرات الشبكة. هذا الفارق هو الضمان.
تدعم Omniston أيضًا عمليات تعبئة جزئية كعمليات فرعية مستقلة (sub-swaps). كل شريحة لها زوج HTLC خاص بها، مما يحد من تأثير الجزء الذي يفشل.
لا توجد مهلات التوقيت بهدف جعل عمليات التبادل الناجحة بطيئة. بل تحدد خروجًا مُتحكمًا عند فشل التسوية.
ليست نصيحة استثمارية — ابحث بنفسك! 🚀
$GRAM
تستخدم Omniston HTLCs مترابطة: HTLC عرض (bid) ثنائي الاتجاه على سلسلة المصدر وHTLC طلب (ask) على سلسلة الوجهة. كلاهما يستخدم قفل تجزئة واحد.
🔐 سر واحد، قفلان
تُقفل أصول المستخدم في جهة المصدر بينما يقوم المحلِّل/المُحلّ (resolver) بإيداع أصوله الخاصة في جهة الوجهة. عندما يطالب المستخدم بأصل الوجهة، يصبح السرّ معلنًا للعموم، ويمكن للمحلّل استخدامه للمطالبة بأموال المصدر.
تدفق العمل هو:
- يقوم المستخدم بقفل الأصول على سلسلة المصدر.
- يقوم المحلّل بقفل الأصول على سلسلة الوجهة.
- يطالب المستخدم ويُفصح عن السر.
- يستخدمه المحلّل للمطالبة بأموال المصدر.
⏱ لا تُعد مهلة التوقيت مؤقت تبادل
مهلة التوقيت ليست الوقت المعتاد الذي يجب أن يستغرقه التبادل. يصف STONfi معظم عمليات التبادل عبر السلاسل بأنها تكتمل تقريبًا خلال 15–40 ثانية. أما مهلة التوقيت فهي تاريخ حد أمان أطول يُستخدم عند تعثر شيء ما.
قبل انتهاء المهلة، يمكن للسر فك قفل HTLC. بعد انتهاء المهلة، يستطيع المالك الأصلي استردادها. وهذا يخلق مسار فشل محدد.
🌐 لماذا يجب أن تختلف الساعتان
لا يمكن أن تكون المواعيد النهائية متطابقة ببساطة. يعمل المحلّل ثانيًا، لذلك يجب أن يبقى HTLC العرض على جهة المصدر صالحًا بعد بقاء HTLC الطلب على جهة الوجهة.
لننظر إلى حالة الفشل:
- يطالب المستخدم قرب موعد التسليم/الوجهة النهائي.
- يصبح السر مرئيًا على السلسلة.
- تؤدي ازدحامات الشبكة إلى تأخير مطالبة المحلّل في جهة المصدر.
- إذا انتهت مهلة المصدر أولًا، فقد يقوم المستخدم باسترداد الأموال الأصلية.
يوفر الفارق وقت رد فعل للمحلّل. حجمه يعتمد على نهائية المعاملة (finality) وتأخيرات الشبكة. هذا الفارق هو الضمان.
تدعم Omniston أيضًا عمليات تعبئة جزئية كعمليات فرعية مستقلة (sub-swaps). كل شريحة لها زوج HTLC خاص بها، مما يحد من تأثير الجزء الذي يفشل.
لا توجد مهلات التوقيت بهدف جعل عمليات التبادل الناجحة بطيئة. بل تحدد خروجًا مُتحكمًا عند فشل التسوية.
ليست نصيحة استثمارية — ابحث بنفسك! 🚀
$GRAM
