لأغراض تعليمية فقط؛ وليس نصيحة استثمارية أو قانونية أو أمنية. تعتمد سلامة HTLC على النصوص البرمجية أو العقود الدقيقة، وقواعد السلاسل، وسياسة التأكيد، والرسوم، والمراقبة، والتصرف في الوقت المناسب.
الإجابة المباشرة
العقد المقفل بالتجزئة والوقت (HTLC) دفعة مشروطة لها مسارا إنفاق متنافسان. قبل الانتهاء يستطيع المستفيد كشف قيمة x تتطابق تجزئتها مع القيمة الملتزم بها h = H(x) واستيفاء التواقيع أو الصلاحيات المطلوبة. بعد الانتهاء يستطيع الدافع استخدام مسار الاسترداد. تحدد السلسلة والعقد الترتيب الدقيق عند الحد، لا كلمة «قبل».
يربط قفل التجزئة الإجراءات: قد تتيح معرفة الصورة الأولية نفسها تسوية دفعة واردة مرتبطة بعد دفع دفعة صادرة. ويحد قفل الوقت مدة بقاء المال مشروطًا. تستخدم قنوات الدفع الخاصيتين لتمرير الدفعات، وتستخدمهما المبادلات الذرية لتنسيق التحويلات بين أنظمة منفصلة.
لا يجعل HTLC العملية تلقائيًا عديمة الثقة أو ذرية أو خاصة أو ذاتية التنفيذ. تتطلب السلامة أيضًا كودًا صحيحًا، وترميزًا متوافقًا، ومواعيد متدرجة، وافتراضات نهائية، ورسومًا متاحة، ومراقبة، وتأكيدًا في الوقت المناسب. HTLC في Lightning تصميم Bitcoin محدد؛ وقد تختلف دلالة عقد سلسلة أخرى.
- فرع التجزئة: اكشف الصورة الأولية واستوفِ صلاحية النجاح ما دام المسار صالحًا.
- فرع الوقت: استوفِ صلاحية الاسترداد بعد نضوج القفل المطلق أو النسبي.
آلية العمل
يختار Bob صورة أولية جديدة غير قابلة للتوقع x، ويحسب h = H(x)، ويسلم h إلى Alice. تقفل Alice الأموال بقواعد تلتزم بـ h وتحدد المخولين والانتهاء T.
- تتحقق Alice قبل التمويل من الخوارزمية والترميز والمبلغ والأصل والمستفيد ووجهة الاسترداد والسلسلة والانتهاء.
- يتحقق Bob من المخرج الممول فعليًا أو العقد المنشور، لا من مسودة أو واجهة.
- إذا طالب Bob عبر فرع النجاح يقدم
x؛ ويتحقق المنطق منH(x) = hوالصلاحية. - قد يتيح نشر
xأو نقله لـ Alice أو وسيط تسوية HTLC آخر يحمل تجزئة الدفع نفسها. - إن لم يستخدم فرع النجاح في وقته يصبح الاسترداد صالحًا عند
T؛ ولا يعني ذلك بثه أو تأكيده تلقائيًا. - يبقى على المشارك إعداد المعاملة أو حفظها، ودفع رسم كافٍ، وإرسالها، ومراقبة الاستبدالات والتعارضات، ونيل التأكيدات.
- بعد كشف
xلطرف مقابل أو سلسلة عامة، اعتبره مكشوفًا ولا تعد استخدامه لشرط غير مرتبط.
يميز Bitcoin بين الأقفال المطلقة والنسبية. يمنع OP_CHECKLOCKTIMEVERIFY في BIP 65 الإنفاق حتى ارتفاع الكتلة أو وقتها المشفر في locktime؛ وينتظر OP_CHECKSEQUENCEVERIFY في BIP 112 العمر النسبي الكافي للمدخل. يجب أن تتوافق حقول المعاملة أيضًا. فقفل الوقت قاعدة تحقق، وليس مجدولًا.
في Lightning تحمل update_add_htlc المبلغ وpayment_hash وcltv_expiry. يجعل كل مسار وسيط HTLC الصادر ينتهي قبل الوارد المقابل، ليبقى وقت للمطالبة في المنبع بعد معرفة الصورة الأولية. يحدد BOLT 3 مخارج الالتزام ومساري HTLC-success وHTLC-timeout والتواقيع والإلغاء وقص الغبار والتأخيرات؛ ولا يكفي فرعان لبناء قناة كاملة.
مثال
في مثال تعليمي، تبدل Alice مقدار 1 BTC مقابل 20 ETH لدى Bob. يوضح المثال الترتيب فقط؛ فالإنتاج يتطلب كودًا مراجعًا لكل سلسلة ولا ينبغي نسخ هذه المدد الاسمية.
- تنشئ Alice قيمتي
xوh = H(x)جديدتين، وتقفل1 BTCليطالب Bob بالصورة الأولية وتسترد Alice بعد48 hours. - بعد التحقق من معاملة Bitcoin وسياسة التأكيد، يقفل Bob مقدار
20 ETHبتجزئة وترميز متوافقين؛ ينتهي مسار Alice بعد24 hoursثم يتاح استرداد Bob. - قبل كشف
xللمطالبة بـ20 ETH، تتحقق Alice من معرف Ethereum والبايت كود والعنوان والأصل والمبلغ والأطراف وhوالمسارين. - يتعلم Bob قيمة
xمن المطالبة أو الرسالة المتفق عليها ويحاول مسار نجاح Bitcoin قبل الموعد الأبعد. - إذا توقف التبادل قبل الكشف، لا يصبح كل استرداد صالحًا إلا وفق قواعد سلسلته ويجب إرساله وتأكيده.
الفارق بين 48 hours و24 hours هامش استجابة لا قيمة آمنة عامة. يجب نمذجة إعادة التنظيم ووقت الكتل والنهائية والتنفيذ والترحيل ومجمع الذاكرة والرسوم والرقابة والتأخير في النظامين. لا ينبغي للطرف الثاني المتابعة لمجرد أن الواجهة تقول «مؤكد».
المخاطر
- التزام خاطئ: تختلف الخوارزمية أو الطول أو الترميز، فلا تصلح
xنفسها للطرفين. - عنصر خاطئ: يختلف المخرج أو معرف السلسلة أو العنوان أو البايت كود أو الأصل أو المبلغ أو المستفيد أو الاسترداد عن الواجهة.
- ترتيب غير آمن: تمنع المواعيد المتساوية أو المتقاربة المطالبة في المنبع بعد الدفع في المصب.
- خطأ الحد: لا يتساوى ارتفاع الكتلة ووقتها والطابع الزمني والعمر النسبي والمقارنتان
<و<=. - لا استرداد تلقائي: النضوج يجيز الإنفاق فقط؛ ويجب أن تتصرف محفظة أو عقدة أو مستخدم أو مراقب.
- الرسوم والغبار: قد تصبح المطالبة غير اقتصادية أو مقصوصة أو عالقة أو مستحيلة بلا أصل الرسوم الأصلي.
- التأكيد وإعادة التنظيم: رؤية معاملة أو صورة أولية لا تعني تسوية غير قابلة للعكس.
- السباق والازدحام: يستهلك النجاح أو انتهاء الوقت أو الاستبدال أو التعارض أو التأخير الهامش.
- التنفيذ: قد تبطل عيوب النص أو العقد أو المحفظة أو التوقيع أو nonce أو RPC أو العميل المسارات.
- المراقبة: قد يفوت الطرف غير المتصل الكشف أو الانتهاء أو الإغلاق القسري أو الاستبدال أو آخر وقت للبث.
- الخصوصية: قد تربط التجزئات المعادة والصور الأولية والمبالغ والأوقات وأحداث القناة بين التحويلات.
- الخيار والتعطيل: يستطيع طرف قفل السيولة ثم الانسحاب؛ فلا يضمن الإكمال أو التعويض.
قبل تعريض قيمة للخطر، اختبر مساري النجاح والاسترداد بمبلغ ضئيل، وسجل العناصر والمواعيد، واحتفظ بالرسوم، وحدد مسؤول المراقبة والبث عند الفشل.
مفاهيم خاطئة شائعة
- «تعود الأموال تلقائيًا عند الانتهاء». غالبًا يصبح الاسترداد صالحًا فقط؛ ويجب أن يبثه شخص ويؤكد.
- «تحقيق
H(x) = hهو العقد كله». التواقيع والفروع والحقول وقواعد السلسلة والإلغاء والصلاحيات مهمة أيضًا. - «الموعد نفسه للطرفين عادل». يحتاج الوسيط أو الطرف الثاني هامشًا في المنبع بعد معرفة
x. - «رؤية الصورة الأولية تضمن وقت المطالبة». قد تستهلكه التأكيدات وإعادة التنظيم والازدحام والرسوم والرقابة.
- «ذرّي يعني تغير السلسلتين في معاملة واحدة غير قابلة للتجزئة». تنسق حالات منفصلة؛ وتظل مسارات الإلغاء والاسترداد والحالات الأحادية المؤقتة.
- «HTLC مجهول ويلغي كل الثقة». قد يسرب إشارات ويعتمد على الكود والسلاسل والمفاتيح والمراقبة والتشغيل.
مواضيع ذات صلة
المصادر
- BIP 65: OP_CHECKLOCKTIMEVERIFY - Bitcoin Improvement Proposals (تاريخ الاطلاع: 2026-08-20)
- BIP 112: CHECKSEQUENCEVERIFY - Bitcoin Improvement Proposals (تاريخ الاطلاع: 2026-08-20)
- BOLT #2: بروتوكول النظراء لإدارة القنوات - Lightning BOLTs (تاريخ الاطلاع: 2026-08-20)
- BOLT #3: تنسيقات معاملات ونصوص Bitcoin - Lightning BOLTs (تاريخ الاطلاع: 2026-08-20)
- BOLT #4: بروتوكول التوجيه البصلي - Lightning BOLTs (تاريخ الاطلاع: 2026-08-20)